Re: [GIT PULL] TI changes for 2020.04-rc1
On Wed, Jan 29, 2020 at 8:48 AM Lokesh Vutla wrote: > > Hi Simon, > > On 29/01/20 12:40 PM, Simon Goldschmidt wrote: > > On Wed, Jan 29, 2020 at 6:00 AM Lokesh Vutla wrote: > >> > >> Hi Tom, > >> > >> Please find the pull request for v2020.04-rc1 containing TI specific > >> changes. > >> This PR brings in multiple features and should have sent before rc1 is > >> tagged. Due to multiple reviews, this is being sent a bit late. For > >> detailed changes please see the PR description below. > >> > >> Gitlab: https://gitlab.denx.de/u-boot/custodians/u-boot-ti/pipelines/2014 > >> Travis-ci: https://travis-ci.org/lokeshvutla/u-boot/builds/643198715 > >> > >> Thanks and regards, > >> Lokesh > >> > >> > >> The following changes since commit > >> b00c3c995bf2293e32cd2be3cb4be7eb39c4ac26: > >> > >> Prepare v2020.04-rc1 (2020-01-28 16:59:30 -0500) > >> > >> are available in the Git repository at: > >> > >> https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git > >> tags/ti-2020.04-rc1 > >> > >> for you to fetch changes up to f1a7f6f7ff2b4b32c8d6a6be380c443457a7a539: > >> > >> configs: j721e_evm_defconfig: Enable PCA953x IO expander (2020-01-29 > >> 08:07:12 +0530) > >> > >> > >> Below are the major changes in this PR: > >> - EMMC boot support on J721e > >> - DFU boot support for J721e > >> - I2C support for J721e > >> - Android boot image updates on AM57XX > >> > >> > >> Faiz Abbas (11): > >> mmc: Add a saved_clock member > > > > Sorry for not reacting on this one earlier, I was kind of offline for a > > week, > > but: > > This one has comments pending that weren't answered. > > Sorry for that. I missed the comment as I was not Cc ed. > > > > >> mmc: Add init() API > > > > This patch contains more than it says (removes non-DM init) and is not > > reviewed > > by the subsystem maintainer. In fact, it is not reviewed by anyone outside > > TI. > > I thought we wanted to establish the rule that code has to go through a > > subsystem maintainer's tree or get an RB by them to improve code quality? > > Agreed. IIRC, these were assigned to me in Patchworks, so I picked it as there > were no comments for quite some time. Peng, please let me know how you would > like to pick these patches once the comments are addressed I would have written a comment if I hadn't been kind of offline the last week. Let me do that now. Regards, Simon > > Tom, > Please ignore this pull-request. > > Thanks and regards, > Lokesh > > > > > >> mmc: Merge SD_LEGACY and MMC_LEGACY bus modes > >> mmc: sdhci: Expose sdhci_init() as non-static > > > > More unaddressed comments... > > > > Regards, > > Simon > > > >> mmc: am654_sdhci: Update output tap delay writes > >> mmc: am654_sdhci: Implement workaround for card detect > >> spl: mmc: Fix spl_mmc_get_uboot_raw_sector() implementation > >> arm: K3: sysfw-loader: Add a config_pm_pre_callback() > >> configs: am65x_evm: Add CONFIG_SUPPORT_EMMC_BOOT > >> configs: j721e_evm: Add Support for eMMC boot > >> configs: j721e_evm_a72: Fix redundant environment offset > >> > >> Sam Protsenko (10): > >> image: android: Add functions for handling dtb field > >> image: android: Add routine to get dtbo params > >> cmd: abootimg: Add abootimg command > >> doc: android: Add documentation for Android Boot Image > >> doc: android: Convert to Sphinx format > >> test/py: android: Add test for abootimg > >> configs: am57xx_evm: Enable Android commands > >> env: ti: boot: Respect slot_suffix in AVB commands > >> env: ti: boot: Boot Android with dynamic partitions > >> arm: ti: boot: Use correct dtb and dtbo on Android boot > >> > >> Vignesh Raghavendra (12): > >> arm: mach-k3: j721e: Rename BOOT_DEVICE_USB to BOOT_DEVICE_DFU > >> arm: mach-k3: sysfw-loader: Add support to download SYSFW via DFU > >> arm: dts: k3-j721e-common-proc-board: Enable USB0 in peripheral mode > >> configs: j721e_evm: Add DFU related variables > >> configs: j721e_evm_r5_defconfig: Increase early malloc size > >> configs: j721e_evm_r5/a72_defconfig: Enable USB Gadget related > >> configs > >> configs: j721e_evm_r5/a72_defconfig: Enable DFU related configs > >> gpio: pca953x_gpio: Add support for 24 bit IO expander > >> arm: dts: k3-j721e: Add I2C nodes > >> arm: dts: k3-j721e-common-proc-board: Add I2C GPIO expander > >> arm: dts: k3-j721e-common-proc-board: Enable I2C expander for SPL > >> configs: j721e_evm_defconfig: Enable PCA953x IO expander > >> > >> MAINTAINERS| 4 +- > >> arch/arm/dts/k3-am65-main.dtsi | 12 +- > >> arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 11 +- > >> .../arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 12 + > >>
Re: [GIT PULL] TI changes for 2020.04-rc1
Hi Simon, On 29/01/20 12:40 PM, Simon Goldschmidt wrote: > On Wed, Jan 29, 2020 at 6:00 AM Lokesh Vutla wrote: >> >> Hi Tom, >> >> Please find the pull request for v2020.04-rc1 containing TI specific changes. >> This PR brings in multiple features and should have sent before rc1 is >> tagged. Due to multiple reviews, this is being sent a bit late. For >> detailed changes please see the PR description below. >> >> Gitlab: https://gitlab.denx.de/u-boot/custodians/u-boot-ti/pipelines/2014 >> Travis-ci: https://travis-ci.org/lokeshvutla/u-boot/builds/643198715 >> >> Thanks and regards, >> Lokesh >> >> >> The following changes since commit b00c3c995bf2293e32cd2be3cb4be7eb39c4ac26: >> >> Prepare v2020.04-rc1 (2020-01-28 16:59:30 -0500) >> >> are available in the Git repository at: >> >> https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-2020.04-rc1 >> >> for you to fetch changes up to f1a7f6f7ff2b4b32c8d6a6be380c443457a7a539: >> >> configs: j721e_evm_defconfig: Enable PCA953x IO expander (2020-01-29 >> 08:07:12 +0530) >> >> >> Below are the major changes in this PR: >> - EMMC boot support on J721e >> - DFU boot support for J721e >> - I2C support for J721e >> - Android boot image updates on AM57XX >> >> >> Faiz Abbas (11): >> mmc: Add a saved_clock member > > Sorry for not reacting on this one earlier, I was kind of offline for a week, > but: > This one has comments pending that weren't answered. Sorry for that. I missed the comment as I was not Cc ed. > >> mmc: Add init() API > > This patch contains more than it says (removes non-DM init) and is not > reviewed > by the subsystem maintainer. In fact, it is not reviewed by anyone outside TI. > I thought we wanted to establish the rule that code has to go through a > subsystem maintainer's tree or get an RB by them to improve code quality? Agreed. IIRC, these were assigned to me in Patchworks, so I picked it as there were no comments for quite some time. Peng, please let me know how you would like to pick these patches once the comments are addressed Tom, Please ignore this pull-request. Thanks and regards, Lokesh > >> mmc: Merge SD_LEGACY and MMC_LEGACY bus modes >> mmc: sdhci: Expose sdhci_init() as non-static > > More unaddressed comments... > > Regards, > Simon > >> mmc: am654_sdhci: Update output tap delay writes >> mmc: am654_sdhci: Implement workaround for card detect >> spl: mmc: Fix spl_mmc_get_uboot_raw_sector() implementation >> arm: K3: sysfw-loader: Add a config_pm_pre_callback() >> configs: am65x_evm: Add CONFIG_SUPPORT_EMMC_BOOT >> configs: j721e_evm: Add Support for eMMC boot >> configs: j721e_evm_a72: Fix redundant environment offset >> >> Sam Protsenko (10): >> image: android: Add functions for handling dtb field >> image: android: Add routine to get dtbo params >> cmd: abootimg: Add abootimg command >> doc: android: Add documentation for Android Boot Image >> doc: android: Convert to Sphinx format >> test/py: android: Add test for abootimg >> configs: am57xx_evm: Enable Android commands >> env: ti: boot: Respect slot_suffix in AVB commands >> env: ti: boot: Boot Android with dynamic partitions >> arm: ti: boot: Use correct dtb and dtbo on Android boot >> >> Vignesh Raghavendra (12): >> arm: mach-k3: j721e: Rename BOOT_DEVICE_USB to BOOT_DEVICE_DFU >> arm: mach-k3: sysfw-loader: Add support to download SYSFW via DFU >> arm: dts: k3-j721e-common-proc-board: Enable USB0 in peripheral mode >> configs: j721e_evm: Add DFU related variables >> configs: j721e_evm_r5_defconfig: Increase early malloc size >> configs: j721e_evm_r5/a72_defconfig: Enable USB Gadget related configs >> configs: j721e_evm_r5/a72_defconfig: Enable DFU related configs >> gpio: pca953x_gpio: Add support for 24 bit IO expander >> arm: dts: k3-j721e: Add I2C nodes >> arm: dts: k3-j721e-common-proc-board: Add I2C GPIO expander >> arm: dts: k3-j721e-common-proc-board: Enable I2C expander for SPL >> configs: j721e_evm_defconfig: Enable PCA953x IO expander >> >> MAINTAINERS| 4 +- >> arch/arm/dts/k3-am65-main.dtsi | 12 +- >> arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 11 +- >> .../arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 12 + >> arch/arm/dts/k3-j721e-common-proc-board.dts| 27 ++ >> arch/arm/dts/k3-j721e-main.dtsi| 92 ++- >> arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 22 ++ >> arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 45 >> arch/arm/dts/k3-j721e.dtsi | 10 + >> arch/arm/mach-imx/imx8/image.c | 3 +- >> arch/arm/mach-k3/am6_init.c
Re: [GIT PULL] TI changes for 2020.04-rc1
On Wed, Jan 29, 2020 at 6:00 AM Lokesh Vutla wrote: > > Hi Tom, > > Please find the pull request for v2020.04-rc1 containing TI specific changes. > This PR brings in multiple features and should have sent before rc1 is > tagged. Due to multiple reviews, this is being sent a bit late. For > detailed changes please see the PR description below. > > Gitlab: https://gitlab.denx.de/u-boot/custodians/u-boot-ti/pipelines/2014 > Travis-ci: https://travis-ci.org/lokeshvutla/u-boot/builds/643198715 > > Thanks and regards, > Lokesh > > > The following changes since commit b00c3c995bf2293e32cd2be3cb4be7eb39c4ac26: > > Prepare v2020.04-rc1 (2020-01-28 16:59:30 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-2020.04-rc1 > > for you to fetch changes up to f1a7f6f7ff2b4b32c8d6a6be380c443457a7a539: > > configs: j721e_evm_defconfig: Enable PCA953x IO expander (2020-01-29 > 08:07:12 +0530) > > > Below are the major changes in this PR: > - EMMC boot support on J721e > - DFU boot support for J721e > - I2C support for J721e > - Android boot image updates on AM57XX > > > Faiz Abbas (11): > mmc: Add a saved_clock member Sorry for not reacting on this one earlier, I was kind of offline for a week, but: This one has comments pending that weren't answered. > mmc: Add init() API This patch contains more than it says (removes non-DM init) and is not reviewed by the subsystem maintainer. In fact, it is not reviewed by anyone outside TI. I thought we wanted to establish the rule that code has to go through a subsystem maintainer's tree or get an RB by them to improve code quality? > mmc: Merge SD_LEGACY and MMC_LEGACY bus modes > mmc: sdhci: Expose sdhci_init() as non-static More unaddressed comments... Regards, Simon > mmc: am654_sdhci: Update output tap delay writes > mmc: am654_sdhci: Implement workaround for card detect > spl: mmc: Fix spl_mmc_get_uboot_raw_sector() implementation > arm: K3: sysfw-loader: Add a config_pm_pre_callback() > configs: am65x_evm: Add CONFIG_SUPPORT_EMMC_BOOT > configs: j721e_evm: Add Support for eMMC boot > configs: j721e_evm_a72: Fix redundant environment offset > > Sam Protsenko (10): > image: android: Add functions for handling dtb field > image: android: Add routine to get dtbo params > cmd: abootimg: Add abootimg command > doc: android: Add documentation for Android Boot Image > doc: android: Convert to Sphinx format > test/py: android: Add test for abootimg > configs: am57xx_evm: Enable Android commands > env: ti: boot: Respect slot_suffix in AVB commands > env: ti: boot: Boot Android with dynamic partitions > arm: ti: boot: Use correct dtb and dtbo on Android boot > > Vignesh Raghavendra (12): > arm: mach-k3: j721e: Rename BOOT_DEVICE_USB to BOOT_DEVICE_DFU > arm: mach-k3: sysfw-loader: Add support to download SYSFW via DFU > arm: dts: k3-j721e-common-proc-board: Enable USB0 in peripheral mode > configs: j721e_evm: Add DFU related variables > configs: j721e_evm_r5_defconfig: Increase early malloc size > configs: j721e_evm_r5/a72_defconfig: Enable USB Gadget related configs > configs: j721e_evm_r5/a72_defconfig: Enable DFU related configs > gpio: pca953x_gpio: Add support for 24 bit IO expander > arm: dts: k3-j721e: Add I2C nodes > arm: dts: k3-j721e-common-proc-board: Add I2C GPIO expander > arm: dts: k3-j721e-common-proc-board: Enable I2C expander for SPL > configs: j721e_evm_defconfig: Enable PCA953x IO expander > > MAINTAINERS| 4 +- > arch/arm/dts/k3-am65-main.dtsi | 12 +- > arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 11 +- > .../arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 12 + > arch/arm/dts/k3-j721e-common-proc-board.dts| 27 ++ > arch/arm/dts/k3-j721e-main.dtsi| 92 ++- > arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 22 ++ > arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 45 > arch/arm/dts/k3-j721e.dtsi | 10 + > arch/arm/mach-imx/imx8/image.c | 3 +- > arch/arm/mach-k3/am6_init.c| 33 ++- > arch/arm/mach-k3/include/mach/j721e_spl.h | 2 +- > arch/arm/mach-k3/include/mach/sysfw-loader.h | 2 +- > arch/arm/mach-k3/j721e_init.c | 33 ++- > arch/arm/mach-k3/sysfw-loader.c| 36 ++- > cmd/Kconfig| 12 +- > cmd/Makefile | 1 + > cmd/abootimg.c | 258 +++ > common/Makefile
Re: [PATCH] global_data: remove unused mxc_i2c specific field
Hello Baruch,
Am 25.12.2019 um 16:57 schrieb Baruch Siach:
The srdata field is unused since commit 71204e95ce13228 ("i2c: mxc:
refactor i2c driver and support dm").
Cc: Peng Fan
Signed-off-by: Baruch Siach
Reviewed-by: Peng Fan
---
include/asm-generic/global_data.h | 3 ---
1 file changed, 3 deletions(-)
Applied to u-boot-i2c master.
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v3 00/23] i2c: designware_ic2: Improvements to timing and general cleanup
Hello Simon, Am 23.01.2020 um 19:48 schrieb Simon Glass: This series updates the Designware I2C driver to support reading its timing from the device tree and handling it in units of nanoseconds instead of clock cycles. A new function converts from nanoseconds to the units used by the I2C controller and makes sure that the requested bus speed is not exceeded. This is more accurate than the existing method. The series includes a few smaller clean-ups in the same driver. In addition the v2 series adds enums for i2c speed and updates drivers to use them. There is currently an existing configuration method used just for a few x86 boards (Baytrail). This method is retained but it should be removed in favour of using the device tree. I have not done this in this series since I am not sure of the timings to use. Changes in v3: - Fix the address of comp_param1 by adding a gap - Drop note about moving to driver model - Use ARRAY_SIZE() for i2c_specs bounds check - Add new patch with support for fast-plus speed - Add new patch to move dw_i2c_speed_config to header - Add new patch to separate out the speed calculation - Add new patch to do more in the probe() method Changes in v2: - Fix 'previde' typo - Add a few more clean-up patches for i2c Simon Glass (23): i2c: designware_i2c: Add more registers i2c: designware_i2c: Don't allow changing IC_CLK i2c: designware_i2c: Include clk.h in the header file i2c: designware_i2c: Rename 'max' speed to 'high' speed i2c: designware_i2c: Use an enum for selected speed mode i2c: designware_i2c: Use an accurate bus clock instead of MHz i2c: designware_i2c: Bring in the binding file i2c: designware_i2c: Read device-tree properties i2c: designware_i2c: Drop scl_sda_cfg parameter i2c: designware_i2c: Put hold config in a struct i2c: designware_i2c: Rewrite timing calculation i2c: designware_i2c: Add spike supression i2c: Add enums for i2c speed and address size i2c: ast_i2c: Update to use standard enums for speed i2c: designware_i2c: Update to use standard enums for speed i2c: kona_i2c: Update to use standard enums for speed i2c: omap: Update to use standard enums for speed i2c: stm32: Update to use standard enums for speed i2c: Update drivers to use enum for speed i2c: designware_i2c: Add support for fast-plus speed i2c: designware_i2c: Move dw_i2c_speed_config to header i2c: designware_i2c: Separate out the speed calculation i2c: designware_i2c: Do more in the probe() method .../i2c/i2c-designware.txt| 73 + drivers/i2c/ast_i2c.c | 2 +- drivers/i2c/ast_i2c.h | 2 - drivers/i2c/designware_i2c.c | 300 ++ drivers/i2c/designware_i2c.h | 73 - drivers/i2c/designware_i2c_pci.c | 4 +- drivers/i2c/exynos_hs_i2c.c | 5 +- drivers/i2c/fsl_i2c.c | 3 +- drivers/i2c/i2c-cdns.c| 2 +- drivers/i2c/i2c-uclass.c | 12 +- drivers/i2c/i2c-uniphier-f.c | 2 +- drivers/i2c/i2c-uniphier.c| 2 +- drivers/i2c/imx_lpi2c.c | 8 +- drivers/i2c/kona_i2c.c| 28 +- drivers/i2c/mv_i2c.c | 4 +- drivers/i2c/mvtwsi.c | 5 +- drivers/i2c/omap24xx_i2c.c| 5 +- drivers/i2c/omap24xx_i2c.h| 4 - drivers/i2c/rcar_i2c.c| 2 +- drivers/i2c/rcar_iic.c| 2 +- drivers/i2c/s3c24x0_i2c.c | 5 +- drivers/i2c/sandbox_i2c.c | 3 +- drivers/i2c/stm32f7_i2c.c | 43 +-- include/i2c.h | 26 ++ 24 files changed, 454 insertions(+), 161 deletions(-) create mode 100644 doc/device-tree-bindings/i2c/i2c-designware.txt Applied the hole series to u-boot-i2c master. Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[U-Boot] Please pull from u-boot-i2c
Hello Tom, please pull from u-boot-i2c master branch: The following changes since commit c05b38df477a50c3918b50c5f986592411785859: common: fix regression on block cache init (2020-01-26 13:36:14 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-i2c.git tags/for-v2020.04 for you to fetch changes up to 2034f6c27fc91407fe8bbd36670714b77d9ef1dc: i2c: designware_i2c: Do more in the probe() method (2020-01-27 07:25:00 +0100) i2c changes for 2020.04 - updates the Designware I2C driver - get timings from device tree - handle units in nanoseconds - make sure that the requested bus speed is not exceeded - few smaller clean-ups - adds enums for i2c speed and update drivers which use them - global_data: remove unused mxc_i2c specific field Baruch Siach (1): global_data: remove unused mxc_i2c specific field Simon Glass (23): i2c: designware_i2c: Add more registers i2c: designware_i2c: Don't allow changing IC_CLK i2c: designware_i2c: Include clk.h in the header file i2c: designware_i2c: Rename 'max' speed to 'high' speed i2c: designware_i2c: Use an enum for selected speed mode i2c: designware_i2c: Use an accurate bus clock instead of MHz i2c: designware_i2c: Bring in the binding file i2c: designware_i2c: Read device-tree properties i2c: designware_i2c: Drop scl_sda_cfg parameter i2c: designware_i2c: Put hold config in a struct i2c: designware_i2c: Rewrite timing calculation i2c: designware_i2c: Add spike supression i2c: Add enums for i2c speed and address size i2c: ast_i2c: Update to use standard enums for speed i2c: designware_i2c: Update to use standard enums for speed i2c: kona_i2c: Update to use standard enums for speed i2c: omap: Update to use standard enums for speed i2c: stm32: Update to use standard enums for speed i2c: Update drivers to use enum for speed i2c: designware_i2c: Add support for fast-plus speed i2c: designware_i2c: Move dw_i2c_speed_config to header i2c: designware_i2c: Separate out the speed calculation i2c: designware_i2c: Do more in the probe() method doc/device-tree-bindings/i2c/i2c-designware.txt | 73 drivers/i2c/ast_i2c.c | 2 +- drivers/i2c/ast_i2c.h | 2 - drivers/i2c/designware_i2c.c| 300 ++-- drivers/i2c/designware_i2c.h| 73 +--- drivers/i2c/designware_i2c_pci.c| 4 +- drivers/i2c/exynos_hs_i2c.c | 5 +- drivers/i2c/fsl_i2c.c | 3 +- drivers/i2c/i2c-cdns.c | 2 +- drivers/i2c/i2c-uclass.c| 12 ++--- drivers/i2c/i2c-uniphier-f.c| 2 +- drivers/i2c/i2c-uniphier.c | 2 +- drivers/i2c/imx_lpi2c.c | 8 ++-- drivers/i2c/kona_i2c.c | 28 +-- drivers/i2c/mv_i2c.c| 4 +- drivers/i2c/mvtwsi.c| 5 +- drivers/i2c/omap24xx_i2c.c | 5 +- drivers/i2c/omap24xx_i2c.h | 4 -- drivers/i2c/rcar_i2c.c | 2 +- drivers/i2c/rcar_iic.c | 2 +- drivers/i2c/s3c24x0_i2c.c | 5 +- drivers/i2c/sandbox_i2c.c | 3 +- drivers/i2c/stm32f7_i2c.c | 43 +++-- include/asm-generic/global_data.h | 3 -- include/i2c.h | 26 ++ 25 files changed, 454 insertions(+), 164 deletions(-) create mode 100644 doc/device-tree-bindings/i2c/i2c-designware.txt Travis build: https://travis-ci.org/hsdenx/u-boot-i2c/builds/642382247 bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[GIT PULL] TI changes for 2020.04-rc1
Hi Tom,
Please find the pull request for v2020.04-rc1 containing TI specific changes.
This PR brings in multiple features and should have sent before rc1 is
tagged. Due to multiple reviews, this is being sent a bit late. For
detailed changes please see the PR description below.
Gitlab: https://gitlab.denx.de/u-boot/custodians/u-boot-ti/pipelines/2014
Travis-ci: https://travis-ci.org/lokeshvutla/u-boot/builds/643198715
Thanks and regards,
Lokesh
The following changes since commit b00c3c995bf2293e32cd2be3cb4be7eb39c4ac26:
Prepare v2020.04-rc1 (2020-01-28 16:59:30 -0500)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-2020.04-rc1
for you to fetch changes up to f1a7f6f7ff2b4b32c8d6a6be380c443457a7a539:
configs: j721e_evm_defconfig: Enable PCA953x IO expander (2020-01-29 08:07:12
+0530)
Below are the major changes in this PR:
- EMMC boot support on J721e
- DFU boot support for J721e
- I2C support for J721e
- Android boot image updates on AM57XX
Faiz Abbas (11):
mmc: Add a saved_clock member
mmc: Add init() API
mmc: Merge SD_LEGACY and MMC_LEGACY bus modes
mmc: sdhci: Expose sdhci_init() as non-static
mmc: am654_sdhci: Update output tap delay writes
mmc: am654_sdhci: Implement workaround for card detect
spl: mmc: Fix spl_mmc_get_uboot_raw_sector() implementation
arm: K3: sysfw-loader: Add a config_pm_pre_callback()
configs: am65x_evm: Add CONFIG_SUPPORT_EMMC_BOOT
configs: j721e_evm: Add Support for eMMC boot
configs: j721e_evm_a72: Fix redundant environment offset
Sam Protsenko (10):
image: android: Add functions for handling dtb field
image: android: Add routine to get dtbo params
cmd: abootimg: Add abootimg command
doc: android: Add documentation for Android Boot Image
doc: android: Convert to Sphinx format
test/py: android: Add test for abootimg
configs: am57xx_evm: Enable Android commands
env: ti: boot: Respect slot_suffix in AVB commands
env: ti: boot: Boot Android with dynamic partitions
arm: ti: boot: Use correct dtb and dtbo on Android boot
Vignesh Raghavendra (12):
arm: mach-k3: j721e: Rename BOOT_DEVICE_USB to BOOT_DEVICE_DFU
arm: mach-k3: sysfw-loader: Add support to download SYSFW via DFU
arm: dts: k3-j721e-common-proc-board: Enable USB0 in peripheral mode
configs: j721e_evm: Add DFU related variables
configs: j721e_evm_r5_defconfig: Increase early malloc size
configs: j721e_evm_r5/a72_defconfig: Enable USB Gadget related configs
configs: j721e_evm_r5/a72_defconfig: Enable DFU related configs
gpio: pca953x_gpio: Add support for 24 bit IO expander
arm: dts: k3-j721e: Add I2C nodes
arm: dts: k3-j721e-common-proc-board: Add I2C GPIO expander
arm: dts: k3-j721e-common-proc-board: Enable I2C expander for SPL
configs: j721e_evm_defconfig: Enable PCA953x IO expander
MAINTAINERS| 4 +-
arch/arm/dts/k3-am65-main.dtsi | 12 +-
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 11 +-
.../arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 12 +
arch/arm/dts/k3-j721e-common-proc-board.dts| 27 ++
arch/arm/dts/k3-j721e-main.dtsi| 92 ++-
arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 22 ++
arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 45
arch/arm/dts/k3-j721e.dtsi | 10 +
arch/arm/mach-imx/imx8/image.c | 3 +-
arch/arm/mach-k3/am6_init.c| 33 ++-
arch/arm/mach-k3/include/mach/j721e_spl.h | 2 +-
arch/arm/mach-k3/include/mach/sysfw-loader.h | 2 +-
arch/arm/mach-k3/j721e_init.c | 33 ++-
arch/arm/mach-k3/sysfw-loader.c| 36 ++-
cmd/Kconfig| 12 +-
cmd/Makefile | 1 +
cmd/abootimg.c | 258 +++
common/Makefile| 2 +-
common/image-android.c | 282 +
common/spl/spl_mmc.c | 11 +-
configs/am57xx_evm_defconfig | 6 +
configs/am57xx_hs_evm_defconfig| 6 +
configs/am57xx_hs_evm_usb_defconfig| 6 +
configs/am65x_evm_a53_defconfig| 1 +
configs/am65x_evm_r5_defconfig | 1 +
configs/j721e_evm_a72_defconfig| 15 +-
configs/j721e_evm_r5_defconfig | 21 +-
configs/sandbox_defconfig | 1 +
doc/android/{ab.txt => ab.rst} | 39 +--
[PATCH v6 02/10] lib: elf: Move the generic elf loading/validating functions to lib
Move the generic elf loading/validating functions to lib/
so that they can be re-used and accessed by code existing
outside cmd.
While at it remove the duplicate static version of load_elf_image_phdr
under arch/arm/mach-imx/imx_bootaux.c.
Signed-off-by: Keerthy
Suggested-by: Simon Goldschmidt
Reviewed-by: Simon Goldschmidt
---
Changes in v6:
* Fixed a build issue due to duplicate static version of load_elf_image_phdr
under arch/arm/mach-imx/imx_bootaux.c
arch/arm/mach-imx/imx_bootaux.c | 46 --
cmd/Kconfig | 1 +
cmd/elf.c | 229
include/elf.h | 4 +
lib/Kconfig | 6 +
lib/Makefile| 1 +
lib/elf.c | 256
7 files changed, 268 insertions(+), 275 deletions(-)
create mode 100644 lib/elf.c
diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
index 21e96f8c88..8092268a3b 100644
--- a/arch/arm/mach-imx/imx_bootaux.c
+++ b/arch/arm/mach-imx/imx_bootaux.c
@@ -28,52 +28,6 @@ static const struct rproc_att *get_host_mapping(unsigned
long auxcore)
return NULL;
}
-
-/*
- * A very simple elf loader, assumes the image is valid, returns the
- * entry point address.
- */
-static unsigned long load_elf_image_phdr(unsigned long addr)
-{
- Elf32_Ehdr *ehdr; /* ELF header structure pointer */
- Elf32_Phdr *phdr; /* Program header structure pointer */
- int i;
-
- ehdr = (Elf32_Ehdr *)addr;
- phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
-
- /* Load each program header */
- for (i = 0; i < ehdr->e_phnum; ++i, ++phdr) {
- const struct rproc_att *mmap = get_host_mapping(phdr->p_paddr);
- void *dst, *src;
-
- if (phdr->p_type != PT_LOAD)
- continue;
-
- if (!mmap) {
- printf("Invalid aux core address: %08x",
- phdr->p_paddr);
- return 0;
- }
-
- dst = (void *)(phdr->p_paddr - mmap->da) + mmap->sa;
- src = (void *)addr + phdr->p_offset;
-
- debug("Loading phdr %i to 0x%p (%i bytes)\n",
- i, dst, phdr->p_filesz);
-
- if (phdr->p_filesz)
- memcpy(dst, src, phdr->p_filesz);
- if (phdr->p_filesz != phdr->p_memsz)
- memset(dst + phdr->p_filesz, 0x00,
- phdr->p_memsz - phdr->p_filesz);
- flush_cache((unsigned long)dst &
- ~(CONFIG_SYS_CACHELINE_SIZE - 1),
- ALIGN(phdr->p_filesz, CONFIG_SYS_CACHELINE_SIZE));
- }
-
- return ehdr->e_entry;
-}
#endif
int arch_auxiliary_core_up(u32 core_id, ulong addr)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index e6ba57035e..9819dd1aaf 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -399,6 +399,7 @@ config CMD_ABOOTIMG
config CMD_ELF
bool "bootelf, bootvx"
default y
+ select LIB_ELF
help
Boot an ELF/vxWorks image from the memory.
diff --git a/cmd/elf.c b/cmd/elf.c
index ba06df06cf..c129077e20 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -27,211 +27,6 @@
#include
#endif
-/*
- * A very simple ELF64 loader, assumes the image is valid, returns the
- * entry point address.
- *
- * Note if U-Boot is 32-bit, the loader assumes the to segment's
- * physical address and size is within the lower 32-bit address space.
- */
-static unsigned long load_elf64_image_phdr(unsigned long addr)
-{
- Elf64_Ehdr *ehdr; /* Elf header structure pointer */
- Elf64_Phdr *phdr; /* Program header structure pointer */
- int i;
-
- ehdr = (Elf64_Ehdr *)addr;
- phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
-
- /* Load each program header */
- for (i = 0; i < ehdr->e_phnum; ++i) {
- void *dst = (void *)(ulong)phdr->p_paddr;
- void *src = (void *)addr + phdr->p_offset;
-
- debug("Loading phdr %i to 0x%p (%lu bytes)\n",
- i, dst, (ulong)phdr->p_filesz);
- if (phdr->p_filesz)
- memcpy(dst, src, phdr->p_filesz);
- if (phdr->p_filesz != phdr->p_memsz)
- memset(dst + phdr->p_filesz, 0x00,
- phdr->p_memsz - phdr->p_filesz);
- flush_cache(rounddown((unsigned long)dst, ARCH_DMA_MINALIGN),
- roundup(phdr->p_memsz, ARCH_DMA_MINALIGN));
- ++phdr;
- }
-
- if (ehdr->e_machine == EM_PPC64 && (ehdr->e_flags &
- EF_PPC64_ELFV1_ABI)) {
- /*
-* For the 64-bit PowerPC ELF V1 ABI, e_entry is a function
-* descriptor pointer with the first double word being the
-
Re: [PATCH v5 00/10] Add support for loading main_r5fss0_core0
On 29/01/20 8:05 am, Lokesh Vutla wrote: On 28/01/20 4:21 PM, Keerthy wrote: This patch series enables mcu_r5fss0_core0 & main_r5fss0_core0. Tested for firmware loading and execution on J721e. Changes in v5: * Moved the fs_loader node under r5-common-proc-board-u-boot.dtsi * Added more information on the envnowhere patch. * Added help LIB_ELF option and removed user configurable description. There are many build errors with this series. https://travis-ci.org/lokeshvutla/u-boot/builds/642979303 Ah there is a static declaration of load_elf_image_phdr in arch/arm/mach-imx/imx_bootaux.c Should i send a fix patch alone on top? Thanks and regards, Lokesh Changes in v4: * Changed env variable names, config names and enhanced commit logs. Changes in v3: * Removed saving env in MMC and fixed env saving in SPL when nowhere option is set. Changes in v2: * Factored out all the generic elf handling functions under lib/elf.c Keerthy (10): env: nowhere: set default enviroment lib: elf: Move the generic elf loading/validating functions to lib arm: k3: Add support for loading non linux remote cores armv7R: K3: r5_mpu: Enable execute permission for MCU0 BTCM armv7R: K3: Add support for jumping to firmware arm: dts: k3-j721e-r5-u-boot: Add fs_loader node arm: dts: k3-j721e-r5: Enable r5fss0 cluster in SPL include: configs: j721e_evm: Add env variables for mcu_r5fss0_core0 & main_r5fss0_core0 configs: j721e_evm_r5: Enable R5F remoteproc support configs: j721e_evm_r5_defconfig: Remove saving ENV in eMMC .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 27 ++ .../arm/dts/k3-j721e-r5-common-proc-board.dts | 2 + arch/arm/mach-k3/common.c | 106 +++- arch/arm/mach-k3/common.h | 2 + arch/arm/mach-k3/j721e_init.c | 34 +++ arch/arm/mach-k3/r5_mpu.c | 4 +- cmd/Kconfig | 1 + cmd/elf.c | 229 configs/j721e_evm_r5_defconfig| 6 +- env/nowhere.c | 1 + include/configs/j721e_evm.h | 4 + include/elf.h | 4 + lib/Kconfig | 6 + lib/Makefile | 1 + lib/elf.c | 256 ++ 15 files changed, 438 insertions(+), 245 deletions(-) create mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi create mode 100644 lib/elf.c
[PATCH 2/2] arm: mvebu: clearfog: support multiple SATA boot
Enabled distro bootcmd support for additional SATA ports if enabled.
Signed-off-by: Joel Johnson
---
This patch builds on and requires the separate patch series adding
configurable SATA support ("arm: mvebu: clearfog: Add SATA mode flags").
---
include/configs/clearfog.h | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index a452f4b009..0bf7e9d950 100644
--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -111,15 +111,40 @@
#endif
#ifdef CONFIG_SCSI
-#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0)
+#define BOOT_TARGET_DEVICES_SCSI_M2SATA(func) func(SCSI, scsi, 0)
+
+/*
+ * Either one or both mPCIe slots may be configured as mSATA interfaces. The
+ * SCSI bus ids are assigned based on sequence of hardware present, not always
+ * tied to hardware slot ids. As such, use second SCSI bus if either slot is
+ * set for SATA, and only use third SCSI bus if both slots are SATA enabled.
+ */
+#if defined (CONFIG_CLEARFOG_CON2_SATA) || defined (CONFIG_CLEARFOG_CON3_SATA)
+#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func) func(SCSI, scsi, 1)
+#else
+#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func)
+#endif
+
+#if defined (CONFIG_CLEARFOG_CON2_SATA) && defined (CONFIG_CLEARFOG_CON3_SATA)
+#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func) func(SCSI, scsi, 2)
#else
-#define BOOT_TARGET_DEVICES_SCSI(func)
+#define BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func)
#endif
+#else
+#define BOOT_TARGET_DEVICES_SCSI_M2SATA(func)
+#endif /* CONFIG_SCSI */
+
+/*
+ * The SCSI buses are attempted in increasing bus order, there is no current
+ * mechanism to alter the default bus priority order for booting.
+ */
#define BOOT_TARGET_DEVICES(func) \
BOOT_TARGET_DEVICES_MMC(func) \
BOOT_TARGET_DEVICES_USB(func) \
- BOOT_TARGET_DEVICES_SCSI(func) \
+ BOOT_TARGET_DEVICES_SCSI_M2SATA(func) \
+ BOOT_TARGET_DEVICES_SCSI_CLEARFOG2(func) \
+ BOOT_TARGET_DEVICES_SCSI_CLEARFOG3(func) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
--
2.20.1
[PATCH 1/2] arm: mvebu: clearfog: add SCSI to distro bootcmd
Include attempting to boot from SCSI (SATA) devices within generated board distro bootcmd environment. The reasoning for boot ordering is that MMC and USB are external and removable, while when a case is in use, replacing M.2 or mSATA drives requires disassembly. Therefore, to boot SCSI, [bootable] external media must be removed. If SCSI were placed before MMC or USB, then removing a bootable SCSI drive to enable MMC or USB booting would be more difficult. Signed-off-by: Joel Johnson --- include/configs/clearfog.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index 633187d86f..a452f4b009 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -110,9 +110,16 @@ #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_SCSI +#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#else +#define BOOT_TARGET_DEVICES_SCSI(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_USB(func) \ + BOOT_TARGET_DEVICES_SCSI(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -- 2.20.1
Re: [PATCH v5 00/10] Add support for loading main_r5fss0_core0
On 28/01/20 4:21 PM, Keerthy wrote: > This patch series enables mcu_r5fss0_core0 & main_r5fss0_core0. > Tested for firmware loading and execution on J721e. > > Changes in v5: > > * Moved the fs_loader node under r5-common-proc-board-u-boot.dtsi > * Added more information on the envnowhere patch. > * Added help LIB_ELF option and removed user configurable description. There are many build errors with this series. https://travis-ci.org/lokeshvutla/u-boot/builds/642979303 Thanks and regards, Lokesh > > Changes in v4: > > * Changed env variable names, config names and enhanced commit logs. > > Changes in v3: > > * Removed saving env in MMC and fixed env saving in SPL when nowhere > option is set. > > Changes in v2: > > * Factored out all the generic elf handling functions under lib/elf.c > > Keerthy (10): > env: nowhere: set default enviroment > lib: elf: Move the generic elf loading/validating functions to lib > arm: k3: Add support for loading non linux remote cores > armv7R: K3: r5_mpu: Enable execute permission for MCU0 BTCM > armv7R: K3: Add support for jumping to firmware > arm: dts: k3-j721e-r5-u-boot: Add fs_loader node > arm: dts: k3-j721e-r5: Enable r5fss0 cluster in SPL > include: configs: j721e_evm: Add env variables for mcu_r5fss0_core0 & > main_r5fss0_core0 > configs: j721e_evm_r5: Enable R5F remoteproc support > configs: j721e_evm_r5_defconfig: Remove saving ENV in eMMC > > .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 27 ++ > .../arm/dts/k3-j721e-r5-common-proc-board.dts | 2 + > arch/arm/mach-k3/common.c | 106 +++- > arch/arm/mach-k3/common.h | 2 + > arch/arm/mach-k3/j721e_init.c | 34 +++ > arch/arm/mach-k3/r5_mpu.c | 4 +- > cmd/Kconfig | 1 + > cmd/elf.c | 229 > configs/j721e_evm_r5_defconfig| 6 +- > env/nowhere.c | 1 + > include/configs/j721e_evm.h | 4 + > include/elf.h | 4 + > lib/Kconfig | 6 + > lib/Makefile | 1 + > lib/elf.c | 256 ++ > 15 files changed, 438 insertions(+), 245 deletions(-) > create mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi > create mode 100644 lib/elf.c >
Pull request: u-boot-samsung master
Dear Tom,
The following changes since commit 052170c6a043eec4e73fad80955876cf1ba5e4f2:
configs: Resync with savedefconfig (2020-01-22 13:38:00 -0500)
are available in the git repository at:
g...@gitlab.denx.de:u-boot/custodians/u-boot-samsung.git master
for you to fetch changes up to 51521e43603d37e6be2ffd1ad2607361650500e9:
arm: exynos: odroid: Change autoboot script to use ${mmcbootdev} (2020-01-28
09:54:49 +0900)
Marek Szyprowski (8):
arm: dts: exynos: Extend board description
arm: exynos: Use proper ADC device name
arm: exynos: Use proper PMIC device names
mmc: s5p_sdhci: Read generic MMC properties from DT
arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2
arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card)
arm: exynos: Read default MMC device from XOM[7:5] pins
arm: exynos: odroid: Change autoboot script to use ${mmcbootdev}
arch/arm/dts/exynos4412-odroid.dts | 3 ++-
arch/arm/dts/exynos5422-odroidxu3.dts | 2 +-
arch/arm/mach-exynos/include/mach/cpu.h | 1 +
board/samsung/common/board.c| 28
board/samsung/common/exynos5-dt-types.c | 8
board/samsung/common/exynos5-dt.c | 6 +++---
configs/odroid-xu3_defconfig| 1 +
configs/odroid_defconfig| 1 +
drivers/mmc/s5p_sdhci.c | 5 +
include/configs/odroid.h| 10 +-
10 files changed, 51 insertions(+), 14 deletions(-)
--
Thanks,
Minkyu Kang.
Re: [PATCH v2 08/10] arm: K3: sysfw-loader: Add a config_pm_pre_callback()
On 1/24/20 8:52 PM, Faiz Abbas wrote:
> System firmware does not guarantee that clocks going out of the device
> will be stable during power management configuration. There are some
> DCRC errors when SPL tries to get the next stage during eMMC boot after
> sysfw pm configuration.
>
> Therefore add a config_pm_pre_callback() to switch off the eMMC clock
> before power management and restart it after it is done.
>
> Signed-off-by: Faiz Abbas
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/mach-k3/am6_init.c | 33 +++-
> arch/arm/mach-k3/include/mach/sysfw-loader.h | 2 +-
> arch/arm/mach-k3/j721e_init.c| 33 +++-
> arch/arm/mach-k3/sysfw-loader.c | 6 +++-
> 4 files changed, 70 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
> index 8d107b870b..9d3c62b3f4 100644
> --- a/arch/arm/mach-k3/am6_init.c
> +++ b/arch/arm/mach-k3/am6_init.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_SPL_BUILD
> #ifdef CONFIG_K3_LOAD_SYSFW
> @@ -86,6 +87,33 @@ static void store_boot_index_from_rom(void)
> bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
> }
>
> +#if defined(CONFIG_K3_LOAD_SYSFW)
> +void k3_mmc_stop_clock(void)
> +{
> + if (spl_boot_device() == BOOT_DEVICE_MMC1) {
> + struct mmc *mmc = find_mmc_device(0);
> +
> + if (!mmc)
> + return;
> +
> + mmc->saved_clock = mmc->clock;
> + mmc_set_clock(mmc, 0, true);
> + }
> +}
> +
> +void k3_mmc_restart_clock(void)
> +{
> + if (spl_boot_device() == BOOT_DEVICE_MMC1) {
> + struct mmc *mmc = find_mmc_device(0);
> +
> + if (!mmc)
> + return;
> +
> + mmc_set_clock(mmc, mmc->saved_clock, false);
> + }
> +}
> +#endif
> +
> void board_init_f(ulong dummy)
> {
> #if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS)
> @@ -128,7 +156,10 @@ void board_init_f(ulong dummy)
>* callback hook, effectively switching on (or over) the console
>* output.
>*/
> - k3_sysfw_loader(preloader_console_init);
> + k3_sysfw_loader(k3_mmc_stop_clock, k3_mmc_restart_clock);
> +
> + /* Prepare console output */
> + preloader_console_init();
>
> /* Disable ROM configured firewalls right after loading sysfw */
> #ifdef CONFIG_TI_SECURE_DEVICE
> diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h
> b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> index 36eb265348..6f5612b4fd 100644
> --- a/arch/arm/mach-k3/include/mach/sysfw-loader.h
> +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h
> @@ -7,6 +7,6 @@
> #ifndef _SYSFW_LOADER_H_
> #define _SYSFW_LOADER_H_
>
> -void k3_sysfw_loader(void (*config_pm_done_callback)(void));
> +void k3_sysfw_loader(void (*config_pm_pre_callback)(void), void
> (*config_pm_done_callback)(void));
>
> #endif
> diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
> index f7f7398081..0994522f6c 100644
> --- a/arch/arm/mach-k3/j721e_init.c
> +++ b/arch/arm/mach-k3/j721e_init.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_SPL_BUILD
> #ifdef CONFIG_K3_LOAD_SYSFW
> @@ -100,6 +101,33 @@ static void ctrl_mmr_unlock(void)
> mmr_unlock(CTRL_MMR0_BASE, 7);
> }
>
> +#if defined(CONFIG_K3_LOAD_SYSFW)
> +void k3_mmc_stop_clock(void)
> +{
> + if (spl_boot_device() == BOOT_DEVICE_MMC1) {
> + struct mmc *mmc = find_mmc_device(0);
> +
> + if (!mmc)
> + return;
> +
> + mmc->saved_clock = mmc->clock;
> + mmc_set_clock(mmc, 0, true);
Use MMC_CLK_DISABLE instead of true.
> + }
> +}
> +
> +void k3_mmc_restart_clock(void)
> +{
> + if (spl_boot_device() == BOOT_DEVICE_MMC1) {
> + struct mmc *mmc = find_mmc_device(0);
> +
> + if (!mmc)
> + return;
> +
> + mmc_set_clock(mmc, mmc->saved_clock, false);
ditto.
> + }
> +}
> +#endif
> +
> /*
> * This uninitialized global variable would normal end up in the .bss
> section,
> * but the .bss is cleared between writing and reading this variable, so move
> @@ -154,7 +182,10 @@ void board_init_f(ulong dummy)
>* callback hook, effectively switching on (or over) the console
>* output.
>*/
> - k3_sysfw_loader(preloader_console_init);
> + k3_sysfw_loader(k3_mmc_stop_clock, k3_mmc_restart_clock);
> +
> + /* Prepare console output */
> + preloader_console_init();
>
> /* Disable ROM configured firewalls right after loading sysfw */
> #ifdef CONFIG_TI_SECURE_DEVICE
> diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
> index 5903bbe12a..8386499ed6 100644
> --- a/arch/arm/mach-k3/sysfw-loader.c
> +++ b/arch/arm/mach-k3/sysfw-loader.c
> @@ -172,7 +172,8 @@
Re: [PATCH v2 01/10] mmc: Add a saved_clock member
On 1/24/20 8:52 PM, Faiz Abbas wrote:
> Add a saved_clock member to struct mmc to store the previous clock speed
> in the clock needs to be stopped for some time.
I think that it doesn't need to add saved_clock for mmc member.
This is for only yours. Does it impossible to add saved_clock in platdata?
And i'm not sure but mmc->tran_speed should be kept previous speed.
I will check it
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Faiz Abbas
> Signed-off-by: Lokesh Vutla
> ---
> include/mmc.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/mmc.h b/include/mmc.h
> index b5cb514f57..2f21dbf1b7 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -602,6 +602,7 @@ struct mmc {
> bool clk_disable; /* true if the clock can be turned off */
> uint bus_width;
> uint clock;
> + uint saved_clock;
> enum mmc_voltage signal_voltage;
> uint card_caps;
> uint host_caps;
>
Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static
On 1/24/20 8:52 PM, Faiz Abbas wrote:
> Expose sdhci_init() as non-static.
Does it need to change to non-static?
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Faiz Abbas
> Signed-off-by: Lokesh Vutla
> ---
> drivers/mmc/sdhci.c | 2 +-
> include/sdhci.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 01fa5a9d4d..4fce85a0ea 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -618,7 +618,7 @@ static int sdhci_set_ios(struct mmc *mmc)
> return 0;
> }
>
> -static int sdhci_init(struct mmc *mmc)
> +int sdhci_init(struct mmc *mmc)
> {
> struct sdhci_host *host = mmc->priv;
> #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_GPIO)
> diff --git a/include/sdhci.h b/include/sdhci.h
> index 01addb7a60..0830e05d53 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -487,6 +487,7 @@ void sdhci_set_uhs_timing(struct sdhci_host *host);
> #ifdef CONFIG_DM_MMC
> /* Export the operations to drivers */
> int sdhci_probe(struct udevice *dev);
> +int sdhci_init(struct mmc *mmc);
> int sdhci_set_clock(struct mmc *mmc, unsigned int clock);
> extern const struct dm_mmc_ops sdhci_ops;
> #else
>
Re: mmc init fails after soft reset on T1042
On 1/26/20 12:42 AM, Amarnath MB wrote: > Hi all, > > I working on a T1042RDB based custom board which has a 8GB eMMC (4bit mode) > on board. I was able to successfully boot 2019.07 uboot on my board from > NOR flash. > > After booting, mmcinfo command detects the on board eMMC and displays it's > properties. But when I issue mmcinfo command after soft reset through reset > command, it gives me mmc_init timeout error. Does mmcinfo display correct information? Or Does it boot with 1bit mode? > > After adding DEBUG and CONFIG_MMC_TRACE macros to my board header file, i > came to know that the eMMC fails to respond to CMD 2. It seems that you have set to wrong value for your eMMC. Could you share more information? Best Regards, Jaehoon Chung > > What can be the issue here? Can anyone guide me? > > Regards, > Amarnath MB > >
Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4
On 1/27/20 9:06 PM, Andre Przywara wrote: > On Mon, 27 Jan 2020 12:50:16 +0100 > LABBE Corentin wrote: > > Hi, > >> On Mon, Jan 27, 2020 at 04:27:03PM +0530, Amit Tomer wrote: >>> Hi, >>> The kernel panic just after with "OF: reserved mem: failed to allocate memory for node 'linux,cma'" but that's another story. >>> >>> But this comes even without having Ethernet patches and when one use >>> booti instead of bootefi, right ? >>> >> >> So booti is unsupported on rpi 4 ? > > It should be supported, but apparently there is some bug. I guess it's about > not properly reserving memory used by the armstub/ATF. Do you use the > embedded RPi foundation armstub or ATF (do you have an "armstub=..." line in > config.txt)? > > I will try take a look at this later. I'm not sure, i had similar issue about failed to allocate memory cma. I had enabled CONFIG_ARCH_FIXUP_OF_MEMORY. And i changed the loading address (kernel/ramdisk/device-tree) in boot script for our environment. Because sometime some address range is overwritten. Best Regards, Jaehoon Chung > >> I need to set a ramdisk and bootefi dont support that. > > Try "initrd=" on the kernel command line. > This is actually an EFI stub feature, the EFI command line is parsed by this > pre-kernel code, which filters for initrd= and loads the initrd using the > UEFI API (implemented by U-Boot). > So the initrd has to live on the EFI system partition, which means you can't > load it easily via TFTP :-( > More details here: > https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html#the-initrd-option > > Cheers, > Andre > >
[PATCH 2/2] MAINTAINERS: board: hisi: poplar: update email
Signed-off-by: Jorge Ramirez-Ortiz --- board/hisilicon/poplar/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/hisilicon/poplar/MAINTAINERS b/board/hisilicon/poplar/MAINTAINERS index 622e5cb18e..9c045eaeb1 100644 --- a/board/hisilicon/poplar/MAINTAINERS +++ b/board/hisilicon/poplar/MAINTAINERS @@ -1,5 +1,5 @@ Poplar BOARD -M: Jorge Ramirez-Ortiz +M: Jorge Ramirez-Ortiz M: Shawn Guo S: Maintained F: board/hisilicon/poplar -- 2.17.1
[PATCH 1/2] MAINTAINERS: board: qcom: db820c: update email
Signed-off-by: Jorge Ramirez-Ortiz --- board/qualcomm/dragonboard820c/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/qualcomm/dragonboard820c/MAINTAINERS b/board/qualcomm/dragonboard820c/MAINTAINERS index a157033bf0..7ef905bdf6 100644 --- a/board/qualcomm/dragonboard820c/MAINTAINERS +++ b/board/qualcomm/dragonboard820c/MAINTAINERS @@ -1,5 +1,5 @@ DRAGONBOARD820C BOARD -M: Jorge Ramirez-Ortiz +M: Jorge Ramirez-Ortiz S: Maintained F: board/qualcomm/dragonboard820c/ F: include/configs/dragonboard820c.h -- 2.17.1
[PATCH] configs: db820c: set bootm_size
set bootm_size to the memory available to safely contain a kernel, device tree and initrd for relocation. Signed-off-by: Jorge Ramirez-Ortiz --- include/configs/dragonboard820c.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/dragonboard820c.h b/include/configs/dragonboard820c.h index 4256e6f060..d7bfb7a100 100644 --- a/include/configs/dragonboard820c.h +++ b/include/configs/dragonboard820c.h @@ -48,6 +48,7 @@ "ramdisk_addr_r=0x9100\0"\ "scriptaddr=0x9000\0"\ "pxefile_addr_r=0x9010\0"\ + "bootm_size=0x800"\ BOOTENV /* Size of malloc() pool */ -- 2.17.1
[ANN] U-Boot v2020.04-rc1 released
Hey all, It's the day after release day, and here is v2020.04-rc1. There's a few more PRs I expect to see soon and a few more changes to bring in from my own queue. In terms of a changelog, git log --merges v2020.01..v2020.04-rc1 contains what I've pulled but as always, better PR messages and tags will provide better results here. I'm planning on doing the standard every other Monday -rc releases from here on out and with a release on April 6th. Thanks all! -- Tom signature.asc Description: PGP signature
DWC4 ethernet in U-Boot receiving it's own traffic
Hi, are you aware of any issues with the DWC4 ethernet in U-Boot? I recently ran into oddity where the MAC receives it's own packets upon replying to ARP request. Test case is as follows: - Assume host PC with IP 192.168.1.1/24 , STM32MP1 board with IP 192.168.1.2/24 - Assume TFTP server has 64MiB file called 64m full of zeroes ($ dd if=/dev/zero of=/tftpboot/64m bs=64M count=1) - Run the following in U-Boot: $ setenv ipaddr 192.168.1.2 $ setenv netmask 255.255.255.0 $ setenv serverip 192.168.1.1 $ tftp 192.168.1.1:64m - In parallel, during the TFTP transfer, run the following on PC: $ arping -c 1 192.168.1.2 Observe 5-second delay while the MAC is trying to recover or complete failure of the transfer. What happens is that the U-Boot is in netloop, receives the ARP request and sends ARP reply. So far so good. However, the DWC4 receives that ARP reply too for reason that is not clear yet (the packet which arrives in eqos_recv() has source MAC equal to the board MAC address). Note that this is modeling a real world scenario where the host PC sends ARP request to the board during a TFTP transfer. The same problem does happen then. Can you try replicating this and see whether this is happening for you too? -- Best regards, Marek Vasut
Re: [PATCH v2][ 3/3] board: tbs2910: Add support for generic distro configuration
On Tue, 28 Jan 2020 18:51:26 +0100 Soeren Moch wrote: > As already discussed, the bootm_size environment variable is not > necessary, otherwise somewhat dangerous with this value. Sorry, for the mistake, I've fixed it now. I'll send a v3 after some feedback from my response to your other points. Thanks a lot for the reviews. Denis. pgpzRl7nDLaIP.pgp Description: OpenPGP digital signature
Re: [PATCH] board: tbs2910: Add support for generic distro configuration
On Sun, 26 Jan 2020 01:40:13 +0100 Soeren Moch wrote: > >> Why do you define CONFIG_BOOTCOMMAND here instead of modifying the > >> existing one? > > I'm a bit confused with it: There seem to be many way to do the same > > thing and I'm not sure which one is the best. > > > > Because of that, I just kept it in the code as it was (instead of > > moving it to tbs2910_defconfig). > This is ok. What I mean: You moved it in the file, and therefore you > unnecessarily changed a lot of lines without actually changing most of > it's contents. If CONFIG_BOOTCOMMAND is not defined before, it will be defined in config_distro_bootcmd.h This means that the order in which defines and #include is done matters. Which lead me to do the inclusion of config_distro_bootcmd.h as early as possible in the tbs2910.h. This way if there are some unintended redefinition due to things having changed in config_distro_bootcmd.h in the future, the compiler will at warn or error about it. Denis. pgpEVVMpnVTij.pgp Description: OpenPGP digital signature
Re: [PATCH v2][ 3/3] board: tbs2910: Add support for generic distro configuration
On Tue, 28 Jan 2020 18:51:26 +0100 Soeren Moch wrote: > There are a lot of unrelated/unexplained changes in tbs2910_defconfig. > This probably should not be part of this patch. I changed only 2 things here: - I added CONFIG_DISTRO_DEFAULTS=y - I added CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb" I double checked that change before sending the patch. Here the big diff is due to savedefconfig minimizing the defconfig after enabling CONFIG_DISTRO_DEFAULTS=y. Denis. pgp5HmScDgSf_.pgp Description: OpenPGP digital signature
Re: [PATCH v2 21/21] imx: imxrt1050-evk: Add support for the NXP i.MXRT1050-EVK
On 1/28/20 10:02 AM, Lukasz Majewski wrote:
Hi Giulio,
This commit adds board support for i.MXRT1050-EVK from NXP. This board
is an evaluation kit provided by NXP for i.MXRT105x processor family.
More information about this board can be found here:
https://www.nxp.com/design/development-boards/i.mx-evaluation-and-development-boards/i.mx-rt1050-evaluation-kit:MIMXRT1050-EVK
The initial supported/tested devices include:
- Debug serial
- SD
Signed-off-by: Giulio Benetti
---
V1->V2:
* introduced CONFIG_IMXRT1050
* added imxrt1050-evk-u-boot.dtsi for imxrt1050-evk.dts
---
arch/arm/dts/Makefile | 2 +
arch/arm/dts/imxrt1050-evk-u-boot.dtsi| 44
arch/arm/dts/imxrt1050-evk.dts| 200
++ arch/arm/mach-imx/imxrt/Kconfig |
12 ++ board/freescale/imxrt1050-evk/Kconfig | 22 ++
board/freescale/imxrt1050-evk/MAINTAINERS | 6 +
board/freescale/imxrt1050-evk/Makefile| 6 +
board/freescale/imxrt1050-evk/README | 31 +++
board/freescale/imxrt1050-evk/imximage.cfg| 36
board/freescale/imxrt1050-evk/imxrt1050-evk.c | 81 +++
configs/imxrt1050-evk_defconfig | 69 ++
include/configs/imxrt1050-evk.h | 46
12 files changed, 555 insertions(+)
create mode 100644 arch/arm/dts/imxrt1050-evk-u-boot.dtsi
create mode 100644 arch/arm/dts/imxrt1050-evk.dts
create mode 100644 board/freescale/imxrt1050-evk/Kconfig
create mode 100644 board/freescale/imxrt1050-evk/MAINTAINERS
create mode 100644 board/freescale/imxrt1050-evk/Makefile
create mode 100644 board/freescale/imxrt1050-evk/README
create mode 100644 board/freescale/imxrt1050-evk/imximage.cfg
create mode 100644 board/freescale/imxrt1050-evk/imxrt1050-evk.c
create mode 100644 configs/imxrt1050-evk_defconfig
create mode 100644 include/configs/imxrt1050-evk.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 983e235f44..0864460751 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -707,6 +707,8 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-evk.dtb \
imx8mp-evk.dtb
+dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb
+
dtb-$(CONFIG_RCAR_GEN2) += \
r8a7790-lager-u-boot.dtb \
r8a7790-stout-u-boot.dtb \
diff --git a/arch/arm/dts/imxrt1050-evk-u-boot.dtsi
b/arch/arm/dts/imxrt1050-evk-u-boot.dtsi new file mode 100644
index 00..fb4f7f6f9d
--- /dev/null
+++ b/arch/arm/dts/imxrt1050-evk-u-boot.dtsi
Ach... Ok, so you have already used the U-Boot specific dtsi.
Yep, did it just before sending :-)
Best regards
--
Giulio Benetti
Benetti Engineering sas
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2019
+ * Author(s): Giulio Benetti
+ */
+
+/ {
+ chosen {
+ u-boot,dm-spl;
+ };
+};
+
+ { /* console */
+ u-boot,dm-spl;
+};
+
+ {
+ bank1: bank@0 {
+ u-boot,dm-spl;
+ };
+};
+
+ {
+ u-boot,dm-spl;
+
+ imxrt1050-evk {
+ u-boot,dm-spl;
+ pinctrl_lpuart1: lpuart1grp {
+ u-boot,dm-spl;
+ };
+
+ pinctrl_semc: semcgrp {
+ u-boot,dm-spl;
+ };
+
+ pinctrl_usdhc0: usdhc0grp {
+ u-boot,dm-spl;
+ };
+ };
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imxrt1050-evk.dts
b/arch/arm/dts/imxrt1050-evk.dts new file mode 100644
index 00..56b75986e2
--- /dev/null
+++ b/arch/arm/dts/imxrt1050-evk.dts
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2019
+ * Author(s): Giulio Benetti
+ */
+
+/dts-v1/;
+#include "imxrt1050.dtsi"
+#include "imxrt1050-evk-u-boot.dtsi"
+#include
+
+/ {
+ model = "NXP IMXRT1050-evk board";
+ compatible = "fsl,imxrt1050-evk", "fsl,imxrt1050";
+
+ chosen {
+ bootargs = "root=/dev/ram";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x8000 0x200>;
+ };
+};
+
+ { /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart1>;
+ status = "okay";
+};
+
+ {
+ /*
+* Memory configuration from sdram datasheet IS42S16160J-6BLI
+*/
+ fsl,sdram-mux = /bits/ 8 ;
+ fsl,sdram-control = /bits/ 8 ;
+ fsl,sdram-timing = /bits/ 8 <0x2
+0x2
+0x9
+0x1
+0x5
+0x6
+
+0x20
+0x09
+0x01
+0x00
+
+0x04
+0x0A
+
Re: [PATCH v2 15/21] serial_lpuart: add clock enable if CONFIG_CLK is defined
Hi Lukasz,
On 1/28/20 9:36 AM, Lukasz Majewski wrote:
Hi Giulio,
This driver assumes that lpuart clock is already enabled before
probing but using DM only lpuart won't be automatically enabled so add
clk_enable() when probing if CONFIG_CLK is defined. If clock is not
found, because DM is not used, let's emit a warning and proceed,
because serial clock could also be already enabled by non DM code. If
clock is found but cna't be enabled then return with error.
- can't
It's too late now, but...
Signed-off-by: Giulio Benetti
---
V1->V2:
* moved error as warning if clk not found
---
drivers/serial/serial_lpuart.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/serial/serial_lpuart.c
b/drivers/serial/serial_lpuart.c index 4b0a964d1b..b2ec56172e 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -483,6 +483,22 @@ static int lpuart_serial_pending(struct udevice
*dev, bool input)
static int lpuart_serial_probe(struct udevice *dev)
{
+#if CONFIG_IS_ENABLED(CLK)
+ struct clk per_clk;
+ int ret;
+
+ ret = clk_get_by_name(dev, "per", _clk);
+ if (!ret) {
+ ret = clk_enable(_clk);
+ if (ret) {
+ dev_err(dev, "Failed to get per clk: %d\n",
ret);
+ return ret;
+ }
+ } else {
+ dev_warn(dev, "Failed to get per clk: %d\n", ret);
^^ - please change to debug() as some devices may
enable CONFIG_CLK, but did not yet support (have
implemented) this clock in CCF.
...not for this, I'm going to send a patch changing this string.
Best regards
--
Giulio Benetti
Benetti Engineering sas
+ }
+#endif
+
if (is_lpuart32(dev))
return _lpuart32_serial_init(dev);
else
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
Re: [PATCH v2 14/21] ARM: dts: imxrt1050: add dtsi file
On 1/28/20 9:31 AM, Lukasz Majewski wrote:
Hi Giulio,
Add dtsi file for i.MXRT1050.
Please add information from where this code was ported (as I've pointed
out in other mails).
This is not ported, this is the original one. :-)
Also a tip:
To avoid extra dtsi maintenance burden, there are u-boot*.dtsi files
(in e.g. arch/arm/dts/) which add extra properties (U-boot specific).
In that way "original" dtsi (from e.g. Linux) are kept separated from
U-Boot adjustments).
Yes, next patch has -uboot.dtsi that includes this.
Best regards
--
Giulio Benetti
Benetti Engineering sas
Signed-off-by: Giulio Benetti
---
arch/arm/dts/imxrt1050.dtsi | 146 +++
include/dt-bindings/pinctrl/pins-imxrt1050.h | 993
+++ 2 files changed, 1139 insertions(+)
create mode 100644 arch/arm/dts/imxrt1050.dtsi
create mode 100644 include/dt-bindings/pinctrl/pins-imxrt1050.h
diff --git a/arch/arm/dts/imxrt1050.dtsi b/arch/arm/dts/imxrt1050.dtsi
new file mode 100644
index 00..b1d98e6feb
--- /dev/null
+++ b/arch/arm/dts/imxrt1050.dtsi
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2019
+ * Author(s): Giulio Benetti
+ */
+
+#include "skeleton.dtsi"
+#include "armv7-m.dtsi"
+#include
+#include
+#include
+#include
+
+/ {
+ aliases {
+ gpio0 =
+ gpio1 =
+ gpio2 =
+ gpio3 =
+ gpio4 =
+ mmc0 =
+ serial0 =
+ };
+
+ clocks {
+ u-boot,dm-spl;
+
+ osc {
+ u-boot,dm-spl;
+ compatible = "fsl,imx-osc", "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ };
+ };
+
+ soc {
+ u-boot,dm-spl;
+
+ semc: semc@402f {
+ u-boot,dm-spl;
+ compatible = "fsl,imxrt-semc";
+ reg = <0x402f 0x4000>;
+ clocks = < IMXRT1050_CLK_SEMC>;
+ pinctrl-0 = <_semc>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ lpuart1: serial@40184000 {
+ compatible = "fsl,imxrt-lpuart";
+ reg = <0x40184000 0x4000>;
+ interrupts = ;
+ clocks = < IMXRT1050_CLK_LPUART1>;
+ clock-names = "per";
+ status = "disabled";
+ };
+
+ iomuxc: iomuxc@401f8000 {
+ compatible = "fsl,imxrt-iomuxc";
+ reg = <0x401f8000 0x4000>;
+ fsl,mux_mask = <0x7>;
+ };
+
+ clks: ccm@400fc000 {
+ u-boot,dm-spl;
+ compatible = "fsl,imxrt1050-ccm";
+ reg = <0x400fc000 0x4000>;
+ interrupts = ,
+;
+ #clock-cells = <1>;
+ };
+
+ usdhc1: usdhc@402c {
+ u-boot,dm-spl;
+ compatible = "fsl,imxrt-usdhc";
+ reg = <0x402c 0x1>;
+ interrupts = ;
+ clocks = < IMXRT1050_CLK_USDHC1>;
+ clock-names = "per";
+ bus-width = <4>;
+ fsl,tuning-start-tap = <20>;
+ fsl,tuning-step= <2>;
+ status = "disabled";
+ };
+
+ gpio1: gpio@401b8000 {
+ u-boot,dm-spl;
+ compatible = "fsl,imxrt-gpio",
"fsl,imx35-gpio";
+ reg = <0x401b8000 0x4000>;
+ interrupts = ,
+;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio2: gpio@401bc000 {
+ u-boot,dm-spl;
+ compatible = "fsl,imxrt-gpio",
"fsl,imx35-gpio";
+ reg = <0x401bc000 0x4000>;
+ interrupts = ,
+ ;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio3: gpio@401c {
+ u-boot,dm-spl;
+ compatible = "fsl,imxrt-gpio",
"fsl,imx35-gpio";
+ reg = <0x401c 0x4000>;
+ interrupts = ,
+ ;
+ gpio-controller;
+
Re: [PATCH v2 05/21] clk: imx: pllv3: add enable() support
On 1/28/20 9:14 AM, Lukasz Majewski wrote:
Hi Giulio,
Before set_rate() pllv3 needs enable() to power the pll up.
Add enable() taking into account different power_bit and
different powerup_set, because some pll needs its power_bit to be
set or reset to be powered on.
I do guess that this code is similar to what we do have in the Linux
kernel (and which I've probably omitted as it was not needed in the
i.MX6Q use case)?
Exactly, in i.MXRT case need a different enabling sequence and this can
be useful for other i.MX families.
Best regards
--
Giulio Benetti
Benetti Engineering sas
Signed-off-by: Giulio Benetti
---
drivers/clk/imx/clk-pllv3.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 02c75c37ea..d8cbe3dd4e 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -16,9 +16,13 @@
#define UBOOT_DM_CLK_IMX_PLLV3_GENERIC"imx_clk_pllv3_generic"
#define UBOOT_DM_CLK_IMX_PLLV3_USB"imx_clk_pllv3_usb"
+#define BM_PLL_POWER (0x1 << 12)
+
struct clk_pllv3 {
struct clk clk;
void __iomem*base;
+ u32 power_bit;
+ boolpowerup_set;
u32 div_mask;
u32 div_shift;
};
@@ -35,8 +39,24 @@ static ulong clk_pllv3_generic_get_rate(struct clk
*clk) return (div == 1) ? parent_rate * 22 : parent_rate * 20;
}
+static int clk_pllv3_generic_enable(struct clk *clk)
+{
+ struct clk_pllv3 *pll = to_clk_pllv3(clk);
+ u32 val;
+
+ val = readl(pll->base);
+ if (pll->powerup_set)
+ val |= pll->power_bit;
+ else
+ val &= ~pll->power_bit;
+ writel(val, pll->base);
+
+ return 0;
+}
+
static const struct clk_ops clk_pllv3_generic_ops = {
.get_rate = clk_pllv3_generic_get_rate,
+ .enable = clk_pllv3_generic_enable,
};
struct clk *imx_clk_pllv3(enum imx_pllv3_type type, const char *name,
@@ -52,14 +72,18 @@ struct clk *imx_clk_pllv3(enum imx_pllv3_type
type, const char *name, if (!pll)
return ERR_PTR(-ENOMEM);
+ pll->power_bit = BM_PLL_POWER;
+
switch (type) {
case IMX_PLLV3_GENERIC:
drv_name = UBOOT_DM_CLK_IMX_PLLV3_GENERIC;
pll->div_shift = 0;
+ pll->powerup_set = false;
break;
case IMX_PLLV3_USB:
drv_name = UBOOT_DM_CLK_IMX_PLLV3_USB;
pll->div_shift = 1;
+ pll->powerup_set = true;
break;
default:
kfree(pll);
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
[U-Boot Patch v2 4/4] bdinfo: fu540: print fdt base address for debugging
Add fdt->gd info to bdinfo so that it is useful for debugging
and easily use it with fdt util.
Signed-off-by: Sagar Shrikant Kadam
---
cmd/bdinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index d6a7175..96892b3 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -433,6 +433,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
print_bi_dram(bd);
print_num("relocaddr", gd->relocaddr);
print_num("reloc off", gd->reloc_off);
+ print_num("fdt_blob", (ulong)gd->fdt_blob);
print_eth_ip_addr();
print_baudrate();
--
2.7.4
[U-Boot Patch v2 3/4] dts: u-boot.dtsi: override flash tx-rx width
The hifive-unleashed-a00.dts has flash spi-tx/rx width set
to 4-bit mode. During sf probe, spi_nor_scan fails to read the
JEDEC ID with reg_proto set to SNOR_PROTO_1_1_1. Setting it to
1-bit mode as of now will help read the JEDEC-ID and perform other
flash operations.
Signed-off-by: Sagar Shrikant Kadam
---
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
index d7a6413..dae9f87 100644
--- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -9,3 +9,11 @@
spi2 =
};
};
+
+ {
+ flash@0 {
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+};
+
--
2.7.4
[U-Boot Patch v2 1/4] fu540: dtsi: spi: add num-cs info to device tree
Add the number of chip select information to spi nodes which
can be used by spi-uclass for error handling if invalid cs
number passed from command.
Signed-off-by: Sagar Shrikant Kadam
---
arch/riscv/dts/fu540-c000.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/dts/fu540-c000.dtsi b/arch/riscv/dts/fu540-c000.dtsi
index afa43c7..9c6ab21 100644
--- a/arch/riscv/dts/fu540-c000.dtsi
+++ b/arch/riscv/dts/fu540-c000.dtsi
@@ -191,6 +191,7 @@
clocks = < PRCI_CLK_TLCLK>;
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = <1>;
status = "disabled";
};
qspi1: spi@10041000 {
@@ -202,6 +203,7 @@
clocks = < PRCI_CLK_TLCLK>;
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = <1>;
status = "disabled";
};
qspi2: spi@1005 {
@@ -212,6 +214,7 @@
clocks = < PRCI_CLK_TLCLK>;
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = <1>;
status = "disabled";
};
eth0: ethernet@1009 {
--
2.7.4
[U-Boot Patch v2 0/4] Fix currently available support for flash on HiFive Unleashed
Currently device ID for flash mounted on HiFive Unleashed is added to
U-Boot. Also there are few patches about to go in mainline (Thanks to
Jagan Tekki and Bin Meng).
This series addresses few issues discussed there:
Patch 1:Add num-cs to device tree which is used by spi-uclass to detect
valid chip select numbers
Patch 2:Handles valid chip selects only. Flash device is now detected only
on chip select 0.
Patch 3:Over-ride spi tx/rx width specified in hifive-unleshed-a00.dts file
from 4 to 1 in corresponding -u-boot.dtsi
This series is based on mainline commit c05b38df477a ("common: fix
regression on block cache init") and two below mentioned patches from [1]
[U-Boot,v2,4/5] riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi
[U-Boot,v2,5/5] sifive: fu540: Enable spi-nor flash support
[1] https://patchwork.ozlabs.org/patch/1177979/
The above series is available for testing here[2]
[2] https://github.com/sagsifive/u-boot/tree/dev/sagark/test_spi-nor_v2
Change History:
V1-V2:
1. Dropped 6th and 7th patch sent in V1 from this series so as to separate
out spi-nor related changes in different series and avoid adding TODO
fixes to spi-nor-core framework.
2. Removed patch to include -uboot.dts, as it gets automatically included.
3. Over-ride tx/rx width from hifive-unleashed-a00.dts using hifive
-unleashed-a00-u-boot.dtsi
4. Print fdt base address in board info for debugging.
V1: First version of series
Log for reference=
Flash detection only at valid Chip select
=> sf probe 0:0
SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
=> sf probe 0:1
Invalid cs number = 1
Failed to initialize SPI flash at 0:1 (error -22)
=> sf probe 0:2
Invalid cs number = 2
Failed to initialize SPI flash at 0:2 (error -22)
=> sf probe 0:0
SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
=>
Full flash memory erase/write/read/validate
=> mw 0x8060 0x12348765 0x80
=> sf erase 0x0 0x200
SF: 33554432 bytes @ 0x0 Erased: OK
=> sf write 0x8060 0x0 0x200
device 0 whole chip
SF: 33554432 bytes @ 0x0 Written: OK
=> sf read 0x8260 0x0 0x200
device 0 whole chip
SF: 33554432 bytes @ 0x0 Read: OK
=> cmp.b 0x8060 0x8260 0x200
Total of 33554432 byte(s) were the same
=>
Sagar Shrikant Kadam (4):
fu540: dtsi: spi: add num-cs info to device tree
spi: fu540: add claim and release method to spi-sifive.c
dts: u-boot.dtsi: override flash tx-rx width
bdinfo: fu540: print fdt base address for debugging
arch/riscv/dts/fu540-c000.dtsi | 3 +++
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 8 ++
cmd/bdinfo.c| 1 +
drivers/spi/spi-sifive.c| 36 +
4 files changed, 48 insertions(+)
--
2.7.4
[U-Boot Patch v2 2/4] spi: fu540: add claim and release method to spi-sifive.c
Add missing bus claim/release method to spi driver for HiFive
Unleashed, and handle num_cs generously so that it generates
an error if invalid cs number is passed to sf probe.
Signed-off-by: Sagar Shrikant Kadam
---
drivers/spi/spi-sifive.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/spi/spi-sifive.c b/drivers/spi/spi-sifive.c
index 969bd4b..f990ad6 100644
--- a/drivers/spi/spi-sifive.c
+++ b/drivers/spi/spi-sifive.c
@@ -186,6 +186,36 @@ static void sifive_spi_tx(struct sifive_spi *spi, const u8
*tx_ptr)
writel(tx_data, spi->regs + SIFIVE_SPI_REG_TXDATA);
}
+static int sifive_spi_claim_bus(struct udevice *dev)
+{
+ int ret;
+ struct udevice *bus = dev->parent;
+ struct sifive_spi *spi = dev_get_priv(bus);
+ struct dm_spi_slave_platdata *slave = dev_get_parent_platdata(dev);
+
+ if (!(slave->cs < spi->num_cs)) {
+ printf("Invalid cs number = %d\n", slave->cs);
+ return -EINVAL;
+ }
+
+ sifive_spi_prep_device(spi, slave);
+
+ ret = sifive_spi_set_cs(spi, slave);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int sifive_spi_release_bus(struct udevice *dev)
+{
+ struct sifive_spi *spi = dev_get_priv(dev->parent);
+
+ sifive_spi_clear_cs(spi);
+
+ return 0;
+}
+
static int sifive_spi_xfer(struct udevice *dev, unsigned int bitlen,
const void *dout, void *din, unsigned long flags)
{
@@ -345,6 +375,10 @@ static int sifive_spi_probe(struct udevice *bus)
/* init the sifive spi hw */
sifive_spi_init_hw(spi);
+ /* Fetch number of chip selects from DT if present */
+ ret = dev_read_u32_default(bus, "num-cs", spi->num_cs);
+ spi->num_cs = ret;
+
return 0;
}
@@ -353,6 +387,8 @@ static const struct dm_spi_ops sifive_spi_ops = {
.set_speed = sifive_spi_set_speed,
.set_mode = sifive_spi_set_mode,
.cs_info= sifive_spi_cs_info,
+ .claim_bus = sifive_spi_claim_bus,
+ .release_bus= sifive_spi_release_bus,
};
static const struct udevice_id sifive_spi_ids[] = {
--
2.7.4
Re: [PATCH v2][ 3/3] board: tbs2910: Add support for generic distro configuration
On 28.01.20 18:04, Denis 'GNUtoo' Carikli wrote: > This keeps the compatibility with the old bootcmd. > > The fdtfile environment variable also needed to be set to > imx6q-tbs2910.dtb to enable booting mainline kernels > otherwise with extlinux.conf it tries to load > mx6-tbs2910.dtb instead. > > Signed-off-by: Denis 'GNUtoo' Carikli There are a lot of unrelated/unexplained changes in tbs2910_defconfig. This probably should not be part of this patch. As already discussed, the bootm_size environment variable is not necessary, otherwise somewhat dangerous with this value. The requested changes for CONFIG_BOOTCOMMAND are not addressed in this v2. Soeren > --- > configs/tbs2910_defconfig | 17 - > include/configs/tbs2910.h | 37 - > 2 files changed, 32 insertions(+), 22 deletions(-) > > diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig > index 0e91eeffd4..0d9e11bd20 100644 > --- a/configs/tbs2910_defconfig > +++ b/configs/tbs2910_defconfig > @@ -9,16 +9,16 @@ CONFIG_NR_DRAM_BANKS=1 > CONFIG_PRE_CON_BUF_ADDR=0x7c00 > CONFIG_CMD_HDMIDETECT=y > CONFIG_AHCI=y > +CONFIG_DISTRO_DEFAULTS=y > CONFIG_BOOTDELAY=3 > +# CONFIG_USE_BOOTCOMMAND is not set > CONFIG_USE_PREBOOT=y > CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start; if hdmidet; then run > set_con_hdmi; else run set_con_serial; fi" > CONFIG_PRE_CONSOLE_BUFFER=y > -CONFIG_SUPPORT_RAW_INITRD=y > +CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb" > CONFIG_BOUNCE_BUFFER=y > CONFIG_BOARD_EARLY_INIT_F=y > -CONFIG_HUSH_PARSER=y > CONFIG_SYS_PROMPT="Matrix U-Boot> " > -CONFIG_CMD_BOOTZ=y > # CONFIG_BOOTM_PLAN9 is not set > # CONFIG_BOOTM_RTEMS is not set > # CONFIG_BOOTM_VXWORKS is not set > @@ -30,22 +30,14 @@ CONFIG_CMD_I2C=y > # CONFIG_CMD_LOADB is not set > # CONFIG_CMD_LOADS is not set > CONFIG_CMD_MMC=y > -CONFIG_CMD_PART=y > CONFIG_CMD_PCI=y > CONFIG_CMD_SATA=y > CONFIG_CMD_USB=y > CONFIG_CMD_USB_MASS_STORAGE=y > -CONFIG_CMD_DHCP=y > -CONFIG_CMD_MII=y > -CONFIG_CMD_PING=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > -CONFIG_CMD_EXT2=y > -CONFIG_CMD_EXT4=y > CONFIG_CMD_EXT4_WRITE=y > -CONFIG_CMD_FAT=y > -CONFIG_CMD_FS_GENERIC=y > -CONFIG_EFI_PARTITION=y > +# CONFIG_ISO_PARTITION is not set > CONFIG_OF_CONTROL=y > CONFIG_OF_EMBED=y > CONFIG_DEFAULT_DEVICE_TREE="imx6q-tbs2910" > @@ -75,7 +67,6 @@ CONFIG_RTC_DS1307=y > CONFIG_DM_THERMAL=y > CONFIG_USB=y > CONFIG_DM_USB=y > -CONFIG_USB_STORAGE=y > CONFIG_USB_KEYBOARD=y > CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > CONFIG_USB_GADGET=y > diff --git a/include/configs/tbs2910.h b/include/configs/tbs2910.h > index b598fca1ec..abeca16555 100644 > --- a/include/configs/tbs2910.h > +++ b/include/configs/tbs2910.h > @@ -8,6 +8,24 @@ > #ifndef __TBS2910_CONFIG_H > #define __TBS2910_CONFIG_H > > +#define CONFIG_BOOTCOMMAND \ > + "mmc rescan; " \ > + "if run bootcmd_up1; then " \ > + "run bootcmd_up2; " \ > + "else " \ > + "run bootcmd_mmc || run distro_bootcmd; " \ > + "fi" > + > +#define BOOT_TARGET_DEVICES(func) \ > + func(MMC, mmc, 0) \ > + func(MMC, mmc, 1) \ > + func(MMC, mmc, 2) \ > + func(SATA, sata, 0) \ > + func(USB, usb, 0) \ > + func(PXE, pxe, na) \ > + func(DHCP, dhcp, na) > +#include > + > #include "mx6_common.h" > > /* General configuration */ > @@ -80,6 +98,13 @@ > #define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - > 1024) */ > > #define CONFIG_EXTRA_ENV_SETTINGS \ > + "bootm_size=0x8000\0" \ > + "fdt_addr=0x1300\0" \ > + "fdt_addr_r=0x1300\0" \ > + "kernel_addr_r=0x10008000\0" \ > + "pxefile_addr_r=0x10008000\0" \ > + "ramdisk_addr_r=0x1800\0" \ > + "scriptaddr=0x1400\0" \ > "bootargs_mmc1=console=ttymxc0,115200 di0_primary console=tty1\0" \ > "bootargs_mmc2=video=mxcfb0:dev=hdmi,1920x1080M@60 " \ > "video=mxcfb1:off video=mxcfb2:off fbmem=28M\0" \ > @@ -102,14 +127,8 @@ > "setenv stderr serial,vga\0" \ > "stderr=serial,vga\0" \ > "stdin=serial,usbkbd\0" \ > - "stdout=serial,vga\0" > - > -#define CONFIG_BOOTCOMMAND \ > - "mmc rescan; " \ > - "if run bootcmd_up1; then " \ > - "run bootcmd_up2; " \ > - "else " \ > - "run bootcmd_mmc; " \ > - "fi" > + "stdout=serial,vga\0" \ > + "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ > + BOOTENV > > #endif /* __TBS2910_CONFIG_H * */
Re: [PATCH v2][ 2/3] tbs2910: disable loadb and loads commands
On 28.01.20 18:04, Denis 'GNUtoo' Carikli wrote: > The loadb and loads commands are not needed for booting. > > There are also more reliable and faster alternatives to > loadb and loads that can be used with the current configuration. > > As that the resulting u-boot.imx image is already very close > to the size limit, removing the loadb and loads commands > shouldn't hurt. > > With arm-linux-gnueabi-gcc 9.2.0-1 from the Parabola > GNU/Linux distribution, it shrinks the image from 388096 to > 384000 bytes. > > Signed-off-by: Denis 'GNUtoo' Carikli I don't know any use case of these commands on tbs2910, so Acked-by: Soeren Moch
Re: [PATCH v2][ 1/3] tbs2910: disable fuse command
On 28.01.20 18:04, Denis 'GNUtoo' Carikli wrote: > The fuse command is not needed for booting or during usual > users interactions with u-boot. > > As that the resulting u-boot.imx image is already very > close to the size limit, removing the fuse command shouldn't > hurt. > > With arm-linux-gnueabi-gcc 9.2.0-1 from the Parabola > GNU/Linux distribution, it shrinks the image from 392192 to > 388096 bytes. > > Signed-off-by: Denis 'GNUtoo' Carikli The fuse command is useful for tbs2910, especially for 1.x board revisions. So NAK. Soeren
Re: [PATCH] dtc: add ability to make nodes conditional on them being referenced
On Tue, 28 Jan 2020 10:07:18 -0700 Simon Glass wrote: Hi Simon, > On Sat, 25 Jan 2020 at 16:18, André Przywara wrote: > > > > On 25/01/2020 16:20, Tom Rini wrote: > > > > Hi Tom, > > > > thanks for having a look! > > > > > > > On Tue, Jan 21, 2020 at 10:23:17AM +, Andre Przywara wrote: > > > > > >> From: Maxime Ripard > > >> > > >> This is needed when importing mainline DTs into U-Boot, as some started > > >> using this /omit-if-no-ref/ tag, so won't compile with U-Boot's current > > >> dtc copy. This is just a cherry-pick of the patch introducing this > > >> feature. > > >> Original commit message from Maxime: > > >> -- > > >> A number of platforms have a need to reduce the number of DT nodes, > > >> mostly because of two similar constraints: the size of the DT blob, and > > >> the time it takes to parse it. > > >> > > >> As the DT is used in more and more SoCs, and by more projects, some > > >> constraints start to appear in bootloaders running from SRAM with an > > >> order of magnitude of 10kB. A typical DT is in the same order of > > >> magnitude, so any effort to reduce the blob size is welcome in such an > > >> environment. > > >> > > >> Some platforms also want to reach very fast boot time, and the time it > > >> takes to parse a typical DT starts to be noticeable. > > >> > > >> Both of these issues can be mitigated by reducing the number of nodes in > > >> the DT. The biggest provider of nodes is usually the pin controller and > > >> its subnodes, usually one for each valid pin configuration in a given > > >> SoC. > > >> > > >> Obviously, a single, fixed, set of these nodes will be used by a given > > >> board, so we can introduce a node property that will tell the DT > > >> compiler to drop the nodes when they are not referenced in the tree, and > > >> as such wouldn't be useful in the targetted system. > > >> > > >> Signed-off-by: Maxime Ripard > > >> Reviewed-by: Rob Herring > > >> Signed-off-by: Andre Przywara > > >> --- > > >> scripts/dtc/checks.c | 13 + > > >> scripts/dtc/dtc-lexer.l | 7 +++ > > >> scripts/dtc/dtc-parser.y | 17 + > > >> scripts/dtc/dtc.h| 4 > > >> scripts/dtc/livetree.c | 14 ++ > > >> 5 files changed, 55 insertions(+) > > Reviewed-by: Simon Glass Thanks! > > Is this for SPL or U-Boot proper? I don't think either of those was the original target here, as this showed up in the Linux tree first. If you need an answer to your question: it would actually be U-Boot proper, as it originates from Maxime's work on some Allwinner A20 devices - and we don't use DT in the SPL on sunxi. > I assume the former since you talk about SRAM. I think the idea was to provide a generic solution for some specific problem. The observation was that the .dtb is growing with all those pinmux nodes, also reportedly boot time increased because of the parsing efforts. So short of hacking/trimming the DT manually, this tag was introduced, to address the issue in a generic way. > But changing dtc won't affect SPL at present, since the DT > is not separately compiled for SPL. Of course if nodes are not needed > for U-Boot proper, removing them is good and may have SPL too. But we > use dtoc to drop unwanted nodes (as you probably know), and U-Boot has > its own tags for indicating what nodes should be present (since > everything is omitted from SPL by default). Understood. As mentioned, sunxi doesn't even use the DT at all in the SPL. The reason I posted this patch is simply that some mainline Linux .dts files carry this tag now, and without U-Boot's dtc understanding it, those DTs fail to build. So for the sake of copying .dts files verbatim from the kernel tree, we need dtc support for this tag. Cheers, Andre.
Re: [PATCH] board: tbs2910: Add support for generic distro configuration
On 28.01.20 18:02, Denis 'GNUtoo' Carikli wrote: > On Sun, 26 Jan 2020 01:40:13 +0100 > Soeren Moch wrote: >>> Ahh ok, now I understand. That probably explains the repeated size >>> issues. >> Why? With SPL+u-boot proper it would be even worse, since then there >> is a gap between SPL and u-boot, u-boot starts at higher address in >> eMMC, and it would not be smaller. And this 2-stage boot would break >> the documented u-boot update procedure, since we have to flash 2 >> files then. > I assumed that in some conditions, the bootrom could load only the SPL > in sram. Once loaded, the SPL would initialize the RAM, detect the boot > media, and fetch u-boot.img from it, and execute it. It is different here. i.MX6Q boot rom loads a imx file. This initializes the DDR controller first, then loads the executable payload, u-boot.bin in this case. So there is no restriction from SRAM size, as long as the DDR settings are fixed, what is the case for tbs2910. > > I also hoped the the SPL would have been significantly smaller than the > current u-boot.imx image. It would be. But then you need the u-boot.bin in addition to the SPL.imx , with all the problems explained earlier. > > In the meantime, I'll send a v2 with some additional patches to reduce > the size of the resulting u-boot.imx. As already explained, this is not necessary now. Soeren > > Denis.
Re: [PATCH v2][ 1/3] tbs2910: disable fuse command
Sorry, sent with wrong sender address. Please only use this address here. Soeren On 28.01.20 18:13, Soeren Moch wrote: > On 28.01.20 18:07, Fabio Estevam wrote: >> On Tue, Jan 28, 2020 at 2:04 PM Denis 'GNUtoo' Carikli >> wrote: >>> The fuse command is not needed for booting or during usual >>> users interactions with u-boot. >>> >>> As that the resulting u-boot.imx image is already very >>> close to the size limit, removing the fuse command shouldn't >>> hurt. >>> >>> With arm-linux-gnueabi-gcc 9.2.0-1 from the Parabola >>> GNU/Linux distribution, it shrinks the image from 392192 to >>> 388096 bytes. >> I think it would be more readable if you put the delta value instead >> of initial versus final. > Which is 4k, surprise, surprise, the alignment of imx files. Actually > you only shrink the binary by a few bytes, which is not worth the pain > it you need fuses. > > Tom today merged a patch with much bigger size reduction (mentioned > earlier), so this should not be required. > > Soeren
Re: U-Boot PCI driver for mx6sxsabresd
On 1/28/20 6:11 PM, Pedro Jardim wrote:
> Hi Marek,
Hi,
> I saw your commit c5773ccdca8a ("pci: imx: Add iMX6SX compatible") and
> I've been trying to convert the PCI driver to DM_PCI on a mx6sxsabresd board.
>
> I did the following changes:
>
> --git a/arch/arm/dts/imx6sx-sdb.dtsi b/arch/arm/dts/imx6sx-sdb.dtsi
> index da815527a7..f5b0e9ee3f 100644
> --- a/arch/arm/dts/imx6sx-sdb.dtsi
> +++ b/arch/arm/dts/imx6sx-sdb.dtsi
> @@ -78,6 +78,17 @@
> enable-active-high;
> };
>
> + reg_pcie_gpio: regulator-pcie-gpio {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pcie_reg>;
> + regulator-name = "MPCIE_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 1 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> reg_usb_otg2_vbus: regulator@2 {
> compatible = "regulator-fixed";
> reg = <2>;
> @@ -154,6 +165,14 @@
> status = "okay";
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pcie>;
> + reset-gpio = < 0 GPIO_ACTIVE_LOW>;
> + vpcie-supply = <®_pcie_gpio>;
^
Is this even a valid DT ?
[...]
> diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig
> index 5150e3a837..6ce7e01b5f 100644
> --- a/configs/mx6sxsabresd_defconfig
> +++ b/configs/mx6sxsabresd_defconfig
> @@ -68,3 +68,4 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_HOST_ETHER=y
> CONFIG_USB_ETHER_ASIX=y
> CONFIG_VIDEO=y
> +CONFIG_DM_PCI=y
You might need DM regulator somewhere. Take a look at what VINING 2000
does there, the PCI worked on that one.
> diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
> index 55aace1c6e..52aaa82fbc 100644
> --- a/include/configs/mx6sxsabresd.h
> +++ b/include/configs/mx6sxsabresd.h
> @@ -166,12 +166,10 @@
> #define CONFIG_USB_MAX_CONTROLLER_COUNT 2
> #endif
>
> -#ifdef CONFIG_CMD_PCI
> #define CONFIG_PCI_SCAN_SHOW
> #define CONFIG_PCIE_IMX
> #define CONFIG_PCIE_IMX_PERST_GPIO IMX_GPIO_NR(2, 0)
> #define CONFIG_PCIE_IMX_POWER_GPIO IMX_GPIO_NR(2, 1)
> -#endif
>
> #define CONFIG_IMX_THERMAL
>
> Which obtained the following output:
>
> => pci enum
> => pci 0
> No such bus
> => pci 1
> No such bus
>
> Before the DM conversion. Do you have any suggestions as to why the
> PCI device is not detected after the DM_PCI conversion? Are you able
> to get i.MX6SX to detect PCI devices when using DM_PCI?
Yep, see above.
--
Best regards,
Marek Vasut
U-Boot PCI driver for mx6sxsabresd
Hi Marek,
I saw your commit c5773ccdca8a ("pci: imx: Add iMX6SX compatible") and
I've been trying to convert the PCI driver to DM_PCI on a mx6sxsabresd board.
I did the following changes:
--git a/arch/arm/dts/imx6sx-sdb.dtsi b/arch/arm/dts/imx6sx-sdb.dtsi
index da815527a7..f5b0e9ee3f 100644
--- a/arch/arm/dts/imx6sx-sdb.dtsi
+++ b/arch/arm/dts/imx6sx-sdb.dtsi
@@ -78,6 +78,17 @@
enable-active-high;
};
+ reg_pcie_gpio: regulator-pcie-gpio {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pcie_reg>;
+ regulator-name = "MPCIE_3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
reg_usb_otg2_vbus: regulator@2 {
compatible = "regulator-fixed";
reg = <2>;
@@ -154,6 +165,14 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pcie>;
+ reset-gpio = < 0 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_pcie_gpio>;
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_enet1>;
@@ -453,6 +472,18 @@
>;
};
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX6SX_PAD_ENET1_COL__GPIO2_IO_0 0x10b0
+ >;
+ };
+
+ pinctrl_pcie_reg: pciereggrp {
+ fsl,pins = <
+ MX6SX_PAD_ENET1_CRS__GPIO2_IO_1 0x10b0
+ >;
+ };
+
pinctrl_peri_3v3: peri3v3grp {
fsl,pins = <
MX6SX_PAD_QSPI1A_DATA0__GPIO4_IO_16
0x8000
diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig
index 5150e3a837..6ce7e01b5f 100644
--- a/configs/mx6sxsabresd_defconfig
+++ b/configs/mx6sxsabresd_defconfig
@@ -68,3 +68,4 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
CONFIG_VIDEO=y
+CONFIG_DM_PCI=y
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index 55aace1c6e..52aaa82fbc 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -166,12 +166,10 @@
#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
#endif
-#ifdef CONFIG_CMD_PCI
#define CONFIG_PCI_SCAN_SHOW
#define CONFIG_PCIE_IMX
#define CONFIG_PCIE_IMX_PERST_GPIO IMX_GPIO_NR(2, 0)
#define CONFIG_PCIE_IMX_POWER_GPIO IMX_GPIO_NR(2, 1)
-#endif
#define CONFIG_IMX_THERMAL
Which obtained the following output:
=> pci enum
=> pci 0
No such bus
=> pci 1
No such bus
Before the DM conversion. Do you have any suggestions as to why the
PCI device is not detected after the DM_PCI conversion? Are you able
to get i.MX6SX to detect PCI devices when using DM_PCI?
Thank you in advance,
Pedro Jardim.
Re: [PATCH] dtc: add ability to make nodes conditional on them being referenced
Hi Andre, On Sat, 25 Jan 2020 at 16:18, André Przywara wrote: > > On 25/01/2020 16:20, Tom Rini wrote: > > Hi Tom, > > thanks for having a look! > > > > On Tue, Jan 21, 2020 at 10:23:17AM +, Andre Przywara wrote: > > > >> From: Maxime Ripard > >> > >> This is needed when importing mainline DTs into U-Boot, as some started > >> using this /omit-if-no-ref/ tag, so won't compile with U-Boot's current > >> dtc copy. This is just a cherry-pick of the patch introducing this > >> feature. > >> Original commit message from Maxime: > >> -- > >> A number of platforms have a need to reduce the number of DT nodes, > >> mostly because of two similar constraints: the size of the DT blob, and > >> the time it takes to parse it. > >> > >> As the DT is used in more and more SoCs, and by more projects, some > >> constraints start to appear in bootloaders running from SRAM with an > >> order of magnitude of 10kB. A typical DT is in the same order of > >> magnitude, so any effort to reduce the blob size is welcome in such an > >> environment. > >> > >> Some platforms also want to reach very fast boot time, and the time it > >> takes to parse a typical DT starts to be noticeable. > >> > >> Both of these issues can be mitigated by reducing the number of nodes in > >> the DT. The biggest provider of nodes is usually the pin controller and > >> its subnodes, usually one for each valid pin configuration in a given > >> SoC. > >> > >> Obviously, a single, fixed, set of these nodes will be used by a given > >> board, so we can introduce a node property that will tell the DT > >> compiler to drop the nodes when they are not referenced in the tree, and > >> as such wouldn't be useful in the targetted system. > >> > >> Signed-off-by: Maxime Ripard > >> Reviewed-by: Rob Herring > >> Signed-off-by: Andre Przywara > >> --- > >> scripts/dtc/checks.c | 13 + > >> scripts/dtc/dtc-lexer.l | 7 +++ > >> scripts/dtc/dtc-parser.y | 17 + > >> scripts/dtc/dtc.h| 4 > >> scripts/dtc/livetree.c | 14 ++ > >> 5 files changed, 55 insertions(+) Reviewed-by: Simon Glass Is this for SPL or U-Boot proper? I assume the former since you talk about SRAM. But changing dtc won't affect SPL at present, since the DT is not separately compiled for SPL. Of course if nodes are not needed for U-Boot proper, removing them is good and may have SPL too. But we use dtoc to drop unwanted nodes (as you probably know), and U-Boot has its own tags for indicating what nodes should be present (since everything is omitted from SPL by default). Regards, Simon
Re: [PATCH v2][ 1/3] tbs2910: disable fuse command
On Tue, Jan 28, 2020 at 2:04 PM Denis 'GNUtoo' Carikli wrote: > > The fuse command is not needed for booting or during usual > users interactions with u-boot. > > As that the resulting u-boot.imx image is already very > close to the size limit, removing the fuse command shouldn't > hurt. > > With arm-linux-gnueabi-gcc 9.2.0-1 from the Parabola > GNU/Linux distribution, it shrinks the image from 392192 to > 388096 bytes. I think it would be more readable if you put the delta value instead of initial versus final.
[PATCH v2][ 1/3] tbs2910: disable fuse command
The fuse command is not needed for booting or during usual users interactions with u-boot. As that the resulting u-boot.imx image is already very close to the size limit, removing the fuse command shouldn't hurt. With arm-linux-gnueabi-gcc 9.2.0-1 from the Parabola GNU/Linux distribution, it shrinks the image from 392192 to 388096 bytes. Signed-off-by: Denis 'GNUtoo' Carikli --- configs/tbs2910_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig index 61d4c74324..0f12b94257 100644 --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -24,6 +24,7 @@ CONFIG_CMD_BOOTZ=y # CONFIG_BOOTM_VXWORKS is not set # CONFIG_CMD_FDT is not set CONFIG_CMD_MEMTEST=y +# CONFIG_CMD_FUSE is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y -- 2.24.1
Re: [PATCH] board: tbs2910: Add support for generic distro configuration
On Sun, 26 Jan 2020 01:40:13 +0100 Soeren Moch wrote: > > Ahh ok, now I understand. That probably explains the repeated size > > issues. > Why? With SPL+u-boot proper it would be even worse, since then there > is a gap between SPL and u-boot, u-boot starts at higher address in > eMMC, and it would not be smaller. And this 2-stage boot would break > the documented u-boot update procedure, since we have to flash 2 > files then. I assumed that in some conditions, the bootrom could load only the SPL in sram. Once loaded, the SPL would initialize the RAM, detect the boot media, and fetch u-boot.img from it, and execute it. I also hoped the the SPL would have been significantly smaller than the current u-boot.imx image. In the meantime, I'll send a v2 with some additional patches to reduce the size of the resulting u-boot.imx. Denis. pgpBSaD6X6Gg5.pgp Description: OpenPGP digital signature
[PATCH v2][ 2/3] tbs2910: disable loadb and loads commands
The loadb and loads commands are not needed for booting. There are also more reliable and faster alternatives to loadb and loads that can be used with the current configuration. As that the resulting u-boot.imx image is already very close to the size limit, removing the loadb and loads commands shouldn't hurt. With arm-linux-gnueabi-gcc 9.2.0-1 from the Parabola GNU/Linux distribution, it shrinks the image from 388096 to 384000 bytes. Signed-off-by: Denis 'GNUtoo' Carikli --- configs/tbs2910_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig index 0f12b94257..0e91eeffd4 100644 --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -27,6 +27,8 @@ CONFIG_CMD_MEMTEST=y # CONFIG_CMD_FUSE is not set CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y +# CONFIG_CMD_LOADB is not set +# CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y CONFIG_CMD_PART=y CONFIG_CMD_PCI=y -- 2.24.1
[PATCH v2][ 3/3] board: tbs2910: Add support for generic distro configuration
This keeps the compatibility with the old bootcmd. The fdtfile environment variable also needed to be set to imx6q-tbs2910.dtb to enable booting mainline kernels otherwise with extlinux.conf it tries to load mx6-tbs2910.dtb instead. Signed-off-by: Denis 'GNUtoo' Carikli --- configs/tbs2910_defconfig | 17 - include/configs/tbs2910.h | 37 - 2 files changed, 32 insertions(+), 22 deletions(-) diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig index 0e91eeffd4..0d9e11bd20 100644 --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -9,16 +9,16 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_PRE_CON_BUF_ADDR=0x7c00 CONFIG_CMD_HDMIDETECT=y CONFIG_AHCI=y +CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTDELAY=3 +# CONFIG_USE_BOOTCOMMAND is not set CONFIG_USE_PREBOOT=y CONFIG_PREBOOT="echo PCI:; pci enum; pci 1; usb start; if hdmidet; then run set_con_hdmi; else run set_con_serial; fi" CONFIG_PRE_CONSOLE_BUFFER=y -CONFIG_SUPPORT_RAW_INITRD=y +CONFIG_DEFAULT_FDT_FILE="imx6q-tbs2910.dtb" CONFIG_BOUNCE_BUFFER=y CONFIG_BOARD_EARLY_INIT_F=y -CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Matrix U-Boot> " -CONFIG_CMD_BOOTZ=y # CONFIG_BOOTM_PLAN9 is not set # CONFIG_BOOTM_RTEMS is not set # CONFIG_BOOTM_VXWORKS is not set @@ -30,22 +30,14 @@ CONFIG_CMD_I2C=y # CONFIG_CMD_LOADB is not set # CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y -CONFIG_CMD_PART=y CONFIG_CMD_PCI=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y -CONFIG_CMD_DHCP=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y -CONFIG_EFI_PARTITION=y +# CONFIG_ISO_PARTITION is not set CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="imx6q-tbs2910" @@ -75,7 +67,6 @@ CONFIG_RTC_DS1307=y CONFIG_DM_THERMAL=y CONFIG_USB=y CONFIG_DM_USB=y -CONFIG_USB_STORAGE=y CONFIG_USB_KEYBOARD=y CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y CONFIG_USB_GADGET=y diff --git a/include/configs/tbs2910.h b/include/configs/tbs2910.h index b598fca1ec..abeca16555 100644 --- a/include/configs/tbs2910.h +++ b/include/configs/tbs2910.h @@ -8,6 +8,24 @@ #ifndef __TBS2910_CONFIG_H #define __TBS2910_CONFIG_H +#define CONFIG_BOOTCOMMAND \ + "mmc rescan; " \ + "if run bootcmd_up1; then " \ + "run bootcmd_up2; " \ + "else " \ + "run bootcmd_mmc || run distro_bootcmd; " \ + "fi" + +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 0) \ + func(MMC, mmc, 1) \ + func(MMC, mmc, 2) \ + func(SATA, sata, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) +#include + #include "mx6_common.h" /* General configuration */ @@ -80,6 +98,13 @@ #define CONFIG_BOARD_SIZE_LIMIT392192 /* (CONFIG_ENV_OFFSET - 1024) */ #define CONFIG_EXTRA_ENV_SETTINGS \ + "bootm_size=0x8000\0" \ + "fdt_addr=0x1300\0" \ + "fdt_addr_r=0x1300\0" \ + "kernel_addr_r=0x10008000\0" \ + "pxefile_addr_r=0x10008000\0" \ + "ramdisk_addr_r=0x1800\0" \ + "scriptaddr=0x1400\0" \ "bootargs_mmc1=console=ttymxc0,115200 di0_primary console=tty1\0" \ "bootargs_mmc2=video=mxcfb0:dev=hdmi,1920x1080M@60 " \ "video=mxcfb1:off video=mxcfb2:off fbmem=28M\0" \ @@ -102,14 +127,8 @@ "setenv stderr serial,vga\0" \ "stderr=serial,vga\0" \ "stdin=serial,usbkbd\0" \ - "stdout=serial,vga\0" - -#define CONFIG_BOOTCOMMAND \ - "mmc rescan; " \ - "if run bootcmd_up1; then " \ - "run bootcmd_up2; " \ - "else " \ - "run bootcmd_mmc; " \ - "fi" + "stdout=serial,vga\0" \ + "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ + BOOTENV #endif/* __TBS2910_CONFIG_H * */ -- 2.24.1
Re: [PATCH v2 02/21] armv7m: cache: add mmu_set_region_dcache_behaviour() stub for compatibility
On 1/28/20 9:10 AM, Lukasz Majewski wrote:
Hi Giulio,
Since some driver
I would prefer more verbose commit message. Please share which driver
requires this change.
Yes, you were right, this is a quite dumb commit log.
Now commit log can't be changed, anyway this is the list of drivers that
use it:
drivers/video/mvebu_lcd.c
drivers/video/mxsfb.c (that I'm going to use soon)
drivers/video/bcm2835.c
drivers/video/fsl_dcu_fb.c
drivers/video/tegra.c
drivers/video/imx/mxc_ipuv3_fb.c
drivers/net/zynq_gem.c
drivers/net/mvneta.c
drivers/net/mvpp2.c
And this function prototype is provided by arch/arm/include/asm/system.h
Everything came out when I've tried to build mxsfb.c.
But after this e-mail I've dug deeper and see that sometimes
mmu_set_region_dcache_behaviour() call is guarded by
CONFIG_IS_ENABLED(SYS_DCACHE_OFF) and sometimes i.e.
arch/arm/cpu/armv8/cache_v8.c that function is defined both implemented
and empty according to CONFIG_IS_ENABLED(SYS_DCACHE_OFF). So one chance
is to put a check to guard against CONFIG_IS_ENABLED(SYS_DCACHE_OFF) on
every call(the files listed above), otherwise, where is guarded we
should remove the guard and adding missing
mmu_set_region_dcache_behaviour() empty implementation. ~5 files to
touch, but if you say it's worth, I can do patches for that, and I don't
see any drawbacks expect having a standard way on dealing with the cache
function.
What about that?
Kind regards
--
Giulio Benetti
Benetti Engineering sas
requires this function add it as an empty stub
when DCACHE is OFF.
Signed-off-by: Giulio Benetti
---
arch/arm/cpu/armv7m/cache.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7m/cache.c b/arch/arm/cpu/armv7m/cache.c
index f4ba3ad50e..7353698557 100644
--- a/arch/arm/cpu/armv7m/cache.c
+++ b/arch/arm/cpu/armv7m/cache.c
@@ -291,6 +291,12 @@ void flush_dcache_all(void)
void invalidate_dcache_all(void)
{
}
+
+void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
+enum dcache_option option)
+{
+}
+
#endif
#if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
Re: [PATCH v2 01/21] spl: fix entry_point equal to load_addr
Hi Lukasz,
all patch series has already been applied, anyway I answer to your
suggestions since something was missing and I'm going to create a patch
for that.
So...
On 1/28/20 9:09 AM, Lukasz Majewski wrote:
Hi Giulio,
At the moment entry_point is set to image_get_load(header) that sets
it to "load address" instead of "entry point", assuming entry_point is
equal to load_addr, but it's not true. Then load_addr is set to
"entry_point - header_size", but this is wrong too since load_addr is
not an entry point.
So use image_get_ep() for entry_point assignment and image_get_load()
for load_addr assignment.
Signed-off-by: Giulio Benetti
---
common/spl/spl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index c1fce62b91..19085ad270 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -284,9 +284,9 @@ int spl_parse_image_header(struct spl_image_info
*spl_image, spl_image->entry_point = image_get_ep(header);
spl_image->size =
image_get_data_size(header); } else {
- spl_image->entry_point =
image_get_load(header);
+ spl_image->entry_point =
image_get_ep(header); /* Load including the header */
- spl_image->load_addr =
spl_image->entry_point -
+ spl_image->load_addr =
image_get_load(header) - header_size;
spl_image->size =
image_get_data_size(header) + header_size;
I'm concerned, that this change will silently break several boards -
the problem is with assumption that entry point is equal to load_addr.
It would be best to pull this change ASAP, so we would have a chance to
fix this by next release.
It's been committed after Patrice fixed a lot of boards:
https://gitlab.denx.de/u-boot/u-boot/commit/38a6cce65737096b836d43a22f09b7a54c9d020c
and
https://gitlab.denx.de/u-boot/u-boot/commit/74bb4570a952b06fecfafc5b961a5cb5147ec544
Indeed at the first moment it's been committed by Tom Rini and started
to cause boot failure as you were worried for, then it's been reverted,
then it's been re-applied after applying Patrice series.
Best regards
--
Giulio Benetti
Benetti Engineering sas
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
Re: [U-Boot] [PATCH] net: eth-uclass: Remove warning about ROM MAC address
Hi Joe, Ping On Mon, Jan 6, 2020 at 8:32 PM Fabio Estevam wrote: > > Hi Joe, > > On Wed, Dec 11, 2019 at 8:54 AM Schrempf Frieder > wrote: > > > > On 11.10.19 01:00, Soeren Moch wrote: > > > Using a MAC address from ROM storage is the normal case for most > > > ethernet hardware. Why should we warn about this? > > > > > > Signed-off-by: Soeren Moch > > > > Some months ago I came up with the very same patch and I currently have > > it in my local fork with the description "Reading the MAC address from > > ROM is often a standard use case and should not produce a warning". > > > > Therefore I'm supporting Soeren's and Fabio's point of view here and I'm > > in favor of merging this patch or if preferred, change the printf() to > > debug(). > > > > Reviewed-by: Frieder Schrempf > > Any feedback, please?
Re: [PATCH v2 01/11] clk: Always use the supplied struct clk
On 1/27/20 6:40 PM, Lukasz Majewski wrote:
>> The real problem with the current approach (IMO) is that there is a
>> mismatch between the clock structure and the clock function. If one
>> calls clk_get_rate on some clock, the get_rate function is chosen
>> based on clk->dev->ops.
>
> Yes, exactly. This seems logical to me -> the "top" structure is struct
> clk, which is a device with proper ops.
> (And in U-Boot the 'central' data structure with DM is struct udevice).
>
>> If that clock is a composite clock, the
>> clk_composite_get_rate
>
> I've found only clk_composite_set_rate @ drivers/clk/clk-composite.c
>
> But, yes it calls its own clk_ops (*mux_ops, *rate_ops, *gate_ops).
>
>> will then choose the *real* get_rate function
>> to call, and will call it with the appropriate component clock.
>
> Yes, the struct clk_composite has several clocks defined.
>
>> But
>> then, the get_rate function says "Aha, I know better than you what
>> clock should be passed to me" and calls itself with the composite
>> clock struct instead!
>
> Wouldn't clk_get_rate just return 0 when it discovers that clk->dev is
> NULL for not bound driver (the clk which builds a composite driver)?
Yes, but then clk_get_parent throws a fit, which gets called by
clk_gate_*, clk_fixed_divider_*, clk_mux_*, etc. So this description is
really for the case where only the first section of this patch is
applied.
>> This is really unintitive behaviour. If
>> anything, this kind of behaviour should be moved up to clk_get_rate,
>> where it can't cause any harm in composite clocks.
>
> Even better, the composite clocks shall be handled in the same way as
> non composite ones.
>
>
> To achieve that:
>
> 1. The struct clk shall be passed to all clk functions (IIRC this is
> now true in U-Boot):
> - then clk IP block specific structure (e.g. struct clk_gate2)
> are accessible via container_of on clk pointer
Ok, so I'm a bit confused about the design decisions here. It seems to
me that there are two uses for struct clk:
- struct clk as used by drivers not using the CCF. Here, the
structure is effectively an extended parameter list,
containing all the data needed to operate on some clock.
clk->dev->priv contains whatever the driver wants, and doesn't
necessarily have a struct clk. Because these clocks are mostly
just parameters, they can be created with xlate and request;
there is no one "canonical" struct clk for any given logical
clock. These clocks can appear on a device tree, and be
acquired by clk_get_by_*.
- struct clk as used by CCF clocks. Here the structure contains
specific information configuring each clock. Each struct clk
refers to a different logical clock. clk->dev->priv contains a
struct clk (though this may not be the same struct clk). These
clocks cannot appear in a device tree, and hence cannot be
acquired by clk_get_by_* (except for clk_get_by_id which
doesn't use the device tree). These clocks are not created by
xlate and request.
With this in mind, I'm not sure why one would ever need to call
dev_get_clk_ptr. In the first case, clk->dev->priv could be anything,
and probably not a clock. In the second case, one already has the
"canonical" struct clk.
> - There shall be clk->dev filled always. In the dev one shall
> use dev->ops to do the necessary work (even for composite
> clocks components)
Do you mean having a struct device for every clock, even components of a
composite clock? I think this is unnecessary, especially for a system
with lots of composite clocks. Storing the clock ops in the composite
clock's struct works fine, and is conceptually simple.
>
> - The struct clk has flags field (clk->flags). New flags:
> -- CCF_CLK_COMPOSITE_REGISTERED (visible with dm tree)
> -- CCF_CLK_COMPOSITE_HIDDEN (used internally to
> gate, mux, etc. the composite clock)
>
>
> -- clk->dev->flags with CCF_CLK_COMPOSITE_REGISTERED
> set puts all "servant" clocks to its child_head list
> (clk->dev->child_head).
>
> __OR__
>
> -- we extend the ccf core to use struct uc_clk_priv
> (as described:
>
> https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/imx/clk/ccf.txt#L40)
> which would have
>
> struct uc_clk_priv {
> struct clk *c; /* back pointer to clk */
>
> struct clk_composite *cc;
> };
>
> struct clk_composite {
> struct clk *mux;
> struct clk *gate;
> ...
> (no ops here - they shall be in struct udevice)
> };
>
>
Re: Pull request: u-boot-spi/master
On Mon, Jan 27, 2020 at 11:18:18PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR. > > Summary: > - spi cs accessing slaves (Bin Meng) > - spi prevent overriding established bus (Marcin Wojtas) > - support speed in spi command (Marek Vasut) > - add W25N01GV spinand (Robert Marko) > - move cadence_qspi to use spi-mem (Vignesh Raghavendra) > - add octal mode (Vignesh Raghavendra) > > thanks, > Jagan. > > The following changes since commit 051e03c0d76b7ce9d4649f76f5be979d8f88e765: > > Merge tag 'u-boot-clk-26Jan2020' of > https://gitlab.denx.de/u-boot/custodians/u-boot-clk (2020-01-27 07:19:26 > -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-spi master > > for you to fetch changes up to daa9405d7c4bdbabe257b03d268277f249bb3297: > > spi: cadence-qspi: Add compatible for TI AM654 (2020-01-27 22:27:22 +0530) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Removing "fdt_high=0xffffffff" from board environments
Hey all, Relatively recently it's been highlighted that a number of boards are disabling relocation of the device tree image in memory and this in turn leading to various difficult to resolve bugs. At heart, disabling device tree relocation at boot is something that should be used in rare circumstances (and more generally fdt_high / initrd_high set to where they are already residing in memory, as a known, correct and aligned address). I would like to ask everyone to update their board config file to use the bootm_size (or set CONFIG_SYS_BOOTMAPSZ) to the amount of memory (size, not location) available to safely contain a kernel, device tree and initrd for relocation. Thanks all! -- Tom signature.asc Description: PGP signature
[PATCH] tools: mkimage: fix STM32 image format for big endian hosts
From: Antonio Borneo Two header fields are not properly converted to little endian before assignment, resulting in incorrect header while executing mkimage on big endian hosts. Convert the value of the header fields image_checksum and edcsa_algorithm to little endian before the assignment. Signed-off-by: Antonio Borneo Reviewed-by: Patrick DELAUNAY Signed-off-by: Patrick Delaunay --- tools/stm32image.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/stm32image.c b/tools/stm32image.c index ff3ec5f3f2..18357c0518 100644 --- a/tools/stm32image.c +++ b/tools/stm32image.c @@ -45,7 +45,7 @@ static void stm32image_default_header(struct stm32_header *ptr) ptr->magic_number = HEADER_MAGIC; ptr->header_version[VER_MAJOR_IDX] = HEADER_VERSION_V1; ptr->option_flags = HEADER_DEFAULT_OPTION; - ptr->ecdsa_algorithm = 1; + ptr->ecdsa_algorithm = cpu_to_le32(1); ptr->binary_type = HEADER_TYPE_UBOOT; } @@ -131,7 +131,8 @@ static void stm32image_set_header(void *ptr, struct stat *sbuf, int ifd, stm32hdr->image_entry_point = cpu_to_le32(params->ep); stm32hdr->image_length = cpu_to_le32((uint32_t)sbuf->st_size - sizeof(struct stm32_header)); - stm32hdr->image_checksum = stm32image_checksum(ptr, sbuf->st_size); + stm32hdr->image_checksum = + cpu_to_le32(stm32image_checksum(ptr, sbuf->st_size)); } /* -- 2.17.1
Re: soft_spi does not get probed in DM
Hi Jagan, On Tue, Jan 28, 2020 at 10:56 AM Jagan Teki wrote: > Hope you have aliases spi0 = here? Even if I add the alias the soft_spi does not get probed. Any ideas?
Re: soft_spi does not get probed in DM
Hi Fabio, On Tue, Jan 28, 2020 at 7:07 PM Fabio Estevam wrote: > > Hi Jagan, > > On a mx7dsabresd board I am not being able to probe the soft_spi > driver using DM with mainline U-Boot. > > Device tree used is the same one as used in the kernel (imx7d-sdb.dts). > > soft_spi driver is used to communicate with a I/O expander (supported > via CONFIG_DM_74X164), but it can't get probed: > > spi 0 [ ] soft_spi |-- spi4 > > which causes the the I/O expander to not get probed as well. > > What needs to be done for soft_spi to get probed in DM? Hope you have aliases spi0 = here? Jagan.
Re: [PATCH v4 01/10] env: nowhere: set default enviroment
Dear Keerthy,
In message <927f859e-9c93-2731-c69e-e491219a8...@ti.com> you wrote:
>
> > --- a/env/nowhere.c
> > +++ b/env/nowhere.c
> > @@ -23,6 +23,7 @@ static int env_nowhere_init(void)
> >{
> > gd->env_addr= (ulong)_environment[0];
> > gd->env_valid = ENV_INVALID;
> > + (NULL, 0);
> >>
> >> ^^
> >> You are inserting this line of "C code" only.
> >
> > I think something got ate along the way. The patch is at
> > http://patchwork.ozlabs.org/patch/1226946/
> > and the full line is:
> > + env_set_default(NULL, 0);
>
> env_set_default(NULL, 0); sets the required flag for us in the nowhere
> path as well.
I see. Sorry, I didn't read the original patch. As you see in the
quote above, the "env_set_default" somehow got lost, and this was
what triggered my comment.
Feel free to ignore it.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Love all, trust a few. - William Shakespeare
[PATCH v3 0/7] board: toradex: prepare and add Verdin iMX8M Mini support
Some preparational steps and then adding initial minimal support for the Toradex Verdin iMX8M Mini Quad 2GB WB IT V1.0A module. They are now strapped to boot from eFuses which are factory fused to properly boot from their on-module eMMC. U-Boot supports booting from the on-module eMMC only, SDP support is disabled for now due to missing i.MX 8M Mini USB support. Functionality wise the following is known to be working: - eMMC, 8-bit and 4-bit MMC/SD card slots - Ethernet - GPIOs - I2C Boot sequence is: SPL ---> ATF (TF-A) ---> U-boot proper ATF, U-boot proper and u-boot.dtb images are packed into a FIT image, loaded by SPL. Boot: U-Boot SPL 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100) Normal Boot Trying to boot from MMC1 NOTICE: Configuring TZASC380 NOTICE: RDC off NOTICE: BL31: v2.0(release):rel_imx_4.14.98_2.3.0-0-g09c5cc994-dirty NOTICE: BL31: Built : 01:11:41, Jan 25 2020 NOTICE: sip svc init U-Boot 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100) CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz Reset cause: POR DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK In:serial Out: serial Err: serial Model: Toradex Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT V1.0A, Serial# 06535149 Net: eth0: ethernet@30be Hit any key to stop autoboot: 0 Verdin iMX8MM # Changes in v3: - Drop pinfunc patches and just sync with linux-next as suggested by Fabio, Frieder and Oleksandr. - Drop AG resp. Inc. in copyright notices as adviced by our legal. - Add Oleksandr's reviewed-by tags. - Add missing config block information for Verdin iMX8M Nano as well. - Use pin names from the linux-next pinfunc sync as suggested by Oleksandr. Changes in v2: - Newly added this patch to the series splitting Verdin one as suggested by Oleksandr. - Split Apalis iMX8X off from this one as suggested by Oleksandr. - Further clean-up as announced on the mailing list. - Update cover letter with updated SKU naming and few clarifications. Igor Opaniuk (3): board: toradex: Add Verdin iMX8M Mini support board: toradex: verdin-imx8mm: add README board: toradex: verdin-imx8mm: add MAINTAINERS Marcel Ziswiler (4): arm: dts: imx8mm-pinfunc: sync latest linux-next pin func header toradex: tdx-cfg-block: add Apalis iMX8X support toradex: tdx-cfg-block: add Verdin iMX8M Mini/Nano support imx: imx8mm_evk: spelling in readme file arch/arm/dts/Makefile |1 + arch/arm/dts/imx8mm-pinfunc.h | 20 +- arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 103 ++ arch/arm/dts/imx8mm-verdin.dts | 1007 ++ arch/arm/mach-imx/imx8m/Kconfig |7 + board/freescale/imx8mm_evk/README |2 +- board/toradex/common/tdx-cfg-block.c| 39 +- board/toradex/common/tdx-cfg-block.h|7 +- board/toradex/verdin-imx8mm/Kconfig | 30 + board/toradex/verdin-imx8mm/MAINTAINERS |9 + board/toradex/verdin-imx8mm/Makefile| 11 + board/toradex/verdin-imx8mm/README | 88 + board/toradex/verdin-imx8mm/imximage.cfg| 16 + board/toradex/verdin-imx8mm/lpddr4_timing.c | 1850 +++ board/toradex/verdin-imx8mm/spl.c | 180 ++ board/toradex/verdin-imx8mm/verdin-imx8mm.c | 73 + configs/verdin-imx8mm_defconfig | 98 + include/configs/verdin-imx8mm.h | 128 ++ 18 files changed, 3662 insertions(+), 7 deletions(-) create mode 100644 arch/arm/dts/imx8mm-verdin-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mm-verdin.dts create mode 100644 board/toradex/verdin-imx8mm/Kconfig create mode 100644 board/toradex/verdin-imx8mm/MAINTAINERS create mode 100644 board/toradex/verdin-imx8mm/Makefile create mode 100644 board/toradex/verdin-imx8mm/README create mode 100644 board/toradex/verdin-imx8mm/imximage.cfg create mode 100644 board/toradex/verdin-imx8mm/lpddr4_timing.c create mode 100644 board/toradex/verdin-imx8mm/spl.c create mode 100644 board/toradex/verdin-imx8mm/verdin-imx8mm.c create mode 100644 configs/verdin-imx8mm_defconfig create mode 100644 include/configs/verdin-imx8mm.h -- 2.24.1
[PATCH v3 7/7] imx: imx8mm_evk: spelling in readme file
From: Marcel Ziswiler Minor spelling fix in README file. Signed-off-by: Marcel Ziswiler Reviewed-by: Oleksandr Suvorov --- Changes in v3: - Add Oleksandr's reviewed-by tags. Changes in v2: None board/freescale/imx8mm_evk/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/imx8mm_evk/README b/board/freescale/imx8mm_evk/README index 9921b35989..fa3f079f31 100644 --- a/board/freescale/imx8mm_evk/README +++ b/board/freescale/imx8mm_evk/README @@ -3,7 +3,7 @@ U-Boot for the NXP i.MX8MM EVK board Quick Start === - Build the ARM Trusted firmware binary -- Get ddr fimware +- Get ddr firmware - Build U-Boot - Boot -- 2.24.1
[PATCH v3 4/7] board: toradex: Add Verdin iMX8M Mini support
From: Igor Opaniuk
This adds initial minimal support for the Toradex Verdin iMX8M Mini Quad
2GB WB IT V1.0A module. They are now strapped to boot from eFuses which
are factory fused to properly boot from their on-module eMMC. U-Boot
supports booting from the on-module eMMC only, SDP support is disabled
for now due to missing i.MX 8M Mini USB support.
Functionality wise the following is known to be working:
- eMMC, 8-bit and 4-bit MMC/SD card slots
- Ethernet
- GPIOs
- I2C
Boot sequence is:
SPL ---> ATF (TF-A) ---> U-boot proper
ATF, U-boot proper and u-boot.dtb images are packed into a FIT image,
loaded by SPL.
Boot:
U-Boot SPL 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
Normal Boot
Trying to boot from MMC1
NOTICE: Configuring TZASC380
NOTICE: RDC off
NOTICE: BL31: v2.0(release):rel_imx_4.14.98_2.3.0-0-g09c5cc994-dirty
NOTICE: BL31: Built : 01:11:41, Jan 25 2020
NOTICE: sip svc init
U-Boot 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz
Reset cause: POR
DRAM: 2 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial
Out: serial
Err: serial
Model: Toradex Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT V1.0A, Serial#
06535149
Net: eth0: ethernet@30be
Hit any key to stop autoboot: 0
Verdin iMX8MM #
Signed-off-by: Igor Opaniuk
Signed-off-by: Max Krummenacher
Signed-off-by: Marcel Ziswiler
---
Changes in v3:
- Drop AG resp. Inc. in copyright notices as adviced by our legal.
- Use pin names from the linux-next pinfunc sync as suggested by
Oleksandr.
Changes in v2:
- Further clean-up as announced on the mailing list.
arch/arm/dts/Makefile |1 +
arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 103 ++
arch/arm/dts/imx8mm-verdin.dts | 1007 ++
arch/arm/mach-imx/imx8m/Kconfig |7 +
board/toradex/verdin-imx8mm/Kconfig | 30 +
board/toradex/verdin-imx8mm/Makefile| 11 +
board/toradex/verdin-imx8mm/imximage.cfg| 16 +
board/toradex/verdin-imx8mm/lpddr4_timing.c | 1850 +++
board/toradex/verdin-imx8mm/spl.c | 180 ++
board/toradex/verdin-imx8mm/verdin-imx8mm.c | 73 +
configs/verdin-imx8mm_defconfig | 98 +
include/configs/verdin-imx8mm.h | 128 ++
12 files changed, 3504 insertions(+)
create mode 100644 arch/arm/dts/imx8mm-verdin-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mm-verdin.dts
create mode 100644 board/toradex/verdin-imx8mm/Kconfig
create mode 100644 board/toradex/verdin-imx8mm/Makefile
create mode 100644 board/toradex/verdin-imx8mm/imximage.cfg
create mode 100644 board/toradex/verdin-imx8mm/lpddr4_timing.c
create mode 100644 board/toradex/verdin-imx8mm/spl.c
create mode 100644 board/toradex/verdin-imx8mm/verdin-imx8mm.c
create mode 100644 configs/verdin-imx8mm_defconfig
create mode 100644 include/configs/verdin-imx8mm.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9303beb2f5..895d405922 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -718,6 +718,7 @@ dtb-$(CONFIG_ARCH_IMX8) += \
dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-evk.dtb \
+ imx8mm-verdin.dtb \
imx8mn-ddr4-evk.dtb \
imx8mq-evk.dtb \
imx8mp-evk.dtb
diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
new file mode 100644
index 00..d091577a96
--- /dev/null
+++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright 2020 Toradex
+ */
+
+ {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_24m {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+_i2c1 {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
+_uart1 {
+ u-boot,dm-spl;
+};
+
+_usdhc2 {
+ u-boot,dm-spl;
+};
+
+&{/soc@0} {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mm-verdin.dts b/arch/arm/dts/imx8mm-verdin.dts
new file mode 100644
index 00..2980053e82
--- /dev/null
+++ b/arch/arm/dts/imx8mm-verdin.dts
@@ -0,0 +1,1007 @@
+//
[PATCH v3 5/7] board: toradex: verdin-imx8mm: add README
From: Igor Opaniuk
Add README with build steps for U-boot and TF-A for Verdin iMX8M Mini SoM.
Signed-off-by: Igor Opaniuk
Signed-off-by: Marcel Ziswiler
Reviewed-by: Oleksandr Suvorov
---
Changes in v3:
- Add Oleksandr's reviewed-by tags.
Changes in v2: None
board/toradex/verdin-imx8mm/README | 88 ++
1 file changed, 88 insertions(+)
create mode 100644 board/toradex/verdin-imx8mm/README
diff --git a/board/toradex/verdin-imx8mm/README
b/board/toradex/verdin-imx8mm/README
new file mode 100644
index 00..1dac969476
--- /dev/null
+++ b/board/toradex/verdin-imx8mm/README
@@ -0,0 +1,88 @@
+U-Boot for the Toradex Verdin iMX8M Mini Module
+
+Quick Start
+===
+
+- Build the ARM trusted firmware binary
+- Get the DDR firmware
+- Build U-Boot
+- Flash to eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware (Trusted Firmware A)
+===
+
+$ echo "Downloading and building TF-A..."
+$ git clone -b imx_4.14.98_2.3.0
https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf
+
+Please edit `plat/imx/imx8mm/include/platform_def.h` so it contains proper
+values for UART configuration and BL31 base address (correct values listed
+below):
+#define BL31_BASE 0x91
+#define IMX_BOOT_UART_BASE 0x3086
+#define DEBUG_CONSOLE 1
+
+Then build ATF (TF-A):
+$ make PLAT=imx8mm bl31
+
+Get the DDR Firmware
+
+
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
+$ chmod +x firmware-imx-8.4.1.bin
+$ ./firmware-imx-8.4.1.bin
+$ cp firmware-imx-8.4.1/firmware/ddr/synopsys/lpddr4*.bin ./
+
+Build U-Boot
+
+
+$ export CROSS_COMPILE=aarch64-linux-gnu-
+$ make verdin-imx8mm_defconfig
+$ make flash.bin
+
+Flash to eMMC
+=
+
+> tftpboot ${loadaddr} flash.bin
+> setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+> mmc dev 0 1 && mmc write ${loadaddr} 0x2 ${blkcnt}
+
+As a convenience, instead of the last two commands one may also use the update
+U-Boot wrapper:
+> run update_uboot
+
+Boot
+
+
+ATF, U-boot proper and u-boot.dtb images are packed into FIT image,
+which is loaded and parsed by SPL.
+
+Boot sequence is:
+SPL ---> ATF (TF-A) ---> U-boot proper
+
+Output:
+U-Boot SPL 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
+Normal Boot
+Trying to boot from MMC1
+NOTICE: Configuring TZASC380
+NOTICE: RDC off
+NOTICE: BL31: v2.0(release):rel_imx_4.14.98_2.3.0-0-g09c5cc994-dirty
+NOTICE: BL31: Built : 01:11:41, Jan 25 2020
+NOTICE: sip svc init
+
+
+U-Boot 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
+
+CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz
+Reset cause: POR
+DRAM: 2 GiB
+MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
+Loading Environment from MMC... OK
+In:serial
+Out: serial
+Err: serial
+Model: Toradex Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT V1.0A, Serial# 06535149
+Net: eth0: ethernet@30be
+Hit any key to stop autoboot: 0
+Verdin iMX8MM #
--
2.24.1
[PATCH v3 1/7] arm: dts: imx8mm-pinfunc: sync latest linux-next pin func header
From: Marcel Ziswiler Synchronise with latest linux-next kernel pin func header file. Signed-off-by: Marcel Ziswiler --- Changes in v3: - Drop pinfunc patches and just sync with linux-next as suggested by Fabio, Frieder and Oleksandr. Changes in v2: None arch/arm/dts/imx8mm-pinfunc.h | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/imx8mm-pinfunc.h b/arch/arm/dts/imx8mm-pinfunc.h index e25f7fcd79..5ccc4cc919 100644 --- a/arch/arm/dts/imx8mm-pinfunc.h +++ b/arch/arm/dts/imx8mm-pinfunc.h @@ -430,18 +430,26 @@ #define MX8MM_IOMUXC_SAI1_MCLK_SIM_M_HRESP 0x1AC 0x414 0x000 0x7 0x0 #define MX8MM_IOMUXC_SAI2_RXFS_SAI2_RX_SYNC 0x1B0 0x418 0x000 0x0 0x0 #define MX8MM_IOMUXC_SAI2_RXFS_SAI5_TX_SYNC 0x1B0 0x418 0x4EC 0x1 0x2 +#define MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x1B0 0x418 0x000 0x4 0x0 +#define MX8MM_IOMUXC_SAI2_RXFS_UART1_DTE_RX 0x1B0 0x418 0x4F4 0x4 0x2 #define MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 0x1B0 0x418 0x000 0x5 0x0 #define MX8MM_IOMUXC_SAI2_RXFS_SIM_M_HSIZE0 0x1B0 0x418 0x000 0x7 0x0 #define MX8MM_IOMUXC_SAI2_RXC_SAI2_RX_BCLK 0x1B4 0x41C 0x000 0x0 0x0 #define MX8MM_IOMUXC_SAI2_RXC_SAI5_TX_BCLK 0x1B4 0x41C 0x4E8 0x1 0x2 +#define MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x1B4 0x41C 0x4F4 0x4 0x3 +#define MX8MM_IOMUXC_SAI2_RXC_UART1_DTE_TX 0x1B4 0x41C 0x000 0x4 0x0 #define MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO22 0x1B4 0x41C 0x000 0x5 0x0 #define MX8MM_IOMUXC_SAI2_RXC_SIM_M_HSIZE1 0x1B4 0x41C 0x000 0x7 0x0 #define MX8MM_IOMUXC_SAI2_RXD0_SAI2_RX_DATA0 0x1B8 0x420 0x000 0x0 0x0 #define MX8MM_IOMUXC_SAI2_RXD0_SAI5_TX_DATA0 0x1B8 0x420 0x000 0x1 0x0 +#define MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x1B8 0x420 0x4F0 0x4 0x2 +#define MX8MM_IOMUXC_SAI2_RXD0_UART1_DTE_CTS_B 0x1B8 0x420 0x000 0x4 0x0 #define MX8MM_IOMUXC_SAI2_RXD0_GPIO4_IO23 0x1B8 0x420 0x000 0x5 0x0 #define MX8MM_IOMUXC_SAI2_RXD0_SIM_M_HSIZE2 0x1B8 0x420 0x000 0x7 0x0 #define MX8MM_IOMUXC_SAI2_TXFS_SAI2_TX_SYNC 0x1BC 0x424 0x000 0x0 0x0 #define MX8MM_IOMUXC_SAI2_TXFS_SAI5_TX_DATA1 0x1BC 0x424 0x000 0x1 0x0 +#define MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x1BC 0x424 0x000 0x4 0x0 +#define MX8MM_IOMUXC_SAI2_TXFS_UART1_DTE_RTS_B 0x1BC 0x424 0x4F0 0x4 0x3 #define MX8MM_IOMUXC_SAI2_TXFS_GPIO4_IO24 0x1BC 0x424 0x000 0x5 0x0 #define MX8MM_IOMUXC_SAI2_TXFS_SIM_M_HWRITE 0x1BC 0x424 0x000 0x7 0x0 #define MX8MM_IOMUXC_SAI2_TXC_SAI2_TX_BCLK 0x1C0 0x428 0x000 0x0 0x0 @@ -462,23 +470,31 @@ #define MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28 0x1CC 0x434 0x000 0x5 0x0 #define MX8MM_IOMUXC_SAI3_RXFS_TPSMP_HTRANS0 0x1CC 0x434 0x000 0x7 0x0 #define MX8MM_IOMUXC_SAI3_RXC_SAI3_RX_BCLK 0x1D0 0x438 0x000 0x0 0x0 -#define MX8MM_IOMUXC_SAI3_RXC_GPT1_CAPTURE2 0x1D0 0x438 0x000 0x1 0x0 +#define MX8MM_IOMUXC_SAI3_RXC_GPT1_CLK 0x1D0 0x438 0x000 0x1 0x0 #define MX8MM_IOMUXC_SAI3_RXC_SAI5_RX_BCLK 0x1D0 0x438 0x4D0 0x2 0x2 +#define MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B 0x1D0 0x438 0x000 0x4 0x0 +#define MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_RTS_B 0x1D0 0x438 0x4F8 0x4 0x2 #define MX8MM_IOMUXC_SAI3_RXC_GPIO4_IO29 0x1D0 0x438 0x000 0x5 0x0 #define MX8MM_IOMUXC_SAI3_RXC_TPSMP_HTRANS1 0x1D0 0x438 0x000 0x7 0x0 #define MX8MM_IOMUXC_SAI3_RXD_SAI3_RX_DATA0 0x1D4 0x43C 0x000 0x0 0x0 #define MX8MM_IOMUXC_SAI3_RXD_GPT1_COMPARE1 0x1D4 0x43C 0x000 0x1 0x0 #define MX8MM_IOMUXC_SAI3_RXD_SAI5_RX_DATA0 0x1D4 0x43C 0x4D4 0x2 0x2 +#define MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x1D4 0x43C 0x4F8 0x4 0x3 +#define MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_CTS_B 0x1D4 0x43C 0x000 0x4 0x0 #define MX8MM_IOMUXC_SAI3_RXD_GPIO4_IO30 0x1D4 0x43C 0x000 0x5 0x0 #define
[PATCH v3 2/7] toradex: tdx-cfg-block: add Apalis iMX8X support
From: Marcel Ziswiler
Add support for storing configuration for Apalis iMX8X SoM
in Toradex config block.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Oleksandr Suvorov
---
Changes in v3:
- Drop AG resp. Inc. in copyright notices as adviced by our legal.
- Add Oleksandr's reviewed-by tags.
Changes in v2:
- Newly added this patch to the series splitting Verdin one as suggested
by Oleksandr.
board/toradex/common/tdx-cfg-block.c | 17 -
board/toradex/common/tdx-cfg-block.h | 4 +++-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 9c86230595..4d7d2b218c 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (c) 2016-2019 Toradex, Inc.
+ * Copyright (c) 2016-2020 Toradex
*/
#include
@@ -8,6 +8,7 @@
#if defined(CONFIG_TARGET_APALIS_IMX6) || \
defined(CONFIG_TARGET_APALIS_IMX8) || \
+ defined(CONFIG_TARGET_APALIS_IMX8X) || \
defined(CONFIG_TARGET_COLIBRI_IMX6) || \
defined(CONFIG_TARGET_COLIBRI_IMX8X)
#include
@@ -112,6 +113,8 @@ const char * const toradex_modules[] = {
[50] = "Colibri iMX8 QuadXPlus 2GB IT",
[51] = "Colibri iMX8 DualX 1GB Wi-Fi / Bluetooth",
[52] = "Colibri iMX8 DualX 1GB",
+ [53] = "Apalis iMX8 QuadXPlus 2GB ECC IT",
+ [54] = "Apalis iMX8 DualXPlus 1GB",
};
#ifdef CONFIG_TDX_CFG_BLOCK_IS_IN_MMC
@@ -307,6 +310,7 @@ static int get_cfgblock_interactive(void)
it = console_buffer[0];
#if defined(CONFIG_TARGET_APALIS_IMX8) || \
+ defined(CONFIG_TARGET_APALIS_IMX8X) || \
defined(CONFIG_TARGET_COLIBRI_IMX6ULL) || \
defined(CONFIG_TARGET_COLIBRI_IMX8X)
sprintf(message, "Does the module have Wi-Fi / Bluetooth? [y/N] ");
@@ -370,6 +374,16 @@ static int get_cfgblock_interactive(void)
tdx_hw_tag.prodid = APALIS_IMX8QP;
}
} else if (is_cpu_type(MXC_CPU_IMX8QXP)) {
+#ifdef CONFIG_TARGET_APALIS_IMX8X
+ if (it == 'y' || it == 'Y' || wb == 'y' || wb == 'Y') {
+ tdx_hw_tag.prodid = APALIS_IMX8QXP_WIFI_BT_IT;
+ } else {
+ if (gd->ram_size == 0x4000)
+ tdx_hw_tag.prodid = APALIS_IMX8DXP;
+ else
+ tdx_hw_tag.prodid = APALIS_IMX8QXP;
+ }
+#elif CONFIG_TARGET_COLIBRI_IMX8X
if (it == 'y' || it == 'Y') {
if (wb == 'y' || wb == 'Y')
tdx_hw_tag.prodid = COLIBRI_IMX8QXP_WIFI_BT_IT;
@@ -381,6 +395,7 @@ static int get_cfgblock_interactive(void)
else
tdx_hw_tag.prodid = COLIBRI_IMX8DX;
}
+#endif
} else if (!strcmp("tegra20", soc)) {
if (it == 'y' || it == 'Y')
if (gd->ram_size == 0x1000)
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index bfdc8b7f70..99628d96dc 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Copyright (c) 2016 Toradex, Inc.
+ * Copyright (c) 2016-2020 Toradex
*/
#ifndef _TDX_CFG_BLOCK_H
@@ -73,6 +73,8 @@ enum {
COLIBRI_IMX8QXP_IT, /* 50 */
COLIBRI_IMX8DX_WIFI_BT,
COLIBRI_IMX8DX,
+ APALIS_IMX8QXP,
+ APALIS_IMX8DXP,
};
extern const char * const toradex_modules[];
--
2.24.1
[PATCH v3 3/7] toradex: tdx-cfg-block: add Verdin iMX8M Mini/Nano support
From: Marcel Ziswiler
Add support for storing configuration for Verdin iMX8M Mini and
Nano SoMs in Toradex config block.
Signed-off-by: Marcel Ziswiler
Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
---
Changes in v3:
- Add missing config block information for Verdin iMX8M Nano as well.
- Add Oleksandr's reviewed-by tag.
Changes in v2:
- Split Apalis iMX8X off from this one as suggested by Oleksandr.
board/toradex/common/tdx-cfg-block.c | 22 --
board/toradex/common/tdx-cfg-block.h | 3 +++
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 4d7d2b218c..1b6c911418 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -10,7 +10,9 @@
defined(CONFIG_TARGET_APALIS_IMX8) || \
defined(CONFIG_TARGET_APALIS_IMX8X) || \
defined(CONFIG_TARGET_COLIBRI_IMX6) || \
- defined(CONFIG_TARGET_COLIBRI_IMX8X)
+ defined(CONFIG_TARGET_COLIBRI_IMX8X) || \
+ defined(CONFIG_TARGET_VERDIN_IMX8MM) || \
+ defined(CONFIG_TARGET_VERDIN_IMX8MN)
#include
#else
#define is_cpu_type(cpu) (0)
@@ -115,6 +117,9 @@ const char * const toradex_modules[] = {
[52] = "Colibri iMX8 DualX 1GB",
[53] = "Apalis iMX8 QuadXPlus 2GB ECC IT",
[54] = "Apalis iMX8 DualXPlus 1GB",
+ [55] = "Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT",
+ [56] = "Verdin iMX8M Nano SoloLite 1GB", /* not currently on sale */
+ [57] = "Verdin iMX8M Mini DualLite 1GB",
};
#ifdef CONFIG_TDX_CFG_BLOCK_IS_IN_MMC
@@ -297,17 +302,24 @@ static int get_cfgblock_interactive(void)
char *soc;
char it = 'n';
char wb = 'n';
- int len;
+ int len = 0;
/* Unknown module by default */
tdx_hw_tag.prodid = 0;
if (cpu_is_pxa27x())
sprintf(message, "Is the module the 312 MHz version? [y/N] ");
+#if !defined(CONFIG_TARGET_VERDIN_IMX8MM) ||
!defined(CONFIG_TARGET_VERDIN_IMX8MN)
else
sprintf(message, "Is the module an IT version? [y/N] ");
+
len = cli_readline(message);
it = console_buffer[0];
+#else
+ else
+ it = 'y';
+#endif
+
#if defined(CONFIG_TARGET_APALIS_IMX8) || \
defined(CONFIG_TARGET_APALIS_IMX8X) || \
@@ -361,6 +373,12 @@ static int get_cfgblock_interactive(void)
tdx_hw_tag.prodid = COLIBRI_IMX7D;
else if (!strcmp("imx7s", soc))
tdx_hw_tag.prodid = COLIBRI_IMX7S;
+ else if (is_cpu_type(MXC_CPU_IMX8MM))
+ tdx_hw_tag.prodid = VERDIN_IMX8MMQ_WIFI_BT_IT;
+ else if (is_cpu_type(MXC_CPU_IMX8MMDL))
+ tdx_hw_tag.prodid = VERDIN_IMX8MMDL;
+ else if (is_cpu_type(MXC_CPU_IMX8MN))
+ tdx_hw_tag.prodid = VERDIN_IMX8MNSL;
else if (is_cpu_type(MXC_CPU_IMX8QM)) {
if (it == 'y' || it == 'Y') {
if (wb == 'y' || wb == 'Y')
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index 99628d96dc..d8f3941f26 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -75,6 +75,9 @@ enum {
COLIBRI_IMX8DX,
APALIS_IMX8QXP,
APALIS_IMX8DXP,
+ VERDIN_IMX8MMQ_WIFI_BT_IT,
+ VERDIN_IMX8MNSL,
+ VERDIN_IMX8MMDL,
};
extern const char * const toradex_modules[];
--
2.24.1
[PATCH v3 6/7] board: toradex: verdin-imx8mm: add MAINTAINERS
From: Igor Opaniuk Assign Igor Opaniuk as a board maintainer. Signed-off-by: Igor Opaniuk Signed-off-by: Marcel Ziswiler Reviewed-by: Oleksandr Suvorov --- Changes in v3: - Add Oleksandr's reviewed-by tags. Changes in v2: - Update cover letter with updated SKU naming and few clarifications. board/toradex/verdin-imx8mm/MAINTAINERS | 9 + 1 file changed, 9 insertions(+) create mode 100644 board/toradex/verdin-imx8mm/MAINTAINERS diff --git a/board/toradex/verdin-imx8mm/MAINTAINERS b/board/toradex/verdin-imx8mm/MAINTAINERS new file mode 100644 index 00..3b4fae5c66 --- /dev/null +++ b/board/toradex/verdin-imx8mm/MAINTAINERS @@ -0,0 +1,9 @@ +Verdin iMX8M Mini +M: Igor Opaniuk +W: https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini +S: Maintained +F: arch/arm/dts/imx8mm-verdin.dts +F: arch/arm/dts/imx8mm-verdin-u-boot.dtsi +F: board/toradex/verdin-imx8mm/ +F: configs/verdin-imx8mm_defconfig +F: include/configs/verdin-imx8mm.h -- 2.24.1
soft_spi does not get probed in DM
Hi Jagan, On a mx7dsabresd board I am not being able to probe the soft_spi driver using DM with mainline U-Boot. Device tree used is the same one as used in the kernel (imx7d-sdb.dts). soft_spi driver is used to communicate with a I/O expander (supported via CONFIG_DM_74X164), but it can't get probed: spi 0 [ ] soft_spi |-- spi4 which causes the the I/O expander to not get probed as well. What needs to be done for soft_spi to get probed in DM? The "spi-gpio" compatible is present, CONFIG_SPI_SOFT is enabled. We need to use the I/O expander to reset the Ethernet PHY and bring Ethernet functionality back. Thanks, Fabio Estevam
Re: [PATCH v4 1/2] Kconfig: add btrfs to distro boot
On Tue, Jan 28, 2020 at 02:06:20PM +0100, Marek Behun wrote: > On Mon, 27 Jan 2020 18:28:25 -0500 > Tom Rini wrote: > > > On Tue, Jan 28, 2020 at 12:26:45AM +0100, Marek Behun wrote: > > > > > On Mon, 27 Jan 2020 16:58:06 -0500 > > > Tom Rini wrote: > > > > > > > This adds around 60kb to many platforms, so I'm not going to take this > > > > right now. > > > > > > Off topic: I was wondering how much space could be saved if it were > > > possible to use -Os with LTO in U-Boot. > > > > It's a good question. Step one is to switch to using gcc to link > > directly. > > Tom, another option would be to try to amalge btrfs sources into > one file and try to compile it with -Os, I am curious about what would > happen. Maybe I'll try sometime this week. Sure, but per the other email I just sent out, just like how I'm not happy about adding a few hundred bytes to hundreds of boards for QSPI support, I'm not happy to see this be the default for a few hundred boards and we need something more fine-grained. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/2] Kconfig: add btrfs to distro boot
On Tue, Jan 28, 2020 at 11:26:25AM +0100, Matthias Brugger wrote: > > > On 27/01/2020 22:58, Tom Rini wrote: > > On Fri, Jan 17, 2020 at 08:59:02PM +0100, matthias@kernel.org wrote: > > > >> From: Matthias Brugger > >> > >> Some distributions use btrfs as the default file system. > >> Enable btrfs support by default when using distro boot for all > >> architectures but riscv, as it breaks compilation due to size problems. > >> > >> Signed-off-by: Matthias Brugger > > > > This adds around 60kb to many platforms, so I'm not going to take this > > right now. But I'm not rejecting it outright. My question however is, > > I was under the impression that the direction distributions were taking > > was that bootefi would be used to start GRUB2 and that (and its > > filesystem modules) would be responsible for doing the next steps. So > > we wouldn't need btrfs support here for example as everything would be > > picked out of the system partition, which is FAT32. Am I mistaken > > about the flow here? Thanks! > > > > I think the assumption is correct for most of the distributions (if not all). > However in distro boot we support e.g. extlinux/sysboot which not necessarily > boots a EFI binary. Apart from that, think about a broken system partition. In > that case if your distribution has the kernel on a btrfs partition, you would > not be able to boot this kernel. > That's the reason why we enable ext2 and ext4 support in distro boot. > > Regarding the size, I'm aware of the problem, that's why it is set as imply in > Kconfig so that individual boards can turn it off. We might think about > chaning > ext2 and ext4 from select to imply as well as we are at the limit on some > platforms. The extN support portion I thought predates bootefi+GRUB being viable/common and is for when /boot was/is formatted as such. My concern here (similar to my concern about distro boot + SPI) is that we encourage the default for all boards to be "use distro boot, it makes life easy on users". Both big name distributions support it as well as embedded oriented distributions. Non-Linux supports it. So growth here is very important to consider. Perhaps what we can talk about, for v2020.07, is a new not-default sub-option of DISTRO_DEFAULTS to make it more robust, as in your use-case and select more filesystems. And move EXT2/EXT4 to that, but also make all existing users keep it enabled (which is a little tricky, but doable of a migration) and add BTRFS. We can even see if it makes sense to add ZFS there too for the BSD folks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/2] Kconfig: add btrfs to distro boot
On Mon, 27 Jan 2020 18:28:25 -0500 Tom Rini wrote: > On Tue, Jan 28, 2020 at 12:26:45AM +0100, Marek Behun wrote: > > > On Mon, 27 Jan 2020 16:58:06 -0500 > > Tom Rini wrote: > > > > > This adds around 60kb to many platforms, so I'm not going to take this > > > right now. > > > > Off topic: I was wondering how much space could be saved if it were > > possible to use -Os with LTO in U-Boot. > > It's a good question. Step one is to switch to using gcc to link > directly. > Tom, another option would be to try to amalge btrfs sources into one file and try to compile it with -Os, I am curious about what would happen. Maybe I'll try sometime this week.
Re: [PATCH v2 2/8] dt-bindings: pinctrl: imx8mm: add alternative uart muxings
On 28.01.20 13:38, Marcel Ziswiler wrote: > Hi Frieder > > On Mon, 2020-01-27 at 09:10 +, Schrempf Frieder wrote: >> Hi, >> >> On 26.01.20 04:55, Marcel Ziswiler wrote: >>> From: Max Krummenacher >>> >>> Add alternative UART muxing defines. >>> >>> Signed-off-by: Max Krummenacher >> >> Patch 1/8 and 2/8 in this series change the pin definitions for the >> i.MX8MM so that they deviate from the definitions in the Linux >> kernel. > > Yes, I agree. This is not the best approach. > >> As Fabio already pointed out for v1, please instead of adding these >> changes, just sync with the definitions in linux-next [1], which >> should >> already contain these additions from what I can see. > > We had a thorough look at this and while we first were in doubt this > being correct in linux-next we understand now that it just implements > whatever bad UART notation used in NXP's reference manual [2] (section > 16.2.2 External Signals e.g. anybody intimately familiar with UARTs > knows that a DTE vs. DCE TX pin would have different directions [2]). Yes the notation of the UART pins and signals for i.MX SoCs has always been questionable. > Anyway, I will adhere to Fabio and your guidance and just sync with > linux-next for a v3. Ok, thanks! > >> Thanks, >> Frieder > > Thanks! > > Cheers > > Marcel > >> [1]: >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h > > [2] https://www.nxp.com/webapp/Download?colCode=IMX8MMRM > [3] https://en.wikipedia.org/wiki/RS-232#Data_and_control_signals > >>> --- >>> >>> Changes in v2: >>> - Fixed some copy-paste errors. >>> >>>arch/arm/dts/imx8mm-pinfunc.h | 16 >>>1 file changed, 16 insertions(+) >>> >>> diff --git a/arch/arm/dts/imx8mm-pinfunc.h b/arch/arm/dts/imx8mm- >>> pinfunc.h >>> index 3e9955566a..e7fac56db3 100644 >>> --- a/arch/arm/dts/imx8mm-pinfunc.h >>> +++ b/arch/arm/dts/imx8mm-pinfunc.h >>> @@ -472,21 +472,37 @@ >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_SAI3_RX_BCLK >>> 0x1D0 0x438 0x000 0x0 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_GPT1_CLK >>> 0x1D0 0x438 0x000 0x1 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_SAI5_RX_BCLK >>> 0x1D0 0x438 0x4D0 0x2 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B >>> 0x1D0 0x438 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_RTS_B >>> 0x1D0 0x438 0x4F8 0x4 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_CTS_B >>> 0x1D0 0x438 0x4F8 0x4 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_RTS_B >>> 0x1D0 0x438 0x000 0x4 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_GPIO4_IO29 >>> 0x1D0 0x438 0x000 0x5 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXC_TPSMP_HTRANS1 >>> 0x1D0 0x438 0x000 0x7 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_SAI3_RX_DATA0 >>> 0x1D4 0x43C 0x000 0x0 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_GPT1_COMPARE1 >>> 0x1D4 0x43C 0x000 0x1 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_SAI5_RX_DATA0 >>> 0x1D4 0x43C 0x4D4 0x2 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B >>> 0x1D4 0x43C 0x4F8 0x4 0x3 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_CTS_B >>> 0x1D4 0x43C 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_RTS_B >>> 0x1D4 0x43C 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_CTS_B >>> 0x1D4 0x43C 0x4F8 0x4 0x3 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_GPIO4_IO30 >>> 0x1D4 0x43C 0x000 0x5 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_RXD_TPSMP_HDATA0 >>> 0x1D4 0x43C 0x000 0x7 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC >>> 0x1D8 0x440 0x000 0x0 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXFS_GPT1_CAPTURE2 >>> 0x1D8 0x440 0x000 0x1 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXFS_SAI5_RX_DATA1 >>> 0x1D8 0x440 0x4D8 0x2 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX >>> 0x1D8 0x440 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_TX >>> 0x1D8 0x440 0x4FC 0x4 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXFS_UART2_DTE_RX >>> 0x1D8 0x440 0x4FC 0x4 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXFS_UART2_DTE_TX >>> 0x1D8 0x440 0x000 0x4 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXFS_GPIO4_IO31 >>> 0x1D8 0x440 0x000 0x5 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXFS_TPSMP_HDATA1 >>> 0x1D8 0x440 0x000 0x7 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXC_SAI3_TX_BCLK >>> 0x1DC 0x444 0x000 0x0 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXC_GPT1_COMPARE2 >>> 0x1DC 0x444 0x000 0x1 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXC_SAI5_RX_DATA2 >>> 0x1DC 0x444 0x4DC 0x2 0x2 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_RX >>> 0x1DC 0x444 0x000 0x4 0x0 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX >>> 0x1DC 0x444 0x4FC 0x4 0x3 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXC_UART2_DTE_RX >>> 0x1DC 0x444 0x4FC 0x4 0x3 >>> +#define >>> MX8MM_IOMUXC_SAI3_TXC_UART2_DTE_TX >>> 0x1DC 0x444 0x000 0x4 0x0 >>>#define >>> MX8MM_IOMUXC_SAI3_TXC_GPIO5_IO0 >>> 0x1DC 0x444 0x000 0x5 0x0
Re: [PATCH v2 5/8] board: toradex: Add Verdin iMX8M Mini support
Hi Oleksandr On Mon, 2020-01-27 at 14:04 +, Oleksandr Suvorov wrote: > On Sun, Jan 26, 2020 at 5:57 AM Marcel Ziswiler > wrote: > > From: Igor Opaniuk > > > > This adds initial minimal support for the Toradex Verdin iMX8M Mini > > Quad > > 2GB WB IT V1.0A module. They are now strapped to boot from eFuses > > which > > are factory fused to properly boot from their on-module eMMC. U- > > Boot > > supports booting from the on-module eMMC only, SDP support is > > disabled > > for now due to missing i.MX 8M Mini USB support. > > > > Functionality wise the following is known to be working: > > - eMMC, 8-bit and 4-bit MMC/SD card slots > > - Ethernet > > - GPIOs > > - I2C > > > > Boot sequence is: > > SPL ---> ATF (TF-A) ---> U-boot proper > > > > ATF, U-boot proper and u-boot.dtb images are packed into a FIT > > image, > > loaded by SPL. > > > > Boot: > > U-Boot SPL 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100) > > Normal Boot > > Trying to boot from MMC1 > > NOTICE: Configuring TZASC380 > > NOTICE: RDC off > > NOTICE: BL31: v2.0(release):rel_imx_4.14.98_2.3.0-0-g09c5cc994- > > dirty > > NOTICE: BL31: Built : 01:11:41, Jan 25 2020 > > NOTICE: sip svc init > > > > U-Boot 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100) > > > > CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz > > Reset cause: POR > > DRAM: 2 GiB > > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 > > Loading Environment from MMC... OK > > In:serial > > Out: serial > > Err: serial > > Model: Toradex Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT V1.0A, > > Serial# 06535149 > > Net: eth0: ethernet@30be > > Hit any key to stop autoboot: 0 > > Verdin iMX8MM # > > > > Signed-off-by: Igor Opaniuk > > Signed-off-by: Max Krummenacher > > Signed-off-by: Marcel Ziswiler > > This patch uses the i.MX8MM pin names from patches 1/8, 2/8 that > deviate from the definitions in the Linux kernel. > Please use their names synched with the definitions in linux-next > [1]. Yes, sir. ... > -- > Best regards > Oleksandr Suvorov > > Toradex AG > Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 > 4800 (main line) Cheers Marcel
Re: [PATCH v2 2/8] dt-bindings: pinctrl: imx8mm: add alternative uart muxings
Hi Frieder On Mon, 2020-01-27 at 09:10 +, Schrempf Frieder wrote: > Hi, > > On 26.01.20 04:55, Marcel Ziswiler wrote: > > From: Max Krummenacher > > > > Add alternative UART muxing defines. > > > > Signed-off-by: Max Krummenacher > > Patch 1/8 and 2/8 in this series change the pin definitions for the > i.MX8MM so that they deviate from the definitions in the Linux > kernel. Yes, I agree. This is not the best approach. > As Fabio already pointed out for v1, please instead of adding these > changes, just sync with the definitions in linux-next [1], which > should > already contain these additions from what I can see. We had a thorough look at this and while we first were in doubt this being correct in linux-next we understand now that it just implements whatever bad UART notation used in NXP's reference manual [2] (section 16.2.2 External Signals e.g. anybody intimately familiar with UARTs knows that a DTE vs. DCE TX pin would have different directions [2]). Anyway, I will adhere to Fabio and your guidance and just sync with linux-next for a v3. > Thanks, > Frieder Thanks! Cheers Marcel > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h [2] https://www.nxp.com/webapp/Download?colCode=IMX8MMRM [3] https://en.wikipedia.org/wiki/RS-232#Data_and_control_signals > > --- > > > > Changes in v2: > > - Fixed some copy-paste errors. > > > > arch/arm/dts/imx8mm-pinfunc.h | 16 > > 1 file changed, 16 insertions(+) > > > > diff --git a/arch/arm/dts/imx8mm-pinfunc.h b/arch/arm/dts/imx8mm- > > pinfunc.h > > index 3e9955566a..e7fac56db3 100644 > > --- a/arch/arm/dts/imx8mm-pinfunc.h > > +++ b/arch/arm/dts/imx8mm-pinfunc.h > > @@ -472,21 +472,37 @@ > > #define > > MX8MM_IOMUXC_SAI3_RXC_SAI3_RX_BCLK > > 0x1D0 0x438 0x000 0x0 0x0 > > #define > > MX8MM_IOMUXC_SAI3_RXC_GPT1_CLK > > 0x1D0 0x438 0x000 0x1 0x0 > > #define > > MX8MM_IOMUXC_SAI3_RXC_SAI5_RX_BCLK > > 0x1D0 0x438 0x4D0 0x2 0x2 > > +#define > > MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B > > 0x1D0 0x438 0x000 0x4 0x0 > > +#define > > MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_RTS_B > > 0x1D0 0x438 0x4F8 0x4 0x2 > > +#define > > MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_CTS_B > > 0x1D0 0x438 0x4F8 0x4 0x2 > > +#define > > MX8MM_IOMUXC_SAI3_RXC_UART2_DTE_RTS_B > > 0x1D0 0x438 0x000 0x4 0x0 > > #define > > MX8MM_IOMUXC_SAI3_RXC_GPIO4_IO29 > > 0x1D0 0x438 0x000 0x5 0x0 > > #define > > MX8MM_IOMUXC_SAI3_RXC_TPSMP_HTRANS1 > > 0x1D0 0x438 0x000 0x7 0x0 > > #define > > MX8MM_IOMUXC_SAI3_RXD_SAI3_RX_DATA0 > > 0x1D4 0x43C 0x000 0x0 0x0 > > #define > > MX8MM_IOMUXC_SAI3_RXD_GPT1_COMPARE1 > > 0x1D4 0x43C 0x000 0x1 0x0 > > #define > > MX8MM_IOMUXC_SAI3_RXD_SAI5_RX_DATA0 > > 0x1D4 0x43C 0x4D4 0x2 0x2 > > +#define > > MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B > > 0x1D4 0x43C 0x4F8 0x4 0x3 > > +#define > > MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_CTS_B > > 0x1D4 0x43C 0x000 0x4 0x0 > > +#define > > MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_RTS_B > > 0x1D4 0x43C 0x000 0x4 0x0 > > +#define > > MX8MM_IOMUXC_SAI3_RXD_UART2_DTE_CTS_B > > 0x1D4 0x43C 0x4F8 0x4 0x3 > > #define > > MX8MM_IOMUXC_SAI3_RXD_GPIO4_IO30 > > 0x1D4 0x43C 0x000 0x5 0x0 > > #define > > MX8MM_IOMUXC_SAI3_RXD_TPSMP_HDATA0 > > 0x1D4 0x43C 0x000 0x7 0x0 > > #define > > MX8MM_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC > > 0x1D8 0x440 0x000 0x0 0x0 > > #define > > MX8MM_IOMUXC_SAI3_TXFS_GPT1_CAPTURE2 > > 0x1D8 0x440 0x000 0x1 0x0 > > #define > > MX8MM_IOMUXC_SAI3_TXFS_SAI5_RX_DATA1 > > 0x1D8 0x440 0x4D8 0x2 0x2 > > +#define > > MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX > > 0x1D8 0x440 0x000 0x4 0x0 > > +#define > > MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_TX > > 0x1D8 0x440 0x4FC 0x4 0x2 > > +#define > > MX8MM_IOMUXC_SAI3_TXFS_UART2_DTE_RX > > 0x1D8 0x440 0x4FC 0x4 0x2 > > +#define > > MX8MM_IOMUXC_SAI3_TXFS_UART2_DTE_TX > > 0x1D8 0x440 0x000 0x4 0x0 > > #define > > MX8MM_IOMUXC_SAI3_TXFS_GPIO4_IO31 > > 0x1D8 0x440 0x000 0x5 0x0 > > #define > > MX8MM_IOMUXC_SAI3_TXFS_TPSMP_HDATA1 > > 0x1D8 0x440 0x000 0x7 0x0 > > #define > > MX8MM_IOMUXC_SAI3_TXC_SAI3_TX_BCLK
[PATCH v2] eth: mtk-eth: aarch64: fix build warnings on ethernet-driver
building mtk ethernet driver for aarch64 (mt7622) results in warnings
drivers/net/mtk_eth.c: In function 'mtk_eth_fifo_init':
drivers/net/mtk_eth.c:856:21: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
flush_dcache_range((u32)pkt_base, (u32)(pkt_base + TOTAL_PKT_BUF_SIZE));
^
drivers/net/mtk_eth.c:856:36: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
^
drivers/net/mtk_eth.c: In function 'mtk_eth_send':
drivers/net/mtk_eth.c:968:21: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
flush_dcache_range((u32)pkt_base, (u32)pkt_base +
drivers/net/mtk_eth.c:968:36: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
drivers/net/mtk_eth.c: In function 'mtk_eth_recv':
drivers/net/mtk_eth.c:994:26: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
invalidate_dcache_range((u32)pkt_base, (u32)pkt_base +
^
drivers/net/mtk_eth.c:994:41: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
^
drivers/net/mtk_eth.c: In function 'mtk_eth_probe':
drivers/net/mtk_eth.c:1026:18: error: cast to pointer from integer of different
size [-Werror=int-to-pointer-cast]
priv->fe_base = (void *)iobase;
^
drivers/net/mtk_eth.c:1029:20: error: cast to pointer from integer of different
size [-Werror=int-to-pointer-cast]
priv->gmac_base = (void *)(iobase + GMAC_BASE);
Fixes: 23f17164d9 ("ethernet: MediaTek: add ethernet driver for MediaTek
ARM-based SoCs")
Signed-off-by: Frank Wunderlich
---
changes since v1: fixing missing unsigned declaration
---
drivers/net/mtk_eth.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
index 6cffc3f32a..82e9d0040c 100644
--- a/drivers/net/mtk_eth.c
+++ b/drivers/net/mtk_eth.c
@@ -853,7 +853,8 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv *priv)
memset(priv->rx_ring_noc, 0, NUM_RX_DESC * sizeof(struct pdma_rxdesc));
memset(priv->pkt_pool, 0, TOTAL_PKT_BUF_SIZE);
- flush_dcache_range((u32)pkt_base, (u32)(pkt_base + TOTAL_PKT_BUF_SIZE));
+ flush_dcache_range((unsigned int)pkt_base,
+ (unsigned int)(pkt_base + TOTAL_PKT_BUF_SIZE));
priv->rx_dma_owner_idx0 = 0;
priv->tx_cpu_owner_idx0 = 0;
@@ -965,7 +966,7 @@ static int mtk_eth_send(struct udevice *dev, void *packet,
int length)
pkt_base = (void *)phys_to_virt(priv->tx_ring_noc[idx].txd_info1.SDP0);
memcpy(pkt_base, packet, length);
- flush_dcache_range((u32)pkt_base, (u32)pkt_base +
+ flush_dcache_range((unsigned int)pkt_base, (unsigned int)pkt_base +
roundup(length, ARCH_DMA_MINALIGN));
priv->tx_ring_noc[idx].txd_info2.SDL0 = length;
@@ -991,8 +992,9 @@ static int mtk_eth_recv(struct udevice *dev, int flags,
uchar **packetp)
length = priv->rx_ring_noc[idx].rxd_info2.PLEN0;
pkt_base = (void *)phys_to_virt(priv->rx_ring_noc[idx].rxd_info1.PDP0);
- invalidate_dcache_range((u32)pkt_base, (u32)pkt_base +
- roundup(length, ARCH_DMA_MINALIGN));
+ invalidate_dcache_range((unsigned int)pkt_base,
+ (unsigned int)(pkt_base +
+ roundup(length, ARCH_DMA_MINALIGN)));
if (packetp)
*packetp = pkt_base;
@@ -1019,7 +1021,7 @@ static int mtk_eth_probe(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_platdata(dev);
struct mtk_eth_priv *priv = dev_get_priv(dev);
- u32 iobase = pdata->iobase;
+ unsigned int iobase = pdata->iobase;
int ret;
/* Frame Engine Register Base */
--
2.17.1
Re: [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
On 1/28/20 10:11 AM, Patrick Delaunay wrote: > From: Antonio Borneo > > LTDC modifies the clock frequency to adapt it to the display. Such > frequency change is not detected by the FDCAN driver that instead > cache the value at probe and pretend to use it later. > > Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R. Now this looks like a grisly workaround. Can you fix the LTDC driver to do something sane on boards which didn't update bootloader yet ?
[PATCH] eth: mtk-eth: aarch64: fix build warnings on ethernet-driver
building mtk ethernet driver for aarch64 (mt7622) results in warnings
drivers/net/mtk_eth.c: In function 'mtk_eth_fifo_init':
drivers/net/mtk_eth.c:856:21: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
flush_dcache_range((u32)pkt_base, (u32)(pkt_base + TOTAL_PKT_BUF_SIZE));
^
drivers/net/mtk_eth.c:856:36: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
^
drivers/net/mtk_eth.c: In function 'mtk_eth_send':
drivers/net/mtk_eth.c:968:21: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
flush_dcache_range((u32)pkt_base, (u32)pkt_base +
drivers/net/mtk_eth.c:968:36: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
drivers/net/mtk_eth.c: In function 'mtk_eth_recv':
drivers/net/mtk_eth.c:994:26: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
invalidate_dcache_range((u32)pkt_base, (u32)pkt_base +
^
drivers/net/mtk_eth.c:994:41: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
^
drivers/net/mtk_eth.c: In function 'mtk_eth_probe':
drivers/net/mtk_eth.c:1026:18: error: cast to pointer from integer of different
size [-Werror=int-to-pointer-cast]
priv->fe_base = (void *)iobase;
^
drivers/net/mtk_eth.c:1029:20: error: cast to pointer from integer of different
size [-Werror=int-to-pointer-cast]
priv->gmac_base = (void *)(iobase + GMAC_BASE);
Fixes: 23f17164d9 ("ethernet: MediaTek: add ethernet driver for MediaTek
ARM-based SoCs")
Signed-off-by: Frank Wunderlich
---
drivers/net/mtk_eth.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
index 6cffc3f32a..5ff3a209f4 100644
--- a/drivers/net/mtk_eth.c
+++ b/drivers/net/mtk_eth.c
@@ -853,7 +853,7 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv *priv)
memset(priv->rx_ring_noc, 0, NUM_RX_DESC * sizeof(struct pdma_rxdesc));
memset(priv->pkt_pool, 0, TOTAL_PKT_BUF_SIZE);
- flush_dcache_range((u32)pkt_base, (u32)(pkt_base + TOTAL_PKT_BUF_SIZE));
+ flush_dcache_range((int)pkt_base, (int)(pkt_base + TOTAL_PKT_BUF_SIZE));
priv->rx_dma_owner_idx0 = 0;
priv->tx_cpu_owner_idx0 = 0;
@@ -965,7 +965,7 @@ static int mtk_eth_send(struct udevice *dev, void *packet,
int length)
pkt_base = (void *)phys_to_virt(priv->tx_ring_noc[idx].txd_info1.SDP0);
memcpy(pkt_base, packet, length);
- flush_dcache_range((u32)pkt_base, (u32)pkt_base +
+ flush_dcache_range((int)pkt_base, (int)pkt_base +
roundup(length, ARCH_DMA_MINALIGN));
priv->tx_ring_noc[idx].txd_info2.SDL0 = length;
@@ -991,8 +991,8 @@ static int mtk_eth_recv(struct udevice *dev, int flags,
uchar **packetp)
length = priv->rx_ring_noc[idx].rxd_info2.PLEN0;
pkt_base = (void *)phys_to_virt(priv->rx_ring_noc[idx].rxd_info1.PDP0);
- invalidate_dcache_range((u32)pkt_base, (u32)pkt_base +
- roundup(length, ARCH_DMA_MINALIGN));
+ invalidate_dcache_range((int)pkt_base, (unsigned int)(pkt_base +
+ roundup(length, ARCH_DMA_MINALIGN)));
if (packetp)
*packetp = pkt_base;
@@ -1019,7 +1019,7 @@ static int mtk_eth_probe(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_platdata(dev);
struct mtk_eth_priv *priv = dev_get_priv(dev);
- u32 iobase = pdata->iobase;
+ unsigned int iobase = pdata->iobase;
int ret;
/* Frame Engine Register Base */
--
2.17.1
[PATCH resend 2/2] gpio: mpc8xxx: don't do RMW on gpdat register when setting value
The driver correctly handles reading back the value of an output gpio
by reading from the shadow register for output, and from gpdat for
inputs.
Unfortunately, when setting the value of some gpio, we do a RMW cycle
on the gpdat register without taking the shadow register into account,
thus accidentally setting other output gpios (at least those whose
value cannot be read back) to 0 at the same time.
When changing a gpio from input to output, we still need to make sure
it initially has the requested value. So, the procedure is
- update the shadow register
- compute the new gpdir register
- write the bitwise and of the shadow and new gpdir register to gpdat
- write the new gpdir register
Signed-off-by: Rasmus Villemoes
---
drivers/gpio/mpc8xxx_gpio.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/mpc8xxx_gpio.c b/drivers/gpio/mpc8xxx_gpio.c
index 5438196fe0..c5be8e673b 100644
--- a/drivers/gpio/mpc8xxx_gpio.c
+++ b/drivers/gpio/mpc8xxx_gpio.c
@@ -57,20 +57,6 @@ static inline u32 mpc8xxx_gpio_get_dir(struct ccsr_gpio
*base, u32 mask)
return in_be32(>gpdir) & mask;
}
-static inline void mpc8xxx_gpio_set_low(struct ccsr_gpio *base, u32 gpios)
-{
- clrbits_be32(>gpdat, gpios);
- /* GPDIR register 1 -> output */
- setbits_be32(>gpdir, gpios);
-}
-
-static inline void mpc8xxx_gpio_set_high(struct ccsr_gpio *base, u32 gpios)
-{
- setbits_be32(>gpdat, gpios);
- /* GPDIR register 1 -> output */
- setbits_be32(>gpdir, gpios);
-}
-
static inline int mpc8xxx_gpio_open_drain_val(struct ccsr_gpio *base, u32 mask)
{
return in_be32(>gpodr) & mask;
@@ -104,14 +90,21 @@ static int mpc8xxx_gpio_direction_input(struct udevice
*dev, uint gpio)
static int mpc8xxx_gpio_set_value(struct udevice *dev, uint gpio, int value)
{
struct mpc8xxx_gpio_data *data = dev_get_priv(dev);
+ struct ccsr_gpio *base = data->base;
+ u32 mask = gpio_mask(gpio);
+ u32 gpdir;
if (value) {
- data->dat_shadow |= gpio_mask(gpio);
- mpc8xxx_gpio_set_high(data->base, gpio_mask(gpio));
+ data->dat_shadow |= mask;
} else {
- data->dat_shadow &= ~gpio_mask(gpio);
- mpc8xxx_gpio_set_low(data->base, gpio_mask(gpio));
+ data->dat_shadow &= ~mask;
}
+
+ gpdir = in_be32(>gpdir);
+ gpdir |= gpio_mask(gpio);
+ out_be32(>gpdat, gpdir & data->dat_shadow);
+ out_be32(>gpdir, gpdir);
+
return 0;
}
--
2.23.0
[PATCH resend 1/2] gpio: mpc8xxx: don't modify gpdat when setting gpio as input
Since some chips don't support reading back the value of output gpios
from the gpdat register, we should not do a RMW cycle (i.e., the
clrbits_be32) on the gpdat register when setting a gpio as input, as
that might accidentally change the value of some other (still
configured as output) gpio.
The extra indirection through mpc8xxx_gpio_set_in() does not help
readability, so just fold the gpdir update into
mpc8xxx_gpio_direction_input().
Signed-off-by: Rasmus Villemoes
---
drivers/gpio/mpc8xxx_gpio.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/mpc8xxx_gpio.c b/drivers/gpio/mpc8xxx_gpio.c
index 9964d69035..5438196fe0 100644
--- a/drivers/gpio/mpc8xxx_gpio.c
+++ b/drivers/gpio/mpc8xxx_gpio.c
@@ -57,13 +57,6 @@ static inline u32 mpc8xxx_gpio_get_dir(struct ccsr_gpio
*base, u32 mask)
return in_be32(>gpdir) & mask;
}
-static inline void mpc8xxx_gpio_set_in(struct ccsr_gpio *base, u32 gpios)
-{
- clrbits_be32(>gpdat, gpios);
- /* GPDIR register 0 -> input */
- clrbits_be32(>gpdir, gpios);
-}
-
static inline void mpc8xxx_gpio_set_low(struct ccsr_gpio *base, u32 gpios)
{
clrbits_be32(>gpdat, gpios);
@@ -100,8 +93,11 @@ static inline void mpc8xxx_gpio_open_drain_off(struct
ccsr_gpio *base,
static int mpc8xxx_gpio_direction_input(struct udevice *dev, uint gpio)
{
struct mpc8xxx_gpio_data *data = dev_get_priv(dev);
+ u32 mask = gpio_mask(gpio);
+
+ /* GPDIR register 0 -> input */
+ clrbits_be32(>base->gpdir, mask);
- mpc8xxx_gpio_set_in(data->base, gpio_mask(gpio));
return 0;
}
--
2.23.0
[PATCH resend 0/2] gpio: mpc8xxx: honour shadow register when writing gpdat
[resending with Mario's correct address, sorry for the double post] The driver correctly uses the shadow register when asked for the current value of an output gpio. Unfortunately, it does RMW on the gpdat register both when setting a gpio as input and output. These two patches fix that. Aside: Apparently, the mpc8309 also partially suffers from the errata preventing outputs from being read back - the bits corresponding to gpios 0-7 are always read as 0, while at least the value of gpio10 is correctly reflected when reading gpdat. Which is how I noticed these bugs - I couldn't understand why turning one LED on would turn off another. Rasmus Villemoes (2): gpio: mpc8xxx: don't modify gpdat when setting gpio as input gpio: mpc8xxx: don't do RMW on gpdat register when setting value drivers/gpio/mpc8xxx_gpio.c | 41 ++--- 1 file changed, 15 insertions(+), 26 deletions(-) -- 2.23.0
Aw: Re: [U-boot,4/4] configs: mediatek: enable mt7622 ethernet support
Hi tom, thanks for testing imho the first 3 can be fixed by this: diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c index 6cffc3f32a..d13020a624 100644 --- a/drivers/net/mtk_eth.c +++ b/drivers/net/mtk_eth.c @@ -853,7 +853,7 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv *priv) memset(priv->rx_ring_noc, 0, NUM_RX_DESC * sizeof(struct pdma_rxdesc)); memset(priv->pkt_pool, 0, TOTAL_PKT_BUF_SIZE); - flush_dcache_range((u32)pkt_base, (u32)(pkt_base + TOTAL_PKT_BUF_SIZE)); + flush_dcache_range((int)pkt_base, (int)(pkt_base + TOTAL_PKT_BUF_SIZE)); priv->rx_dma_owner_idx0 = 0; priv->tx_cpu_owner_idx0 = 0; @@ -965,7 +965,7 @@ static int mtk_eth_send(struct udevice *dev, void *packet, int length) pkt_base = (void *)phys_to_virt(priv->tx_ring_noc[idx].txd_info1.SDP0); memcpy(pkt_base, packet, length); - flush_dcache_range((u32)pkt_base, (u32)pkt_base + + flush_dcache_range((int)pkt_base, (int)pkt_base + roundup(length, ARCH_DMA_MINALIGN)); priv->tx_ring_noc[idx].txd_info2.SDL0 = length; @@ -991,8 +991,8 @@ static int mtk_eth_recv(struct udevice *dev, int flags, uchar **packetp) length = priv->rx_ring_noc[idx].rxd_info2.PLEN0; pkt_base = (void *)phys_to_virt(priv->rx_ring_noc[idx].rxd_info1.PDP0); - invalidate_dcache_range((u32)pkt_base, (u32)pkt_base + - roundup(length, ARCH_DMA_MINALIGN)); + invalidate_dcache_range((int)pkt_base, (unsigned int)(pkt_base + + roundup(length, ARCH_DMA_MINALIGN))); if (packetp) *packetp = pkt_base; did not get the last 2 (after fixing the first 3)... i can send full patch if it's ok regards Frank > Gesendet: Montag, 27. Januar 2020 um 19:49 Uhr > Von: "Tom Rini" > An: MarkLee > Cc: "Albert Aribaud" , "Ryder Lee" > , "Steven Liu" , "Joe > Hershberger" , u-boot@lists.denx.de, > GSS_MTK_Uboot_upstream > Betreff: Re: [U-boot,4/4] configs: mediatek: enable mt7622 ethernet support > > On Tue, Jan 21, 2020 at 07:32:00PM +0800, MarkLee wrote: > > > This patch enable mt7622 ethernet support in its defconfig > > > > Signed-off-by: MarkLee > > --- > > configs/mt7622_rfb_defconfig | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/configs/mt7622_rfb_defconfig b/configs/mt7622_rfb_defconfig > > index e1917e70e7..806087a3d6 100644 > > --- a/configs/mt7622_rfb_defconfig > > +++ b/configs/mt7622_rfb_defconfig > > @@ -34,6 +34,10 @@ CONFIG_SPI_FLASH_SPANSION=y > > CONFIG_SPI_FLASH_STMICRO=y > > CONFIG_SPI_FLASH_WINBOND=y > > CONFIG_DM_ETH=y > > +CONFIG_PHY_FIXED=y > > +CONFIG_MEDIATEK_ETH=y > > +CONFIG_NET_RANDOM_ETHADDR=y > > +CONFIG_CMD_PING=y > > CONFIG_PINCTRL=y > > CONFIG_PINCONF=y > > CONFIG_PINCTRL_MT7622=y > > This leads to warnings in the ethernet driver: > drivers/net/mtk_eth.c: In function 'mtk_eth_fifo_init': > drivers/net/mtk_eth.c:856:21: error: cast from pointer to integer of > different size [-Werror=pointer-to-int-cast] > flush_dcache_range((u32)pkt_base, (u32)(pkt_base + TOTAL_PKT_BUF_SIZE)); > ^ > drivers/net/mtk_eth.c:856:36: error: cast from pointer to integer of > different size [-Werror=pointer-to-int-cast] > ^ > drivers/net/mtk_eth.c: In function 'mtk_eth_send': > drivers/net/mtk_eth.c:968:21: error: cast from pointer to integer of > different size [-Werror=pointer-to-int-cast] > flush_dcache_range((u32)pkt_base, (u32)pkt_base + > drivers/net/mtk_eth.c:968:36: error: cast from pointer to integer of > different size [-Werror=pointer-to-int-cast] > drivers/net/mtk_eth.c: In function 'mtk_eth_recv': > drivers/net/mtk_eth.c:994:26: error: cast from pointer to integer of > different size [-Werror=pointer-to-int-cast] > invalidate_dcache_range((u32)pkt_base, (u32)pkt_base + > ^ > drivers/net/mtk_eth.c:994:41: error: cast from pointer to integer of > different size [-Werror=pointer-to-int-cast] > ^ > drivers/net/mtk_eth.c: In function 'mtk_eth_probe': > drivers/net/mtk_eth.c:1026:18: error: cast to pointer from integer of > different size [-Werror=int-to-pointer-cast] > priv->fe_base = (void *)iobase; > ^ > drivers/net/mtk_eth.c:1029:20: error: cast to pointer from integer of > different size [-Werror=int-to-pointer-cast] > priv->gmac_base = (void *)(iobase + GMAC_BASE); > > -- > Tom >
[PATCH] mx6slevk: Convert to DM_ETH
This fixes the following warning:
= WARNING ==
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
Signed-off-by: Pedro Jardim
---
board/freescale/mx6slevk/mx6slevk.c | 30 -
configs/mx6slevk_defconfig | 2 ++
include/configs/mx6slevk.h | 5 +
3 files changed, 3 insertions(+), 34 deletions(-)
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index 453f281418..f104f9930a 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -21,7 +21,6 @@
#include
#include
#include
-#include
#include
#include
#include "../common/pfuze.h"
@@ -102,34 +101,11 @@ static iomux_v3_cfg_t const usdhc3_pads[] = {
};
#endif
-static iomux_v3_cfg_t const fec_pads[] = {
- MX6_PAD_FEC_MDC__FEC_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_MDIO__FEC_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_CRS_DV__FEC_RX_DV | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_RXD0__FEC_RX_DATA0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_RXD1__FEC_RX_DATA1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_TX_EN__FEC_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_TXD0__FEC_TX_DATA0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_TXD1__FEC_TX_DATA1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_REF_CLK__FEC_REF_OUT | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_FEC_RX_ER__GPIO_4_19 | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_FEC_TX_CLK__GPIO_4_21 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
static void setup_iomux_uart(void)
{
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
}
-static void setup_iomux_fec(void)
-{
- imx_iomux_v3_setup_multiple_pads(fec_pads, ARRAY_SIZE(fec_pads));
-
- /* Power up LAN8720 PHY */
- gpio_request(ETH_PHY_POWER, "eth_pwr");
- gpio_direction_output(ETH_PHY_POWER , 1);
- udelay(15000);
-}
int board_mmc_get_env_dev(int devno)
{
@@ -179,12 +155,6 @@ int power_init_board(void)
#endif
#ifdef CONFIG_FEC_MXC
-int board_eth_init(bd_t *bis)
-{
- setup_iomux_fec();
-
- return cpu_eth_init(bis);
-}
static int setup_fec(void)
{
diff --git a/configs/mx6slevk_defconfig b/configs/mx6slevk_defconfig
index a0f9df1f5f..2df1430a92 100644
--- a/configs/mx6slevk_defconfig
+++ b/configs/mx6slevk_defconfig
@@ -61,3 +61,5 @@ CONFIG_DM_USB=y
CONFIG_USB_STORAGE=y
CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
+CONFIG_DM_ETH=y
+CONFIG_FEC_MXC=y
diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
index 6b2a174e7a..db5f9bcb60 100644
--- a/include/configs/mx6slevk.h
+++ b/include/configs/mx6slevk.h
@@ -32,10 +32,11 @@
#define CONFIG_SYS_I2C_MXC_I2C3/* enable I2C bus 3 */
#define CONFIG_SYS_I2C_SPEED 10
-#define CONFIG_FEC_MXC
-#define IMX_FEC_BASE ENET_BASE_ADDR
-#define CONFIG_FEC_XCV_TYPERMII
-#define CONFIG_FEC_MXC_PHYADDR 0
+#define CONFIG_ETHPRIME"eth0"
#define CONFIG_PHY_SMSC
--
2.17.1
Re: [PATCH 8/9] doc: add board documentation for stm32mp1
On 1/28/20 10:11 AM, Patrick Delaunay wrote: Change plain test README to rst format and move this file in documentation directory. Signed-off-by: Patrick Delaunay When I apply only this patch to origin/master: git am /tmp/1.patch Applying: doc: add board documentation for stm32mp1 error: patch failed: board/st/stm32mp1/README:1 error: board/st/stm32mp1/README: patch does not apply .git/rebase-apply/patch:1164: new blank line at EOF. Maybe this patch will have to be rebased. --- board/st/stm32mp1/README | 520 + doc/board/index.rst | 1 + doc/board/st/index.rst| 9 + doc/board/st/stm32mp1.rst | 598 ++ 4 files changed, 609 insertions(+), 519 deletions(-) create mode 100644 doc/board/st/index.rst create mode 100644 doc/board/st/stm32mp1.rst diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README index 5d7465a8c8..8172d26a66 100644 --- a/board/st/stm32mp1/README +++ b/board/st/stm32mp1/README @@ -1,519 +1 @@ -SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause -# -# Copyright (C) 2018 STMicroelectronics - All Rights Reserved -# - -U-Boot on STMicroelectronics STM32MP15x -=== - -1. Summary -== -This is a quick instruction for setup stm32mp1 boards. - -2. Supported devices - -U-Boot supports STMP32MP15x SoCs: STM32MP157, STM32MP153 and STM32MP151 - -The STM32MP15x is a Cortex-A MPU aimed at various applications. -It features: -- Dual core Cortex-A7 application core (Single on STM32MP151) -- 2D/3D image composition with GPU (only on STM32MP157) -- Standard memories interface support -- Standard connectivity, widely inherited from the STM32 MCU family -- Comprehensive security support - -Everything is supported in Linux but U-Boot is limited to: -1. UART -2. SDCard/MMC controller (SDMMC) -3. NAND controller (FMC) -4. NOR controller (QSPI) -5. USB controller (OTG DWC2) -6. Ethernet controller - -And the necessary drivers -1. I2C -2. STPMIC1 (PMIC and regulator) -3. Clock, Reset, Sysreset -4. Fuse - -Currently the following boards are supported: -+ stm32mp157a-avenger96.dts -+ stm32mp157a-dk1.dts -+ stm32mp157c-dk2.dts -+ stm32mp157c-ed1.dts -+ stm32mp157c-ev1.dts - -3. Boot Sequences -= - -BootRom => FSBL in SYSRAM => SSBL in DDR => OS (Linux Kernel) - -with FSBL = First Stage Bootloader - SSBL = Second Stage Bootloader - -3 boot configurations are supported: - -1) The "Trusted" boot chain (defconfig_file : stm32mp15_trusted_defconfig) - BootRom => FSBL = Trusted Firmware-A (TF-A) => SSBL = U-Boot - TF-A performs a full initialization of Secure peripherals and installs a - secure monitor. - U-Boot is running in normal world and uses TF-A monitor - to access to secure resources. - -2) The "Trusted" boot chain with OP-TEE - (defconfig_file : stm32mp15_optee_defconfig) - BootRom => FSBL = Trusted Firmware-A (TF-A) => SSBL = U-Boot - TF-A performs a full initialization of Secure peripherals and installs OP-TEE - from specific partitions (teeh, teed, teex). - U-Boot is running in normal world and uses OP-TEE monitor to access - to secure resources. - -3) The "Basic" boot chain (defconfig_file : stm32mp15_basic_defconfig) - BootRom => FSBL = U-Boot SPL => SSBL = U-Boot - SPL has limited security initialisation - U-Boot is running in secure mode and provide a secure monitor to the kernel - with only PSCI support (Power State Coordination Interface defined by ARM). - -All the STM32MP15x boards supported by U-Boot use the same generic board -stm32mp1 which support all the bootable devices. - -Each board is configurated only with the associated device tree. - -4. Device Tree Selection - - -You need to select the appropriate device tree for your board, -the supported device trees for stm32mp157 are: - -+ ev1: eval board with pmic stpmic1 (ev1 = mother board + daughter ed1) - dts: stm32mp157c-ev1 - -+ ed1: daughter board with pmic stpmic1 - dts: stm32mp157c-ed1 - -+ dk1: Discovery board - dts: stm32mp157a-dk1 - -+ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel - dts: stm32mp157c-dk2 - -+ avenger96: Avenger96 board from Arrow Electronics - dts: stm32mp157a-avenger96 - -5. Build Procedure -== - -1. Install required tools for U-Boot - - + install package needed in U-Boot makefile - (libssl-dev, swig, libpython-dev...) - + install ARMv7 toolchain for 32bit Cortex-A (from Linaro, - from SDK for STM32MP15x, or any crosstoolchains from your distribution) - -2. Set the cross compiler: - - # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi- - (you can use any gcc cross compiler compatible with U-Boot) - -3. Select the output directory (optional) - - # export KBUILD_OUTPUT=/path/to/output - - for example: use one output directory for each configuration - # export KBUILD_OUTPUT=stm32mp15_trusted -
Re: [PATCH v4 6/6] config: enable DFU over USB on Raspberry Pi4 boards
On 1/28/20 8:20 PM, Matthias Brugger wrote: > > > On 02/12/2019 12:11, Marek Szyprowski wrote: >> Enable support for DFU over USB. This requires to enable USB gadget, >> DWC2 UDC OTG driver and DFU command. DFU entities are defined for the >> following firmware objects: u-boot.bin, uboot.env, config.txt, and >> zImage/Image. >> >> Signed-off-by: Marek Szyprowski >> Reviewed-by: Lukasz Majewski >> --- >> configs/rpi_4_32b_defconfig | 11 +++ >> configs/rpi_4_defconfig | 11 +++ > > In the meanwhile we have a third config rpi_arm64_defconfig > > does it make sense to add DFU support there too? > I suppose it works on RPi3 as well. If so, would you mind to send a follow-up > patch? As i know, RPI3's HW doesn't support. SO it doesn't need to apply this patch on RPI3. Best Regards, Jaehoon Chung > > Regards, > Matthias > >> include/configs/rpi.h | 20 >> 3 files changed, 42 insertions(+) >> >> diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig >> index 7ff390cd24..9d0515029c 100644 >> --- a/configs/rpi_4_32b_defconfig >> +++ b/configs/rpi_4_32b_defconfig >> @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y >> # CONFIG_DISPLAY_CPUINFO is not set >> # CONFIG_DISPLAY_BOARDINFO is not set >> CONFIG_SYS_PROMPT="U-Boot> " >> +CONFIG_CMD_DFU=y >> # CONFIG_CMD_FLASH is not set >> CONFIG_CMD_GPIO=y >> CONFIG_CMD_MMC=y >> @@ -21,6 +22,7 @@ CONFIG_ENV_FAT_INTERFACE="mmc" >> CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" >> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >> CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y >> +CONFIG_DFU_MMC=y >> CONFIG_DM_KEYBOARD=y >> CONFIG_DM_MMC=y >> CONFIG_MMC_SDHCI=y >> @@ -28,6 +30,15 @@ CONFIG_MMC_SDHCI_BCM2835=y >> CONFIG_PINCTRL=y >> # CONFIG_PINCTRL_GENERIC is not set >> # CONFIG_REQUIRE_SERIAL_CONSOLE is not set >> +CONFIG_USB=y >> +CONFIG_DM_USB=y >> +CONFIG_DM_USB_GADGET=y >> +CONFIG_USB_GADGET=y >> +CONFIG_USB_GADGET_MANUFACTURER="FSL" >> +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >> +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 >> +CONFIG_USB_GADGET_DWC2_OTG=y >> +CONFIG_USB_GADGET_DOWNLOAD=y >> CONFIG_DM_VIDEO=y >> CONFIG_SYS_WHITE_ON_BLACK=y >> CONFIG_CONSOLE_SCROLL_LINES=10 >> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig >> index c5089eb9c8..3d660d182a 100644 >> --- a/configs/rpi_4_defconfig >> +++ b/configs/rpi_4_defconfig >> @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y >> # CONFIG_DISPLAY_CPUINFO is not set >> # CONFIG_DISPLAY_BOARDINFO is not set >> CONFIG_SYS_PROMPT="U-Boot> " >> +CONFIG_CMD_DFU=y >> # CONFIG_CMD_FLASH is not set >> CONFIG_CMD_GPIO=y >> CONFIG_CMD_MMC=y >> @@ -21,6 +22,7 @@ CONFIG_ENV_FAT_INTERFACE="mmc" >> CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" >> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >> CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y >> +CONFIG_DFU_MMC=y >> CONFIG_DM_KEYBOARD=y >> CONFIG_DM_MMC=y >> CONFIG_MMC_SDHCI=y >> @@ -28,6 +30,15 @@ CONFIG_MMC_SDHCI_BCM2835=y >> CONFIG_PINCTRL=y >> # CONFIG_PINCTRL_GENERIC is not set >> # CONFIG_REQUIRE_SERIAL_CONSOLE is not set >> +CONFIG_USB=y >> +CONFIG_DM_USB=y >> +CONFIG_DM_USB_GADGET=y >> +CONFIG_USB_GADGET=y >> +CONFIG_USB_GADGET_MANUFACTURER="FSL" >> +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >> +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 >> +CONFIG_USB_GADGET_DWC2_OTG=y >> +CONFIG_USB_GADGET_DOWNLOAD=y >> CONFIG_DM_VIDEO=y >> CONFIG_SYS_WHITE_ON_BLACK=y >> CONFIG_CONSOLE_SCROLL_LINES=10 >> diff --git a/include/configs/rpi.h b/include/configs/rpi.h >> index 83e258a6b9..b53a4b65d0 100644 >> --- a/include/configs/rpi.h >> +++ b/include/configs/rpi.h >> @@ -74,6 +74,25 @@ >> #define CONFIG_TFTP_TSIZE >> #endif >> >> +/* DFU over USB/UDC */ >> +#ifdef CONFIG_CMD_DFU >> +#define CONFIG_SYS_DFU_DATA_BUF_SIZESZ_1M >> +#define CONFIG_SYS_DFU_MAX_FILE_SIZESZ_2M >> + >> +#ifdef CONFIG_ARM64 >> +#define KERNEL_FILENAME "Image" >> +#else >> +#define KERNEL_FILENAME "zImage" >> +#endif >> + >> +#define ENV_DFU_SETTINGS \ >> +"dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;" \ >> + "config.txt fat 0 1;" \ >> + KERNEL_FILENAME " fat 0 1\0" >> +#else >> +#define ENV_DFU_SETTINGS "" >> +#endif >> + >> /* Console configuration */ >> #define CONFIG_SYS_CBSIZE 1024 >> >> @@ -188,6 +207,7 @@ >> #define CONFIG_EXTRA_ENV_SETTINGS \ >> "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ >> ENV_DEVICE_SETTINGS \ >> +ENV_DFU_SETTINGS \ >> ENV_MEM_LAYOUT_SETTINGS \ >> BOOTENV >> >> > >
Re: [PATCH v4 6/6] config: enable DFU over USB on Raspberry Pi4 boards
On 02/12/2019 12:11, Marek Szyprowski wrote: > Enable support for DFU over USB. This requires to enable USB gadget, > DWC2 UDC OTG driver and DFU command. DFU entities are defined for the > following firmware objects: u-boot.bin, uboot.env, config.txt, and > zImage/Image. > > Signed-off-by: Marek Szyprowski > Reviewed-by: Lukasz Majewski > --- > configs/rpi_4_32b_defconfig | 11 +++ > configs/rpi_4_defconfig | 11 +++ In the meanwhile we have a third config rpi_arm64_defconfig does it make sense to add DFU support there too? I suppose it works on RPi3 as well. If so, would you mind to send a follow-up patch? Regards, Matthias > include/configs/rpi.h | 20 > 3 files changed, 42 insertions(+) > > diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig > index 7ff390cd24..9d0515029c 100644 > --- a/configs/rpi_4_32b_defconfig > +++ b/configs/rpi_4_32b_defconfig > @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y > # CONFIG_DISPLAY_CPUINFO is not set > # CONFIG_DISPLAY_BOARDINFO is not set > CONFIG_SYS_PROMPT="U-Boot> " > +CONFIG_CMD_DFU=y > # CONFIG_CMD_FLASH is not set > CONFIG_CMD_GPIO=y > CONFIG_CMD_MMC=y > @@ -21,6 +22,7 @@ CONFIG_ENV_FAT_INTERFACE="mmc" > CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y > +CONFIG_DFU_MMC=y > CONFIG_DM_KEYBOARD=y > CONFIG_DM_MMC=y > CONFIG_MMC_SDHCI=y > @@ -28,6 +30,15 @@ CONFIG_MMC_SDHCI_BCM2835=y > CONFIG_PINCTRL=y > # CONFIG_PINCTRL_GENERIC is not set > # CONFIG_REQUIRE_SERIAL_CONSOLE is not set > +CONFIG_USB=y > +CONFIG_DM_USB=y > +CONFIG_DM_USB_GADGET=y > +CONFIG_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="FSL" > +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > +CONFIG_USB_GADGET_DWC2_OTG=y > +CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_DM_VIDEO=y > CONFIG_SYS_WHITE_ON_BLACK=y > CONFIG_CONSOLE_SCROLL_LINES=10 > diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig > index c5089eb9c8..3d660d182a 100644 > --- a/configs/rpi_4_defconfig > +++ b/configs/rpi_4_defconfig > @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y > # CONFIG_DISPLAY_CPUINFO is not set > # CONFIG_DISPLAY_BOARDINFO is not set > CONFIG_SYS_PROMPT="U-Boot> " > +CONFIG_CMD_DFU=y > # CONFIG_CMD_FLASH is not set > CONFIG_CMD_GPIO=y > CONFIG_CMD_MMC=y > @@ -21,6 +22,7 @@ CONFIG_ENV_FAT_INTERFACE="mmc" > CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y > +CONFIG_DFU_MMC=y > CONFIG_DM_KEYBOARD=y > CONFIG_DM_MMC=y > CONFIG_MMC_SDHCI=y > @@ -28,6 +30,15 @@ CONFIG_MMC_SDHCI_BCM2835=y > CONFIG_PINCTRL=y > # CONFIG_PINCTRL_GENERIC is not set > # CONFIG_REQUIRE_SERIAL_CONSOLE is not set > +CONFIG_USB=y > +CONFIG_DM_USB=y > +CONFIG_DM_USB_GADGET=y > +CONFIG_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="FSL" > +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > +CONFIG_USB_GADGET_DWC2_OTG=y > +CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_DM_VIDEO=y > CONFIG_SYS_WHITE_ON_BLACK=y > CONFIG_CONSOLE_SCROLL_LINES=10 > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > index 83e258a6b9..b53a4b65d0 100644 > --- a/include/configs/rpi.h > +++ b/include/configs/rpi.h > @@ -74,6 +74,25 @@ > #define CONFIG_TFTP_TSIZE > #endif > > +/* DFU over USB/UDC */ > +#ifdef CONFIG_CMD_DFU > +#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_1M > +#define CONFIG_SYS_DFU_MAX_FILE_SIZE SZ_2M > + > +#ifdef CONFIG_ARM64 > +#define KERNEL_FILENAME "Image" > +#else > +#define KERNEL_FILENAME "zImage" > +#endif > + > +#define ENV_DFU_SETTINGS \ > + "dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;" \ > + "config.txt fat 0 1;" \ > + KERNEL_FILENAME " fat 0 1\0" > +#else > +#define ENV_DFU_SETTINGS "" > +#endif > + > /* Console configuration */ > #define CONFIG_SYS_CBSIZE1024 > > @@ -188,6 +207,7 @@ > #define CONFIG_EXTRA_ENV_SETTINGS \ > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > ENV_DEVICE_SETTINGS \ > + ENV_DFU_SETTINGS \ > ENV_MEM_LAYOUT_SETTINGS \ > BOOTENV > >
[PATCH 2/2] gpio: mpc8xxx: don't do RMW on gpdat register when setting value
The driver correctly handles reading back the value of an output gpio
by reading from the shadow register for output, and from gpdat for
inputs.
Unfortunately, when setting the value of some gpio, we do a RMW cycle
on the gpdat register without taking the shadow register into account,
thus accidentally setting other output gpios (at least those whose
value cannot be read back) to 0 at the same time.
When changing a gpio from input to output, we still need to make sure
it initially has the requested value. So, the procedure is
- update the shadow register
- compute the new gpdir register
- write the bitwise and of the shadow and new gpdir register to gpdat
- write the new gpdir register
Signed-off-by: Rasmus Villemoes
---
drivers/gpio/mpc8xxx_gpio.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/mpc8xxx_gpio.c b/drivers/gpio/mpc8xxx_gpio.c
index 5438196fe0..c5be8e673b 100644
--- a/drivers/gpio/mpc8xxx_gpio.c
+++ b/drivers/gpio/mpc8xxx_gpio.c
@@ -57,20 +57,6 @@ static inline u32 mpc8xxx_gpio_get_dir(struct ccsr_gpio
*base, u32 mask)
return in_be32(>gpdir) & mask;
}
-static inline void mpc8xxx_gpio_set_low(struct ccsr_gpio *base, u32 gpios)
-{
- clrbits_be32(>gpdat, gpios);
- /* GPDIR register 1 -> output */
- setbits_be32(>gpdir, gpios);
-}
-
-static inline void mpc8xxx_gpio_set_high(struct ccsr_gpio *base, u32 gpios)
-{
- setbits_be32(>gpdat, gpios);
- /* GPDIR register 1 -> output */
- setbits_be32(>gpdir, gpios);
-}
-
static inline int mpc8xxx_gpio_open_drain_val(struct ccsr_gpio *base, u32 mask)
{
return in_be32(>gpodr) & mask;
@@ -104,14 +90,21 @@ static int mpc8xxx_gpio_direction_input(struct udevice
*dev, uint gpio)
static int mpc8xxx_gpio_set_value(struct udevice *dev, uint gpio, int value)
{
struct mpc8xxx_gpio_data *data = dev_get_priv(dev);
+ struct ccsr_gpio *base = data->base;
+ u32 mask = gpio_mask(gpio);
+ u32 gpdir;
if (value) {
- data->dat_shadow |= gpio_mask(gpio);
- mpc8xxx_gpio_set_high(data->base, gpio_mask(gpio));
+ data->dat_shadow |= mask;
} else {
- data->dat_shadow &= ~gpio_mask(gpio);
- mpc8xxx_gpio_set_low(data->base, gpio_mask(gpio));
+ data->dat_shadow &= ~mask;
}
+
+ gpdir = in_be32(>gpdir);
+ gpdir |= gpio_mask(gpio);
+ out_be32(>gpdat, gpdir & data->dat_shadow);
+ out_be32(>gpdir, gpdir);
+
return 0;
}
--
2.23.0
Re: [PATCH v4 0/6] Raspberry Pi4: add support for DFU over USB
On 27/01/2020 23:36, Lukasz Majewski wrote:
> Hi Matthias,
>
> Do you plan to pull this patch series to RPI repository?
>
> I'm asking as it contains some DFU related patches (Acked already by
> me), which I would like to see pulled in this merge window.
>
Yes I was waiting on the first to patches for FAT as Tom asked to add a test. So
I'm reluctant to take these two. I can take the rest of the series though.
Regards,
Matthias
> Thanks in advance for your help :-)
>
>> Hi All!
>>
>> This patchset enables support for DFU over USB protocol on Raspberry
>> Pi4 board. The board has DWC2 UDC controller connected to the USB-C
>> power connector. Enabling DFU on it, make the u-boot development much
>> more convenient, as one no longer needs to swap SD-card between RPi4
>> board and host machine to update the u-boot binary.
>>
>> Patches are based on current 'master' u-boot branch. They were tested
>> on the 2019-07-10-raspbian-buster-lite.img sd-card image with the
>> following lines added to config.txt:
>> dtoverlay=dwc2,dr_mode=peripheral
>> dtparam=i2c_arm=on
>> dtparam=spi=on
>> enable_uart=1
>> uart_2ndstage=1
>> kernel=u-boot.bin
>>
>> To enable DFU, one has to enter follwing command:
>> # dfu 0 mmc 0
>>
>> During the development of this feature I've encountered a serious bugs
>> in FAT write code. Over-writing discontiguous files always caused
>> serious filesystem corruption. This was especially anoying, because
>> the system environment is kept on FAT volume in uboot.env file, so
>> 'saveenv' basically corrupted the boot partiting on the second call.
>> Another bunch of the issues in the FAT write code has been revealed
>> while removing predefined file size limit in DFU MMC code and then
>> running sandbox tests.
>>
>> I hope that my fixes for FAT code will be helpful for non-RPi users
>> too.
>>
>> Best regards
>> Marek Szyprowski
>> Samsung R Institute Poland
>>
>>
>> Changelog:
>>
>> v4:
>> - rechecked the FAT related fixes, it turned out that much simpler
>> patch fixes both issues discovered while working on DFU support;
>> added simple sandbox based tests reveleaing the issue and showing
>> correctness of the fix
>> - rebased patches onto current u-boot's master branch: 4b19b89ca4a8
>> ("Merge tag 'rpi-next-2020.01' of https://github.com/mbgg/u-boot;)
>>
>> v3: https://patchwork.ozlabs.org/cover/1200793/
>> - fixed one more FAT issue revealed by sandbox tests
>>
>> v3: (patch 6/6 posted separately):
>> https://patchwork.ozlabs.org/patch/1195645/
>> - fixed non-RPi4 builds (missing #else ENV_DFU_SETTINGS def)
>> - removed config.txt entity (not needed in uboot-based boot)
>> - switched arm64 kernel filename to 'Image'
>>
>> v2: https://patchwork.ozlabs.org/cover/1166589/
>> - added changes to rpi_4_defconfig too (arm64 version)
>> - extended DFU entity list by confix.txt, cmdline.txt and Image.gz
>> - fixed missing '\0' at the end of dfu_alt_info env
>> - added reviewed-by tags
>> - added patches for DFU MMC to remove file size limit
>> - added patch for fat write to fix issues on non-zero file offset
>> (revealed by previous patch)
>>
>> v1: https://patchwork.ozlabs.org/cover/1162770/
>> - initial version
>>
>>
>> Patch summary:
>>
>> Marek Szyprowski (6):
>> fat: write: fix broken write to fragmented files
>> fat: write: adjust data written in each partial write
>> dfu: mmc: rearrange the code
>> dfu: mmc: remove file size limit for io operations
>> usb: dwc2_udc_otg: add bcm2835 SoC (Raspberry Pi4) support
>> config: enable DFU over USB on Raspberry Pi4 boards
>>
>> configs/rpi_4_32b_defconfig| 11 +++
>> configs/rpi_4_defconfig| 11 +++
>> drivers/dfu/dfu_mmc.c | 93
>> +- drivers/usb/gadget/dwc2_udc_otg.c |
>> 2 + drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 12 +--
>> fs/fat/fat_write.c | 8 +-
>> include/configs/rpi.h | 20 +
>> 7 files changed, 112 insertions(+), 45 deletions(-)
>>
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
>
[PATCH 0/2] gpio: mpc8xxx: honour shadow register when writing gpdat
The driver correctly uses the shadow register when asked for the current value of an output gpio. Unfortunately, it does RMW on the gpdat register both when setting a gpio as input and output. These two patches fix that. Aside: Apparently, the mpc8309 also partially suffers from the errata preventing outputs from being read back - the bits corresponding to gpios 0-7 are always read as 0, while at least the value of gpio10 is correctly reflected when reading gpdat. Which is how I noticed these bugs - I couldn't understand why turning one LED on would turn off another. Rasmus Villemoes (2): gpio: mpc8xxx: don't modify gpdat when setting gpio as input gpio: mpc8xxx: don't do RMW on gpdat register when setting value drivers/gpio/mpc8xxx_gpio.c | 41 ++--- 1 file changed, 15 insertions(+), 26 deletions(-) -- 2.23.0
[PATCH 1/2] gpio: mpc8xxx: don't modify gpdat when setting gpio as input
Since some chips don't support reading back the value of output gpios
from the gpdat register, we should not do a RMW cycle (i.e., the
clrbits_be32) on the gpdat register when setting a gpio as input, as
that might accidentally change the value of some other (still
configured as output) gpio.
The extra indirection through mpc8xxx_gpio_set_in() does not help
readability, so just fold the gpdir update into
mpc8xxx_gpio_direction_input().
Signed-off-by: Rasmus Villemoes
---
drivers/gpio/mpc8xxx_gpio.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/mpc8xxx_gpio.c b/drivers/gpio/mpc8xxx_gpio.c
index 9964d69035..5438196fe0 100644
--- a/drivers/gpio/mpc8xxx_gpio.c
+++ b/drivers/gpio/mpc8xxx_gpio.c
@@ -57,13 +57,6 @@ static inline u32 mpc8xxx_gpio_get_dir(struct ccsr_gpio
*base, u32 mask)
return in_be32(>gpdir) & mask;
}
-static inline void mpc8xxx_gpio_set_in(struct ccsr_gpio *base, u32 gpios)
-{
- clrbits_be32(>gpdat, gpios);
- /* GPDIR register 0 -> input */
- clrbits_be32(>gpdir, gpios);
-}
-
static inline void mpc8xxx_gpio_set_low(struct ccsr_gpio *base, u32 gpios)
{
clrbits_be32(>gpdat, gpios);
@@ -100,8 +93,11 @@ static inline void mpc8xxx_gpio_open_drain_off(struct
ccsr_gpio *base,
static int mpc8xxx_gpio_direction_input(struct udevice *dev, uint gpio)
{
struct mpc8xxx_gpio_data *data = dev_get_priv(dev);
+ u32 mask = gpio_mask(gpio);
+
+ /* GPDIR register 0 -> input */
+ clrbits_be32(>base->gpdir, mask);
- mpc8xxx_gpio_set_in(data->base, gpio_mask(gpio));
return 0;
}
--
2.23.0
Re: [PATCH] usb: gadget: Handle SPL_* configs
On Tue, 28 Jan 2020 at 20:26, Lukasz Majewski wrote: > > On Tue, 28 Jan 2020 17:50:03 +1000 > Nathan Rossi wrote: > > > On Mon, 27 Jan 2020 at 22:51, Lukasz Majewski wrote: > > > > > > Hi Nathan, > > > > > > > Handle selection of objects based on $(SPL_) to allow for normal > > > > and SPL builds to have differing object compilation. > > > > > > Could you share the exact use case? I do guess that you want to add > > > some gadget(s) to SPL? > > > > I am primarily trying to disable SPL_ENV_SUPPORT for beaglebone > > (am335x_evm). SPL_USB_ETHER has a dependency on SPL_ENV_SUPPORT, thus > > the desire to disable it (whilst leaving SPL_USB_GADGET enabled). > > Ok. > > > > > > > > > (Such changes may cause issues on boards already using this feature > > > - could you run: > > > > > > ./tools/buildman/buildman.py --branch=HEAD siemens samsung bbb > > > --detail --verbose --show_errors --force-build --count=1 > > > --output-dir=./BUILD/ > > > > Running this showed no regressions. Also I noticed "bbb" does not > > refer to any boards? > > I see. Then please try am335x instead. There are no regressions for those boards either. Regards, Nathan > > > > > Thanks, > > Nathan > > > > > > > > > > > > > > > > > > > Signed-off-by: Nathan Rossi > > > > --- > > > > drivers/usb/gadget/Makefile | 8 > > > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/usb/gadget/Makefile > > > > b/drivers/usb/gadget/Makefile index 70f3bf43e7..8967745513 100644 > > > > --- a/drivers/usb/gadget/Makefile > > > > +++ b/drivers/usb/gadget/Makefile > > > > @@ -3,8 +3,8 @@ > > > > # (C) Copyright 2000-2007 > > > > # Wolfgang Denk, DENX Software Engineering, w...@denx.de. > > > > > > > > -obj-$(CONFIG_USB_GADGET) += epautoconf.o config.o usbstring.o > > > > -obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o usbstring.o > > > > +obj-$(CONFIG_$(SPL_)USB_GADGET) += epautoconf.o config.o > > > > usbstring.o +obj-$(CONFIG_$(SPL_)USB_ETHER) += epautoconf.o > > > > config.o usbstring.o > > > > > > > > ifdef CONFIG_SPL_BUILD > > > > obj-$(CONFIG_SPL_USB_GADGET) += g_dnl.o > > > > @@ -13,7 +13,7 @@ obj-$(CONFIG_SPL_USB_SDP_SUPPORT) += f_sdp.o > > > > endif > > > > > > > > # new USB gadget layer dependencies > > > > -ifdef CONFIG_USB_GADGET > > > > +ifdef CONFIG_$(SPL_)USB_GADGET > > > > obj-$(CONFIG_USB_GADGET_AT91) += at91_udc.o > > > > obj-$(CONFIG_USB_GADGET_ATMEL_USBA) += atmel_usba_udc.o > > > > obj-$(CONFIG_USB_GADGET_BCM_UDC_OTG_PHY) += bcm_udc_otg_phy.o > > > > @@ -31,7 +31,7 @@ obj-$(CONFIG_USB_FUNCTION_SDP) += f_sdp.o > > > > obj-$(CONFIG_USB_FUNCTION_ROCKUSB) += f_rockusb.o > > > > endif > > > > endif > > > > -ifdef CONFIG_USB_ETHER > > > > +ifdef CONFIG_$(SPL_)USB_ETHER > > > > obj-y += ether.o > > > > obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o > > > > obj-$(CONFIG_CI_UDC) += ci_udc.o > > > > --- > > > > 2.24.1 > > > > > > > > > > > > > > > Best regards, > > > > > > Lukasz Majewski > > > > > > -- > > > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang > > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, > > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: > > > lu...@denx.de > > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
[PATCH v5 09/10] configs: j721e_evm_r5: Enable R5F remoteproc support
Enable R5F remoteproc support in R5 defconfig so that R5s can be started in SPL. While at it enable the SPL_FS_EXT4 config option to load the firmwares from file system. Signed-off-by: Keerthy Signed-off-by: Lokesh Vutla --- configs/j721e_evm_r5_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index d5e9fdd089..36fb71b84d 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -28,6 +28,7 @@ CONFIG_SPL_EARLY_BSS=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400 CONFIG_SPL_ENV_SUPPORT=y +CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_RESET=y @@ -99,6 +100,7 @@ CONFIG_SPL_DM_REGULATOR=y CONFIG_DM_REGULATOR_TPS65941=y CONFIG_K3_SYSTEM_CONTROLLER=y CONFIG_REMOTEPROC_TI_K3_ARM64=y +CONFIG_REMOTEPROC_TI_K3_R5F=y CONFIG_DM_RESET=y CONFIG_RESET_TI_SCI=y CONFIG_DM_SERIAL=y -- 2.17.1
[PATCH v5 08/10] include: configs: j721e_evm: Add env variables for mcu_r5fss0_core0 & main_r5fss0_core0
Add env variables for mcu_r5fss0_core0 & main_r5fss0_core0 firmware
loadaddr and name.
Signed-off-by: Keerthy
---
include/configs/j721e_evm.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index 4371c471e5..fc73a9c932 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -88,6 +88,10 @@
"mmcdev=1\0"\
"bootpart=1:2\0"\
"bootdir=/boot\0" \
+ "addr_mainr5f0_0load=8800\0"
\
+ "name_mainr5f0_0fw=/lib/firmware/j7-main-r5f0_0-fw\0" \
+ "addr_mcur5f0_0load=8900\0" \
+ "name_mcur5f0_0fw=/lib/firmware/j7-mcu-r5f0_0-fw\0" \
"rd_spec=-\0" \
"init_mmc=run args_all args_mmc\0" \
"get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}\0" \
--
2.17.1
[PATCH v5 05/10] armv7R: K3: Add support for jumping to firmware
MCU Domain rf50 is currently shutting down after loading the ATF.
Load elf firmware and jump to firmware post loading ATF.
ROM doesn't enable ATCM memory, so make sure that firmware that
is being loaded doesn't use ATCM memory or override SPL.
Signed-off-by: Keerthy
Signed-off-by: Lokesh Vutla
---
arch/arm/mach-k3/common.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index bddb62ea5e..5c5eedb6eb 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -132,8 +132,10 @@ __weak void start_non_linux_remote_cores(void)
void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
{
+ typedef void __noreturn (*image_entry_noargs_t)(void);
struct ti_sci_handle *ti_sci = get_ti_sci_handle();
- int ret;
+ u32 loadaddr = 0;
+ int ret, size;
/* Release all the exclusive devices held by SPL before starting ATF */
ti_sci->ops.dev_ops.release_exclusive_devices(ti_sci);
@@ -144,6 +146,9 @@ void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image)
init_env();
start_non_linux_remote_cores();
+ size = load_firmware("name_mcur5f0_0fw", "addr_mcur5f0_0load",
+);
+
/*
* It is assumed that remoteproc device 1 is the corresponding
@@ -159,13 +164,18 @@ void __noreturn jump_to_image_no_args(struct
spl_image_info *spl_image)
ret = rproc_start(1);
if (ret)
panic("%s: ATF failed to start on rproc (%d)\n", __func__, ret);
+ if (!(size > 0 && valid_elf_image(loadaddr))) {
+ debug("Shutting down...\n");
+ release_resources_for_core_shutdown();
+
+ while (1)
+ asm volatile("wfe");
+ }
- debug("Releasing resources...\n");
- release_resources_for_core_shutdown();
+ image_entry_noargs_t image_entry =
+ (image_entry_noargs_t)load_elf_image_phdr(loadaddr);
- debug("Finalizing core shutdown...\n");
- while (1)
- asm volatile("wfe");
+ image_entry();
}
#endif
--
2.17.1
[PATCH v5 07/10] arm: dts: k3-j721e-r5: Enable r5fss0 cluster in SPL
Enable MAIN domain r5fss0 cluster and its core0 in R5 spl.
Signed-off-by: Keerthy
---
.../dts/k3-j721e-r5-common-proc-board-u-boot.dtsi| 12
arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 2 ++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
index f98be993e8..526f42e3a9 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
@@ -13,3 +13,15 @@
compatible = "u-boot,fs-loader";
};
};
+
+_r5fss0 {
+ u-boot,dm-spl;
+};
+
+_r5fss0_core0 {
+ u-boot,dm-spl;
+};
+
+_r5fss0_core1 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
index 1f14d71438..ba2a312602 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -13,6 +13,8 @@
aliases {
remoteproc0 =
remoteproc1 = _0;
+ remoteproc2 = _r5fss0_core0;
+ remoteproc3 = _r5fss0_core1;
};
chosen {
--
2.17.1
[PATCH v5 10/10] configs: j721e_evm_r5_defconfig: Remove saving ENV in eMMC
Remove saving ENV in eMMC in R5 as the power domains are not setup. Environment in eMMC cannot be read if we do not boot from eMMC. Signed-off-by: Keerthy --- configs/j721e_evm_r5_defconfig | 4 1 file changed, 4 deletions(-) diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index 36fb71b84d..39e32caec2 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -7,7 +7,6 @@ CONFIG_SYS_MALLOC_F_LEN=0x7 CONFIG_SOC_K3_J721E=y CONFIG_TARGET_J721E_R5_EVM=y CONFIG_ENV_SIZE=0x2 -CONFIG_ENV_OFFSET=0x68 CONFIG_DM_GPIO=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y @@ -54,9 +53,6 @@ CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-common-proc-board" -CONFIG_ENV_IS_IN_MMC=y -CONFIG_SYS_REDUNDAND_ENVIRONMENT=y -CONFIG_ENV_OFFSET_REDUND=0x70 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_SPL_DM=y -- 2.17.1
[PATCH v5 06/10] arm: dts: k3-j721e-r5-u-boot: Add fs_loader node
Add fs_loader node which will be needed for loading firmwares
from the boot media/filesystem.
Signed-off-by: Keerthy
---
.../dts/k3-j721e-r5-common-proc-board-u-boot.dtsi | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
new file mode 100644
index 00..f98be993e8
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/ {
+ chosen {
+ firmware-loader = _loader0;
+ };
+
+ fs_loader0: fs_loader@0 {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ };
+};
--
2.17.1
[PATCH v5 04/10] armv7R: K3: r5_mpu: Enable execute permission for MCU0 BTCM
Enable execute permission for mcu_r5fss0_core0 BTCM so that we can jump
to a firmware directly from SPL.
Signed-off-by: Keerthy
---
arch/arm/mach-k3/r5_mpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/r5_mpu.c b/arch/arm/mach-k3/r5_mpu.c
index ee076ed877..3d2ff6775a 100644
--- a/arch/arm/mach-k3/r5_mpu.c
+++ b/arch/arm/mach-k3/r5_mpu.c
@@ -26,7 +26,9 @@ struct mpu_region_config k3_mpu_regions[16] = {
/* U-Boot's code area marking it as WB and Write allocate */
{CONFIG_SYS_SDRAM_BASE, REGION_2, XN_DIS, PRIV_RW_USR_RW,
O_I_WB_RD_WR_ALLOC, REGION_2GB},
- {0x0, 3, 0x0, 0x0, 0x0, 0x0},
+ /* mcu_r5fss0_core0 BTCM area marking it as WB and Write allocate. */
+ {0x4101, 3, XN_DIS, PRIV_RW_USR_RW, O_I_WB_RD_WR_ALLOC,
+REGION_8MB},
{0x0, 4, 0x0, 0x0, 0x0, 0x0},
{0x0, 5, 0x0, 0x0, 0x0, 0x0},
{0x0, 6, 0x0, 0x0, 0x0, 0x0},
--
2.17.1
[PATCH v5 02/10] lib: elf: Move the generic elf loading/validating functions to lib
Move the generic elf loading/validating functions to lib/
so that they can be re-used and accessed by code existing
outside cmd.
Signed-off-by: Keerthy
Suggested-by: Simon Goldschmidt
Reviewed-by: Simon Goldschmidt
---
cmd/Kconfig | 1 +
cmd/elf.c | 229
include/elf.h | 4 +
lib/Kconfig | 6 ++
lib/Makefile | 1 +
lib/elf.c | 256 ++
6 files changed, 268 insertions(+), 229 deletions(-)
create mode 100644 lib/elf.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index e6ba57035e..9819dd1aaf 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -399,6 +399,7 @@ config CMD_ABOOTIMG
config CMD_ELF
bool "bootelf, bootvx"
default y
+ select LIB_ELF
help
Boot an ELF/vxWorks image from the memory.
diff --git a/cmd/elf.c b/cmd/elf.c
index ba06df06cf..c129077e20 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -27,211 +27,6 @@
#include
#endif
-/*
- * A very simple ELF64 loader, assumes the image is valid, returns the
- * entry point address.
- *
- * Note if U-Boot is 32-bit, the loader assumes the to segment's
- * physical address and size is within the lower 32-bit address space.
- */
-static unsigned long load_elf64_image_phdr(unsigned long addr)
-{
- Elf64_Ehdr *ehdr; /* Elf header structure pointer */
- Elf64_Phdr *phdr; /* Program header structure pointer */
- int i;
-
- ehdr = (Elf64_Ehdr *)addr;
- phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
-
- /* Load each program header */
- for (i = 0; i < ehdr->e_phnum; ++i) {
- void *dst = (void *)(ulong)phdr->p_paddr;
- void *src = (void *)addr + phdr->p_offset;
-
- debug("Loading phdr %i to 0x%p (%lu bytes)\n",
- i, dst, (ulong)phdr->p_filesz);
- if (phdr->p_filesz)
- memcpy(dst, src, phdr->p_filesz);
- if (phdr->p_filesz != phdr->p_memsz)
- memset(dst + phdr->p_filesz, 0x00,
- phdr->p_memsz - phdr->p_filesz);
- flush_cache(rounddown((unsigned long)dst, ARCH_DMA_MINALIGN),
- roundup(phdr->p_memsz, ARCH_DMA_MINALIGN));
- ++phdr;
- }
-
- if (ehdr->e_machine == EM_PPC64 && (ehdr->e_flags &
- EF_PPC64_ELFV1_ABI)) {
- /*
-* For the 64-bit PowerPC ELF V1 ABI, e_entry is a function
-* descriptor pointer with the first double word being the
-* address of the entry point of the function.
-*/
- uintptr_t addr = ehdr->e_entry;
-
- return *(Elf64_Addr *)addr;
- }
-
- return ehdr->e_entry;
-}
-
-static unsigned long load_elf64_image_shdr(unsigned long addr)
-{
- Elf64_Ehdr *ehdr; /* Elf header structure pointer */
- Elf64_Shdr *shdr; /* Section header structure pointer */
- unsigned char *strtab = 0; /* String table pointer */
- unsigned char *image; /* Binary image pointer */
- int i; /* Loop counter */
-
- ehdr = (Elf64_Ehdr *)addr;
-
- /* Find the section header string table for output info */
- shdr = (Elf64_Shdr *)(addr + (ulong)ehdr->e_shoff +
-(ehdr->e_shstrndx * sizeof(Elf64_Shdr)));
-
- if (shdr->sh_type == SHT_STRTAB)
- strtab = (unsigned char *)(addr + (ulong)shdr->sh_offset);
-
- /* Load each appropriate section */
- for (i = 0; i < ehdr->e_shnum; ++i) {
- shdr = (Elf64_Shdr *)(addr + (ulong)ehdr->e_shoff +
-(i * sizeof(Elf64_Shdr)));
-
- if (!(shdr->sh_flags & SHF_ALLOC) ||
- shdr->sh_addr == 0 || shdr->sh_size == 0) {
- continue;
- }
-
- if (strtab) {
- debug("%sing %s @ 0x%08lx (%ld bytes)\n",
- (shdr->sh_type == SHT_NOBITS) ? "Clear" : "Load",
- [shdr->sh_name],
- (unsigned long)shdr->sh_addr,
- (long)shdr->sh_size);
- }
-
- if (shdr->sh_type == SHT_NOBITS) {
- memset((void *)(uintptr_t)shdr->sh_addr, 0,
- shdr->sh_size);
- } else {
- image = (unsigned char *)addr + (ulong)shdr->sh_offset;
- memcpy((void *)(uintptr_t)shdr->sh_addr,
- (const void *)image, shdr->sh_size);
- }
- flush_cache(rounddown(shdr->sh_addr, ARCH_DMA_MINALIGN),
- roundup((shdr->sh_addr + shdr->sh_size),
-ARCH_DMA_MINALIGN) -
- rounddown(shdr->sh_addr,
[PATCH v5 03/10] arm: k3: Add support for loading non linux remote cores
Add MAIN domain R5FSS0 remoteproc support from spl. This enables
loading the elf firmware in SPL and starting the remotecore.
In order to start the core, there should be a file with path
"/lib/firmware/j7-main-r5f0_0-fw" under filesystem
of respective boot mode.
Signed-off-by: Keerthy
Signed-off-by: Lokesh Vutla
[Guard start_non_linux_remote_cores under CONFIG_FS_LOADER]
Signed-off-by: Andreas Dannenberg
---
arch/arm/mach-k3/common.c | 84 ---
arch/arm/mach-k3/common.h | 2 +
arch/arm/mach-k3/j721e_init.c | 34 ++
3 files changed, 115 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 2f82edb970..bddb62ea5e 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -17,6 +17,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
struct ti_sci_handle *get_ti_sci_handle(void)
{
@@ -58,6 +62,74 @@ int early_console_init(void)
#endif
#ifdef CONFIG_SYS_K3_SPL_ATF
+
+void init_env(void)
+{
+#ifdef CONFIG_SPL_ENV_SUPPORT
+ char *part;
+
+ env_init();
+ env_load();
+ switch (spl_boot_device()) {
+ case BOOT_DEVICE_MMC2:
+ part = env_get("bootpart");
+ env_set("storage_interface", "mmc");
+ env_set("fw_dev_part", part);
+ break;
+ case BOOT_DEVICE_SPI:
+ env_set("storage_interface", "ubi");
+ env_set("fw_ubi_mtdpart", "UBI");
+ env_set("fw_ubi_volume", "UBI0");
+ break;
+ default:
+ printf("%s from device %u not supported!\n",
+ __func__, spl_boot_device());
+ return;
+ }
+#endif
+}
+
+#ifdef CONFIG_FS_LOADER
+int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr)
+{
+ struct udevice *fsdev;
+ char *name = NULL;
+ int size = 0;
+
+ *loadaddr = 0;
+#ifdef CONFIG_SPL_ENV_SUPPORT
+ switch (spl_boot_device()) {
+ case BOOT_DEVICE_MMC2:
+ name = env_get(name_fw);
+ *loadaddr = env_get_hex(name_loadaddr, *loadaddr);
+ break;
+ default:
+ printf("Loading rproc fw image from device %u not supported!\n",
+ spl_boot_device());
+ return 0;
+ }
+#endif
+ if (!*loadaddr)
+ return 0;
+
+ if (!uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, )) {
+ size = request_firmware_into_buf(fsdev, name, (void *)*loadaddr,
+0, 0);
+ }
+
+ return size;
+}
+#else
+int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr)
+{
+ return 0;
+}
+#endif
+
+__weak void start_non_linux_remote_cores(void)
+{
+}
+
void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
{
struct ti_sci_handle *ti_sci = get_ti_sci_handle();
@@ -66,15 +138,17 @@ void __noreturn jump_to_image_no_args(struct
spl_image_info *spl_image)
/* Release all the exclusive devices held by SPL before starting ATF */
ti_sci->ops.dev_ops.release_exclusive_devices(ti_sci);
+ ret = rproc_init();
+ if (ret)
+ panic("rproc failed to be initialized (%d)\n", ret);
+
+ init_env();
+ start_non_linux_remote_cores();
+
/*
* It is assumed that remoteproc device 1 is the corresponding
* Cortex-A core which runs ATF. Make sure DT reflects the same.
*/
- ret = rproc_dev_init(1);
- if (ret)
- panic("%s: ATF failed to initialize on rproc (%d)\n", __func__,
- ret);
-
ret = rproc_load(1, spl_image->entry_point, 0x200);
if (ret)
panic("%s: ATF failed to load on rproc (%d)\n", __func__, ret);
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index d8b34fe060..42fb8ee6e7 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -24,3 +24,5 @@ void setup_k3_mpu_regions(void);
int early_console_init(void);
void disable_linefill_optimization(void);
void remove_fwl_configs(struct fwl_data *fwl_data, size_t fwl_data_size);
+void start_non_linux_remote_cores(void);
+int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr);
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 0994522f6c..d80813e8bb 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_SPL_BUILD
#ifdef CONFIG_K3_LOAD_SYSFW
@@ -326,3 +327,36 @@ void release_resources_for_core_shutdown(void)
}
}
#endif
+
+#ifdef CONFIG_SYS_K3_SPL_ATF
+void start_non_linux_remote_cores(void)
+{
+ int size = 0, ret;
+ u32 loadaddr = 0;
+
+ size = load_firmware("name_mainr5f0_0fw", "addr_mainr5f0_0load",
+);
+
[PATCH v5 01/10] env: nowhere: set default enviroment
In case only CONFIG_ENV_IS_NOWHERE without any of the memory
based configs like CONFIG_ENV_IS_IN_MMC the env_set function
fails as the gd->flags & GD_FLG_ENV_READY check fails.
Set default enviroment so that set_env calls succeed when only
ENV_IS_NOWHERE set.
Signed-off-by: Keerthy
---
env/nowhere.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/env/nowhere.c b/env/nowhere.c
index f5b0a17652..70c3b3e011 100644
--- a/env/nowhere.c
+++ b/env/nowhere.c
@@ -23,6 +23,7 @@ static int env_nowhere_init(void)
{
gd->env_addr= (ulong)_environment[0];
gd->env_valid = ENV_INVALID;
+ env_set_default(NULL, 0);
return 0;
}
--
2.17.1
