Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
On 6/4/24 05:34, Brunham, Kalen wrote:
Hi Tom/Heinrich,
I have https://github.com/u-boot/u-boot/pull/574 that has a proposed change. It
is currently failing clang sandbox, which looks a little strange and I'm
looking into it. Please let me know if you have any feedback on the general
strategy.
Thanks,
-Kalen
-Original Message-
From: Tom Rini
Sent: Monday, June 3, 2024 1:23 PM
To: Brunham, Kalen
Cc: Jiaxun Yang ; Heinrich Schuchardt ;
Ilias Apalodimas ; U-Boot@lists.denx.de
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
On Sun, Jun 02, 2024 at 12:16:38AM +, Brunham, Kalen wrote:
Thanks Tom.
Can you suggest who is the existing owner of this code I could work with?
You should CC Heinrich for sure once you have things working.
-Original Message-
From: Tom Rini
Sent: Friday, May 31, 2024 12:03 PM
To: Brunham, Kalen
Cc: Jiaxun Yang ; Heinrich Schuchardt ;
Ilias Apalodimas ; U-Boot@lists.denx.de
Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
On Thu, May 30, 2024 at 02:53:17PM +, Brunham, Kalen wrote:
Hi Tom,
What are next steps on this change?
I'm committed to the idea of EFI apps opposed to examples/standalone.
EFI currently requires block devices which is not enabled when only using flash.
Should config BLK be updated to include DM_SPI_FLASH?
The UEFI implementation should not depend on DM_SPI_FLASH.
You could make BLK manually selectable again instead:
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 6ad18889f61..1f0e1010f0e 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -1,5 +1,5 @@
config BLK
- bool # "Support block devices"
+ bool "Support block devices"
Cf. 0417b8523c47 ("blk: Hide the BLK and SPL_LEGACY_BLOCK options")
Best regards
Heinrich
Should we explore how to remove BLK as a dependency for EFI_LOADER?
Yes, someone needs to explore how to cleanly make BLK optional for EFI_LOADER.
--
Tom
[PATCH 1/1] dfu: add missing dependency for SPI flash DFU driver
Building the SPI flash DFU driver fails if SPI flash support is missing. drivers/dfu/dfu_sf.c:123:29: error: ‘CONFIG_SF_DEFAULT_MODE’ undeclared (first use in this function); Add the missing dependency. Signed-off-by: Heinrich Schuchardt --- drivers/dfu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig index 0360d9da142..971204758aa 100644 --- a/drivers/dfu/Kconfig +++ b/drivers/dfu/Kconfig @@ -68,6 +68,7 @@ config DFU_RAM config DFU_SF bool "SPI flash back end for DFU" + depends on SPI_FLASH || DM_SPI_FLASH help This option enables using DFU to read and write to SPI flash based storage. -- 2.43.0
Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
On 6/4/24 05:34, Brunham, Kalen wrote: Hi Tom/Heinrich, I have https://github.com/u-boot/u-boot/pull/574 that has a proposed change. It is currently failing clang sandbox, which looks a little strange and I'm looking into it. Please let me know if you have any feedback on the general strategy. Thanks, -Kalen -Original Message- From: Tom Rini Sent: Monday, June 3, 2024 1:23 PM To: Brunham, Kalen Cc: Jiaxun Yang ; Heinrich Schuchardt ; Ilias Apalodimas ; U-Boot@lists.denx.de Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0 On Sun, Jun 02, 2024 at 12:16:38AM +, Brunham, Kalen wrote: Thanks Tom. Can you suggest who is the existing owner of this code I could work with? You should CC Heinrich for sure once you have things working. -Original Message- From: Tom Rini Sent: Friday, May 31, 2024 12:03 PM To: Brunham, Kalen Cc: Jiaxun Yang ; Heinrich Schuchardt ; Ilias Apalodimas ; U-Boot@lists.denx.de Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0 On Thu, May 30, 2024 at 02:53:17PM +, Brunham, Kalen wrote: Hi Tom, What are next steps on this change? I'm committed to the idea of EFI apps opposed to examples/standalone. EFI currently requires block devices which is not enabled when only using flash. Should config BLK be updated to include DM_SPI_FLASH? Should we explore how to remove BLK as a dependency for EFI_LOADER? Yes, someone needs to explore how to cleanly make BLK optional for EFI_LOADER. EFI applications like iPXE provide block devices. CONFIG_BLK does not depend on anything but CONFIG_DM. Why would you prefer to make BLK optional for EFI_LOADER? Best regards Heinrich
[PATCH 1/1] mtd: simplify CONFIG_DM_SPI_FLASH dependencies
CONFIG_DM_SPI depends on CONFIG_DM. There is no need to list CONFIG_DM explicitly as dependency for CONFIG_DM_SPI_FLASH Signed-off-by: Heinrich Schuchardt --- drivers/mtd/spi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index bedc4e970e..63b0fd899f 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -2,7 +2,7 @@ menu "SPI Flash Support" config DM_SPI_FLASH bool "Enable Driver Model for SPI flash" - depends on DM && DM_SPI + depends on DM_SPI imply SPI_FLASH help Enable driver model for SPI flash. This SPI flash interface -- 2.43.0
Re: [PATCH] fs: ubifs: Add support for ZSTD decompression
Hello Piotr, On 28.05.24 17:05, Piotr Wojtaszczyk wrote: ZSTD can be a better tradeoff between NAND IO operations and decompression speed giving a better boot time. Signed-off-by: Piotr Wojtaszczyk --- fs/ubifs/ubifs-media.h | 2 ++ fs/ubifs/ubifs.c | 53 -- 2 files changed, 53 insertions(+), 2 deletions(-) Please add in future a list of changes you have done (You did, or?) And add me at least to cc (I nearly missed this patch), see: https://docs.u-boot.org/en/latest/develop/sending_patches.html thanks! Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
RE: [PATCH 1/1] Added arm64 assembly for examples/api crt0
Hi Tom/Heinrich, I have https://github.com/u-boot/u-boot/pull/574 that has a proposed change. It is currently failing clang sandbox, which looks a little strange and I'm looking into it. Please let me know if you have any feedback on the general strategy. Thanks, -Kalen -Original Message- From: Tom Rini Sent: Monday, June 3, 2024 1:23 PM To: Brunham, Kalen Cc: Jiaxun Yang ; Heinrich Schuchardt ; Ilias Apalodimas ; U-Boot@lists.denx.de Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0 On Sun, Jun 02, 2024 at 12:16:38AM +, Brunham, Kalen wrote: > Thanks Tom. > > Can you suggest who is the existing owner of this code I could work with? You should CC Heinrich for sure once you have things working. > > -Original Message- > From: Tom Rini > Sent: Friday, May 31, 2024 12:03 PM > To: Brunham, Kalen > Cc: Jiaxun Yang ; Heinrich Schuchardt > ; Ilias Apalodimas ; > U-Boot@lists.denx.de > Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0 > > On Thu, May 30, 2024 at 02:53:17PM +, Brunham, Kalen wrote: > > > Hi Tom, > > > > What are next steps on this change? > > > > I'm committed to the idea of EFI apps opposed to examples/standalone. > > EFI currently requires block devices which is not enabled when only using > > flash. > > > > Should config BLK be updated to include DM_SPI_FLASH? > > Should we explore how to remove BLK as a dependency for EFI_LOADER? > > Yes, someone needs to explore how to cleanly make BLK optional for EFI_LOADER. > > -- > Tom -- Tom
Re: [PATCH v1 0/5] FUSB302 USB-C controller support
Hello Jonas, On Mon, Jun 03, 2024 at 11:58:07AM +0200, Jonas Karlman wrote: > Some initial quick feedback is that the tcpm uclass and driver should > probably take more advantage of the u-boot driver model. > > Few quick thoughts: > - Split out uclass/driver api parts into tcpm-uclass.c > - Take advantage of uclass_driver ops such as post_probe and > per_device_auto/per_device_plat_auto to e.g. handle tcpm_port_init and > tcpm_port/tcpm_dev > - udevice should probably be passed to tcpm_ functions instead of a > tcpm_port, dev_get_uclass_plat/priv could possible be used to get > the tcpm_port data for the udevice > > I have not yet had time to runtime test this but will do and get back > with a more in depth review later this week. Thanks for the quick thoughts. They do sound very sensible, so I gave them a go. The diff turned out to be quite big (about 20% of all lines changed). It's currently one big cleanup commit, which I still need to split and merge into the tcpm and fusb302 commits. After doing that and some more testing on my side I will send PATCHv2. I expect this to happen within the next 48h, so it might be sensible to wait with further testing / review until that happened. Greetings, -- Sebastian signature.asc Description: PGP signature
Re: [PATCH v6] test/py: net_boot: Add test cases for net boot
On Mon, Jun 03, 2024 at 08:03:45PM +0530, Love Kumar wrote: > Add tests for booting image using tftpboot/pxe boot commands, tftpboot > boot case loads the FIT image into DDR and boots using bootm command > whereas pxe boot cases downloads the pxe configuration file from the > TFTP server and interprets it to boot the images mentioned in the pxe > configurations file. > This test relies on boardenv_* containing configuration values including > the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the > boot log pattern value is matched. For example, if the parameter > 'pattern' is defined as 'login:', it will boot till login prompt. > > Signed-off-by: Love Kumar So, I get as far as this with the PXE test: Captured stdout call - U-Boot> setenv autoload no U-Boot> U-Boot> dhcp Waiting for Ethernet connection... done. BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.1.100 (254 ms) U-Boot> U-Boot> echo $bootfile U-Boot> U-Boot> pxe get missing environment variable: pxeuuid Retrieving file: pxelinux.cfg/01-b8-27-eb-fc-64-a6 Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.1.10; our IP address is 192.168.1.100 Filename 'pxelinux.cfg/01-b8-27-eb-fc-64-a6'. Load address: 0x250 Loading: ## 64 Bytes 0 Bytes/s done Bytes transferred = 64 (40 hex) Config file '' found U-Boot> U-Boot> pxe boot 20 Ignoring unknown command: <9G??0`@???p U-Boot> -- Tom signature.asc Description: PGP signature
[ANN] U-Boot v2024.07-rc4 released
Hey all, It's release day and here is -rc4. To reiterate what I said last release, this really is the time for bug fixes (which includes documentation corrections) only at this point. Pretty much anything else should be for -next. In terms of a changelog, git log --merges v2024.07-rc3..v2024.07-rc4 contains what I've pulled but as always, better PR messages and tags will provide better results here. I hope to remain on schedule and that means the rest of the rcs every other Monday, and with final release on Monday, July 1st, 2024. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] Please pull u-boot-imx-next-20240603
On Mon, Jun 03, 2024 at 01:43:03PM -0300, Fabio Estevam wrote: > Hi Tom, > > Please pull from u-boot-imx/next, thanks. > > The following changes since commit 7e52d6ccfb76e2afc2d183b357abe2a2e2f948cf: > > Merge patch series "FWU: Add support for FWU metadata version 2" > (2024-05-24 13:42:07 -0600) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-next-20240603 > > for you to fetch changes up to fb95661116fb4269883721afd80578e6d88ce043: > > imx8mm-cl-iot-gate: Add support for the Realtek RTL8211E PHY (2024-06-03 > 12:14:29 -0300) > > u-boot-imx-next-20240603 Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/next-cleanup
On Sun, Jun 02, 2024 at 02:51:15PM +0200, Marek Vasut wrote: > The following changes since commit 7e52d6ccfb76e2afc2d183b357abe2a2e2f948cf: > > Merge patch series "FWU: Add support for FWU metadata version 2" > (2024-05-24 13:42:07 -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git next-cleanup > > for you to fetch changes up to 63da3a795e86dcf0906beb99865e3d4139114872: > > ARM: dts: renesas: Drop R8A779H0 V4M DTs with OF_UPSTREAM counterparts > (2024-06-02 02:30:13 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: obscure microsd detection issue between U-Boot and kernel
On Mon, Jun 3, 2024 at 1:18 AM Christian Loehle wrote: > > On 5/31/24 21:47, Tim Harvey wrote: > > Greetings, > > > > I'm seeing an issue on an imx8mm board (imx8mm-venice-gw73xx) where > > for a specific set of microsd cards if I have accessed the microsd in > > U-Boot with UHS/1.8V the kernel will not recognize that microsd when > > scanning. > > > > The issue does not occur with all microsd cards but seems to appear > > with a large sample size of a specific card/model (Kingston SDC32 32GB > > SDR104 card). I do not see a signal integrity issue on the scope. > > > > Instrumenting the kernel the issue is that the host reports a CRC > > error as soon as the first mmc_send_if_cond call which occurs in > > mmc_rescan_try_freq. > > > > I can avoid the issue by either not accessing the microsd in U-Boot or > > by disabling UHS/1.8V mode in U-Boot therefore what I think is > > happening is that U-Boot leaves the card in UHS/1.8V signalling mode > > and when the kernel scans it sets the voltage back to 3.3V > > standard/default and default timings then issues its clock cycles to > > 'reset' the card and the card does not recognize the reset. I'm > > wondering if this is because the reset is done via clock cycles after > > the kernel has set the I/O voltage back to 3.3V when perhaps the card > > is still in 1.8V mode (although I don't see how that would cause an > > issue)? > > It will cause an issue for many cards and might break some cards. > > > > > Is there some sort of MMC 'reset' I can/should do in U-Boot before > > booting the kernel? Has anyone encountered anything like this before? > > There is no 'switching back' to 3.3V signalling from UHS 1.8V. > The only way this can be done is therefore a full power-off. > Is that done correctly for your system? > AFAIR spec dictates 500ms of <0.5V on VCC. Note that driving CLK/signal > lines can also sustain the card somewhat, as leakage is only limited > within operating voltage. Hi Christian, Are you saying the only way to properly reset from 1.8V is to have a VDD supply on the microSD card that can be turned off before booting to Linux? We have never had that before and never encountered something like this. Best Regards, Tim
Re: [PATCH v1 0/4] Sync StarFive JH7110 clock and reset dt-bindings with Linux
Hi Hal, Instead of manual dt-bindings sync can we please adopt OF_UPSTREAM for JH7110 ? -E On Mon, Jun 3, 2024 at 6:57 AM Hal Feng wrote: > > There are differences in clock / reset dt-bindings between U-Boot and > Linux. Sync them, so it is feasible to use OF_UPSTREAM for StarFive > JH7110 SoC. > > Hal Feng (4): > dt-bindings: clock: jh7110: Sync with Linux > dt-bindings: reset: jh7110: Sync with Linux > clk: starfive: jh7110: Sync clock definitions with Linux > riscv: dts: jh7110: Sync clock and reset definitions with Linux > > .../dts/jh7110-starfive-visionfive-2.dtsi | 6 +- > arch/riscv/dts/jh7110-u-boot.dtsi | 2 +- > arch/riscv/dts/jh7110.dtsi| 28 +-- > drivers/clk/starfive/clk-jh7110-pll.c | 6 +- > drivers/clk/starfive/clk-jh7110.c | 44 ++--- > .../dt-bindings/clock/starfive,jh7110-crg.h | 180 +++--- > .../dt-bindings/reset/starfive,jh7110-crg.h | 144 -- > 7 files changed, 243 insertions(+), 167 deletions(-) > > > base-commit: ea722aa5eb33740ae77e8816aeb72b385e621cd0 > -- > 2.43.2 >
Re: [PATCH 2/2] net: phy: Replace PHY_ANEG_TIMEOUT with Kconfig symbol
Hello Tom, Il 3 giugno 2024 19:56:07 CEST, Tom Rini ha scritto: >On Sat, Jun 01, 2024 at 11:21:54AM +0200, Francesco Dolcini wrote: >> Hello Marek, >> >> On Fri, May 31, 2024 at 06:47:17PM +0200, Marek Vasut wrote: >> > Switch PHY_ANEG_TIMEOUT to CONFIG_PHY_ANEG_TIMEOUT Kconfig symbol. >> > This removes one more configuration headers option finalizes its >> > Kconfig symbol conversion. No functional change expected. >> > >> > Signed-off-by: Marek Vasut >> > --- >> ... >> >> > diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h >> > index 0df3917e200..6fd43511ee4 100644 >> > --- a/include/configs/apalis_imx6.h >> > +++ b/include/configs/apalis_imx6.h >> > @@ -22,7 +22,6 @@ >> > #define CFG_SYS_FSL_USDHC_NUM 3 >> > >> > /* Network */ >> > -#define PHY_ANEG_TIMEOUT 15000 /* PHY needs longer aneg time */ >> >> You should remove also the line before, after removing the define it's >> just a stale comment. > >It would be nice, but there's lots of similar garbage remaining from >other transitions, so to me it's not a deal-breaker here. I see your point, I gonna send a follow-up patch to cleanup what I care the most afterwards if we merge this as it is. Francesco
Re: [PATCH 2/2] net: phy: Replace PHY_ANEG_TIMEOUT with Kconfig symbol
On Sat, Jun 01, 2024 at 11:21:54AM +0200, Francesco Dolcini wrote: > Hello Marek, > > On Fri, May 31, 2024 at 06:47:17PM +0200, Marek Vasut wrote: > > Switch PHY_ANEG_TIMEOUT to CONFIG_PHY_ANEG_TIMEOUT Kconfig symbol. > > This removes one more configuration headers option finalizes its > > Kconfig symbol conversion. No functional change expected. > > > > Signed-off-by: Marek Vasut > > --- > ... > > > diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h > > index 0df3917e200..6fd43511ee4 100644 > > --- a/include/configs/apalis_imx6.h > > +++ b/include/configs/apalis_imx6.h > > @@ -22,7 +22,6 @@ > > #define CFG_SYS_FSL_USDHC_NUM 3 > > > > /* Network */ > > -#define PHY_ANEG_TIMEOUT 15000 /* PHY needs longer aneg time */ > > You should remove also the line before, after removing the define it's > just a stale comment. It would be nice, but there's lots of similar garbage remaining from other transitions, so to me it's not a deal-breaker here. -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-samsung master
On Mon, Jun 03, 2024 at 03:08:53PM +0900, Minkyu Kang wrote: > Dear Tom, > > The following changes since commit 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a: > > Merge tag 'tpm-master-27052024' of > https://source.denx.de/u-boot/custodians/u-boot-tpm (2024-05-27 08:56:02 > -0600) > > are available in the git repository at: > > 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a > > for you to fetch changes up to 7045c4dd04648fd2ba1806b75e139d941db0d6c5: > > arm: exynos: Map iRAM APM area for Exynos850 SoC (2024-05-28 11:54:07 > +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master-cleanup
On Sun, Jun 02, 2024 at 02:50:14PM +0200, Marek Vasut wrote: > The following changes since commit ea722aa5eb33740ae77e8816aeb72b385e621cd0: > > Merge branch '2024-05-29-assorted-small-fixes' (2024-05-29 11:21:14 -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git master-cleanup > > for you to fetch changes up to ecfa301911405f9ebc27677f6d26fcd43309ed36: > > configs: rzg2_beacon: Realign ENV location and offset (2024-06-02 02:30:01 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] u-boot-riscv/master
On Thu, May 30, 2024 at 04:56:49PM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a: > > Merge tag 'tpm-master-27052024' of > https://source.denx.de/u-boot/custodians/u-boot-tpm (2024-05-27 08:56:02 > -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to 1d29c718b7ba09807f8060796d9c21772e3c1b52: > > andes: Use UCCTLCOMMAND instead of MCCTLCOMMAND (2024-05-30 16:01:13 +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/20920 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND PATCH 0/4] omap3: igep0x00: Fix boot failure and modernize the boards support
On Sat, 18 May 2024 15:06:11 +0200, Javier Martinez Canillas wrote: > I noticed that the IGEPv2 board did not boot anymore with mainline U-Boot. > This was caused by a driver change to allocate its platform data before > relocation and U-Boot not having enough pre-relocation heap size for this. > > This series fixes this issue and also makes the board support more modern, > by enabling DM for SPL and migrating the IGEP boards to use upstream DTBs. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
On Sun, Jun 02, 2024 at 12:16:38AM +, Brunham, Kalen wrote: > Thanks Tom. > > Can you suggest who is the existing owner of this code I could work with? You should CC Heinrich for sure once you have things working. > > -Original Message- > From: Tom Rini > Sent: Friday, May 31, 2024 12:03 PM > To: Brunham, Kalen > Cc: Jiaxun Yang ; Heinrich Schuchardt > ; Ilias Apalodimas ; > U-Boot@lists.denx.de > Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0 > > On Thu, May 30, 2024 at 02:53:17PM +, Brunham, Kalen wrote: > > > Hi Tom, > > > > What are next steps on this change? > > > > I'm committed to the idea of EFI apps opposed to examples/standalone. > > EFI currently requires block devices which is not enabled when only using > > flash. > > > > Should config BLK be updated to include DM_SPI_FLASH? > > Should we explore how to remove BLK as a dependency for EFI_LOADER? > > Yes, someone needs to explore how to cleanly make BLK optional for EFI_LOADER. > > -- > Tom -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] imx8mm-cl-iot-gate: Add support for Samsung 4GB DDR
On Tue, May 28, 2024 at 4:15 PM Fabio Estevam wrote: > > From: Fabio Estevam > > Newer versions of the imx8mm-cl-iot-gate boards may come populated with a > Samsung 4GB DDR model. > > Add support for it. > > Signed-off-by: Fabio Estevam Applied all to u-boot-imx/next, thanks.
Re: [PATCH 0/4] Support all phyCORE-i.MX8MP RAM variants
On Tue, May 28, 2024 at 10:35 AM Teresa Remmet wrote: > > Add support for several RAM sizes and speed grades for phyCORE-i.MX8MP. > > We have support with this series for: > - 1GB 1.5GHz > - 1GB 2GHz > - 2GB 1.5GHz (was supported before) > - 2GB 2GHz (was supported before) > - 4GB 1.5GHz > - 4GB 2GHz > - 8GB 2GHz > > RAM size and speed grade is detected and set using EEPROM data on default. > Alternative it is possible to set fix RAM size and speed over Kconfig. Applied all to u-boot-imx/next, thanks.
Re: [PATCH 0/2] Migrate PHYTEC imx8m boards to OF_UPSTREAM
On Tue, May 28, 2024 at 8:25 AM Yannic Moog wrote: > > - update MAINTAINERS > - delete synced dt files > - imply OF_UPSTREAM > - update default device tree Applied all to u-boot-imx/next, thanks.
Re: [PATCH v1 0/5] board: toradex: Add new Verdin and Aquila SKUs
On Tue, May 28, 2024 at 7:00 AM Emanuele Ghidoli wrote: > > From: Emanuele Ghidoli > > Hi, > This series adds support for 0090 PID4 Verdin iMX8M Mini Quad 4GB WB ET SKU. > It also adds two new SKUs config block support: 0088 Aquila AM69 Octa 32GB WB > IT and 0089 Verdin iMX95 Hexa 16GB WB IT. Applied all to u-boot-imx/next, thanks.
[GIT PULL] Please pull u-boot-imx-next-20240603
Hi Tom, Please pull from u-boot-imx/next, thanks. The following changes since commit 7e52d6ccfb76e2afc2d183b357abe2a2e2f948cf: Merge patch series "FWU: Add support for FWU metadata version 2" (2024-05-24 13:42:07 -0600) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-next-20240603 for you to fetch changes up to fb95661116fb4269883721afd80578e6d88ce043: imx8mm-cl-iot-gate: Add support for the Realtek RTL8211E PHY (2024-06-03 12:14:29 -0300) u-boot-imx-next-20240603 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20956 - Support different RAM sizes on imx8m phycoce boards. - Support new toradex variants. - Support Samsung 4GB DDR and Realtek RTL8211E PHY on imx8mm-cl-iot-gate. - Convert imx8mm-phycore and imx8mp-phycore boards to use OF_UPSTREAM. Benjamin Hahn (1): board: phycore_imx8mp: enable setting 2GHz timings without RAM size Emanuele Ghidoli (5): board: toradex: verdin-imx8mm: add 4 GB lpddr4 memory support board: toradex: verdin-imx8mm: increase maximum addressable ram to 4GB toradex: tdx-cfg-block: add aquila am69 sku 0088 pid4 toradex: tdx-cfg-block: add verdin imx95 sku 0089 pid4 toradex: tdx-cfg-block: add verdin i.mx8m mini 0090 pid4 Fabio Estevam (2): imx8mm-cl-iot-gate: Add support for Samsung 4GB DDR imx8mm-cl-iot-gate: Add support for the Realtek RTL8211E PHY Teresa Remmet (3): board: phytec: phycore-imx8mp: spl: Fix syle issue board: phytec: phycore_imx8mp: Add support for different RAM sizes board: phytec: phycore_imx8mp: Make RAM size configuration fix Yannic Moog (2): arm: imx8mm-phycore: move to OF_UPSTREAM arm: imx8mp-phycore: move to OF_UPSTREAM arch/arm/dts/Makefile | 3 - arch/arm/dts/imx8mm-phyboard-polis-rdk.dts | 460 --- arch/arm/dts/imx8mm-phycore-som.dtsi | 440 -- arch/arm/dts/imx8mm-phygate-tauri-l.dts| 489 - arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts| 361 --- arch/arm/dts/imx8mp-phycore-som.dtsi | 323 -- arch/arm/mach-imx/imx8m/Kconfig| 2 + board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c| 4 +- .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c| 106 - board/phytec/phycore_imx8mm/MAINTAINERS| 3 - board/phytec/phycore_imx8mp/Kconfig| 67 +++ board/phytec/phycore_imx8mp/MAINTAINERS| 1 - board/phytec/phycore_imx8mp/lpddr4_timing.c| 153 +++ board/phytec/phycore_imx8mp/lpddr4_timing.h| 16 + board/phytec/phycore_imx8mp/phycore-imx8mp.c | 11 + board/phytec/phycore_imx8mp/spl.c | 136 +++--- board/toradex/common/tdx-cfg-block.c | 3 + board/toradex/common/tdx-cfg-block.h | 3 + board/toradex/verdin-imx8mm/lpddr4_timing.c| 14 +- board/toradex/verdin-imx8mm/verdin-imx8mm.c| 5 +- configs/imx8mm-phygate-tauri-l_defconfig | 2 +- configs/phycore-imx8mm_defconfig | 2 +- configs/phycore-imx8mp_defconfig | 2 +- include/configs/imx8mm-cl-iot-gate.h | 2 +- include/configs/phycore_imx8mp.h | 4 +- include/configs/verdin-imx8mm.h| 6 +- 26 files changed, 454 insertions(+), 2164 deletions(-) delete mode 100644 arch/arm/dts/imx8mm-phyboard-polis-rdk.dts delete mode 100644 arch/arm/dts/imx8mm-phycore-som.dtsi delete mode 100644 arch/arm/dts/imx8mm-phygate-tauri-l.dts delete mode 100644 arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts delete mode 100644 arch/arm/dts/imx8mp-phycore-som.dtsi create mode 100644 board/phytec/phycore_imx8mp/lpddr4_timing.h
[PATCH v2] Makefile: Fix include directory for OF_UPSTREAM
Always prioritizing u-boot includes causes problems when trying to migrate boards to OF_UPSTREAM that have different local devicetree files with respect to the upstream ones, if local DT headers are not dropped. At the same time if local and upstream files are the same, migrations can be, and have been, introduced without dropping local DT headers. This also causes problems whenever upstream DTS and DT headers are patched. For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM breaks it, as there are some missing defines in a local DT header file (`imx6ul-clock.h`); the solution would be to drop it, which has not always been done in previous OF_UPSTREAM migration patches for other boards because most of the time the two are the same. This solution is also vulnerable to ABI breakage, although this has not yet happened since the introduction of OF_UPSTREAM support and is unlikely. Maintainers assure backwards compatibility for DT headers when syncing the upstream folder with the kernel. The problem is that, at the current state, all boards that have not dropped their local headers when migrating to OF_UPSTREAM will break once the upstream devicetrees are patched, for example, to use any newly added define which is not present in the local DT header file, even if those changes are backwards compatible. This patch fixes these problems by prioritizing upstream includes when `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when it is not. Also in case of ABI breakage in the kernel, keeping redundant header files (only until strictly necessary, e.g. until all boards including them have been migrated to OF_UPSTREAM) together with this selective prioritization of the include folder is a solution for keeping not-yet-migrated boards from breaking. Link: https://lore.kernel.org/u-boot/20240528084224.113385-1-patrick.barsa...@amarulasolutions.com/ Signed-off-by: Patrick Barsanti Tested-by: Michael Trimarchi --- Changes in v2: - Reword and correct the commit message following the discussion with Sumit, per Michael's suggestion. Makefile | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Makefile b/Makefile index 79b28c2d81..899ae664ca 100644 --- a/Makefile +++ b/Makefile @@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g) # Use UBOOTINCLUDE when you must reference the include/ directory. # Needed to be compatible with the O= option +ifeq ($(CONFIG_OF_UPSTREAM),y) +UBOOTINCLUDE:= \ + -I$(srctree)/dts/upstream/include \ + -Iinclude \ + $(if $(KBUILD_SRC), -I$(srctree)/include) \ + $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \ + $(if $(CONFIG_HAS_THUMB2), \ + $(if $(CONFIG_CPU_V7M), \ + -I$(srctree)/arch/arm/thumb1/include), \ + -I$(srctree)/arch/arm/thumb1/include)) \ + -I$(srctree)/arch/$(ARCH)/include \ + -include $(srctree)/include/linux/kconfig.h +else UBOOTINCLUDE:= \ -Iinclude \ $(if $(KBUILD_SRC), -I$(srctree)/include) \ @@ -837,6 +850,7 @@ UBOOTINCLUDE:= \ -I$(srctree)/arch/$(ARCH)/include \ -include $(srctree)/include/linux/kconfig.h \ -I$(srctree)/dts/upstream/include +endif NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) -- 2.45.1
Re: [PATCH 2/2] xilinx: zynqmp: Enable reset_cpu() in SPL
On 6/3/24 16:50, Lukas Funke wrote:
On 03.06.2024 16:32, Michal Simek wrote:
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 95a134b972d..99f5c178c1d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
+ PM_RESET_ACTION_ASSERT, 0, 0, NULL);
If you disable ZYNQMP_FIRMWARE xilinx_pm_request() should fail.
we should likely fix it in drivers/mmc/zynq_sdhci.c:114
That's an odd place for a default implementation. I'd like to move the functions
to a common location but I've no idea where. That's probably why the last
developer moved it here. Any suggestions?
static inline to include/zynqmp_firmware.h?
M
Re: [PATCH 2/2] xilinx: zynqmp: Enable reset_cpu() in SPL
On 03.06.2024 16:32, Michal Simek wrote:
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 95a134b972d..99f5c178c1d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
+ PM_RESET_ACTION_ASSERT, 0, 0, NULL);
If you disable ZYNQMP_FIRMWARE xilinx_pm_request() should fail.
we should likely fix it in drivers/mmc/zynq_sdhci.c:114
That's an odd place for a default implementation. I'd like to move the
functions to a common location but I've no idea where. That's probably
why the last developer moved it here. Any suggestions?
Thanks,
Michal
[PATCH v6] test/py: net_boot: Add test cases for net boot
Add tests for booting image using tftpboot/pxe boot commands, tftpboot
boot case loads the FIT image into DDR and boots using bootm command
whereas pxe boot cases downloads the pxe configuration file from the
TFTP server and interprets it to boot the images mentioned in the pxe
configurations file.
This test relies on boardenv_* containing configuration values including
the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the
boot log pattern value is matched. For example, if the parameter
'pattern' is defined as 'login:', it will boot till login prompt.
Signed-off-by: Love Kumar
---
Changes in v2:
- Expand commit message
Changes in v3:
- Add the config option to skip the test
- Remove imi command to check FIT image config
- Configure static networking only if DHCP fails
Changes in v4:
- Use configured timeout for tftpboot
Changes in v5:
- Add pre-req for boot test to enable error check
- Merged boot and boot config test
Changes in v6:
- Use common setup_networking function for tftp and pxe cases
- Check for bootfile env variable for pxe config name
---
test/py/tests/test_net_boot.py | 394 +
1 file changed, 394 insertions(+)
create mode 100644 test/py/tests/test_net_boot.py
diff --git a/test/py/tests/test_net_boot.py b/test/py/tests/test_net_boot.py
new file mode 100644
index ..41591b192830
--- /dev/null
+++ b/test/py/tests/test_net_boot.py
@@ -0,0 +1,394 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+import pytest
+import u_boot_utils
+import test_net
+import re
+
+"""
+Note: This test relies on boardenv_* containing configuration values to define
+which the network environment available for testing. Without this, this test
+will be automatically skipped.
+
+For example:
+
+# Details regarding a boot image file that may be read from a TFTP server. This
+# variable may be omitted or set to None if TFTP boot testing is not possible
+# or desired.
+env__net_tftp_bootable_file = {
+'fn': 'image.ub',
+'addr': 0x1000,
+'size': 5058624,
+'crc32': 'c2244b26',
+'pattern': 'Linux',
+'config': 'config@2',
+'timeout': 5,
+'check_type': 'boot_error',
+'check_pattern': 'ERROR',
+}
+
+# False or omitted if a TFTP boot test should be tested.
+# If TFTP boot testing is not possible or desired, set this variable to True.
+# For example: If FIT image is not proper to boot
+env__tftp_boot_test_skip = False
+
+# Here is the example of FIT image configurations:
+configurations {
+default = "config@1";
+config@1 {
+description = "Boot Linux kernel with config@1";
+kernel = "kernel@0";
+fdt = "fdt@0";
+ramdisk = "ramdisk@0";
+hash@1 {
+algo = "sha1";
+};
+};
+config@2 {
+description = "Boot Linux kernel with config@2";
+kernel = "kernel@1";
+fdt = "fdt@1";
+ramdisk = "ramdisk@1";
+hash@1 {
+algo = "sha1";
+};
+};
+};
+
+# Details regarding a file that may be read from a TFTP server. This variable
+# may be omitted or set to None if PXE testing is not possible or desired.
+env__net_pxe_bootable_file = {
+'fn': 'default',
+'addr': 0x1000,
+'size': 74,
+'timeout': 5,
+'pattern': 'Linux',
+'valid_label': '1',
+'invalid_label': '2',
+'exp_str_invalid': 'Skipping install for failure retrieving',
+'local_label': '3',
+'exp_str_local': 'missing environment variable: localcmd',
+'empty_label': '4',
+'exp_str_empty': 'No kernel given, skipping boot',
+'check_type': 'boot_error',
+'check_pattern': 'ERROR',
+}
+
+# False or omitted if a PXE boot test should be tested.
+# If PXE boot testing is not possible or desired, set this variable to True.
+# For example: If pxe configuration file is not proper to boot
+env__pxe_boot_test_skip = False
+
+# Here is the example of pxe configuration file ordered based on the execution
+# flow:
+1) /tftpboot/pxelinux.cfg/default-arm-zynqmp
+
+menu include pxelinux.cfg/default-arm
+timeout 50
+
+default Linux
+
+2) /tftpboot/pxelinux.cfg/default-arm
+
+menu title Linux boot selections
+menu include pxelinux.cfg/default
+
+label install
+menu label Invalid boot
+kernel kernels/install.bin
+append console=ttyAMA0,38400 debug earlyprintk
+initrd initrds/uzInitrdDebInstall
+
+label local
+menu label Local boot
+append root=/dev/sdb1
+localboot 1
+
+label boot
+menu label Empty boot
+
+3) /tftpboot/pxelinux.cfg/default
+
+label Linux
+menu label Boot kernel
+kernel Image
+fdt system.dtb
+initrd rootfs.cpio.gz.u-boot
+"""
+
+def setup_networking(u_boot_console):
+test_net.test_net_dhcp(u_boot_console)
+if not test_net.net_set_up:
+test_net.test_net_setup_static(u_boot_console)
+
+def
Re: [PATCH 2/2] xilinx: zynqmp: Enable reset_cpu() in SPL
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 95a134b972d..99f5c178c1d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
+ PM_RESET_ACTION_ASSERT, 0, 0, NULL);
If you disable ZYNQMP_FIRMWARE xilinx_pm_request() should fail.
we should likely fix it in drivers/mmc/zynq_sdhci.c:114
Thanks,
Michal
Re: [PATCH 1/2] arm64: zynqmp: Add 'SPL_ZYNQMP_FIRMWARE' to Kconfig
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
In order to make CONFIG_IS_ENABLED() work with 'ZYNQMP_FIRMWARE'
introduce an additional Kconfig 'SPL_ZYNQMP_FIRMWARE' which is selected
if and only if ZYNQMP_FIRMWARE is enabled. Driver are adapted such
that they build with and without the config being set.
Signed-off-by: Lukas Funke
---
arch/arm/mach-zynqmp/Kconfig | 2 +-
arch/arm/mach-zynqmp/aes.c | 2 ++
arch/arm/mach-zynqmp/cpu.c | 4 ++--
board/xilinx/zynqmp/zynqmp.c | 4 ++--
drivers/firmware/Kconfig | 5 +
drivers/mmc/zynq_sdhci.c | 4 ++--
drivers/pinctrl/Kconfig | 2 +-
7 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
index 0d2238ace1e..304dce45439 100644
--- a/arch/arm/mach-zynqmp/Kconfig
+++ b/arch/arm/mach-zynqmp/Kconfig
@@ -36,7 +36,7 @@ config PMUFW_INIT_FILE
config ZYNQMP_SPL_PM_CFG_OBJ_FILE
string "PMU firmware configuration object to load at runtime by SPL"
- depends on SPL
+ depends on SPL && ZYNQMP_FIRMWARE
Isn't this SPL_ZYNQMP_FIRMWARE?
help
Path to a binary PMU firmware configuration object to be linked
into U-Boot SPL and loaded at runtime into the PMU firmware.
diff --git a/arch/arm/mach-zynqmp/aes.c b/arch/arm/mach-zynqmp/aes.c
index 8a2b7fdcbe9..100dde2f372 100644
--- a/arch/arm/mach-zynqmp/aes.c
+++ b/arch/arm/mach-zynqmp/aes.c
@@ -17,6 +17,7 @@
int zynqmp_aes_operation(struct zynqmp_aes *aes)
{
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
u32 ret_payload[PAYLOAD_ARG_CNT];
int ret;
@@ -54,6 +55,7 @@ int zynqmp_aes_operation(struct zynqmp_aes *aes)
ret, ret_payload[1]);
return -EIO;
}
+#endif
return 0;
Very likely you want to return error if functionality is not present.
}
diff --git a/arch/arm/mach-zynqmp/cpu.c b/arch/arm/mach-zynqmp/cpu.c
index 6ae27894ecd..3515be257a5 100644
--- a/arch/arm/mach-zynqmp/cpu.c
+++ b/arch/arm/mach-zynqmp/cpu.c
@@ -188,7 +188,7 @@ int zynqmp_mmio_write(const u32 address,
{
if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3)
return zynqmp_mmio_rawwrite(address, mask, value);
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
else
return xilinx_pm_request(PM_MMIO_WRITE, address, mask,
value, 0, NULL);
@@ -207,7 +207,7 @@ int zynqmp_mmio_read(const u32 address, u32 *value)
if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
ret = zynqmp_mmio_rawread(address, value);
}
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
else {
u32 ret_payload[PAYLOAD_ARG_CNT];
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f370fb7347a..95a134b972d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -147,14 +147,14 @@ int board_init(void)
int ret;
#endif
-#if defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_SPL_BUILD) && CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
/* Check *at build time* if the filename is an non-empty string */
if (sizeof(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE) > 1)
zynqmp_pmufw_load_config_object(zynqmp_pm_cfg_obj,
zynqmp_pm_cfg_obj_size);
#endif
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
struct udevice *dev;
uclass_get_device_by_name(UCLASS_FIRMWARE, "power-management", );
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 8789b1ea141..ae785d55d54 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -30,6 +30,7 @@ config TI_SCI_PROTOCOL
config ZYNQMP_FIRMWARE
bool "ZynqMP Firmware interface"
select FIRMWARE
+ select SPL_ZYNQMP_FIRMWARE if SPL
I don't think this is correct. Why you should connect SPL symbol with non SPL
one?
I would just remove line above that I can enable/disable firmware in SPL or
U-Boot separately.
help
Firmware interface driver is used by different
drivers to communicate with the firmware for
@@ -37,6 +38,10 @@ config ZYNQMP_FIRMWARE
Say yes to enable ZynqMP firmware interface driver.
If in doubt, say N.
+config SPL_ZYNQMP_FIRMWARE
+ bool "Enable ZynqMP Firmware interface in SPL"
Can we remove "Enable" at the beginning? Or add Enable it to ZYNQMP_FIRMWARE.
+ depends on FIRMWARE && SPL
+
config ARM_SMCCC_FEATURES
bool "Arm SMCCC features discovery"
depends on ARM_PSCI_FW
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 935540d1719..3e4cae60c17 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -992,7 +992,7 @@ static const struct sdhci_ops arasan_ops = {
};
[PATCH v1 4/4] riscv: dts: jh7110: Sync clock and reset definitions with Linux
The JH7110 clock and reset dt-bindings are synchronized with Linux,
so update the clock and reset definitions in device tree accordingly.
Signed-off-by: Hal Feng
---
.../dts/jh7110-starfive-visionfive-2.dtsi | 6 ++--
arch/riscv/dts/jh7110-u-boot.dtsi | 2 +-
arch/riscv/dts/jh7110.dtsi| 28 +--
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
index e11babc1cd..2666fd4696 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
@@ -334,9 +334,9 @@
< JH7110_SYSCLK_BUS_ROOT>,
< JH7110_SYSCLK_PERH_ROOT>,
< JH7110_SYSCLK_QSPI_REF>;
- assigned-clock-parents = < JH7110_SYSCLK_PLL0_OUT>,
-< JH7110_SYSCLK_PLL2_OUT>,
-< JH7110_SYSCLK_PLL2_OUT>,
+ assigned-clock-parents = < JH7110_PLLCLK_PLL0_OUT>,
+< JH7110_PLLCLK_PLL2_OUT>,
+< JH7110_PLLCLK_PLL2_OUT>,
< JH7110_SYSCLK_QSPI_REF_SRC>;
assigned-clock-rates = <0>, <0>, <0>, <0>;
};
diff --git a/arch/riscv/dts/jh7110-u-boot.dtsi
b/arch/riscv/dts/jh7110-u-boot.dtsi
index c09d5c9170..56530cf4c2 100644
--- a/arch/riscv/dts/jh7110-u-boot.dtsi
+++ b/arch/riscv/dts/jh7110-u-boot.dtsi
@@ -62,7 +62,7 @@
< JH7110_SYSRST_DDR_OSC>,
< JH7110_SYSRST_DDR_APB>;
reset-names = "axi", "osc", "apb";
- clocks = < JH7110_SYSCLK_PLL1_OUT>;
+ clocks = < JH7110_PLLCLK_PLL1_OUT>;
clock-names = "pll1_out";
clock-frequency = <2133>;
};
diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
index 2cdc683d49..dbce57c421 100644
--- a/arch/riscv/dts/jh7110.dtsi
+++ b/arch/riscv/dts/jh7110.dtsi
@@ -503,9 +503,9 @@
<_bclk_ext>, <_lrck_ext>,
<_bclk_ext>, <_lrck_ext>,
<_ext>, <_ext>,
-< JH7110_SYSCLK_PLL0_OUT>,
-< JH7110_SYSCLK_PLL1_OUT>,
-< JH7110_SYSCLK_PLL2_OUT>;
+< JH7110_PLLCLK_PLL0_OUT>,
+< JH7110_PLLCLK_PLL1_OUT>,
+< JH7110_PLLCLK_PLL2_OUT>;
clock-names = "osc", "gmac1_rmii_refin",
"gmac1_rgmii_rxin",
"i2stx_bclk_ext", "i2stx_lrck_ext",
@@ -646,10 +646,10 @@
rng: rng@1600c000 {
compatible = "starfive,jh7110-trng";
reg = <0x0 0x1600C000 0x0 0x4000>;
- clocks = < JH7110_STGCLK_SEC_HCLK>,
-< JH7110_STGCLK_SEC_MISCAHB>;
+ clocks = < JH7110_STGCLK_SEC_AHB>,
+< JH7110_STGCLK_SEC_MISC_AHB>;
clock-names = "hclk", "ahb";
- resets = < JH7110_STGRST_SEC_TOP_HRESETN>;
+ resets = < JH7110_STGRST_SEC_AHB>;
interrupts = <30>;
};
@@ -707,12 +707,12 @@
bus-range = <0x0 0xff>;
clocks = < JH7110_SYSCLK_NOC_BUS_STG_AXI>,
< JH7110_STGCLK_PCIE0_TL>,
-< JH7110_STGCLK_PCIE0_AXI>,
+< JH7110_STGCLK_PCIE0_AXI_MST0>,
< JH7110_STGCLK_PCIE0_APB>;
clock-names = "noc", "tl", "axi", "apb";
- resets = < JH7110_STGRST_PCIE0_MST0>,
-< JH7110_STGRST_PCIE0_SLV0>,
-< JH7110_STGRST_PCIE0_SLV>,
+ resets = < JH7110_STGRST_PCIE0_AXI_MST0>,
+< JH7110_STGRST_PCIE0_AXI_SLV0>,
+< JH7110_STGRST_PCIE0_AXI_SLV>,
< JH7110_STGRST_PCIE0_BRG>,
< JH7110_STGRST_PCIE0_CORE>,
< JH7110_STGRST_PCIE0_APB>;
@@ -744,12 +744,12 @@
bus-range = <0x0 0xff>;
clocks = < JH7110_SYSCLK_NOC_BUS_STG_AXI>,
< JH7110_STGCLK_PCIE1_TL>,
-< JH7110_STGCLK_PCIE1_AXI>,
+< JH7110_STGCLK_PCIE1_AXI_MST0>,
< JH7110_STGCLK_PCIE1_APB>;
clock-names = "noc", "tl", "axi",
[PATCH v1 3/4] clk: starfive: jh7110: Sync clock definitions with Linux
The JH7110 clock dt-bindings is synchronized with Linux,
so update the clock definitions in drivers accordingly.
Signed-off-by: Hal Feng
---
drivers/clk/starfive/clk-jh7110-pll.c | 6 ++--
drivers/clk/starfive/clk-jh7110.c | 44 +--
2 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/clk/starfive/clk-jh7110-pll.c
b/drivers/clk/starfive/clk-jh7110-pll.c
index 1568a1f4cd..96beacb4fa 100644
--- a/drivers/clk/starfive/clk-jh7110-pll.c
+++ b/drivers/clk/starfive/clk-jh7110-pll.c
@@ -375,13 +375,13 @@ static int jh7110_pll_clk_probe(struct udevice *dev)
if (sysreg == FDT_ADDR_T_NONE)
return -EINVAL;
- clk_dm(JH7110_PLL_ID_TRANS(JH7110_SYSCLK_PLL0_OUT),
+ clk_dm(JH7110_PLL_ID_TRANS(JH7110_PLLCLK_PLL0_OUT),
starfive_jh7110_pll("pll0_out", "oscillator", reg,
(void __iomem *)sysreg,
_jh7110_pll0));
- clk_dm(JH7110_PLL_ID_TRANS(JH7110_SYSCLK_PLL1_OUT),
+ clk_dm(JH7110_PLL_ID_TRANS(JH7110_PLLCLK_PLL1_OUT),
starfive_jh7110_pll("pll1_out", "oscillator", reg,
(void __iomem *)sysreg,
_jh7110_pll1));
- clk_dm(JH7110_PLL_ID_TRANS(JH7110_SYSCLK_PLL2_OUT),
+ clk_dm(JH7110_PLL_ID_TRANS(JH7110_PLLCLK_PLL2_OUT),
starfive_jh7110_pll("pll2_out", "oscillator", reg,
(void __iomem *)sysreg,
_jh7110_pll2));
diff --git a/drivers/clk/starfive/clk-jh7110.c
b/drivers/clk/starfive/clk-jh7110.c
index a38694809a..523342128e 100644
--- a/drivers/clk/starfive/clk-jh7110.c
+++ b/drivers/clk/starfive/clk-jh7110.c
@@ -496,37 +496,37 @@ static int jh7110_stgcrg_init(struct udevice *dev)
{
struct jh7110_clk_priv *priv = dev_get_priv(dev);
- clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB_APB),
+ clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB0_APB),
starfive_clk_gate(priv->reg,
"usb_apb", "apb_bus",
-OFFSET(JH7110_STGCLK_USB_APB)));
- clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB_UTMI_APB),
+OFFSET(JH7110_STGCLK_USB0_APB)));
+ clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB0_UTMI_APB),
starfive_clk_gate(priv->reg,
"usb_utmi_apb", "apb_bus",
-OFFSET(JH7110_STGCLK_USB_UTMI_APB)));
- clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB_AXI),
+OFFSET(JH7110_STGCLK_USB0_UTMI_APB)));
+ clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB0_AXI),
starfive_clk_gate(priv->reg,
"usb_axi", "stg_axiahb",
-OFFSET(JH7110_STGCLK_USB_AXI)));
- clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB_LPM),
+OFFSET(JH7110_STGCLK_USB0_AXI)));
+ clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB0_LPM),
starfive_clk_gate_divider(priv->reg,
"usb_lpm", "oscillator",
-OFFSET(JH7110_STGCLK_USB_LPM), 2));
- clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB_STB),
+OFFSET(JH7110_STGCLK_USB0_LPM), 2));
+ clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB0_STB),
starfive_clk_gate_divider(priv->reg,
"usb_stb", "oscillator",
-OFFSET(JH7110_STGCLK_USB_STB), 3));
- clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB_APP_125),
+OFFSET(JH7110_STGCLK_USB0_STB), 3));
+ clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB0_APP_125),
starfive_clk_gate(priv->reg,
"usb_app_125", "usb_125m",
-OFFSET(JH7110_STGCLK_USB_APP_125)));
- clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB_REFCLK),
+OFFSET(JH7110_STGCLK_USB0_APP_125)));
+ clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_USB0_REFCLK),
starfive_clk_divider(priv->reg, "usb_refclk", "oscillator",
- OFFSET(JH7110_STGCLK_USB_REFCLK), 2));
- clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_PCIE0_AXI),
+ OFFSET(JH7110_STGCLK_USB0_REFCLK), 2));
+ clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_PCIE0_AXI_MST0),
starfive_clk_gate(priv->reg,
"pcie0_axi", "stg_axiahb",
-OFFSET(JH7110_STGCLK_PCIE0_AXI)));
+OFFSET(JH7110_STGCLK_PCIE0_AXI_MST0)));
clk_dm(JH7110_STG_ID_TRANS(JH7110_STGCLK_PCIE0_APB),
starfive_clk_gate(priv->reg,
"pcie0_apb", "apb_bus",
@@ -535,10 +535,10 @@ static int jh7110_stgcrg_init(struct udevice
[PATCH v1 2/4] dt-bindings: reset: jh7110: Sync with Linux
Sync JH7110 reset dt-bindings with Linux, which is the same with dts/upstream/include/dt-bindings/reset/starfive,jh7110-crg.h except copyright. Signed-off-by: Hal Feng --- .../dt-bindings/reset/starfive,jh7110-crg.h | 144 +++--- 1 file changed, 88 insertions(+), 56 deletions(-) diff --git a/include/dt-bindings/reset/starfive,jh7110-crg.h b/include/dt-bindings/reset/starfive,jh7110-crg.h index 1d596581da..771b1aecd0 100644 --- a/include/dt-bindings/reset/starfive,jh7110-crg.h +++ b/include/dt-bindings/reset/starfive,jh7110-crg.h @@ -5,13 +5,13 @@ * Author: Yanhong Wang */ -#ifndef __DT_BINDINGS_RESET_STARFIVE_JH7110_H__ -#define __DT_BINDINGS_RESET_STARFIVE_JH7110_H__ +#ifndef __DT_BINDINGS_RESET_STARFIVE_JH7110_CRG_H__ +#define __DT_BINDINGS_RESET_STARFIVE_JH7110_CRG_H__ /* SYSCRG resets */ -#define JH7110_SYSRST_JTAG2APB 0 -#define JH7110_SYSRST_SYSCON 1 -#define JH7110_SYSRST_IOMUX_APB2 +#define JH7110_SYSRST_JTAG_APB 0 +#define JH7110_SYSRST_SYSCON_APB 1 +#define JH7110_SYSRST_IOMUX_APB2 #define JH7110_SYSRST_BUS 3 #define JH7110_SYSRST_DEBUG4 #define JH7110_SYSRST_CORE05 @@ -29,10 +29,10 @@ #define JH7110_SYSRST_TRACE2 17 #define JH7110_SYSRST_TRACE3 18 #define JH7110_SYSRST_TRACE4 19 -#define JH7110_SYSRST_TRACE_COM20 +#define JH7110_SYSRST_TRACE_COM20 #define JH7110_SYSRST_GPU_APB 21 #define JH7110_SYSRST_GPU_DOMA 22 -#define JH7110_SYSRST_NOC_BUS_APB_BUS 23 +#define JH7110_SYSRST_NOC_BUS_APB 23 #define JH7110_SYSRST_NOC_BUS_AXICFG0_AXI 24 #define JH7110_SYSRST_NOC_BUS_CPU_AXI 25 #define JH7110_SYSRST_NOC_BUS_DISP_AXI 26 @@ -43,17 +43,17 @@ #define JH7110_SYSRST_NOC_BUS_VDEC_AXI 31 #define JH7110_SYSRST_NOC_BUS_VENC_AXI 32 -#define JH7110_SYSRST_AXI_CFG1_DEC_AHB 33 -#define JH7110_SYSRST_AXI_CFG1_DEC_MAIN34 -#define JH7110_SYSRST_AXI_CFG0_DEC_MAIN35 -#define JH7110_SYSRST_AXI_CFG0_DEC_MAIN_DIV36 -#define JH7110_SYSRST_AXI_CFG0_DEC_HIFI4 37 +#define JH7110_SYSRST_AXI_CFG1_AHB 33 +#define JH7110_SYSRST_AXI_CFG1_MAIN34 +#define JH7110_SYSRST_AXI_CFG0_MAIN35 +#define JH7110_SYSRST_AXI_CFG0_MAIN_DIV36 +#define JH7110_SYSRST_AXI_CFG0_HIFI4 37 #define JH7110_SYSRST_DDR_AXI 38 #define JH7110_SYSRST_DDR_OSC 39 #define JH7110_SYSRST_DDR_APB 40 -#define JH7110_SYSRST_DOM_ISP_TOP_N41 -#define JH7110_SYSRST_DOM_ISP_TOP_AXI 42 -#define JH7110_SYSRST_DOM_VOUT_TOP_SRC 43 +#define JH7110_SYSRST_ISP_TOP 41 +#define JH7110_SYSRST_ISP_TOP_AXI 42 +#define JH7110_SYSRST_VOUT_TOP_SRC 43 #define JH7110_SYSRST_CODAJ12_AXI 44 #define JH7110_SYSRST_CODAJ12_CORE 45 #define JH7110_SYSRST_CODAJ12_APB 46 @@ -61,8 +61,8 @@ #define JH7110_SYSRST_WAVE511_BPU 48 #define JH7110_SYSRST_WAVE511_VCE 49 #define JH7110_SYSRST_WAVE511_APB 50 -#define JH7110_SYSRST_VDEC_JPG_ARB_JPG 51 -#define JH7110_SYSRST_VDEC_JPG_ARB_MAIN52 +#define JH7110_SYSRST_VDEC_JPG 51 +#define JH7110_SYSRST_VDEC_MAIN52 #define JH7110_SYSRST_AXIMEM0_AXI 53 #define JH7110_SYSRST_WAVE420L_AXI 54 #define JH7110_SYSRST_WAVE420L_BPU 55 @@ -75,11 +75,11 @@ #define JH7110_SYSRST_QSPI_APB 62 #define JH7110_SYSRST_QSPI_REF 63 -#define JH7110_SYSRST_SDIO0_AHB64 -#define JH7110_SYSRST_SDIO1_AHB65 -#define JH7110_SYSRST_GMAC1_AXI66 -#define JH7110_SYSRST_GMAC1_AHB67 -#define JH7110_SYSRST_MAILBOX 68 +#define JH7110_SYSRST_SDIO0_AHB64 +#define JH7110_SYSRST_SDIO1_AHB65 +#define JH7110_SYSRST_GMAC1_AXI66 +#define JH7110_SYSRST_GMAC1_AHB67 +#define JH7110_SYSRST_MAILBOX_APB 68 #define JH7110_SYSRST_SPI0_APB 69 #define JH7110_SYSRST_SPI1_APB 70 #define JH7110_SYSRST_SPI2_APB 71 @@ -94,24 +94,24 @@ #define JH7110_SYSRST_I2C4_APB 80 #define JH7110_SYSRST_I2C5_APB 81 #define JH7110_SYSRST_I2C6_APB 82 -#define JH7110_SYSRST_UART0_APB83 +#define JH7110_SYSRST_UART0_APB83 #define JH7110_SYSRST_UART0_CORE 84 -#define JH7110_SYSRST_UART1_APB85 +#define JH7110_SYSRST_UART1_APB85 #define
[PATCH v1 1/4] dt-bindings: clock: jh7110: Sync with Linux
Sync JH7110 clock dt-bindings with Linux, which is the same with dts/upstream/include/dt-bindings/clock/starfive,jh7110-crg.h except copyright. Signed-off-by: Hal Feng --- .../dt-bindings/clock/starfive,jh7110-crg.h | 180 +++--- 1 file changed, 112 insertions(+), 68 deletions(-) diff --git a/include/dt-bindings/clock/starfive,jh7110-crg.h b/include/dt-bindings/clock/starfive,jh7110-crg.h index b51e3829ff..4eabb05473 100644 --- a/include/dt-bindings/clock/starfive,jh7110-crg.h +++ b/include/dt-bindings/clock/starfive,jh7110-crg.h @@ -5,19 +5,21 @@ * Author: Yanhong Wang */ -#ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_H__ -#define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_H__ +#ifndef __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__ +#define __DT_BINDINGS_CLOCK_STARFIVE_JH7110_CRG_H__ -#define JH7110_SYSCLK_PLL0_OUT 0 -#define JH7110_SYSCLK_PLL1_OUT 1 -#define JH7110_SYSCLK_PLL2_OUT 2 +/* PLL clocks */ +#define JH7110_PLLCLK_PLL0_OUT 0 +#define JH7110_PLLCLK_PLL1_OUT 1 +#define JH7110_PLLCLK_PLL2_OUT 2 #define JH7110_PLLCLK_END 3 +/* SYSCRG clocks */ #define JH7110_SYSCLK_CPU_ROOT 0 #define JH7110_SYSCLK_CPU_CORE 1 #define JH7110_SYSCLK_CPU_BUS 2 #define JH7110_SYSCLK_GPU_ROOT 3 -#define JH7110_SYSCLK_PERH_ROOT4 +#define JH7110_SYSCLK_PERH_ROOT4 #define JH7110_SYSCLK_BUS_ROOT 5 #define JH7110_SYSCLK_NOCSTG_BUS 6 #define JH7110_SYSCLK_AXI_CFG0 7 @@ -26,9 +28,9 @@ #define JH7110_SYSCLK_AHB1 10 #define JH7110_SYSCLK_APB_BUS 11 #define JH7110_SYSCLK_APB0 12 -#define JH7110_SYSCLK_PLL0_DIV213 -#define JH7110_SYSCLK_PLL1_DIV214 -#define JH7110_SYSCLK_PLL2_DIV215 +#define JH7110_SYSCLK_PLL0_DIV213 +#define JH7110_SYSCLK_PLL1_DIV214 +#define JH7110_SYSCLK_PLL2_DIV215 #define JH7110_SYSCLK_AUDIO_ROOT 16 #define JH7110_SYSCLK_MCLK_INNER 17 #define JH7110_SYSCLK_MCLK 18 @@ -50,12 +52,12 @@ #define JH7110_SYSCLK_TRACE2 34 #define JH7110_SYSCLK_TRACE3 35 #define JH7110_SYSCLK_TRACE4 36 -#define JH7110_SYSCLK_TRACE_COM37 +#define JH7110_SYSCLK_TRACE_COM37 #define JH7110_SYSCLK_NOC_BUS_CPU_AXI 38 #define JH7110_SYSCLK_NOC_BUS_AXICFG0_AXI 39 #define JH7110_SYSCLK_OSC_DIV2 40 -#define JH7110_SYSCLK_PLL1_DIV441 -#define JH7110_SYSCLK_PLL1_DIV842 +#define JH7110_SYSCLK_PLL1_DIV441 +#define JH7110_SYSCLK_PLL1_DIV842 #define JH7110_SYSCLK_DDR_BUS 43 #define JH7110_SYSCLK_DDR_AXI 44 #define JH7110_SYSCLK_GPU_CORE 45 @@ -64,21 +66,21 @@ #define JH7110_SYSCLK_GPU_APB 48 #define JH7110_SYSCLK_GPU_RTC_TOGGLE 49 #define JH7110_SYSCLK_NOC_BUS_GPU_AXI 50 -#define JH7110_SYSCLK_ISP_TOP_CLK_ISPCORE_2X 51 -#define JH7110_SYSCLK_ISP_TOP_CLK_ISP_AXI 52 +#define JH7110_SYSCLK_ISP_TOP_CORE 51 +#define JH7110_SYSCLK_ISP_TOP_AXI 52 #define JH7110_SYSCLK_NOC_BUS_ISP_AXI 53 #define JH7110_SYSCLK_HIFI4_CORE 54 -#define JH7110_SYSCLK_HIFI4_AXI55 -#define JH7110_SYSCLK_AXI_CFG1_DEC_MAIN56 -#define JH7110_SYSCLK_AXI_CFG1_DEC_AHB 57 +#define JH7110_SYSCLK_HIFI4_AXI55 +#define JH7110_SYSCLK_AXI_CFG1_MAIN56 +#define JH7110_SYSCLK_AXI_CFG1_AHB 57 #define JH7110_SYSCLK_VOUT_SRC 58 #define JH7110_SYSCLK_VOUT_AXI 59 #define JH7110_SYSCLK_NOC_BUS_DISP_AXI 60 -#define JH7110_SYSCLK_VOUT_TOP_CLK_VOUT_AHB61 -#define JH7110_SYSCLK_VOUT_TOP_CLK_VOUT_AXI62 -#define JH7110_SYSCLK_VOUT_TOP_CLK_HDMITX0_MCLK63 -#define JH7110_SYSCLK_VOUT_TOP_CLK_MIPIPHY_REF 64 -#define JH7110_SYSCLK_JPEGC_AXI65 +#define JH7110_SYSCLK_VOUT_TOP_AHB 61 +#define JH7110_SYSCLK_VOUT_TOP_AXI 62 +#define JH7110_SYSCLK_VOUT_TOP_HDMITX0_MCLK63 +#define JH7110_SYSCLK_VOUT_TOP_MIPIPHY_REF 64 +#define JH7110_SYSCLK_JPEGC_AXI65 #define JH7110_SYSCLK_CODAJ12_AXI 66 #define JH7110_SYSCLK_CODAJ12_CORE 67 #define JH7110_SYSCLK_CODAJ12_APB 68 @@ -87,8 +89,8 @@ #define JH7110_SYSCLK_WAVE511_BPU 71 #define JH7110_SYSCLK_WAVE511_VCE 72 #define JH7110_SYSCLK_WAVE511_APB 73 -#define JH7110_SYSCLK_VDEC_JPG_ARB_JPG 74
[PATCH v1 0/4] Sync StarFive JH7110 clock and reset dt-bindings with Linux
There are differences in clock / reset dt-bindings between U-Boot and Linux. Sync them, so it is feasible to use OF_UPSTREAM for StarFive JH7110 SoC. Hal Feng (4): dt-bindings: clock: jh7110: Sync with Linux dt-bindings: reset: jh7110: Sync with Linux clk: starfive: jh7110: Sync clock definitions with Linux riscv: dts: jh7110: Sync clock and reset definitions with Linux .../dts/jh7110-starfive-visionfive-2.dtsi | 6 +- arch/riscv/dts/jh7110-u-boot.dtsi | 2 +- arch/riscv/dts/jh7110.dtsi| 28 +-- drivers/clk/starfive/clk-jh7110-pll.c | 6 +- drivers/clk/starfive/clk-jh7110.c | 44 ++--- .../dt-bindings/clock/starfive,jh7110-crg.h | 180 +++--- .../dt-bindings/reset/starfive,jh7110-crg.h | 144 -- 7 files changed, 243 insertions(+), 167 deletions(-) base-commit: ea722aa5eb33740ae77e8816aeb72b385e621cd0 -- 2.43.2
Re: [PATCH v3 8/8] qcom_defconfig: enable capsule update support
On Mon, 3 Jun 2024 at 15:49, Caleb Connolly wrote: > > Enable all the necessary options for capsule updates to work, as well as > a few additional EFI features. > > Signed-off-by: Caleb Connolly > --- > configs/qcom_defconfig | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig > index f2dfced4bc1e..d1de7158e3f5 100644 > --- a/configs/qcom_defconfig > +++ b/configs/qcom_defconfig > @@ -19,33 +19,39 @@ CONFIG_LOG_MAX_LEVEL=9 > CONFIG_LOG_DEFAULT_LEVEL=4 > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > CONFIG_CMD_BOOTMENU=y > +CONFIG_CMD_NVEDIT_EFI=y > CONFIG_CMD_EEPROM=y > CONFIG_SYS_I2C_EEPROM_BUS=2 > CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 > CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5 > # CONFIG_CMD_BIND is not set > CONFIG_CMD_CLK=y > +CONFIG_CMD_DFU=y > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_CMD_MMC=y > CONFIG_CMD_UFS=y > CONFIG_CMD_USB=y > CONFIG_CMD_CAT=y > CONFIG_CMD_BMP=y > +CONFIG_CMD_EFIDEBUG=y > CONFIG_CMD_LOG=y > CONFIG_OF_LIVE=y > CONFIG_BUTTON_QCOM_PMIC=y > CONFIG_CLK=y > +CONFIG_CLK_STUB=y > CONFIG_CLK_QCOM_QCM2290=y > CONFIG_CLK_QCOM_QCS404=y > CONFIG_CLK_QCOM_SDM845=y > CONFIG_CLK_QCOM_SM6115=y > CONFIG_CLK_QCOM_SM8250=y > CONFIG_CLK_QCOM_SM8550=y > CONFIG_CLK_QCOM_SM8650=y > -CONFIG_CLK_STUB=y > +CONFIG_DFU_MMC=y > +CONFIG_DFU_SCSI=y > +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x20 > CONFIG_MSM_GPIO=y > CONFIG_QCOM_PMIC_GPIO=y > CONFIG_DM_I2C=y > CONFIG_SYS_I2C_QUP=y > @@ -105,6 +111,10 @@ CONFIG_VIDEO=y > CONFIG_VIDEO_FONT_16X32=y > CONFIG_SYS_WHITE_ON_BLACK=y > CONFIG_NO_FB_CLEAR=y > CONFIG_VIDEO_SIMPLE=y > -CONFIG_HEXDUMP=y > +CONFIG_SYMBOL_LOOKUP=y > +CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y > +CONFIG_EFI_CAPSULE_ON_DISK=y > +CONFIG_EFI_IGNORE_OSINDICATIONS=y > +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y > CONFIG_LMB_MAX_REGIONS=64 > > -- > 2.45.0 > Reviewed-by: Ilias Apalodimas
Re: [PATCH v3 4/8] mach-snapdragon: implement capsule update support
Hi Caleb,
On Mon, 3 Jun 2024 at 15:49, Caleb Connolly wrote:
>
> Qualcomm boards flash U-Boot to the boot partition, implement support
> for determining which slot U-Boot is running from and finding the
> correct boot partition for that slot and configuring the appropriate DFU
> string.
>
> For now this only supports boards with SCSI/UFS storage where U-Boot is
> flashed to the boot partition, and only U-Boot itself is updated. In the
> future we may also support updating additional firmware components (tz,
> hyp, xbl) as well as having U-Boot installed to other partitions (e.g.
> as a first-stage bootloader).
>
> Signed-off-by: Caleb Connolly
> ---
> arch/arm/mach-snapdragon/Makefile | 1 +
> arch/arm/mach-snapdragon/board.c | 3 +
> arch/arm/mach-snapdragon/capsule_update.c | 147
> ++
> arch/arm/mach-snapdragon/qcom-priv.h | 6 ++
> include/configs/qcom.h| 5 +
> 5 files changed, 162 insertions(+)
>
> diff --git a/arch/arm/mach-snapdragon/Makefile
> b/arch/arm/mach-snapdragon/Makefile
> index 7a4495c8108f..343e825c6fdd 100644
> --- a/arch/arm/mach-snapdragon/Makefile
> +++ b/arch/arm/mach-snapdragon/Makefile
> @@ -2,5 +2,6 @@
> #
> # (C) Copyright 2015 Mateusz Kulikowski
>
> obj-y += board.o
> +obj-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += capsule_update.o
> obj-$(CONFIG_OF_LIVE) += of_fixup.o
> diff --git a/arch/arm/mach-snapdragon/board.c
> b/arch/arm/mach-snapdragon/board.c
> index b439a19ec7eb..c4a3394706e6 100644
> --- a/arch/arm/mach-snapdragon/board.c
> +++ b/arch/arm/mach-snapdragon/board.c
> @@ -299,8 +299,11 @@ int board_late_init(void)
>
> configure_env();
> qcom_late_init();
>
> + /* Configure the dfu_string for capsule updates */
> + qcom_configure_capsule_updates();
> +
> return 0;
> }
>
> static void build_mem_map(void)
> diff --git a/arch/arm/mach-snapdragon/capsule_update.c
> b/arch/arm/mach-snapdragon/capsule_update.c
> new file mode 100644
> index ..505f5bf5ae07
> --- /dev/null
> +++ b/arch/arm/mach-snapdragon/capsule_update.c
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Common initialisation for Qualcomm Snapdragon boards.
initialization
> + *
> + * Copyright (c) 2024 Linaro Ltd.
> + * Author: Caleb Connolly
> + */
> +
> +#define pr_fmt(fmt) "QCOM-FMP: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "qcom-priv.h"
> +
> +struct efi_fw_image fw_images[] = {
> + {
> + .image_type_id = QUALCOMM_UBOOT_BOOT_IMAGE_GUID,
> + .fw_name = u"QUALCOMM-UBOOT",
> + .image_index = 1,
> + },
> +};
> +
> +struct efi_capsule_update_info update_info = {
> + /* Filled in by configure_dfu_string() */
> + .dfu_string = NULL,
> + .num_images = ARRAY_SIZE(fw_images),
> + .images = fw_images,
> +};
> +
> +/* LSB first */
> +struct part_slot_status {
> + u16: 2;
> + u16 active : 1;
> + u16: 3;
> + u16 successful : 1;
> + u16 unbootable : 1;
> + u16 tries_remaining : 4;
> +};
This is part of their first-stage boot loader and can't change right?
[...]
> +/**
> + * qcom_configure_capsule_updates() - Configure the DFU string for capsule
> updates
> + *
> + * U-Boot is flashed to the boot partition on Qualcomm boards. In most cases
> there
> + * are two boot partitions, boot_a and boot_b. As we don't currently support
> doing
> + * full A/B updates, we only support updating the currently active boot
> partition.
> + *
> + * So we need to find the current slot suffix and the associated boot
> partition.
> + * We do this by looking for the boot partition that has the 'active' flag
> set
> + * in the GPT partition vendor attribute bits.
> + */
> +void qcom_configure_capsule_updates(void)
> +{
> + struct blk_desc *desc;
> + int ret = 0, partnum = -1, devnum;
> + static char dfu_string[32] = { 0 };
Use PART_NAME_LEN here, since that's the length struct disk_partition
defines (and the one you end up copying)
> + char name[32]; /* GPT partition name */
> + char *partname = "boot";
> + struct udevice *dev = NULL;
> +
> + /*
> +* There is currently no good way to check how U-Boot is booting, but
> we have
> +* a few hueristics, like here checking if our DTB has a kaslr-seed
> specified
heuristics
> +* will tell us if we were chainloaded by another bootloader.
> +* FIXME: we should do this check once and use some proper API to
> expose the data.
> +*/
> + if (!ofnode_has_property(ofnode_path("/chosen"), "kaslr-seed")) {
[...]
Acked-by: Ilias Apalodimas
[PATCH 1/2] arm64: zynqmp: Add 'SPL_ZYNQMP_FIRMWARE' to Kconfig
From: Lukas Funke
In order to make CONFIG_IS_ENABLED() work with 'ZYNQMP_FIRMWARE'
introduce an additional Kconfig 'SPL_ZYNQMP_FIRMWARE' which is selected
if and only if ZYNQMP_FIRMWARE is enabled. Driver are adapted such
that they build with and without the config being set.
Signed-off-by: Lukas Funke
---
arch/arm/mach-zynqmp/Kconfig | 2 +-
arch/arm/mach-zynqmp/aes.c | 2 ++
arch/arm/mach-zynqmp/cpu.c | 4 ++--
board/xilinx/zynqmp/zynqmp.c | 4 ++--
drivers/firmware/Kconfig | 5 +
drivers/mmc/zynq_sdhci.c | 4 ++--
drivers/pinctrl/Kconfig | 2 +-
7 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
index 0d2238ace1e..304dce45439 100644
--- a/arch/arm/mach-zynqmp/Kconfig
+++ b/arch/arm/mach-zynqmp/Kconfig
@@ -36,7 +36,7 @@ config PMUFW_INIT_FILE
config ZYNQMP_SPL_PM_CFG_OBJ_FILE
string "PMU firmware configuration object to load at runtime by SPL"
- depends on SPL
+ depends on SPL && ZYNQMP_FIRMWARE
help
Path to a binary PMU firmware configuration object to be linked
into U-Boot SPL and loaded at runtime into the PMU firmware.
diff --git a/arch/arm/mach-zynqmp/aes.c b/arch/arm/mach-zynqmp/aes.c
index 8a2b7fdcbe9..100dde2f372 100644
--- a/arch/arm/mach-zynqmp/aes.c
+++ b/arch/arm/mach-zynqmp/aes.c
@@ -17,6 +17,7 @@
int zynqmp_aes_operation(struct zynqmp_aes *aes)
{
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
u32 ret_payload[PAYLOAD_ARG_CNT];
int ret;
@@ -54,6 +55,7 @@ int zynqmp_aes_operation(struct zynqmp_aes *aes)
ret, ret_payload[1]);
return -EIO;
}
+#endif
return 0;
}
diff --git a/arch/arm/mach-zynqmp/cpu.c b/arch/arm/mach-zynqmp/cpu.c
index 6ae27894ecd..3515be257a5 100644
--- a/arch/arm/mach-zynqmp/cpu.c
+++ b/arch/arm/mach-zynqmp/cpu.c
@@ -188,7 +188,7 @@ int zynqmp_mmio_write(const u32 address,
{
if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3)
return zynqmp_mmio_rawwrite(address, mask, value);
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
else
return xilinx_pm_request(PM_MMIO_WRITE, address, mask,
value, 0, NULL);
@@ -207,7 +207,7 @@ int zynqmp_mmio_read(const u32 address, u32 *value)
if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
ret = zynqmp_mmio_rawread(address, value);
}
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
else {
u32 ret_payload[PAYLOAD_ARG_CNT];
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f370fb7347a..95a134b972d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -147,14 +147,14 @@ int board_init(void)
int ret;
#endif
-#if defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_SPL_BUILD) && CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
/* Check *at build time* if the filename is an non-empty string */
if (sizeof(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE) > 1)
zynqmp_pmufw_load_config_object(zynqmp_pm_cfg_obj,
zynqmp_pm_cfg_obj_size);
#endif
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
struct udevice *dev;
uclass_get_device_by_name(UCLASS_FIRMWARE, "power-management", );
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 8789b1ea141..ae785d55d54 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -30,6 +30,7 @@ config TI_SCI_PROTOCOL
config ZYNQMP_FIRMWARE
bool "ZynqMP Firmware interface"
select FIRMWARE
+ select SPL_ZYNQMP_FIRMWARE if SPL
help
Firmware interface driver is used by different
drivers to communicate with the firmware for
@@ -37,6 +38,10 @@ config ZYNQMP_FIRMWARE
Say yes to enable ZynqMP firmware interface driver.
If in doubt, say N.
+config SPL_ZYNQMP_FIRMWARE
+ bool "Enable ZynqMP Firmware interface in SPL"
+ depends on FIRMWARE && SPL
+
config ARM_SMCCC_FEATURES
bool "Arm SMCCC features discovery"
depends on ARM_PSCI_FW
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 935540d1719..3e4cae60c17 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -992,7 +992,7 @@ static const struct sdhci_ops arasan_ops = {
};
#endif
-#if defined(CONFIG_ARCH_ZYNQMP) && defined(CONFIG_ZYNQMP_FIRMWARE)
+#if defined(CONFIG_ARCH_ZYNQMP) && CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
static int sdhci_zynqmp_set_dynamic_config(struct arasan_sdhci_priv *priv,
struct udevice *dev)
{
@@ -1094,7 +1094,7 @@ static int arasan_sdhci_probe(struct udevice *dev)
host = priv->host;
-#if defined(CONFIG_ARCH_ZYNQMP) && defined(CONFIG_ZYNQMP_FIRMWARE)
+#if
[PATCH 2/2] xilinx: zynqmp: Enable reset_cpu() in SPL
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 95a134b972d..99f5c178c1d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
+ PM_RESET_ACTION_ASSERT, 0, 0, NULL);
}
#endif
--
2.30.2
[PATCH 0/2] Enable reset_cpu() in SPL for ZynqMP
From: Lukas Funke This series enables the CPU reset in the SPL for ZynqMP based platforms. This only works if CONFIG_SYSRESET is disabled. This is usually the case since the the regular sysreset requires bl31 firmware to be loaded in order to hand the sysreset over to PMU firmware. In SPL we can talk to the PMU firmware directly and request a CPU reset. The series also introduces SPL_ZYNQMP_FIRMWARE Kconfig symbol in order to make 'CONFIG_IS_ENABLED()' work in SPL. Lukas Funke (2): arm64: zynqmp: Add 'SPL_ZYNQMP_FIRMWARE' to Kconfig xilinx: zynqmp: Enable reset_cpu() in SPL arch/arm/mach-zynqmp/Kconfig | 2 +- arch/arm/mach-zynqmp/aes.c | 2 ++ arch/arm/mach-zynqmp/cpu.c | 4 ++-- board/xilinx/zynqmp/zynqmp.c | 13 +++-- drivers/firmware/Kconfig | 5 + drivers/mmc/zynq_sdhci.c | 4 ++-- drivers/pinctrl/Kconfig | 2 +- 7 files changed, 24 insertions(+), 8 deletions(-) -- 2.30.2
[PATCH] arm64: zynqmp: Setup multiboot register to 0
On Kria when board starts from Image A or Image B partition multiboot
register is already setup to that location. When reset command is called
board is issuing soft reset which start SW at already used location (offset
of multiboot * 32k).
But board should continue to run from multiboot offset 0 (start of QSPI)
and call early bootloader every reboot that's why clear multiboot register
to 0 by default to go that route all the time.
Signed-off-by: Michal Simek
---
board/xilinx/zynqmp/zynqmp_kria.env | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/xilinx/zynqmp/zynqmp_kria.env
b/board/xilinx/zynqmp/zynqmp_kria.env
index 846eceb0118d..69e333c53887 100644
--- a/board/xilinx/zynqmp/zynqmp_kria.env
+++ b/board/xilinx/zynqmp/zynqmp_kria.env
@@ -65,6 +65,7 @@ kd240_setup=i2c dev 1 && run usb_hub_init;zynqmp pmufw node
33; zynqmp pmufw nod
tpm_setup=tpm autostart;
board_setup=\
+zynqmp mmio_write 0xFFCA0010 0xfff 0; \
if test ${card1_name} = SCK-KV-G; then run kv260_setup; fi;\
if test ${card1_name} = SCK-KR-G; then run kr260_setup; fi;\
if test ${card1_name} = SCK-KD-G; then run kd240_setup; fi;\
--
2.40.1
[PATCH v3 8/8] qcom_defconfig: enable capsule update support
Enable all the necessary options for capsule updates to work, as well as a few additional EFI features. Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index f2dfced4bc1e..d1de7158e3f5 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -19,33 +19,39 @@ CONFIG_LOG_MAX_LEVEL=9 CONFIG_LOG_DEFAULT_LEVEL=4 # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_CMD_BOOTMENU=y +CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_EEPROM=y CONFIG_SYS_I2C_EEPROM_BUS=2 CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5 # CONFIG_CMD_BIND is not set CONFIG_CMD_CLK=y +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_UFS=y CONFIG_CMD_USB=y CONFIG_CMD_CAT=y CONFIG_CMD_BMP=y +CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_LOG=y CONFIG_OF_LIVE=y CONFIG_BUTTON_QCOM_PMIC=y CONFIG_CLK=y +CONFIG_CLK_STUB=y CONFIG_CLK_QCOM_QCM2290=y CONFIG_CLK_QCOM_QCS404=y CONFIG_CLK_QCOM_SDM845=y CONFIG_CLK_QCOM_SM6115=y CONFIG_CLK_QCOM_SM8250=y CONFIG_CLK_QCOM_SM8550=y CONFIG_CLK_QCOM_SM8650=y -CONFIG_CLK_STUB=y +CONFIG_DFU_MMC=y +CONFIG_DFU_SCSI=y +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x20 CONFIG_MSM_GPIO=y CONFIG_QCOM_PMIC_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_QUP=y @@ -105,6 +111,10 @@ CONFIG_VIDEO=y CONFIG_VIDEO_FONT_16X32=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_NO_FB_CLEAR=y CONFIG_VIDEO_SIMPLE=y -CONFIG_HEXDUMP=y +CONFIG_SYMBOL_LOOKUP=y +CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y +CONFIG_EFI_CAPSULE_ON_DISK=y +CONFIG_EFI_IGNORE_OSINDICATIONS=y +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y CONFIG_LMB_MAX_REGIONS=64 -- 2.45.0
[PATCH v3 7/8] mach-snapdragon: bump up heap size
For capsule updates we need more heap space for the DFU buffer. Give ourselves a whole 8MiB! Reviewed-by: Neil Armstrong Reviewed-by: Ilias Apalodimas Signed-off-by: Caleb Connolly --- arch/arm/mach-snapdragon/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig index 536960b83c3b..5023c906bed8 100644 --- a/arch/arm/mach-snapdragon/Kconfig +++ b/arch/arm/mach-snapdragon/Kconfig @@ -10,8 +10,11 @@ config SYS_VENDOR Allows to specify vendor for the Snapdragon SoCs based boards. Based on this option board// will be used as the custom board directory. +config SYS_MALLOC_LEN + default 0x80 + config SYS_MALLOC_F_LEN default 0x2000 config SPL_SYS_MALLOC_F -- 2.45.0
[PATCH v3 6/8] mach-snapdragon: use SYSRESET_PSCI
Capsule updates depend on SYSRESET, which we currently don't select but
instead use a custom reset_cpu() implementation which just calls
psci_reset().
Clean this up, drop our custom function and require PSCI reset.
There are some Qualcomm platforms that either can or do run without PSCI
support, but we didn't handle these properly before anyway.
Reviewed-by: Neil Armstrong
Reviewed-by: Ilias Apalodimas
Signed-off-by: Caleb Connolly
---
arch/arm/Kconfig | 2 ++
arch/arm/mach-snapdragon/board.c | 5 -
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 39ad03acd2e4..0d5161358e33 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1084,8 +1084,10 @@ config ARCH_SNAPDRAGON
select OF_CONTROL
select OF_SEPARATE
select SMEM
select SPMI
+ select SYSRESET
+ select SYSRESET_PSCI
select BOARD_LATE_INIT
select OF_BOARD
select SAVE_PREV_BL_FDT_ADDR
select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index c4a3394706e6..b0d9a65bb8f5 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -106,13 +106,8 @@ void *board_fdt_blob_setup(int *err)
return (void *)fdt;
}
-void reset_cpu(void)
-{
- psci_system_reset();
-}
-
/*
* Some Qualcomm boards require GPIO configuration when switching USB modes.
* Support setting this configuration via pinctrl state.
*/
--
2.45.0
[PATCH v3 5/8] qcom_defconfig: savedefconfig
run savedefconfig Reviewed-by: Neil Armstrong Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 65f13ae7a089..f2dfced4bc1e 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -1,17 +1,18 @@ CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_POSITION_INDEPENDENT=y +CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864 CONFIG_ARCH_SNAPDRAGON=y CONFIG_DEFAULT_DEVICE_TREE="qcom/sdm845-db845c" CONFIG_SYS_LOAD_ADDR=0xA000 -CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864 CONFIG_BUTTON_CMD=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_BOOTSTD_FULL=y # CONFIG_BOOTMETH_VBE is not set CONFIG_BOOTDELAY=1 +CONFIG_OF_BOARD_SETUP=y CONFIG_USE_PREBOOT=y CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR=y CONFIG_SYS_CBSIZE=512 CONFIG_LOG_MAX_LEVEL=9 @@ -33,9 +34,8 @@ CONFIG_CMD_USB=y CONFIG_CMD_CAT=y CONFIG_CMD_BMP=y CONFIG_CMD_LOG=y CONFIG_OF_LIVE=y -CONFIG_OF_BOARD_SETUP=y CONFIG_BUTTON_QCOM_PMIC=y CONFIG_CLK=y CONFIG_CLK_QCOM_QCM2290=y CONFIG_CLK_QCOM_QCS404=y @@ -106,6 +106,5 @@ CONFIG_VIDEO_FONT_16X32=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_NO_FB_CLEAR=y CONFIG_VIDEO_SIMPLE=y CONFIG_HEXDUMP=y -CONFIG_GENERATE_SMBIOS_TABLE=y CONFIG_LMB_MAX_REGIONS=64 -- 2.45.0
[PATCH v3 4/8] mach-snapdragon: implement capsule update support
Qualcomm boards flash U-Boot to the boot partition, implement support
for determining which slot U-Boot is running from and finding the
correct boot partition for that slot and configuring the appropriate DFU
string.
For now this only supports boards with SCSI/UFS storage where U-Boot is
flashed to the boot partition, and only U-Boot itself is updated. In the
future we may also support updating additional firmware components (tz,
hyp, xbl) as well as having U-Boot installed to other partitions (e.g.
as a first-stage bootloader).
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/Makefile | 1 +
arch/arm/mach-snapdragon/board.c | 3 +
arch/arm/mach-snapdragon/capsule_update.c | 147 ++
arch/arm/mach-snapdragon/qcom-priv.h | 6 ++
include/configs/qcom.h| 5 +
5 files changed, 162 insertions(+)
diff --git a/arch/arm/mach-snapdragon/Makefile
b/arch/arm/mach-snapdragon/Makefile
index 7a4495c8108f..343e825c6fdd 100644
--- a/arch/arm/mach-snapdragon/Makefile
+++ b/arch/arm/mach-snapdragon/Makefile
@@ -2,5 +2,6 @@
#
# (C) Copyright 2015 Mateusz Kulikowski
obj-y += board.o
+obj-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += capsule_update.o
obj-$(CONFIG_OF_LIVE) += of_fixup.o
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index b439a19ec7eb..c4a3394706e6 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -299,8 +299,11 @@ int board_late_init(void)
configure_env();
qcom_late_init();
+ /* Configure the dfu_string for capsule updates */
+ qcom_configure_capsule_updates();
+
return 0;
}
static void build_mem_map(void)
diff --git a/arch/arm/mach-snapdragon/capsule_update.c
b/arch/arm/mach-snapdragon/capsule_update.c
new file mode 100644
index ..505f5bf5ae07
--- /dev/null
+++ b/arch/arm/mach-snapdragon/capsule_update.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Common initialisation for Qualcomm Snapdragon boards.
+ *
+ * Copyright (c) 2024 Linaro Ltd.
+ * Author: Caleb Connolly
+ */
+
+#define pr_fmt(fmt) "QCOM-FMP: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "qcom-priv.h"
+
+struct efi_fw_image fw_images[] = {
+ {
+ .image_type_id = QUALCOMM_UBOOT_BOOT_IMAGE_GUID,
+ .fw_name = u"QUALCOMM-UBOOT",
+ .image_index = 1,
+ },
+};
+
+struct efi_capsule_update_info update_info = {
+ /* Filled in by configure_dfu_string() */
+ .dfu_string = NULL,
+ .num_images = ARRAY_SIZE(fw_images),
+ .images = fw_images,
+};
+
+/* LSB first */
+struct part_slot_status {
+ u16: 2;
+ u16 active : 1;
+ u16: 3;
+ u16 successful : 1;
+ u16 unbootable : 1;
+ u16 tries_remaining : 4;
+};
+
+static int find_boot_partition(const char *partname, struct blk_desc *blk_dev,
char *name)
+{
+ int ret;
+ int partnum;
+ struct disk_partition info;
+ struct part_slot_status *slot_status;
+
+ for (partnum = 1;; partnum++) {
+ ret = part_get_info(blk_dev, partnum, );
+ if (ret)
+ return ret;
+
+ slot_status = (struct part_slot_status *)_flags;
+ log_io("%16s: Active: %1d, Successful: %1d, Unbootable: %1d,
Tries left: %1d\n",
+ info.name, slot_status->active,
+ slot_status->successful, slot_status->unbootable,
+ slot_status->tries_remaining);
+ if (!strncmp(info.name, partname, strlen(partname)) &&
slot_status->active) {
+ log_debug("Found active %s partition: '%s'!\n",
partname, info.name);
+ strlcpy(name, info.name, sizeof(info.name));
+ return partnum;
+ }
+ }
+
+ return -1;
+}
+
+/**
+ * qcom_configure_capsule_updates() - Configure the DFU string for capsule
updates
+ *
+ * U-Boot is flashed to the boot partition on Qualcomm boards. In most cases
there
+ * are two boot partitions, boot_a and boot_b. As we don't currently support
doing
+ * full A/B updates, we only support updating the currently active boot
partition.
+ *
+ * So we need to find the current slot suffix and the associated boot
partition.
+ * We do this by looking for the boot partition that has the 'active' flag set
+ * in the GPT partition vendor attribute bits.
+ */
+void qcom_configure_capsule_updates(void)
+{
+ struct blk_desc *desc;
+ int ret = 0, partnum = -1, devnum;
+ static char dfu_string[32] = { 0 };
+ char name[32]; /* GPT partition name */
+ char *partname = "boot";
+ struct udevice *dev = NULL;
+
+ /*
+* There is currently no good way to check how U-Boot is booting, but
we have
+* a few hueristics, like here checking if our DTB has
[PATCH v3 3/8] mmc: msm_sdhci: work around a bug when writing
For some unknown reason, writes of larger than 1 block always fail with a checksum error on Qualcomm v5 controllers. Until this is resolved, work around the issue by setting b_max to 1 for these controllers. Reviewed-by: Neil Armstrong Signed-off-by: Caleb Connolly --- drivers/mmc/msm_sdhci.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c index 4ce0de6c47d8..fc3e8d101b6e 100644 --- a/drivers/mmc/msm_sdhci.c +++ b/drivers/mmc/msm_sdhci.c @@ -195,8 +195,15 @@ static int msm_sdc_probe(struct udevice *dev) return ret; host->mmc->priv = >host; upriv->mmc = host->mmc; + /* +* FIXME: v5 controllers have a bug in U-Boot that causes all writes +* greater than 1 block to fail. Work around this by setting b_max to 1. +*/ + if (var_info->mci_removed) + plat->cfg.b_max = 1; + return sdhci_probe(dev); } static int msm_sdc_remove(struct udevice *dev) -- 2.45.0
[PATCH v3 1/8] dfu: add scsi backend
This is extremely similar to the MMC backend, but there are some notable
differences.
Works with a DFU string like
scsi 4=u-boot-bin part 11
Where "4" is the SCSI dev number (sequential LUN across all SCSI devices)
and "11" is the partition number.
Signed-off-by: Caleb Connolly
---
doc/usage/dfu.rst | 32
drivers/dfu/Kconfig| 7 +
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 5 +-
drivers/dfu/dfu_scsi.c | 435 +
include/dfu.h | 26 +++
6 files changed, 505 insertions(+), 1 deletion(-)
diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst
index 8cc09c308d82..f497dcf137a4 100644
--- a/doc/usage/dfu.rst
+++ b/doc/usage/dfu.rst
@@ -21,8 +21,9 @@ U-Boot implements this DFU capability (CONFIG_DFU) with the
command dfu
Today the supported DFU backends are:
- MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system / SKIP / SCRIPT)
+- SCSI (UFS, RAW partition, FAT / EXT2 / EXT3 / EXT4 file system / SKIP /
SCRIPT)
- NAND
- RAM
- SF (serial flash)
- MTD (all MTD device: NAND, SPI-NOR, SPI-NAND,...)
@@ -166,8 +167,38 @@ mmc
Please note that this means the user will be able to execute any
arbitrary commands just like in the u-boot's shell.
+scsi
+for UFS storage::
+
+dfu 0 scsi
+
+each element in *dfu_alt_info* being
+
+* raw raw access to SCSI LUN
+* part raw access to partition
+* fatfile in FAT partition
+* ext4 file in EXT4 partition
+* skip 0 0ignore flashed data
+* script 0 0 execute commands in shell
+
+with
+
+size
+is the size of the access area (hexadecimal without "0x")
+or 0 which means whole device
+partid
+is the GPT or DOS partition index.
+dev
+is the SCSI LU (Logical Unit) index (decimal only)
+
+A value of environment variable *dfu_alt_info* for UFS could be::
+
+u-boot part 4;bl2 raw 0x1e 0x1d
+
+See mmc section above for details on the skip and script types.
+
nand
raw slc nand device::
dfu 0 nand
@@ -277,8 +308,9 @@ alternate list separated by '&' with the same format for
each ::
mmc =;;
nand =;;
ram =;;
+scsi =;;
sf =;;
mtd =;;
virt =;;
diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
index 0360d9da1427..158c660e6c4e 100644
--- a/drivers/dfu/Kconfig
+++ b/drivers/dfu/Kconfig
@@ -86,8 +86,15 @@ config DFU_VIRT
This option enables using DFU to read and write to VIRTUAL device
used at board level to manage specific behavior
(OTP update for example).
+config DFU_SCSI
+ bool "SCSI flash back end for DFU"
+ help
+ This option enables using DFU to read and write to SCSI devices
+ used at board level to manage specific behavior
+ (OTP update for example).
+
config SET_DFU_ALT_INFO
bool "Dynamic set of DFU alternate information"
help
This option allows to call the function set_dfu_alt_info to
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index dfbf64da6677..3b3ba0994b3a 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_$(SPL_)DFU_NAND) += dfu_nand.o
obj-$(CONFIG_$(SPL_)DFU_RAM) += dfu_ram.o
obj-$(CONFIG_$(SPL_)DFU_SF) += dfu_sf.o
obj-$(CONFIG_$(SPL_)DFU_WRITE_ALT) += dfu_alt.o
obj-$(CONFIG_$(SPL_)DFU_VIRT) += dfu_virt.o
+obj-$(CONFIG_$(SPL_)DFU_SCSI) += dfu_scsi.o
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 540d48fab77d..c81fa7724268 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -547,8 +547,11 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char
*s, int alt,
return -1;
} else if (strcmp(interface, "virt") == 0) {
if (dfu_fill_entity_virt(dfu, devstr, argv, argc))
return -1;
+ } else if (strcmp(interface, "scsi") == 0) {
+ if (dfu_fill_entity_scsi(dfu, devstr, argv, argc))
+ return -1;
} else {
printf("%s: Device %s not (yet) supported!\n",
__func__, interface);
return -1;
@@ -643,9 +646,9 @@ int dfu_config_entities(char *env, char *interface, char
*devstr)
const char *dfu_get_dev_type(enum dfu_device_type t)
{
const char *const dev_t[] = {NULL, "eMMC", "OneNAND", "NAND", "RAM",
-"SF", "MTD", "VIRT"};
+"SF", "MTD", "VIRT", "SCSI"};
return dev_t[t];
}
const char *dfu_get_layout(enum dfu_layout l)
diff --git a/drivers/dfu/dfu_scsi.c b/drivers/dfu/dfu_scsi.c
new file mode 100644
index ..9f95194784c1
--- /dev/null
+++ b/drivers/dfu/dfu_scsi.c
@@ -0,0 +1,435 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DFU SCSI backend (based on MMC backend).
+ *
+ * Copyright (C)
[PATCH v3 2/8] disk: expose partition type flags
GPT partition tables include two bytes worth of vendor defined
attributes, per partition. ChromeOS and Qualcomm both use these (with
different encoding!) to handle A/B slot switching with a retry counter.
Expose these via the disk_partition struct so that they can be parsed by
the relevant board code.
This will be used on Qualcomm boards to determine which slot we're
booting on so that we can flash capsule updates to the correct one.
Reviewed-by: Ilias Apalodimas
Reviewed-by: Mattijs Korpershoek
Signed-off-by: Caleb Connolly
---
disk/part_efi.c | 1 +
include/part.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index b1a03bd165e0..bde4adcfa087 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -291,8 +291,9 @@ int part_get_info_efi(struct blk_desc *desc, int part,
snprintf((char *)info->name, sizeof(info->name), "%s",
print_efiname(_pte[part - 1]));
strcpy((char *)info->type, "U-Boot");
info->bootable = get_bootable(_pte[part - 1]);
+ info->type_flags = gpt_pte[part -
1].attributes.fields.type_guid_specific;
if (CONFIG_IS_ENABLED(PARTITION_UUIDS)) {
uuid_bin_to_str(gpt_pte[part - 1].unique_partition_guid.b,
(char *)disk_partition_uuid(info),
UUID_STR_FORMAT_GUID);
diff --git a/include/part.h b/include/part.h
index 32ee40488563..afae51f1b933 100644
--- a/include/part.h
+++ b/include/part.h
@@ -68,8 +68,9 @@ struct disk_partition {
* PART_BOOTABLEthe MBR bootable flag is set
* PART_EFI_SYSTEM_PARTITIONthe partition is an EFI system partition
*/
int bootable;
+ u16 type_flags; /* top 16 bits of GPT partition attributes
*/
#if CONFIG_IS_ENABLED(PARTITION_UUIDS)
charuuid[UUID_STR_LEN + 1]; /* filesystem UUID as string, if exists
*/
#endif
#ifdef CONFIG_PARTITION_TYPE_GUID
--
2.45.0
[PATCH v3 0/8] qcom: implement capsule updates
Hook up support for capsule updates loaded from disk on Qualcomm platforms. Most Qualcomm devices have an A/B partition layout, with most partitions duplicated. The metadata on which slot is active is stored in the GPT headers in the vendor-specific attribute bits of each partition. Add support for reading this attributes via the disk_partition struct and using them to determine which boot partition U-Boot is flashed to and generate the appropriate DFU string. This logic is gated behind a check to ensure that U-Boot is actually being chainloaded and not run via some other mechanism. SCSI support for most Qualcomm platforms is not yet enabled upstream, but will follow in future patches. This series enables capsule updates on the RB2, however [1] is required for it to work properly (as otherwise MMC won't be available). [1]: https://lore.kernel.org/u-boot/20240527-b4-clk-stub-v2-0-29013855e...@linaro.org/ To: Tom Rini To: Simon Glass To: Lukasz Majewski To: Mattijs Korpershoek To: Caleb Connolly To: Neil Armstrong To: Sumit Garg Cc: Ilias Apalodimas Cc: u-boot@lists.denx.de Cc: u-boot-q...@groups.io Changes in v3: - Address comments in scsi dfu support - enable CONFIG_DFU_SCSI for qcom - Link to v2: https://lore.kernel.org/r/20240527-b4-qcom-capsule-updates-v2-0-47583d7ad...@linaro.org Changes in v2: - Add qcom capsule update support patches - Link to v1: https://lore.kernel.org/r/20240409-b4-dfu-scsi-v1-0-3e1441a60...@linaro.org --- Caleb Connolly (8): dfu: add scsi backend disk: expose partition type flags mmc: msm_sdhci: work around a bug when writing mach-snapdragon: implement capsule update support qcom_defconfig: savedefconfig mach-snapdragon: use SYSRESET_PSCI mach-snapdragon: bump up heap size qcom_defconfig: enable capsule update support arch/arm/Kconfig | 2 + arch/arm/mach-snapdragon/Kconfig | 3 + arch/arm/mach-snapdragon/Makefile | 1 + arch/arm/mach-snapdragon/board.c | 8 +- arch/arm/mach-snapdragon/capsule_update.c | 147 ++ arch/arm/mach-snapdragon/qcom-priv.h | 6 + configs/qcom_defconfig| 19 +- disk/part_efi.c | 1 + doc/usage/dfu.rst | 32 +++ drivers/dfu/Kconfig | 7 + drivers/dfu/Makefile | 1 + drivers/dfu/dfu.c | 5 +- drivers/dfu/dfu_scsi.c| 435 ++ drivers/mmc/msm_sdhci.c | 7 + include/configs/qcom.h| 5 + include/dfu.h | 26 ++ include/part.h| 1 + 17 files changed, 695 insertions(+), 11 deletions(-) --- change-id: 20240523-b4-qcom-capsule-updates-ea2e4f8f0ff0 base-commit: 5d8881a0801241d68701e8644d495f1d535506f0 // Caleb (they/them)
Re: obscure microsd detection issue between U-Boot and kernel
On 5/31/24 21:47, Tim Harvey wrote: > Greetings, > > I'm seeing an issue on an imx8mm board (imx8mm-venice-gw73xx) where > for a specific set of microsd cards if I have accessed the microsd in > U-Boot with UHS/1.8V the kernel will not recognize that microsd when > scanning. > > The issue does not occur with all microsd cards but seems to appear > with a large sample size of a specific card/model (Kingston SDC32 32GB > SDR104 card). I do not see a signal integrity issue on the scope. > > Instrumenting the kernel the issue is that the host reports a CRC > error as soon as the first mmc_send_if_cond call which occurs in > mmc_rescan_try_freq. > > I can avoid the issue by either not accessing the microsd in U-Boot or > by disabling UHS/1.8V mode in U-Boot therefore what I think is > happening is that U-Boot leaves the card in UHS/1.8V signalling mode > and when the kernel scans it sets the voltage back to 3.3V > standard/default and default timings then issues its clock cycles to > 'reset' the card and the card does not recognize the reset. I'm > wondering if this is because the reset is done via clock cycles after > the kernel has set the I/O voltage back to 3.3V when perhaps the card > is still in 1.8V mode (although I don't see how that would cause an > issue)? It will cause an issue for many cards and might break some cards. > > Is there some sort of MMC 'reset' I can/should do in U-Boot before > booting the kernel? Has anyone encountered anything like this before? There is no 'switching back' to 3.3V signalling from UHS 1.8V. The only way this can be done is therefore a full power-off. Is that done correctly for your system? AFAIR spec dictates 500ms of <0.5V on VCC. Note that driving CLK/signal lines can also sustain the card somewhat, as leakage is only limited within operating voltage.
[PATCH v3 4/5] net: add Qualcomm ESS EDMA adapter
This adds the driver for the ESS EDMA ethernet adapter
found inside of Qualcomm IPQ40xx SoC series.
This driver also integrates the built in modified QCA8337N
switch support as they are tightly integrated.
Co-Developed-by: Gabor Juhos
Signed-off-by: Gabor Juhos
Signed-off-by: Robert Marko
---
Changes in v3:
* Use dev_dbg for printing
* Switch to ofnode_read_u32() instead of ofnode_read_u32_default()
Changes in v2:
* Adapt to the Linux pending DT node instead
* Check if port node is enabled
drivers/net/Kconfig |8 +
drivers/net/Makefile |1 +
drivers/net/essedma.c | 1192 +
drivers/net/essedma.h | 198 +++
4 files changed, 1399 insertions(+)
create mode 100644 drivers/net/essedma.c
create mode 100644 drivers/net/essedma.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2d7b49976..9b7626e1c5 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -307,6 +307,14 @@ config EEPRO100
This driver supports Intel(R) PRO/100 82557/82559/82559ER fast
ethernet family of adapters.
+config ESSEDMA
+ bool "Qualcomm ESS Edma support"
+ depends on DM_ETH && ARCH_IPQ40XX
+ select PHYLIB
+ help
+ This driver supports ethernet DMA adapter found in
+ Qualcomm IPQ40xx series SoC-s.
+
config ETH_SANDBOX
depends on SANDBOX
default y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index dc3404519d..8533793de5 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_DWC_ETH_QOS_STM32) += dwc_eth_qos_stm32.o
obj-$(CONFIG_E1000) += e1000.o
obj-$(CONFIG_E1000_SPI) += e1000_spi.o
obj-$(CONFIG_EEPRO100) += eepro100.o
+obj-$(CONFIG_ESSEDMA) += essedma.o
obj-$(CONFIG_ETHOC) += ethoc.o
obj-$(CONFIG_ETH_DESIGNWARE) += designware.o
obj-$(CONFIG_ETH_DESIGNWARE_MESON8B) += dwmac_meson8b.o
diff --git a/drivers/net/essedma.c b/drivers/net/essedma.c
new file mode 100644
index 00..0de363806f
--- /dev/null
+++ b/drivers/net/essedma.c
@@ -0,0 +1,1192 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Sartura Ltd.
+ *
+ * Author: Robert Marko
+ *
+ * Copyright (c) 2021 Toco Technologies FZE
+ * Copyright (c) 2021 Gabor Juhos
+ *
+ * Qualcomm ESS EDMA ethernet driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "essedma.h"
+
+#define EDMA_MAX_PKT_SIZE (PKTSIZE_ALIGN + PKTALIGN)
+
+#define EDMA_RXQ_ID0
+#define EDMA_TXQ_ID0
+
+/* descriptor ring */
+struct edma_ring {
+ u16 count; /* number of descriptors in the ring */
+ void *hw_desc; /* descriptor ring virtual address */
+ unsigned int hw_size; /* hw descriptor ring length in bytes */
+ dma_addr_t dma; /* descriptor ring physical address */
+ u16 head; /* next Tx descriptor to fill */
+ u16 tail; /* next Tx descriptor to clean */
+};
+
+struct ess_switch {
+ phys_addr_t base;
+ struct phy_device *phydev[ESS_PORTS_NUM];
+ u32 phy_mask;
+ ofnode ports_node;
+ phy_interface_t port_wrapper_mode;
+ int num_phy;
+};
+
+struct essedma_priv {
+ phys_addr_t base;
+ struct udevice *dev;
+ struct clk ess_clk;
+ struct reset_ctl ess_rst;
+ struct udevice *mdio_dev;
+ struct ess_switch esw;
+ phys_addr_t psgmii_base;
+ struct edma_ring tpd_ring;
+ struct edma_ring rfd_ring;
+};
+
+static void esw_port_loopback_set(struct ess_switch *esw, int port,
+ bool enable)
+{
+ u32 t;
+
+ t = readl(esw->base + ESS_PORT_LOOKUP_CTRL(port));
+ if (enable)
+ t |= ESS_PORT_LOOP_BACK_EN;
+ else
+ t &= ~ESS_PORT_LOOP_BACK_EN;
+ writel(t, esw->base + ESS_PORT_LOOKUP_CTRL(port));
+}
+
+static void esw_port_loopback_set_all(struct ess_switch *esw, bool enable)
+{
+ int i;
+
+ for (i = 1; i < ESS_PORTS_NUM; i++)
+ esw_port_loopback_set(esw, i, enable);
+}
+
+static void ess_reset(struct udevice *dev)
+{
+ struct essedma_priv *priv = dev_get_priv(dev);
+
+ reset_assert(>ess_rst);
+ mdelay(10);
+
+ reset_deassert(>ess_rst);
+ mdelay(10);
+}
+
+void qca8075_ess_reset(struct udevice *dev)
+{
+ struct essedma_priv *priv = dev_get_priv(dev);
+ struct phy_device *psgmii_phy;
+ int i, val;
+
+ /* Find the PSGMII PHY */
+ psgmii_phy = priv->esw.phydev[priv->esw.num_phy - 1];
+
+ /* Fix phy psgmii RX 20bit */
+ phy_write(psgmii_phy, MDIO_DEVAD_NONE, MII_BMCR, 0x005b);
+
+ /* Reset phy psgmii */
+ phy_write(psgmii_phy, MDIO_DEVAD_NONE, MII_BMCR, 0x001b);
+
+ /* Release reset phy psgmii */
+ phy_write(psgmii_phy, MDIO_DEVAD_NONE, MII_BMCR, 0x005b);
+ for (i = 0; i < 100; i++) {
+ val = phy_read_mmd(psgmii_phy, MDIO_MMD_PMAPMD,
[PATCH v3 3/5] clock: qcom: ipq4019: add missing networking resets
IPQ4019 has more networking related resets that will be required for future
wired networking support, so lets add them.
This syncs the driver with Linux.
Signed-off-by: Robert Marko
Reviewed-by: Caleb Connolly
---
drivers/clk/qcom/clock-ipq4019.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/qcom/clock-ipq4019.c b/drivers/clk/qcom/clock-ipq4019.c
index 09be203d4b..fca7626ada 100644
--- a/drivers/clk/qcom/clock-ipq4019.c
+++ b/drivers/clk/qcom/clock-ipq4019.c
@@ -124,6 +124,12 @@ static const struct qcom_reset_map gcc_ipq4019_resets[] = {
[GCC_TCSR_BCR] = {0x22000, 0},
[GCC_MPM_BCR] = {0x24000, 0},
[GCC_SPDM_BCR] = {0x25000, 0},
+ [ESS_MAC1_ARES] = {0x1200C, 0},
+ [ESS_MAC2_ARES] = {0x1200C, 1},
+ [ESS_MAC3_ARES] = {0x1200C, 2},
+ [ESS_MAC4_ARES] = {0x1200C, 3},
+ [ESS_MAC5_ARES] = {0x1200C, 4},
+ [ESS_PSGMII_ARES] = {0x1200C, 5},
};
static struct msm_clk_data ipq4019_clk_data = {
--
2.45.1
[PATCH v3 5/5] arm: dts: add IPQ4019 ESS EDMA U-Boot additions
IPQ4019 ESS EDMA support is not yet in upstream Linux, so for now lets use
the latest pending Linux DTS node for wired networking.
Signed-off-by: Robert Marko
---
Chanes in v2:
* Use the latest pending Linux DT node for EDMA instead
arch/arm/dts/qcom-ipq4019-u-boot.dtsi | 104 ++
1 file changed, 104 insertions(+)
create mode 100644 arch/arm/dts/qcom-ipq4019-u-boot.dtsi
diff --git a/arch/arm/dts/qcom-ipq4019-u-boot.dtsi
b/arch/arm/dts/qcom-ipq4019-u-boot.dtsi
new file mode 100644
index 00..079f41
--- /dev/null
+++ b/arch/arm/dts/qcom-ipq4019-u-boot.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/ {
+ soc {
+ switch: switch@c00 {
+ compatible = "qcom,ipq4019-ess";
+ reg = <0xc00 0x8>, <0x98000 0x800>, <0xc08
0x8000>;
+ reg-names = "base", "psgmii_phy", "edma";
+ resets = < ESS_PSGMII_ARES>, < ESS_RESET>;
+ reset-names = "psgmii", "ess";
+ clocks = < GCC_ESS_CLK>;
+ clock-names = "ess";
+ mdio = <>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ swport1: port@1 { /* MAC1 */
+ reg = <1>;
+ label = "lan1";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+
+ swport2: port@2 { /* MAC2 */
+ reg = <2>;
+ label = "lan2";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+
+ swport3: port@3 { /* MAC3 */
+ reg = <3>;
+ label = "lan3";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+
+ swport4: port@4 { /* MAC4 */
+ reg = <4>;
+ label = "lan4";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+
+ swport5: port@5 { /* MAC5 */
+ reg = <5>;
+ label = "wan";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+ };
+ };
+ };
+};
+
+ {
+ psgmiiphy: psgmii-phy@5 {
+ reg = <5>;
+ };
+};
--
2.45.1
[PATCH v3 2/5] dt-bindings: clock: qcom: ipq4019: drop downstream file
IPQ4019 clock dt-bindings are available in Linux upstream, and we can just use those instead of carrying a downstream file that matches the upstream one anyway. Signed-off-by: Robert Marko Reviewed-by: Sumit Garg --- Changes in v2: * Drop the downstream dt-bindings header as it matches the upstream Linux one include/dt-bindings/clock/qcom,gcc-ipq4019.h | 169 --- 1 file changed, 169 deletions(-) delete mode 100644 include/dt-bindings/clock/qcom,gcc-ipq4019.h diff --git a/include/dt-bindings/clock/qcom,gcc-ipq4019.h b/include/dt-bindings/clock/qcom,gcc-ipq4019.h deleted file mode 100644 index 7e8a7be6dc..00 --- a/include/dt-bindings/clock/qcom,gcc-ipq4019.h +++ /dev/null @@ -1,169 +0,0 @@ -/* Copyright (c) 2015 The Linux Foundation. All rights reserved. - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - * - */ -#ifndef __QCOM_CLK_IPQ4019_H__ -#define __QCOM_CLK_IPQ4019_H__ - -#define GCC_DUMMY_CLK 0 -#define AUDIO_CLK_SRC 1 -#define BLSP1_QUP1_I2C_APPS_CLK_SRC2 -#define BLSP1_QUP1_SPI_APPS_CLK_SRC3 -#define BLSP1_QUP2_I2C_APPS_CLK_SRC4 -#define BLSP1_QUP2_SPI_APPS_CLK_SRC5 -#define BLSP1_UART1_APPS_CLK_SRC 6 -#define BLSP1_UART2_APPS_CLK_SRC 7 -#define GCC_USB3_MOCK_UTMI_CLK_SRC 8 -#define GCC_APPS_CLK_SRC 9 -#define GCC_APPS_AHB_CLK_SRC 10 -#define GP1_CLK_SRC11 -#define GP2_CLK_SRC12 -#define GP3_CLK_SRC13 -#define SDCC1_APPS_CLK_SRC 14 -#define FEPHY_125M_DLY_CLK_SRC 15 -#define WCSS2G_CLK_SRC 16 -#define WCSS5G_CLK_SRC 17 -#define GCC_APSS_AHB_CLK 18 -#define GCC_AUDIO_AHB_CLK 19 -#define GCC_AUDIO_PWM_CLK 20 -#define GCC_BLSP1_AHB_CLK 21 -#define GCC_BLSP1_QUP1_I2C_APPS_CLK22 -#define GCC_BLSP1_QUP1_SPI_APPS_CLK23 -#define GCC_BLSP1_QUP2_I2C_APPS_CLK24 -#define GCC_BLSP1_QUP2_SPI_APPS_CLK25 -#define GCC_BLSP1_UART1_APPS_CLK 26 -#define GCC_BLSP1_UART2_APPS_CLK 27 -#define GCC_DCD_XO_CLK 28 -#define GCC_GP1_CLK29 -#define GCC_GP2_CLK30 -#define GCC_GP3_CLK31 -#define GCC_BOOT_ROM_AHB_CLK 32 -#define GCC_CRYPTO_AHB_CLK 33 -#define GCC_CRYPTO_AXI_CLK 34 -#define GCC_CRYPTO_CLK 35 -#define GCC_ESS_CLK36 -#define GCC_IMEM_AXI_CLK 37 -#define GCC_IMEM_CFG_AHB_CLK 38 -#define GCC_PCIE_AHB_CLK 39 -#define GCC_PCIE_AXI_M_CLK 40 -#define GCC_PCIE_AXI_S_CLK 41 -#define GCC_PCNOC_AHB_CLK 42 -#define GCC_PRNG_AHB_CLK 43 -#define GCC_QPIC_AHB_CLK 44 -#define GCC_QPIC_CLK 45 -#define GCC_SDCC1_AHB_CLK 46 -#define GCC_SDCC1_APPS_CLK 47 -#define GCC_SNOC_PCNOC_AHB_CLK 48 -#define GCC_SYS_NOC_125M_CLK 49 -#define GCC_SYS_NOC_AXI_CLK50 -#define GCC_TCSR_AHB_CLK 51 -#define GCC_TLMM_AHB_CLK 52 -#define GCC_USB2_MASTER_CLK53 -#define GCC_USB2_SLEEP_CLK 54 -#define GCC_USB2_MOCK_UTMI_CLK 55 -#define GCC_USB3_MASTER_CLK56 -#define GCC_USB3_SLEEP_CLK
[PATCH v3 1/5] clock: qcom: ipq4019: add ESS clock
ESS clock is the Ethernet Subsystem clock, so lets add it as its already configured by SBL1. Signed-off-by: Robert Marko Reviewed-by: Caleb Connolly --- drivers/clk/qcom/clock-ipq4019.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/clk/qcom/clock-ipq4019.c b/drivers/clk/qcom/clock-ipq4019.c index 72f235eab2..09be203d4b 100644 --- a/drivers/clk/qcom/clock-ipq4019.c +++ b/drivers/clk/qcom/clock-ipq4019.c @@ -44,6 +44,9 @@ static int ipq4019_clk_enable(struct clk *clk) case GCC_USB2_MOCK_UTMI_CLK: /* These clocks is already initialized by SBL1 */ return 0; + case GCC_ESS_CLK: + /* This clock is already initialized by SBL1 */ + return 0; default: return -EINVAL; } -- 2.45.1
Re: [PATCH v1 0/5] FUSB302 USB-C controller support
Hi Sebastian, On 2024-05-31 17:08, Sebastian Reichel wrote: > Hi, > > On ROCK 5B power is usually supplied via it's USB-C port. This port has the > data lines connected to RK3588, VBUS connected to the input regulator and > CC pins connected to FUSB302. FUSB302 is a USB-C controller, which can be > accessed via I2C from RK3588. The USB-C controller is needed to figure out > the USB-C cable orientation, but also to do USB PD communication. Thus it > would be great to enable support for it in the operating system. > > But the USB-PD specification requires, that a device reacts to USB-PD messages > send by the power-supply within around 5 seconds. If that does not happen the > power-supply assumes, that the device does not support USB-PD. If a device > later starts sending USB-PD messages it is considered an error, which is > solved > by doing a hard reset. A USB-PD hard reset means, that all supply voltages are > removed for a short period of time. For boards, which are solely powered > through their USB-C port, like the Radxa Rock 5B, this results in an machine > reset. This is currently worked around by not describing the FUSB302 in the > kernel DT, so nothing will ever speak USB-PD on the Rock 5B. This means > > 1. the USB-C port cannot be used at all > 2. the board will be running via fallback supply, which provides limited >power capabilities > > In order to avoid the hard reset, this adds FUSB302 support to U-Boot, so > that we react to the power-supply's queries in time. The code, which is > originally from the Linux kernel, consists of two parts: > > 1. the tcpm state machine, which implements the Type C port manager state >machine as described in the USB PD specification > 2. the fusb302 driver, which knows about specific registers > > Especially the first part has been heavily modified compared to the > kernel, which makes use of multiple delayed works and threads. For this > I used a priorly ported version from Rockchip, removed their hacks and > any states not necessary in U-Boot (e.g. audio accessory support). Thanks for working on this! Some initial quick feedback is that the tcpm uclass and driver should probably take more advantage of the u-boot driver model. Few quick thoughts: - Split out uclass/driver api parts into tcpm-uclass.c - Take advantage of uclass_driver ops such as post_probe and per_device_auto/per_device_plat_auto to e.g. handle tcpm_port_init and tcpm_port/tcpm_dev - udevice should probably be passed to tcpm_ functions instead of a tcpm_port, dev_get_uclass_plat/priv could possible be used to get the tcpm_port data for the udevice I have not yet had time to runtime test this but will do and get back with a more in depth review later this week. Regards, Jonas > > Greetings, > > -- Sebastian > > Sebastian Reichel (5): > usb: tcpm: add core framework > usb: tcpm: fusb302: add driver > board: rock5b-rk3588: add USB-C controller support > board: rock5b-rk3588: enable USB-C in operating system > MAINTAINERS: add TCPM section > > MAINTAINERS |8 + > Makefile |1 + > arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 28 + > board/radxa/rock5b-rk3588/Makefile|6 + > board/radxa/rock5b-rk3588/rock5b-rk3588.c | 33 + > cmd/Kconfig |7 + > cmd/Makefile |1 + > cmd/tcpm.c| 117 + > configs/rock5b-rk3588_defconfig |5 + > drivers/usb/Kconfig |2 + > drivers/usb/tcpm/Kconfig | 16 + > drivers/usb/tcpm/Makefile |4 + > drivers/usb/tcpm/fusb302.c| 1427 > drivers/usb/tcpm/fusb302_reg.h| 177 ++ > drivers/usb/tcpm/tcpm.c | 2406 + > include/dm/uclass-id.h|1 + > include/usb/pd.h | 516 + > include/usb/tcpm.h| 116 + > 18 files changed, 4871 insertions(+) > create mode 100644 board/radxa/rock5b-rk3588/Makefile > create mode 100644 board/radxa/rock5b-rk3588/rock5b-rk3588.c > create mode 100644 cmd/tcpm.c > create mode 100644 drivers/usb/tcpm/Kconfig > create mode 100644 drivers/usb/tcpm/Makefile > create mode 100644 drivers/usb/tcpm/fusb302.c > create mode 100644 drivers/usb/tcpm/fusb302_reg.h > create mode 100644 drivers/usb/tcpm/tcpm.c > create mode 100644 include/usb/pd.h > create mode 100644 include/usb/tcpm.h >
[PATCH] bootstd: Fix a handful of doc typos in bootmeth
Fix some trivial typos found by browsing the code.
Done with flyspell.
Signed-off-by: Mattijs Korpershoek
---
include/bootmeth.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/bootmeth.h b/include/bootmeth.h
index 0fc36104ece0..529c4d813d82 100644
--- a/include/bootmeth.h
+++ b/include/bootmeth.h
@@ -40,7 +40,7 @@ struct bootmeth_ops {
/**
* get_state_desc() - get detailed state information
*
-* Prodecues a textual description of the state of the bootmeth. This
+* Produces a textual description of the state of the bootmeth. This
* can include newline characters if it extends to multiple lines. It
* must be a nul-terminated string.
*
@@ -138,7 +138,7 @@ struct bootmeth_ops {
* @dev:Bootmethod device to boot
* @bflow: Bootflow to boot
* Return: does not return on success, since it should boot the
-* Operating Systemn. Returns -EFAULT if that fails, -ENOTSUPP if
+* Operating System. Returns -EFAULT if that fails, -ENOTSUPP if
* trying method resulted in finding out that is not actually
* supported for this boot and should not be tried again unless
* something changes, other -ve on other error
@@ -151,7 +151,7 @@ struct bootmeth_ops {
/**
* bootmeth_get_state_desc() - get detailed state information
*
- * Prodecues a textual description of the state of the bootmeth. This
+ * Produces a textual description of the state of the bootmeth. This
* can include newline characters if it extends to multiple lines. It
* must be a nul-terminated string.
*
@@ -244,7 +244,7 @@ int bootmeth_read_file(struct udevice *dev, struct bootflow
*bflow,
* @dev: Bootmethod device to use
* @bflow: Bootflow to read
* Return: does not return on success, since it should boot the
- * Operating Systemn. Returns -EFAULT if that fails, other -ve on
+ * Operating System. Returns -EFAULT if that fails, other -ve on
* other error
*/
int bootmeth_read_all(struct udevice *dev, struct bootflow *bflow);
@@ -255,7 +255,7 @@ int bootmeth_read_all(struct udevice *dev, struct bootflow
*bflow);
* @dev: Bootmethod device to boot
* @bflow: Bootflow to boot
* Return: does not return on success, since it should boot the
- * Operating Systemn. Returns -EFAULT if that fails, other -ve on
+ * Operating System. Returns -EFAULT if that fails, other -ve on
* other error
*/
int bootmeth_boot(struct udevice *dev, struct bootflow *bflow);
@@ -264,7 +264,7 @@ int bootmeth_boot(struct udevice *dev, struct bootflow
*bflow);
* bootmeth_setup_iter_order() - Set up the ordering of bootmeths to scan
*
* This sets up the ordering information in @iter, based on the selected
- * ordering of the bootmethds in bootstd_priv->bootmeth_order. If there is no
+ * ordering of the bootmeths in bootstd_priv->bootmeth_order. If there is no
* ordering there, then all bootmethods are added
*
* @iter: Iterator to update with the order
---
base-commit: ea722aa5eb33740ae77e8816aeb72b385e621cd0
change-id: 20240603-bootmeth-typos-47c865e70ccf
Best regards,
--
Mattijs Korpershoek
[PATCH] cmd: bcb: Fix bcb compilation when CONFIG_CMD_BCB=n
commit dfeb4f0d7935 ("cmd: bcb: extend BCB C API to allow read/write the
fields")
introduced the bcb_get() function.
When CONFIG_CMD_BCB=n, that function is stubbed.
The stubbed function has a wrong prototype: value_size arg is missing.
Add the missing argument to fix build when CONFIG_CMD_BCB=n.
Fixes: dfeb4f0d7935 ("cmd: bcb: extend BCB C API to allow read/write the
fields")
Signed-off-by: Mattijs Korpershoek
---
include/bcb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/bcb.h b/include/bcb.h
index 1941d8c28b4f..a56b547595a6 100644
--- a/include/bcb.h
+++ b/include/bcb.h
@@ -58,7 +58,8 @@ static inline int bcb_set(enum bcb_field field, const char
*value)
return -EOPNOTSUPP;
}
-static inline int bcb_get(enum bcb_field field, char *value_out)
+static inline int bcb_get(enum bcb_field field,
+ char *value_out, size_t value_size)
{
return -EOPNOTSUPP;
}
---
base-commit: ea722aa5eb33740ae77e8816aeb72b385e621cd0
change-id: 20240603-bcb-compil-d8eaf7074475
Best regards,
--
Mattijs Korpershoek
Re: [PATCH 06/42] mmc: dw_mmc: Extract clock on/off code into a separate routine
Hi Sam, On 5/30/24 2:06 AM, Sam Protsenko wrote: On Thu, May 23, 2024 at 9:36 AM Quentin Schulz wrote: Hi Sam, Hi Quentin, Thanks for reviewing this series! My answers are below (inline). On 5/23/24 1:30 AM, Sam Protsenko wrote: Extract clock control code into a separate routine to avoid code duplication in dwmci_setup_bus(). No functional change. There are some differences though. With everything discussed below, I guess it still can be argued that this patch doesn't change the functionality of the driver? Depends on definition though. Please let me know if you don't like this bit and I'll remove it in v2. [snip] @@ -439,35 +461,19 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32 freq) else div = DIV_ROUND_UP(sclk, 2 * freq); - dwmci_writel(host, DWMCI_CLKENA, 0); + /* Disable clock */ dwmci_writel(host, DWMCI_CLKSRC, 0); + ret = dwmci_control_clken(host, false); Here, CLKENA and CLKSRC are swapped. The kernel still calls CLKENA before CLKSRC, is this really safe? (I have no documentation so cannot tell). E.g., we could have CLKSRC register be a way to select the clock parent/source, 0 could be 24MHz crystal for example, so switching to this new parent before disabling the clock output would likely result in glitches? Yes, you are right. In fact, Exynos850 TRM specifically mentions this. Here is how TRM describes the whole procedure for "CIU Update": 8<->8 To prevent a clock glitch, ensure that software stops the clock when it updates the clock divider and clock source registers. Software uses the following sequence to update the clock divider settings: 1. Disables the clock. 2. Updates the clock divider and/or the clock source registers. 3, Enables the clock. Code Sample to Update CIU: // Disable clock while (rSTATUS & (1 << 9)); rCLKENA = 0x0; rCMD = 0x80202000; // inform CIU while (rCMD & 0x8000); // Update divider and source rCLKDIV = clock_divider; rCLKSRC = clock_source; // Enable clock while (rSTATUS & (1 << 9)); rCLKENA= 0x1; rCMD = 0x80202000; // inform CIU while (rCMD & 0x8000); 8<->8 It's an overlook on my part. And although CLKSRC reset value is 0x0 and it's only being written with 0x0 in the driver, it still has to be fixed. I'll move CLKSRC modification below CLKDIV to make it look like TRM suggests. Did you mean "move CLKENA before CLKSRC"? Because if the clock is disabled, I don't think the order in which the parent clock and its divider are set matters? Linux kernel implementation also doesn't follow the sequence recommended in TRM as you can see, but it works fine because CLKSRC is always written to 0 there (and it's also 0 at reset time). OK, so wrong logic but it works because we essentially never change CLKSRC so it's virtually a no-op and thus there are no change to the parent clock when the clock is enabled, resulting in no glitch. Not sure we should ignore the improper logic though? What are you suggesting we do here? + if (ret) + return ret; + /* Set clock to desired speed */ dwmci_writel(host, DWMCI_CLKDIV, div); Same here, CLKDIV is set now after the CIU is informed, is this an issue? We may want to set the clock speed before we enable the clock again. Right now it's setting the desired speed while disabled, inform the CIU, enable the clock, inform the CIU. This now does, disable the clock, inform the CIU, set the desired speed, enable the clock, inform the CIU. We may need to wait for the clock to stabilize before enabling it? Again, just making guesses, no documentation for me here :/ In this case, my implementation is following TRM (as described above). After CLKDIV modification my code informs CIU again, inside of the dwmci_control_clken() call. Just to be thorough, here is what TRM says about DWMCI_CMD_UPD_CLK (bit 21): 8<->8 ...Following are the register values transferred into the card clock domain: * CLKDIV * CLKSRC * CLKENA 8<->8 So you are right that each time this bit is set all 3 values are being transferred to CIU. But because that bit is set two times (before and after updating CLKDIV/CLKSRC) -- it's ok. And also this way is recommended in TRM, as stated above. Hopefully there aren't other implementations than Exynos 850's that need to do something else :) Aside from the improper logic, looks good to me, can you please add this information to the commit log so it's not lost in the mailing list :) ? Thanks, Quentin
Re: [PATCH v2 2/2] drivers: misc: Add driver to access ZynqMP efuses
On 29.05.2024 16:40, Michal Simek wrote:
On 5/15/24 14:41, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by: Lukas Funke
---
Changes in v2:
- Drop vendor specific fuse cmd, use existing fuse cmd
- Minor code refactoring (reverse x-mas tree)
drivers/misc/Kconfig | 8 +
drivers/misc/Makefile | 1 +
drivers/misc/zynqmp_efuse.c | 324
3 files changed, 333 insertions(+)
create mode 100644 drivers/misc/zynqmp_efuse.c
would be good to get also 3/3 which enables
CONFIG_CMD_FUSE=y
CONFIG_ZYNQMP_EFUSE=y
in zynqmp defconfigs (virt and kria) to have it enabled.
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
Security Monitor can be transitioned on any security failures,
like software violations or hardware security violations.
+config ZYNQMP_EFUSE
+ bool "Enable ZynqMP eFUSE Driver"
+ depends on ZYNQMP_FIRMWARE
+ help
+ Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU
firmware
+ interface. ZnyqMP has 256 eFUSEs where some of them are
security related
+ and cannot be read back (i.e. AES key).
+
choice
prompt "Security monitor interaction endianess"
depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
obj-$(CONFIG_SL28CPLD) += sl28cpld.o
obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..98a39c1ebdd
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK 0x5FFF
+#define P_USER_127_LOWER_4_BIT_MASK 0xF
+#define WORD_INBYTES (4)
+#define SOC_VER_SIZE (0x4)
+#define SOC_VERSION_OFFSET (0x0)
+#define EFUSE_START_OFFSET (0xC)
+#define EFUSE_END_OFFSET (0xFC)
+#define EFUSE_PUF_START_OFFSET (0x100)
+#define EFUSE_PUF_MID_OFFSET (0x140)
+#define EFUSE_PUF_END_OFFSET (0x17F)
+#define EFUSE_NOT_ENABLED (29)
+#define EFUSE_READ (0)
+#define EFUSE_WRITE (1)
I did compare it with the latest upstream version and there are some
differences which don't need to be there. Above macros for example
+
+/**
+ * struct efuse_map_entry - offset and length of zynqmp fuses
+ * @offset: offset of efuse to be read/write
+ * @length: length of efuse
+ */
+struct efuse_map_entry {
+ u32 offset;
+ u32 length;
+};
+
+struct efuse_map_entry zynqmp_efuse_table[] = {
+ {0x000, 0x04}, /* soc revision */
+ {0x00c, 0x0c}, /* SoC DNA */
+ {0x020, 0x04}, /* efuse-usr0 */
+ {0x024, 0x04}, /* efuse-usr1 */
+ {0x028, 0x04}, /* efuse-usr2 */
+ {0x02c, 0x04}, /* efuse-usr3 */
+ {0x030, 0x04}, /* efuse-usr4 */
+ {0x034, 0x04}, /* efuse-usr5 */
+ {0x038, 0x04}, /* efuse-usr6 */
+ {0x03c, 0x04}, /* efuse-usr7 */
+ {0x040, 0x04}, /* efuse-miscusr */
+ {0x050, 0x04}, /* efuse-chash */
+ {0x054, 0x04}, /* efuse-pufmisc */
+ {0x058, 0x04}, /* efuse-sec */
+ {0x05c, 0x04}, /* efuse-spkid */
+ {0x060, 0x30}, /* efuse-aeskey */
+ {0x0a0, 0x30}, /* ppk0-hash */
+ {0x0d0, 0x30}, /* ppk1-hash */
+ {0x100, 0x7f}, /* pufuser */
+};
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src: address of the buffer to store the data to be write/read
+ * @size: no of words to be read/write
+ * @offset: offset to be read/write`
a little bit different description compare to upsream linux
+ * @flag: 0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for
read/write
+ * 1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+ u64 src;
+ u32 size;
+ u32 offset;
+ u32 flag;
+ u32 pufuserfuse;
+};
+
+static int zynqmp_efuse_get_length(u32 offset, u32 *base_offset, u32
*len)
+{
+ struct efuse_map_entry *fuse;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(zynqmp_efuse_table); ++i) {
+ fuse = _efuse_table[i];
+ if (offset >= fuse->offset &&
+ offset <
Re: [PATCH v5 02/23] doc: ti: k3: Correct spelling mistakes and improve clarity
Hi Jon, Thank you for the patch. On ven., mai 31, 2024 at 17:20, Jonathan Humphreys wrote: > Few cosmetic fixes for clarity and spelling mistakes. > > Signed-off-by: Jonathan Humphreys Reviewed-by: Mattijs Korpershoek > --- > doc/board/ti/k3.rst | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst > index a1c01d1cf02..927f3976d34 100644 > --- a/doc/board/ti/k3.rst > +++ b/doc/board/ti/k3.rst > @@ -51,14 +51,14 @@ For all K3 SoCs the first core started will be inside the > Security > Management Subsystem (SMS) which will secure the device and start a core > in the wakeup domain to run the ROM code. ROM will then initialize the > boot media needed to load the binaries packaged inside `tiboot3.bin`, > -including a 32bit U-Boot SPL, (called the wakup SPL) that ROM will jump > +including a 32bit U-Boot SPL, (called the wakeup SPL) that ROM will jump > to after it has finished loading everything into internal SRAM. > > .. image:: img/boot_flow_01.svg >:alt: Boot flow up to wakeup domain SPL > > The wakeup SPL, running on a wakeup domain core, will initialize DDR and > -any peripherals needed load the larger binaries inside the `tispl.bin` > +any peripherals needed to load the larger binaries inside the `tispl.bin` > into DDR. Once loaded the wakeup SPL will start one of the 'big' > application cores inside the main domain to initialize the main domain, > starting with Trusted Firmware-A (TF-A), before moving on to start > @@ -94,7 +94,7 @@ essentially 4 unique but very similar flows: > * Combined binary with a split firmware: (eg: AM62) > > For devices that utilize the split binary approach, ROM is not capable > -of loading the firmware into the SoC requiring the wakeup domain's > +of loading the firmware into the SoC, requiring the wakeup domain's > U-Boot SPL to load the firmware. > > Devices with a split firmware will have two firmwares loaded into the > @@ -114,8 +114,8 @@ K3 HS-SE (High Security - Security Enforced) devices > enforce an > authenticated boot flow for secure boot. HS-FS (High Security - Field > Securable) is the state of a K3 device before it has been eFused with > customer security keys. In the HS-FS state the authentication still can > -function as in HS-SE but as there are no customer keys to verify the > -signatures against the authentication will pass for certificates signed > +function as in HS-SE, but as there are no customer keys to verify the > +signatures against, the authentication will pass for certificates signed > with any key. > > Chain of trust > -- > 2.34.1
Please pull u-boot-samsung master
Dear Tom, The following changes since commit 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a: Merge tag 'tpm-master-27052024' of https://source.denx.de/u-boot/custodians/u-boot-tpm (2024-05-27 08:56:02 -0600) are available in the git repository at: 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a for you to fetch changes up to 7045c4dd04648fd2ba1806b75e139d941db0d6c5: arm: exynos: Map iRAM APM area for Exynos850 SoC (2024-05-28 11:54:07 +0900) Sam Protsenko (3): arm: exynos: Migrate E850-96 board to OF_UPSTREAM arm: dts: e850-96: Remove not needed bootph-all flags arm: exynos: Map iRAM APM area for Exynos850 SoC MAINTAINERS | 7 +- arch/arm/dts/Makefile | 1 - arch/arm/dts/exynos850-e850-96-u-boot.dtsi | 28 -- arch/arm/dts/exynos850-e850-96.dts | 273 --- arch/arm/dts/exynos850-pinctrl.dtsi | 663 -- arch/arm/dts/exynos850.dtsi | 809 arch/arm/mach-exynos/Kconfig| 1 + arch/arm/mach-exynos/mmu-arm64.c| 8 + board/samsung/e850-96/MAINTAINERS | 1 - configs/e850-96_defconfig | 2 +- doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml | 307 - doc/device-tree-bindings/soc/samsung/exynos-usi.yaml| 162 include/dt-bindings/clock/exynos850.h | 337 --- include/dt-bindings/soc/samsung,exynos-usi.h| 17 -- 14 files changed, 11 insertions(+), 2605 deletions(-) delete mode 100644 arch/arm/dts/exynos850-e850-96.dts delete mode 100644 arch/arm/dts/exynos850-pinctrl.dtsi delete mode 100644 arch/arm/dts/exynos850.dtsi delete mode 100644 doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml delete mode 100644 doc/device-tree-bindings/soc/samsung/exynos-usi.yaml delete mode 100644 include/dt-bindings/clock/exynos850.h delete mode 100644 include/dt-bindings/soc/samsung,exynos-usi.h Thanks, Minkyu Kang.
