bootph-all'.
Fixes: 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1")
Cc: Neha Francis
Signed-off-by: Nishanth Menon
---
The original patch was reviewed prior to commit 9e644284ab81
However the recent break in u-boot requires fixup to maintain sanity.
Neha: I have only build
On 12:22-20231005, Andrew Davis wrote:
> On 10/5/23 12:16 PM, Nishanth Menon wrote:
> > On 12:10-20231005, Nishanth Menon wrote:
> > > On 12:36-20231005, Tom Rini wrote:
> > > > On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:
> > > >
On 12:10-20231005, Nishanth Menon wrote:
> On 12:36-20231005, Tom Rini wrote:
> > On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:
> > > On 10/4/23 8:54 AM, Nishanth Menon wrote:
> > > > On 08:48-20231004, Andrew Davis wrote:
> > > >
AULTS already?
So, all we are picking up in effect is really CFG_SYS_SDRAM_BASE - which
is consistent across platforms.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
On 12:36-20231005, Tom Rini wrote:
> On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:
> > On 10/4/23 8:54 AM, Nishanth Menon wrote:
> > > On 08:48-20231004, Andrew Davis wrote:
> > > > On 10/4/23 8:23 AM, Roger Quadros wrote:
> > > > > t
boot/u-boot/commit/7e5b6f1cff846218b824a4d906e2831c15864a53
https://lore.kernel.org/all/3376a0eb-57f4-416a-b4b8-86cee769d...@siemens.com/
etc..
as a rule of thumb: u-boot.dtsi uses bootph-all; r5-xyz.dts uses booth-pre-ram
Where this failed completely is when A53 started using booth-pre-ram in
which c
2_EVM_H
>
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -/* DDR Configuration */
> -#define CFG_SYS_SDRAM_BASE1 0x88000
> -
> /* Now for the remaining common defines */
> #include
>
> --
> 2.34.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
"fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <2>;
> - bootph-pre-ram;
> + bootph-all;
Here and else where in the r5 file: why switch from pre-ram to bootph-all
? dont we need these prior to ddr initialization?
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
On 06:18-20231005, Jan Kiszka wrote:
> On 04.10.23 14:15, Nishanth Menon wrote:
> > On 22:26-20231003, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> Since commit [1] A53 u-boot proper is broken. This is because nodes
> >> marked as 'bootph-pre-r
On 10:29-20231005, Manorit Chawdhry wrote:
> Hi Nishanth,
>
> On 07:24-20231004, Nishanth Menon wrote:
> > On 10:43-20231004, Manorit Chawdhry wrote:
> >
> > > These are required to remove the firewall configurations that are done
> > > by ROM, those
'bootph-all'.
>
> [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
> after relocation")
>
> Signed-off-by: Jan Kiszka
Reviewed-by: Nishanth Menon
> ---
> .../dts/k3-am65-iot2050-common-u-boot.dtsi| 44 +--
> 1 file cha
egions are different for J784S4 from J721S2,
> and on the hardware side also, i.e. J784S4 has 4x8G DDR slots,
> so how can we bring it in same CONFIG as J721S2?
Is'nt that what device tree is for? what harm do we run into if
we define the common super set in the common file?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
w_binaries?, it is parsed by u-boot to find all
> the firmwares
> from filesystem for doing early boot of firmwares.
Does stdboot support this?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
On 16:23-20231004, Roger Quadros wrote:
> ti_mmc is not a valid boot_target for standard boot flow so
> remove it. Prefer mmc1 (sd-card) over mmc0 (emmc).
>
> Signed-off-by: Roger Quadros
Reviewed-by: Nishanth Menon
> ---
> board/ti/am62x/am62x.env | 2 +-
> 1 file chang
+ b/include/configs/am64x_evm.h
> @@ -10,8 +10,6 @@
> #define __CONFIG_AM642_EVM_H
>
> #include
Do we really need this?
> -#include
> -#include
> #include
OR this?
> #include
you dont need k3_dfu.h either. the env setup is already in
board/ti/am64x/am64x.env (
oard/ti/am62x/am62x.env
> > +++ b/board/ti/am62x/am62x.env
> > @@ -8,7 +8,7 @@ args_all=setenv optargs ${optargs}
> > earlycon=ns16550a,mmio32,0x0280
> > ${mtdparts}
> > run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
> > -boot_targets=ti_mmc mmc0 mmc1 us
ecure boot is done so that people don't end up
huh? the code seems to blindly call the remove_fwl_configs(cbass_hc_cfg0_fwls,
ARRAY_SIZE(cbass_hc_cfg0_fwls));
where is the distinction of HS vs GP here? This implementation looks
completely broken to me at least.. please correct what I missed here.
uot;rx", "tx";
> mboxes= <_proxy_main 22>,
> <_proxy_main 23>;
> - bootph-pre-ram;
> + bootph-all;
> };
> };
> @@ -55,11 +55,11 @@
> };
> _esm {
> - bootph-pre-ram;
> + bootph-all;
> };
> _proxy_sa3 {
> - bootph-pre-ram;
> + bootph-all;
> /* We require this for boot handshake */
> status = "okay";
> };
> @@ -69,12 +69,12 @@
> compatible = "ti,am654-system-controller";
> mboxes= <_proxy_main 1>, <_proxy_main 0>,
> <_proxy_sa3 0>;
> mbox-names = "tx", "rx", "boot_notify";
> - bootph-pre-ram;
> + bootph-all;
> };
> };
> _esm {
> - bootph-pre-ram;
> + bootph-all;
> };
> _pktdma {
> --
> 2.35.3
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
AK.
> >
> > Do this cleanup in the context of the new platform addition - when you
> > get it in the kernel first.
>
> I haven't planned to have a kernel dt for am62sip as there is only
> difference is DDR size which will be taken care by U-boot.
We can cross that bridge when
ke syncs easier in the future. unless there is a strong
reasoning on an alternate rationale, i'd rather not mess with the flow
in play already.
Personally though, I am miffed at a breaking change of this form :(
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232
return BOOT_DEVICE_ETHERNET;
> + case BACKUP_BOOT_DEVICE_MMC2:
> + {
> + u32 port = (main_devstat & MAIN_DEVSTAT_BKUP_MMC_PORT_MASK) >>
> + MAIN_DEVSTAT_BKUP_MMC_PORT_SHIFT;
> + if (port == 0x0)
> + return BOOT_DEVICE_MMC1;
> + return BOOT_DEVICE_MMC2;
> + }
> + case BACKUP_BOOT_DEVICE_SPI:
> + return BOOT_DEVICE_SPI;
> + case BACKUP_BOOT_DEVICE_I2C:
> + return BOOT_DEVICE_I2C;
> + }
> +
> + return BOOT_DEVICE_RAM;
> +}
> +
> +static u32 __get_primary_bootmedia(u32 main_devstat, u32 wkup_devstat)
> +{
> + u32 bootmode = (wkup_devstat & WKUP_DEVSTAT_PRIMARY_BOOTMODE_MASK) >>
> + WKUP_DEVSTAT_PRIMARY_BOOTMODE_SHIFT;
> +
> + bootmode |= (main_devstat & MAIN_DEVSTAT_BOOT_MODE_B_MASK) <<
> + BOOT_MODE_B_SHIFT;
> +
> + if (bootmode == BOOT_DEVICE_OSPI || bootmode == BOOT_DEVICE_QSPI ||
> + bootmode == BOOT_DEVICE_XSPI)
> + bootmode = BOOT_DEVICE_SPI;
> +
> + if (bootmode == BOOT_DEVICE_MMC2) {
> + u32 port = (main_devstat &
> + MAIN_DEVSTAT_PRIM_BOOTMODE_MMC_PORT_MASK) >>
> +MAIN_DEVSTAT_PRIM_BOOTMODE_PORT_SHIFT;
> + if (port == 0x0)
> + bootmode = BOOT_DEVICE_MMC1;
> + }
> +
> + return bootmode;
> +}
> +
> +u32 spl_spi_boot_bus(void)
> +{
> + u32 wkup_devstat = readl(CTRLMMR_WKUP_DEVSTAT);
> + u32 main_devstat = readl(CTRLMMR_MAIN_DEVSTAT);
> + u32 bootmode = ((wkup_devstat & WKUP_DEVSTAT_PRIMARY_BOOTMODE_MASK) >>
> + WKUP_DEVSTAT_PRIMARY_BOOTMODE_SHIFT) |
> + ((main_devstat & MAIN_DEVSTAT_BOOT_MODE_B_MASK) <<
> BOOT_MODE_B_SHIFT);
> +
> + return (bootmode == BOOT_DEVICE_QSPI) ? 1 : 0;
> +}
> +
> +u32 spl_boot_device(void)
> +{
> + u32 wkup_devstat = readl(CTRLMMR_WKUP_DEVSTAT);
> + u32 main_devstat;
> +
> + if (wkup_devstat & WKUP_DEVSTAT_MCU_OMLY_MASK) {
> + printf("ERROR: MCU only boot is not yet supported\n");
> + return BOOT_DEVICE_RAM;
> + }
> +
> + /* MAIN CTRL MMR can only be read if MCU ONLY is 0 */
> + main_devstat = readl(CTRLMMR_MAIN_DEVSTAT);
> +
> + if (bootindex == K3_PRIMARY_BOOTMODE)
> + return __get_primary_bootmedia(main_devstat, wkup_devstat);
> + else
> + return __get_backup_bootmedia(main_devstat);
> +}
> --
> 2.34.1
>
I think there is an opportunity to merge j721s2 and j784s4.. but i am
not expert on either of the chips to better comment.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
; #define K3_SOC_ID(id, ID) \
> static inline bool soc_is_##id(void) \
> --
> 2.34.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
= "ti,j721e-r5fss"},
> { .compatible = "ti,j7200-r5fss"},
> + { .compatible = "ti,j721s2-r5fss"},
> {}
> };
>
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
(emmc), usb pxe dhcp.
> +boot=mmc
> +mmcdev=1
> +dorprocboot=1
> +bootpart=1:2
> +bootdir=/boot
> +rd_spec=-
> +
> +rproc_fw_binaries= 2 /lib/firmware/j784s4-main-r5f0_0-fw 3
> /lib/firmware/j784s4-main-r5f0_1-fw 4 /lib/firmware/j784s4-main-r5f1_0-fw 5
> /lib/firmware/j784s4-main-r5f1_1-fw 6 /lib/firmware/j784s4-main-r5f2_0-fw 7
> /lib/firmware/j784s4-main-r5f2_1-fw 8 /lib/firmware/j784s4-c71_0-fw 9
> /lib/firmware/j784s4-c71_1-fw 10 /lib/firmware/j784s4-c71_2-fw 11
> /lib/firmware/j784s4-c71_3-fw
No clue what the above mess is.
> +
> +splashfile=ti.gz
> +splashimage=0x8200
> +splashpos=m,m
> +splashsource=mmc
You have splash screen support?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
ti/k3-j784s4-evm.dtb; fi;
What function is this doing? Why not leave it for defaults?
Just use include/env/ti/default_findfdt.env and be done with it?
> setenv fdtfile ${name_fdt}
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
s from linux kernel
error: sha1 information is lacking or useless (arch/arm/dts/Makefile).
error: could not build fake ancestor
Patch failed at 0010 arm: dts: Introduce am69-sk dts from linux kernel
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have
rst b/doc/board/ti/k3.rst
> index ec447358ac..60aacdac99 100644
> --- a/doc/board/ti/k3.rst
> +++ b/doc/board/ti/k3.rst
> @@ -35,6 +35,7 @@ K3 Based SoCs
> am65x_evm
> j7200_evm
> j721e_evm
> + j784s4_evm
>
> Boot Flow Overview
> --
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
> + bootph-all;
> +};
> +
> +_rgmii2_pins_default {
> + bootph-all;
> +};
> +
> +_gmii_sel {
> + bootph-all;
> +};
> +
> {
> bootph-all;
> + ethernet-ports {
> + bootph-all;
> + };
> };
>
> _port1 {
> --
> 2.34.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
bootph-all;
> };
>
> {
> - bootph-pre-ram;
> + bootph-all;
>
> flash@0 {
> - bootph-pre-ram;
> + bootph-all;
>
> partitions {
> - bootph-pre-ram;
> + bootph-all;
>
> partition
_default {
> + bootph-all;
> +};
> +
> +_mdio {
> + bootph-all;
> +};
> +
> +_phy0 {
> + bootph-all;
> +};
> +
> +_phy1 {
> + bootph-all;
> +};
> +
> +_pins_default {
> + bootph-all;
> +};
> +
> +_pins_default {
> + bootp
_pins_default {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _pins_default {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _phy1 {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _usb0_pins_default {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _ln_ctrl {
> @@ -141,25 +137,25 @@
> };
>
> {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _wiz0 {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _usb_link {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _refclk {
> - bootph-pre-ram;
> + bootph-all;
> };
> --
> 2.34.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
otph-all;
> +};
> +
> +_port1 {
> + bootph-all;
> };
>
> _port2 {
> diff --git a/arch/arm/dts/k3-am642-r5-evm.dts
> b/arch/arm/dts/k3-am642-r5-evm.dts
> index 696735d8e2..64b3c3af63 100644
> --- a/arch/arm/dts/k3-am642-r5-evm.dts
> +++ b/arch/arm/dts/k
};
>
> {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _port2 {
> diff --git a/arch/arm/dts/k3-am642-r5-evm.dts
> b/arch/arm/dts/k3-am642-r5-evm.dts
> index 73461f8f6c..696735d8e2 100644
> --- a/arch/arm/dts/k3-am642-r5-evm.dts
> +++ b/arch/arm/dts/k3-am64
after
relocation")
Reported-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Based on Roger's series:
https://lore.kernel.org/all/20230929134646.214781-1-rog...@kernel.org/
Based on:
next e29b932aa07f Merge branch
'2023-09-30-Kconfig-updates' into next
See discuss
On 15:09-20230928, Nitin Yadav wrote:
>
>
> On 27/09/23 17:26, Nishanth Menon wrote:
> > On 13:51-20230927, Nitin Yadav wrote:
> >> Add k3-am62x-r5-sk-common to include nodes common for R5
> >> SPL from k3-am625-r5-sk for AM62x SoC based boards. Add
> >>
On 15:00-20230928, Nitin Yadav wrote:
> Hi,
>
> On 27/09/23 17:22, Nishanth Menon wrote:
> > On 13:51-20230927, Nitin Yadav wrote:
> >> The AM62x LP SK board is similar to the AM62x SK board,
> >> but has some significant changes that requires different
> >&
/next?after=90c81f407dd4a7747385b10f9b8f732202c45cde+104=next_name=refs%2Fheads%2Fnext
Can you send delta patches based off u-boot next?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
ch/arm/dts/k3-am62x-ddr-lp4-50-800-800.dtsi
> create mode 100644 arch/arm/dts/k3-am62x-r5-sk-common.dtsi
> create mode 100644 arch/arm/dts/k3-am62x-sk-common-u-boot.dtsi
> create mode 100644 board/ti/am62x/am62x_lpsk_a53.config
> create mode 100644 board/ti/am62x/am62x_lpsk_r5.config
>
ff-by: Nitin Yadav
> ---
[...]
> +#include "k3-am625-sk-binman.dtsi"
Might be a good time to refactor and squash sk-binman.dtsi to
u-boot.dtsi ?
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
pxe dhcp
> +boot=mmc
> +mmcdev=1
> +bootpart=1:2
> +bootdir=/boot
> +rd_spec=-
> +
> +splashfile=ti.gz
> +splashimage=0x8020
> +splashpos=m,m
> +splashsource=sf
Why dont we use the am62.env ? What is here to customize?
> --
> 2.25.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
LP_SK_DTB;
> +};
> +
> +_am625_sk_dtb {
> + filename = SPL_AM62_LP_SK_DTB;
> +};
> +
> +_sk_dtb {
> + filename = AM62_LP_SK_DTB;
> +};
> +
> +#endif
> --
> 2.25.1
>
Squash this to the u-boot.dtsi ?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
0-800.dtsi
> new file mode 100644
> index 00..74693d12e1
> --- /dev/null
> +++ b/arch/arm/dts/k3-am62x-ddr-lp4-50-800-800.dtsi
> @@ -0,0 +1,2190 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * This file was generated with the
> + * AM62x SysConfig DDR Subsystem
uct udevice *dev,
> }
>
> spm->scfg = devfdt_get_addr_name(dev, "scfg");
> - if (spm->rt == FDT_ADDR_T_NONE) {
> + if (spm->scfg == FDT_ADDR_T_NONE) {
> dev_err(dev, "No reg property for Secure Cfg base\n");
>
On 16:09-20230922, Neha Malcom Francis wrote:
> U-Boot uses mcu_timer0 as the tick-timer, so add it to device list.
>
> Signed-off-by: Neha Malcom Francis
> Reviewed-by: Manorit Chawdhry
Reviewed-by: Nishanth Menon
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) /
before using the timer, move clk_k3 driver
> probe before k3_sysfw_loader to ensure we have all necessary clocks set
> up before.
>
> Signed-off-by: Neha Malcom Francis
Reviewed-by: Nishanth Menon
> ---
> arch/arm/mach-k3/j721e_init.c | 24
> 1 f
> +
> + if (ret)
> + return ret;
> +
> return handle;
> }
>
> @@ -2825,11 +2832,9 @@ static int ti_sci_probe(struct udevice *dev)
> list_add_tail(>list, _sci_list);
> ti_sci_setup_ops(info);
>
> - ret = ti_sci_cmd_get_
lt;50>;
> + clock-frequency = <1920>;
I have'nt seen us needing this elsewhere.
> };
>
> _i2c0 {
> @@ -293,97 +122,19 @@
I dont like the inclusion of tps659413a which is not in upstream
- document that in commit message.
> };
>
> };
[...]
>
> _ringacc {
> @@ -393,31 +144,3 @@
> _udmap {
> ti,sci = <_tifs>;
> };
Move the ra and udmap nodes ahead of the peripherals.
[...]
> diff --git a/arch/arm/dts/k3-j721e-r5-sk.dts b/arch/arm/dts/k3-j721e-r5-sk.dts
> index 1cc64d07f7..0274465fa4 100644
> --- a/arch/arm/dts/k3-j721e-r5-sk.dts
> +++ b/arch/arm/dts/k3-j721e-r5-sk.dts
Unrelated to this patch: I noticed also that the DDR configuration for
J721e-sk is stale (0.6 rev of DDR tool Vs 0.10 for EVM)
For SK's R5 dts and u-boot.dtsi:
The above pattern of comments from EVM repeat on SK as well, I will skip
repeating the comments.
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
| 7 +++
> arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 14 ++
> 3 files changed, 28 insertions(+)
Get this as part of kernel dt sync.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
et_rate(struct clk *clk, ulong
> rate)
> return ret;
> }
>
> + if (set_avs_after_clock && IS_ENABLED(CONFIG_K3_AVS0))
> + k3_avs_notify_freq(clk->id, clk->data, rate);
> +
> return rate;
> }
>
> --
> 2.34.1
>
First look - it looks fine, but note: these are two different patches.
the clk-sci.c is a fix for an existing implementation and clk-k3.c is a
new feature addition. please don't mix the two.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
nmuxes from r5 and -u-boot.dtsi files and
> include k3-am68-sk-base-board.dts for Linux fixes to propagate
> to U-boot.
>
Please fix your $subject: arm: dts: k3-am68: ...
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
nmuxes from r5 and -u-boot.dtsi files and
> include k3-j721s2-common-proc-board.dts for Linux fixes to propagate
> to U-boot.
>
Please fix your $subject arm: dts: k3-j721s2:
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
On 22:58-20230919, Kumar, Udit wrote:
> Hi Nishanth,
>
> On 9/19/2023 9:07 PM, Nishanth Menon wrote:
> > On 19:34-20230919, Udit Kumar wrote:
> > > AVS is enabled at R5 SPL stage, on few platforms like J721E
> > > and J7200 clk-k3 is used instead if clk-sci driver
t; F1), then Seq 1 is valid. But if V2 > V1 (F2 >
F1) Seq 2 is valid.
We seem to ignore this constraint. Can you explain this in the commit
message?
clk-sci.c seems to use Seq 2, vs this patch seems to take Seq 1.
> return new_rate;
> }
>
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
xt revision queued by b4 also has the same problem. Not
> exactly sure what went wrong with b4 but would be careful next time.
> Thanks for pointing it out.
Please resubmit.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
30911162535.1044560-4...@ti.com
That should take care of this in the kernel sync next time around.
But, for next:
Reviewed-by: Nishanth Menon
>
> > ---
> >
> > (no changes since v1)
> >
> > arch/arm/dts/k3-am625-sk-u-boot.dtsi | 8
> > 1 file changed, 8 in
, rate);
>
> -#ifdef CONFIG_K3_AVS0
> - k3_avs_notify_freq(clk->id, clk->data, rate);
> -#endif
> -
Why drop from here? we do have am64 and am65 that use ti-sci, correct?
> ret = cops->set_freq(sci, clk->id, clk->data, 0, rate, ULONG_MAX);
> if (ret) {
> dev_err(clk->dev, "%s: set_freq failed (%d)\n", __func__, ret);
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
t Kumar (1):
> configs: j721s2_evm_r5_defconfig: Increase malloc pool size in DRAM
>
Not sure what happened to your patches, but they are missing sequence
numbering and versioning info.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
done;
> get_kern_mmc=load mmc ${bootpart} ${loadaddr}
>
> base-commit: 2fe4b54556ea6271237b35de68dc458bfceab94c
we should move to stdboot and simplify this.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
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
>
Reviewed
--- 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
On 18:36-20230912, Udit Kumar wrote:
> TI SOC has two clock domains CLK_TI_SCI and
> CLK_K3. These are mutually exclusive.
>
> Adding conditional check for CLK_TI_SCI
> and CLK_K3 along with other associated configs options.
>
> Suggested-by: Nishanth Menon
> S
On 18:36-20230912, Udit Kumar wrote:
> TI SOC has two power domain TI_SCI_POWER_DOMAIN and
> TI_POWER_DOMAIN. These are mutually exclusive.
> So adding rule to select one, in case defconfig enabled both.
>
> Suggested-by: Nishanth Menon
> Signed-off-by: Udit Kumar
> ---
&g
their device trees with a more permissive
> license like GPL-2.0-or-later OR MIT
> like most others do?
We can check again, but some sort of corporate policy thing, I suspect.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
-sk", "ti,j784s4";
> > + model = "Texas Instruments AM69 SK";
>
> I never understood TI's naming. Somewhere they call it Evaluation Module
> (EVM), somewhere Starter Kit (SK) and
> even at other places Evaluation Board (EVB).
>
Hehe - neither do we understand marketing speak - changes over time
etc.. overall pattern: SK is cost optimized (aka "low cost"
and limited expansion) vs evm - relatively large expansion and expensive ;)
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
;
> > break;
> > + case JTAG_ID_PARTNO_J784S4:
> > + family = "J784S4";
> > + break;
> > default:
> > family = "Unknown Silicon";
> > };
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
both drivers in line with the same
> compatibles.
>
> Since the j7200 uses the config as the j721e, the data is inherited
> from j721e vs creating a duplicate
>
> Signed-off-by: Neha Francis
> Signed-off-by: Reid Tonking
> ---
Reviewed-by: Nishanth Menon
--
Regards,
Ni
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
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
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 c
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
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
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
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
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
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
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
reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
> + bootph-pre-ram;
> +};
>
> - chipid@43000014 {
> +_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;
> - };
> };
NOTE: v6.6-rc1 has been tagged yesterday - so it is probably time for us
to sync with that and drop these.
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
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-ti
On 12:20-20230908, Andrew Davis wrote:
> On 9/8/23 12:03 PM, Nishanth Menon wrote:
> > On 10:59-20230908, Andrew Davis wrote:
> > > On 9/8/23 9:42 AM, Nishanth Menon wrote:
> > > > On 16:35-20230908, Apurva Nandan wrote:
> > > > > From: Dasnavi
+++ 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?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
On 10:59-20230908, Andrew Davis wrote:
> On 9/8/23 9:42 AM, Nishanth Menon wrote:
> > On 16:35-20230908, Apurva Nandan wrote:
> > > From: Dasnavis Sabiya
> > >
> > > The board name is programmed in the EEPROM. Add support for board
> > > detection and
update the serial environment variable with the same.
>
> Signed-off-by: Dasnavis Sabiya
> Signed-off-by: Apurva Nandan
NAK. go with the approach similar to AM62x. AM69-SK has it's own
fragment.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
/lore.kernel.org/all/52a7c0b2-7a87-c74e-e63f-d07821ffc...@ti.com/
we are going to end up creating a dependency nightmare.
Can we just do a single series(might be just a single patch) for
compatible additions for k3_avs.c and make the dts syncs dependent on this?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
t; CONFIG_SYS_FLASH_CFI=y
> -CONFIG_HBMC_AM654=y
> CONFIG_DM_SPI_FLASH=y
> CONFIG_SPI_FLASH_SFDP_SUPPORT=y
> CONFIG_SPI_FLASH_STMICRO=y
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
= ti_sci_cmd_get_revision(>handle);
> + else
> + ret = 0;
>
> INIT_LIST_HEAD(>dev_list);
>
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
panic("Failed to initialize clk-k3!\n");
> - }
> -
> /* Prepare console output */
> preloader_console_init();
>
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
$subject: s/dtb/device tree or dts
On 13:13-20230905, Reid Tonking wrote:
> Sync j7200 device tree files with Linux 6.5-rc1
With that..
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
ed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
;
>
> U_BOOT_DRIVER(k3_avs) = {
> --
> 2.34.1
>
https://lore.kernel.org/all/1fed9388-dfc4-0b9c-4502-b5020b2ae...@ti.com/
Will let Udit and you sort this out.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
t; 1 file changed, 9 insertions(+), 2 deletions(-)
>
For whatever it is worth:
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
8
>
> Reviewed-by: Neha Malcom Francis
> Signed-off-by: Manorit Chawdhry
> ---
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
info exists SOC] } {
# Set the SoC of interest
set SOC j721s2
}
source [find target/ti_k3.cfg]
ftdi tdo_sample_edge falling
# Speeds for FT2232H are in multiples of 2, and 32MHz is tops
# max speed we seem to achieve is ~20MHz.. so we pick 16MHz
adapter speed 16000
> dif
On 23:43-20230901, Kumar, Udit wrote:
>
> On 9/1/2023 11:03 PM, Nishanth Menon wrote:
> > On 22:54-20230901, Kumar, Udit wrote:
> > > > > +static const struct udevice_id of_k3_j72xx_bandgap_match[] = {
> > > > > + {
> >
/ from sdhci nodes
>
> We have the necessary clock and dev data so remove these.
>
> - Remove dummy_clocks and fs_loader0
>
> These weren't being used anywhere so remove it.
>
> All these have been put in a single commit to not break the
> bisectability.
>
ty.
>
> Reviewed-by: Neha Malcom Francis
> Signed-off-by: Manorit Chawdhry
> ---
Thank you for cleaning this up.
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
t;
> Reviewed-by: Neha Malcom Francis
> Signed-off-by: Manorit Chawdhry
Thank you for cleaning this up
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
u-boot when needed.
you are saying the drivers are mutually exclusive - how about detecting
over-temp scenario at R5 boot? switching on A53 will be a mistake at
that point, no?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
writel(val, data[id].bgp->cfg2_base + data[id].ctrl_offset);
> +
> + bgp->ts_data[id] = [id];
> + }
> +
> + /*
> + * Program TSHUT thresholds
> + * Step 1: set the thresholds to ~123C and 105C WKUP_VTM_MISC_CTRL2
> + * Step 2: WKUP_VTM_TMPSENS_CTRL_j set the MAXT_OUTRG_EN bit
> + * This is already taken care as per of init
> + * Step 3: WKUP_VTM_MISC_CTRL set the ANYMAXT_OUTRG_ALERT_EN bit
> + */
> + high_max = k3_j72xx_bandgap_temp_to_adc_code(MAX_TEMP);
> + low_temp = k3_j72xx_bandgap_temp_to_adc_code(COOL_DOWN_TEMP);
> +
> + writel((low_temp << 16) | high_max, data[0].bgp->cfg2_base +
> +K3_VTM_MISC_CTRL2_OFFSET);
> + mdelay(100);
> + writel(K3_VTM_ANYMAXT_OUTRG_ALERT_EN, data[0].bgp->cfg2_base +
> +K3_VTM_MISC_CTRL_OFFSET);
> +
> + print_look_up_table(dev, ref_table);
> + /*
> + * Now that the derived_table has the appropriate look up values
> + * Free up the ref_table
> + */
> + kfree(ref_table);
> +
> + return 0;
> +
> +err_free_ref_table:
> + kfree(ref_table);
> +
> +err_alloc:
> +
> + return ret;
> +}
> +
> +static const struct k3_j72xx_bandgap_data k3_j72xx_bandgap_j721e_data = {
> + .has_errata_i2128 = true,
> +};
> +
> +static const struct k3_j72xx_bandgap_data k3_j72xx_bandgap_j7200_data = {
> + .has_errata_i2128 = false,
> +};
> +
> +static const struct udevice_id of_k3_j72xx_bandgap_match[] = {
> + {
> + .compatible = "ti,j721e-vtm",
> + .data = (ulong)_j72xx_bandgap_j721e_data,
So what happens to drivers/misc/k3_avs.c ?
> + },
> + {
> + .compatible = "ti,j7200-vtm",
> + .data = (ulong)_j72xx_bandgap_j7200_data,
> + },
> + { /* sentinel */ },
> +};
> +
> +U_BOOT_DRIVER(ti_bandgap_thermal) = {
> + .name = "ti_bandgap_thermal",
> + .id = UCLASS_THERMAL,
> + .ops= _of_thermal_ops,
> + .probe = k3_j72xx_bandgap_probe,
> + .of_match = of_k3_j72xx_bandgap_match,
> + .priv_auto = sizeof(struct k3_j72xx_bandgap),
> +};
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
On 13:56-20230831, Neha Malcom Francis wrote:
> Hi Nishanth
>
> On 28/08/23 23:03, Nishanth Menon wrote:
> > On 17:01-20230828, Neha Malcom Francis wrote:
> > > This series aims to sync kernel.org v6.5-rc1 DTS with that of U-Boot. It
> > > also includes cleanups w
On 13:51-20230831, Neha Malcom Francis wrote:
> Hi Nishanth
>
> On 28/08/23 22:39, Nishanth Menon wrote:
> > On 17:01-20230828, Neha Malcom Francis wrote:
> > > Sync k3-j721e DTS with kernel.org v6.5-rc1.
> > > * pcie_epx nodes have been deleted, they are not ne
301 - 400 of 1407 matches
Mail list logo
