Re: [PATCH v3 05/13] firmware: scmi: install base protocol to SCMI agent
On Fri, Sep 08, 2023 at 02:19:22PM +, Etienne CARRIERE wrote:
> > From: AKASHI Takahiro
> > Sent: Friday, September 8, 2023 04:51
> >
> > SCMI base protocol is mandatory, and once SCMI node is found in a device
> > tree, the protocol handle (udevice) is unconditionally installed to
> > the agent. Then basic information will be retrieved from SCMI server via
> > the protocol and saved into the agent instance's local storage.
> >
> > Signed-off-by: AKASHI Takahiro
> > Reviewed-by: Simon Glass
> > Reviewed-by: Etienne Carriere
> > ---
> > v3
> > * typo fix: add '@' for argument name in function description
> > * eliminate dev_get_uclass_plat()'s repeated in inline
> > * modify the code for dynamically allocated sub-vendor/agent names
> > v2
> > * use helper functions, removing direct uses of ops
> > ---
>
> For info, I see that this patch, as placed in this PATCH v3 series, breaks
> pytest.
> Patch v3 08/13 ("firmware: scmi: fake base protocol commands on sandbox")
> and patch v3 09/13 ("test: dm: simplify SCMI unit test on sandbox") should be
> picked before to have scmi DM pytest running.
Thank you for catching this problem.
Will shuffle the commits.
-Takahiro Akashi
> BR,
> etienne
Re: [PATCH RFC 0/2] board: visionfive2: Select fdtfile based on revision
Hello Jami, For DDR size problem, I think we could enable CONFIG_OF_BOARD_SETUP, then use ft_board_setup() to apply fdt_fixup_memory()? Just like what they did in spl.c: https://patchwork.ozlabs.org/project/uboot/patch/20230615093652.23161-12-yanhong.w...@starfivetech.com/ Best regards, Shengyu (This mail is sent twice because the first one didn't use reply all) >From: Jami Kettunen > >Currently booting a mainline Linux kernel via extlinux with fdtdir set >doesn't load a proper DTB but passes on the U-Boot one to the kernel >which as far as I know is very incorrect and prevents user (normally >distro) provided DTB usage in a sensible/generic way. > >A uEnv.txt or similar manual environment changes were not used and >should not be required to boot the board as per: >https://u-boot.readthedocs.io/en/latest/develop/distro.html > >This also currently needs a kernel patch[1] for my board to have the >full 8GB of memory available to Linux instead of just 4GB it shows with >these patches alone. > >[1] >https://gitlab.alpinelinux.org/nmeum/alpine-visionfive/-/blob/main/starfive/linux-starfive/set-8GB-RAM.patch > >Jami Kettunen (2): > board: visionfive2: Select fdtfile based on revision > configs: visionfive2: Enable MISC_INIT_R > > .../visionfive2/starfive_visionfive2.c| 25 +++ > configs/starfive_visionfive2_defconfig| 1 + > 2 files changed, 26 insertions(+) >
Re: [PATCH v2 7/7] arm: dts: k3-j721e: Sync with v6.5-rc1
Hi Nishanth
On 11/09/23 16:53, Nishanth Menon wrote:
On 19:44-20230907, Neha Malcom Francis wrote:
Sync k3-j721e DTS with kernel.org v6.5-rc1.
Signed-off-by: Neha Malcom Francis
---
.../k3-j721e-common-proc-board-u-boot.dtsi| 146 +--
arch/arm/dts/k3-j721e-common-proc-board.dts | 483 ++---
arch/arm/dts/k3-j721e-main.dtsi | 974 --
arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 280 -
.../arm/dts/k3-j721e-r5-common-proc-board.dts | 302 +-
arch/arm/dts/k3-j721e-r5-sk.dts | 522 +-
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 177 +---
arch/arm/dts/k3-j721e-sk.dts | 663 +---
arch/arm/dts/k3-j721e-som-p0.dtsi | 226 ++--
arch/arm/dts/k3-j721e-thermal.dtsi| 75 ++
arch/arm/dts/k3-j721e.dtsi| 32 +-
11 files changed, 2365 insertions(+), 1515 deletions(-)
create mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 540c847eb3..4cca01be61 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -7,15 +7,7 @@
#include "k3-j721e-binman.dtsi"
/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
aliases {
- ethernet0 = _port1;
- spi0 =
- spi1 =
remoteproc0 = _r5fss0_core0;
remoteproc1 = _r5fss0_core1;
remoteproc2 = _r5fss0_core0;
@@ -25,61 +17,49 @@
remoteproc6 = _0;
remoteproc7 = _1;
remoteproc8 = _0;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c1;
- i2c3 = _i2c0;
};
As Manorit mentioned, drop the aliases
[...]
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
index 7bb5ce775c..0452e94b6d 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -12,16 +12,15 @@
#include
What are you using from phy-cadence.h?
This file has:
* tps659413 -> Should come in from upstream kernel please.
* flash@0 -> are intentionally changing properties here? if so document
why - same with ospi nodes (reg)
* hbmc is still retained. Though the node is disabled in u-boot.dtsi
[...]
diff --git a/arch/arm/dts/k3-j721e-r5-sk.dts b/arch/arm/dts/k3-j721e-r5-sk.dts
index 1cc64d07f7..f5eb29a861 100644
--- a/arch/arm/dts/k3-j721e-r5-sk.dts
+++ b/arch/arm/dts/k3-j721e-r5-sk.dts
@@ -11,151 +11,13 @@
#include "k3-j721e-sk-u-boot.dtsi"
/ {
- model = "Texas Instruments J721E SK R5";
+ chosen {
+ tick-timer = _timer0;
+ };
we have tps659412 defined here - should have come in from
upstream kernel.org
[...]
flash@0{
please fix that space before {
- compatible = "jedec,spi-nor";
- reg = <0x0>;
- spi-tx-bus-width = <8>;
- spi-rx-bus-width = <8>;
- spi-max-frequency = <2500>;
- cdns,tshsl-ns = <60>;
- cdns,tsd2d-ns = <60>;
- cdns,tchsh-ns = <60>;
- cdns,tslch-ns = <60>;
- cdns,read-delay = <4>;
cdns,phy-mode;
Why do we need this anymore?
#address-cells = <1>;
#size-cells = <1>;
};
};
[...]
diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
index 205dacff4d..e4bd71913c 100644
--- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
@@ -7,14 +7,7 @@
#include "k3-j721e-binman.dtsi"
You dont need to include ti-dp83867.h anymore.
/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
aliases {
- ethernet0 = _port1;
- spi0 =
remoteproc0 = _r5fss0_core0;
remoteproc1 = _r5fss0_core1;
remoteproc2 = _r5fss0_core0;
@@ -24,61 +17,49 @@
remoteproc6 = _0;
remoteproc7 = _1;
remoteproc8 = _0;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c0;
- mmc1 = _sdhci1; /* SD Card */
Same comment as before - drop all these aliases.
[...]
+_ringacc {
+ reg = <0x0 0x2b80 0x0 0x40>,
+ <0x0 0x2b00 0x0 0x40>,
+ <0x0 0x2859 0x0 0x100>,
+ <0x0 0x2a50 0x0 0x4>,
+ <0x0 0x2844 0x0 0x4>;
+ reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
+ bootph-pre-ram;
+};
- chipid@4314 {
+_udmap {
+
Re: [PATCH v3] bootstd: sata: Add bootstd support for ahci sata
Hi Simon,
On Sun, Sep 10, 2023 at 3:37 PM Simon Glass wrote:
>
> Hi Tony,
>
> On Fri, 8 Sept 2023 at 13:10, Tony Dinh wrote:
> >
> > Add ahci sata bootdev and corresponding hunting function.
> >
> > Signed-off-by: Tony Dinh
> > ---
> >
> > Changes in v3:
> > - Correct drivers/ata/Makefile to compile sata_bootdev only if
> > ahci sata is enabled.
> >
> > Changes in v2:
> > - set devtype to sata in bootmeth_script for non-scsi SATA device.
> >
> > boot/bootmeth_script.c | 12 ++--
> > drivers/ata/Makefile | 2 +-
> > drivers/ata/sata.c | 25 +++
> > drivers/ata/sata_bootdev.c | 62 ++
> > include/sata.h | 1 +
> > 5 files changed, 99 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/ata/sata_bootdev.c
> >
> > diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
> > index 58c57a2d4b..0269e0f9b0 100644
> > --- a/boot/bootmeth_script.c
> > +++ b/boot/bootmeth_script.c
> > @@ -190,10 +190,18 @@ static int script_boot(struct udevice *dev, struct
> > bootflow *bflow)
> > ulong addr;
> > int ret;
> >
> > - if (desc->uclass_id == UCLASS_USB)
> > + if (desc->uclass_id == UCLASS_USB) {
> > ret = env_set("devtype", "usb");
> > - else
> > + } else {
> > ret = env_set("devtype", blk_get_devtype(bflow->blk));
> > +
> > + /* If the parent uclass is AHCI, but the driver is ATA
> > +* (not scsi), set devtype to sata
> > +*/
> > + if (!ret && IS_ENABLED(CONFIG_SATA) &&
> > + !strcmp("ahci", env_get("devtype")))
>
> Can you not use desc->uclass_id to do the right thing here? It seems
> odd to compare with the value of the env var you just set up above.
Indeed, I must have been too caught up with the env :)
>
> > + ret = env_set("devtype", "sata");
> > + }
> > if (!ret)
> > ret = env_set_hex("devnum", desc->devnum);
> > if (!ret)
> > diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> > index 6e30180b8b..0b6f91098a 100644
> > --- a/drivers/ata/Makefile
> > +++ b/drivers/ata/Makefile
> > @@ -10,7 +10,7 @@ obj-$(CONFIG_SCSI_AHCI) += ahci.o
> > obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
> > obj-$(CONFIG_FSL_SATA) += fsl_sata.o
> > obj-$(CONFIG_LIBATA) += libata.o
> > -obj-$(CONFIG_SATA) += sata.o
> > +obj-$(CONFIG_SATA) += sata.o sata_bootdev.o
> > obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
> > obj-$(CONFIG_SATA_MV) += sata_mv.o
> > obj-$(CONFIG_SATA_SIL) += sata_sil.o
> > diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
> > index ce3e9b5a40..9da7218564 100644
> > --- a/drivers/ata/sata.c
> > +++ b/drivers/ata/sata.c
> > @@ -15,6 +15,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #ifndef CONFIG_AHCI
> > struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
> > @@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
> > return ops->scan(dev);
> > }
> >
> > +int sata_rescan(bool verbose)
> > +{
> > + struct udevice *dev;
> > + int devnum = 0;
> > + int ret;
> > +
> > + /* Find and probing the SATA controller */
> > + ret = uclass_get_device(UCLASS_AHCI, devnum, );
>
> This does not actually rescan...if the device has already been probed,
> it won't be probed again. You will need to use the logic like in
> sata_remove().
>
> Also, please avoid using devnum. You should probably just use
> uclass_probe_all(UCLASS_AHCI)
OK.
>
> > +
> > + /* Sanity check */
> > + if (ret)
> > + ret = uclass_find_first_device(UCLASS_AHCI, );
>
> That just finds it, but does not probe it. See uclass_first_device_err()
>
> > + if (ret) {
> > + printf("Cannot probe SATA device %d (err=%d)\n", devnum,
> > ret);
> > + return -ENOSYS;
>
> return ret
>
> > + }
> > + if (!dev) {
> > + printf("No SATA device found!\n");
> > + return -ENOSYS;
> > + }
> > + return 0;
> > +}
> > +
> > #ifndef CONFIG_AHCI
> > #ifdef CONFIG_PARTITIONS
> > struct blk_desc *sata_get_dev(int dev)
> > diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
> > new file mode 100644
> > index 00..f638493ce0
> > --- /dev/null
> > +++ b/drivers/ata/sata_bootdev.c
> > @@ -0,0 +1,62 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Bootdev for sata
> > + *
> > + * Copyright 2023 Tony Dinh
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static int sata_bootdev_bind(struct udevice *dev)
> > +{
> > + struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
> > +
> > + ucp->prio = BOOTDEVP_4_SCAN_FAST;
> > +
> > + return 0;
> > +}
> > +
> > +static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
> > +{
> > + int ret;
> > +
> > + if
Re: [PATCH v2 1/2] rockchip: Kconfig: Enable external TPL binary for rk3308
On 2023/9/9 17:33, Massimo Pegorer wrote: There is no support to initialize DRAM on rk3308 SoC using U-Boot TPL or SPL, and therefore an external TPL binary must be used to package a bootable u-boot-rockchip.bin image. Default ROCKCHIP_EXTERNAL_TPL to yes if ROCKCHIP_RK3308. Remove useless TPL_SERIAL. Signed-off-by: Massimo Pegorer Reviewed-by: Kever Yang Thanks, - Kever --- arch/arm/mach-rockchip/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index a279582f4f..3b044269bd 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -166,7 +166,6 @@ config ROCKCHIP_RK3308 imply SPL_SYSCON imply SPL_RAM imply SPL_SERIAL - imply TPL_SERIAL imply SPL_SEPARATE_BSS help The Rockchip RK3308 is a ARM-based Soc which embedded with quad @@ -436,7 +435,7 @@ config TPL_ROCKCHIP_COMMON_BOARD config ROCKCHIP_EXTERNAL_TPL bool "Use external TPL binary" - default y if ROCKCHIP_RK3568 || ROCKCHIP_RK3588 + default y if ROCKCHIP_RK3308 || ROCKCHIP_RK3568 || ROCKCHIP_RK3588 help Some Rockchip SoCs require an external TPL to initialize DRAM. Enable this option and build with ROCKCHIP_TPL=/path/to/ddr.bin to
Re: NVMe support on RPi CM4 board
Hi Simon, no problem, apologies for the quoting issue, and thank you for all your prompt answers and some guidance to try to understand what is happening. Although I'm still having the same issue, I'll share more insights just in case they might be useful for anyone having the same problem. 1. After I run nvme scan I'm noticing that the m.2 led starts flashing (it was not flashing, before running the command it was always On). 2. I'm having the same issue on the Official IO Board and Waveshare cm4-io-base-b, using latest stable rpi-eeprom firmware and boot files (start4x.elf, etc), latest u-boot version 2023.10-rc4 (I've also used previous versions, but using the latest one because it has debug messages) It does not appear that there is any GPIO related to NVMe. Unfortunately I'll move forward and try other boards. Thank you again for your help Simon. El dom, 10 sept 2023 a las 17:37, Simon Glass () escribió: > Hi Luis, > > On Tue, 5 Sept 2023 at 17:17, Luis Alfredo da Silva > wrote: > > > > Thanks for your answer Simon, > > > >> Can you check if the device has PCI bus master enabled? > > > > > > I think this one will take me a bit more time, should this be in > raspberry pi’s eeprom firmware? > > > > Will the disabled PCI bus master also be a problem for the Linux kernel? > As this is working as expected > > (BTW the quoting seems broken in your email; also the text came out > white so at first I thought you had sent an empty reply) > > Actually I can see that nvme_probe() turns on bus mastering. > > So no, I don't know what is wrong, sorry. Perhaps there are some > quirks in the Linux driver which need to be added to U-Boot? Perhaps > there is a power GPIO to set? > > Regards, > Simon >
Re: [PATCH] sunxi: board: provide CPU idle states to loaded OS
On Wed, 6 Sep 2023 23:53:51 +0300 Andrey Skvortsov wrote: Hi Andrey, we seem to have a very different approach to the whole booting process, which makes this conversation quite involved. I understand how things have been traditionally handled in the past, in the embedded world (DTBs bundled with the kernel, distros installing boot firmware), but we should really move on from this ill-fated approach. For a while now we try hard to keep the DTs compatible across several kernel version, making only compatible changes. In particular I have been deliberately keeping compatibility with pre-v5.13 kernels in the U-Boot copy of the Allwinner DTs, so you can always take the latest version and boot that with a wide range of kernels. > On 23-09-06 01:12, Andre Przywara wrote: > > On Tue, 5 Sep 2023 11:37:31 +0300 > > Andrey Skvortsov wrote: > > > > Hi, > > > > > On 23-09-05 09:27, Andre Przywara wrote: > > > > On Mon, 4 Sep 2023 23:54:30 +0300 > > > > Andrey Skvortsov wrote: > > > > > > > > Hi Andrey, > > > > > > > > > When using SCPI as the PSCI backend, firmware can wake up the CPUs and > > > > > cluster from sleep, so CPU idle states are available for loaded OS to > > > > > use. TF-A modifies DTB to advertise available CPU idle states, when > > > > > SCPI is detected. This change copies nodes added by TF-A to any new > > > > > dtb that is used for loaded OS. > > > > > > > > Why do you need that, exactly? Why not just use $fdtcontroladdr for the > > > > kernel? We now keep the U-Boot copy of the .dts files in sync with the > > > > kernel. If you need to modify the DT in U-Boot, for instance by applying > > > > overlays, you can copy that DTB into a better suitable location first: > > > > > > > > => fdt move $fdtcontroladdr $fdt_addr_r > > > > > > > > In any case, there shall be only one DT, that one in the U-Boot image. > > > > Why > > > > do you need to load another one for the kernel? > > > > > > extlinux is used by distributions (sometimes with device-specific changes > > > especially > > > > What distros are that? I guess some special ones, targeting embedded > > devices, like the Pinephone? > > It's more likely universal operating system. In my particular case > this is Mobian (several device-specific packages on top of > Debian). It's very-very close to Debian with a goal to be > pure Debian in the near future. > > Rhino Linux is using extlinux as well and will benefit for this change > as well. We seem to have a very different understanding of "universal operating systems" ;-) You seem to talk about specific distros for embedded devices, whereas I think of Ubuntu/Debian/Fedora/Arch/you-name-it. And I still don't understand what a particular distribution has to do with that: this is purely a question of boot firmware and who provides the DTB. > > And who is generating extlinux.conf then? Is that some distro specific > > scripting, similar to how grub is configured? > > extlinux.conf is automatically generated by standard Debian > u-boot-menu package. See [1] and [2]. Ah, thanks, I was looking for the extlinux package, which only seems to exist for x86. > > Honest questions, I am not a user of extlinux, I mostly use UEFI > > booting, or type U-Boot commands directly for experiments, or use > > boot.scr, as a quick-and-dirty hack. > > > > > for platforms not fully supported by mainline yet), > > > > Do you need any changes to the DT? Do you need to apply overlays? > > If you run on a non-mainlined platform, you could still put your DT > > into the U-Boot tree, then you wouldn't need to load another DTB, which > > also simplifies the deployment on the kernel/distro side. > > Currently Mobian linux kernel for sunxi-devices contains 36 extra patches > with DT That does not sound good. Why are those patches not upstream? > modifications (add/remove nodes, modify existing properties). One of > them unconditionally adds cpuidle states to DT, that I'm trying to fix > upstream here with the proposed change. That's very honourable, but not every patch that works(TM) is the right approach to take upstream. > DT overlays are not used. > > Honestly I don't think that using dtb from u-boot will simplify > distribution deployment and maintenance. IMHO, it will make things > more complex. Currently on my device there are records in extlinux.conf > for 5.9, 5.10, 5.15, several 6.1 kernels, that I'm working on. All of > them have slightly (or sometimes more) different device-trees. And why is that, exactly? The DT describes the *device*, so why do you have different DTs for different kernels? Sure, they evolve, devices get added and we will have fixes, but conceptually there should be one best DT for each device, for every kernel, and that could be the one in the U-Boot tree - or the one in the latest kernel *tree*. And why do you have different kernels to begin with? Are those various vendor kernels, for different SoCs, each with their own pile of
Re: [PATCH] arm: apple: Add initial Apple M2 Ultra support
> From: Janne Grunau
> Date: Wed, 06 Sep 2023 23:50:34 +0200
>
> Apple's M2 Ultra SoC are somewhat similar to the M1 Ultra but needs
> a tweaked memory map as the M2 Pro/Max SoCs. USB, NVMe, UART, WDT
> and PCIe are working with the existing drivers.
>
> Signed-off-by: Janne Grunau
Reviewed-by: Mark Kettenis
> ---
> arch/arm/mach-apple/board.c | 183
>
> 1 file changed, 183 insertions(+)
>
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index d50194811843..47393babbc62 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -444,6 +444,187 @@ static struct mm_region t6020_mem_map[] = {
> }
> };
>
> +/* Apple M2 Ultra */
> +
> +static struct mm_region t6022_mem_map[] = {
> + {
> + /* I/O */
> + .virt = 0x28000,
> + .phys = 0x28000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x34000,
> + .phys = 0x34000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x38000,
> + .phys = 0x38000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x58000,
> + .phys = 0x58000,
> + .size = SZ_512M,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* PCIE */
> + .virt = 0x5a000,
> + .phys = 0x5a000,
> + .size = SZ_512M,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRE) |
> + PTE_BLOCK_INNER_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* PCIE */
> + .virt = 0x5c000,
> + .phys = 0x5c000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRE) |
> + PTE_BLOCK_INNER_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x7,
> + .phys = 0x7,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0xb,
> + .phys = 0xb,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0xf,
> + .phys = 0xf,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x13,
> + .phys = 0x13,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x228000,
> + .phys = 0x228000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x234000,
> + .phys = 0x234000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x238000,
> + .phys = 0x238000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x258000,
> + .phys = 0x258000,
> + .size = SZ_512M,
> +
Re: [PATCH] arm: apple: Add initial Apple M2 Ultra support
> From: Simon Glass
> Date: Sun, 10 Sep 2023 16:36:48 -0600
>
> Hi,
>
> On Wed, 6 Sept 2023 at 15:50, Janne Grunau wrote:
> >
> > Apple's M2 Ultra SoC are somewhat similar to the M1 Ultra but needs
> > a tweaked memory map as the M2 Pro/Max SoCs. USB, NVMe, UART, WDT
> > and PCIe are working with the existing drivers.
> >
> > Signed-off-by: Janne Grunau
> > ---
> > arch/arm/mach-apple/board.c | 183
> >
> > 1 file changed, 183 insertions(+)
> >
> > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > index d50194811843..47393babbc62 100644
> > --- a/arch/arm/mach-apple/board.c
> > +++ b/arch/arm/mach-apple/board.c
> > @@ -444,6 +444,187 @@ static struct mm_region t6020_mem_map[] = {
> > }
> > };
> >
> > +/* Apple M2 Ultra */
> > +
> > +static struct mm_region t6022_mem_map[] = {
> > + {
> > + /* I/O */
> > + .virt = 0x28000,
> > + .phys = 0x28000,
> > + .size = SZ_1G,
> > + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +PTE_BLOCK_NON_SHARE |
> > +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > + }, {
>
> Is there no devicetree binding for this information?
Not directly. The device tree does contain the addresses of the
devices of course. But what we want here is a memory map that uses a
few big ranges that cover all the devices in the device tree rather
than lots of small ranges that cover the individual devices.
But yes, it sucks that every time Apple produces a new SoC we need to
add another memory map.
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Fri, Sep 08, 2023 at 06:28:14PM +0300, Ilias Apalodimas wrote: > Hi Tom, > > On Fri, 8 Sept 2023 at 17:54, Tom Rini wrote: > > > > On Fri, Sep 08, 2023 at 01:13:42PM +0300, Ilias Apalodimas wrote: > > > Hi Simon, > > > > > > On Thu, 7 Sept 2023 at 15:23, Simon Glass wrote: > > > > > > > > Hi Ilias, > > > > > > > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > > > > wrote: > > > > > > > > > > Hi Rob, > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > What is the point of removing them? Instead, we should > > > > > > > > > > > make sure that > > > > > > > > > > > we upstream the bindings and encourage SoC vendors to > > > > > > > > > > > sync them. If we > > > > > > > > > > > remove them, no one will bother and U-Boot just becomes a > > > > > > > > > > > dumping > > > > > > > > > > > ground. > > > > > > > > > > > > > > > > > > > > Well things like the binman entries in DT are U-Boot > > > > > > > > > > specific and not > > > > > > > > > > useful for HW related descriptions or for Linux or another > > > > > > > > > > OS being > > > > > > > > > > able to deal with HW so arguably we're already a dumping > > > > > > > > > > ground to > > > > > > > > > > some degree for not defining hardware. > > > > > > > > > > > > > > > > > > I have started the process to upstream the binman bindings. > > > > > > > > > > > > > > > > I don't think they should be in DT at all, they don't describe > > > > > > > > anything to do with hardware, or generally even the runtime of a > > > > > > > > device, they don't even describe the boot/runtime state of the > > > > > > > > firmware, they describe build time, so I don't see what that > > > > > > > > has to do > > > > > > > > with device tree? Can you explain that? To me those sorts of > > > > > > > > things > > > > > > > > should live in a build time style config file. > > > > > > > > > > > > For the record, I tend to agree. > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > I beg to differ. Devicetree is more than just hardware and always > > > > > > > has > > > > > > > been. See, for example the /chosen and /options nodes. > > > > > > > > > > > > There are exceptions... > > > > > > > > > > > > > > > > We've been this over and over again and frankly it gets a bit > > > > > annoying. > > > > > It's called *DEVICE* tree for a reason. As Rob pointed out there are > > > > > exceptions, but those made a lot of sense. Having arbitrary internal > > > > > ABI > > > > > stuff of various projects in the schema just defeats the definition > > > > > of a > > > > > spec. > > > > > > > > Our efforts should not just be about internal ABI, but working to > > > > provide a consistent configuration system for all firmware elements. > > > > > > And that's what the firmware handoff was all about. > > > I get what you are trying to do here. I am just aware of any other > > > > "just not aware" did you mean? > > Yep, sorry! > > > > > > project apart from U-Boot which uses DT for it's own configuration. > > > So trying to standardize some bindings that are useful to all projects > > > that use DT is fine. Trying to *enforce* them to use it for config > > > isn't IMHO. > > > > > > > > > > > We cannot have it both ways, i.e. refusing to accept non-hardware > > > > bindings and then complaining that U-Boot does not pass schema > > > > validation. Devicetree should be a shared resource, not just for the > > > > use of Linux. > > > > > > It's not for the use of Linux, I've wasted enough time repeating that > > > and so has Rob. Please go back to previous emails and read the > > > arguments. > > > > Right, it's not just for Linux, but Linux is where most of the > > exceptions to the "ONLY HARDWARE" rule got in, because they also make > > sense. > > Exactly. > > > And the overarching point Simon keeps trying to make I believe > > can be boiled down to that too. There are things that one does not have > > a (reasonable) choice about how to do things with when interacting with > > the hunk of melted sand on your desk and that information needs to go > > somewhere. > > DT is a big hammer indeed, but that doesn't mean we always need to use > it. I never disagreed with adding nodes that make sense and will be > useful for others. For example, the internal Driver model > configuration options used to enable a device early etc etc are > probably useful to more projects. On the other hand, if U-Boot is > indeed the only project using DT for its internal configuration why > should we care? > > For example, let's imagine you build TF-A, and TF-A is configured and > bundled with a device tree that gets passed along to U-Boot (using > OF_BOARD). Why on earth should TF-A be aware of internal DM > implementation details and build a device tree containing > u-boot,dm-pre-reloc, u-boot,dm-spl, dm-tpl, and every other > non-upstreamed nodes we have? I don't think this is a clear example, sorry. "dm-pre-reloc" etc are the bootph things now that you say
[PATCH v3 2/2] arm: dts: j7200: dts sync with Linux 6.6-rc1
Sync j7200 dts with Linux 6.6-rc1
- k3-j7200-r5-common-proc-board.dts now inherits from
k3-j7200-common-proc-board.dts instead of k3-j7200-som-p0.dtsi. This
allows us to trim down the r5 file considerably by using existing
properties
- remove pimux nodes from r5 file
- remove duplicate nodes & node properties from r5/u-boot files
- mcu_timer0 now used instead of timer1
mcu_timer0 device id added to dev-data.c file in order to work
- remove cpsw node
This node is no longer required since the compatible is now fixed
- remove dummy_clock_19_2_mhz
This node wasn't being used anyhere, so it was removed
- remove dummy_clock_200mhz
main_sdhci0 & main_sdhci1 no longer need dummy clock for eMMC/SD
- fix secure proxy node
mcu_secproxy changed to used secure_prxy_mcu which is already
defined in k3-j7200-mcu-wakeup.dtsi
- removed _ringacc property override since they're present in
v6.6-rc1
Reviewed-by: Nishanth Menon
Signed-off-by: Reid Tonking
---
.../k3-j7200-common-proc-board-u-boot.dtsi| 150 ++---
arch/arm/dts/k3-j7200-common-proc-board.dts | 188 +++---
arch/arm/dts/k3-j7200-main.dtsi | 535 +-
arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 286 +-
.../arm/dts/k3-j7200-r5-common-proc-board.dts | 301 +-
arch/arm/dts/k3-j7200-som-p0.dtsi | 154 +++--
arch/arm/dts/k3-j7200-thermal.dtsi| 47 ++
arch/arm/dts/k3-j7200.dtsi| 30 +-
arch/arm/dts/k3-serdes.h | 204 +++
9 files changed, 1382 insertions(+), 513 deletions(-)
create mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
create mode 100644 arch/arm/dts/k3-serdes.h
diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index f25c7136c9..41f94ae891 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -1,22 +1,13 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2023 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-j7200-binman.dtsi"
/ {
chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
- aliases {
- ethernet0 = _port1;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c1;
- i2c3 = _i2c0;
+ tick-timer = _timer0;
};
};
@@ -28,48 +19,36 @@
bootph-pre-ram;
};
-_mcu_wakeup {
+_esm {
bootph-pre-ram;
+};
- timer1: timer@4040 {
- compatible = "ti,omap5430-timer";
- reg = <0x0 0x4040 0x0 0x80>;
- ti,timer-alwon;
- clock-frequency = <25000>;
- bootph-pre-ram;
- };
+_mcu_wakeup {
+ bootph-pre-ram;
chipid@4314 {
bootph-pre-ram;
};
+};
- mcu_navss: bus@2838 {
- bootph-pre-ram;
- #address-cells = <2>;
- #size-cells = <2>;
-
- ringacc@2b80 {
- reg = <0x0 0x2b80 0x0 0x40>,
- <0x0 0x2b00 0x0 0x40>,
- <0x0 0x2859 0x0 0x100>,
- <0x0 0x2a50 0x0 0x4>,
- <0x0 0x2844 0x0 0x4>;
- reg-names = "rt", "fifos", "proxy_gcfg",
"proxy_target", "cfg";
- bootph-pre-ram;
- };
-
- dma-controller@285c {
- reg = <0x0 0x285c 0x0 0x100>,
- <0x0 0x284c 0x0 0x4000>,
- <0x0 0x2a80 0x0 0x4>,
- <0x0 0x284a 0x0 0x4000>,
- <0x0 0x2aa0 0x0 0x4>,
- <0x0 0x2840 0x0 0x2000>;
- reg-names = "gcfg", "rchan", "rchanrt", "tchan",
- "tchanrt", "rflow";
- bootph-pre-ram;
- };
- };
+_navss {
+ bootph-pre-ram;
+};
+
+_ringacc {
+ bootph-pre-ram;
+};
+
+_udmap {
+ reg = <0x0 0x285c 0x0 0x100>,
+ <0x0 0x284c 0x0 0x4000>,
+ <0x0 0x2a80 0x0 0x4>,
+ <0x0 0x284a 0x0 0x4000>,
+ <0x0 0x2aa0 0x0 0x4>,
+ <0x0 0x2840 0x0 0x2000>;
+ reg-names = "gcfg", "rchan", "rchanrt", "tchan",
+ "tchanrt", "rflow";
+ bootph-pre-ram;
};
_proxy_main {
@@ -100,6 +79,10 @@
bootph-pre-ram;
};
+_pmx2 {
+ bootph-pre-ram;
+};
+
_pmx0 {
bootph-pre-ram;
};
@@ -108,6 +91,10 @@
bootph-pre-ram;
};
+_uart2 {
+
[PATCH v3 1/2] arm: mach-k3: j7200: Add mcu_timer0 id to the dev list
mcu_timer0 is now used as the tick timer in u-boot, so this adds the
timer to the soc device list so it can be enabled via the k3 power
controller.
Reviewed-by: Nishanth Menon
Signed-off-by: Reid Tonking
---
arch/arm/mach-k3/j7200/dev-data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-k3/j7200/dev-data.c
b/arch/arm/mach-k3/j7200/dev-data.c
index 4ddc34210e..8ce6796fd0 100644
--- a/arch/arm/mach-k3/j7200/dev-data.c
+++ b/arch/arm/mach-k3/j7200/dev-data.c
@@ -46,6 +46,7 @@ static struct ti_lpsc soc_lpsc_list[] = {
static struct ti_dev soc_dev_list[] = {
PSC_DEV(30, _lpsc_list[0]),
+ PSC_DEV(35, _lpsc_list[0]),
PSC_DEV(61, _lpsc_list[1]),
PSC_DEV(90, _lpsc_list[2]),
PSC_DEV(8, _lpsc_list[3]),
--
2.34.1
[PATCH v3 0/2] J7200 device tree sync from v6.6-rc1 to u-boot
This series tries to sync device tree files from Linux v6.6-rc1 while making changes to the u-boot.dtsi and r5-common-proc-board.dts files in order to remove duplicate nodes and achieve successful boot. This is dependent on [0]. This patch was originally a part of v2, but was spun of as a dependency for both j7200 & j721e dtb sync series. DMA fixes [1] are currently being upstreamed to Linux. They'll be fixed in U-boot post their merge in Linux. Test Logs are included in [2] [0]: https://lore.kernel.org/u-boot/20230907180635.89011-1-re...@ti.com/T/#u [1]: https://lore.kernel.org/all/20230810174356.3322583-1-vigne...@ti.com/ [2]: https://gist.github.com/Glockn/ecbe92606a8a772486fb9f636dd1f814 --- Changes in v3: - Sync is now ith v6.6-rc1 instead of v6.5-rc1 - _ringacc property overrides in u-boot.dtsi removed (patch 2/2) - Change to drivers/misc/k3_avs.c is now a separate patch [0] - dropped the trailing white space (patch 1/2) - changed wording in commit message (patch 2/2) - added k3_sysreset node back into u-boot.dtsi (patch 2/2) - Link to v2: https://lore.kernel.org/u-boot/20230905181309.61666-1-re...@ti.com/T/#m8d254c1d912aae3b636fadb23a0c8aacdd9ea484 --- Reid Tonking (2): arm: mach-k3: j7200: Add mcu_timer0 id to the dev list arm: dts: j7200: dts sync with Linux 6.6-rc1 .../k3-j7200-common-proc-board-u-boot.dtsi| 150 ++--- arch/arm/dts/k3-j7200-common-proc-board.dts | 188 +++--- arch/arm/dts/k3-j7200-main.dtsi | 535 +- arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 286 +- .../arm/dts/k3-j7200-r5-common-proc-board.dts | 301 +- arch/arm/dts/k3-j7200-som-p0.dtsi | 154 +++-- arch/arm/dts/k3-j7200-thermal.dtsi| 47 ++ arch/arm/dts/k3-j7200.dtsi| 30 +- arch/arm/dts/k3-serdes.h | 204 +++ arch/arm/mach-k3/j7200/dev-data.c | 1 + 10 files changed, 1383 insertions(+), 513 deletions(-) create mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi create mode 100644 arch/arm/dts/k3-serdes.h -- 2.34.1
[PATCH v2 8/8] arch: meson: use secure monitor driver
Now we have to use UCLASS_SM driver instead of
raw smc_call() function call.
Signed-off-by: Alexey Romanov
---
arch/arm/mach-meson/Kconfig | 1 +
arch/arm/mach-meson/sm.c| 110 +++-
2 files changed, 58 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index 669ca09a00..d6c8905806 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -11,6 +11,7 @@ config MESON64_COMMON
select PWRSEQ
select MMC_PWRSEQ
select BOARD_LATE_INIT
+ select MESON_SM
imply CMD_DM
config MESON_GX
diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c
index b5dd6c6d39..0c60aa8695 100644
--- a/arch/arm/mach-meson/sm.c
+++ b/arch/arm/mach-meson/sm.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,70 +19,62 @@
#include
#include
#include
+#include
-#define FN_GET_SHARE_MEM_INPUT_BASE0x8220
-#define FN_GET_SHARE_MEM_OUTPUT_BASE 0x8221
-#define FN_EFUSE_READ 0x8230
-#define FN_EFUSE_WRITE 0x8231
-#define FN_CHIP_ID 0x8244
-#define FN_PWRDM_SET 0x8293
-
-static void *shmem_input;
-static void *shmem_output;
-
-static void meson_init_shmem(void)
+static inline struct udevice *meson_get_sm_device(void)
{
- struct pt_regs regs;
-
- if (shmem_input && shmem_output)
- return;
+ struct udevice *dev;
+ int err;
- regs.regs[0] = FN_GET_SHARE_MEM_INPUT_BASE;
- smc_call();
- shmem_input = (void *)regs.regs[0];
-
- regs.regs[0] = FN_GET_SHARE_MEM_OUTPUT_BASE;
- smc_call();
- shmem_output = (void *)regs.regs[0];
+ err = uclass_get_device_by_name(UCLASS_SM, "secure-monitor", );
+ if (err) {
+ pr_err("Mesom SM device not found\n");
+ return ERR_PTR(err);
+ }
- debug("Secure Monitor shmem: 0x%p 0x%p\n", shmem_input, shmem_output);
+ return dev;
}
ssize_t meson_sm_read_efuse(uintptr_t offset, void *buffer, size_t size)
{
- struct pt_regs regs;
+ struct udevice *dev;
+ struct pt_regs regs = { 0 };
+ int err;
- meson_init_shmem();
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
- regs.regs[0] = FN_EFUSE_READ;
regs.regs[1] = offset;
regs.regs[2] = size;
- smc_call();
+ err = sm_call_read(dev, buffer, size,
+ MESON_SMC_CMD_EFUSE_READ, );
+ if (err < 0)
+ pr_err("Failed to read efuse memory (%d)\n", err);
- if (regs.regs[0] == 0)
- return -1;
-
- memcpy(buffer, shmem_output, min(size, regs.regs[0]));
-
- return regs.regs[0];
+ return err;
}
ssize_t meson_sm_write_efuse(uintptr_t offset, void *buffer, size_t size)
{
- struct pt_regs regs;
-
- meson_init_shmem();
+ struct udevice *dev;
+ struct pt_regs regs = { 0 };
+ int err;
-memcpy(shmem_input, buffer, size);
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
- regs.regs[0] = FN_EFUSE_WRITE;
regs.regs[1] = offset;
regs.regs[2] = size;
- smc_call();
+ err = sm_call_write(dev, buffer, size,
+ MESON_SMC_CMD_EFUSE_WRITE, );
+ if (err < 0)
+ pr_err("Failed to write efuse memory (%d)\n", err);
- return regs.regs[0];
+ return err;
}
#define SM_CHIP_ID_LENGTH 119
@@ -90,18 +83,21 @@ ssize_t meson_sm_write_efuse(uintptr_t offset, void
*buffer, size_t size)
int meson_sm_get_serial(void *buffer, size_t size)
{
- struct pt_regs regs;
+ struct udevice *dev;
+ struct pt_regs regs = { 0 };
+ u8 id_buffer[SM_CHIP_ID_LENGTH];
+ int err;
- meson_init_shmem();
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
- regs.regs[0] = FN_CHIP_ID;
- regs.regs[1] = 0;
- regs.regs[2] = 0;
+ err = sm_call_read(dev, id_buffer, SM_CHIP_ID_LENGTH,
+ MESON_SMC_CMD_CHIP_ID_GET, );
+ if (err < 0)
+ pr_err("Failed to read serial number (%d)\n", err);
- smc_call();
-
- memcpy(buffer, shmem_output + SM_CHIP_ID_OFFSET,
- min_t(size_t, size, SM_CHIP_ID_SIZE));
+ memcpy(buffer, id_buffer + SM_CHIP_ID_OFFSET, size);
return 0;
}
@@ -141,13 +137,21 @@ int meson_sm_get_reboot_reason(void)
int meson_sm_pwrdm_set(size_t index, int cmd)
{
- struct pt_regs regs;
+ struct udevice *dev;
+ struct pt_regs regs = { 0 };
+ int err;
+
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
- regs.regs[0] = FN_PWRDM_SET;
[PATCH v2 6/8] drivers: introduce Meson Secure Monitor driver
This patch adds an implementation of the Meson Secure Monitor
driver based on UCLASS_SM.
Signed-off-by: Alexey Romanov
---
MAINTAINERS | 1 +
drivers/sm/Kconfig| 7 ++
drivers/sm/Makefile | 1 +
drivers/sm/meson-sm.c | 198 ++
include/meson/sm.h| 19
5 files changed, 226 insertions(+)
create mode 100644 drivers/sm/meson-sm.c
create mode 100644 include/meson/sm.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 6c64427782..bdc364fd4c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -158,6 +158,7 @@ F: drivers/net/phy/meson-gxl.c
F: drivers/adc/meson-saradc.c
F: drivers/phy/meson*
F: drivers/mmc/meson_gx_mmc.c
+F: drivers/sm/meson-sm.c
F: drivers/spi/meson_spifc.c
F: drivers/pinctrl/meson/
F: drivers/power/domain/meson-gx-pwrc-vpu.c
diff --git a/drivers/sm/Kconfig b/drivers/sm/Kconfig
index 6cc6d55578..b4cc3f768e 100644
--- a/drivers/sm/Kconfig
+++ b/drivers/sm/Kconfig
@@ -1,2 +1,9 @@
config SM
bool "Enable Secure Monitor driver support"
+
+config MESON_SM
+ bool "Amlogic Secure Monitor driver"
+ depends on SM
+ default n
+ help
+ Say y here to enable the Amlogic secure monitor driver.
diff --git a/drivers/sm/Makefile b/drivers/sm/Makefile
index af5f475c2b..da81ee898a 100644
--- a/drivers/sm/Makefile
+++ b/drivers/sm/Makefile
@@ -2,3 +2,4 @@
obj-y += sm-uclass.o
obj-$(CONFIG_SANDBOX) += sandbox-sm.o
+obj-$(CONFIG_MESON_SM) += meson-sm.o
diff --git a/drivers/sm/meson-sm.c b/drivers/sm/meson-sm.c
new file mode 100644
index 00..25adaf4560
--- /dev/null
+++ b/drivers/sm/meson-sm.c
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct meson_sm_cmd {
+ u32 smc_id;
+};
+
+#define SET_CMD(index, id) \
+ [index] = { \
+ .smc_id = (id), \
+ }
+
+struct meson_sm_data {
+ u32 cmd_get_shmem_in;
+ u32 cmd_get_shmem_out;
+ unsigned int shmem_size;
+ struct meson_sm_cmd cmd[];
+};
+
+struct meson_sm_priv {
+ void *sm_shmem_in;
+ void *sm_shmem_out;
+ const struct meson_sm_data *data;
+};
+
+static unsigned long __meson_sm_call(u32 cmd, const struct pt_regs *args)
+{
+ struct pt_regs r = *args;
+
+ r.regs[0] = cmd;
+ smc_call();
+
+ return r.regs[0];
+};
+
+static u32 meson_sm_get_cmd(const struct meson_sm_data *data,
+ u32 cmd_index)
+{
+ struct meson_sm_cmd cmd;
+
+ if (cmd_index >= MESON_SMC_CMD_COUNT)
+ return 0;
+
+ cmd = data->cmd[cmd_index];
+ return cmd.smc_id;
+}
+
+static int meson_sm_call(struct udevice *dev, u32 cmd_index, s32 *retval,
+struct pt_regs *args)
+{
+ struct meson_sm_priv *priv = dev_get_priv(dev);
+ u32 cmd, ret;
+
+ cmd = meson_sm_get_cmd(priv->data, cmd_index);
+ if (!cmd)
+ return -ENOENT;
+
+ ret = __meson_sm_call(cmd, args);
+ if (retval)
+ *retval = ret;
+
+ return 0;
+}
+
+static int meson_sm_call_read(struct udevice *dev, void *buffer, size_t size,
+ u32 cmd_index, struct pt_regs *args)
+{
+ struct meson_sm_priv *priv = dev_get_priv(dev);
+ s32 nbytes;
+ int ret;
+
+ if (!buffer || size > priv->data->shmem_size)
+ return -EINVAL;
+
+ ret = meson_sm_call(dev, cmd_index, , args);
+ if (ret)
+ return ret;
+
+ if (nbytes < 0 || nbytes > size)
+ return -ENOBUFS;
+
+ /* In some cases (for example GET_CHIP_ID command),
+* SMC doesn't return the number of bytes read, even
+* though the bytes were actually read into sm_shmem_out.
+* So this check is needed.
+*/
+ ret = nbytes;
+ if (!nbytes)
+ nbytes = size;
+
+ memcpy(buffer, priv->sm_shmem_out, nbytes);
+
+ return ret;
+}
+
+static int meson_sm_call_write(struct udevice *dev, void *buffer, size_t size,
+ u32 cmd_index, struct pt_regs *args)
+{
+ struct meson_sm_priv *priv = dev_get_priv(dev);
+ s32 nbytes;
+ int ret;
+
+ if (!buffer || size > priv->data->shmem_size)
+ return -EINVAL;
+
+ memcpy(priv->sm_shmem_in, buffer, size);
+
+ ret = meson_sm_call(dev, cmd_index, , args);
+ if (ret)
+ return ret;
+
+ if (nbytes <= 0 || nbytes > size)
+ return -EIO;
+
+ return nbytes;
+}
+
+static int meson_sm_probe(struct udevice *dev)
+{
+ struct meson_sm_priv *priv = dev_get_priv(dev);
+ struct pt_regs regs = { 0 };
+
+ priv->data = (struct meson_sm_data
[PATCH v2 7/8] arch: meson: sm: set correct order of the includes
The common.h header should always be first, followed by other headers in order, then headers with directories, then local files. Signed-off-by: Alexey Romanov --- arch/arm/mach-meson/sm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c index d600c64d0b..b5dd6c6d39 100644 --- a/arch/arm/mach-meson/sm.c +++ b/arch/arm/mach-meson/sm.c @@ -6,7 +6,10 @@ */ #include +#include #include +#include +#include #include #include #include @@ -14,10 +17,7 @@ #include #include #include -#include #include -#include -#include #define FN_GET_SHARE_MEM_INPUT_BASE0x8220 #define FN_GET_SHARE_MEM_OUTPUT_BASE 0x8221 -- 2.25.1
[PATCH v2 5/8] sandbox: defconfig: enable CONFIG_SM option
We use this option for test UCLASS_SM. Signed-off-by: Alexey Romanov --- configs/sandbox_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index be46cae7aa..0745a4ecca 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -270,6 +270,7 @@ CONFIG_RTC_RV8803=y CONFIG_SCSI=y CONFIG_DM_SCSI=y CONFIG_SANDBOX_SERIAL=y +CONFIG_SM=y CONFIG_SMEM=y CONFIG_SANDBOX_SMEM=y CONFIG_SOUND=y -- 2.25.1
[PATCH v2 4/8] sandbox: add tests for UCLASS_SM
This patchs adds simple tests for Secure Monitor uclass.
Signed-off-by: Alexey Romanov
---
test/dm/Makefile | 1 +
test/dm/sm.c | 65
2 files changed, 66 insertions(+)
create mode 100644 test/dm/sm.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 7a79b6e1a2..30550a62ad 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_DM_SPI) += spi.o
obj-$(CONFIG_SPMI) += spmi.o
obj-y += syscon.o
obj-$(CONFIG_RESET_SYSCON) += syscon-reset.o
+obj-$(CONFIG_SM) += sm.o
obj-$(CONFIG_SYSINFO) += sysinfo.o
obj-$(CONFIG_SYSINFO_GPIO) += sysinfo-gpio.o
obj-$(CONFIG_UT_DM) += tag.o
diff --git a/test/dm/sm.c b/test/dm/sm.c
new file mode 100644
index 00..7ebb0c9c85
--- /dev/null
+++ b/test/dm/sm.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int dm_test_sm(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+ struct pt_regs regs;
+ char buffer[128] = { 0 };
+ char test_string[] = "secure-monitor";
+ int ret, val;
+
+ ut_assertok(uclass_get_device_by_name(UCLASS_SM,
+ "secure-monitor", ));
+
+ ret = sm_call(dev, SANDBOX_SMC_CMD_COUNT, NULL, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call(dev, SANDBOX_SMC_CMD_COMMON, , );
+ ut_asserteq(ret, 0);
+ ut_asserteq(val, 0);
+
+ ret = sm_call_write(dev, buffer, sizeof(buffer),
+ SANDBOX_SMC_CMD_COUNT, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call_write(dev, buffer, SZ_4K + 1,
+ SANDBOX_SMC_CMD_WRITE_MEM, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call_write(dev, buffer, sizeof(buffer),
+ SANDBOX_SMC_CMD_COUNT, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call_write(dev, buffer, SZ_4K + 1,
+ SANDBOX_SMC_CMD_READ_MEM, );
+ ut_asserteq(ret, -EINVAL);
+
+ ret = sm_call_write(dev, test_string, sizeof(test_string),
+ SANDBOX_SMC_CMD_WRITE_MEM, );
+ ut_asserteq(ret, sizeof(test_string));
+
+ ret = sm_call_read(dev, buffer, sizeof(buffer),
+ SANDBOX_SMC_CMD_READ_MEM, );
+ ut_asserteq(ret, sizeof(buffer));
+
+ ut_asserteq_str(buffer, test_string);
+
+ return 0;
+}
+
+DM_TEST(dm_test_sm, UT_TESTF_SCAN_FDT);
--
2.25.1
[PATCH v2 3/8] sandbox: dts: add meson secure monitor node
We need this to test UCLASS_SM.
Signed-off-by: Alexey Romanov
---
arch/sandbox/dts/test.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dffe10adbf..4475aa58a6 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -693,6 +693,10 @@
};
};
};
+
+ sm: secure-monitor {
+ compatible = "sandbox,sm";
+ };
};
fpga {
--
2.25.1
[PATCH v2 2/8] sandbox: add sandobx sm uclass driver
This patch adds sandbox secure monitor driver.
Signed-off-by: Alexey Romanov
---
drivers/sm/Makefile | 1 +
drivers/sm/sandbox-sm.c | 76 +
include/sandbox-sm.h| 18 ++
3 files changed, 95 insertions(+)
create mode 100644 drivers/sm/sandbox-sm.c
create mode 100644 include/sandbox-sm.h
diff --git a/drivers/sm/Makefile b/drivers/sm/Makefile
index 9f4683ba06..af5f475c2b 100644
--- a/drivers/sm/Makefile
+++ b/drivers/sm/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-y += sm-uclass.o
+obj-$(CONFIG_SANDBOX) += sandbox-sm.o
diff --git a/drivers/sm/sandbox-sm.c b/drivers/sm/sandbox-sm.c
new file mode 100644
index 00..109ddb2af5
--- /dev/null
+++ b/drivers/sm/sandbox-sm.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static u8 test_buffer[SZ_4K];
+
+static int sandbox_sm_call(struct udevice *dev, u32 cmd_index, s32 *smc_ret,
+ struct pt_regs *args)
+{
+ if (cmd_index >= SANDBOX_SMC_CMD_COUNT)
+ return -EINVAL;
+
+ if (smc_ret)
+ *smc_ret = 0;
+
+ return 0;
+}
+
+static int sandbox_sm_call_read(struct udevice *dev, void *buffer, size_t size,
+ u32 cmd_index, struct pt_regs *args)
+{
+ if (cmd_index >= SANDBOX_SMC_CMD_COUNT || !buffer)
+ return -EINVAL;
+
+ if (size > sizeof(test_buffer))
+ return -EINVAL;
+
+ memcpy(buffer, test_buffer, size);
+
+ return size;
+}
+
+static int sandbox_sm_call_write(struct udevice *dev, void *buffer, size_t
size,
+u32 cmd_index, struct pt_regs *args)
+{
+ if (cmd_index >= SANDBOX_SMC_CMD_COUNT || !buffer)
+ return -EINVAL;
+
+ if (size > sizeof(test_buffer))
+ return -EINVAL;
+
+ memcpy(test_buffer, buffer, size);
+
+ return size;
+}
+
+static const struct udevice_id sandbox_sm_ids[] = {
+ {
+ .compatible = "sandbox,sm",
+ },
+ {},
+};
+
+static const struct sm_ops sandbox_sm_ops = {
+ .sm_call = sandbox_sm_call,
+ .sm_call_read = sandbox_sm_call_read,
+ .sm_call_write = sandbox_sm_call_write,
+};
+
+U_BOOT_DRIVER(sm) = {
+ .name = "sm",
+ .id = UCLASS_SM,
+ .of_match = sandbox_sm_ids,
+ .ops = _sm_ops,
+};
diff --git a/include/sandbox-sm.h b/include/sandbox-sm.h
new file mode 100644
index 00..91c30d501d
--- /dev/null
+++ b/include/sandbox-sm.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#ifndef __SANDBOX_SM_H__
+#define __SANDBOX_SM_H__
+
+enum sandbox_smc_cmd {
+ SANDBOX_SMC_CMD_READ_MEM,
+ SANDBOX_SMC_CMD_WRITE_MEM,
+ SANDBOX_SMC_CMD_COMMON,
+ SANDBOX_SMC_CMD_COUNT,
+};
+
+#endif
--
2.25.1
[PATCH v2 1/8] drivers: introduce Secure Monitor uclass
At the moment, we don't have a common API for working with
SM, only the smc_call() function. This approach is not generic
and difficult to configure and maintain.
This patch adds UCLASS_SM with the generic API:
- sm_call()
- sm_call_write()
- sm_call_read()
These functions operate with struct pt_regs, which describes
Secure Monitor arguments.
Signed-off-by: Alexey Romanov
---
drivers/Kconfig| 2 ++
drivers/Makefile | 1 +
drivers/sm/Kconfig | 2 ++
drivers/sm/Makefile| 3 ++
drivers/sm/sm-uclass.c | 55
include/dm/uclass-id.h | 1 +
include/sm-uclass.h| 72 ++
include/sm.h | 67 +++
8 files changed, 203 insertions(+)
create mode 100644 drivers/sm/Kconfig
create mode 100644 drivers/sm/Makefile
create mode 100644 drivers/sm/sm-uclass.c
create mode 100644 include/sm-uclass.h
create mode 100644 include/sm.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 75ac149d31..72e6405322 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -112,6 +112,8 @@ source "drivers/scsi/Kconfig"
source "drivers/serial/Kconfig"
+source "drivers/sm/Kconfig"
+
source "drivers/smem/Kconfig"
source "drivers/sound/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 6f1de58e00..b7bd3633b1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -124,3 +124,4 @@ obj-$(CONFIG_DM_RNG) += rng/
endif
obj-y += soc/
+obj-y += sm/
diff --git a/drivers/sm/Kconfig b/drivers/sm/Kconfig
new file mode 100644
index 00..6cc6d55578
--- /dev/null
+++ b/drivers/sm/Kconfig
@@ -0,0 +1,2 @@
+config SM
+ bool "Enable Secure Monitor driver support"
diff --git a/drivers/sm/Makefile b/drivers/sm/Makefile
new file mode 100644
index 00..9f4683ba06
--- /dev/null
+++ b/drivers/sm/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-y += sm-uclass.o
diff --git a/drivers/sm/sm-uclass.c b/drivers/sm/sm-uclass.c
new file mode 100644
index 00..78af857026
--- /dev/null
+++ b/drivers/sm/sm-uclass.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+
+static const struct sm_ops *get_sm_ops(struct udevice *dev)
+{
+ return (const struct sm_ops *)dev->driver->ops;
+}
+
+int sm_call(struct udevice *dev, u32 cmd, s32 *ret, struct pt_regs *args)
+{
+ const struct sm_ops *ops = get_sm_ops(dev);
+
+ if (ops->sm_call)
+ return ops->sm_call(dev, cmd, ret, args);
+
+ return -EPROTONOSUPPORT;
+}
+
+int sm_call_read(struct udevice *dev, void *buffer, size_t size,
+u32 cmd, struct pt_regs *args)
+{
+ const struct sm_ops *ops = get_sm_ops(dev);
+
+ if (ops->sm_call_read)
+ return ops->sm_call_read(dev, buffer, size, cmd,
+args);
+
+ return -EPROTONOSUPPORT;
+}
+
+int sm_call_write(struct udevice *dev, void *buffer, size_t size,
+ u32 cmd, struct pt_regs *args)
+{
+ const struct sm_ops *ops = get_sm_ops(dev);
+
+ if (ops->sm_call_write)
+ return ops->sm_call_write(dev, buffer, size, cmd,
+ args);
+
+ return -EPROTONOSUPPORT;
+}
+
+UCLASS_DRIVER(sm) = {
+ .name = "sm",
+ .id = UCLASS_SM,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 376f741cc2..545c9352a8 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -80,6 +80,7 @@ enum uclass_id {
UCLASS_MDIO,/* MDIO bus */
UCLASS_MDIO_MUX,/* MDIO MUX/switch */
UCLASS_MEMORY, /* Memory Controller device */
+ UCLASS_SM, /* Secure Monitor driver */
UCLASS_MISC,/* Miscellaneous device */
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
diff --git a/include/sm-uclass.h b/include/sm-uclass.h
new file mode 100644
index 00..c114484044
--- /dev/null
+++ b/include/sm-uclass.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#ifndef __SM_UCLASS_H__
+#define __SM_UCLASS_H__
+
+#include
+#include
+
+struct udevice;
+
+/**
+ * struct sm_ops - The functions that a SM driver must implement.
+ *
+ * @sm_call: Request a secure monitor call with specified command.
+ *
+ * @sm_call_read: Request a secure monitor call and retrieve data
+ * from secure-monitor (depends on specified command).
+ *
+ * @sm_call_write: Request a secure monitor call and send data
+ * to secure-monitor (depends on specified command).
+ *
+ * The individual methods are described more fully below.
+ */
+struct sm_ops {
+ /**
+* sm_call - generic SMC call to the
[PATCH v2 0/8] Add SM uclass and Meson SM driver
Hello! At the moment, there is no single general approach to using secure monitor in U-Boot, there is only the smc_call() function, over which everyone builds their own add-ons. This patchset is designed to solve this problem by adding a new uclass - SM_UCLASS. This UCLASS export following generic API: 1. sm_call() - generic SMC call to the secure-monitor 2. sm_call_read() - retrieve data from secure-monitor 3. sm_call_write() - send data to secure-monitor In the future, it is necessary to completely get rid of raw smc_call() calls, replacing them with the use of SM_UCLASS based drivers. V2: - Add SM UCLASS - Add SM sandbox driver - Add test for sandbox driver - Meson Secure Monitor driver now based on SM_UCLASS - Fix include order in arch/arm/mach-meson/sm.c Also, during the discussion in V1 of this patchset, it was discussed to create MESON_SM_UCLASS, but I considered such a uclass to be too arch-specific. That's why I suggest SM_UCLASS, which is not so arch-specific: secure monitor can used for whole ARM devices, not only for Amlogic SoC's. Alexey Romanov (8): drivers: introduce Secure Monitor uclass sandbox: add sandobx sm uclass driver sandbox: dts: add meson secure monitor node sandbox: add tests for UCLASS_SM sandbox: defconfig: enable CONFIG_SM option drivers: introduce Meson Secure Monitor driver arch: meson: sm: set correct order of the includes arch: meson: use secure monitor driver MAINTAINERS | 1 + arch/arm/mach-meson/Kconfig | 1 + arch/arm/mach-meson/sm.c| 116 +++-- arch/sandbox/dts/test.dts | 4 + configs/sandbox_defconfig | 1 + drivers/Kconfig | 2 + drivers/Makefile| 1 + drivers/sm/Kconfig | 9 ++ drivers/sm/Makefile | 5 + drivers/sm/meson-sm.c | 198 drivers/sm/sandbox-sm.c | 76 ++ drivers/sm/sm-uclass.c | 55 ++ include/dm/uclass-id.h | 1 + include/meson/sm.h | 19 include/sandbox-sm.h| 18 include/sm-uclass.h | 72 + include/sm.h| 67 test/dm/Makefile| 1 + test/dm/sm.c| 65 19 files changed, 656 insertions(+), 56 deletions(-) create mode 100644 drivers/sm/Kconfig create mode 100644 drivers/sm/Makefile create mode 100644 drivers/sm/meson-sm.c create mode 100644 drivers/sm/sandbox-sm.c create mode 100644 drivers/sm/sm-uclass.c create mode 100644 include/meson/sm.h create mode 100644 include/sandbox-sm.h create mode 100644 include/sm-uclass.h create mode 100644 include/sm.h create mode 100644 test/dm/sm.c -- 2.25.1
[PATCH RFC 2/2] configs: visionfive2: Enable MISC_INIT_R
From: Jami Kettunen Used to select mainline kernel fdtfile based on board revision. Signed-off-by: Jami Kettunen --- configs/starfive_visionfive2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index e9b63e5b84..33f9ec8ad6 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -125,3 +125,4 @@ CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y CONFIG_USB_KEYBOARD=y +CONFIG_MISC_INIT_R=y -- 2.42.0
[PATCH RFC 1/2] board: visionfive2: Select fdtfile based on revision
From: Jami Kettunen
Linux mainline kernel device tree files[1] are named:
- jh7110-starfive-visionfive-2-v1.2a
- jh7110-starfive-visionfive-2-v1.3b
which should be selected accordingly by U-Boot to have a proper extlinux
experience with fdtdir set by the distribution.
[1] https://github.com/torvalds/linux/tree/master/arch/riscv/boot/dts/starfive
Signed-off-by: Jami Kettunen
---
.../visionfive2/starfive_visionfive2.c| 25 +++
1 file changed, 25 insertions(+)
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
b/board/starfive/visionfive2/starfive_visionfive2.c
index d609262b67..9244d4654b 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
#define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
#define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
@@ -41,6 +43,29 @@ int board_init(void)
return 0;
}
+int misc_init_r(void)
+{
+ u8 rev;
+ const char *linux_dtb_file;
+
+ rev = get_pcb_revision_from_eeprom();
+ switch (rev) {
+ case 'a':
+ case 'A':
+ linux_dtb_file =
"starfive/jh7110-starfive-visionfive-2-v1.2a.dtb";
+ break;
+
+ case 'b':
+ case 'B':
+ default:
+ linux_dtb_file =
"starfive/jh7110-starfive-visionfive-2-v1.3b.dtb";
+ break;
+ };
+
+ env_set("fdtfile", linux_dtb_file);
+ return 0;
+}
+
void *board_fdt_blob_setup(int *err)
{
*err = 0;
--
2.42.0
[PATCH RFC 0/2] board: visionfive2: Select fdtfile based on revision
From: Jami Kettunen Currently booting a mainline Linux kernel via extlinux with fdtdir set doesn't load a proper DTB but passes on the U-Boot one to the kernel which as far as I know is very incorrect and prevents user (normally distro) provided DTB usage in a sensible/generic way. A uEnv.txt or similar manual environment changes were not used and should not be required to boot the board as per: https://u-boot.readthedocs.io/en/latest/develop/distro.html This also currently needs a kernel patch[1] for my board to have the full 8GB of memory available to Linux instead of just 4GB it shows with these patches alone. [1] https://gitlab.alpinelinux.org/nmeum/alpine-visionfive/-/blob/main/starfive/linux-starfive/set-8GB-RAM.patch Jami Kettunen (2): board: visionfive2: Select fdtfile based on revision configs: visionfive2: Enable MISC_INIT_R .../visionfive2/starfive_visionfive2.c| 25 +++ configs/starfive_visionfive2_defconfig| 1 + 2 files changed, 26 insertions(+) -- 2.42.0
[PATCH v2 6/7] rng: stm32: Implement custom RNG configuration support
STM32 RNG configuration should best fit the requirements of the
platform. Therefore, put a platform-specific RNG configuration
field in the platform data. Default RNG configuration for STM32MP13
is the NIST certified configuration [1].
While there, fix and the RNG init sequence to support all RNG
versions.
[1]
https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/53
Signed-off-by: Gatien Chevallier
Reviewed-by: Patrick Delaunay
---
Changes in V2:
- Added Patrick's tag
drivers/rng/stm32_rng.c | 54 ++---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index b1a790b217..c397b4d95c 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -21,8 +21,15 @@
#define RNG_CR 0x00
#define RNG_CR_RNGEN BIT(2)
#define RNG_CR_CED BIT(5)
+#define RNG_CR_CONFIG1 GENMASK(11, 8)
+#define RNG_CR_NISTC BIT(12)
+#define RNG_CR_CONFIG2 GENMASK(15, 13)
#define RNG_CR_CLKDIV_SHIFT16
+#define RNG_CR_CLKDIV GENMASK(19, 16)
+#define RNG_CR_CONFIG3 GENMASK(25, 20)
#define RNG_CR_CONDRST BIT(30)
+#define RNG_CR_ENTROPY_SRC_MASK(RNG_CR_CONFIG1 | RNG_CR_NISTC |
RNG_CR_CONFIG2 | RNG_CR_CONFIG3)
+#define RNG_CR_CONFIG_MASK (RNG_CR_ENTROPY_SRC_MASK | RNG_CR_CED |
RNG_CR_CLKDIV)
#define RNG_SR 0x04
#define RNG_SR_SEISBIT(6)
@@ -32,17 +39,28 @@
#define RNG_DR 0x08
+#define RNG_NSCR 0x0C
+#define RNG_NSCR_MASK GENMASK(17, 0)
+
+#define RNG_HTCR 0x10
+
#define RNG_NB_RECOVER_TRIES 3
/*
* struct stm32_rng_data - RNG compat data
*
* @max_clock_rate:Max RNG clock frequency, in Hertz
+ * @cr:Entropy source configuration
+ * @nscr: Noice sources control configuration
+ * @htcr: Health tests configuration
* @has_cond_reset:True if conditionnal reset is supported
*
*/
struct stm32_rng_data {
uint max_clock_rate;
+ u32 cr;
+ u32 nscr;
+ u32 htcr;
bool has_cond_reset;
};
@@ -244,28 +262,48 @@ static int stm32_rng_init(struct stm32_rng_plat *pdata)
cr = readl(pdata->base + RNG_CR);
- if (pdata->data->has_cond_reset) {
+ /*
+* Keep default RNG configuration if none was specified, that is when
conf.cr is set to 0.
+*/
+ if (pdata->data->has_cond_reset && pdata->data->cr) {
uint clock_div = stm32_rng_clock_freq_restrain(pdata);
- cr |= RNG_CR_CONDRST | (clock_div << RNG_CR_CLKDIV_SHIFT);
+ cr &= ~RNG_CR_CONFIG_MASK;
+ cr |= RNG_CR_CONDRST | (pdata->data->cr &
RNG_CR_ENTROPY_SRC_MASK) |
+ (clock_div << RNG_CR_CLKDIV_SHIFT);
if (pdata->ced)
cr &= ~RNG_CR_CED;
else
cr |= RNG_CR_CED;
writel(cr, pdata->base + RNG_CR);
+
+ /* Health tests and noise control registers */
+ writel_relaxed(pdata->data->htcr, pdata->base + RNG_HTCR);
+ writel_relaxed(pdata->data->nscr & RNG_NSCR_MASK, pdata->base +
RNG_NSCR);
+
cr &= ~RNG_CR_CONDRST;
cr |= RNG_CR_RNGEN;
writel(cr, pdata->base + RNG_CR);
err = readl_poll_timeout(pdata->base + RNG_CR, cr,
(!(cr & RNG_CR_CONDRST)), 1);
- if (err)
+ if (err) {
+ log_err("%s: Timeout!", __func__);
return err;
+ }
} else {
+ if (pdata->data->has_cond_reset)
+ cr |= RNG_CR_CONDRST;
+
if (pdata->ced)
cr &= ~RNG_CR_CED;
else
cr |= RNG_CR_CED;
+ writel(cr, pdata->base + RNG_CR);
+
+ if (pdata->data->has_cond_reset)
+ cr &= ~RNG_CR_CONDRST;
+
cr |= RNG_CR_RNGEN;
writel(cr, pdata->base + RNG_CR);
@@ -276,6 +314,9 @@ static int stm32_rng_init(struct stm32_rng_plat *pdata)
err = readl_poll_timeout(pdata->base + RNG_SR, sr,
sr & RNG_SR_DRDY, 1);
+ if (err)
+ log_err("%s: Timeout!", __func__);
+
return err;
}
@@ -335,11 +376,18 @@ static const struct dm_rng_ops stm32_rng_ops = {
static const struct stm32_rng_data stm32mp13_rng_data = {
.has_cond_reset = true,
.max_clock_rate = 4800,
+ .htcr = 0x969D,
+ .nscr = 0x2B5BB,
+ .cr = 0xF00D00,
};
static const struct stm32_rng_data stm32_rng_data = {
.has_cond_reset = false,
.max_clock_rate = 300,
+ /* Not supported */
+ .htcr = 0,
+
[PATCH v2 7/7] ARM: dts: stm32: add RNG node for STM32MP13x platforms
Add RNG node for STM32MP13x platforms.
Signed-off-by: Gatien Chevallier
Reviewed-by: Patrick Delaunay
---
Changes in V2:
- Added Patrick's tag
arch/arm/dts/stm32mp131.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index d23bbc3639..bd7285053d 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -1208,6 +1208,14 @@
};
};
+ rng: rng@54004000 {
+ compatible = "st,stm32mp13-rng";
+ reg = <0x54004000 0x400>;
+ clocks = < RNG1_K>;
+ resets = < RNG1_R>;
+ status = "disabled";
+ };
+
mdma: dma-controller@5800 {
compatible = "st,stm32h7-mdma";
reg = <0x5800 0x1000>;
--
2.25.1
[PATCH v2 5/7] rng: stm32: add error concealment sequence
Seed errors can occur when using the hardware RNG. Implement the
sequences to handle them. This avoids irrecoverable RNG state.
Try to conceal seed errors when possible. If, despite the error
concealing tries, a seed error is still present, then return an error.
A clock error does not compromise the hardware block and data can
still be read from RNG_DR. Just warn that the RNG clock is too slow
and clear RNG_SR.
Signed-off-by: Gatien Chevallier
Reviewed-by: Patrick Delaunay
---
Changes in V2:
- Added Patrick's tag
drivers/rng/stm32_rng.c | 163 ++--
1 file changed, 140 insertions(+), 23 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index f943acd7d2..b1a790b217 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -32,6 +32,8 @@
#define RNG_DR 0x08
+#define RNG_NB_RECOVER_TRIES 3
+
/*
* struct stm32_rng_data - RNG compat data
*
@@ -52,45 +54,160 @@ struct stm32_rng_plat {
bool ced;
};
+/*
+ * Extracts from the STM32 RNG specification when RNG supports CONDRST.
+ *
+ * When a noise source (or seed) error occurs, the RNG stops generating
+ * random numbers and sets to “1” both SEIS and SECS bits to indicate
+ * that a seed error occurred. (...)
+ *
+ * 1. Software reset by writing CONDRST at 1 and at 0 (see bitfield
+ * description for details). This step is needed only if SECS is set.
+ * Indeed, when SEIS is set and SECS is cleared it means RNG performed
+ * the reset automatically (auto-reset).
+ * 2. If SECS was set in step 1 (no auto-reset) wait for CONDRST
+ * to be cleared in the RNG_CR register, then confirm that SEIS is
+ * cleared in the RNG_SR register. Otherwise just clear SEIS bit in
+ * the RNG_SR register.
+ * 3. If SECS was set in step 1 (no auto-reset) wait for SECS to be
+ * cleared by RNG. The random number generation is now back to normal.
+ */
+static int stm32_rng_conceal_seed_error_cond_reset(struct stm32_rng_plat
*pdata)
+{
+ u32 sr = readl_relaxed(pdata->base + RNG_SR);
+ u32 cr = readl_relaxed(pdata->base + RNG_CR);
+ int err;
+
+ if (sr & RNG_SR_SECS) {
+ /* Conceal by resetting the subsystem (step 1.) */
+ writel_relaxed(cr | RNG_CR_CONDRST, pdata->base + RNG_CR);
+ writel_relaxed(cr & ~RNG_CR_CONDRST, pdata->base + RNG_CR);
+ } else {
+ /* RNG auto-reset (step 2.) */
+ writel_relaxed(sr & ~RNG_SR_SEIS, pdata->base + RNG_SR);
+ return 0;
+ }
+
+ err = readl_relaxed_poll_timeout(pdata->base + RNG_SR, sr, !(sr &
RNG_CR_CONDRST), 10);
+ if (err) {
+ log_err("%s: timeout %x\n", __func__, sr);
+ return err;
+ }
+
+ /* Check SEIS is cleared (step 2.) */
+ if (readl_relaxed(pdata->base + RNG_SR) & RNG_SR_SEIS)
+ return -EINVAL;
+
+ err = readl_relaxed_poll_timeout(pdata->base + RNG_SR, sr, !(sr &
RNG_SR_SECS), 10);
+ if (err) {
+ log_err("%s: timeout %x\n", __func__, sr);
+ return err;
+ }
+
+ return 0;
+}
+
+/*
+ * Extracts from the STM32 RNG specification, when CONDRST is not supported
+ *
+ * When a noise source (or seed) error occurs, the RNG stops generating
+ * random numbers and sets to “1” both SEIS and SECS bits to indicate
+ * that a seed error occurred. (...)
+ *
+ * The following sequence shall be used to fully recover from a seed
+ * error after the RNG initialization:
+ * 1. Clear the SEIS bit by writing it to “0”.
+ * 2. Read out 12 words from the RNG_DR register, and discard each of
+ * them in order to clean the pipeline.
+ * 3. Confirm that SEIS is still cleared. Random number generation is
+ * back to normal.
+ */
+static int stm32_rng_conceal_seed_error_sw_reset(struct stm32_rng_plat *pdata)
+{
+ uint i = 0;
+ u32 sr = readl_relaxed(pdata->base + RNG_SR);
+
+ writel_relaxed(sr & ~RNG_SR_SEIS, pdata->base + RNG_SR);
+
+ for (i = 12; i != 0; i--)
+ (void)readl_relaxed(pdata->base + RNG_DR);
+
+ if (readl_relaxed(pdata->base + RNG_SR) & RNG_SR_SEIS)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int stm32_rng_conceal_seed_error(struct stm32_rng_plat *pdata)
+{
+ log_debug("Concealing RNG seed error\n");
+
+ if (pdata->data->has_cond_reset)
+ return stm32_rng_conceal_seed_error_cond_reset(pdata);
+ else
+ return stm32_rng_conceal_seed_error_sw_reset(pdata);
+};
+
static int stm32_rng_read(struct udevice *dev, void *data, size_t len)
{
- int retval, i;
- u32 sr, count, reg;
+ int retval;
+ u32 sr, reg;
size_t increment;
struct stm32_rng_plat *pdata = dev_get_plat(dev);
+ uint tries = 0;
while (len > 0) {
retval = readl_poll_timeout(pdata->base + RNG_SR, sr,
- sr & RNG_SR_DRDY,
[PATCH v2 4/7] rng: stm32: add RNG clock frequency restraint
In order to ensure a good RNG quality and compatibility with
certified RNG configuration, add RNG clock frequency restraint.
Signed-off-by: Gatien Chevallier
Reviewed-by: Patrick Delaunay
---
Changes in V2:
- Added Patrick's tag
drivers/rng/stm32_rng.c | 43 -
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index ada5d92214..f943acd7d2 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -18,10 +18,11 @@
#include
#include
-#define RNG_CR 0x00
-#define RNG_CR_RNGEN BIT(2)
-#define RNG_CR_CED BIT(5)
-#define RNG_CR_CONDRST BIT(30)
+#define RNG_CR 0x00
+#define RNG_CR_RNGEN BIT(2)
+#define RNG_CR_CED BIT(5)
+#define RNG_CR_CLKDIV_SHIFT16
+#define RNG_CR_CONDRST BIT(30)
#define RNG_SR 0x04
#define RNG_SR_SEISBIT(6)
@@ -31,7 +32,15 @@
#define RNG_DR 0x08
+/*
+ * struct stm32_rng_data - RNG compat data
+ *
+ * @max_clock_rate:Max RNG clock frequency, in Hertz
+ * @has_cond_reset:True if conditionnal reset is supported
+ *
+ */
struct stm32_rng_data {
+ uint max_clock_rate;
bool has_cond_reset;
};
@@ -87,6 +96,26 @@ static int stm32_rng_read(struct udevice *dev, void *data,
size_t len)
return 0;
}
+static uint stm32_rng_clock_freq_restrain(struct stm32_rng_plat *pdata)
+{
+ ulong clock_rate = 0;
+ uint clock_div = 0;
+
+ clock_rate = clk_get_rate(>clk);
+
+ /*
+* Get the exponent to apply on the CLKDIV field in RNG_CR register.
+* No need to handle the case when clock-div > 0xF as it is physically
+* impossible.
+*/
+ while ((clock_rate >> clock_div) > pdata->data->max_clock_rate)
+ clock_div++;
+
+ log_debug("RNG clk rate : %lu\n", clk_get_rate(>clk) >>
clock_div);
+
+ return clock_div;
+}
+
static int stm32_rng_init(struct stm32_rng_plat *pdata)
{
int err;
@@ -99,7 +128,9 @@ static int stm32_rng_init(struct stm32_rng_plat *pdata)
cr = readl(pdata->base + RNG_CR);
if (pdata->data->has_cond_reset) {
- cr |= RNG_CR_CONDRST;
+ uint clock_div = stm32_rng_clock_freq_restrain(pdata);
+
+ cr |= RNG_CR_CONDRST | (clock_div << RNG_CR_CLKDIV_SHIFT);
if (pdata->ced)
cr &= ~RNG_CR_CED;
else
@@ -186,10 +217,12 @@ static const struct dm_rng_ops stm32_rng_ops = {
static const struct stm32_rng_data stm32mp13_rng_data = {
.has_cond_reset = true,
+ .max_clock_rate = 4800,
};
static const struct stm32_rng_data stm32_rng_data = {
.has_cond_reset = false,
+ .max_clock_rate = 300,
};
static const struct udevice_id stm32_rng_match[] = {
--
2.25.1
[PATCH v2 3/7] rng: stm32: Implement configurable RNG clock error detection
RNG clock error detection is now enabled if the "clock-error-detect"
property is set in the device tree.
Signed-off-by: Gatien Chevallier
Reviewed-by: Patrick Delaunay
---
Changes in V2:
- Added Patrick's tag
drivers/rng/stm32_rng.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index 89da78c6c8..ada5d92214 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -40,6 +40,7 @@ struct stm32_rng_plat {
struct clk clk;
struct reset_ctl rst;
const struct stm32_rng_data *data;
+ bool ced;
};
static int stm32_rng_read(struct udevice *dev, void *data, size_t len)
@@ -97,25 +98,34 @@ static int stm32_rng_init(struct stm32_rng_plat *pdata)
cr = readl(pdata->base + RNG_CR);
- /* Disable CED */
- cr |= RNG_CR_CED;
if (pdata->data->has_cond_reset) {
cr |= RNG_CR_CONDRST;
+ if (pdata->ced)
+ cr &= ~RNG_CR_CED;
+ else
+ cr |= RNG_CR_CED;
writel(cr, pdata->base + RNG_CR);
cr &= ~RNG_CR_CONDRST;
+ cr |= RNG_CR_RNGEN;
writel(cr, pdata->base + RNG_CR);
err = readl_poll_timeout(pdata->base + RNG_CR, cr,
(!(cr & RNG_CR_CONDRST)), 1);
if (err)
return err;
+ } else {
+ if (pdata->ced)
+ cr &= ~RNG_CR_CED;
+ else
+ cr |= RNG_CR_CED;
+
+ cr |= RNG_CR_RNGEN;
+
+ writel(cr, pdata->base + RNG_CR);
}
/* clear error indicators */
writel(0, pdata->base + RNG_SR);
- cr |= RNG_CR_RNGEN;
- writel(cr, pdata->base + RNG_CR);
-
err = readl_poll_timeout(pdata->base + RNG_SR, sr,
sr & RNG_SR_DRDY, 1);
return err;
@@ -165,6 +175,8 @@ static int stm32_rng_of_to_plat(struct udevice *dev)
if (err)
return err;
+ pdata->ced = dev_read_bool(dev, "clock-error-detect");
+
return 0;
}
--
2.25.1
[PATCH v2 1/7] rng: stm32: rename STM32 RNG driver
Rename the RNG driver as it is usable by other STM32 platforms
than the STM32MP1x ones. Rename CONFIG_RNG_STM32MP1 to
CONFIG_RNG_STM32
Signed-off-by: Gatien Chevallier
Reviewed-by: Grzegorz Szymaszek
---
Changes in V2:
- Added ARCH_STM32 in the "depends on" section of the
RNG_STM32 configuration field.
- Added Grzegorz's tag and discarded Patrick's and
Heinrich's as there's a modification
MAINTAINERS | 2 +-
configs/stm32mp15_basic_defconfig | 2 +-
configs/stm32mp15_defconfig | 2 +-
configs/stm32mp15_trusted_defconfig | 2 +-
drivers/rng/Kconfig | 8
drivers/rng/Makefile| 2 +-
drivers/rng/{stm32mp1_rng.c => stm32_rng.c} | 0
7 files changed, 9 insertions(+), 9 deletions(-)
rename drivers/rng/{stm32mp1_rng.c => stm32_rng.c} (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0a10a436bc..a3bffa63d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -621,7 +621,7 @@ F: drivers/ram/stm32mp1/
F: drivers/remoteproc/stm32_copro.c
F: drivers/reset/stm32-reset.c
F: drivers/rng/optee_rng.c
-F: drivers/rng/stm32mp1_rng.c
+F: drivers/rng/stm32_rng.c
F: drivers/rtc/stm32_rtc.c
F: drivers/serial/serial_stm32.*
F: drivers/spi/stm32_qspi.c
diff --git a/configs/stm32mp15_basic_defconfig
b/configs/stm32mp15_basic_defconfig
index 9ea5aaa714..29b869cf34 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -150,7 +150,7 @@ CONFIG_DM_REGULATOR_STM32_VREFBUF=y
CONFIG_DM_REGULATOR_STPMIC1=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_DM_RNG=y
-CONFIG_RNG_STM32MP1=y
+CONFIG_RNG_STM32=y
CONFIG_DM_RTC=y
CONFIG_RTC_STM32=y
CONFIG_SERIAL_RX_BUFFER=y
diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index 4d0a81f8a8..b061a83f9d 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -123,7 +123,7 @@ CONFIG_DM_REGULATOR_SCMI=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_RESET_SCMI=y
CONFIG_DM_RNG=y
-CONFIG_RNG_STM32MP1=y
+CONFIG_RNG_STM32=y
CONFIG_DM_RTC=y
CONFIG_RTC_STM32=y
CONFIG_SERIAL_RX_BUFFER=y
diff --git a/configs/stm32mp15_trusted_defconfig
b/configs/stm32mp15_trusted_defconfig
index 0a7d862485..b51eefe652 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -123,7 +123,7 @@ CONFIG_DM_REGULATOR_STPMIC1=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_RESET_SCMI=y
CONFIG_DM_RNG=y
-CONFIG_RNG_STM32MP1=y
+CONFIG_RNG_STM32=y
CONFIG_DM_RTC=y
CONFIG_RTC_STM32=y
CONFIG_SERIAL_RX_BUFFER=y
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index 5deb5db5b7..24666bff98 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -48,11 +48,11 @@ config RNG_OPTEE
accessible to normal world but reserved and used by the OP-TEE
to avoid the weakness of a software PRNG.
-config RNG_STM32MP1
- bool "Enable random number generator for STM32MP1"
- depends on ARCH_STM32MP
+config RNG_STM32
+ bool "Enable random number generator for STM32"
+ depends on ARCH_STM32 || ARCH_STM32MP
help
- Enable STM32MP1 rng driver.
+ Enable STM32 rng driver.
config RNG_ROCKCHIP
bool "Enable random number generator for rockchip crypto rng"
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 78f61051ac..192f911e15 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
obj-$(CONFIG_RNG_MSM) += msm_rng.o
obj-$(CONFIG_RNG_NPCM) += npcm_rng.o
obj-$(CONFIG_RNG_OPTEE) += optee_rng.o
-obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
+obj-$(CONFIG_RNG_STM32) += stm32_rng.o
obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
obj-$(CONFIG_RNG_IPROC200) += iproc_rng200.o
obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
diff --git a/drivers/rng/stm32mp1_rng.c b/drivers/rng/stm32_rng.c
similarity index 100%
rename from drivers/rng/stm32mp1_rng.c
rename to drivers/rng/stm32_rng.c
--
2.25.1
[PATCH v2 2/7] configs: default activate CONFIG_RNG_STM32 for STM32MP13x platforms
Default embed this configuration. If OP-TEE PTA RNG is exposed, it means that the RNG is managed by the secure world. Therefore, the RNG node should be disabled in the device tree as an access would be denied by the hardware firewall. Signed-off-by: Gatien Chevallier Reviewed-by: Patrick Delaunay --- Changes in V2: - Added Patrick's tag configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index 82b62744f6..4a899c85de 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -65,6 +65,7 @@ CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_SCMI=y CONFIG_RESET_SCMI=y CONFIG_DM_RNG=y +CONFIG_RNG_STM32=y CONFIG_DM_RTC=y CONFIG_RTC_STM32=y CONFIG_SERIAL_RX_BUFFER=y -- 2.25.1
[PATCH v2 0/7] rng: stm32: support STM32MP13x platforms
This is the cover letter for patchset [1]. First, do not restrain the STM32 RNG driver to the MPU series. The STM32MP13x platforms have a RNG hardware block that supports customization, a conditional reset sequences that allows to recover from certain situations and a configuration locking mechanism. This series adds support for the mentionned features. Note that the hardware RNG can and should be managed in the secure world for this platform, hence the rng not being default enabled on the STM32MP135F-DK board. [1] http://patchwork.ozlabs.org/project/uboot/list/?series=372119=* Changes in V2: - Added this cover letter - Added ARCH_STM32 as a dependency for RNG_STM32 - Added review tags Gatien Chevallier (7): rng: stm32: rename STM32 RNG driver configs: default activate CONFIG_RNG_STM32 for STM32MP13x platforms rng: stm32: Implement configurable RNG clock error detection rng: stm32: add RNG clock frequency restraint rng: stm32: add error concealment sequence rng: stm32: Implement custom RNG configuration support ARM: dts: stm32: add RNG node for STM32MP13x platforms MAINTAINERS | 2 +- arch/arm/dts/stm32mp131.dtsi| 8 + configs/stm32mp13_defconfig | 1 + configs/stm32mp15_basic_defconfig | 2 +- configs/stm32mp15_defconfig | 2 +- configs/stm32mp15_trusted_defconfig | 2 +- drivers/rng/Kconfig | 8 +- drivers/rng/Makefile| 2 +- drivers/rng/stm32_rng.c | 408 drivers/rng/stm32mp1_rng.c | 198 -- 10 files changed, 426 insertions(+), 207 deletions(-) create mode 100644 drivers/rng/stm32_rng.c delete mode 100644 drivers/rng/stm32mp1_rng.c -- 2.25.1
[PATCH v1] rockchip: include: asm: fix entering download mode rk3066
When a Rockchip rk3066 board download key is pressed it hangs.
The rk3066 BROM doesn't have support to check the return to BROM,
so when a key is pressed the loop that reads data must be broken
by writing a "-1" to the variable that points to the next page address.
It then goes in download mode and waits for data on USB OTG and UART0.
Signed-off-by: Johan Jonker
---
arch/arm/include/asm/arch-rockchip/boot0.h | 32 +++---
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h
b/arch/arm/include/asm/arch-rockchip/boot0.h
index 0c375e543a5e..305461ce3751 100644
--- a/arch/arm/include/asm/arch-rockchip/boot0.h
+++ b/arch/arm/include/asm/arch-rockchip/boot0.h
@@ -3,6 +3,8 @@
* Copyright 2017 Theobroma Systems Design und Consulting GmbH
*/
+#include
+
/*
* Execution starts on the instruction following this 4-byte header
* (containing the magic 'RK30', 'RK31', 'RK32' or 'RK33'). This
@@ -23,17 +25,39 @@
* the first one may be overwritten, if this is the first stage
* contained in the final image created with mkimage)...
*/
- b 1f /* if overwritten, entry-address is at the next word */
+ b 1f /* if overwritten, entry-address is at the next word */
1:
#endif
#if CONFIG_IS_ENABLED(ROCKCHIP_EARLYRETURN_TO_BROM)
- adr r3, entry_counter
+#if IS_ENABLED(CONFIG_ROCKCHIP_RK3066)
+/*
+ * Unlike newer Rockchip SoC models the rk3066 BROM code does not have
+ * built-in support to enter download mode after return to BROM code.
+ * Before a return the boot mode register must be checked for the
+ * BOOT_BROM_DOWNLOAD flag. Writing '-1' to a location in SRAM
+ * where the BROM stores the next page address breaks the loop
+ * that reads boot blocks. The boot ROM code then goes into a
+ * download mode and waits for data on USB OTG and UART0.
+ */
+ ldr r1, =BOOT_BROM_DOWNLOAD
+ ldr r0, =CONFIG_ROCKCHIP_BOOT_MODE_REG
+ ldr r0, [r0]
+ cmp r0, r1 /* if (readl(CONFIG_ROCKCHIP_BOOT_MODE_REG) ==
*/
+ bne counter_check/* BOOT_BROM_DOWNLOAD) { */
+ ldr r1, =0x
+ ldr r0, =0x10080028
+ str r1, [r0] /* writel(0x, 0x10080028);*/
+ mov r0, #1 /* return 1; */
+ bx lr /* } */
+counter_check:
+#endif
+ adr r3, entry_counter
ldr r0, [r3]
cmp r0, #1 /* check if entry_counter == 1 */
beq reset/* regular bootup */
- add r0, #1
+ add r0, #1
str r0, [r3] /* increment the entry_counter in memory */
- mov r0, #0 /* return 0 to the BROM to signal 'OK' */
+ mov r0, #0 /* return 0 to the BROM to signal 'OK' */
bx lr /* return control to the BROM */
entry_counter:
.word 0
--
2.39.2
Re: [PATCH] config: j7200: removed not needed power config
On 20:29-20230911, Kumar, Udit wrote: > Thank you for suggestion Nishanth > > On 9/11/2023 6:51 PM, Nishanth Menon wrote: > > On 16:49-20230911, Udit Kumar wrote: > > > [..] > > And maybe expand this patch so that it contains something like the > > following to prevent this from coming back again elsewhere? > > > > diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig > > index fbcdefd889ae..aff1ba5ab43b 100644 > > --- a/drivers/clk/ti/Kconfig > > +++ b/drivers/clk/ti/Kconfig > > @@ -36,7 +36,7 @@ config CLK_TI_MUX > > config CLK_TI_SCI > > bool "TI System Control Interface (TI SCI) clock driver" > > - depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL > > + depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL && !CLK_K3 > > help > > This enables the clock driver support over TI System Control Interface > > available on some new TI's SoCs. If you wish to use clock resources > > @@ -44,24 +44,24 @@ config CLK_TI_SCI > > [..] > > config CLK_K3 > > bool "Clock support for K3 SoC family of devices" > > - depends on CLK > > + depends on CLK && !CLK_TI_SCI > > help > > Enables the clock translation layer from DT to device clocks. > > I think these may end up recursive dependency Please do the needful, but it is best if the Kconfig enforces this prior to defconfig updates. > > > > diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig > > index 411c210756a3..9625764b304b 100644 > > --- a/drivers/power/domain/Kconfig > > +++ b/drivers/power/domain/Kconfig > > @@ -92,14 +92,14 @@ config TEGRA186_POWER_DOMAIN > > config TI_SCI_POWER_DOMAIN > > bool "Enable the TI SCI-based power domain driver" > > - depends on POWER_DOMAIN && TI_SCI_PROTOCOL > > + depends on POWER_DOMAIN && TI_SCI_PROTOCOL && !TI_POWER_DOMAIN > > help > > Generic power domain implementation for TI devices implementing the > > TI SCI protocol. > > config TI_POWER_DOMAIN > > bool "Enable the TI K3 Power domain driver" > > - depends on POWER_DOMAIN && ARCH_K3 > > + depends on POWER_DOMAIN && ARCH_K3 && !TI_SCI_POWER_DOMAIN > > help > > Generic power domain implementation for TI K3 devices. > > and these too. > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] config: j7200: removed not needed power config
Thank you for suggestion Nishanth On 9/11/2023 6:51 PM, Nishanth Menon wrote: On 16:49-20230911, Udit Kumar wrote: [..] And maybe expand this patch so that it contains something like the following to prevent this from coming back again elsewhere? diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig index fbcdefd889ae..aff1ba5ab43b 100644 --- a/drivers/clk/ti/Kconfig +++ b/drivers/clk/ti/Kconfig @@ -36,7 +36,7 @@ config CLK_TI_MUX config CLK_TI_SCI bool "TI System Control Interface (TI SCI) clock driver" - depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL + depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL && !CLK_K3 help This enables the clock driver support over TI System Control Interface available on some new TI's SoCs. If you wish to use clock resources @@ -44,24 +44,24 @@ config CLK_TI_SCI [..] config CLK_K3 bool "Clock support for K3 SoC family of devices" - depends on CLK + depends on CLK && !CLK_TI_SCI help Enables the clock translation layer from DT to device clocks. I think these may end up recursive dependency diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig index 411c210756a3..9625764b304b 100644 --- a/drivers/power/domain/Kconfig +++ b/drivers/power/domain/Kconfig @@ -92,14 +92,14 @@ config TEGRA186_POWER_DOMAIN config TI_SCI_POWER_DOMAIN bool "Enable the TI SCI-based power domain driver" - depends on POWER_DOMAIN && TI_SCI_PROTOCOL + depends on POWER_DOMAIN && TI_SCI_PROTOCOL && !TI_POWER_DOMAIN help Generic power domain implementation for TI devices implementing the TI SCI protocol. config TI_POWER_DOMAIN bool "Enable the TI K3 Power domain driver" - depends on POWER_DOMAIN && ARCH_K3 + depends on POWER_DOMAIN && ARCH_K3 && !TI_SCI_POWER_DOMAIN help Generic power domain implementation for TI K3 devices. and these too.
[PATCH 1/4] arm: dts: Introduce k3-serdes.h from v6.6-rc1
Introduce the new serdes header from kernel v6.6-rc1 The DTS uses constants for SERDES MUX idle state values which were earlier provided as bindings header. But they are unsuitable for bindings. So move these constants in a header next to DTS. Signed-off-by: Nishanth Menon --- arch/arm/dts/k3-serdes.h | 204 +++ 1 file changed, 204 insertions(+) create mode 100644 arch/arm/dts/k3-serdes.h diff --git a/arch/arm/dts/k3-serdes.h b/arch/arm/dts/k3-serdes.h new file mode 100644 index ..29167f85c1f6 --- /dev/null +++ b/arch/arm/dts/k3-serdes.h @@ -0,0 +1,204 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * This header provides constants for SERDES MUX for TI SoCs + * + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/ + */ + +#ifndef DTS_ARM64_TI_K3_SERDES_H +#define DTS_ARM64_TI_K3_SERDES_H + +/* J721E */ + +#define J721E_SERDES0_LANE0_QSGMII_LANE1 0x0 +#define J721E_SERDES0_LANE0_PCIE0_LANE00x1 +#define J721E_SERDES0_LANE0_USB3_0_SWAP0x2 +#define J721E_SERDES0_LANE0_IP4_UNUSED 0x3 + +#define J721E_SERDES0_LANE1_QSGMII_LANE2 0x0 +#define J721E_SERDES0_LANE1_PCIE0_LANE10x1 +#define J721E_SERDES0_LANE1_USB3_0 0x2 +#define J721E_SERDES0_LANE1_IP4_UNUSED 0x3 + +#define J721E_SERDES1_LANE0_QSGMII_LANE3 0x0 +#define J721E_SERDES1_LANE0_PCIE1_LANE00x1 +#define J721E_SERDES1_LANE0_USB3_1_SWAP0x2 +#define J721E_SERDES1_LANE0_SGMII_LANE00x3 + +#define J721E_SERDES1_LANE1_QSGMII_LANE4 0x0 +#define J721E_SERDES1_LANE1_PCIE1_LANE10x1 +#define J721E_SERDES1_LANE1_USB3_1 0x2 +#define J721E_SERDES1_LANE1_SGMII_LANE10x3 + +#define J721E_SERDES2_LANE0_IP1_UNUSED 0x0 +#define J721E_SERDES2_LANE0_PCIE2_LANE00x1 +#define J721E_SERDES2_LANE0_USB3_1_SWAP0x2 +#define J721E_SERDES2_LANE0_SGMII_LANE00x3 + +#define J721E_SERDES2_LANE1_IP1_UNUSED 0x0 +#define J721E_SERDES2_LANE1_PCIE2_LANE10x1 +#define J721E_SERDES2_LANE1_USB3_1 0x2 +#define J721E_SERDES2_LANE1_SGMII_LANE10x3 + +#define J721E_SERDES3_LANE0_IP1_UNUSED 0x0 +#define J721E_SERDES3_LANE0_PCIE3_LANE00x1 +#define J721E_SERDES3_LANE0_USB3_0_SWAP0x2 +#define J721E_SERDES3_LANE0_IP4_UNUSED 0x3 + +#define J721E_SERDES3_LANE1_IP1_UNUSED 0x0 +#define J721E_SERDES3_LANE1_PCIE3_LANE10x1 +#define J721E_SERDES3_LANE1_USB3_0 0x2 +#define J721E_SERDES3_LANE1_IP4_UNUSED 0x3 + +#define J721E_SERDES4_LANE0_EDP_LANE0 0x0 +#define J721E_SERDES4_LANE0_IP2_UNUSED 0x1 +#define J721E_SERDES4_LANE0_QSGMII_LANE5 0x2 +#define J721E_SERDES4_LANE0_IP4_UNUSED 0x3 + +#define J721E_SERDES4_LANE1_EDP_LANE1 0x0 +#define J721E_SERDES4_LANE1_IP2_UNUSED 0x1 +#define J721E_SERDES4_LANE1_QSGMII_LANE6 0x2 +#define J721E_SERDES4_LANE1_IP4_UNUSED 0x3 + +#define J721E_SERDES4_LANE2_EDP_LANE2 0x0 +#define J721E_SERDES4_LANE2_IP2_UNUSED 0x1 +#define J721E_SERDES4_LANE2_QSGMII_LANE7 0x2 +#define J721E_SERDES4_LANE2_IP4_UNUSED 0x3 + +#define J721E_SERDES4_LANE3_EDP_LANE3 0x0 +#define J721E_SERDES4_LANE3_IP2_UNUSED 0x1 +#define J721E_SERDES4_LANE3_QSGMII_LANE8 0x2 +#define J721E_SERDES4_LANE3_IP4_UNUSED 0x3 + +/* J7200 */ + +#define J7200_SERDES0_LANE0_QSGMII_LANE3 0x0 +#define J7200_SERDES0_LANE0_PCIE1_LANE00x1 +#define J7200_SERDES0_LANE0_IP3_UNUSED 0x2 +#define J7200_SERDES0_LANE0_IP4_UNUSED 0x3 + +#define J7200_SERDES0_LANE1_QSGMII_LANE4 0x0 +#define J7200_SERDES0_LANE1_PCIE1_LANE10x1 +#define J7200_SERDES0_LANE1_IP3_UNUSED 0x2 +#define J7200_SERDES0_LANE1_IP4_UNUSED 0x3 + +#define J7200_SERDES0_LANE2_QSGMII_LANE1 0x0 +#define J7200_SERDES0_LANE2_PCIE1_LANE20x1 +#define J7200_SERDES0_LANE2_IP3_UNUSED 0x2 +#define J7200_SERDES0_LANE2_IP4_UNUSED 0x3 + +#define J7200_SERDES0_LANE3_QSGMII_LANE2 0x0 +#define J7200_SERDES0_LANE3_PCIE1_LANE30x1 +#define J7200_SERDES0_LANE3_USB0x2 +#define J7200_SERDES0_LANE3_IP4_UNUSED 0x3 + +/* AM64 */ + +#define AM64_SERDES0_LANE0_PCIE0 0x0 +#define AM64_SERDES0_LANE0_USB 0x1 + +/* J721S2 */ + +#define J721S2_SERDES0_LANE0_EDP_LANE0 0x0 +#define J721S2_SERDES0_LANE0_PCIE1_LANE0 0x1 +#define J721S2_SERDES0_LANE0_IP3_UNUSED0x2 +#define J721S2_SERDES0_LANE0_IP4_UNUSED0x3 + +#define J721S2_SERDES0_LANE1_EDP_LANE1 0x0 +#define J721S2_SERDES0_LANE1_PCIE1_LANE1 0x1 +#define J721S2_SERDES0_LANE1_USB 0x2 +#define J721S2_SERDES0_LANE1_IP4_UNUSED
[PATCH 3/4] dt-bindings: ti-serdes: Deprecate header with constants with v6.6-rc1
The constants to define the idle state of SERDES MUX were defined in
bindings header. They are used only in DTS and driver uses the dt property
to set the idle state making it unsuitable for bindings.
The constants are moved to header next to DTS ("arch/arm/boot/dts/")
and all the references to bindings header are removed.
So add a warning to mark this bindings header as deprecated.
We could probably drop this header, but let us wait for kernel to
cleanup.
Signed-off-by: Nishanth Menon
---
include/dt-bindings/mux/ti-serdes.h | 70 +
1 file changed, 70 insertions(+)
diff --git a/include/dt-bindings/mux/ti-serdes.h
b/include/dt-bindings/mux/ti-serdes.h
index d3116c52ab72..b0b1091aad6d 100644
--- a/include/dt-bindings/mux/ti-serdes.h
+++ b/include/dt-bindings/mux/ti-serdes.h
@@ -6,6 +6,14 @@
#ifndef _DT_BINDINGS_MUX_TI_SERDES
#define _DT_BINDINGS_MUX_TI_SERDES
+/*
+ * These bindings are deprecated, because they do not match the actual
+ * concept of bindings but rather contain pure constants values used only
+ * in DTS board files.
+ * Instead include the header in the DTS source directory.
+ */
+#warning "These bindings are deprecated. Instead, use the header in the DTS
source directory."
+
/* J721E */
#define J721E_SERDES0_LANE0_QSGMII_LANE1 0x0
@@ -117,4 +125,66 @@
#define J721S2_SERDES0_LANE3_USB 0x2
#define J721S2_SERDES0_LANE3_IP4_UNUSED0x3
+/* J784S4 */
+
+#define J784S4_SERDES0_LANE0_IP1_UNUSED0x0
+#define J784S4_SERDES0_LANE0_PCIE1_LANE0 0x1
+#define J784S4_SERDES0_LANE0_IP3_UNUSED0x2
+#define J784S4_SERDES0_LANE0_IP4_UNUSED0x3
+
+#define J784S4_SERDES0_LANE1_IP1_UNUSED0x0
+#define J784S4_SERDES0_LANE1_PCIE1_LANE1 0x1
+#define J784S4_SERDES0_LANE1_IP3_UNUSED0x2
+#define J784S4_SERDES0_LANE1_IP4_UNUSED0x3
+
+#define J784S4_SERDES0_LANE2_PCIE3_LANE0 0x0
+#define J784S4_SERDES0_LANE2_PCIE1_LANE2 0x1
+#define J784S4_SERDES0_LANE2_IP3_UNUSED0x2
+#define J784S4_SERDES0_LANE2_IP4_UNUSED0x3
+
+#define J784S4_SERDES0_LANE3_PCIE3_LANE1 0x0
+#define J784S4_SERDES0_LANE3_PCIE1_LANE3 0x1
+#define J784S4_SERDES0_LANE3_USB 0x2
+#define J784S4_SERDES0_LANE3_IP4_UNUSED0x3
+
+#define J784S4_SERDES1_LANE0_QSGMII_LANE3 0x0
+#define J784S4_SERDES1_LANE0_PCIE0_LANE0 0x1
+#define J784S4_SERDES1_LANE0_IP3_UNUSED0x2
+#define J784S4_SERDES1_LANE0_IP4_UNUSED0x3
+
+#define J784S4_SERDES1_LANE1_QSGMII_LANE4 0x0
+#define J784S4_SERDES1_LANE1_PCIE0_LANE1 0x1
+#define J784S4_SERDES1_LANE1_IP3_UNUSED0x2
+#define J784S4_SERDES1_LANE1_IP4_UNUSED0x3
+
+#define J784S4_SERDES1_LANE2_QSGMII_LANE1 0x0
+#define J784S4_SERDES1_LANE2_PCIE0_LANE2 0x1
+#define J784S4_SERDES1_LANE2_PCIE2_LANE0 0x2
+#define J784S4_SERDES1_LANE2_IP4_UNUSED0x3
+
+#define J784S4_SERDES1_LANE3_QSGMII_LANE2 0x0
+#define J784S4_SERDES1_LANE3_PCIE0_LANE3 0x1
+#define J784S4_SERDES1_LANE3_PCIE2_LANE1 0x2
+#define J784S4_SERDES1_LANE3_IP4_UNUSED0x3
+
+#define J784S4_SERDES2_LANE0_QSGMII_LANE5 0x0
+#define J784S4_SERDES2_LANE0_IP2_UNUSED0x1
+#define J784S4_SERDES2_LANE0_IP3_UNUSED0x2
+#define J784S4_SERDES2_LANE0_IP4_UNUSED0x3
+
+#define J784S4_SERDES2_LANE1_QSGMII_LANE6 0x0
+#define J784S4_SERDES2_LANE1_IP2_UNUSED0x1
+#define J784S4_SERDES2_LANE1_IP3_UNUSED0x2
+#define J784S4_SERDES2_LANE1_IP4_UNUSED0x3
+
+#define J784S4_SERDES2_LANE2_QSGMII_LANE7 0x0
+#define J784S4_SERDES2_LANE2_QSGMII_LANE1 0x1
+#define J784S4_SERDES2_LANE2_IP3_UNUSED0x2
+#define J784S4_SERDES2_LANE2_IP4_UNUSED0x3
+
+#define J784S4_SERDES2_LANE3_QSGMII_LANE8 0x0
+#define J784S4_SERDES2_LANE3_QSGMII_LANE2 0x1
+#define J784S4_SERDES2_LANE3_IP3_UNUSED0x2
+#define J784S4_SERDES2_LANE3_IP4_UNUSED0x3
+
#endif /* _DT_BINDINGS_MUX_TI_SERDES */
--
2.40.0
[PATCH 2/4] arm: dts: k3*: Use local header for SERDES MUX idle-state values
The DTS uses constants for SERDES MUX idle state values which were earlier
provided as bindings header. But they are unsuitable for bindings.
So move these constants in a header next to DTS.
NOTE: sync with v6.6-rc1 will bring in this change naturally.
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-evm.dts | 2 +-
arch/arm/dts/k3-am642-sk.dts| 2 +-
arch/arm/dts/k3-j7200-common-proc-board.dts | 2 +-
arch/arm/dts/k3-j721e-main.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 15c282c93467..fe2ea25b396f 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -6,11 +6,11 @@
/dts-v1/;
#include
-#include
#include
#include
#include
#include "k3-am642.dtsi"
+#include "k3-serdes.h"
/ {
compatible = "ti,am642-evm", "ti,am642";
diff --git a/arch/arm/dts/k3-am642-sk.dts b/arch/arm/dts/k3-am642-sk.dts
index cbce43dbe3f9..ece75680f3f4 100644
--- a/arch/arm/dts/k3-am642-sk.dts
+++ b/arch/arm/dts/k3-am642-sk.dts
@@ -5,12 +5,12 @@
/dts-v1/;
-#include
#include
#include
#include
#include
#include "k3-am642.dtsi"
+#include "k3-serdes.h"
/ {
compatible = "ti,am642-sk", "ti,am642";
diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts
b/arch/arm/dts/k3-j7200-common-proc-board.dts
index d14f3c18b65f..ef5e807a80b4 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-common-proc-board.dts
@@ -8,8 +8,8 @@
#include "k3-j7200-som-p0.dtsi"
#include
#include
-#include
#include
+#include "k3-serdes.h"
/ {
chosen {
diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
index cf3482376c1e..d2edf5df2eb9 100644
--- a/arch/arm/dts/k3-j721e-main.dtsi
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -6,7 +6,7 @@
*/
#include
#include
-#include
+#include "k3-serdes.h"
/ {
cmn_refclk: clock-cmnrefclk {
--
2.40.0
[PATCH 0/4] arm: dts: k3-am642: Sync with kernel v6.6-rc1
Sync with kernel v6.6-rc1 Bootlog: am642-sk: https://gist.github.com/nmenon/35f509e2f63b0ab0b434625e68e4f37d Nishanth Menon (4): arm: dts: Introduce k3-serdes.h from v6.6-rc1 arm: dts: k3*: Use local header for SERDES MUX idle-state values dt-bindings: ti-serdes: Deprecate header with constants with v6.6-rc1 arm: dts: k3-am642: Sync with kernel v6.6-rc1 arch/arm/dts/k3-am64-main.dtsi| 48 +- arch/arm/dts/k3-am642-evm.dts | 4 +- arch/arm/dts/k3-am642-sk.dts | 8 +- arch/arm/dts/k3-j7200-common-proc-board.dts | 2 +- arch/arm/dts/k3-j721e-main.dtsi | 2 +- .../ti-serdes.h => arch/arm/dts/k3-serdes.h | 90 ++- include/dt-bindings/mux/ti-serdes.h | 70 +++ 7 files changed, 186 insertions(+), 38 deletions(-) copy include/dt-bindings/mux/ti-serdes.h => arch/arm/dts/k3-serdes.h (55%) -- 2.40.0
[PATCH 4/4] arm: dts: k3-am642: Sync with kernel v6.6-rc1
Sync device tree with v6.6-rc1
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am64-main.dtsi | 48 +++---
arch/arm/dts/k3-am642-evm.dts | 2 ++
arch/arm/dts/k3-am642-sk.dts | 6 ++---
3 files changed, 25 insertions(+), 31 deletions(-)
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 1664d9f0241c..0df54a741824 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -44,11 +44,28 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x4300 0x2>;
+ chipid@14 {
+ compatible = "ti,am654-chipid";
+ reg = <0x0014 0x4>;
+ };
+
serdes_ln_ctrl: mux-controller {
compatible = "mmio-mux";
#mux-control-cells = <1>;
mux-reg-masks = <0x4080 0x3>; /* SERDES0 lane0 select */
};
+
+ phy_gmii_sel: phy@4044 {
+ compatible = "ti,am654-phy-gmii-sel";
+ reg = <0x4044 0x8>;
+ #phy-cells = <1>;
+ };
+
+ epwm_tbclk: clock-controller@4140 {
+ compatible = "ti,am64-epwm-tbclk";
+ reg = <0x4130 0x4>;
+ #clock-cells = <1>;
+ };
};
gic500: interrupt-controller@180 {
@@ -203,31 +220,6 @@
pinctrl-single,function-mask = <0x>;
};
- main_conf: syscon@4300 {
- compatible = "syscon", "simple-mfd";
- reg = <0x00 0x4300 0x00 0x2>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x00 0x00 0x4300 0x2>;
-
- chipid@14 {
- compatible = "ti,am654-chipid";
- reg = <0x0014 0x4>;
- };
-
- phy_gmii_sel: phy@4044 {
- compatible = "ti,am654-phy-gmii-sel";
- reg = <0x4044 0x8>;
- #phy-cells = <1>;
- };
-
- epwm_tbclk: clock@4140 {
- compatible = "ti,am64-epwm-tbclk", "syscon";
- reg = <0x4130 0x4>;
- #clock-cells = <1>;
- };
- };
-
main_timer0: timer@240 {
compatible = "ti,am654-timer";
reg = <0x00 0x240 0x00 0x400>;
@@ -733,7 +725,7 @@
pinctrl-single,function-mask = <0x000107ff>;
};
- usbss0: cdns-usb@f90{
+ usbss0: cdns-usb@f90 {
compatible = "ti,am64-usb";
reg = <0x00 0xf90 0x00 0x100>;
power-domains = <_pds 161 TI_SCI_PD_EXCLUSIVE>;
@@ -744,7 +736,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
- usb0: usb@f40{
+ usb0: usb@f40 {
compatible = "cdns,usb3";
reg = <0x00 0xf40 0x00 0x1>,
<0x00 0xf41 0x00 0x1>,
@@ -773,6 +765,7 @@
assigned-clock-parents = <_clks 0 3>;
assigned-clock-rates = <6000>;
clock-names = "fck";
+ status = "disabled";
adc {
#io-channel-cells = <1>;
@@ -802,6 +795,7 @@
assigned-clock-parents = <_clks 75 7>;
assigned-clock-rates = <1>;
power-domains = <_pds 75 TI_SCI_PD_EXCLUSIVE>;
+ status = "disabled";
};
};
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index fe2ea25b396f..b4a1f73d4fb1 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -10,6 +10,7 @@
#include
#include
#include "k3-am642.dtsi"
+
#include "k3-serdes.h"
/ {
@@ -519,6 +520,7 @@
};
{
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
diff --git a/arch/arm/dts/k3-am642-sk.dts b/arch/arm/dts/k3-am642-sk.dts
index ece75680f3f4..722fd285a34e 100644
--- a/arch/arm/dts/k3-am642-sk.dts
+++ b/arch/arm/dts/k3-am642-sk.dts
@@ -10,6 +10,7 @@
#include
#include
#include "k3-am642.dtsi"
+
#include "k3-serdes.h"
/ {
@@ -512,11 +513,8 @@
};
};
- {
- status = "disabled";
-};
-
{
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
--
2.40.0
Re: [PATCH 3/8] binman: capsule: Generate capsules through config file
hi Simon, On Mon, 11 Sept 2023 at 00:44, Simon Glass wrote: > > Hi Sughosh, > > On Fri, 8 Sept 2023 at 06:00, Sughosh Ganu wrote: > > > > Add support in binman for generating capsules by reading the capsule > > parameters through a config file. Also add a test case in binman for > > this mode of capsule generation. > > > > Signed-off-by: Sughosh Ganu > > --- > > > > tools/binman/entries.rst | 35 > > tools/binman/etype/efi_capsule_cfg_file.py | 66 ++ > > tools/binman/ftest.py | 29 ++ > > tools/binman/test/319_capsule_cfg.dts | 15 + > > 4 files changed, 145 insertions(+) > > create mode 100644 tools/binman/etype/efi_capsule_cfg_file.py > > create mode 100644 tools/binman/test/319_capsule_cfg.dts > > I think we discussed this some time ago. The problem I have with this > is that it adds another way of specifying the image description, > separate from the binman definition. This introduces all sorts of > problems: > > - the question of where the filenames are located, something which > binman tries to handle cohesively > - binman has no knowledge of what is being put in the capsules > - the resulting fdtmap lacks any information about what is in the capsules > - it seems to create two ways of doing the same thing > > Binman can presumably already create multiple capsule files, just by > adding to the description. > > What need does this feature meet? We already had this discussion earlier about the need for generating capsules through the config file, where I had explained the need for this [1]. This is functionality which is supported by the specification, and we have folks who are interested in having the capsules generated through config file, and also in generation of a single capsule file consisting of multiple input payloads. I understand that this model does not fit with the usual way in binman of generating an output image by specifying it's inputs as DT nodes. But just because this does not fit or align with the design of the tool does not mean that we do not add support for the functionality. Why can't we support this in binman as long as it is properly documented as to what is being done. Moreover, my initial versions of this patchset were attempting to achieve this by adding a make target, but you had shot it down [2]. So it either has to be done through binman, or through a make target. -sughosh [1] - https://lists.denx.de/pipermail/u-boot/2023-July/524849.html [2] - https://lists.denx.de/pipermail/u-boot/2023-June/521103.html
[PATCH 5/5] arm64: zynqmp: Update ECAM size to discover up to 256 buses
From: Thippeswamy Havalige Update ECAM size to discover up to 256 buses Signed-off-by: Thippeswamy Havalige Acked-by: Venkatesh Yadav Abbarapu Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index a71875755bc0..79c5af241104 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -678,7 +678,7 @@ msi-parent = <>; reg = <0x0 0xfd0e 0x0 0x1000>, <0x0 0xfd48 0x0 0x1000>, - <0x80 0x 0x0 0x100>; + <0x80 0x 0x0 0x1000>; reg-names = "breg", "pcireg", "cfg"; ranges = <0x0200 0x 0xe000 0x 0xe000 0x 0x1000>,/* non-prefetchable memory */ <0x4300 0x0006 0x 0x0006 0x 0x0002 0x>;/* prefetchable memory */ -- 2.36.1
[PATCH 4/5] arm64: zynqmp: Add resets property for CAN nodes
From: Srinivas Neeli Added resets property for CAN nodes. Signed-off-by: Srinivas Neeli Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 355f360281b5..a71875755bc0 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -262,6 +262,7 @@ interrupt-parent = <>; tx-fifo-depth = <0x40>; rx-fifo-depth = <0x40>; + resets = <_reset ZYNQMP_RESET_CAN0>; power-domains = <_firmware PD_CAN_0>; }; @@ -274,6 +275,7 @@ interrupt-parent = <>; tx-fifo-depth = <0x40>; rx-fifo-depth = <0x40>; + resets = <_reset ZYNQMP_RESET_CAN1>; power-domains = <_firmware PD_CAN_1>; }; -- 2.36.1
[PATCH 3/5] arm64: zynqmp: Fix i2c address for si570_user1 clock
From: Saeed Nowshadi
Correct the i2c address for si570 oscillator that generates the si570_user1
clock. i2c address was changed by commit b6a8c603d680 ("arm64: zynqmp: Fix
i2c addresses for vck190 SC") because address in node name wasn't aligned
with reg property. But actual 0x5f address is correct which is quite rare
because all other si570s are at 0x5d.
Signed-off-by: Saeed Nowshadi
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
b/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
index bf6ffb778b6a..bf7569c6dda5 100644
--- a/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
@@ -2,7 +2,8 @@
/*
* dts file for Xilinx Versal a2197 RevA System Controller
*
- * (C) Copyright 2019 - 2021, Xilinx, Inc.
+ * (C) Copyright 2019 - 2022, Xilinx, Inc.
+ * (C) Copyright 2022 - 2023, Advanced Micro Devices, Inc.
*
* Michal Simek
*/
@@ -460,10 +461,10 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <6>;
- si570_user1: clock-generator@5d { /* u205 */
+ si570_user1: clock-generator@5f { /* u205 */
#clock-cells = <0>;
compatible = "silabs,si570";
- reg = <0x5d>;
+ reg = <0x5f>;
temperature-stability = <50>;
factory-fout = <1>;
clock-frequency = <1>;
--
2.36.1
[PATCH 2/5] arm64: versal: Add no-wp DT property in OSPI flash node
From: Amit Kumar Mahapatra Added no-wp DT property in OSPI flash node for all board dts & dtsi files on which the WP# signal of the OSPI flash device is not connected. If this property is set, then the software will avoid setting the status register write disable (SRWD) bit in status register during status register write operation. Signed-off-by: Amit Kumar Mahapatra Signed-off-by: Michal Simek --- arch/arm/dts/versal-mini-ospi.dtsi | 1 + arch/arm/dts/versal-net-mini-ospi.dtsi | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/dts/versal-mini-ospi.dtsi b/arch/arm/dts/versal-mini-ospi.dtsi index 19caea7368a0..5683a2306bde 100644 --- a/arch/arm/dts/versal-mini-ospi.dtsi +++ b/arch/arm/dts/versal-mini-ospi.dtsi @@ -57,6 +57,7 @@ spi-tx-bus-width = <8>; spi-rx-bus-width = <8>; spi-max-frequency = <2000>; + no-wp; }; }; }; diff --git a/arch/arm/dts/versal-net-mini-ospi.dtsi b/arch/arm/dts/versal-net-mini-ospi.dtsi index ce8e2158f6ed..5d188db62d92 100644 --- a/arch/arm/dts/versal-net-mini-ospi.dtsi +++ b/arch/arm/dts/versal-net-mini-ospi.dtsi @@ -72,6 +72,7 @@ spi-tx-bus-width = <8>; spi-rx-bus-width = <8>; spi-max-frequency = <2000>; + no-wp; }; }; }; -- 2.36.1
[PATCH 1/5] arm64: zynqmp: Rename xlnx, mio_bank to xlnx, mio-bank for DLC21
xlnx,mio_bank was used in past but it was renamed to xlnx,mio-bank because
'_' in property shoudln't be used. There is no impact on the platform
because if the properly is not defined bank 0 is default. Bank 0 and 1 have
the same configuration that's why there shouldn't be any issue.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-dlc21-revA.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-dlc21-revA.dts
b/arch/arm/dts/zynqmp-dlc21-revA.dts
index 1b247bfa8944..016081ef7b99 100644
--- a/arch/arm/dts/zynqmp-dlc21-revA.dts
+++ b/arch/arm/dts/zynqmp-dlc21-revA.dts
@@ -61,14 +61,14 @@
non-removable;
disable-wp;
bus-width = <8>;
- xlnx,mio_bank = <0>;
+ xlnx,mio-bank = <0>;
};
{ /* sd1 MIO45-51 cd in place */
status = "okay";
no-1-8-v;
disable-wp;
- xlnx,mio_bank = <1>;
+ xlnx,mio-bank = <1>;
};
{
--
2.36.1
[PATCH 0/5] xilinx: Sync DTs with Xilinx tree
Hi, I am sending patches which I found are not sent out yet. These 5 patches are fixing typos or incorrect device description or adding already defined properties. Thanks, Michal Amit Kumar Mahapatra (1): arm64: versal: Add no-wp DT property in OSPI flash node Michal Simek (1): arm64: zynqmp: Rename xlnx,mio_bank to xlnx,mio-bank for DLC21 Saeed Nowshadi (1): arm64: zynqmp: Fix i2c address for si570_user1 clock Srinivas Neeli (1): arm64: zynqmp: Add resets property for CAN nodes Thippeswamy Havalige (1): arm64: zynqmp: Update ECAM size to discover up to 256 buses arch/arm/dts/versal-mini-ospi.dtsi | 1 + arch/arm/dts/versal-net-mini-ospi.dtsi | 1 + arch/arm/dts/zynqmp-dlc21-revA.dts | 4 ++-- arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 7 --- arch/arm/dts/zynqmp.dtsi| 4 +++- 5 files changed, 11 insertions(+), 6 deletions(-) -- 2.36.1
[PATCH 2/2] arm: dts: k3-am625: Sync with kernel v6.6-rc1
Sync device tree with v6.6-rc1
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am62-main.dtsi | 52 -
arch/arm/dts/k3-am62-mcu.dtsi| 24 +
arch/arm/dts/k3-am62-verdin-dev.dtsi | 50 +
arch/arm/dts/k3-am62-verdin.dtsi | 45 +++-
arch/arm/dts/k3-am62.dtsi| 8 ++
arch/arm/dts/k3-am625-beagleplay.dts | 154 ++-
arch/arm/dts/k3-am625-sk.dts | 2 +-
7 files changed, 325 insertions(+), 10 deletions(-)
diff --git a/arch/arm/dts/k3-am62-main.dtsi b/arch/arm/dts/k3-am62-main.dtsi
index 2488e3a537fe..284b90c94da8 100644
--- a/arch/arm/dts/k3-am62-main.dtsi
+++ b/arch/arm/dts/k3-am62-main.dtsi
@@ -55,11 +55,29 @@
#phy-cells = <1>;
};
- epwm_tbclk: clock@4130 {
- compatible = "ti,am62-epwm-tbclk", "syscon";
+ epwm_tbclk: clock-controller@4130 {
+ compatible = "ti,am62-epwm-tbclk";
reg = <0x4130 0x4>;
#clock-cells = <1>;
};
+
+ audio_refclk0: clock-controller@82e0 {
+ compatible = "ti,am62-audio-refclk";
+ reg = <0x82e0 0x4>;
+ clocks = <_clks 157 0>;
+ assigned-clocks = <_clks 157 0>;
+ assigned-clock-parents = <_clks 157 8>;
+ #clock-cells = <0>;
+ };
+
+ audio_refclk1: clock-controller@82e4 {
+ compatible = "ti,am62-audio-refclk";
+ reg = <0x82e4 0x4>;
+ clocks = <_clks 157 10>;
+ assigned-clocks = <_clks 157 10>;
+ assigned-clock-parents = <_clks 157 18>;
+ #clock-cells = <0>;
+ };
};
dmss: bus@4800 {
@@ -174,7 +192,6 @@
crypto: crypto@4090 {
compatible = "ti,am62-sa3ul";
reg = <0x00 0x4090 0x00 0x1200>;
- power-domains = <_pds 70 TI_SCI_PD_SHARED>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x00 0x4090 0x00 0x4090 0x00 0x3>;
@@ -590,7 +607,7 @@
usb0: usb@3100 {
compatible = "snps,dwc3";
- reg =<0x00 0x3100 0x00 0x5>;
+ reg = <0x00 0x3100 0x00 0x5>;
interrupts = , /*
irq.0 */
; /*
irq.0 */
interrupt-names = "host", "peripheral";
@@ -613,7 +630,7 @@
usb1: usb@3110 {
compatible = "snps,dwc3";
- reg =<0x00 0x3110 0x00 0x5>;
+ reg = <0x00 0x3110 0x00 0x5>;
interrupts = , /*
irq.0 */
; /*
irq.0 */
interrupt-names = "host", "peripheral";
@@ -718,6 +735,31 @@
};
};
+ dss: dss@3020 {
+ compatible = "ti,am625-dss";
+ reg = <0x00 0x3020 0x00 0x1000>, /* common */
+ <0x00 0x30202000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30206000 0x00 0x1000>, /* vid */
+ <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
+ <0x00 0x3020a000 0x00 0x1000>, /* vp1: Used for OLDI */
+ <0x00 0x3020b000 0x00 0x1000>; /* vp2: Used as DPI Out */
+ reg-names = "common", "vidl1", "vid",
+ "ovr1", "ovr2", "vp1", "vp2";
+ power-domains = <_pds 186 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 186 6>,
+<_vp1_clk>,
+<_clks 186 2>;
+ clock-names = "fck", "vp1", "vp2";
+ interrupts = ;
+ status = "disabled";
+
+ dss_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
hwspinlock: spinlock@2a00 {
compatible = "ti,am64-hwspinlock";
reg = <0x00 0x2a00 0x00 0x1000>;
diff --git a/arch/arm/dts/k3-am62-mcu.dtsi b/arch/arm/dts/k3-am62-mcu.dtsi
index 19fc38157d94..80a3e1db26a9 100644
--- a/arch/arm/dts/k3-am62-mcu.dtsi
+++ b/arch/arm/dts/k3-am62-mcu.dtsi
@@ -147,4 +147,28 @@
/* Tightly coupled to M4F */
status = "reserved";
};
+
+ mcu_mcan0: can@4e08000 {
+ compatible = "bosch,m_can";
+ reg = <0x00 0x4e08000 0x00 0x200>,
+ <0x00 0x4e0 0x00 0x8000>;
+ reg-names = "m_can", "message_ram";
+ power-domains = <_pds 188
[PATCH 1/2] arm: dts: k3-pinctrl: Sync with kernel v6.6-rc1
Sync pinctrl header with v6.6-rc1 Signed-off-by: Nishanth Menon --- arch/arm/dts/k3-pinctrl.h | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/dts/k3-pinctrl.h b/arch/arm/dts/k3-pinctrl.h index c97548a3f42d..2a4e0e084d69 100644 --- a/arch/arm/dts/k3-pinctrl.h +++ b/arch/arm/dts/k3-pinctrl.h @@ -11,6 +11,7 @@ #define PULLUDEN_SHIFT (16) #define PULLTYPESEL_SHIFT (17) #define RXACTIVE_SHIFT (18) +#define DEBOUNCE_SHIFT (11) #define PULL_DISABLE (1 << PULLUDEN_SHIFT) #define PULL_ENABLE(0 << PULLUDEN_SHIFT) @@ -29,9 +30,20 @@ #define PIN_INPUT_PULLUP (INPUT_EN | PULL_UP) #define PIN_INPUT_PULLDOWN (INPUT_EN | PULL_DOWN) +#define PIN_DEBOUNCE_DISABLE (0 << DEBOUNCE_SHIFT) +#define PIN_DEBOUNCE_CONF1 (1 << DEBOUNCE_SHIFT) +#define PIN_DEBOUNCE_CONF2 (2 << DEBOUNCE_SHIFT) +#define PIN_DEBOUNCE_CONF3 (3 << DEBOUNCE_SHIFT) +#define PIN_DEBOUNCE_CONF4 (4 << DEBOUNCE_SHIFT) +#define PIN_DEBOUNCE_CONF5 (5 << DEBOUNCE_SHIFT) +#define PIN_DEBOUNCE_CONF6 (6 << DEBOUNCE_SHIFT) + #define AM62AX_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) #define AM62AX_MCU_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) +#define AM62PX_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) +#define AM62PX_MCU_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) + #define AM62X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) #define AM62X_MCU_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) -- 2.40.0
[PATCH 0/2] arm: dts: k3-am625: Sync with kernel v6.6-rc1
Sync device tree with v6.6-rc1 Bootlog: beagleplay: https://gist.github.com/nmenon/b46863248e8cf0cdaaeca0d55c966af4 Nishanth Menon (2): arm: dts: k3-pinctrl: Sync with kernel v6.6-rc1 arm: dts: k3-am625: Sync with kernel v6.6-rc1 arch/arm/dts/k3-am62-main.dtsi | 52 - arch/arm/dts/k3-am62-mcu.dtsi| 24 + arch/arm/dts/k3-am62-verdin-dev.dtsi | 50 + arch/arm/dts/k3-am62-verdin.dtsi | 45 +++- arch/arm/dts/k3-am62.dtsi| 8 ++ arch/arm/dts/k3-am625-beagleplay.dts | 154 ++- arch/arm/dts/k3-am625-sk.dts | 2 +- arch/arm/dts/k3-pinctrl.h| 12 +++ 8 files changed, 337 insertions(+), 10 deletions(-) -- 2.40.0
Re: [PATCH] buildman: Disable CONFIG_CMD_CONFIG for reproduceable build
On Sun, Sep 10, 2023 at 06:13:35PM -0600, Simon Glass wrote: > When the ordering of CONFIG options changes, the gzipped CONFIG list can > change in size and contents. This makes it hard to compare commits which > only different in CONFIG ordering. > > Disable this when -r is given, to make this easier. Update the > documentation as well. > > Signed-off-by: Simon Glass This isn't the right approach. First, thanks for figuring out the slight rodata change that happens when testing some Kconfig rework series. However, this first violates the principal of least surprise as you're turning off part of the build that was on before. Second, it's not the only zlib in the build, and it's often reproducible. We should have a section somewhere in the docs about tips and tricks for doing Kconfig rework as there's other things too such as not having the baseline commit to compare with be a version tag since everything will grow slightly due to then having a githash appending to it. -- Tom signature.asc Description: PGP signature
[PATCH] dm: core: ofnode: Fix error message in ofnode_read_bootscript_address/flash()
Missing u-boot node shouldn't be visible in bootlog without debug enabled
that's why change message from printf to debug.
Signed-off-by: Michal Simek
---
drivers/core/ofnode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 2d82f38db36d..df2d7fdd535c 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -1603,7 +1603,7 @@ int ofnode_read_bootscript_address(u64 *bootscr_address,
u64 *bootscr_offset)
uboot = ofnode_path("/options/u-boot");
if (!ofnode_valid(uboot)) {
- printf("%s: Missing /u-boot node\n", __func__);
+ debug("%s: Missing /u-boot node\n", __func__);
return -EINVAL;
}
@@ -1629,7 +1629,7 @@ int ofnode_read_bootscript_flash(u64
*bootscr_flash_offset,
uboot = ofnode_path("/options/u-boot");
if (!ofnode_valid(uboot)) {
- printf("%s: Missing /u-boot node\n", __func__);
+ debug("%s: Missing /u-boot node\n", __func__);
return -EINVAL;
}
--
2.36.1
Re: [PATCH] arm64: xilinx: Guard distro boot variable generation
On 9/5/23 13:30, Michal Simek wrote:
When distro boot is disabled there is no reason to generate variables for
it. Also do not update boot_targets variable because it would be unused.
It is useful for example when standard boot is enabled and distro boot
is disabled.
Signed-off-by: Michal Simek
---
board/xilinx/versal-net/board.c | 32 -
board/xilinx/versal/board.c | 31 +++-
board/xilinx/zynqmp/zynqmp.c| 56 +
include/configs/xilinx_versal.h | 6
include/configs/xilinx_versal_net.h | 6
include/configs/xilinx_zynqmp.h | 6
6 files changed, 97 insertions(+), 40 deletions(-)
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index 7ad299f3a231..c18be0c26c99 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -194,7 +194,7 @@ static u8 versal_net_get_bootmode(void)
return bootmode;
}
-int board_late_init(void)
+static int boot_targets_setup(void)
{
u8 bootmode;
struct udevice *dev;
@@ -205,14 +205,6 @@ int board_late_init(void)
char *new_targets;
char *env_targets;
- if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
- debug("Saved variables - Skipping\n");
- return 0;
- }
-
- if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
- return 0;
-
bootmode = versal_net_get_bootmode();
puts("Bootmode: ");
@@ -320,6 +312,28 @@ int board_late_init(void)
env_set("boot_targets", new_targets);
}
+
+ return 0;
+}
+
+int board_late_init(void)
+{
+ int ret;
+
+ if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
+ debug("Saved variables - Skipping\n");
+ return 0;
+ }
+
+ if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
+ return 0;
+
+ if (IS_ENABLED(CONFIG_DISTRO_DEFAULTS)) {
+ ret = boot_targets_setup();
+ if (ret)
+ return ret;
+ }
+
return board_late_init_xilinx();
}
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 982a8b3779f1..e4bdd5d7a38b 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -126,7 +126,7 @@ static u8 versal_get_bootmode(void)
return bootmode;
}
-int board_late_init(void)
+static int boot_targets_setup(void)
{
u8 bootmode;
struct udevice *dev;
@@ -137,14 +137,6 @@ int board_late_init(void)
char *new_targets;
char *env_targets;
- if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
- debug("Saved variables - Skipping\n");
- return 0;
- }
-
- if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
- return 0;
-
bootmode = versal_get_bootmode();
puts("Bootmode: ");
@@ -247,6 +239,27 @@ int board_late_init(void)
env_set("boot_targets", new_targets);
}
+ return 0;
+}
+
+int board_late_init(void)
+{
+ int ret;
+
+ if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
+ debug("Saved variables - Skipping\n");
+ return 0;
+ }
+
+ if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
+ return 0;
+
+ if (IS_ENABLED(CONFIG_DISTRO_DEFAULTS)) {
+ ret = boot_targets_setup();
+ if (ret)
+ return ret;
+ }
+
return board_late_init_xilinx();
}
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 0b6d4e57078b..f16280308483 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -384,7 +384,7 @@ static int set_fdtfile(void)
return 0;
}
-int board_late_init(void)
+static int boot_targets_setup(void)
{
u8 bootmode;
struct udevice *dev;
@@ -394,27 +394,6 @@ int board_late_init(void)
const char *mode = NULL;
char *new_targets;
char *env_targets;
- int ret, multiboot;
-
-#if defined(CONFIG_USB_ETHER) && !defined(CONFIG_USB_GADGET_DOWNLOAD)
- usb_ether_init();
-#endif
-
- if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
- debug("Saved variables - Skipping\n");
- return 0;
- }
-
- if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
- return 0;
-
- ret = set_fdtfile();
- if (ret)
- return ret;
-
- multiboot = multi_boot();
- if (multiboot >= 0)
- env_set_hex("multiboot", multiboot);
bootmode = zynqmp_get_bootmode();
@@ -525,6 +504,39 @@ int board_late_init(void)
free(new_targets);
}
+ return 0;
+}
+
+int board_late_init(void)
+{
+ int ret, multiboot;
+
+#if defined(CONFIG_USB_ETHER) && !defined(CONFIG_USB_GADGET_DOWNLOAD)
+ usb_ether_init();
+#endif
+
+ if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
Re: [PATCH] arm64: versal: Do not define boot command for mini configurations
On 9/5/23 10:23, Michal Simek wrote: Mini configuration is not design to boot anything that's why there is no reason to setup boot command. CONFIG_DISTRO_DEFAULTS is disabled anyway. Signed-off-by: Michal Simek --- configs/xilinx_versal_mini_defconfig | 2 -- configs/xilinx_versal_mini_emmc0_defconfig | 2 -- configs/xilinx_versal_mini_emmc1_defconfig | 2 -- 3 files changed, 6 deletions(-) diff --git a/configs/xilinx_versal_mini_defconfig b/configs/xilinx_versal_mini_defconfig index 53376db9df30..78be2002fb8a 100644 --- a/configs/xilinx_versal_mini_defconfig +++ b/configs/xilinx_versal_mini_defconfig @@ -21,8 +21,6 @@ CONFIG_SYS_MEMTEST_END=0x1000 CONFIG_REMAKE_ELF=y # CONFIG_LEGACY_IMAGE_FORMAT is not set # CONFIG_AUTOBOOT is not set -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="run distro_bootcmd" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_BOARD_EARLY_INIT_R=y diff --git a/configs/xilinx_versal_mini_emmc0_defconfig b/configs/xilinx_versal_mini_emmc0_defconfig index 31b3c02f7389..129ddce3ef06 100644 --- a/configs/xilinx_versal_mini_emmc0_defconfig +++ b/configs/xilinx_versal_mini_emmc0_defconfig @@ -17,8 +17,6 @@ CONFIG_SYS_LOAD_ADDR=0x800 # CONFIG_EXPERT is not set CONFIG_REMAKE_ELF=y # CONFIG_AUTOBOOT is not set -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="run distro_bootcmd" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_BOARD_EARLY_INIT_R=y diff --git a/configs/xilinx_versal_mini_emmc1_defconfig b/configs/xilinx_versal_mini_emmc1_defconfig index 5480cf1d9cc4..116ec450bda8 100644 --- a/configs/xilinx_versal_mini_emmc1_defconfig +++ b/configs/xilinx_versal_mini_emmc1_defconfig @@ -17,8 +17,6 @@ CONFIG_SYS_LOAD_ADDR=0x800 # CONFIG_EXPERT is not set CONFIG_REMAKE_ELF=y # CONFIG_AUTOBOOT is not set -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="run distro_bootcmd" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_BOARD_EARLY_INIT_R=y Applied. M
Re: [PATCH] config: j7200: removed not needed power config
On 16:49-20230911, Udit Kumar wrote: > For J7200, R5/SPL TI_SCI_POWER_DOMAIN should be > disabled as DM is a separate binary like other > SOC of J7* family. > > Fixes: 02dff65efe7 (configs: j7200_evm_r5: Add initial support) > > Signed-off-by: Udit Kumar > --- > Boot logs > https://gist.github.com/uditkumarti/04f053efa73eae8be53666d9a31033c2 > > configs/j7200_evm_r5_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig > index 6d240b16cb..9e744ba434 100644 > --- a/configs/j7200_evm_r5_defconfig > +++ b/configs/j7200_evm_r5_defconfig > @@ -126,7 +126,6 @@ CONFIG_SPL_PINCTRL=y > # CONFIG_SPL_PINCTRL_GENERIC is not set > CONFIG_PINCTRL_SINGLE=y > CONFIG_POWER_DOMAIN=y > -CONFIG_TI_SCI_POWER_DOMAIN=y > CONFIG_TI_POWER_DOMAIN=y > CONFIG_DM_PMIC=y > CONFIG_PMIC_TPS65941=y > -- > 2.34.1 > And maybe expand this patch so that it contains something like the following to prevent this from coming back again elsewhere? diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig index fbcdefd889ae..aff1ba5ab43b 100644 --- a/drivers/clk/ti/Kconfig +++ b/drivers/clk/ti/Kconfig @@ -36,7 +36,7 @@ config CLK_TI_MUX config CLK_TI_SCI bool "TI System Control Interface (TI SCI) clock driver" - depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL + depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL && !CLK_K3 help This enables the clock driver support over TI System Control Interface available on some new TI's SoCs. If you wish to use clock resources @@ -44,24 +44,24 @@ config CLK_TI_SCI config CLK_K3_PLL bool "PLL clock support for K3 SoC family of devices" - depends on CLK && LIB_RATIONAL + depends on CLK && LIB_RATIONAL && !CLK_TI_SCI help Enables PLL clock support for K3 SoC family of devices. config SPL_CLK_K3_PLL bool "PLL clock support for K3 SoC family of devices" - depends on CLK && LIB_RATIONAL && SPL + depends on CLK && LIB_RATIONAL && SPL && !CLK_TI_SCI help Enables PLL clock support for K3 SoC family of devices. config CLK_K3 bool "Clock support for K3 SoC family of devices" - depends on CLK + depends on CLK && !CLK_TI_SCI help Enables the clock translation layer from DT to device clocks. config SPL_CLK_K3 bool "Clock support for K3 SoC family of devices" - depends on CLK && SPL + depends on CLK && SPL && !CLK_TI_SCI help Enables the clock translation layer from DT to device clocks. diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig index 411c210756a3..9625764b304b 100644 --- a/drivers/power/domain/Kconfig +++ b/drivers/power/domain/Kconfig @@ -92,14 +92,14 @@ config TEGRA186_POWER_DOMAIN config TI_SCI_POWER_DOMAIN bool "Enable the TI SCI-based power domain driver" - depends on POWER_DOMAIN && TI_SCI_PROTOCOL + depends on POWER_DOMAIN && TI_SCI_PROTOCOL && !TI_POWER_DOMAIN help Generic power domain implementation for TI devices implementing the TI SCI protocol. config TI_POWER_DOMAIN bool "Enable the TI K3 Power domain driver" - depends on POWER_DOMAIN && ARCH_K3 + depends on POWER_DOMAIN && ARCH_K3 && !TI_SCI_POWER_DOMAIN help Generic power domain implementation for TI K3 devices. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH 3/3] trace: Fix alignment logic in flyrecord header
Current alignment which is using 16 bytes is not correct in connection to
trace_clocks description and it's length.
That's why use start_addr variable and record proper size based on used
entries.
Fixes: be16fc81b2ed ("trace: Update proftool to use new binary format").
Signed-off-by: Michal Simek
---
tools/proftool.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/tools/proftool.c b/tools/proftool.c
index 7c95a94482fc..f79128169e68 100644
--- a/tools/proftool.c
+++ b/tools/proftool.c
@@ -1493,19 +1493,43 @@ static int write_pages(struct twriter *tw, enum
out_format_t out_format,
static int write_flyrecord(struct twriter *tw, enum out_format_t out_format,
int *missing_countp, int *skip_countp)
{
- unsigned long long start, len;
+ unsigned long long start, start_addr, len;
int ret;
FILE *fout = tw->fout;
char str[200];
+ /* Record start pointer */
+ start_addr = tw->ptr;
+ debug("Start of flyrecord header at: 0x%llx\n", start_addr);
+
tw->ptr += fprintf(fout, "flyrecord%c", 0);
+ /* flyrecord\0 - allocated 10 bytes */
+ start_addr += 10;
+
+ /*
+* 8 bytes that are a 64-bit word containing the offset into the file
+* that holds the data for the CPU.
+*
+* 8 bytes that are a 64-bit word containing the size of the CPU
+* data at that offset.
+*/
+ start_addr += 16;
+
snprintf(str, sizeof(str),
"[local] global counter uptime perf mono mono_raw boot
x86-tsc\n");
len = strlen(str);
+ /* trace clock length - 8 bytes */
+ start_addr += 8;
+ /* trace clock data */
+ start_addr += len;
+
+ debug("Calculated flyrecord header end at: 0x%llx, trace clock len:
0x%llx\n",
+ start_addr, len);
+
/* trace data */
- start = ALIGN(tw->ptr + 16, TRACE_PAGE_SIZE);
+ start = ALIGN(start_addr, TRACE_PAGE_SIZE);
tw->ptr += tputq(fout, start);
/* use a placeholder for the size */
@@ -1517,6 +1541,9 @@ static int write_flyrecord(struct twriter *tw, enum
out_format_t out_format,
tw->ptr += tputq(fout, len);
tw->ptr += tputs(fout, str);
+ debug("End of flyrecord header at: 0x%x, offset: 0x%llx\n",
+ tw->ptr, start);
+
debug("trace text base %lx, map file %lx\n", text_base, text_offset);
ret = write_pages(tw, out_format, missing_countp, skip_countp);
--
2.36.1
[PATCH 2/3] trace: Move trace_clocks description above record offset calculation
Flyrecord tracing data are page aligned that's why it is necessary to calculate alignment properly. Because trace_clocks description is the part of record length it is necessary to have information about length earlier. Signed-off-by: Michal Simek --- tools/proftool.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/proftool.c b/tools/proftool.c index 869a2a32c510..7c95a94482fc 100644 --- a/tools/proftool.c +++ b/tools/proftool.c @@ -1500,6 +1500,10 @@ static int write_flyrecord(struct twriter *tw, enum out_format_t out_format, tw->ptr += fprintf(fout, "flyrecord%c", 0); + snprintf(str, sizeof(str), +"[local] global counter uptime perf mono mono_raw boot x86-tsc\n"); + len = strlen(str); + /* trace data */ start = ALIGN(tw->ptr + 16, TRACE_PAGE_SIZE); tw->ptr += tputq(fout, start); @@ -1510,9 +1514,6 @@ static int write_flyrecord(struct twriter *tw, enum out_format_t out_format, return -1; tw->ptr += ret; - snprintf(str, sizeof(str), -"[local] global counter uptime perf mono mono_raw boot x86-tsc\n"); - len = strlen(str); tw->ptr += tputq(fout, len); tw->ptr += tputs(fout, str); -- 2.36.1
[PATCH 0/3] trace: Fix flyrecord alignment issue
Hi, sandbox is getting bigger and bigger and I have reached the case that adding some more functions ends up in CI loop failure. After some investigation I found that flyrecord header have incorrect information about data offset which is caused by incorrect alignment calculation. That's why this series is fixing alignment calculation. I have done it via 3 patches where the first two are just preparing code for actual fixup. Thanks, Michal Michal Simek (3): trace: Use 64bit variable for start and len trace: Move trace_clocks description above record offset calculation trace: Fix alignment logic in flyrecord header tools/proftool.c | 39 ++- 1 file changed, 34 insertions(+), 5 deletions(-) -- 2.36.1
[PATCH 1/3] trace: Use 64bit variable for start and len
tputq() requires variables to have 64bit width that's why make them 64bit
to clean alignment requirement.
Signed-off-by: Michal Simek
---
tools/proftool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/proftool.c b/tools/proftool.c
index 101bcb63334e..869a2a32c510 100644
--- a/tools/proftool.c
+++ b/tools/proftool.c
@@ -1493,7 +1493,8 @@ static int write_pages(struct twriter *tw, enum
out_format_t out_format,
static int write_flyrecord(struct twriter *tw, enum out_format_t out_format,
int *missing_countp, int *skip_countp)
{
- int start, ret, len;
+ unsigned long long start, len;
+ int ret;
FILE *fout = tw->fout;
char str[200];
--
2.36.1
Re: [PATCH 30/32] fdt: Allow the devicetree to come from a bloblist
Hi Michal, On Mon, 11 Sept 2023 at 13:58, Michal Simek wrote: > > Hi Ilias, > > On 9/11/23 09:56, Ilias Apalodimas wrote: > > Hi Michal, > > > > On Mon, 11 Sept 2023 at 09:38, Michal Simek wrote: > >> > >> > >> > >> On 9/11/23 08:17, Ilias Apalodimas wrote: > >>> Hi Simon, > >>> > >>> On Sun, 10 Sept 2023 at 22:14, Simon Glass wrote: > > Hi Ilias, > > On Mon, 4 Sept 2023 at 03:31, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > On Fri, 1 Sept 2023 at 18:51, Simon Glass wrote: > >> > >> Hi Ilias, > >> > >> On Fri, 1 Sept 2023 at 01:50, Ilias Apalodimas > >> wrote: > >>> > >>> [...] > >>> > > > >> +config OF_BLOBLIST > >> + bool "DTB is provided by a bloblist" > >> + help > >> + Select this to read the devicetree from the bloblist. This > >> allows > >> + using a bloblist to transfer the devicetree between > >> U-Boot phases. > >> + The devicetree is stored in the bloblist by an early phase > >> so that > >> + U-Boot can read it. > >> + > > > > I dont think this is a good idea. We used to have 4-5 different > > options > > here, which we tried to clean up and ended up with two very discrete > > options. Why do we have to reintroduce a new one? Doesn't that > > bloblist > > have a header of some sort? The bloblist literally comes from a > > previous > > stage bootloader which is what OF_BOARD is here for. So why can't > > we just > > read the header and figure out if the magic of the bloblist matches? > > No, OF_BOARD is a hack to allow boards to do what they like with the > FDT. > > This patch is a standard mechanism to pass the DT from one firmware > phase to the next. We have spent quite a bit of time creating a spec > for it, and we should use it. > >>> > >>> Where exactly am I objecting using the spec? Can you please re-read > >>> my email? > >>> I am actually pointing out we should use the spec *properly*. So > >>> instead of having a Kconfig option for the DT, which is pretty > >>> pointless, we should parse the bloblist. If the header defined by > >>> the *spec* is found, we should just search for the DT in there. > >>> What you are doing here, is take the spec, pick a very specific item > >>> that the list contains, and create a Kconfig option out of it. Which > >>> basically ignores the discoverable options of the bloblist. For > >>> example, that bloblist can also contain an entry to a TPM eventlog. > >>> Should we start creating Kconfig options for all the firmware handoff > >>> entries that are defined on that spec? > >> > >> OK so that is a different thing. What should it do if it expects to > >> find a bloblist but cannot? I want it to throw an error, because I am > >> trying to make the boot deterministic. What do you think? > > > > That's fine by me. You can even put that under IS_ENABLED for the > > bloblist inside the existing OF_BOARD check. So I was thinking > > - If no bloblist is required in Kconfig options we do the hacks we used > > to > > - if bloblist is selected and the config option is OF_BOARD, throw an > > error and mention that the previous stage loader should hand over a DT > > > > Is that what you had in mind? > > Yes, that sounds good to me. > > But I still think we need an OF_BLOBLIST option to control whether the > devicetree comes from there. > Otherwise we will end up with people > using OF_BOARD to work around it. We also have the SPL case which does > not pass the DT in a bloblist...in fact SPL typically doesn't even > have the full DT. > >>> > >>> Wouldn't IS_ENABLED(BLOBLIST) || IS_ENABLED(SPL_BLOBLIST) be enough? > >>> Inside the OF_BOARD portion of the function, search for a bloblist if > >>> the option is enabled. If you can't find a bloblist and the DT within > >>> that bloblist, then error out > >> > >> Just my 2c here. > >> I think all options should be possible to disable. It means I can imagine > >> to > >> disable u-boot not to take care about DT provided from previous stage. The > >> same > >> is for TPM event log. IMHO every stage should have an option to simply > >> ignore > >> data pass from previous stage. I don't really mind how it is done but there > >> should be an option to by purpose say to ignore the part of pass data. > > > > That would be done by disabling BLOBLIST. I don't think having a Kconfig > > to say > > "I want a bloblist, but I only want the DT from there" is reasonable > > (or for any other item the bloblist can carry). OF_BOARD means the > > DT will come from a previous stage loader. If
Re: [PATCH v2 7/7] arm: dts: k3-j721e: Sync with v6.5-rc1
On 19:44-20230907, Neha Malcom Francis wrote:
> Sync k3-j721e DTS with kernel.org v6.5-rc1.
>
> Signed-off-by: Neha Malcom Francis
> ---
> .../k3-j721e-common-proc-board-u-boot.dtsi| 146 +--
> arch/arm/dts/k3-j721e-common-proc-board.dts | 483 ++---
> arch/arm/dts/k3-j721e-main.dtsi | 974 --
> arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 280 -
> .../arm/dts/k3-j721e-r5-common-proc-board.dts | 302 +-
> arch/arm/dts/k3-j721e-r5-sk.dts | 522 +-
> arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 177 +---
> arch/arm/dts/k3-j721e-sk.dts | 663 +---
> arch/arm/dts/k3-j721e-som-p0.dtsi | 226 ++--
> arch/arm/dts/k3-j721e-thermal.dtsi| 75 ++
> arch/arm/dts/k3-j721e.dtsi| 32 +-
> 11 files changed, 2365 insertions(+), 1515 deletions(-)
> create mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi
>
> diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> index 540c847eb3..4cca01be61 100644
> --- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> @@ -7,15 +7,7 @@
> #include "k3-j721e-binman.dtsi"
>
> / {
> - chosen {
> - stdout-path = "serial2:115200n8";
> - tick-timer =
> - };
> -
> aliases {
> - ethernet0 = _port1;
> - spi0 =
> - spi1 =
> remoteproc0 = _r5fss0_core0;
> remoteproc1 = _r5fss0_core1;
> remoteproc2 = _r5fss0_core0;
> @@ -25,61 +17,49 @@
> remoteproc6 = _0;
> remoteproc7 = _1;
> remoteproc8 = _0;
> - i2c0 = _i2c0;
> - i2c1 = _i2c0;
> - i2c2 = _i2c1;
> - i2c3 = _i2c0;
> };
As Manorit mentioned, drop the aliases
[...]
> diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
> b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
> index 7bb5ce775c..0452e94b6d 100644
> --- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
> @@ -12,16 +12,15 @@
> #include
What are you using from phy-cadence.h?
>
This file has:
* tps659413 -> Should come in from upstream kernel please.
* flash@0 -> are intentionally changing properties here? if so document
why - same with ospi nodes (reg)
* hbmc is still retained. Though the node is disabled in u-boot.dtsi
[...]
> diff --git a/arch/arm/dts/k3-j721e-r5-sk.dts b/arch/arm/dts/k3-j721e-r5-sk.dts
> index 1cc64d07f7..f5eb29a861 100644
> --- a/arch/arm/dts/k3-j721e-r5-sk.dts
> +++ b/arch/arm/dts/k3-j721e-r5-sk.dts
> @@ -11,151 +11,13 @@
> #include "k3-j721e-sk-u-boot.dtsi"
>
> / {
> - model = "Texas Instruments J721E SK R5";
> + chosen {
> + tick-timer = _timer0;
> + };
>
we have tps659412 defined here - should have come in from
upstream kernel.org
[...]
> flash@0{
please fix that space before {
> - compatible = "jedec,spi-nor";
> - reg = <0x0>;
> - spi-tx-bus-width = <8>;
> - spi-rx-bus-width = <8>;
> - spi-max-frequency = <2500>;
> - cdns,tshsl-ns = <60>;
> - cdns,tsd2d-ns = <60>;
> - cdns,tchsh-ns = <60>;
> - cdns,tslch-ns = <60>;
> - cdns,read-delay = <4>;
> cdns,phy-mode;
Why do we need this anymore?
> #address-cells = <1>;
> #size-cells = <1>;
> };
> };
[...]
> diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
> b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
> index 205dacff4d..e4bd71913c 100644
> --- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
> @@ -7,14 +7,7 @@
> #include "k3-j721e-binman.dtsi"
You dont need to include ti-dp83867.h anymore.
>
> / {
> - chosen {
> - stdout-path = "serial2:115200n8";
> - tick-timer =
> - };
> -
> aliases {
> - ethernet0 = _port1;
> - spi0 =
> remoteproc0 = _r5fss0_core0;
> remoteproc1 = _r5fss0_core1;
> remoteproc2 = _r5fss0_core0;
> @@ -24,61 +17,49 @@
> remoteproc6 = _0;
> remoteproc7 = _1;
> remoteproc8 = _0;
> - i2c0 = _i2c0;
> - i2c1 = _i2c0;
> - i2c2 = _i2c0;
> - mmc1 = _sdhci1; /* SD Card */
Same comment as before - drop all these aliases.
[...]
> +_ringacc {
> + reg = <0x0 0x2b80 0x0 0x40>,
> + <0x0 0x2b00 0x0 0x40>,
> + <0x0 0x2859 0x0 0x100>,
> + <0x0 0x2a50 0x0 0x4>,
> + <0x0 0x2844 0x0 0x4>;
> + reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
> + bootph-pre-ram;
> +};
>
> -
[PATCH] config: j7200: removed not needed power config
For J7200, R5/SPL TI_SCI_POWER_DOMAIN should be disabled as DM is a separate binary like other SOC of J7* family. Fixes: 02dff65efe7 (configs: j7200_evm_r5: Add initial support) Signed-off-by: Udit Kumar --- Boot logs https://gist.github.com/uditkumarti/04f053efa73eae8be53666d9a31033c2 configs/j7200_evm_r5_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig index 6d240b16cb..9e744ba434 100644 --- a/configs/j7200_evm_r5_defconfig +++ b/configs/j7200_evm_r5_defconfig @@ -126,7 +126,6 @@ CONFIG_SPL_PINCTRL=y # CONFIG_SPL_PINCTRL_GENERIC is not set CONFIG_PINCTRL_SINGLE=y CONFIG_POWER_DOMAIN=y -CONFIG_TI_SCI_POWER_DOMAIN=y CONFIG_TI_POWER_DOMAIN=y CONFIG_DM_PMIC=y CONFIG_PMIC_TPS65941=y -- 2.34.1
Re: [PATCH] ARM: dts: am335x-pocketbeagle: choose tick-timer
On 09:27-20230909, Trevor Woerner wrote:
> On Fri 2023-09-08 @ 12:36:17 PM, Nishanth Menon wrote:
> > On 11:25-20230830, Trevor Woerner wrote:
> > > Commit 4b2be78ab66c ("time: Fix get_ticks being non-monotonic")
> > > requires '/chosen/tick-timer' in device-tree. Otherwise we get:
> > >
> > > U-Boot 2023.07.02 (Jul 11 2023 - 15:20:44 +)
> > >
> > > CPU : AM335X-GP rev 2.1
> > > Model: TI AM335x PocketBeagle
> > > DRAM: 512 MiB
> > > Core: 154 devices, 16 uclasses, devicetree: separate
> > > Could not initialize timer (err -19)
> > >
> > > resetting ...
> > >
> > > Suggested-by: Pierre Lebleu
> > > Signed-off-by: Trevor Woerner
> > > ---
> > > arch/arm/dts/am335x-pocketbeagle.dts | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm/dts/am335x-pocketbeagle.dts
> > > b/arch/arm/dts/am335x-pocketbeagle.dts
> > > index b379e3a5570d..02e3aac56064 100644
> > > --- a/arch/arm/dts/am335x-pocketbeagle.dts
> > > +++ b/arch/arm/dts/am335x-pocketbeagle.dts
> > > @@ -15,6 +15,7 @@
> > >
> > > chosen {
> > > stdout-path =
> > > + tick-timer =
> > > };
> > >
> > > leds {
> > > --
> > > 2.41.0.327.gaa9166bcc0ba
> > >
> >
> > Does enabling CONFIG_SYS_ARCH_TIMER solve this?
[...]
> Getting the code to compile with CONFIG_SYS_ARCH_TIMER would require a deeper
> reworking of the configuration/Make logic in order to swap out the functions
> in arch/arm/mach-omap2/timer.c for the ones in
> arch/arm/cpu/armv7/arch_timer.c. The definitions of those functions in both
> those locations are quite different, so even after getting the build to work
> there's no guarantee the arch functions would work.
The difference is using SoC level dmtimer vs cpu level arch timer.
Either way, it will be good to send this upstream kernel.org.
Looking at the trm[1], it looks like arch timer isn't there for
cortex-a8?
[1] https://developer.arm.com/documentation/ddi0344/latest/
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 30/32] fdt: Allow the devicetree to come from a bloblist
Hi Ilias, On 9/11/23 09:56, Ilias Apalodimas wrote: Hi Michal, On Mon, 11 Sept 2023 at 09:38, Michal Simek wrote: On 9/11/23 08:17, Ilias Apalodimas wrote: Hi Simon, On Sun, 10 Sept 2023 at 22:14, Simon Glass wrote: Hi Ilias, On Mon, 4 Sept 2023 at 03:31, Ilias Apalodimas wrote: Hi Simon, On Fri, 1 Sept 2023 at 18:51, Simon Glass wrote: Hi Ilias, On Fri, 1 Sept 2023 at 01:50, Ilias Apalodimas wrote: [...] +config OF_BLOBLIST + bool "DTB is provided by a bloblist" + help + Select this to read the devicetree from the bloblist. This allows + using a bloblist to transfer the devicetree between U-Boot phases. + The devicetree is stored in the bloblist by an early phase so that + U-Boot can read it. + I dont think this is a good idea. We used to have 4-5 different options here, which we tried to clean up and ended up with two very discrete options. Why do we have to reintroduce a new one? Doesn't that bloblist have a header of some sort? The bloblist literally comes from a previous stage bootloader which is what OF_BOARD is here for. So why can't we just read the header and figure out if the magic of the bloblist matches? No, OF_BOARD is a hack to allow boards to do what they like with the FDT. This patch is a standard mechanism to pass the DT from one firmware phase to the next. We have spent quite a bit of time creating a spec for it, and we should use it. Where exactly am I objecting using the spec? Can you please re-read my email? I am actually pointing out we should use the spec *properly*. So instead of having a Kconfig option for the DT, which is pretty pointless, we should parse the bloblist. If the header defined by the *spec* is found, we should just search for the DT in there. What you are doing here, is take the spec, pick a very specific item that the list contains, and create a Kconfig option out of it. Which basically ignores the discoverable options of the bloblist. For example, that bloblist can also contain an entry to a TPM eventlog. Should we start creating Kconfig options for all the firmware handoff entries that are defined on that spec? OK so that is a different thing. What should it do if it expects to find a bloblist but cannot? I want it to throw an error, because I am trying to make the boot deterministic. What do you think? That's fine by me. You can even put that under IS_ENABLED for the bloblist inside the existing OF_BOARD check. So I was thinking - If no bloblist is required in Kconfig options we do the hacks we used to - if bloblist is selected and the config option is OF_BOARD, throw an error and mention that the previous stage loader should hand over a DT Is that what you had in mind? Yes, that sounds good to me. But I still think we need an OF_BLOBLIST option to control whether the devicetree comes from there. Otherwise we will end up with people using OF_BOARD to work around it. We also have the SPL case which does not pass the DT in a bloblist...in fact SPL typically doesn't even have the full DT. Wouldn't IS_ENABLED(BLOBLIST) || IS_ENABLED(SPL_BLOBLIST) be enough? Inside the OF_BOARD portion of the function, search for a bloblist if the option is enabled. If you can't find a bloblist and the DT within that bloblist, then error out Just my 2c here. I think all options should be possible to disable. It means I can imagine to disable u-boot not to take care about DT provided from previous stage. The same is for TPM event log. IMHO every stage should have an option to simply ignore data pass from previous stage. I don't really mind how it is done but there should be an option to by purpose say to ignore the part of pass data. That would be done by disabling BLOBLIST. I don't think having a Kconfig to say "I want a bloblist, but I only want the DT from there" is reasonable (or for any other item the bloblist can carry). OF_BOARD means the DT will come from a previous stage loader. If bloblist is enabled then the DT must come from there. I don't agree on this. If bloblist is enabled and DT is passed SW should have a freedom to ignore it. At start everything is likely in sync but later stages before U-Boot can stay at certain version but there could be a need to update u-boot where DT from previous stage could be broken. Regarding DT part. We are experimenting with TF-A injecting for example DDR memory reservation to DT. Injection is working properly if you are using single DT but in SOM case we are using FIT image with a lot of DTBs inside (issue with checksums calculation). I see couple of platforms (IIRC renesas/imx) which are using DT overlays and passing it via specific registers. For these using bloblist might be right way to go. Yes that's in fact the purpose of that spec. Good that I read it properly. Thanks, Michal
Re: [PATCH 1/7] rng: stm32: rename STM32 RNG driver
On Mon, Sep 11, 2023 at 10:27:38AM +0200, Grzegorz Szymaszek wrote:
> [...] Shouldn't the "depends on" be updated as well?
> ("depends on ARCH_STM32 || ARCH_STM32MP", like in STM32_RESET.)
Forgot to add:
Reviewed-by: Grzegorz Szymaszek
signature.asc
Description: PGP signature
[PATCH] configs: rockchip: rock-pi-s: use default bootdelay (2s)
align with other boards. Signed-off-by: FUKAUMI Naoki --- configs/rock-pi-s-rk3308_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/rock-pi-s-rk3308_defconfig b/configs/rock-pi-s-rk3308_defconfig index cc3274a98b..cd0a996ee7 100644 --- a/configs/rock-pi-s-rk3308_defconfig +++ b/configs/rock-pi-s-rk3308_defconfig @@ -24,7 +24,6 @@ CONFIG_DEBUG_UART=y CONFIG_ANDROID_BOOT_IMAGE=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -CONFIG_BOOTDELAY=0 CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_MAX_SIZE=0x2 -- 2.39.2
[PATCH 1/2] configs: rockchip: rk3308: use CONFIG_DEFAULT_FDT_FILE
all rk3308 boards should use their own dtb file. also, change fdt_addr_r to avoid following error: "ERROR: Did not find a cmdline Flattened Device Tree" it happens on Radxa ROCK Pi S (256MB/512MB) with kernel built from Radxa BSP. Signed-off-by: FUKAUMI Naoki --- configs/evb-rk3308_defconfig | 1 + configs/roc-cc-rk3308_defconfig| 1 + configs/rock-pi-s-rk3308_defconfig | 1 + include/configs/rk3308_common.h| 3 ++- 4 files changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/evb-rk3308_defconfig b/configs/evb-rk3308_defconfig index a13a809c1e..2c7ac88ed9 100644 --- a/configs/evb-rk3308_defconfig +++ b/configs/evb-rk3308_defconfig @@ -24,6 +24,7 @@ CONFIG_ANDROID_BOOT_IMAGE=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_BOOTDELAY=0 +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3308-evb.dtb" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_MAX_SIZE=0x2 diff --git a/configs/roc-cc-rk3308_defconfig b/configs/roc-cc-rk3308_defconfig index 9a789b212f..9cb90f6ee6 100644 --- a/configs/roc-cc-rk3308_defconfig +++ b/configs/roc-cc-rk3308_defconfig @@ -24,6 +24,7 @@ CONFIG_ANDROID_BOOT_IMAGE=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_BOOTDELAY=0 +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3308-roc-cc.dtb" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_MAX_SIZE=0x2 diff --git a/configs/rock-pi-s-rk3308_defconfig b/configs/rock-pi-s-rk3308_defconfig index cc3274a98b..e2abe4b4f7 100644 --- a/configs/rock-pi-s-rk3308_defconfig +++ b/configs/rock-pi-s-rk3308_defconfig @@ -25,6 +25,7 @@ CONFIG_ANDROID_BOOT_IMAGE=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_BOOTDELAY=0 +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3308-rock-pi-s.dtb" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_MAX_SIZE=0x2 diff --git a/include/configs/rk3308_common.h b/include/configs/rk3308_common.h index 7d55fcd975..a413af1bd4 100644 --- a/include/configs/rk3308_common.h +++ b/include/configs/rk3308_common.h @@ -16,11 +16,12 @@ #define ENV_MEM_LAYOUT_SETTINGS \ "scriptaddr=0x0050\0" \ "pxefile_addr_r=0x0060\0" \ - "fdt_addr_r=0x0280\0" \ + "fdt_addr_r=0x03e0\0" \ "kernel_addr_r=0x0068\0" \ "ramdisk_addr_r=0x0400\0" #define CFG_EXTRA_ENV_SETTINGS \ + "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ ENV_MEM_LAYOUT_SETTINGS \ "partitions=" PARTS_DEFAULT \ ROCKCHIP_DEVICE_SETTINGS \ -- 2.39.2
[PATCH 2/2] configs: rockchip: rk3308: enable CONFIG_OF_LIBFDT_OVERLAY
enable CONFIG_OF_LIBFDT_OVERLAY and use it on Radxa ROCK Pi S. Signed-off-by: FUKAUMI Naoki --- configs/rock-pi-s-rk3308_defconfig | 1 + include/configs/rk3308_common.h| 1 + 2 files changed, 2 insertions(+) diff --git a/configs/rock-pi-s-rk3308_defconfig b/configs/rock-pi-s-rk3308_defconfig index e2abe4b4f7..ca4a1800e7 100644 --- a/configs/rock-pi-s-rk3308_defconfig +++ b/configs/rock-pi-s-rk3308_defconfig @@ -9,6 +9,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80 CONFIG_DEFAULT_DEVICE_TREE="rk3308-rock-pi-s" +CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_ROCKCHIP_RK3308=y CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x0 diff --git a/include/configs/rk3308_common.h b/include/configs/rk3308_common.h index a413af1bd4..861154fbeb 100644 --- a/include/configs/rk3308_common.h +++ b/include/configs/rk3308_common.h @@ -17,6 +17,7 @@ "scriptaddr=0x0050\0" \ "pxefile_addr_r=0x0060\0" \ "fdt_addr_r=0x03e0\0" \ + "fdtoverlay_addr_r=0x03f0\0" \ "kernel_addr_r=0x0068\0" \ "ramdisk_addr_r=0x0400\0" -- 2.39.2
Re: [PATCH 1/7] rng: stm32: rename STM32 RNG driver
On 9/11/23 10:27, Grzegorz Szymaszek wrote:
Hi,
On Thu, Sep 07, 2023 at 06:21:54PM +0200, Gatien Chevallier wrote:
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
-%<-
-config RNG_STM32MP1
- bool "Enable random number generator for STM32MP1"
+config RNG_STM32
+ bool "Enable random number generator for STM32"
depends on ARCH_STM32MP
Shouldn't the "depends on" be updated as well?
("depends on ARCH_STM32 || ARCH_STM32MP", like in STM32_RESET.)
Hi Grzegorz,
I agree, this could be used for MCUs so I'll add ARCH_STM32.
Heinrich, Patrick, can I keep your tag while adding this?
Best regards,
Gatien
All the best
Re: [PATCH 7/7] ARM: dts: stm32: add RNG node for STM32MP13x platforms
Hi,
On 9/7/23 18:22, Gatien Chevallier wrote:
Add RNG node for STM32MP13x platforms.
Signed-off-by: Gatien Chevallier
---
arch/arm/dts/stm32mp131.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index d23bbc3639..bd7285053d 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -1208,6 +1208,14 @@
};
};
+ rng: rng@54004000 {
+ compatible = "st,stm32mp13-rng";
+ reg = <0x54004000 0x400>;
+ clocks = < RNG1_K>;
+ resets = < RNG1_R>;
+ status = "disabled";
+ };
+
mdma: dma-controller@5800 {
compatible = "st,stm32h7-mdma";
reg = <0x5800 0x1000>;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 6/7] rng: stm32: Implement custom RNG configuration support
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: STM32 RNG configuration should best fit the requirements of the platform. Therefore, put a platform-specific RNG configuration field in the platform data. Default RNG configuration for STM32MP13 is the NIST certified configuration [1]. While there, fix and the RNG init sequence to support all RNG versions. [1] https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/53 Signed-off-by: Gatien Chevallier --- drivers/rng/stm32_rng.c | 54 ++--- 1 file changed, 51 insertions(+), 3 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 5/7] rng: stm32: add error concealment sequence
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: Seed errors can occur when using the hardware RNG. Implement the sequences to handle them. This avoids irrecoverable RNG state. Try to conceal seed errors when possible. If, despite the error concealing tries, a seed error is still present, then return an error. A clock error does not compromise the hardware block and data can still be read from RNG_DR. Just warn that the RNG clock is too slow and clear RNG_SR. Signed-off-by: Gatien Chevallier --- drivers/rng/stm32_rng.c | 163 ++-- 1 file changed, 140 insertions(+), 23 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH v2 1/2] rockchip: Kconfig: Enable external TPL binary for rk3308
hi, On 9/9/23 18:33, Massimo Pegorer wrote: There is no support to initialize DRAM on rk3308 SoC using U-Boot TPL or SPL, and therefore an external TPL binary must be used to package a bootable u-boot-rockchip.bin image. Default ROCKCHIP_EXTERNAL_TPL to yes if ROCKCHIP_RK3308. Remove useless TPL_SERIAL. Signed-off-by: Massimo Pegorer --- arch/arm/mach-rockchip/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Tested-by: FUKAUMI Naoki thank you very much for your work! diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index a279582f4f..3b044269bd 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -166,7 +166,6 @@ config ROCKCHIP_RK3308 imply SPL_SYSCON imply SPL_RAM imply SPL_SERIAL - imply TPL_SERIAL imply SPL_SEPARATE_BSS help The Rockchip RK3308 is a ARM-based Soc which embedded with quad @@ -436,7 +435,7 @@ config TPL_ROCKCHIP_COMMON_BOARD config ROCKCHIP_EXTERNAL_TPL bool "Use external TPL binary" - default y if ROCKCHIP_RK3568 || ROCKCHIP_RK3588 + default y if ROCKCHIP_RK3308 || ROCKCHIP_RK3568 || ROCKCHIP_RK3588 help Some Rockchip SoCs require an external TPL to initialize DRAM. Enable this option and build with ROCKCHIP_TPL=/path/to/ddr.bin to
Re: [PATCH 4/7] rng: stm32: add RNG clock frequency restraint
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: In order to ensure a good RNG quality and compatibility with certified RNG configuration, add RNG clock frequency restraint. Signed-off-by: Gatien Chevallier --- drivers/rng/stm32_rng.c | 43 - 1 file changed, 38 insertions(+), 5 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 3/7] rng: stm32: Implement configurable RNG clock error detection
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: RNG clock error detection is now enabled if the "clock-error-detect" property is set in the device tree. Signed-off-by: Gatien Chevallier --- drivers/rng/stm32_rng.c | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 2/7] configs: default activate CONFIG_RNG_STM32 for STM32MP13x platforms
On 9/8/23 20:58, Heinrich Schuchardt wrote: On 9/7/23 18:21, Gatien Chevallier wrote: Default embed this configuration. If OP-TEE PTA RNG is present as well, the priority will be given to it instead of the U-Boot driver. Are you relying here on drivers being probed in alphabetical sequence? Best regards Heinrich Hello Heinrich, I've made a strange wording here. OP-TEE RNG PTA shouldn't be exposed if the RNG is non-secure as it shouldn't be handled by the secure world. If it is, it is a bad OP-TEE configuration. On the contrary, if the RNG OPTEE PTA is exposed, then the OP-TEE RNG PTA should be used. Therefore, the RNG node status shouldn't be set to "okay" in U-boot's device tree. Hope this solves the confusion, I'll reword the sentence. Best regards, Gatien Signed-off-by: Gatien Chevallier --- configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index 82b62744f6..4a899c85de 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -65,6 +65,7 @@ CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_SCMI=y CONFIG_RESET_SCMI=y CONFIG_DM_RNG=y +CONFIG_RNG_STM32=y CONFIG_DM_RTC=y CONFIG_RTC_STM32=y CONFIG_SERIAL_RX_BUFFER=y
Re: [PATCH 2/7] configs: default activate CONFIG_RNG_STM32 for STM32MP13x platforms
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: Default embed this configuration. If OP-TEE PTA RNG is present as well, the priority will be given to it instead of the U-Boot driver. The STM32 RNG driver will be probed when the is activated in U-Boot device tree, it is avaiable for non secure world. OP-TEE RNG PTA will be registered when the RNG access is liited to secure world by firewall. For me not priority here but secure/non secure configuration, managed by device tree. Signed-off-by: Gatien Chevallier --- configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index 82b62744f6..4a899c85de 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -65,6 +65,7 @@ CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_SCMI=y CONFIG_RESET_SCMI=y CONFIG_DM_RNG=y +CONFIG_RNG_STM32=y CONFIG_DM_RTC=y CONFIG_RTC_STM32=y CONFIG_SERIAL_RX_BUFFER=y with commit message update Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 1/7] rng: stm32: rename STM32 RNG driver
Hi,
On 9/7/23 18:21, Gatien Chevallier wrote:
Rename the RNG driver as it is usable by other STM32 platforms
than the STM32MP1x ones. Rename CONFIG_RNG_STM32MP1 to
CONFIG_RNG_STM32
Signed-off-by: Gatien Chevallier
---
MAINTAINERS | 2 +-
configs/stm32mp15_basic_defconfig | 2 +-
configs/stm32mp15_defconfig | 2 +-
configs/stm32mp15_trusted_defconfig | 2 +-
drivers/rng/Kconfig | 6 +++---
drivers/rng/Makefile| 2 +-
drivers/rng/{stm32mp1_rng.c => stm32_rng.c} | 0
7 files changed, 8 insertions(+), 8 deletions(-)
rename drivers/rng/{stm32mp1_rng.c => stm32_rng.c} (100%)
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 3/7] rng: stm32: Implement configurable RNG clock error detection
Hi,
On 9/8/23 21:07, Heinrich Schuchardt wrote:
On 9/7/23 18:21, Gatien Chevallier wrote:
RNG clock error detection is now enabled if the "clock-error-detect"
property is set in the device tree.
Signed-off-by: Gatien Chevallier
---
drivers/rng/stm32_rng.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index 89da78c6c8..ada5d92214 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -40,6 +40,7 @@ struct stm32_rng_plat {
struct clk clk;
struct reset_ctl rst;
const struct stm32_rng_data *data;
+ bool ced;
};
static int stm32_rng_read(struct udevice *dev, void *data, size_t len)
@@ -97,25 +98,34 @@ static int stm32_rng_init(struct stm32_rng_plat
*pdata)
cr = readl(pdata->base + RNG_CR);
- /* Disable CED */
- cr |= RNG_CR_CED;
if (pdata->data->has_cond_reset) {
cr |= RNG_CR_CONDRST;
+ if (pdata->ced)
+ cr &= ~RNG_CR_CED;
+ else
+ cr |= RNG_CR_CED;
writel(cr, pdata->base + RNG_CR);
cr &= ~RNG_CR_CONDRST;
+ cr |= RNG_CR_RNGEN;
writel(cr, pdata->base + RNG_CR);
err = readl_poll_timeout(pdata->base + RNG_CR, cr,
(!(cr & RNG_CR_CONDRST)), 1);
if (err)
return err;
+ } else {
+ if (pdata->ced)
+ cr &= ~RNG_CR_CED;
+ else
+ cr |= RNG_CR_CED;
+
+ cr |= RNG_CR_RNGEN;
+
+ writel(cr, pdata->base + RNG_CR);
}
/* clear error indicators */
writel(0, pdata->base + RNG_SR);
- cr |= RNG_CR_RNGEN;
- writel(cr, pdata->base + RNG_CR);
-
err = readl_poll_timeout(pdata->base + RNG_SR, sr,
sr & RNG_SR_DRDY, 1);
return err;
@@ -165,6 +175,8 @@ static int stm32_rng_of_to_plat(struct udevice *dev)
if (err)
return err;
+ pdata->ced = dev_read_bool(dev, "clock-error-detect");
The kernel describes this property in
Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
Which patch is adding it to the U-Boot device-trees?
I can't find it in this patch series.
For STM32 platform we rely on the bindin files of kernel to avoid to
duplicate the binding after yaml migration
and we add the U-Boot specificity only when it is needed (for clock and ram)
See Documentation:
https://u-boot.readthedocs.io/en/stable/board/st/st-dt.html
doc/board/st/st-dt.rst
* rng
- rng/st,stm32-rng.yaml
So for me no need of binding patch in U-Boot since [1] as this property
is already supported by kernel binding.
[1] 551a959a8c11 ("doc: stm32mp1: add page for device tree bindings")
http://patchwork.ozlabs.org/project/uboot/patch/20210802180823.1.I3aa79d907e5213c8692d2d428f5a1fbccdce555b@changeid/
Patrick
It would have been helpful to send a cover-letter with the patch series
to get an overview of the changed files in the patch set.
Best regards
Heinrich
+
return 0;
}
Re: [PATCH 1/7] rng: stm32: rename STM32 RNG driver
Hi,
On Thu, Sep 07, 2023 at 06:21:54PM +0200, Gatien Chevallier wrote:
> diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> -%<-
> -config RNG_STM32MP1
> - bool "Enable random number generator for STM32MP1"
> +config RNG_STM32
> + bool "Enable random number generator for STM32"
> depends on ARCH_STM32MP
Shouldn't the "depends on" be updated as well?
("depends on ARCH_STM32 || ARCH_STM32MP", like in STM32_RESET.)
All the best
--
Grzegorz Szymaszek
signature.asc
Description: PGP signature
Re: [PATCH 30/32] fdt: Allow the devicetree to come from a bloblist
Hi Michal, On Mon, 11 Sept 2023 at 09:38, Michal Simek wrote: > > > > On 9/11/23 08:17, Ilias Apalodimas wrote: > > Hi Simon, > > > > On Sun, 10 Sept 2023 at 22:14, Simon Glass wrote: > >> > >> Hi Ilias, > >> > >> On Mon, 4 Sept 2023 at 03:31, Ilias Apalodimas > >> wrote: > >>> > >>> Hi Simon, > >>> > >>> On Fri, 1 Sept 2023 at 18:51, Simon Glass wrote: > > Hi Ilias, > > On Fri, 1 Sept 2023 at 01:50, Ilias Apalodimas > wrote: > > > > [...] > > > >>> > +config OF_BLOBLIST > + bool "DTB is provided by a bloblist" > + help > + Select this to read the devicetree from the bloblist. This > allows > + using a bloblist to transfer the devicetree between U-Boot > phases. > + The devicetree is stored in the bloblist by an early phase > so that > + U-Boot can read it. > + > >>> > >>> I dont think this is a good idea. We used to have 4-5 different > >>> options > >>> here, which we tried to clean up and ended up with two very discrete > >>> options. Why do we have to reintroduce a new one? Doesn't that > >>> bloblist > >>> have a header of some sort? The bloblist literally comes from a > >>> previous > >>> stage bootloader which is what OF_BOARD is here for. So why can't we > >>> just > >>> read the header and figure out if the magic of the bloblist matches? > >> > >> No, OF_BOARD is a hack to allow boards to do what they like with the > >> FDT. > >> > >> This patch is a standard mechanism to pass the DT from one firmware > >> phase to the next. We have spent quite a bit of time creating a spec > >> for it, and we should use it. > > > > Where exactly am I objecting using the spec? Can you please re-read > > my email? > > I am actually pointing out we should use the spec *properly*. So > > instead of having a Kconfig option for the DT, which is pretty > > pointless, we should parse the bloblist. If the header defined by > > the *spec* is found, we should just search for the DT in there. > > What you are doing here, is take the spec, pick a very specific item > > that the list contains, and create a Kconfig option out of it. Which > > basically ignores the discoverable options of the bloblist. For > > example, that bloblist can also contain an entry to a TPM eventlog. > > Should we start creating Kconfig options for all the firmware handoff > > entries that are defined on that spec? > > OK so that is a different thing. What should it do if it expects to find > a bloblist but cannot? I want it to throw an error, because I am trying > to make the boot deterministic. What do you think? > >>> > >>> That's fine by me. You can even put that under IS_ENABLED for the > >>> bloblist inside the existing OF_BOARD check. So I was thinking > >>> - If no bloblist is required in Kconfig options we do the hacks we used to > >>> - if bloblist is selected and the config option is OF_BOARD, throw an > >>> error and mention that the previous stage loader should hand over a DT > >>> > >>> Is that what you had in mind? > >> > >> Yes, that sounds good to me. > >> > >> But I still think we need an OF_BLOBLIST option to control whether the > >> devicetree comes from there. > >> Otherwise we will end up with people > >> using OF_BOARD to work around it. We also have the SPL case which does > >> not pass the DT in a bloblist...in fact SPL typically doesn't even > >> have the full DT. > > > > Wouldn't IS_ENABLED(BLOBLIST) || IS_ENABLED(SPL_BLOBLIST) be enough? > > Inside the OF_BOARD portion of the function, search for a bloblist if > > the option is enabled. If you can't find a bloblist and the DT within > > that bloblist, then error out > > Just my 2c here. > I think all options should be possible to disable. It means I can imagine to > disable u-boot not to take care about DT provided from previous stage. The > same > is for TPM event log. IMHO every stage should have an option to simply ignore > data pass from previous stage. I don't really mind how it is done but there > should be an option to by purpose say to ignore the part of pass data. That would be done by disabling BLOBLIST. I don't think having a Kconfig to say "I want a bloblist, but I only want the DT from there" is reasonable (or for any other item the bloblist can carry). OF_BOARD means the DT will come from a previous stage loader. If bloblist is enabled then the DT must come from there. > > Regarding DT part. We are experimenting with TF-A injecting for example DDR > memory reservation to DT. > Injection is working properly if you are using single DT but in SOM case we > are > using FIT image with a lot of DTBs inside (issue with checksums calculation). > I see couple of platforms (IIRC renesas/imx) which are using DT overlays
Re: [PATCH v3 13/13] test: dm: add scmi command test
On Fri, Sep 08, 2023 at 02:27:15PM +, Etienne CARRIERE wrote:
> > From: AKASHI Takahiro
> > Sent: Friday, September 8, 2023 04:51
> >
> > In this test, "scmi" command is tested against different sub-commands.
> > Please note that scmi command is for debug purpose and is not intended
> > in production system.
> >
> > Signed-off-by: AKASHI Takahiro
> > Reviewed-by: Simon Glass
> > Reviewed-by: Etienne Carriere
> > ---
> > v3
> > * change char to u8 in vendor/agent names
> > v2
> > * use helper functions, removing direct uses of ops
> > ---
>
> This change breaks pytest ut_dm_dm_test_scmi_cmd.
> CONFIG_CMD_SCMI=y is missing in sandbox_defconfig.
Sure.
>
> > test/dm/scmi.c | 62 ++
> > 1 file changed, 57 insertions(+), 5 deletions(-)
> >
> > diff --git a/test/dm/scmi.c b/test/dm/scmi.c
> > index 0785948186f0..423b6ef70b29 100644
> > --- a/test/dm/scmi.c
> > +++ b/test/dm/scmi.c
> > @@ -104,8 +104,7 @@ static int dm_test_scmi_base(struct unit_test_state
> > *uts)
> > struct scmi_agent_priv *priv;
> > u32 version, num_agents, num_protocols, impl_version;
> > u32 attributes, agent_id;
> > - char *vendor, *agent_name;
> > - u8 *protocols;
> > + u8 *vendor, *agent_name, *protocols;
>
> Could you squash these fixups into patch 10/13
> ("test: dm: add SCMI base protocol test") unlesswhat that patch
> makes sandbox test build to fail.
Okay.
> > int ret;
> >
> > /* preparation */
> > @@ -134,9 +133,9 @@ static int dm_test_scmi_base(struct unit_test_state
> > *uts)
> > free(vendor);
> >
> > /* message attributes */
> > - ret = scmi_protocol_message_attrs(base,
> > - SCMI_BASE_DISCOVER_SUB_VENDOR,
> > - );
> > + ret = scmi_base_protocol_message_attrs(base,
> > +
> > SCMI_BASE_DISCOVER_SUB_VENDOR,
> > + );
>
> Same here.
Yes.
-Takahiro Akashi
> BR,
> etienne
>
> > ut_assertok(ret);
> > ut_assertok(attributes);
> >
> > @@ -207,6 +206,59 @@ static int dm_test_scmi_base(struct unit_test_state
> > *uts)
> >
> > DM_TEST(dm_test_scmi_base, UT_TESTF_SCAN_FDT);
> >
> > +static int dm_test_scmi_cmd(struct unit_test_state *uts)
> > +{
> > + struct udevice *agent_dev;
> > +
> > + /* preparation */
> > + ut_assertok(uclass_get_device_by_name(UCLASS_SCMI_AGENT, "scmi",
> > + _dev));
> > + ut_assertnonnull(agent_dev);
> > +
> > + /* scmi info */
> > + ut_assertok(run_command("scmi info", 0));
> > +
> > + ut_assert_nextline("SCMI device: scmi");
> > + ut_assert_nextline(" protocol version: 0x2");
> > + ut_assert_nextline(" # of agents: 2");
> > + ut_assert_nextline(" 0: platform");
> > + ut_assert_nextline(" > 1: OSPM");
> > + ut_assert_nextline(" # of protocols: 3");
> > + ut_assert_nextline(" Clock management");
> > + ut_assert_nextline(" Reset domain management");
> > + ut_assert_nextline(" Voltage domain management");
> > + ut_assert_nextline(" vendor: U-Boot");
> > + ut_assert_nextline(" sub vendor: Sandbox");
> > + ut_assert_nextline(" impl version: 0x1");
> > +
> > + ut_assert_console_end();
> > +
> > + /* scmi perm_dev */
> > + ut_assertok(run_command("scmi perm_dev 1 0 1", 0));
> > + ut_assert_console_end();
> > +
> > + ut_assert(run_command("scmi perm_dev 1 0 0", 0));
> > + ut_assert_nextline("Denying access to device:0 failed (-13)");
> > + ut_assert_console_end();
> > +
> > + /* scmi perm_proto */
> > + ut_assertok(run_command("scmi perm_proto 1 0 14 1", 0));
> > + ut_assert_console_end();
> > +
> > + ut_assert(run_command("scmi perm_proto 1 0 14 0", 0));
> > + ut_assert_nextline("Denying access to protocol:0x14 on device:0
> > failed (-13)");
> > + ut_assert_console_end();
> > +
> > + /* scmi reset */
> > + ut_assert(run_command("scmi reset 1 1", 0));
> > + ut_assert_nextline("Reset failed (-13)");
> > + ut_assert_console_end();
> > +
> > + return 0;
> > +}
> > +
> > +DM_TEST(dm_test_scmi_cmd, UT_TESTF_SCAN_FDT);
> > +
> > static int dm_test_scmi_clocks(struct unit_test_state *uts)
> > {
> > struct sandbox_scmi_agent *agent;
> > --
> > 2.34.1
> >
Re: [PATCH v3 05/13] firmware: scmi: install base protocol to SCMI agent
On Fri, Sep 08, 2023 at 02:02:22PM +, Etienne CARRIERE wrote:
> Hello Akashi-san,
>
> Some minor comments.
>
> > From: AKASHI Takahiro
> > Sent: Friday, September 8, 2023 04:51
> >
> > SCMI base protocol is mandatory, and once SCMI node is found in a device
> > tree, the protocol handle (udevice) is unconditionally installed to
> > the agent. Then basic information will be retrieved from SCMI server via
> > the protocol and saved into the agent instance's local storage.
> >
> > Signed-off-by: AKASHI Takahiro
> > Reviewed-by: Simon Glass
> > Reviewed-by: Etienne Carriere
> > ---
> > v3
> > * typo fix: add '@' for argument name in function description
> > * eliminate dev_get_uclass_plat()'s repeated in inline
> > * modify the code for dynamically allocated sub-vendor/agent names
> > v2
> > * use helper functions, removing direct uses of ops
> > ---
> > drivers/firmware/scmi/scmi_agent-uclass.c | 116 ++
> > include/scmi_agent-uclass.h | 66
> > 2 files changed, 182 insertions(+)
> >
> > diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
> > b/drivers/firmware/scmi/scmi_agent-uclass.c
> > index e823d105a3eb..87a667d60124 100644
> > --- a/drivers/firmware/scmi/scmi_agent-uclass.c
> > +++ b/drivers/firmware/scmi/scmi_agent-uclass.c
> > @@ -57,6 +57,9 @@ struct udevice *scmi_get_protocol(struct udevice *dev,
> > }
> >
> > switch (id) {
> > + case SCMI_PROTOCOL_ID_BASE:
> > + proto = priv->base_dev;
> > + break;
> > case SCMI_PROTOCOL_ID_CLOCK:
> > proto = priv->clock_dev;
> > break;
> > @@ -101,6 +104,9 @@ static int scmi_add_protocol(struct udevice *dev,
> > }
> >
> > switch (proto_id) {
> > + case SCMI_PROTOCOL_ID_BASE:
> > + priv->base_dev = proto;
> > + break;
> > case SCMI_PROTOCOL_ID_CLOCK:
> > priv->clock_dev = proto;
> > break;
> > @@ -237,6 +243,83 @@ int devm_scmi_process_msg(struct udevice *dev, struct
> > scmi_msg *msg)
> > return scmi_process_msg(protocol->parent, priv->channel, msg);
> > }
> >
> > +/**
> > + * scmi_fill_base_info - get base information about SCMI server
> > + * @agent: SCMI agent device
> > + * @dev: SCMI protocol device
> > + *
> > + * By using Base protocol commands, collect the base information
> > + * about SCMI server.
> > + *
> > + * Return: 0 on success, error code otherwise
> > + */
> > +static int scmi_fill_base_info(struct udevice *agent, struct udevice *dev)
> > +{
> > + struct scmi_agent_priv *priv = dev_get_uclass_plat(agent);
> > + int ret;
> > +
> > + ret = scmi_base_protocol_version(dev, >version);
> > + if (ret) {
> > + dev_err(dev, "protocol_version() failed (%d)\n", ret);
> > + return ret;
> > + }
> > + /* check for required version */
> > + if (priv->version < SCMI_BASE_PROTOCOL_VERSION) {
> > + dev_err(dev, "base protocol version (%d) lower than
> > expected\n",
> > + priv->version);
> > + return -EPROTO;
> > + }
> > +
> > + ret = scmi_base_protocol_attrs(dev, >num_agents,
> > + >num_protocols);
> > + if (ret) {
> > + dev_err(dev, "protocol_attrs() failed (%d)\n", ret);
> > + return ret;
> > + }
> > + ret = scmi_base_discover_vendor(dev, >vendor);
> > + if (ret) {
> > + dev_err(dev, "base_discover_vendor() failed (%d)\n", ret);
> > + return ret;
> > + }
> > + ret = scmi_base_discover_sub_vendor(dev, >sub_vendor);
> > + if (ret) {
> > + if (ret != -EOPNOTSUPP) {
> > + dev_err(dev, "base_discover_sub_vendor() failed
> > (%d)\n",
> > + ret);
> > + return ret;
> > + }
> > + priv->sub_vendor = "NA";
> > + }
> > + ret = scmi_base_discover_impl_version(dev, >impl_version);
> > + if (ret) {
> > + dev_err(dev, "base_discover_impl_version() failed (%d)\n",
> > + ret);
> > + return ret;
> > + }
> > +
> > + priv->agent_id = 0x; /* to avoid false claim */
>
> I think this line should move in below instruction block, next to
> priv->agent_name = "NA", for consistency,
Yeah. Move it there.
> > + ret = scmi_base_discover_agent(dev, 0x,
> > + >agent_id, >agent_name);
> > + if (ret) {
> > + if (ret != -EOPNOTSUPP) {
> > + dev_err(dev,
> > + "base_discover_agent() failed for myself
> > (%d)\n",
> > + ret);
> > + return ret;
> > + }
> > +
Re: [PATCH v3 04/13] firmware: scmi: framework for installing additional protocols
On Fri, Sep 08, 2023 at 02:01:52PM +, Etienne CARRIERE wrote:
>
> > From: AKASHI Takahiro
> > Sent: Friday, September 8, 2023 04:51
> >
> > This framework allows SCMI protocols to be installed and bound to the agent
> > so that the agent can manage and utilize them later.
> >
> > Signed-off-by: AKASHI Takahiro
> > Reviewed-by: Simon Glass
> > Reviewed-by: Etienne Carriere
> > ---
> > v3
> > * move "per_device_plat_auto" from a earlier patch
> > * fix comments in "scmi_agent_priv"
> > * modify an order of include files in scmi_agent.h
> > v2
> > * check for availability of protocols
> > ---
> > drivers/firmware/scmi/scmi_agent-uclass.c | 101 +-
> > include/scmi_agent-uclass.h | 15 +++-
> > include/scmi_agent.h | 14 +++
> > 3 files changed, 126 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
> > b/drivers/firmware/scmi/scmi_agent-uclass.c
> > index 94e54eeb066b..e823d105a3eb 100644
> > --- a/drivers/firmware/scmi/scmi_agent-uclass.c
> > +++ b/drivers/firmware/scmi/scmi_agent-uclass.c
> > @@ -38,6 +38,86 @@ static const struct error_code scmi_linux_errmap[] = {
> > { .scmi = SCMI_PROTOCOL_ERROR, .errno = -EPROTO, },
> > };
> >
> > +/*
> > + * NOTE: The only one instance should exist according to
> > + * the current specification and device tree bindings.
> > + */
> > +struct udevice *scmi_agent;
> > +
> > +struct udevice *scmi_get_protocol(struct udevice *dev,
> > + enum scmi_std_protocol id)
> > +{
> > + struct scmi_agent_priv *priv;
> > + struct udevice *proto;
> > +
> > + priv = dev_get_uclass_plat(dev);
> > + if (!priv) {
> > + dev_err(dev, "No priv data found\n");
> > + return NULL;
> > + }
> > +
> > + switch (id) {
> > + case SCMI_PROTOCOL_ID_CLOCK:
> > + proto = priv->clock_dev;
> > + break;
> > + case SCMI_PROTOCOL_ID_RESET_DOMAIN:
> > + proto = priv->resetdom_dev;
> > + break;
> > + case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
> > + proto = priv->voltagedom_dev;
> > + break;
> > + default:
> > + dev_err(dev, "Protocol not supported\n");
> > + proto = NULL;
> > + break;
> > + }
> > + if (proto && device_probe(proto))
> > + dev_err(dev, "Probe failed\n");
> > +
> > + return proto;
> > +}
> > +
> > +/**
> > + * scmi_add_protocol - add protocol to agent
> > + * @dev: SCMI agent device
> > + * @proto_id: SCMI protocol ID
> > + * @proto: SCMI protocol device
> > + *
> > + * Associate the protocol instance, @proto, to the agent, @dev,
> > + * for later use.
> > + *
> > + * Return: 0 on success, error code otherwise
> > + */
> > +static int scmi_add_protocol(struct udevice *dev,
> > + enum scmi_std_protocol proto_id,
> > + struct udevice *proto)
> > +{
> > + struct scmi_agent_priv *priv;
> > +
> > + priv = dev_get_uclass_plat(dev);
> > + if (!priv) {
> > + dev_err(dev, "No priv data found\n");
> > + return -ENODEV;
> > + }
> > +
> > + switch (proto_id) {
> > + case SCMI_PROTOCOL_ID_CLOCK:
> > + priv->clock_dev = proto;
> > + break;
> > + case SCMI_PROTOCOL_ID_RESET_DOMAIN:
> > + priv->resetdom_dev = proto;
> > + break;
> > + case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
> > + priv->voltagedom_dev = proto;
> > + break;
> > + default:
> > + dev_err(dev, "Protocol not supported\n");
> > + return -EPROTO;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > int scmi_to_linux_errno(s32 scmi_code)
> > {
> > int n;
> > @@ -164,12 +244,14 @@ int devm_scmi_process_msg(struct udevice *dev, struct
> > scmi_msg *msg)
> > */
> > static int scmi_bind_protocols(struct udevice *dev)
> > {
> > + struct udevice *agent;
>
> nit: my build reported 'agent' here is not used in the scope of this patch.
> Strictly speaking, it should be brought by patch v3 05/13.
> ("firmware: scmi: install base protocol to SCMI agent")
You're right.
I will move this variable declaration to patch#5.
-Takahiro Akashi
> BR,
> etienne
>
> > (snip)
Re: [PATCH v3 01/13] scmi: refactor the code to hide a channel from devices
Hi Etienne,
Thank you gain for your review.
On Fri, Sep 08, 2023 at 02:01:51PM +, Etienne CARRIERE wrote:
> Hello Akashi-san,
>
> >
> > From: AKASHI Takahiro
> > Sent: Friday, September 8, 2023 04:51
> >
> > The commit 85dc58289238 ("firmware: scmi: prepare uclass to pass channel
> > reference") added an explicit parameter, channel, but it seems to make
> > the code complex.
> >
> > Hiding this parameter will allow for adding a generic (protocol-agnostic)
> > helper function, i.e. for PROTOCOL_VERSION, in a later patch.
> >
> > Signed-off-by: AKASHI Takahiro
> > Reviewed-by: Simon Glass
> > ---
> > v3
> > * fix an issue on ST board (reported by Etienne)
> > by taking care of cases where probed devices are children of
> > SCMI protocol device (i.e. clock devices under CCF)
> > See find_scmi_protocol_device().
> > * move "per_device_plato_auto" to a succeeding right patch
> > v2
> > * new patch
> > ---
> > drivers/clk/clk_scmi.c | 27 +---
> > drivers/firmware/scmi/scmi_agent-uclass.c | 160 +++---
> > drivers/power/regulator/scmi_regulator.c | 27 +---
> > drivers/reset/reset-scmi.c | 19 +--
> > include/scmi_agent.h | 15 +-
> > 5 files changed, 103 insertions(+), 145 deletions(-)
> >
> > diff --git a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c
> > index d172fed24c9d..34a49363a51a 100644
> > --- a/drivers/clk/clk_scmi.c
> > +++ b/drivers/clk/clk_scmi.c
> > @@ -13,17 +13,8 @@
> > #include
> > #include
> >
> > -/**
> > - * struct scmi_clk_priv - Private data for SCMI clocks
> > - * @channel: Reference to the SCMI channel to use
> > - */
> > -struct scmi_clk_priv {
> > - struct scmi_channel *channel;
> > -};
> > -
> > static int scmi_clk_get_num_clock(struct udevice *dev, size_t *num_clocks)
> > {
> > - struct scmi_clk_priv *priv = dev_get_priv(dev);
> > struct scmi_clk_protocol_attr_out out;
> > struct scmi_msg msg = {
> > .protocol_id = SCMI_PROTOCOL_ID_CLOCK,
> > @@ -33,7 +24,7 @@ static int scmi_clk_get_num_clock(struct udevice *dev,
> > size_t *num_clocks)
> > };
> > int ret;
> >
> > - ret = devm_scmi_process_msg(dev, priv->channel, );
> > + ret = devm_scmi_process_msg(dev, );
> > if (ret)
> > return ret;
> >
> > @@ -44,7 +35,6 @@ static int scmi_clk_get_num_clock(struct udevice *dev,
> > size_t *num_clocks)
> >
> > static int scmi_clk_get_attibute(struct udevice *dev, int clkid, char
> > **name)
> > {
> > - struct scmi_clk_priv *priv = dev_get_priv(dev);
> > struct scmi_clk_attribute_in in = {
> > .clock_id = clkid,
> > };
> > @@ -59,7 +49,7 @@ static int scmi_clk_get_attibute(struct udevice *dev, int
> > clkid, char **name)
> > };
> > int ret;
> >
> > - ret = devm_scmi_process_msg(dev, priv->channel, );
> > + ret = devm_scmi_process_msg(dev, );
> > if (ret)
> > return ret;
> >
> > @@ -70,7 +60,6 @@ static int scmi_clk_get_attibute(struct udevice *dev, int
> > clkid, char **name)
> >
> > static int scmi_clk_gate(struct clk *clk, int enable)
> > {
> > - struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
> > struct scmi_clk_state_in in = {
> > .clock_id = clk->id,
> > .attributes = enable,
> > @@ -81,7 +70,7 @@ static int scmi_clk_gate(struct clk *clk, int enable)
> > in, out);
> > int ret;
> >
> > - ret = devm_scmi_process_msg(clk->dev, priv->channel, );
> > + ret = devm_scmi_process_msg(clk->dev, );
> > if (ret)
> > return ret;
> >
> > @@ -100,7 +89,6 @@ static int scmi_clk_disable(struct clk *clk)
> >
> > static ulong scmi_clk_get_rate(struct clk *clk)
> > {
> > - struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
> > struct scmi_clk_rate_get_in in = {
> > .clock_id = clk->id,
> > };
> > @@ -110,7 +98,7 @@ static ulong scmi_clk_get_rate(struct clk *clk)
> > in, out);
> > int ret;
> >
> > - ret = devm_scmi_process_msg(clk->dev, priv->channel, );
> > + ret = devm_scmi_process_msg(clk->dev, );
> > if (ret < 0)
> > return ret;
> >
> > @@ -123,7 +111,6 @@ static ulong scmi_clk_get_rate(struct clk *clk)
> >
> > static ulong scmi_clk_set_rate(struct clk *clk, ulong rate)
> > {
> > - struct scmi_clk_priv *priv = dev_get_priv(clk->dev);
> > struct scmi_clk_rate_set_in in = {
> > .clock_id = clk->id,
> > .flags = SCMI_CLK_RATE_ROUND_CLOSEST,
> > @@ -136,7 +123,7 @@ static ulong scmi_clk_set_rate(struct clk *clk, ulong
> > rate)
> > in, out);
> > int ret;
> >
> > - ret =
Re: [PATCH 30/32] fdt: Allow the devicetree to come from a bloblist
On 9/11/23 08:17, Ilias Apalodimas wrote: Hi Simon, On Sun, 10 Sept 2023 at 22:14, Simon Glass wrote: Hi Ilias, On Mon, 4 Sept 2023 at 03:31, Ilias Apalodimas wrote: Hi Simon, On Fri, 1 Sept 2023 at 18:51, Simon Glass wrote: Hi Ilias, On Fri, 1 Sept 2023 at 01:50, Ilias Apalodimas wrote: [...] +config OF_BLOBLIST + bool "DTB is provided by a bloblist" + help + Select this to read the devicetree from the bloblist. This allows + using a bloblist to transfer the devicetree between U-Boot phases. + The devicetree is stored in the bloblist by an early phase so that + U-Boot can read it. + I dont think this is a good idea. We used to have 4-5 different options here, which we tried to clean up and ended up with two very discrete options. Why do we have to reintroduce a new one? Doesn't that bloblist have a header of some sort? The bloblist literally comes from a previous stage bootloader which is what OF_BOARD is here for. So why can't we just read the header and figure out if the magic of the bloblist matches? No, OF_BOARD is a hack to allow boards to do what they like with the FDT. This patch is a standard mechanism to pass the DT from one firmware phase to the next. We have spent quite a bit of time creating a spec for it, and we should use it. Where exactly am I objecting using the spec? Can you please re-read my email? I am actually pointing out we should use the spec *properly*. So instead of having a Kconfig option for the DT, which is pretty pointless, we should parse the bloblist. If the header defined by the *spec* is found, we should just search for the DT in there. What you are doing here, is take the spec, pick a very specific item that the list contains, and create a Kconfig option out of it. Which basically ignores the discoverable options of the bloblist. For example, that bloblist can also contain an entry to a TPM eventlog. Should we start creating Kconfig options for all the firmware handoff entries that are defined on that spec? OK so that is a different thing. What should it do if it expects to find a bloblist but cannot? I want it to throw an error, because I am trying to make the boot deterministic. What do you think? That's fine by me. You can even put that under IS_ENABLED for the bloblist inside the existing OF_BOARD check. So I was thinking - If no bloblist is required in Kconfig options we do the hacks we used to - if bloblist is selected and the config option is OF_BOARD, throw an error and mention that the previous stage loader should hand over a DT Is that what you had in mind? Yes, that sounds good to me. But I still think we need an OF_BLOBLIST option to control whether the devicetree comes from there. Otherwise we will end up with people using OF_BOARD to work around it. We also have the SPL case which does not pass the DT in a bloblist...in fact SPL typically doesn't even have the full DT. Wouldn't IS_ENABLED(BLOBLIST) || IS_ENABLED(SPL_BLOBLIST) be enough? Inside the OF_BOARD portion of the function, search for a bloblist if the option is enabled. If you can't find a bloblist and the DT within that bloblist, then error out Just my 2c here. I think all options should be possible to disable. It means I can imagine to disable u-boot not to take care about DT provided from previous stage. The same is for TPM event log. IMHO every stage should have an option to simply ignore data pass from previous stage. I don't really mind how it is done but there should be an option to by purpose say to ignore the part of pass data. Regarding DT part. We are experimenting with TF-A injecting for example DDR memory reservation to DT. Injection is working properly if you are using single DT but in SOM case we are using FIT image with a lot of DTBs inside (issue with checksums calculation). I see couple of platforms (IIRC renesas/imx) which are using DT overlays and passing it via specific registers. For these using bloblist might be right way to go. I wasn't aware about the whole fdt bloblist discussion but based on my experiments you can create multiple FDT entries that's why I expect that there could be DT overlays from different stages. And I even think that all of them can be overlays without base DT which can be select later on. Thanks, Michal
Re: [PATCH 30/32] fdt: Allow the devicetree to come from a bloblist
Hi Simon, On Sun, 10 Sept 2023 at 22:14, Simon Glass wrote: > > Hi Ilias, > > On Mon, 4 Sept 2023 at 03:31, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > On Fri, 1 Sept 2023 at 18:51, Simon Glass wrote: > > > > > > Hi Ilias, > > > > > > On Fri, 1 Sept 2023 at 01:50, Ilias Apalodimas > > > wrote: > > > > > > > > [...] > > > > > > > > > > > > > > > > > +config OF_BLOBLIST > > > > > > > + bool "DTB is provided by a bloblist" > > > > > > > + help > > > > > > > + Select this to read the devicetree from the bloblist. > > > > > > > This allows > > > > > > > + using a bloblist to transfer the devicetree between > > > > > > > U-Boot phases. > > > > > > > + The devicetree is stored in the bloblist by an early > > > > > > > phase so that > > > > > > > + U-Boot can read it. > > > > > > > + > > > > > > > > > > > > I dont think this is a good idea. We used to have 4-5 different > > > > > > options > > > > > > here, which we tried to clean up and ended up with two very discrete > > > > > > options. Why do we have to reintroduce a new one? Doesn't that > > > > > > bloblist > > > > > > have a header of some sort? The bloblist literally comes from a > > > > > > previous > > > > > > stage bootloader which is what OF_BOARD is here for. So why can't > > > > > > we just > > > > > > read the header and figure out if the magic of the bloblist matches? > > > > > > > > > > No, OF_BOARD is a hack to allow boards to do what they like with the > > > > > FDT. > > > > > > > > > > This patch is a standard mechanism to pass the DT from one firmware > > > > > phase to the next. We have spent quite a bit of time creating a spec > > > > > for it, and we should use it. > > > > > > > > Where exactly am I objecting using the spec? Can you please re-read > > > > my email? > > > > I am actually pointing out we should use the spec *properly*. So > > > > instead of having a Kconfig option for the DT, which is pretty > > > > pointless, we should parse the bloblist. If the header defined by > > > > the *spec* is found, we should just search for the DT in there. > > > > What you are doing here, is take the spec, pick a very specific item > > > > that the list contains, and create a Kconfig option out of it. Which > > > > basically ignores the discoverable options of the bloblist. For > > > > example, that bloblist can also contain an entry to a TPM eventlog. > > > > Should we start creating Kconfig options for all the firmware handoff > > > > entries that are defined on that spec? > > > > > > OK so that is a different thing. What should it do if it expects to find > > > a bloblist but cannot? I want it to throw an error, because I am trying > > > to make the boot deterministic. What do you think? > > > > That's fine by me. You can even put that under IS_ENABLED for the > > bloblist inside the existing OF_BOARD check. So I was thinking > > - If no bloblist is required in Kconfig options we do the hacks we used to > > - if bloblist is selected and the config option is OF_BOARD, throw an > > error and mention that the previous stage loader should hand over a DT > > > > Is that what you had in mind? > > Yes, that sounds good to me. > > But I still think we need an OF_BLOBLIST option to control whether the > devicetree comes from there. > Otherwise we will end up with people > using OF_BOARD to work around it. We also have the SPL case which does > not pass the DT in a bloblist...in fact SPL typically doesn't even > have the full DT. Wouldn't IS_ENABLED(BLOBLIST) || IS_ENABLED(SPL_BLOBLIST) be enough? Inside the OF_BOARD portion of the function, search for a bloblist if the option is enabled. If you can't find a bloblist and the DT within that bloblist, then error out Thanks /Ilias > > [..] > > Regards, > Simon
