Re: [PATCH] doc: devicetree: Lets avoid short reference link names
On 01/03/2024 13:24, Sumit Garg wrote: > Short reference link names like "dtspec", "dtrepo", "dttweaks" etc. > interrupt the flow of the document text. Lets avoid them and instead > expand in place for better readability. > > Suggested-by: Paul Barker > Signed-off-by: Sumit Garg > --- > doc/develop/devicetree/control.rst | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) > > diff --git a/doc/develop/devicetree/control.rst > b/doc/develop/devicetree/control.rst > index c94d84192b71..4cc1457d4ea8 100644 > --- a/doc/develop/devicetree/control.rst > +++ b/doc/develop/devicetree/control.rst > @@ -36,10 +36,10 @@ What is a Flattened Devicetree? > --- > > An fdt can be specified in source format as a text file. To read about > -the fdt syntax, take a look at the specification (dtspec_). > +the fdt syntax, take a look at `the devicetree specification`_. > > -There is also a mailing list (dtlist_) for the compiler and associated > -tools. > +There is also a `devicetree compiler mailing list`_ for the compiler and > +associated tools. > > In case you are wondering, OF stands for Open Firmware. This follows the > convention used in Linux. > @@ -89,7 +89,7 @@ Failing that, you could write one from scratch yourself! > Resyncing with devicetree-rebasing > -- > > -The devicetee-rebasing repository (dtrepo_) maintains a fork cum mirror copy > of > +The `devicetree-rebasing repository`_ maintains a fork cum mirror copy of > devicetree files along with the bindings synced at every Linux kernel major > release or intermediate release candidates. The U-Boot maintainers regularly > sync the `dts/upstream/` subtree from the devicetree-rebasing repo whenever > @@ -118,7 +118,7 @@ as `arch//dts/.dts`. To select that add `# > CONFIG_OF_UPSTREAM is not > set` and set `DEFAULT_DEVICE_TREE=` when prompted by Kconfig. > > This should include your CPU or SoC's devicetree file. On top of that any > U-Boot > -specific tweaks (see: dttweaks_) can be made for your board. > +specific tweaks (see: :ref:`dttweaks`) can be made for your board. > > If `OF_EMBED` is selected by Kconfig, then it will be picked up and built > into > the U-Boot image (including u-boot.bin). This is suitable for debugging > @@ -243,7 +243,7 @@ Dependencies > > The DT schema project must be installed in order to validate the DT schema > binding documents and validate DTS files using the DT schema. For > installation > -instructions, refer to the DT schema project page (dtschema_). > +instructions, refer to the `DT schema project page`_. > > Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be > installed. Ensure they are in your PATH (~/.local/bin by default). > @@ -333,10 +333,10 @@ used it before Linux (e.g. snow). The two projects > developed in parallel > and there are still some differences in the bindings for certain boards. > While there has been discussion of having a separate repository for > devicetree > files, in practice the Linux kernel Git repository has become the place where > -these are stored, with U-Boot taking copies via devicetree-rebasing repo > -(see: dtrepo_) and adding tweaks with u-boot.dtsi files. > +these are stored, with U-Boot taking copies via > +`devicetree-rebasing repository`_ and adding tweaks with u-boot.dtsi files. > > -.. _dtspec: https://www.devicetree.org/specifications/ > -.. _dtlist: https://www.spinics.net/lists/devicetree-compiler/ > -.. _dtrepo: > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > -.. _dtschema: https://github.com/devicetree-org/dt-schema/tree/main > +.. _the devicetree specification: https://www.devicetree.org/specifications/ > +.. _devicetree compiler mailing list: > https://www.spinics.net/lists/devicetree-compiler/ > +.. _devicetree-rebasing repository: > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > +.. _DT schema project page: > https://github.com/devicetree-org/dt-schema/tree/main Reviewed-by: Paul Barker -- Paul Barker OpenPGP_0x27F4B3459F002257.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/2] cli: allow users to disable history if unused at all
Hi Tom, Thanks for reviewing! I am not quite sure about the tests which you refer to. Is it the CI in the gitlab? I think this patch is simple and it doesn’t occur any errors during my work these days, thus I tested it manually which didn’t throw any problems, and sent it. Could you please give me some hints about the broken tests? If it is a CI, could you please give me the link to the error information? Thanks! Regards, Hanyuan > 2024年3月2日 05:37，Tom Rini 写道： > > On Sat, Feb 17, 2024 at 09:54:43PM +0800, Hanyuan Zhao wrote: > >> This commit allows user to determine whether to have history recording >> in command-line. Previously the history data as uninitialized static >> array would not directly take much space in binary file since it only >> marks size in the binary. However now it asks to allocate space. By >> connecting the original CMD_HISTORY flag in Kconfig, users could unset >> the whole history function, and the memory usage could be eased, if the >> history function is not used at all. >> >> Signed-off-by: Hanyuan Zhao >> --- >> cmd/Kconfig | 1 + >> common/cli_readline.c | 44 --- >> 2 files changed, 26 insertions(+), 19 deletions(-) > > This breaks current tests, please re-test, thanks. > > -- > Tom
Re: [PATCH 4/8] clk: qcom: add support for power domains uclass
On 29.02.2024 15:21, Volodymyr Babchuk wrote:
> Now sub-drivers for particular SoCs can register them as power domain
> drivers. This is needed for upcoming SM8150 support, because it needs
> to power up the Ethernet module.
>
> Signed-off-by: Volodymyr Babchuk
> ---
>
> drivers/clk/qcom/clock-qcom.c | 93 ++-
> drivers/clk/qcom/clock-qcom.h | 6 +++
> 2 files changed, 98 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c
> index 729d190c54..986b8e4da4 100644
> --- a/drivers/clk/qcom/clock-qcom.c
> +++ b/drivers/clk/qcom/clock-qcom.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include "clock-qcom.h"
>
> @@ -30,6 +31,11 @@
> #define CBCR_BRANCH_ENABLE_BIT BIT(0)
> #define CBCR_BRANCH_OFF_BIT BIT(31)
>
> +#define GDSC_POWER_UP_COMPLETE BIT(16)
> +#define GDSC_POWER_DOWN_COMPLETE BIT(15)
Please keep things sorted by bit index for bitfields and register offset
for registers
> +#define CFG_GDSCR_OFFSET 0x4
> +#define PWR_ON_MASK BIT(31)
> +
> /* Enable clock controlled by CBC soft macro */
> void clk_enable_cbc(phys_addr_t cbcr)
> {
> @@ -223,7 +229,7 @@ U_BOOT_DRIVER(qcom_clk) = {
> int qcom_cc_bind(struct udevice *parent)
> {
> struct msm_clk_data *data = (struct msm_clk_data
> *)dev_get_driver_data(parent);
> - struct udevice *clkdev, *rstdev;
> + struct udevice *clkdev, *rstdev, *pwrdev;
> struct driver *drv;
> int ret;
>
> @@ -253,6 +259,20 @@ int qcom_cc_bind(struct udevice *parent)
> if (ret)
> device_unbind(clkdev);
>
> + if (!data->power_domains)
> + return ret;
> +
> + /* Get a handle to the common power domain handler */
> + drv = lists_driver_lookup_name("qcom_power");
> + if (!drv)
> + return -ENOENT;
> +
> + /* Register the power domain controller */
> + ret = device_bind_with_driver_data(parent, drv, "qcom_power",
> (ulong)data,
> +dev_ofnode(parent), );
> + if (ret)
> + device_unbind(pwrdev);
> +
> return ret;
> }
>
> @@ -306,3 +326,74 @@ U_BOOT_DRIVER(qcom_reset) = {
> .ops = _reset_ops,
> .probe = qcom_reset_probe,
> };
> +
> +static int qcom_power_set(struct power_domain *pwr, bool on)
> +{
> + struct msm_clk_data *data = (struct msm_clk_data
> *)dev_get_driver_data(pwr->dev);
> + void __iomem *base = dev_get_priv(pwr->dev);
> + const struct qcom_power_map *map;
> + u32 value;
> +
> + if (pwr->id >= data->num_power_domains)
> + return -ENODEV;
> +
> + map = >power_domains[pwr->id];
> +
> + if (!map->reg)
> + return -ENODEV;
> +
> + value = readl(base + map->reg);
> +
> + if (on)
> + value &= ~BIT(0);
These magic bits should be #defined.
> + else
> + value |= BIT(0);
> +
> + writel(value, base + map->reg);
> +
> + /* Wait for power on */
> + while (true) {
Uhh.. I'm not sure a tight loop is the best idea here, especially since
GDSCs are known to be grumpy and not wanna power on if they're missing
a dependency. I'd say a timeout is definitely in order. 1500ms following
Linux
Konrad
Re: [PATCH v3 2/2] spl: Add support for booting from ESP
On Mon, Jan 22, 2024 at 04:40:22PM +0530, Mayuresh Chitale wrote: > Some platforms as described by EBBR specification may store images in > the FIRMWARE directory of the UEFI system partition(ESP). Add support > to boot from the EFI system partition if it is enabled for a platform. > > Signed-off-by: Mayuresh Chitale > Reviewed-by: Heinrich Schuchardt [snip] > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index cf7ffc9b112..48e4e43196a 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -1292,6 +1292,14 @@ config SPL_SATA_RAW_U_BOOT_SECTOR > Sector on the SATA disk to load U-Boot from, when the SATA disk is > being > used in raw mode. Units: SATA disk sectors (1 sector = 512 bytes). > > +config SPL_ESP_BOOT > + bool "Load next stage boot image from the UEFI system partition" > + default y if BOOT_DEFAULTS > + select SPL_PARTITION_TYPE_GUID > + help > + When enabled, first try to boot from the UEFI system partition as > + described in the Ch.4 of the EBBR specification. > + > config SPL_NVME > bool "NVM Express device support" > depends on BLK This introduces: WARNING: unmet direct dependencies detected for SPL_PARTITION_TYPE_GUID Depends on [n]: SPL_EFI_PARTITION [=n] Selected by [y]: - SPL_ESP_BOOT [=y] && SPL [=y] On for example coreboot64. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] cmd: md5sum: use hash_command
On Sun, Feb 11, 2024 at 07:56:16PM +0100, Igor Opaniuk wrote: > From: Igor Opaniuk > > Drop old implementation and use hash_command() instead, as > how it's currently done for crc32 and sha1sum cmds. > > Test: > => md5sum 0x6000 0x200 > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 > > Signed-off-by: Igor Opaniuk > --- > > cmd/md5sum.c | 149 --- > 1 file changed, 9 insertions(+), 140 deletions(-) This breaks building of imx8mm_phg. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] cli: allow users to disable history if unused at all
On Sat, Feb 17, 2024 at 09:54:43PM +0800, Hanyuan Zhao wrote: > This commit allows user to determine whether to have history recording > in command-line. Previously the history data as uninitialized static > array would not directly take much space in binary file since it only > marks size in the binary. However now it asks to allocate space. By > connecting the original CMD_HISTORY flag in Kconfig, users could unset > the whole history function, and the memory usage could be eased, if the > history function is not used at all. > > Signed-off-by: Hanyuan Zhao > --- > cmd/Kconfig | 1 + > common/cli_readline.c | 44 --- > 2 files changed, 26 insertions(+), 19 deletions(-) This breaks current tests, please re-test, thanks. -- Tom signature.asc Description: PGP signature
Re: [PULL] Please pull qcom/qcom-next
On Fri, Mar 01, 2024 at 03:45:21PM +, Caleb Connolly wrote: > Hi Tom, > > I know Sumits dt-rebasing series just landed, so the timing isn't fantastic > with > this series importing a bunch of DT stuff from Linux. However we've had two > new > contributors this week adding new Qualcomm boards - I'd really like to get > this rework in so those folks aren't blocked on it and we can get out of this > limbo state. > > I'll follow this up with a switch to OF_UPSTREAM asap! > > Thanks and regards, > // Caleb > > The following changes since commit 5b825032957c2613ef2f8f639e949ae02cb5bdff: > > Merge patch series "An effort to bring DT bindings compliance within > U-Boot" (2024-02-29 22:24:23 -0500) > > are available in the Git repository at: > > g...@source.denx.de:/u-boot/custodians/u-boot-snapdragon.git HEAD > > for you to fetch changes up to cbf3152f6afff25c25aa69ae06488671ca0aa765: > > clk/qcom: apq8016: allow apq8016_clk_init_uart() to be called externally > (2024-03-01 15:08:59 +) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/8] clk: qcom: add driver for SM8150 SoC
Hi Caleb,
Caleb Connolly writes:
> On 29/02/2024 14:21, Volodymyr Babchuk wrote:
>> Add clock, reset and power domain driver for SM8150. Driver code is
>> based on the similar U-Boot drivers. All constants are taken from the
>> corresponding Linux driver.
>>
>> This driver supports clock rate setting only for the debug UART and
>> RGMII/Ethernet modules, because this is all I can test right now.
>>
>> Signed-off-by: Volodymyr Babchuk
>> ---
>>
>> drivers/clk/qcom/Kconfig| 8 ++
>> drivers/clk/qcom/Makefile | 1 +
>> drivers/clk/qcom/clock-qcom.h | 1 +
>> drivers/clk/qcom/clock-sm8150.c | 234
>> 4 files changed, 244 insertions(+)
>> create mode 100644 drivers/clk/qcom/clock-sm8150.c
>>
>> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
>> index 0df0d1881a..18ccf6a45e 100644
>> --- a/drivers/clk/qcom/Kconfig
>> +++ b/drivers/clk/qcom/Kconfig
>> @@ -47,6 +47,14 @@ config CLK_QCOM_SDM845
>>on the Snapdragon 845 SoC. This driver supports the clocks
>>and resets exposed by the GCC hardware block.
>>
>> +config CLK_QCOM_SM8150
>> +bool "Qualcomm SM8150 GCC"
>> +select CLK_QCOM
>> +help
>> + Say Y here to enable support for the Global Clock Controller
>> + on the Snapdragon 8150 SoC. This driver supports the clocks
>> + and resets exposed by the GCC hardware block.
>> +
>> endmenu
>>
>> endif
>> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
>> index cb179fdac5..12c09ba19e 100644
>> --- a/drivers/clk/qcom/Makefile
>> +++ b/drivers/clk/qcom/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8016) += clock-apq8016.o
>> obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
>> obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
>> obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
>> +obj-$(CONFIG_CLK_QCOM_SM8150) += clock-sm8150.o
>> diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
>> index 12a1eaec2b..41107df216 100644
>> --- a/drivers/clk/qcom/clock-qcom.h
>> +++ b/drivers/clk/qcom/clock-qcom.h
>> @@ -9,6 +9,7 @@
>>
>> #define CFG_CLK_SRC_CXO (0 << 8)
>> #define CFG_CLK_SRC_GPLL0 (1 << 8)
>> +#define CFG_CLK_SRC_GPLL7_MAIN (3 << 8)
> Please follow the existing scheme and remove the _MAIN suffix.
Ah, yes, planned to do this, but looks like lost it when created a final
version of the patch.
> I'd also be fine with converting all of these definitions to follow how
> the Linux drivers name them.
This should be done in the separate patch, I think.
[...]
>> +static int sm8150_clk_enable(struct clk *clk)
>> +{
>> +struct msm_clk_priv *priv = dev_get_priv(clk->dev);
>> +
>> +clk_enable_gpll0(priv->base, _vote_clk);
> This will write to the GPLL for every single clock, I think you're
> missing a switch case block here.
Yes, you are right.
>> +qcom_gate_clk_en(priv, clk->id);
>> +
>> +return 0;
>> +}
>> +
>> +static const struct qcom_reset_map sm8150_gcc_resets[] = {
>> +[GCC_EMAC_BCR] = { 0x6000 },
>> +[GCC_GPU_BCR] = { 0x71000 },
>> +[GCC_MMSS_BCR] = { 0xb000 },
>> +[GCC_NPU_BCR] = { 0x4d000 },
>> +[GCC_PCIE_0_BCR] = { 0x6b000 },
>> +[GCC_PCIE_0_PHY_BCR] = { 0x6c01c },
>> +[GCC_PCIE_1_BCR] = { 0x8d000 },
>> +[GCC_PCIE_1_PHY_BCR] = { 0x8e01c },
>> +[GCC_PCIE_PHY_BCR] = { 0x6f000 },
>> +[GCC_PDM_BCR] = { 0x33000 },
>> +[GCC_PRNG_BCR] = { 0x34000 },
>> +[GCC_QSPI_BCR] = { 0x24008 },
>> +[GCC_QUPV3_WRAPPER_0_BCR] = { 0x17000 },
>> +[GCC_QUPV3_WRAPPER_1_BCR] = { 0x18000 },
>> +[GCC_QUPV3_WRAPPER_2_BCR] = { 0x1e000 },
>> +[GCC_QUSB2PHY_PRIM_BCR] = { 0x12000 },
>> +[GCC_QUSB2PHY_SEC_BCR] = { 0x12004 },
>> +[GCC_USB3_PHY_PRIM_BCR] = { 0x5 },
>> +[GCC_USB3_DP_PHY_PRIM_BCR] = { 0x50008 },
>> +[GCC_USB3_PHY_SEC_BCR] = { 0x5000c },
>> +[GCC_USB3PHY_PHY_SEC_BCR] = { 0x50010 },
>> +[GCC_SDCC2_BCR] = { 0x14000 },
>> +[GCC_SDCC4_BCR] = { 0x16000 },
>> +[GCC_TSIF_BCR] = { 0x36000 },
>> +[GCC_UFS_CARD_BCR] = { 0x75000 },
>> +[GCC_UFS_PHY_BCR] = { 0x77000 },
>> +[GCC_USB30_PRIM_BCR] = { 0xf000 },
>> +[GCC_USB30_SEC_BCR] = { 0x1 },
>> +[GCC_USB_PHY_CFG_AHB2PHY_BCR] = { 0x6a000 },
>> +};
>> +
>> +static const struct qcom_power_map sm8150_gcc_power_domains[] = {
> This is really nice! Certainly better than my approach [1].
> Please reorder the patches so that the power domain driver is added
> before this so we don't break future bisects.
power domain driver is added in the previous patch: "[PATCH 4/8] clk:
qcom: add support for power domains uclass"
>> +[EMAC_GDSC] = { 0x6004 },
>> +[PCIE_0_GDSC] = { 0x6b004 },
>> +[PCIE_1_GDSC] = { 0x8d004 },
>> +[UFS_CARD_GDSC] = { 0x75004 },
>> +[UFS_PHY_GDSC] = { 0x7704 },
>> +[USB30_PRIM_GDSC] = { 0x6004 },
>> +[USB30_SEC_GDSC] = { 0x10004 },
>> +};
>> +
>> +
>> +static struct msm_clk_data sm8150_clk_data = {
>> +.resets = sm8150_gcc_resets,
Re: [PATCH 0/8] Add support for Qualcomm SA8155-ADP board
Hi Caleb, Caleb Connolly writes: > On 29/02/2024 14:21, Volodymyr Babchuk wrote: >> >> This patch series adds support for Qualcomm SA8155-ADP development >> board. Main motivation for this series is to allow running >> virtualization software on this board and U-Boot is a good way to >> break Qualcomm's boot chain at EL2 with more convenient ways for >> uploading and running the code. With this patches applied it is >> possible to upload and run Xen on this board. KVM probably should work >> too. > > This is really cool! I've experimented with this on SDM845 and SM8250 > but never really did anything with it... I'd love to take a look at your > Xen branch? Honestly, there is nothing to look at right now. I just implemented early printk serial driver for the qcom, made hacks to the device tree and trying to boot Dom0. I already expecting issues with the GPU, because it has own SMMU without virtualization support and Xen already complains about it. So I had to remove it from the DTS for a time being. Anyways, right now my Dom0 does not want to boot due to some issues with UFS. I suspect that some power domain or clock is disabled or some other bit of initialization is missing in the mainline Linux. And reason why bare Linux kernel have no issues with UFS is because aboot/xbl does proper UFS initialization, while in my case I am skipping the android bootloader completely... I'll publish my work when I'll get Dom0 running. -- WBR, Volodymyr
Re: [PATCH 5/8] clk: qcom: add driver for SM8150 SoC
>> Please reorder the patches so that the power domain driver is added >> before this so we don't break future bisects. > > power domain driver is added in the previous patch: "[PATCH 4/8] clk: > qcom: add support for power domains uclass" Ah, my mistake! >> >> Just in case it's useful to you, I have some work in progress patches >> for dumping the clock configuration, I hope to upstream these eventually >> but in the mean time you can find them here: > > This is what bothers me now. Looks like I jumped in the middle of your > USB series and Sumit's Qulacom device tree binding series. I don't want > to interfere with the ongoing work, so probably I postpone posting my v2 > unless at least Sumit's series are taken into the mainline. On other > hand, there are couple of patches that are not directly related to the > SM8155P-ADP, like my fix to the clock driver or already mentioned "clk: > qcom: add support for power domains uclass", which you can reuse. So I > can post them separately or you can include them into your series if you > want. What is your opinion? The big conflict is really just the board support stuff and DTS. The other patches would definitely be good to have. Could you rebase this series on top of qcom-next [1]? The big series has gone in now (and should be in U-Boot next shortly) so we shouldn't have to delay yours. Your last patch introducing the board support will conflict, but you don't have any heavily board specific features so it should be pretty easy: * Drop init_sm8150.c and sysmap-sm8150.c (everything they do is handled generically in board.c) * Drop your changes to mach-snapdragon/Kconfig * Delete board/qualcomm/sa8155p-adp/Kconfig * Replace CONFIG_TARGET_SA8155P_ADP=y with CONFIG_SYS_BOARD="sa8155p-adp" in your defconfig * Set CONFIG_SYS_CONFIG_NAME="sa8155p_adp" (or rename the config file to use a '-' instead). It's now possible to use pre-processor directives from defconfigs, so you could also rework your defconfig to #include "qcom_defconfig" and that way only have to define your board specific options, but I guess there isn't much room in the hyp partition so you might not want all the bells and whistles - totally up to you. If you could split this into series, one with your fixes and drivers, and another adding the DTS and board changes I think that would be fine. Regarding the DT stuff, you probably drop your sm8150 DTS patch and instead select OF_UPSTREAM for ARCH_SNAPDRAGON, I'll likely send a patch for this soon. [1]: https://source.denx.de/u-boot/custodians/u-boot-snapdragon > -- // Caleb (they/them)
Re: [PATCH 1/2] opos6uldev: make the LCD work again
On Fri, Mar 01, 2024 at 01:32:53PM +, Conor Dooley wrote:
> Hey,
>
> Replying here because this is only version of this in my inbox atm.
Please note that for additional context, in 2019 when d9aa4d4fca67 ("ARM:
dts: opos6uldev: use OF graph to describe the display") was merged
re-sync of DTS files to U-Boot was a best-effort per platform and
infrequent. As of yesterday we have devicetree-rebasing included as a
git subtree and platforms can and should switch to using that, and that
tree will be updated every U-Boot merge window. So I wanted to ask a
broader question in this thread about how to handle dts changes break
U-Boot functionality, and have an example that wasn't ancient (the
serial problem from 2013 or so) nor incorrect PHY mode was specified in
the dts file to start with. This thread is that example.
> On Fri, Mar 01, 2024 at 10:17:35AM +0100, Sébastien Szymanski wrote:
> > On 3/1/24 07:02, Sumit Garg wrote:
> > > On Thu, 29 Feb 2024 at 19:31, Tom Rini wrote:
> > > > On Thu, Feb 29, 2024 at 08:42:42AM -0500, Tom Rini wrote:
> > > > > On Thu, Feb 29, 2024 at 11:17:28AM +0530, Sumit Garg wrote:
> > > > > > On Wed, 28 Feb 2024 at 20:50, Tom Rini wrote:
> > > > > > > On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> > > > > > > > On Wed, 28 Feb 2024 at 18:40, Tom Rini
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > > > > > > > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien
> > > > > > > > > > Szymanski wrote:
> > > > > > > > > > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device
> > > > > > > > > > > trees with
> > > > > > > > > > > linux") removed the display timings from the board device
> > > > > > > > > > > tree whereas
> > > > > > > > > > > they are still needed by the mxsfb driver.
> > > > > > > > > > > Add the timings back (the correct ones) in the
> > > > > > > > > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from
> > > > > > > > > > > the
> > > > > > > > > > > opos6uldev.env file.
> > > > > > > > > > >
> > > > > > > > > > > Update the opos6uldev_defconfig file so that the LCD
> > > > > > > > > > > turns on at boot.
> > > > > > > > > > >
> > > > > > > > > > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device
> > > > > > > > > > > trees with linux")
> > > > > > > > > > > Signed-off-by: Sébastien Szymanski
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Huh. This is the commit that did that upstream.
> > > > > > > > > >
> > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > > > > > > > > >
> > > > > > > > > > It's interesting how the timings in linux were always
> > > > > > > > > > slightly different
> > > > > > > > > > from in u-boot.
> > > > > > > > >
> > > > > > > > > Thanks for tracking that down, Dan. I'm adding in Sumit and
> > > > > > > > > Rob here
> > > > > > > > > because this is a recent (rather than ancient) example of one
> > > > > > > > > of the
> > > > > > > > > concerns about OF_UPSTREAM.
> > > > > > > >
> > > > > > > > I rather think about this as an opportunity to improve with
> > > > > > > > OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> > > > > > > > corresponding Linux kernel sub-arch maintainers. Especially
> > > > > > > > once we
> > > > > > > > move to OF_UPSTREAM and a sub-arch maintainer profile in Linux
> > > > > > > > kernel
> > > > > > > > to keep them aware that U-Boot should be considered too.
> > > > > > >
> > > > > > > Yes, a more extensive check around when removing information from
> > > > > > > dts
> > > > > > > files would be good.
>
> Whenever people remove things from bindings (or from being required) we
> do ask them "have you checked that there's no users for this outside of
> linux" - but for me at least I don't apply that scrutiny for most (read
> arm{,64}) devicetrees. There's just too much volume if I went asking
> those questions on every removal, it's up to the platform maintainers to
> keep an eye on that.
>
> That said, modifications to a devicetree are fixable with a revert,
> while modifications to a binding may not really be fixable in a way that
> isn't disruptive for some user, so I think that I am spending my time
> wisely.
I agree that so long as reverting dts changes, even after a release
includes them, is possible, it's not the end of the world and we can all
manage.
> > > > > > > > > I think the commit in question can be
> > > > > > > > > summarized as "remove a bunch of explicit HW information
> > > > > > > > > because there's
> > > > > > > > > now a Linux Kernel driver that determines that dynamically".
> > > > > > > > > What do we
> > > > > > > > > do next? The old information is in a presumably valid binding
> > > > > > > > > still, can
> > > > > > > > > we just put it back and comment that consumers outside of
> > > > > > > > > Linux use this
> > > > >
Re: [PATCH 1/2] opos6uldev: make the LCD work again
On Fri, Mar 01, 2024 at 10:17:35AM +0100, Sébastien Szymanski wrote:
> On 3/1/24 07:02, Sumit Garg wrote:
> > On Thu, 29 Feb 2024 at 19:31, Tom Rini wrote:
> > >
> > > On Thu, Feb 29, 2024 at 08:42:42AM -0500, Tom Rini wrote:
> > > > On Thu, Feb 29, 2024 at 11:17:28AM +0530, Sumit Garg wrote:
> > > > > On Wed, 28 Feb 2024 at 20:50, Tom Rini wrote:
> > > > > >
> > > > > > On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> > > > > > > + Shawn, Krzysztof, Conor
> > > > > > >
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Wed, 28 Feb 2024 at 18:40, Tom Rini wrote:
> > > > > > > >
> > > > > > > > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > > > > > > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski
> > > > > > > > > wrote:
> > > > > > > > > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device
> > > > > > > > > > trees with
> > > > > > > > > > linux") removed the display timings from the board device
> > > > > > > > > > tree whereas
> > > > > > > > > > they are still needed by the mxsfb driver.
> > > > > > > > > > Add the timings back (the correct ones) in the
> > > > > > > > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > > > > > > > > opos6uldev.env file.
> > > > > > > > > >
> > > > > > > > > > Update the opos6uldev_defconfig file so that the LCD turns
> > > > > > > > > > on at boot.
> > > > > > > > > >
> > > > > > > > > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device
> > > > > > > > > > trees with linux")
> > > > > > > > > > Signed-off-by: Sébastien Szymanski
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Huh. This is the commit that did that upstream.
> > > > > > > > >
> > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > > > > > > > >
> > > > > > > > > It's interesting how the timings in linux were always
> > > > > > > > > slightly different
> > > > > > > > > from in u-boot.
> > > > > > > >
> > > > > > > > Thanks for tracking that down, Dan. I'm adding in Sumit and Rob
> > > > > > > > here
> > > > > > > > because this is a recent (rather than ancient) example of one
> > > > > > > > of the
> > > > > > > > concerns about OF_UPSTREAM.
> > > > > > >
> > > > > > > I rather think about this as an opportunity to improve with
> > > > > > > OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> > > > > > > corresponding Linux kernel sub-arch maintainers. Especially once
> > > > > > > we
> > > > > > > move to OF_UPSTREAM and a sub-arch maintainer profile in Linux
> > > > > > > kernel
> > > > > > > to keep them aware that U-Boot should be considered too.
> > > > > >
> > > > > > Yes, a more extensive check around when removing information from
> > > > > > dts
> > > > > > files would be good.
> > > > > >
> > > > > > > > I think the commit in question can be
> > > > > > > > summarized as "remove a bunch of explicit HW information
> > > > > > > > because there's
> > > > > > > > now a Linux Kernel driver that determines that dynamically".
> > > > > > > > What do we
> > > > > > > > do next? The old information is in a presumably valid binding
> > > > > > > > still, can
> > > > > > > > we just put it back and comment that consumers outside of Linux
> > > > > > > > use this
> > > > > > > > still so it's not removed again later? Or am I just missing
> > > > > > > > where we can
> > > > > > > > instead get this information from the DT still and not need to
> > > > > > > > come up
> > > > > > > > with a new driver and subsystems?
> > > > > > >
> > > > > > > I can see following two paths forward:
> > > > > > >
> > > > > > > 1) Partially revert the Linux kernel commit to add back the
> > > > > > > display
> > > > > > > timings in DT.
> > > > > > > 2) Extend drivers/video/simple_panel.c in U-Boot to add support
> > > > > > > for
> > > > > > > compatible: "armadeus,st0700-adapt".
> > > > > > >
> > > > > > > If possible then I would be in favour of (2) rather than the
> > > > > > > current
> > > > > > > patch to do this properly.
> > > > > >
> > > > > > Well, looking at the kernel drivers/gpu/drm/panel/panel-simple.c
> > > > > > driver
> > > > > > and then our drivers/video/simple_panel.c it sure would be nice if
> > > > > > it's
> > > > > > just a matter of adding a compatible but I wouldn't be surprised if
> > > > > > it
> > > > > > ends up needing more information being passed along too?
> > > > >
> > > > > Although I am not a LCD panel expert but looking at the kernel driver
> > > > > code [1], the display timings are rather taken from a static data
> > > > > structure matching the compatible "armadeus,st0700-adapt".
> > > > >
> > > > > [1]
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c#n901
> > > >
> > > > Yes. My point is that it seems like the situation changed from "device
> > > > tree provides timings for the
Re: [PATCH] arm: dts: k3-am625-verdin-r5: Change CPU frequency to 1000MHz
On Mon, Feb 19, 2024 at 12:34:08PM +, Vitor Soares wrote: > From: Vitor Soares > > The same U-Boot binary is compatible with multiple Verdin AM62 board > variants. However, some of the SoC models can only operate at a maximum > speed of 1 GHz. > > Previously, the boards with lower-speed grades were running at > overclocked speeds, leading to kernel complaints about unsupported > configurations. > > To resolve this issue, the operating speed has been decreased to the > maximum allowable value across all Verdin AM62 board variants. As a > result, there is a regression in overall boot time, increasing by around > 200 milliseconds for the faster SoC variant. > > Signed-off-by: Vitor Soares > Reviewed-by: Francesco Dolcini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] arm: mach-k3: Refactor QoS settings
On Mon, Feb 12, 2024 at 03:36:35PM +0530, Aradhya Bhatia wrote: > Refactor common QoS code into a new common header file, and the soc > specific setup_qos functions into a common API. > > Rename $(soc)_qos_count and $(soc)_qos_data variables to qos_count and > qos_data. When QoS settings of more SoCs are added, only one pair will > be defined at a time, based on the config SOC_K3_$(soc). > > This refactoring has been done for 2 major purposes. > > - The auto-generated $(soc)_qos_data.c and $(soc)_qos.h files cannot > have any code that is specific to any bootloader. Those files have to > remain agnostic of different bootloader implementations and their > header files. > > - The existing implementation was less than ideal and would have enabled > multiple $(soc)_qos_count and $(soc)_qos_data variables for all SoC > variants. > > Signed-off-by: Aradhya Bhatia Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] pylibfdt: Fix "invalid escape sequence '\w'" in setup.py
On Tue, Feb 20, 2024 at 08:52:48AM -0500, Tom Rini wrote:
> From: Florian Schmaus
>
> Once u-boot's build system invokes
>
> python3 scripts/dtc/pylibfdt/setup.py --quiet build_ext --inplace
>
> it may fail with
>
> scripts/dtc/pylibfdt/setup.py:40: SyntaxWarning: invalid escape sequence '\w'
> RE_KEY_VALUE = re.compile('(?P\w+) *(?P[+])?= *(?P.*)$')
>
> depending on the used Python version.
>
> Explicitly mark the regex string as raw string to avoid the warning.
>
> Signed-off-by: Florian Schmaus
> Reviewed-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] dtoc: avoid invalid escape sequence '\s'
On Tue, Feb 27, 2024 at 10:51:38PM +0100, Heinrich Schuchardt wrote: > \s is not a valid escape sequence in strings. > Mark regular expressions with r''. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/7] toradex: fix reset and hardware detection regressions
On Fri, 23 Feb 2024 10:11:36 +0100, Francesco Dolcini wrote: > From: Francesco Dolcini > > This series fixes two regressions affecting multiple Toradex boards > (i.MX, TI and TEGRA based) and targets the current master, e.g. v2024.04 > release. > > U-Boot `reset` command is broken on all Tordex i.MX6* based SoMs since > v2023.07, this series fixes it enabling the `wdt-reboot` driver. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 0/8] Add support for Qualcomm SA8155-ADP board
On 01/03/2024 18:25, Volodymyr Babchuk wrote: > > Hi Caleb, > > Caleb Connolly writes: > >> On 29/02/2024 14:21, Volodymyr Babchuk wrote: >>> >>> This patch series adds support for Qualcomm SA8155-ADP development >>> board. Main motivation for this series is to allow running >>> virtualization software on this board and U-Boot is a good way to >>> break Qualcomm's boot chain at EL2 with more convenient ways for >>> uploading and running the code. With this patches applied it is >>> possible to upload and run Xen on this board. KVM probably should work >>> too. >> >> This is really cool! I've experimented with this on SDM845 and SM8250 >> but never really did anything with it... I'd love to take a look at your >> Xen branch? > > Honestly, there is nothing to look at right now. I just implemented > early printk serial driver for the qcom, made hacks to the device tree > and trying to boot Dom0. I already expecting issues with the GPU, > because it has own SMMU without virtualization support and Xen already > complains about it. So I had to remove it from the DTS for a time being. Hmm, I see. You'll also definitely start running into issues with the DSPs and probably anything else that loads firmware. Qualcomm's hypervisor seems to be involved in booting a lot of the peripherals. The sc7180 Chromebook support is probably a good reference for how to do this in Linux as they also run in EL2. > > Anyways, right now my Dom0 does not want to boot due to some issues with > UFS. I suspect that some power domain or clock is disabled or some > other bit of initialization is missing in the mainline Linux. And > reason why bare Linux kernel have no issues with UFS is because > aboot/xbl does proper UFS initialization, while in my case I am skipping > the android bootloader completely... Oh that's always fun... > > I'll publish my work when I'll get Dom0 running. For sure, I'd love to try it out! It's really exciting to know you're working on this :D > -- // Caleb (they/them)
Re: [PATCH 5/8] clk: qcom: add driver for SM8150 SoC
On 29/02/2024 14:21, Volodymyr Babchuk wrote:
> Add clock, reset and power domain driver for SM8150. Driver code is
> based on the similar U-Boot drivers. All constants are taken from the
> corresponding Linux driver.
>
> This driver supports clock rate setting only for the debug UART and
> RGMII/Ethernet modules, because this is all I can test right now.
>
> Signed-off-by: Volodymyr Babchuk
> ---
>
> drivers/clk/qcom/Kconfig| 8 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clock-qcom.h | 1 +
> drivers/clk/qcom/clock-sm8150.c | 234
> 4 files changed, 244 insertions(+)
> create mode 100644 drivers/clk/qcom/clock-sm8150.c
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 0df0d1881a..18ccf6a45e 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -47,6 +47,14 @@ config CLK_QCOM_SDM845
> on the Snapdragon 845 SoC. This driver supports the clocks
> and resets exposed by the GCC hardware block.
>
> +config CLK_QCOM_SM8150
> + bool "Qualcomm SM8150 GCC"
> + select CLK_QCOM
> + help
> + Say Y here to enable support for the Global Clock Controller
> + on the Snapdragon 8150 SoC. This driver supports the clocks
> + and resets exposed by the GCC hardware block.
> +
> endmenu
>
> endif
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index cb179fdac5..12c09ba19e 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8016) += clock-apq8016.o
> obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
> obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
> obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
> +obj-$(CONFIG_CLK_QCOM_SM8150) += clock-sm8150.o
> diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
> index 12a1eaec2b..41107df216 100644
> --- a/drivers/clk/qcom/clock-qcom.h
> +++ b/drivers/clk/qcom/clock-qcom.h
> @@ -9,6 +9,7 @@
>
> #define CFG_CLK_SRC_CXO (0 << 8)
> #define CFG_CLK_SRC_GPLL0 (1 << 8)
> +#define CFG_CLK_SRC_GPLL7_MAIN (3 << 8)
Please follow the existing scheme and remove the _MAIN suffix.
I'd also be fine with converting all of these definitions to follow how
the Linux drivers name them.
> #define CFG_CLK_SRC_GPLL0_EVEN (6 << 8)
> #define CFG_CLK_SRC_MASK (7 << 8)
>
> diff --git a/drivers/clk/qcom/clock-sm8150.c b/drivers/clk/qcom/clock-sm8150.c
> new file mode 100644
> index 00..e23dbccdd3
> --- /dev/null
> +++ b/drivers/clk/qcom/clock-sm8150.c
> @@ -0,0 +1,234 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Clock drivers for Qualcomm SM8150
> + *
> + * Volodymyr Babchuk
> + * Copyright (c) 2024 EPAM Systems.
> + *
> + * Based on U-Boot driver for SDM845. Constants are taken from the Linux
> driver.
> + */
> +
> +#include
> +#include
> +#include
This header is unused
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clock-qcom.h"
> +
> +static struct pll_vote_clk gpll7_vote_clk = {
> + .status = 0x1a000,
> + .status_bit = BIT(31),
> + .ena_vote = 0x52000,
> + .vote_bit = BIT(7),
> +};
> +
> +static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
> + F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
> + F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
> + F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> + F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
> + F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
> + F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
> + F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
> + F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
> + F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
> + F(1, CFG_CLK_SRC_GPLL0_EVEN, 3, 0, 0),
> + F(10240, CFG_CLK_SRC_GPLL0_EVEN, 1, 128, 375),
> + F(11200, CFG_CLK_SRC_GPLL0_EVEN, 1, 28, 75),
> + F(117964800, CFG_CLK_SRC_GPLL0_EVEN, 1, 6144, 15625),
> + F(12000, CFG_CLK_SRC_GPLL0_EVEN, 2.5, 0, 0),
> + F(12800, CFG_CLK_SRC_GPLL0, 1, 16, 75),
> + { }
> +};
> +
> +static const struct freq_tbl ftbl_gcc_emac_rgmii_clk_src[] = {
> + F(250, CFG_CLK_SRC_CXO, 1, 25, 192),
> + F(500, CFG_CLK_SRC_CXO, 1, 25, 96),
> + F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> + F(2500, CFG_CLK_SRC_GPLL0_EVEN, 12, 0, 0),
> + F(5000, CFG_CLK_SRC_GPLL0_EVEN, 6, 0, 0),
> + F(12500, CFG_CLK_SRC_GPLL7_MAIN, 4, 0, 0),
> + F(25000, CFG_CLK_SRC_GPLL7_MAIN, 2, 0, 0),
> + { }
> +};
> +
> +static const struct bcr_regs uart2_regs = {
> + .cfg_rcgr = 0x1814C,
> + .cmd_rcgr = 0x18148,
> + .M = 0x18150,
> + .N = 0x18154,
> + .D = 0x18158,
> +};
> +
> +static const struct bcr_regs rgmii_regs = {
> + .cfg_rcgr = 0x6020,
> + .cmd_rcgr = 0x601C,
> + .M = 0x6024,
> + .N = 0x6028,
> + .D = 0x602C,
> +};
> +
> +static ulong sm8150_clk_set_rate(struct clk
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
Hi Sumit, On Fri, Mar 1, 2024 at 9:57 AM Tom Rini wrote: > > On Thu, 22 Feb 2024 15:05:56 +0530, Sumit Garg wrote: > > > Changes in v6: > > -- > > - v6_dt: https://github.com/b49020/u-boot/tree/v6_dt > > - Patch #3: Incorporate fix for sandbox CI failure. > > - Patch #6: Incorporate shell script comments from Marek. > > - Patch #8: Incorporate documentation review comments from Paul. > > > > [...] > > Applied to u-boot/next, thanks! I am trying to use OF_UPSTREAM with imx8mp_evk_defconfig: diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig index 328c3e388051..29d0c5ce6485 100644 --- a/arch/arm/mach-imx/imx8m/Kconfig +++ b/arch/arm/mach-imx/imx8m/Kconfig @@ -8,6 +8,7 @@ config IMX8M select LTO select ROM_UNIFIED_SECTIONS select ARMV8_CRYPTO + imply OF_UPSTREAM config IMX8MQ bool diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig index 2350d2f409b7..cdf840c683c0 100644 --- a/configs/imx8mp_evk_defconfig +++ b/configs/imx8mp_evk_defconfig @@ -8,7 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_OFFSET=0x40 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="imx8mp-evk" +CONFIG_DEFAULT_DEVICE_TREE="freescale/imx8mp-evk" CONFIG_SPL_TEXT_BASE=0x92 CONFIG_TARGET_IMX8MP_EVK=y CONFIG_SYS_MONITOR_LEN=524288 I ran "./dts/update-dts-subtree.sh pull v6.8-rc6-dts". make mrproper make imx8mp_evk_defconfig make The dtb is built: dts/upstream/src/arm64/freescale/imx8mp-evk.dtb but mkimage still looks for the old path: MKIMAGE u-boot.img ./tools/mkimage: Can't open arch/arm/dts/freescale/imx8mp-evk.dtb: No such file or directory ./tools/mkimage: failed to build FIT Any suggestions? Thanks
Re: [PATCH 6/8] pinctr: qcom: pass pin number to get_function_mux callback
On 29/02/2024 14:21, Volodymyr Babchuk wrote:
> This patch is the preparation for SM8150 support. This new SoC
> depending on the particular pin can have different numbers for the
> same function. For example "rgmii" function for GPIO4 has id=2 while
> for GPIO59 it has id=1. So, to support this type of SoCs,
> get_function_mux() callback needs to know for which pin the function
> is requested.
>
> Signed-off-by: Volodymyr Babchuk
Reviewed-by: Caleb Connolly
> ---
>
> drivers/pinctrl/qcom/pinctrl-apq8016.c | 3 ++-
> drivers/pinctrl/qcom/pinctrl-apq8096.c | 3 ++-
> drivers/pinctrl/qcom/pinctrl-ipq4019.c | 3 ++-
> drivers/pinctrl/qcom/pinctrl-qcom.c| 4 ++--
> drivers/pinctrl/qcom/pinctrl-qcom.h| 3 ++-
> drivers/pinctrl/qcom/pinctrl-qcs404.c | 3 ++-
> drivers/pinctrl/qcom/pinctrl-sdm845.c | 3 ++-
> 7 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c
> b/drivers/pinctrl/qcom/pinctrl-apq8016.c
> index 8149ffd83c..53042b6e05 100644
> --- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
> +++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
> @@ -49,7 +49,8 @@ static const char *apq8016_get_pin_name(struct udevice *dev,
> }
> }
>
> -static unsigned int apq8016_get_function_mux(unsigned int selector)
> +static unsigned int apq8016_get_function_mux(__maybe_unused unsigned int pin,
> + unsigned int selector)
> {
> return msm_pinctrl_functions[selector].val;
> }
> diff --git a/drivers/pinctrl/qcom/pinctrl-apq8096.c
> b/drivers/pinctrl/qcom/pinctrl-apq8096.c
> index d64ab1ff7b..8dcd171259 100644
> --- a/drivers/pinctrl/qcom/pinctrl-apq8096.c
> +++ b/drivers/pinctrl/qcom/pinctrl-apq8096.c
> @@ -44,7 +44,8 @@ static const char *apq8096_get_pin_name(struct udevice *dev,
> }
> }
>
> -static unsigned int apq8096_get_function_mux(unsigned int selector)
> +static unsigned int apq8096_get_function_mux(__maybe_unused unsigned int pin,
> + unsigned int selector)
> {
> return msm_pinctrl_functions[selector].val;
> }
> diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> index 2d99f99e1e..c2c358f556 100644
> --- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> +++ b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> @@ -40,7 +40,8 @@ static const char *ipq4019_get_pin_name(struct udevice *dev,
> return pin_name;
> }
>
> -static unsigned int ipq4019_get_function_mux(unsigned int selector)
> +static unsigned int ipq4019_get_function_mux(__maybe_unused unsigned int pin,
> + unsigned int selector)
> {
> return msm_pinctrl_functions[selector].val;
> }
> diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c
> b/drivers/pinctrl/qcom/pinctrl-qcom.c
> index dc3d8c4d90..de0bb4de0a 100644
> --- a/drivers/pinctrl/qcom/pinctrl-qcom.c
> +++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
> @@ -82,10 +82,10 @@ static int msm_pinmux_set(struct udevice *dev, unsigned
> int pin_selector,
> unsigned int func_selector)
> {
> struct msm_pinctrl_priv *priv = dev_get_priv(dev);
> + u32 func = priv->data->get_function_mux(pin_selector, func_selector);
>
> clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
> - TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE,
> - priv->data->get_function_mux(func_selector) << 2);
> + TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE, func << 2);
> return 0;
> }
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.h
> b/drivers/pinctrl/qcom/pinctrl-qcom.h
> index 07f2eae9ba..49b7bfbc00 100644
> --- a/drivers/pinctrl/qcom/pinctrl-qcom.h
> +++ b/drivers/pinctrl/qcom/pinctrl-qcom.h
> @@ -18,7 +18,8 @@ struct msm_pinctrl_data {
> int functions_count;
> const char *(*get_function_name)(struct udevice *dev,
>unsigned int selector);
> - unsigned int (*get_function_mux)(unsigned int selector);
> + unsigned int (*get_function_mux)(unsigned int pin,
> + unsigned int selector);
> const char *(*get_pin_name)(struct udevice *dev,
> unsigned int selector);
> };
> diff --git a/drivers/pinctrl/qcom/pinctrl-qcs404.c
> b/drivers/pinctrl/qcom/pinctrl-qcs404.c
> index ac00afa2a1..977f7b2ac3 100644
> --- a/drivers/pinctrl/qcom/pinctrl-qcs404.c
> +++ b/drivers/pinctrl/qcom/pinctrl-qcs404.c
> @@ -56,7 +56,8 @@ static const char *qcs404_get_pin_name(struct udevice *dev,
> }
> }
>
> -static unsigned int qcs404_get_function_mux(unsigned int selector)
> +static unsigned int qcs404_get_function_mux(__maybe_unused unsigned int pin,
> + unsigned int selector)
> {
> return msm_pinctrl_functions[selector].val;
> }
> diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
>
Re: [PATCH 0/8] Add support for Qualcomm SA8155-ADP board
On 29/02/2024 14:21, Volodymyr Babchuk wrote: > > This patch series adds support for Qualcomm SA8155-ADP development > board. Main motivation for this series is to allow running > virtualization software on this board and U-Boot is a good way to > break Qualcomm's boot chain at EL2 with more convenient ways for > uploading and running the code. With this patches applied it is > possible to upload and run Xen on this board. KVM probably should work > too. This is really cool! I've experimented with this on SDM845 and SM8250 but never really did anything with it... I'd love to take a look at your Xen branch? > > I added myself as a maintainer for this board, but my abilities to > maintain it are quite limited as I have no access to Qualcomm > documentation. I used mostly Linux drivers as the source for > device-specific information, like register addresses and offsets. > If anyone wants to maintain this, I will gladly agree. > > > Volodymyr Babchuk (8): > clk: qcom: clear div mask before assigning new divider > dts: qcom: import device trees and bindings for SA8155P-ADP > net: dw_eth_qos: add support for Qualcomm SM8150 SoC > clk: qcom: add support for power domains uclass > clk: qcom: add driver for SM8150 SoC > pinctr: qcom: pass pin number to get_function_mux callback > pinctrl: qcom: add driver for SM8150 SoC > board: add support for Qualcomm SA8155P-ADP board > > arch/arm/dts/pmm8155au_1.dtsi | 135 + > arch/arm/dts/pmm8155au_2.dtsi | 108 + > arch/arm/dts/sa8155p-adp-u-boot.dtsi | 30 + > arch/arm/dts/sa8155p-adp.dts | 606 ++ > arch/arm/dts/sa8155p.dtsi | 40 + > arch/arm/dts/sm8150.dtsi | 5293 + > arch/arm/mach-snapdragon/Kconfig | 14 + > arch/arm/mach-snapdragon/Makefile |2 + > arch/arm/mach-snapdragon/init_sa8155p.c | 30 + > arch/arm/mach-snapdragon/sysmap-sm8150.c | 31 + > board/qualcomm/sa8155p-adp/Kconfig| 12 + > board/qualcomm/sa8155p-adp/MAINTAINERS|6 + > configs/sa8155p_adp_defconfig | 33 + > doc/board/qualcomm/index.rst |1 + > doc/board/qualcomm/sa8155p-adp.rst| 94 + > drivers/clk/qcom/Kconfig |8 + > drivers/clk/qcom/Makefile |1 + > drivers/clk/qcom/clock-qcom.c | 96 +- > drivers/clk/qcom/clock-qcom.h |7 + > drivers/clk/qcom/clock-sm8150.c | 234 + > drivers/net/dwc_eth_qos.c |4 + > drivers/net/dwc_eth_qos.h |2 + > drivers/net/dwc_eth_qos_qcom.c| 47 +- > drivers/pinctrl/qcom/Kconfig |7 + > drivers/pinctrl/qcom/Makefile |1 + > drivers/pinctrl/qcom/pinctrl-apq8016.c|3 +- > drivers/pinctrl/qcom/pinctrl-apq8096.c|3 +- > drivers/pinctrl/qcom/pinctrl-ipq4019.c|3 +- > drivers/pinctrl/qcom/pinctrl-qcom.c |4 +- > drivers/pinctrl/qcom/pinctrl-qcom.h |3 +- > drivers/pinctrl/qcom/pinctrl-qcs404.c |3 +- > drivers/pinctrl/qcom/pinctrl-sdm845.c |3 +- > drivers/pinctrl/qcom/pinctrl-sm8150.c | 589 ++ > include/configs/sa8155p_adp.h | 25 + > .../dt-bindings/clock/qcom,dispcc-sm8150.h| 76 + > include/dt-bindings/clock/qcom,gcc-sm8150.h | 252 + > include/dt-bindings/clock/qcom,gpucc-sm8150.h | 33 + > include/dt-bindings/clock/qcom,rpmh.h | 37 + > include/dt-bindings/dma/qcom-gpi.h| 11 + > include/dt-bindings/firmware/qcom,scm.h | 39 + > include/dt-bindings/iio/qcom,spmi-vadc.h | 303 + > .../dt-bindings/interconnect/qcom,osm-l3.h| 15 + > .../dt-bindings/interconnect/qcom,sm8150.h| 159 + > include/dt-bindings/phy/phy-qcom-qmp.h| 20 + > include/dt-bindings/power/qcom-rpmpd.h| 412 ++ > .../regulator/qcom,rpmh-regulator.h | 36 + > include/dt-bindings/soc/qcom,rpmh-rsc.h | 14 + > 47 files changed, 8866 insertions(+), 19 deletions(-) > create mode 100644 arch/arm/dts/pmm8155au_1.dtsi > create mode 100644 arch/arm/dts/pmm8155au_2.dtsi > create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi > create mode 100644 arch/arm/dts/sa8155p-adp.dts > create mode 100644 arch/arm/dts/sa8155p.dtsi > create mode 100644 arch/arm/dts/sm8150.dtsi > create mode 100644 arch/arm/mach-snapdragon/init_sa8155p.c > create mode 100644 arch/arm/mach-snapdragon/sysmap-sm8150.c > create mode 100644 board/qualcomm/sa8155p-adp/Kconfig > create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS > create mode 100644 configs/sa8155p_adp_defconfig > create mode 100644 doc/board/qualcomm/sa8155p-adp.rst > create mode 100644 drivers/clk/qcom/clock-sm8150.c > create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8150.c
Re: [PATCH] dts: imx8mm: Add optee entry for binman
On Fri, Mar 1, 2024 at 4:00 AM Manuel Traut wrote:
>
> Used to embed the OPTEE OS binary into flash.bin so it can be
> detected and loaded by trusted-firmware-arm.
>
> Signed-off-by: Manuel Traut
> ---
> arch/arm/dts/imx8mm-u-boot.dtsi | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
> index 06f2f73a03..8ca4515c9f 100644
> --- a/arch/arm/dts/imx8mm-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-u-boot.dtsi
> @@ -130,6 +130,22 @@
> type = "atf-bl31";
> };
> };
> +
> +#ifdef CONFIG_OPTEE
> + optee {
> + description = "OP-TEE";
> + type = "firmware";
> + arch = "arm";
> + os = "tee";
> + compression = "none";
> + load = <0xbe00>;
> + entry = <0xbe00>;
> +
> + blob-ext {
> + filename =
> "tee.bin";
> + };
> + };
> +#endif
> #endif
>
> binman_fip: fip {
> @@ -160,7 +176,11 @@
> fdt = "fdt-SEQ";
> firmware = "uboot";
> #ifndef CONFIG_ARMV8_PSCI
> +#ifdef CONFIG_OPTEE
> + loadables = "atf", "optee";
> +#else
> loadables = "atf";
> +#endif
> #endif
> };
> };
> --
> 2.43.0
>
Hi Manuel,
The load/entry address of 0xbe00 you are using is only appropriate
for a 2GiB DRAM config. You need to ensure that BL32_BASE used when
building the ATF and CFG_TZDRAM_START used when building OPTEE match
this address.
I have some documentation on this at [1] which assumes you have the
patch I added [2] to our downstream U-Boot to put the address in a
configurable variable
I submitted something similar a while back that does what your trying
to do for imx8mm/imx8mn/imx8mp via a new config variable but the
variable caused some issue [3] and needed some rework.
Could you look at that or explain to me why 0xbe00 could work in
all DRAM size cases?
Best Regards,
Tim
[1] https://trac.gateworks.com/wiki/venice/secure_boot#OP-TEEonvenice
[2]
https://github.com/Gateworks/uboot-venice/commit/0bfe0f8155dc9c4f8ec370c5cbdd2731b40c0c14
[3] https://lists.denx.de/pipermail/u-boot/2023-July/522513.html
Re: [PATCH 1/8] clk: qcom: clear div mask before assigning new divider
On 29/02/2024 14:21, Volodymyr Babchuk wrote: > We need to do this to ensure that new divider is applied "The current behaviour does a bitwise OR of the previous and new divider values, this is wrong." > correctly. This fixes potential issue with 1Gbit ethernet on > SA8155P-ADP boards. Wow, that's a subtle one! > > Signed-off-by: Volodymyr Babchuk Small nit with the wording, otherwise Reviewed-by: Caleb Connolly > --- > > drivers/clk/qcom/clock-qcom.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c > index 7c683e5192..729d190c54 100644 > --- a/drivers/clk/qcom/clock-qcom.c > +++ b/drivers/clk/qcom/clock-qcom.c > @@ -117,7 +117,8 @@ void clk_rcg_set_rate_mnd(phys_addr_t base, const struct > bcr_regs *regs, > > /* setup src select and divider */ > cfg = readl(base + regs->cfg_rcgr); > - cfg &= ~(CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK); > + cfg &= ~(CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK | > + CFG_SRC_DIV_MASK); > cfg |= source & CFG_SRC_SEL_MASK; /* Select clock source */ > > if (div) -- // Caleb (they/them)
[PULL] Please pull qcom/qcom-next
Hi Tom, I know Sumits dt-rebasing series just landed, so the timing isn't fantastic with this series importing a bunch of DT stuff from Linux. However we've had two new contributors this week adding new Qualcomm boards - I'd really like to get this rework in so those folks aren't blocked on it and we can get out of this limbo state. I'll follow this up with a switch to OF_UPSTREAM asap! Thanks and regards, // Caleb The following changes since commit 5b825032957c2613ef2f8f639e949ae02cb5bdff: Merge patch series "An effort to bring DT bindings compliance within U-Boot" (2024-02-29 22:24:23 -0500) are available in the Git repository at: g...@source.denx.de:/u-boot/custodians/u-boot-snapdragon.git HEAD for you to fetch changes up to cbf3152f6afff25c25aa69ae06488671ca0aa765: clk/qcom: apq8016: allow apq8016_clk_init_uart() to be called externally (2024-03-01 15:08:59 +) Caleb Connolly (40): arm: init: export prev_bl_fdt_addr usb: dwc3-generic: support external vbus regulator mmc: msm_sdhci: use modern clock handling dt-bindings: drop msm_sdhci binding clk/qcom: use upstream compatible properties clock/qcom: qcs404: fix clk_set_rate serial: msm: add debug UART serial: msm: fix clock handling and pinctrl gpio: qcom_pmic: 1-based GPIOs gpio: qcom_pmic: add a quirk to skip GPIO configuration gpio: qcom_pmic: add pinctrl driver sandbox: dts: fix qcom pmic gpio pinctrl: qcom: stub support for special GPIOs pinctrl: qcom: fix DT compatibility pinctrl: qcom: apq8016: init pre-reloaction board: dragonboard410c: add chainloaded config fragment board: dragonboard410c: upstream DT compat board: dragonboard410c: import board code from mach-snapdragon board: dragonboard820c: use LINUX_KERNEL_IMAGE_HEADER mach-snapdragon: generalise board support mach-snapdragon: dynamic load addresses mach-snapdragon: generate fdtfile automatically mach-snapdragon: carve out no-map regions board: qcs404-evb: drop board code doc: board/qualcomm: document generic targets doc: board/qualcomm: link to APQ8016 TRM dt-bindings: import headers for SDM845 dts: sdm845: import supporting dtsi files dts: sdm845: replace with upstream DTS dt-bindings: import headers for MSM8916 dts: msm8916: import PMIC dtsi files dts: msm8916: replace with upstream DTS dt-bindings: import headers for MSM8996 dts: msm8996: import PMIC dtsi files dts: dragonboard820c: use correct bindings for clocks dts: msm8996: replace with upstream DTS dt-bindings: import headers for qcs404 dts: qcs404-evb: replace with upstream DT MAINTAINERS: Qualcomm: add some missing paths clk/qcom: apq8016: allow apq8016_clk_init_uart() to be called externally MAINTAINERS| 12 +- arch/arm/Kconfig |4 + arch/arm/dts/Makefile |9 +- arch/arm/dts/apq8016-sbc-u-boot.dtsi | 20 + arch/arm/dts/apq8016-sbc.dts | 729 +++ arch/arm/dts/apq8096-db820c-u-boot.dtsi| 14 + arch/arm/dts/apq8096-db820c.dts| 1137 arch/arm/dts/dragonboard410c-uboot.dtsi| 44 - arch/arm/dts/dragonboard410c.dts | 209 - arch/arm/dts/dragonboard820c-uboot.dtsi| 32 - arch/arm/dts/dragonboard820c.dts | 151 - arch/arm/dts/dragonboard845c-uboot.dtsi| 26 - arch/arm/dts/dragonboard845c.dts | 48 - arch/arm/dts/msm8916-pm8916.dtsi | 157 + arch/arm/dts/msm8916.dtsi | 2702 + arch/arm/dts/msm8996.dtsi | 3884 + arch/arm/dts/pm8916.dtsi | 178 + arch/arm/dts/pm8994.dtsi | 152 + arch/arm/dts/pm8998.dtsi | 130 + arch/arm/dts/pmi8994.dtsi | 65 + arch/arm/dts/pmi8998.dtsi | 98 + arch/arm/dts/pms405.dtsi | 149 + arch/arm/dts/qcs404-evb-4000-u-boot.dtsi | 48 + arch/arm/dts/qcs404-evb-4000.dts | 96 + arch/arm/dts/qcs404-evb-uboot.dtsi | 30 - arch/arm/dts/qcs404-evb.dts| 390 -- arch/arm/dts/qcs404-evb.dtsi | 389 ++ arch/arm/dts/qcs404.dtsi | 1829 ++ arch/arm/dts/sdm845-db845c.dts | 1190 .../arm/dts/sdm845-samsung-starqltechn-u-boot.dtsi | 16 + arch/arm/dts/sdm845-samsung-starqltechn.dts| 460 ++ arch/arm/dts/sdm845-wcd9340.dtsi | 86 + arch/arm/dts/sdm845.dtsi | 5801
Re: [PATCH] usb: dwc3-generic: Fix build errors when USB_DWC3_GADGET is disabled
Hi Jonas, thank you for the patch. On lun., févr. 26, 2024 at 13:36, Jonas Karlman wrote: > On 2024-02-26 11:18, Marek Vasut wrote: >> On 2/26/24 10:50 AM, Jonas Karlman wrote: >>> On 2024-02-26 09:22, Marek Vasut wrote: On 2/26/24 8:54 AM, Jonas Karlman wrote: > On 2024-02-26 02:47, Tom Rini wrote: >> On Mon, Feb 26, 2024 at 01:02:04AM +0100, Jonas Karlman wrote: >>> On 2024-02-25 23:01, Marek Vasut wrote: On 2/25/24 4:27 PM, Jonas Karlman wrote: > Build fail with the following error when DM_USB_GADGET is enabled and > USB_DWC3_GADGET is disabled: > > dwc3/dwc3-generic.o: in function > `dm_usb_gadget_handle_interrupts': > > dwc3/dwc3-generic.c:201:(.text.dm_usb_gadget_handle_interrupts+0x10): >undefined reference to `dwc3_gadget_uboot_handle_interrupt' > > Build also fail with the following error when USB_GADGET_DWC2_OTG + > DM_USB_GADGET is enabled and USB_DWC3_GADGET is disabled: > > gadget/dwc2_udc_otg.o: in function > `dm_usb_gadget_handle_interrupts': > gadget/dwc2_udc_otg.c:947: multiple definition of > `dm_usb_gadget_handle_interrupts'; >dwc3/dwc3-generic.o:dwc3/dwc3-generic.c:197: first defined here > > Fix this by checking for USB_DWC3_GADGET in addition to DM_USB_GADGET. > > Signed-off-by: Jonas Karlman > --- > drivers/usb/dwc3/dwc3-generic.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/dwc3/dwc3-generic.c > b/drivers/usb/dwc3/dwc3-generic.c > index 6fb2de8a5ace..891d01957619 100644 > --- a/drivers/usb/dwc3/dwc3-generic.c > +++ b/drivers/usb/dwc3/dwc3-generic.c > @@ -192,7 +192,7 @@ static int dwc3_generic_of_to_plat(struct udevice > *dev) > return 0; > } > > -#if CONFIG_IS_ENABLED(DM_USB_GADGET) > +#if IS_ENABLED(CONFIG_USB_DWC3_GADGET) && > CONFIG_IS_ENABLED(DM_USB_GADGET) Maybe just make USB_DWC3_GADGET depend on (or select?) DM_USB_GADGET , since I think the DWC3 code doesn't work without DM anyway . >>> >>> Do you mean in addition to this? I do not think that alone is something >>> that will address my intention to be able to disable the gadget part of >>> the dwc3-generic driver. >>> >>> Before this patch it was possible to enable disable host or gadget by >>> using USB_HOST/SPL_USB_HOST and DM_USB_GADGET/SPL_DM_USB_GADGET options. >>> >>> However, Rockchip RK3328 boards have dwc2 otg and dwc3 host, trying to >>> use DM_USB_GADGET for dwc2 and USB_HOST for dwc3 is currently not >>> possible and result in the build errors reported, i.e. multiple >>> definition of dm_usb_gadget_handle_interrupts() and undefined reference >>> to dwc3_gadget_uboot_handle_interrupt(). >>> >>> After this patch I can use dm dwc2 gadget and dwc3 host without issue. >> >> Note that *DM_* symbols can be confusing. At this point, in SPL >> SPL_DM_USB and SPL_DM_USB_GADGET are encouraged but not required for >> host/gadget drivers. In full U-Boot, DM_USB is required for all host >> drivers and really should be enabled in all cases for DM_USB_GADGET. We >> can't enforce that at the Kconfig level because of, iirc, some of the >> armv7 part gadget drivers (more than one). But for newer and still very >> active chips, we should be using DM_USB_GADGET unconditionally in full >> U-Boot. > > The issue is that with DM_USB_GADGET we can only have one driver > providing the dm_usb_gadget_handle_interrupts() function. DM was always intended to permit multiple drivers, so this is a bug and should be fixed, e.g. by turning the interrupt handling function into a driver-specific callback. >>> >>> I fully agree, and I hope that someone can work on that separate issue >>> and that it does not block this build error fix patch. >> >> Please, let's fix this properly instead of piling up another ifdef >> workaround. I agree with Marek. > > Reworking the core usb gadget interrupt handling is unfortunately not > something I can spend any of my already limited hobbyist free time on. I understand you don't have time for this. I will try to tackle it, but I have limited time in the upcoming weeks. I will keep you posted. > > If this workaround is not acceptable I can just drop the RK3328 cleanup > and leave usb in current semi-broken state. > >> >> Since CI does pass, where is there a build error ? > > Currently there is no board with a configuration that cause build errors, > that happens when I add DM_USB_GADGET=y to RK3328 boards in a separate > series. > > Previously you have requested that I do not send usb patches as part of > a larger
Re: [PATCH v5 00/39] Qualcomm generic board support
On Mon, 26 Feb 2024 17:26:04 +, Caleb Connolly wrote: > Historically, Qualcomm boards in U-Boot have all had their own > board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their > own hardcoded sysmap-xyz.c file, and their own U-Boot specific > devicetree with little/no compatibility with upstream DT. > > This series makes a few final prepatory changes, and then replaces > almost all of the board specific code with generic alternatives. The end > result is that all Qualcomm boards both current and future (with the > exception of the db410c and db820c) can be supported by a single U-Boot > binary by just providing the correct DT. New boards can be added without > introducing any addition mach/ or board/ code or config options. > > [...] Applied, thanks! [01/39] arm: init: export prev_bl_fdt_addr commit: ca84ba63858a607fe2dabf56ed593d7808d2689d [02/39] usb: dwc3-generic: support external vbus regulator commit: de451d5d5b6f1913b7a7c270e7e5ff606342f126 [03/39] mmc: msm_sdhci: use modern clock handling commit: 5f3c4cca362b29fa60fd4fb5efeec60fe8f35af1 [04/39] dt-bindings: drop msm_sdhci binding commit: dae9614e1eb8fa5d4ae8051497a582940430e134 [05/39] clk/qcom: use upstream compatible properties commit: 7d96cca9e1d83ef307d7907e15d7a504ffc1ae69 [06/39] clock/qcom: qcs404: fix clk_set_rate commit: 641237bf99f701ffdf3748f5fe1e118eb2d7b781 [07/39] serial: msm: add debug UART commit: 90023bdfe979a5ea3806b73e73fabfc3e1a94a04 [08/39] serial: msm: fix clock handling and pinctrl commit: 92781cff6e7115b5a8957e6a9ded6cd7516d4fc7 [09/39] gpio: qcom_pmic: 1-based GPIOs commit: a2ce3aac46121e7ffa244540b62b439ddeed7a9c [10/39] gpio: qcom_pmic: add a quirk to skip GPIO configuration commit: 19f000b72b2fa7e4540f7cdb91287aff594239bd [11/39] gpio: qcom_pmic: add pinctrl driver commit: eb2393d7d5443750b8ab61912ead78eb54b42fb9 [12/39] sandbox: dts: fix qcom pmic gpio commit: cc18d5486b2cb520d50d2154fc2e9fe2566f480c [13/39] pinctrl: qcom: stub support for special GPIOs commit: a245aece2acfbbaf01f41c595f9bfb02a9aedb70 [14/39] pinctrl: qcom: fix DT compatibility commit: 97487ac76de85d22653b12c7561e6c007a3b4eb5 [15/39] pinctrl: qcom: apq8016: init pre-reloaction commit: 8048976e9c9943b28aec8b7e4d998e128b39fe70 [16/39] board: dragonboard410c: add chainloaded config fragment commit: e9302ba6cc6bfdf8a3dc4e9f232767b9bc0b217d [17/39] board: dragonboard410c: upstream DT compat commit: c744e6308951d47f597e5dac450cab698246 [18/39] board: dragonboard410c: import board code from mach-snapdragon commit: 14868845db54b4f64701977385dc9a6e951e4139 [19/39] board: dragonboard820c: use LINUX_KERNEL_IMAGE_HEADER commit: 9d5e434eb24d1bc73c8eb881bee95949a798f150 [20/39] mach-snapdragon: generalise board support commit: 059d526af3123935c1fb525d12953d570d392f7c [21/39] mach-snapdragon: dynamic load addresses commit: a2364d97ffaef6b708b0e7098c5cb5de98f5b6e1 [22/39] mach-snapdragon: generate fdtfile automatically commit: 2bdc48f7fdcf412d9a67c07673bf7e7202628186 [23/39] mach-snapdragon: carve out no-map regions commit: c6f4985a04f50dead54fee43745fca87107bace7 [24/39] board: qcs404-evb: drop board code commit: 90744c1a14c54d08c9981869dec9262289da2d6b [25/39] doc: board/qualcomm: document generic targets commit: d9252fcde1218902ed4805acd951da0405ba7d1b [26/39] doc: board/qualcomm: link to APQ8016 TRM commit: d795efef8361e6406c08fd1551e1f1d98b1751ff [27/39] dt-bindings: import headers for SDM845 commit: c0297b30f1b576180c95dbc44b7647f20f3a4bd1 [28/39] dts: sdm845: import supporting dtsi files commit: e59755b0d688d0b5ff63b5034a1722d6c4c8ece7 [29/39] dts: sdm845: replace with upstream DTS commit: 99870a4c412b41893014eeb2d7ce8ba74d7b7d1a [30/39] dt-bindings: import headers for MSM8916 commit: 8a09bdceae5f1d295ced5feb19db3b883ed2dfd7 [31/39] dts: msm8916: import PMIC dtsi files commit: 89a013dbe8b5eca8f29c029bd60e7ca0c5f14da3 [32/39] dts: msm8916: replace with upstream DTS commit: ed8fbd2889fc072b12fe2437ac92e83676c93728 [33/39] dt-bindings: import headers for MSM8996 commit: 7d5e9976f25149cace7fd9d6ebaf8b7b87dbf66f [34/39] dts: msm8996: import PMIC dtsi files commit: 0d80f44c644aed766cc26fbb201e1c1a38bca924 [35/39] dts: dragonboard820c: use correct bindings for clocks commit: 5566bb447647bc155d06fad852db4ba3006d9329 [36/39] dts: msm8996: replace with upstream DTS commit: 93441fc3b527a3e5c60d687dc4cb01df03221759 [37/39] dt-bindings: import headers for qcs404 commit: 4745c4d76cd463129d5f4a82ea4e4bbcc32dfd21 [38/39] dts: qcs404-evb: replace with upstream DT commit: 890207c6517d0d6dbd63d503c1fa8180c6022b98 [39/39] MAINTAINERS: Qualcomm: add some missing paths commit: f70ab46df3c2768002fdfc0fca9652af732cd619 Best regards, -- // Caleb
Re: [PATCH] clk/qcom: apq8016: allow apq8016_clk_init_uart() to be called externally
On Fri, 01 Mar 2024 15:00:24 +, Caleb Connolly wrote: > When U-Boot as running as the first stage bootloader on MSM8916 devices, > early debug UART requires turning on the clocks (for some reason the > pre-loader turns them off?!). > > To simplify developing for this platform, allow the > apq8016_clk_init_uart() function to be called externally. Developers can > call this from the serial_msm debug uart driver to configure the clocks > before the driver model is available. > > [...] Applied, thanks! [1/1] clk/qcom: apq8016: allow apq8016_clk_init_uart() to be called externally commit: cbf3152f6afff25c25aa69ae06488671ca0aa765 Best regards, -- // Caleb (they/them)
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
On Fri, 1 Mar 2024 at 19:18, wrote: > > On 01/03/2024 14:30, Sumit Garg wrote: > > On Fri, 1 Mar 2024 at 18:27, Tom Rini wrote: > >> > >> On Thu, 22 Feb 2024 15:05:56 +0530, Sumit Garg wrote: > >> > >>> Changes in v6: > >>> -- > >>> - v6_dt: https://github.com/b49020/u-boot/tree/v6_dt > >>> - Patch #3: Incorporate fix for sandbox CI failure. > >>> - Patch #6: Incorporate shell script comments from Marek. > >>> - Patch #8: Incorporate documentation review comments from Paul. > >>> > >>> [...] > >> > >> Applied to u-boot/next, thanks! > >> > > > > Thanks Tom and everyone involved with the reviews. I hope we can carry > > forward from this effort towards a healthy devicetree story for > > U-Boot. > > Thanks Sumit! > > I'll try to submit patches for Amlogic GXL & G12A to switch to this! > Thanks Neil for your support to be the first volunteer for this OF_UPSTREAM switch. -Sumit > Neil > > > > > -Sumit > > > >> -- > >> Tom > >> > >> >
[PATCH] clk/qcom: apq8016: allow apq8016_clk_init_uart() to be called externally
When U-Boot as running as the first stage bootloader on MSM8916 devices,
early debug UART requires turning on the clocks (for some reason the
pre-loader turns them off?!).
To simplify developing for this platform, allow the
apq8016_clk_init_uart() function to be called externally. Developers can
call this from the serial_msm debug uart driver to configure the clocks
before the driver model is available.
As it is only possible to enable early debug UART in custom builds of
U-Boot, this solution at least gives developers the option.
Signed-off-by: Caleb Connolly
---
This patch was meant to be in v5 of my Qualcomm generic board support series[1],
but got lost somewhere in the mix.
[1]:
https://lore.kernel.org/u-boot/cafa6wynxe3x8skrb8bbpodcfxbzeevpkpu0-qt7ezsy-r7u...@mail.gmail.com/
---
drivers/clk/qcom/clock-apq8016.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index 9de0ad5ed32d..e6647f7c41dd 100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -102,22 +102,22 @@ static const struct bcr_regs uart2_regs = {
.D = BLSP1_UART2_APPS_D,
};
/* UART: 115200 */
-static int clk_init_uart(struct msm_clk_priv *priv)
+int apq8016_clk_init_uart(phys_addr_t base)
{
/* Enable AHB clock */
- clk_enable_vote_clk(priv->base, _blsp1_ahb_clk);
+ clk_enable_vote_clk(base, _blsp1_ahb_clk);
/* 7372800 uart block clock @ GPLL0 */
- clk_rcg_set_rate_mnd(priv->base, _regs, 1, 144, 15625,
+ clk_rcg_set_rate_mnd(base, _regs, 1, 144, 15625,
CFG_CLK_SRC_GPLL0, 16);
/* Vote for gpll0 clock */
- clk_enable_gpll0(priv->base, _vote_clk);
+ clk_enable_gpll0(base, _vote_clk);
/* Enable core clk */
- clk_enable_cbc(priv->base + BLSP1_UART2_APPS_CBCR);
+ clk_enable_cbc(base + BLSP1_UART2_APPS_CBCR);
return 0;
}
@@ -132,9 +132,9 @@ static ulong apq8016_clk_set_rate(struct clk *clk, ulong
rate)
case GCC_SDCC2_APPS_CLK: /* SDC2 */
return clk_init_sdc(priv, 1, rate);
break;
case GCC_BLSP1_UART2_APPS_CLK: /* UART2 */
- return clk_init_uart(priv);
+ return apq8016_clk_init_uart(priv->base);
break;
default:
return 0;
}
--
2.43.1
Re: [PATCH] test: dm: add button_cmd test
On Wed, Feb 14, 2024 at 05:03:46PM +, Caleb Connolly wrote:
> Add a test for the button_cmd feature. This validates that commands can
> be mapped to two buttons, that the correct command runs based on which
> button is pressed, that only 1 command is run, and that no command runs
> if button_cmd_0_name is wrong or unset.
>
> CONFIG_BUTTON is now enabled automatically and was removed when running
> save_defconfig.
>
> Signed-off-by: Caleb Connolly
Locally this fails:
== FAILURES
===
__ test_ut[ut_dm_dm_test_button_cmd]
__
test/py/u_boot_spawn.py:195: in expect
c = os.read(self.fd, 1024).decode(errors='replace')
E OSError: [Errno 5] Input/output error
During handling of the above exception, another exception occurred:
test/py/tests/test_ut.py:509: in test_ut
output = u_boot_console.run_command('ut ' + ut_subtest)
test/py/u_boot_console_base.py:266: in run_command
m = self.p.expect([self.prompt_compiled] + self.bad_patterns)
test/py/u_boot_spawn.py:204: in expect
raise ValueError('U-Boot exited with %s' % info)
E ValueError: U-Boot exited with signal 11 (SIGSEGV)
Captured stdout call
-
=> ut dm dm_test_button_cmd
Test: dm_test_button_cmd: button.c
BTN 'button1'> env set test_button_cmds_0 PASS
BTN 'button1'> env set test_button_cmds_0 PASS
BTN 'button2'> env set test_button_cmds_1 PASS
=== short test summary info
===
FAILED test/py/tests/test_ut.py::test_ut[ut_dm_dm_test_button_cmd] -
ValueError: U-Boot exit...
On top of current master.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 00/39] Qualcomm generic board support
Hi Caleb,
On Mon, 26 Feb 2024 at 22:56, Caleb Connolly wrote:
>
> Historically, Qualcomm boards in U-Boot have all had their own
> board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their
> own hardcoded sysmap-xyz.c file, and their own U-Boot specific
> devicetree with little/no compatibility with upstream DT.
>
> This series makes a few final prepatory changes, and then replaces
> almost all of the board specific code with generic alternatives. The end
> result is that all Qualcomm boards both current and future (with the
> exception of the db410c and db820c) can be supported by a single U-Boot
> binary by just providing the correct DT. New boards can be added without
> introducing any addition mach/ or board/ code or config options.
>
> Due to the nature of this change, the patch ("mach-snapdragon:
> generalise board support") has become pretty big, I tried a few
> different ways to represent this in git history, but the other methods
> (e.g. adding a stub "generic" target and removing it again) were more
> confusing and made for much messier git history. The current patch is
> mostly atomic, but requires regenerating the config.
>
> The QCS404 EVB board had some code to enable the USB VBUS regulator,
> this is dropped in favour of a adding a new vbus-supply property to the
> dwc3-generic driver. This will also be used by the dragonboard845c in a
> future patch. This handles the common case of a board requiring some
> regulator be enabled for USB host mode.
>
> A more detailed description of the changes is below.
>
> == Memory map ==
>
> The memory map was historically hardcoded into U-Boot, this meant that
> U-Boot had to be built for a specific variant of a device. This is
> changed to instead read the memory map from the DT /memory node.
>
> Additionally, most boards mapped addresss 0x0 as valid, as a result if a
> null pointer access happens then it will cause a bus stall (and board
> hang). This is fixed so that null pointer accesses will now correctly
> throw an exception.
>
> == DT loading ==
>
> Previously, boards used the FDT blob embedded into U-Boot (via
> OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
> bootloader, so we can instead rely on the first-stage bootloader to
> populate some useful FDT properties for us (notably the /memory node and
> KASLR seed) and fetch the DTB that it provides. Combined with the memory
> map changes above, this let's us entirely avoid configuring the memory
> map explicitly.
>
> == defconfig ==
>
> Most of the board defconfigs and config headers were quite similar, to
> simplify maintenance going forward, all the fully generic boards (sdm845
> and qcs404-evb so far) are adapted to use the new qcom_defconfig. Going
> forward, all new Qualcomm boards should be supported by this defconfig.
> A notable exception is for specific usecases (like U-Boot as the primary
> bootloader).
>
> == The older dragonboards ==
>
> The db410c and db820c both have some custom board init code, as a result
> they aren't yet binary compatible. mach-snapdragon is adjusted so
> that all the necessary config options (e.g. CONFIG_SYS_BOARD) can be set
> from their defconfigs, this makes it possible to enable support for new
> boards without introducing additional config options.
>
> The db410c can run U-Boot either chainloaded like the other boards, or
> as a first-stage bootloader replacing aboot. However it was hardcoded to
> only build for the latter option. This series introduces a new
> "chainloaded" defconfig to enable easier testing via fastboot.
>
> == dynamic environment variables ==
>
> This series also introduces runtime-allocated load addresses via the lmb
> allocator. This allows for booting on boards with vastly different
> memory layouts without any pre-calculation or macro magic in the config
> header. This feature is based on similar code in mach-apple.
>
> The soc, board, and fdtfile environment variables are also generated
> automatically. Many Qualcomm boards follow a similar scheme for DTB
> naming such that the name can often be derived from the root compatible
> properties. This is intended to cover the most common cases and be a
> simple solution for booting generic distro images without having to
> explicitly choose the right DTB. The U-Boot DTS can be tweaked if
> necessary to produce the correct name, the variable can be overwritten,
> or a bootloader like GRUB can load the devicetree instead.
>
> == Upstream DT ==
>
> All Qualcomm boards have had their devicetree files replaced with the
> upstream versions. Previous patch series made the necessary driver
> adjustments to fully support the upstream DT format. All future
> Qualcomm boards should use upstream DTS by default.
>
> Once Sumit's work to import dt-rebasing has been merged, we will drop
> the imported DT and bindings again.
I suppose we are just in time for this as the OF_UPSTREAM work has
been merged into U-Boot next branch [1]. Can you rebase this patch-set
on
Re: [PATCH v2 1/1] net: ti: am65-cpsw-nuss: Remove incorrect RGMII_ID bit functionality
On Thu, Feb 01, 2024 at 08:17:05PM +, Ken Sloat wrote: > The CPSW implementations on the AM6x platforms do not support the > selectable RGMII TX clk delay functionality via the RGMII_ID_MODE bit as > the earlier platforms did. While it is possible to write the bit, > according to various TI AM6x datasheets, reference manuals, hardware > design guides and TI forum posts from TI, this bit is "not timed, tested > or characterized. RGMII_ID is enabled by default." > > The driver implementation today however, will incorrectly set this bit > whenever the interface mode is in RGMII_ID or RGMII_TXID. Since > disabling the delay (bit=1) is not supported by TI, this bit should > always be written as 0. > > See: > https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1211306/am625-enet1_ctrl_rgmii_id-_mode > https://www.ti.com/lit/pdf/spruiv7 (Rev. B Figure 14-1717) > https://www.ti.com/lit/gpn/am625 (Rev. B Figure 7-31 Note A) > https://www.ti.com/lit/an/sprad05b/sprad05b.pdf (Rev. B Section 7.4) > > Signed-off-by: Ken Sloat > Reviewed-by: Roger Quadros The whitespace in this version was totally destroyed, please re-send, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
On 01/03/2024 14:30, Sumit Garg wrote: On Fri, 1 Mar 2024 at 18:27, Tom Rini wrote: On Thu, 22 Feb 2024 15:05:56 +0530, Sumit Garg wrote: Changes in v6: -- - v6_dt: https://github.com/b49020/u-boot/tree/v6_dt - Patch #3: Incorporate fix for sandbox CI failure. - Patch #6: Incorporate shell script comments from Marek. - Patch #8: Incorporate documentation review comments from Paul. [...] Applied to u-boot/next, thanks! Thanks Tom and everyone involved with the reviews. I hope we can carry forward from this effort towards a healthy devicetree story for U-Boot. Thanks Sumit! I'll try to submit patches for Amlogic GXL & G12A to switch to this! Neil -Sumit -- Tom
Re: [PATCH v1 0/4] Introduce mtdblock device
Hi Frieder, On Thu, Feb 29, 2024 at 09:51:04AM +0100, Frieder Schrempf wrote: > Hi Alexey, > > On 27.02.24 11:04, Alexey Romanov wrote: > > Hello! > > > > This series adds support for the mtdblock device, which > > allows to read/write data block by block. For example, > > it can now be used for BCB or Android AB command: > > > > $ bcb load mtd 0 part_name > > > > Tested only on SPI NAND, so bind is made only for > > SPI NAND drivers. > > I don't know much about Android, but as far as I understand you are > trying to store dynamic, boot-related information on the MTD device. > > This might be acceptable if the underlying device is a NOR flash, but > for any type of NAND device it sounds like a rather bad idea. > > NAND devices need some kind of FTL (flash translation layer) in order to > work reliably. Using a block filesystem directly on the NAND MTD device > will cause problems as soon as any bad blocks or bit flips occur. > > People are therefore discouraged to use mtdblock on NAND and in the > kernel there is even a warning if you try to mount a NAND mtdblock > partition. You are completely right. But, unfortunately, these are legacy ones that need to be supported. On some boards this approach was chosen a long time ago and mistakenly, so I think we need to support this for NAND. > > Maybe you should reconsider this and look into how to use UBIFS as a > FTL. On the other hand I'm not quite sure if the UBIFS layer in U-Boot > is really stable and maintained. So this might not be a good idea either. Yeah, on our new boards we switched to using UBI, and we already have an implementation UBI block device for U-Boot. Will send this to mailing list in the near future. > > Anyway, I'm against implementing mtdblock for SPI NAND (or any other NAND). Maybe we'll just add warning like it's done in the Linux? > > Best regards > Frieder -- Thank you, Alexey
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
On Fri, 1 Mar 2024 at 18:27, Tom Rini wrote: > > On Thu, 22 Feb 2024 15:05:56 +0530, Sumit Garg wrote: > > > Changes in v6: > > -- > > - v6_dt: https://github.com/b49020/u-boot/tree/v6_dt > > - Patch #3: Incorporate fix for sandbox CI failure. > > - Patch #6: Incorporate shell script comments from Marek. > > - Patch #8: Incorporate documentation review comments from Paul. > > > > [...] > > Applied to u-boot/next, thanks! > Thanks Tom and everyone involved with the reviews. I hope we can carry forward from this effort towards a healthy devicetree story for U-Boot. -Sumit > -- > Tom > >
Re: [PATCH 1/2] opos6uldev: make the LCD work again
Hey,
Replying here because this is only version of this in my inbox atm.
On Fri, Mar 01, 2024 at 10:17:35AM +0100, Sébastien Szymanski wrote:
> On 3/1/24 07:02, Sumit Garg wrote:
> > On Thu, 29 Feb 2024 at 19:31, Tom Rini wrote:
> > > On Thu, Feb 29, 2024 at 08:42:42AM -0500, Tom Rini wrote:
> > > > On Thu, Feb 29, 2024 at 11:17:28AM +0530, Sumit Garg wrote:
> > > > > On Wed, 28 Feb 2024 at 20:50, Tom Rini wrote:
> > > > > > On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> > > > > > > On Wed, 28 Feb 2024 at 18:40, Tom Rini wrote:
> > > > > > > >
> > > > > > > > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > > > > > > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski
> > > > > > > > > wrote:
> > > > > > > > > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device
> > > > > > > > > > trees with
> > > > > > > > > > linux") removed the display timings from the board device
> > > > > > > > > > tree whereas
> > > > > > > > > > they are still needed by the mxsfb driver.
> > > > > > > > > > Add the timings back (the correct ones) in the
> > > > > > > > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > > > > > > > > opos6uldev.env file.
> > > > > > > > > >
> > > > > > > > > > Update the opos6uldev_defconfig file so that the LCD turns
> > > > > > > > > > on at boot.
> > > > > > > > > >
> > > > > > > > > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device
> > > > > > > > > > trees with linux")
> > > > > > > > > > Signed-off-by: Sébastien Szymanski
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Huh. This is the commit that did that upstream.
> > > > > > > > >
> > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > > > > > > > >
> > > > > > > > > It's interesting how the timings in linux were always
> > > > > > > > > slightly different
> > > > > > > > > from in u-boot.
> > > > > > > >
> > > > > > > > Thanks for tracking that down, Dan. I'm adding in Sumit and Rob
> > > > > > > > here
> > > > > > > > because this is a recent (rather than ancient) example of one
> > > > > > > > of the
> > > > > > > > concerns about OF_UPSTREAM.
> > > > > > >
> > > > > > > I rather think about this as an opportunity to improve with
> > > > > > > OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> > > > > > > corresponding Linux kernel sub-arch maintainers. Especially once
> > > > > > > we
> > > > > > > move to OF_UPSTREAM and a sub-arch maintainer profile in Linux
> > > > > > > kernel
> > > > > > > to keep them aware that U-Boot should be considered too.
> > > > > >
> > > > > > Yes, a more extensive check around when removing information from
> > > > > > dts
> > > > > > files would be good.
Whenever people remove things from bindings (or from being required) we
do ask them "have you checked that there's no users for this outside of
linux" - but for me at least I don't apply that scrutiny for most (read
arm{,64}) devicetrees. There's just too much volume if I went asking
those questions on every removal, it's up to the platform maintainers to
keep an eye on that.
That said, modifications to a devicetree are fixable with a revert,
while modifications to a binding may not really be fixable in a way that
isn't disruptive for some user, so I think that I am spending my time
wisely.
> > > > > > > > I think the commit in question can be
> > > > > > > > summarized as "remove a bunch of explicit HW information
> > > > > > > > because there's
> > > > > > > > now a Linux Kernel driver that determines that dynamically".
> > > > > > > > What do we
> > > > > > > > do next? The old information is in a presumably valid binding
> > > > > > > > still, can
> > > > > > > > we just put it back and comment that consumers outside of Linux
> > > > > > > > use this
> > > > > > > > still so it's not removed again later? Or am I just missing
> > > > > > > > where we can
> > > > > > > > instead get this information from the DT still and not need to
> > > > > > > > come up
> > > > > > > > with a new driver and subsystems?
I don't think this is an accurate summary. The "explict hw information"
was never allowed for an imx6ul, only for some older devices, so "the
old information is in a presumably valid binding" is not accurate.
See 7b920aae917d ("dt-bindings: mxsfb: Add new bindings for the MXSFB
driver") for when doing things that way was deprecated. The imx6ul was
only documented several years after it was introduced (so likely several
years after it started incorrectly using that binding).
Seeing that, I am not sure that I would even question the kernel patch
cited above, the change was done for binding compliance and I would not
be inclined to think twice, given the bindings are the ABI.
Cheers,
Conor.
signature.asc
Description: PGP signature
[PATCH] doc: devicetree: Lets avoid short reference link names
Short reference link names like "dtspec", "dtrepo", "dttweaks" etc. interrupt the flow of the document text. Lets avoid them and instead expand in place for better readability. Suggested-by: Paul Barker Signed-off-by: Sumit Garg --- doc/develop/devicetree/control.rst | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index c94d84192b71..4cc1457d4ea8 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -36,10 +36,10 @@ What is a Flattened Devicetree? --- An fdt can be specified in source format as a text file. To read about -the fdt syntax, take a look at the specification (dtspec_). +the fdt syntax, take a look at `the devicetree specification`_. -There is also a mailing list (dtlist_) for the compiler and associated -tools. +There is also a `devicetree compiler mailing list`_ for the compiler and +associated tools. In case you are wondering, OF stands for Open Firmware. This follows the convention used in Linux. @@ -89,7 +89,7 @@ Failing that, you could write one from scratch yourself! Resyncing with devicetree-rebasing -- -The devicetee-rebasing repository (dtrepo_) maintains a fork cum mirror copy of +The `devicetree-rebasing repository`_ maintains a fork cum mirror copy of devicetree files along with the bindings synced at every Linux kernel major release or intermediate release candidates. The U-Boot maintainers regularly sync the `dts/upstream/` subtree from the devicetree-rebasing repo whenever @@ -118,7 +118,7 @@ as `arch//dts/.dts`. To select that add `# CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=` when prompted by Kconfig. This should include your CPU or SoC's devicetree file. On top of that any U-Boot -specific tweaks (see: dttweaks_) can be made for your board. +specific tweaks (see: :ref:`dttweaks`) can be made for your board. If `OF_EMBED` is selected by Kconfig, then it will be picked up and built into the U-Boot image (including u-boot.bin). This is suitable for debugging @@ -243,7 +243,7 @@ Dependencies The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. For installation -instructions, refer to the DT schema project page (dtschema_). +instructions, refer to the `DT schema project page`_. Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default). @@ -333,10 +333,10 @@ used it before Linux (e.g. snow). The two projects developed in parallel and there are still some differences in the bindings for certain boards. While there has been discussion of having a separate repository for devicetree files, in practice the Linux kernel Git repository has become the place where -these are stored, with U-Boot taking copies via devicetree-rebasing repo -(see: dtrepo_) and adding tweaks with u-boot.dtsi files. +these are stored, with U-Boot taking copies via +`devicetree-rebasing repository`_ and adding tweaks with u-boot.dtsi files. -.. _dtspec: https://www.devicetree.org/specifications/ -.. _dtlist: https://www.spinics.net/lists/devicetree-compiler/ -.. _dtrepo: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git -.. _dtschema: https://github.com/devicetree-org/dt-schema/tree/main +.. _the devicetree specification: https://www.devicetree.org/specifications/ +.. _devicetree compiler mailing list: https://www.spinics.net/lists/devicetree-compiler/ +.. _devicetree-rebasing repository: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git +.. _DT schema project page: https://github.com/devicetree-org/dt-schema/tree/main -- 2.34.1
Re: [RFC PATCH 0/6] Clean up arm linker scripts
Thanks Sam
On Thu, 29 Feb 2024 at 23:07, Sam Edwards wrote:
>
>
>
> On 2/28/24 04:15, Ilias Apalodimas wrote:
> > On Wed, 28 Feb 2024 at 13:11, Peter Robinson wrote:
> >>
> >> On Wed, 28 Feb 2024 at 10:58, Ilias Apalodimas
> >> wrote:
> >>>
> >>> The arm linker scripts had a mix of symbols and C defined variables in an
> >>> effort to emit relative references instead of absolute ones e.g [0].
> >>> This has led to confusion over the years, ending up with mixed section
> >>> definitions. Some sections being defined with overlays and different
> >>> definitions between v7 and v8 architectures.
> >>> For example __efi_runtime_rel_start/end is defined as a linker symbol for
> >>> armv8 and a C variable in armv7.
> >>>
> >>> I am not sure if this used to be a compiler bug, but linker scripts
> >>> nowadays
> >>> can emit relative references, as long as the symbol definition is
> >>> contained
> >>> within the section definition. So let's switch most of the C defined
> >>> variables
> >>
> >> Should we be setting/upping the minimum version of the linker version
> >> as part of this?
> >
> > The patch that added those as C-defined variables, was in 2013. So any
> > linker that's not ancient history should emit those correctly.
> >
>
> GNU ld fixed the problem on 2016-02-23, with this entry in the bfd
> changelog:
>
> * elflink.c (bfd_elf_record_link_assignment): Check for shared
> library, instead of PIC, and don't check PDE when making linker
> assigned symbol dynamic.
>
> It looks like the change was first included in binutils 2.27, released
> 2016-08-03. I don't know where the minimum linker version requirement is
> memorialized but there's a good chance that U-Boot already requires a
> version more recent than that. (Someone who knows where that is will
> have to check.)
Ok, this is useful. Thanks for digging it up. I'll update the commit
messages on the next version.
>
> In either case, I strongly agree: sections.c is an unnecessary
> workaround with any reasonably recent linker version, it's
> fickle/incompatible with non-GNU linkers such as LLD, and the marker
> symbols belong in the linker script. This patchset is a big step in the
> right direction!
Yes and the only reason I haven't removed secure_start/end etc, is
that I don't have a platform to test.
So I'd rather land this first and then clean up the remaining 5
entries of sections.c (and the file itself)
Cheers
/Ilias
>
> >
> >>
> >>> and clean up the arm sections.c file. There's still a few symbols
> >>> remaining --
> >>> __secure_start/end, __secure_stack_start/end and __end which can be
> >>> cleaned up
> >>> in a followup series.
> >>>
> >>> The resulting binary (tested in QEMU v7/v8) had no size differences apart
> >>> from
> >>> the emited sections and object types of those variables. I've also added
> >>> prints
> >>> throughout the U-Boot init sequence. The offsets and delta for 'end -
> >>> start'
> >>> section sizes is unchanged.
> >>>
> >>> For example on QEMU v8:
> >>> $~ ./scripts/bloat-o-meter u-boot u-boot.new
> >>> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> >>> Function old new delta
> >>> Total: Before=798861, After=798861, chg +0.00%
> >>>
> >>> $~ readelf -sW u-boot | grep bss_s
> >>> 12: 001029b8 0 SECTION LOCAL DEFAULT 12 .bss_start
> >>>8088: 0018 0 NOTYPE GLOBAL DEFAULT1 _bss_start_ofs
> >>>8376: 001029b8 0 OBJECT GLOBAL DEFAULT 12 __bss_start
> >>> $~ readelf -sW u-boot.new | grep bss_s
> >>>8085: 0018 0 NOTYPE GLOBAL DEFAULT1 _bss_start_ofs
> >>>8373: 001029b8 0 NOTYPE GLOBAL DEFAULT 12 __bss_start
> >>>
> >>> For QEMU v7 the differences are a bit bigger but only affect the variables
> >>> placed in the .bss section because that was defined as an OVERLAY in the
> >>> existing linker script.
> >>> For example:
> >>> $~ nm u-boot | grep tftp_prev_block
> >>> 000ca0dc ? tftp_prev_block
> >>> $~ nm u-boot.new | grep tftp_prev_block
> >>> 000e0a5c b tftp_prev_block -> The symbol is now placed into .bss
> >>>
> >>> It's worth noting that since the efi regions are affected by the change,
> >>> booting
> >>> with EFI is preferable while testing. Booting the kernel only should be
> >>> enough
> >>> since the efi stub and the kernel proper do request boottime and runtime
> >>> services respectively.
> >>> Something along the lines of
> virtio scan && load virtio 0 $kernel_addr_r Image && bootefi
> $kernel_addr_r
> >>> will work for QEMU aarch64.
> >>>
> >>> Tested platforms:
> >>> - QEMU aarch64
> >>> - Xilinx kv260 kria starter kit & zynq
> >>> - QEMU armv7
> >>> - STM32MP157C-DK2
> >>>
> >>> [0] commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__
> >>> compiler-generated")
> >>>
> >>> Ilias Apalodimas (6):
> >>>arm: baltos: remove custom linker script
> >>>arm: clean up v7 and v8 linker scripts for
Re: [RFC PATCH 2/6] arm: clean up v7 and v8 linker scripts for bss_start/end
Thanks for testing Caleb,
On Thu, 29 Feb 2024 at 15:49, Caleb Connolly wrote:
>
>
>
> On 28/02/2024 10:48, Ilias Apalodimas wrote:
> > commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__
> > compiler-generated")
> > and
> > commit f84a7b8f54db ("ARM: Fix __bss_start and __bss_end in linker scripts")
> > were moving the bss_start/end on c generated variables that were
> > injected in their own sections. The reason was that we needed relative
> > relocations for position independent code.
> >
> > However, the linker documentation pages states that symbols that are
> > defined within a section definition will create a relocatable
> > type with the value being a fixed offset from the base of a section.
> >
> > So let's start cleaning this up starting with the bss_start and bss_end
> > variables. Convert them into symbols within the .bss section definition.
> >
> > [0] https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html#SEC13
> >
> > Signed-off-by: Ilias Apalodimas
> Tested-by: Caleb Connolly # Qualcomm sdm845
>
> This patch and a few others in this series conflict with my patch [1]
> which drops the dragonboard820c linker script. My patch doesn't have any
> external dependencies, so would it be easier for you to take it along
> with this series? Or how best should we avoid the merge conflicts here?
Yes, I can carry the snapdragon lds removal. Rebasing on top is of it
is pretty easy
/Ilias
>
> [1]:
> https://lore.kernel.org/u-boot/20240226-b4-qcom-common-target-v5-19-10c8e078b...@linaro.org/
>
> Thanks and regards,
> > ---
> > arch/arm/cpu/armv8/u-boot-spl.lds | 14 +++---
> > arch/arm/cpu/armv8/u-boot.lds | 15 +++
> > arch/arm/cpu/u-boot.lds | 22 --
> > arch/arm/lib/sections.c | 2 --
> > arch/arm/mach-rockchip/u-boot-tpl-v8.lds | 14 +++---
> > arch/arm/mach-zynq/u-boot.lds | 21 +++--
> > board/qualcomm/dragonboard820c/u-boot.lds | 15 +++
> > 7 files changed, 19 insertions(+), 84 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds
> > b/arch/arm/cpu/armv8/u-boot-spl.lds
> > index 7cb9d731246d..16fddb46e9cb 100644
> > --- a/arch/arm/cpu/armv8/u-boot-spl.lds
> > +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
> > @@ -63,18 +63,10 @@ SECTIONS
> >
> > _image_binary_end = .;
> >
> > - .bss_start (NOLOAD) : {
> > - . = ALIGN(8);
> > - KEEP(*(.__bss_start));
> > - } >.sdram
> > -
> > - .bss (NOLOAD) : {
> > + .bss : {
> > + __bss_start = .;
> > *(.bss*)
> > - . = ALIGN(8);
> > - } >.sdram
> > -
> > - .bss_end (NOLOAD) : {
> > - KEEP(*(.__bss_end));
> > + __bss_end = .;
> > } >.sdram
> >
> > /DISCARD/ : { *(.rela*) }
> > diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
> > index fb6a30c922f7..c4ee10ebc3ff 100644
> > --- a/arch/arm/cpu/armv8/u-boot.lds
> > +++ b/arch/arm/cpu/armv8/u-boot.lds
> > @@ -149,19 +149,10 @@ SECTIONS
> >
> > _end = .;
> >
> > - . = ALIGN(8);
> > -
> > - .bss_start : {
> > - KEEP(*(.__bss_start));
> > - }
> > -
> > - .bss : {
> > + .bss ALIGN(8): {
> > + __bss_start = .;
> > *(.bss*)
> > - . = ALIGN(8);
> > - }
> > -
> > - .bss_end : {
> > - KEEP(*(.__bss_end));
> > + __bss_end = .;
> > }
> >
> > /DISCARD/ : { *(.dynsym) }
> > diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
> > index 7724c9332c3b..90d329b1ebe0 100644
> > --- a/arch/arm/cpu/u-boot.lds
> > +++ b/arch/arm/cpu/u-boot.lds
> > @@ -206,27 +206,13 @@ SECTIONS
> > *(.mmutable)
> > }
> >
> > -/*
> > - * Compiler-generated __bss_start and __bss_end, see arch/arm/lib/bss.c
> > - * __bss_base and __bss_limit are for linker only (overlay ordering)
> > - */
> > -
> > - .bss_start __rel_dyn_start (OVERLAY) : {
> > - KEEP(*(.__bss_start));
> > - __bss_base = .;
> > - }
> > -
> > - .bss __bss_base (OVERLAY) : {
> > + .bss ALIGN(4): {
> > + __bss_start = .;
> > *(.bss*)
> > - . = ALIGN(4);
> > - __bss_limit = .;
> > - }
> > -
> > - .bss_end __bss_limit (OVERLAY) : {
> > - KEEP(*(.__bss_end));
> > + __bss_end = .;
> > }
> >
> > - .dynsym _image_binary_end : { *(.dynsym) }
> > + .dynsym : { *(.dynsym) }
> > .dynbss : { *(.dynbss) }
> > .dynstr : { *(.dynstr*) }
> > .dynamic : { *(.dynamic*) }
> > diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
> > index 857879711c6a..8e8bd5797e16 100644
> > --- a/arch/arm/lib/sections.c
> > +++ b/arch/arm/lib/sections.c
> > @@ -19,8 +19,6 @@
> >* aliasing warnings.
> >*/
> >
> > -char __bss_start[0] __section(".__bss_start");
> > -char
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
On Thu, 22 Feb 2024 15:05:56 +0530, Sumit Garg wrote: > Changes in v6: > -- > - v6_dt: https://github.com/b49020/u-boot/tree/v6_dt > - Patch #3: Incorporate fix for sandbox CI failure. > - Patch #6: Incorporate shell script comments from Marek. > - Patch #8: Incorporate documentation review comments from Paul. > > [...] Applied to u-boot/next, thanks! -- Tom
[PATCH] dts: imx8mm: Add optee entry for binman
Used to embed the OPTEE OS binary into flash.bin so it can be
detected and loaded by trusted-firmware-arm.
Signed-off-by: Manuel Traut
---
arch/arm/dts/imx8mm-u-boot.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index 06f2f73a03..8ca4515c9f 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -130,6 +130,22 @@
type = "atf-bl31";
};
};
+
+#ifdef CONFIG_OPTEE
+ optee {
+ description = "OP-TEE";
+ type = "firmware";
+ arch = "arm";
+ os = "tee";
+ compression = "none";
+ load = <0xbe00>;
+ entry = <0xbe00>;
+
+ blob-ext {
+ filename =
"tee.bin";
+ };
+ };
+#endif
#endif
binman_fip: fip {
@@ -160,7 +176,11 @@
fdt = "fdt-SEQ";
firmware = "uboot";
#ifndef CONFIG_ARMV8_PSCI
+#ifdef CONFIG_OPTEE
+ loadables = "atf", "optee";
+#else
loadables = "atf";
+#endif
#endif
};
};
--
2.43.0
Re: [PATCH v10 12/15] arm: dts: Introduce am69-sk u-boot dts files
Hi Apurva
On 24/02/24 01:51, Apurva Nandan wrote:
From: Dasnavis Sabiya
Introduce the base dts files needed for u-boot or to augment the linux
dtbs for use in the u-boot-spl and u-boot binaries.
Signed-off-by: Dasnavis Sabiya
Signed-off-by: Apurva Nandan
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/k3-am69-r5-sk.dts | 106
arch/arm/dts/k3-am69-sk-u-boot.dtsi | 54 ++
board/ti/j784s4/MAINTAINERS | 6 ++
4 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/k3-am69-r5-sk.dts
create mode 100644 arch/arm/dts/k3-am69-sk-u-boot.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e484112dd7c..e3a47d055b0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1413,7 +1413,8 @@ dtb-$(CONFIG_SOC_K3_J721S2) += k3-am68-sk-base-board.dtb\
k3-j721s2-common-proc-board.dtb\
k3-j721s2-r5-common-proc-board.dtb
-dtb-$(CONFIG_SOC_K3_J784S4) += k3-j784s4-r5-evm.dtb
+dtb-$(CONFIG_SOC_K3_J784S4) += k3-am69-r5-sk.dtb \
+ k3-j784s4-r5-evm.dtb
dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
k3-am642-r5-evm.dtb \
diff --git a/arch/arm/dts/k3-am69-r5-sk.dts b/arch/arm/dts/k3-am69-r5-sk.dts
new file mode 100644
index 000..f177f563527
--- /dev/null
+++ b/arch/arm/dts/k3-am69-r5-sk.dts
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am69-sk.dts"
+#include "k3-j784s4-ddr-evm-lp4-4266.dtsi"
+#include "k3-j784s4-ddr.dtsi"
+#include "k3-am69-sk-u-boot.dtsi"
+
+/ {
+ chosen {
+ tick-timer = _timer0;
+ };
+
+ aliases {
+ remoteproc0 =
+ remoteproc1 = _0;
+ };
+
+ a72_0: a72@0 {
+ compatible = "ti,am654-rproc";
+ reg = <0x0 0x00a9 0x0 0x10>;
+ power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
+ <_pds 202 TI_SCI_PD_EXCLUSIVE>;
+ resets = <_reset 202 0>;
+ clocks = <_clks 61 0>;
+ assigned-clocks = <_clks 61 0>, <_clks 202 0>;
+ assigned-clock-parents = <_clks 61 2>;
+ assigned-clock-rates = <2>, <20>;
+ ti,sci = <>;
+ ti,sci-proc-id = <32>;
+ ti,sci-host-id = <10>;
+ bootph-pre-ram;
+ };
+
+ dm_tifs: dm-tifs {
+ compatible = "ti,j721e-dm-sci";
+ ti,host-id = <3>;
+ ti,secure-host;
+ mbox-names = "rx", "tx";
+ mboxes= <_proxy_mcu 21>, <_proxy_mcu 23>;
+ bootph-pre-ram;
+ };
+};
+
+_timer0 {
+ status = "okay";
+ clock-frequency = <25000>;
+ bootph-pre-ram;
+};
+
+_proxy_sa3 {
+ status = "okay";
+ bootph-pre-ram;
+};
+
+_proxy_mcu {
+ status = "okay";
+ bootph-pre-ram;
+};
+
+_mcu_wakeup {
+ sysctrler: sysctrler {
+ compatible = "ti,am654-system-controller";
+ mboxes= <_proxy_mcu 4>,
+ <_proxy_mcu 5>,
+ <_proxy_sa3 5>;
+ mbox-names = "tx", "rx", "boot_notify";
+ bootph-pre-ram;
+ };
+};
+
+ {
+ mboxes= <_proxy_mcu 8>, <_proxy_mcu 6>, <_proxy_mcu
5>;
+ mbox-names = "tx", "rx", "notify";
+ ti,host-id = <4>;
+ ti,secure-host;
+ bootph-pre-ram;
+};
+
+/* WKUP UART0 is used for DM firmware logs */
+_uart0 {
+ bootph-pre-ram;
+ status = "okay";
+};
+
+ {
+ reg = <0x0 0x4704 0x0 0x100>,
+ <0x0 0x5000 0x0 0x800>;
+};
+
+ {
+ reg = <0x0 0x4705 0x0 0x100>,
+ <0x0 0x5800 0x0 0x800>;
+};
+
+_ringacc {
+ ti,sci = <_tifs>;
+};
+
+_udmap {
+ ti,sci = <_tifs>;
+};
diff --git a/arch/arm/dts/k3-am69-sk-u-boot.dtsi
b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
new file mode 100644
index 000..bed330e6d4e
--- /dev/null
+++ b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-j784s4-binman.dtsi"
+
+/ {
+ memory@8000 {
+ bootph-all;
+ };
+};
+
+_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;
+};
+
+ {
+ k3_sysreset: sysreset-controller {
+ compatible =
Re: [PATCH v10 15/15] doc: board: ti: k3: Add J784S4 EVM and AM69 SK documentation
Hi Apurva On 24/02/24 01:51, Apurva Nandan wrote: TI K3 J784S4 and AM69 are new additions to the K3 SoC family. Add documentation about the J784S4 EVM and AM69 SK. Signed-off-by: Dasnavis Sabiya Signed-off-by: Apurva Nandan --- board/ti/j784s4/MAINTAINERS | 1 + doc/board/ti/j784s4_evm.rst | 299 doc/board/ti/k3.rst | 1 + 3 files changed, 301 insertions(+) create mode 100644 doc/board/ti/j784s4_evm.rst diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS index 46f4ba5da96..b7605ff335b 100644 --- a/board/ti/j784s4/MAINTAINERS +++ b/board/ti/j784s4/MAINTAINERS @@ -10,6 +10,7 @@ F:arch/arm/dts/k3-j784s4-evm-u-boot.dtsi F:arch/arm/dts/k3-j784s4-r5-evm.dts F:arch/arm/dts/k3-j784s4-ddr.dtsi F:arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi +F: doc/board/ti/j784s4_evm.rst AM69 SK BOARD M:Apurva Nandan diff --git a/doc/board/ti/j784s4_evm.rst b/doc/board/ti/j784s4_evm.rst new file mode 100644 index 000..5c4bd2c927d --- /dev/null +++ b/doc/board/ti/j784s4_evm.rst @@ -0,0 +1,299 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause +.. sectionauthor:: Apurva Nandan + +J784S4 and AM69 Platforms += + +Introduction + +The J784S4 SoC belongs to the K3 Multicore SoC architecture +platform, providing advanced system integration in automotive, +ADAS and industrial applications requiring AI at the network edge. +This SoC extends the K3 Jacinto 7 family of SoCs with focus on +raising performance and integration while providing interfaces, +memory architecture and compute performance for multi-sensor, high +concurrency applications. + +The device is partitioned into three functional domains, each containing +specific processing cores and peripherals: + +1. Wake-up (WKUP) domain +* ARM Cortex-M4F processor, runs TI Foundational Security (TIFS) + +2. Microcontroller (MCU) domain +* Dual core ARM Cortex-R5F processor, runs device management + and SoC early boot + +3. MAIN domain +* Two clusters of quad core 64-bit ARM Cortex-A72, runs HLOS +* Dual core ARM Cortex-R5F processor used for RTOS applications +* Four C7x DSPs used for Machine Learning applications. + + +More info can be found in TRM: http://www.ti.com/lit/zip/spruj52 + +Platform information: + +* https://www.ti.com/tool/J784S4XEVM +* https://www.ti.com/tool/SK-AM69 + +Boot Flow +- +Below is the pictorial representation of boot flow: + +.. image:: img/boot_diagram_k3_current.svg +:alt: K3 boot flow + +- On this platform, "TI Foundational Security" (TIFS) functions as the + security enclave master. While "Device Manager" (DM), also known as the + "TISCI server" in TI terminology, offers all the essential services. + +- As illustrated in the diagram above, R5 SPL manages power and clock + services independently before handing over control to DM. The A72 or + the C7x (Aux core) software components request TIFS/DM to handle + security or device management services. + +Sources +--- + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_boot_sources +:end-before: .. k3_rst_include_end_boot_sources + +Build procedure +--- +0. Setup the environment variables: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_desc +:end-before: .. k3_rst_include_end_common_env_vars_desc + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_board_env_vars_desc +:end-before: .. k3_rst_include_end_board_env_vars_desc + +Set the variables corresponding to this platform: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_defn +:end-before: .. k3_rst_include_end_common_env_vars_defn +.. code-block:: bash + + $ export UBOOT_CFG_CORTEXR=j784s4_evm_r5_defconfig + $ export UBOOT_CFG_CORTEXA=j784s4_evm_a72_defconfig + $ export TFA_BOARD=j784s4 + $ export TFA_EXTRA_ARGS="K3_USART=0x8" + $ export OPTEE_PLATFORM=k3-j784s4 + $ export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8" + +.. j784s4_evm_rst_include_start_build_steps + +1. Trusted Firmware-A + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_tfa +:end-before: .. k3_rst_include_end_build_steps_tfa + + +2. OP-TEE + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_optee +:end-before: .. k3_rst_include_end_build_steps_optee + +3. U-Boot + +.. _j784s4_evm_rst_u_boot_r5: + +* 3.1 R5 + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_spl_r5 +:end-before: .. k3_rst_include_end_build_steps_spl_r5 + +.. _j784s4_evm_rst_u_boot_a72: + +* 3.2 A72 + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_uboot +:end-before: .. k3_rst_include_end_build_steps_uboot +.. j784s4_evm_rst_include_end_build_steps + +Target Images +- +In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC +variant
RE: [UBOOT PATCH v3] mtd: nand: arasan: Print warning for unsupported ecc modes
Hi Michal,
> -Original Message-
> From: Simek, Michal
> Sent: Friday, March 1, 2024 4:55 PM
> To: Abbarapu, Venkatesh ; u-
> b...@lists.denx.de
> Cc: dario.binac...@amarulasolutions.com; mich...@amarulasolutions.com;
> git (AMD-Xilinx) ; Ashok Reddy Soma
>
> Subject: Re: [UBOOT PATCH v3] mtd: nand: arasan: Print warning for
> unsupported ecc modes
>
>
>
> On 3/1/24 12:12, Venkatesh Yadav Abbarapu wrote:
> > Currently only hw ecc is supported in U-Boot. If any other ecc mode is
> > given in DT, it simply ignores and switches to hw ecc. So better print
> > what is being done.
> >
> > Revert this patch once soft ecc support is fixed in future.
> >
> > Signed-off-by: Ashok Reddy Soma
> > Signed-off-by: Venkatesh Yadav Abbarapu
>
> > ---
> > Changes in v2:
> > - Added the ecc mode check in the arasan driver itself.
> > Changes in v3:
> > - Skip the driver probe when sw-ecc mode is present in the device tree.
> > ---
> > drivers/mtd/nand/raw/arasan_nfc.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/raw/arasan_nfc.c
> > b/drivers/mtd/nand/raw/arasan_nfc.c
> > index 14766401bf..426160c384 100644
> > --- a/drivers/mtd/nand/raw/arasan_nfc.c
> > +++ b/drivers/mtd/nand/raw/arasan_nfc.c
> > @@ -1233,6 +1233,7 @@ static int arasan_probe(struct udevice *dev)
> > struct mtd_info *mtd;
> > ofnode child;
> > int err = -1;
> > + const char *str;
> >
> > info->reg = dev_read_addr_ptr(dev);
> > mtd = nand_to_mtd(nand_chip);
> > @@ -1263,6 +1264,12 @@ static int arasan_probe(struct udevice *dev)
> > goto fail;
> > }
> >
> > + str = ofnode_read_string(nand_chip->flash_node, "nand-ecc-mode");
> > + if (strcmp(str, "hw")) {
> > + printf("%s ecc is not supported, switch to hw ecc\n", str);
>
> you are returning below. It means switch to HW ecc is not happening right?
Yes. We are not switching to HW ecc, just returning from the probe
if it is other that HW ecc.
Thanks
Venkatesh
>
> M
Re: [PATCH] mtd: nand: arasan: Update the correct return codes
On Fri, Mar 01, 2024 at 04:51:09PM +0530, Venkatesh Yadav Abbarapu wrote:
> The below exception observed on QEMU, as it doesn't support
> NAND controller.
>
> "Synchronous Abort" handler, esr 0x9605, far 0x17acfc878
> elr: 0803ad40 lr : 0805f438 (reloc)
> elr: 7fcb4d40 lr : 7fcd9438
> x0 : 7bbfc880 x1 : ff10
> x2 : 7fcf059c x3 : 7bbfc870
> x4 : 7fd9a388 x5 : 00017acfc870
> x6 : x7 : 7bbfd0e0
> x8 : 3dd4 x9 : 7bbeec0c
> x10: 0001 x11: 3f8c
> x12: 7bbeecfc x13: 7bbeeeb0
> x14: 7bbeeeb0 x15: 7bbee474
> x16: 7fcef18c x17:
> x18: 7bbf9d70 x19: 7bbfc888
> x20: 7bbfc870 x21: 7fd68ddb
> x22: ffed x23: 7bbfc878
> x24: x25:
> x26: x27:
> x28: x29: 7bbeed10
>
> Code: 927ff8c1 924000c6 8b010065 f9400887 (f94004a2)
> Resetting CPU ...
>
> Updating the correct return codes rather than hardcoding, remove the
> free as there is no memory allocated using malloc.
>
> Signed-off-by: Venkatesh Yadav Abbarapu
The crash is caused by the use after free because we shouldn't
free(nand)? Returning the correct error codes is nice, but it shouldn't
cause a crash...
Fixes: 3dd0f8cccd6d ("mtd: nand: Remove hardcoded base address of nand")
regards,
dan carpenter
Re: [UBOOT PATCH v3] mtd: nand: arasan: Print warning for unsupported ecc modes
On Fri, Mar 01, 2024 at 04:42:54PM +0530, Venkatesh Yadav Abbarapu wrote:
> @@ -1263,6 +1264,12 @@ static int arasan_probe(struct udevice *dev)
> goto fail;
> }
>
> + str = ofnode_read_string(nand_chip->flash_node, "nand-ecc-mode");
> + if (strcmp(str, "hw")) {
> + printf("%s ecc is not supported, switch to hw ecc\n", str);
I'm a newbie to device trees, but the two other callers assume that it's
possible for ofnode_read_string(nand->flash_node, "nand-ecc-mode") to
return NULL so probably we should add a NULL check here too.
if (!str || strcmp(str, "hw") != 0) {
regards,
dan carpenter
Re: [UBOOT PATCH v3] mtd: nand: arasan: Print warning for unsupported ecc modes
On 3/1/24 12:12, Venkatesh Yadav Abbarapu wrote:
Currently only hw ecc is supported in U-Boot. If any other ecc mode is
given in DT, it simply ignores and switches to hw ecc. So better print
what is being done.
Revert this patch once soft ecc support is fixed in future.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
Changes in v2:
- Added the ecc mode check in the arasan driver itself.
Changes in v3:
- Skip the driver probe when sw-ecc mode is present in the device tree.
---
drivers/mtd/nand/raw/arasan_nfc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/nand/raw/arasan_nfc.c
b/drivers/mtd/nand/raw/arasan_nfc.c
index 14766401bf..426160c384 100644
--- a/drivers/mtd/nand/raw/arasan_nfc.c
+++ b/drivers/mtd/nand/raw/arasan_nfc.c
@@ -1233,6 +1233,7 @@ static int arasan_probe(struct udevice *dev)
struct mtd_info *mtd;
ofnode child;
int err = -1;
+ const char *str;
info->reg = dev_read_addr_ptr(dev);
mtd = nand_to_mtd(nand_chip);
@@ -1263,6 +1264,12 @@ static int arasan_probe(struct udevice *dev)
goto fail;
}
+ str = ofnode_read_string(nand_chip->flash_node, "nand-ecc-mode");
+ if (strcmp(str, "hw")) {
+ printf("%s ecc is not supported, switch to hw ecc\n", str);
you are returning below. It means switch to HW ecc is not happening right?
M
[PATCH] mtd: nand: arasan: Update the correct return codes
The below exception observed on QEMU, as it doesn't support
NAND controller.
"Synchronous Abort" handler, esr 0x9605, far 0x17acfc878
elr: 0803ad40 lr : 0805f438 (reloc)
elr: 7fcb4d40 lr : 7fcd9438
x0 : 7bbfc880 x1 : ff10
x2 : 7fcf059c x3 : 7bbfc870
x4 : 7fd9a388 x5 : 00017acfc870
x6 : x7 : 7bbfd0e0
x8 : 3dd4 x9 : 7bbeec0c
x10: 0001 x11: 3f8c
x12: 7bbeecfc x13: 7bbeeeb0
x14: 7bbeeeb0 x15: 7bbee474
x16: 7fcef18c x17:
x18: 7bbf9d70 x19: 7bbfc888
x20: 7bbfc870 x21: 7fd68ddb
x22: ffed x23: 7bbfc878
x24: x25:
x26: x27:
x28: x29: 7bbeed10
Code: 927ff8c1 924000c6 8b010065 f9400887 (f94004a2)
Resetting CPU ...
Updating the correct return codes rather than hardcoding, remove the
free as there is no memory allocated using malloc.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/mtd/nand/raw/arasan_nfc.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/raw/arasan_nfc.c
b/drivers/mtd/nand/raw/arasan_nfc.c
index 426160c384..d78e9ada82 100644
--- a/drivers/mtd/nand/raw/arasan_nfc.c
+++ b/drivers/mtd/nand/raw/arasan_nfc.c
@@ -1232,7 +1232,7 @@ static int arasan_probe(struct udevice *dev)
struct nand_config *nand = >config;
struct mtd_info *mtd;
ofnode child;
- int err = -1;
+ int ret;
const char *str;
info->reg = dev_read_addr_ptr(dev);
@@ -1259,9 +1259,10 @@ static int arasan_probe(struct udevice *dev)
writel(0x0, >reg->pgm_reg);
/* first scan to find the device and get the page size */
- if (nand_scan_ident(mtd, CONFIG_SYS_NAND_MAX_CHIPS, NULL)) {
+ ret = nand_scan_ident(mtd, CONFIG_SYS_NAND_MAX_CHIPS, NULL);
+ if (ret) {
printf("%s: nand_scan_ident failed\n", __func__);
- goto fail;
+ return ret;
}
str = ofnode_read_string(nand_chip->flash_node, "nand-ecc-mode");
@@ -1289,26 +1290,26 @@ static int arasan_probe(struct udevice *dev)
nand_chip->ecc.bytes = 0;
nand_chip->ecc.layout = _nand_oob_64;
} else {
- if (arasan_nand_ecc_init(mtd)) {
+ ret = arasan_nand_ecc_init(mtd);
+ if (ret) {
printf("%s: nand_ecc_init failed\n", __func__);
- goto fail;
+ return ret;
}
}
- if (nand_scan_tail(mtd)) {
+ ret = nand_scan_tail(mtd);
+ if (ret) {
printf("%s: nand_scan_tail failed\n", __func__);
- goto fail;
+ return ret;
}
- if (nand_register(0, mtd)) {
+ ret = nand_register(0, mtd);
+ if (ret) {
printf("Nand Register Fail\n");
- goto fail;
+ return ret;
}
- return 0;
-fail:
- free(nand);
- return err;
+ return ret;
}
static const struct udevice_id arasan_nand_dt_ids[] = {
--
2.25.1
[UBOOT PATCH v3] mtd: nand: arasan: Print warning for unsupported ecc modes
Currently only hw ecc is supported in U-Boot. If any other ecc mode is
given in DT, it simply ignores and switches to hw ecc. So better print
what is being done.
Revert this patch once soft ecc support is fixed in future.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
Changes in v2:
- Added the ecc mode check in the arasan driver itself.
Changes in v3:
- Skip the driver probe when sw-ecc mode is present in the device tree.
---
drivers/mtd/nand/raw/arasan_nfc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/nand/raw/arasan_nfc.c
b/drivers/mtd/nand/raw/arasan_nfc.c
index 14766401bf..426160c384 100644
--- a/drivers/mtd/nand/raw/arasan_nfc.c
+++ b/drivers/mtd/nand/raw/arasan_nfc.c
@@ -1233,6 +1233,7 @@ static int arasan_probe(struct udevice *dev)
struct mtd_info *mtd;
ofnode child;
int err = -1;
+ const char *str;
info->reg = dev_read_addr_ptr(dev);
mtd = nand_to_mtd(nand_chip);
@@ -1263,6 +1264,12 @@ static int arasan_probe(struct udevice *dev)
goto fail;
}
+ str = ofnode_read_string(nand_chip->flash_node, "nand-ecc-mode");
+ if (strcmp(str, "hw")) {
+ printf("%s ecc is not supported, switch to hw ecc\n", str);
+ return -EINVAL;
+ }
+
nand_chip->ecc.mode = NAND_ECC_HW;
nand_chip->ecc.hwctl = NULL;
nand_chip->ecc.read_page = arasan_nand_read_page_hwecc;
--
2.25.1
Re: [PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot
Hi Tom, On Thu, 22 Feb 2024 at 15:06, Sumit Garg wrote: > > Changes in v6: > -- > - v6_dt: https://github.com/b49020/u-boot/tree/v6_dt > - Patch #3: Incorporate fix for sandbox CI failure. > - Patch #6: Incorporate shell script comments from Marek. > - Patch #8: Incorporate documentation review comments from Paul. > I haven't heard any major feedback/comments for v6. So can you pick up this series for the U-Boot -next branch? As you may already be aware that it is a dependency for [1] [2] [3]. Also, we would like to move all new Qcom platforms to use upstream DT too. [1] https://patchwork.ozlabs.org/project/uboot/list/?series=396399 [2] https://patchwork.ozlabs.org/project/uboot/list/?series=396742 [3] https://patchwork.ozlabs.org/project/uboot/list/?series=396992=* -Sumit > Changes in v5: > -- > - Rebased on tip of master (050a9b981d6a835133521b599be3ae189ce70f41) > - Created v5_dt branch for testing purposes: > https://github.com/b49020/u-boot/tree/v5_dt > - Patch #6: Added support to cherry-pick fixes in subtree update script. > Also, used https:// instead of git://. > - Patch #7: Fixed inappropriate documentation update. > - Patch #8: Document how to cherry-pick fixes from devicetree-rebasing > tree. > > Changes in v4: > -- > - Switched subtree to be imported as dts/upstream sub-directory rather > than devicetree-rebasing sub-directory to better suite U-Boot > directory structure. > - Since we now have v6.7-dts tag available now, so switch subtree to > that from its beginning. > - Patch #2: Incorporate build fix to adjust Bindings Makefile rules to > old U-Boot Kbuild infrastructure. > - Patch #3: Incorporate fix to resolve rk3399 migration issue reported > by Simon. > - Patch #4: New patch to reuse upstream DT includes by U-Boot as per > Brian's use-case for TI K3 SoCs. > - Patch #5: Added a note to OF_UPSTREAM Kconfig option. > - Patch #6: New patch to add script dts/update-dts-subtree.sh as per > Rob's comments. > - Patch #7: Separate patch to align documentation to use Kconfig symbols > instead. > - Patch #8: Clarify subtree uprev schedule as a separate documentation > section. Also, fixed documentation typos. > - Patch #9: Added commit description. > > Changes in v3: > -- > - Patch #4: Minor commit message update > - Patch #5: Replace CONFIG_* with Kconfig options > - Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC > instead. > - Patch #1, #3, #6 and #8: Picked up review tags > > Changes in v2: > -- > - Patch #1: excluded gitab CI config check and added commit description. > - Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/ > - Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > - Patch #5: s/U-boot/U-Boot/ > - Patch #6 and #7: Picked up review tags > > Prerequisite > > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-Boot repo via: > > $ git subtree add --prefix dts/upstream \ > > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > \ > v6.7-dts --squash > > Background > -- > > This effort started while I was reviewing patch series corresponding to > Qcom platforms [1] which was about to import modified devicetree source > files from Linux kernel. I suppose keeping devicetree files sync with > Linux kernel without any DT bindings schema validation has been a pain > for U-Boot SoC/platform maintainers. There has been past discussions > about a single DT repo but that hasn't come up and Linux kernel remained > the place where DT source files as well as bindings are placed and > maintained. > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather > use devicetree-rebasing repo [3] which is a forked copy from Linux > kernel for DT source files as well as bindings. It is tagged at every > Linux kernel major release or intermideate release candidates. So here I > have tried to reuse that to bring DT bingings compliance as well as a > standard way to maintain a regular sync of DT source files with Linux > kernel. > > In order to maintain devicetree files sync, U-Boot will maintains a Git > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window > opens with the next available kernel major release. > `dts/update-dts-subtree.sh` script provides a wrapper around git subtree > pull command, usage from the top level U-Boot source tree, run: > > $ ./dts/update-dts-subtree.sh pull > > If required it is also possible to cherry-pick fixes from > devicetree-rebasing tree prior to next sync, usage: > > $ ./dts/update-dts-subtree.sh pick > > The RFC/prototype for this series has been discussed with Linux DT > maintainers as well as U-Boot maintainers here [4]. Now we would like to > reach out to wider U-Boot community to seek feedback. > > [1] >
Re: [PATCH v2 2/2] net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO framework
On 2/28/24 4:05 PM, Roger Quadros wrote: > Add a new Kconfig symbol MDIO_TI_CPSW for the CPSW MDIO > driver and build it with proper DM support if enabled. > > If MDIO_TI_CPSW is not enabled then we continue to > behave like before. > > Clean up MDIO custom handling in am65-cpsw and use > dm_eth_phy_connect() to get the PHY. > > Signed-off-by: Roger Quadros > --- > Changelog: > > v2: no change > --- > drivers/net/ti/Kconfig | 8 ++ > drivers/net/ti/Makefile | 3 +- > drivers/net/ti/am65-cpsw-nuss.c | 190 ++ > drivers/net/ti/cpsw_mdio.c | 198 > +++- > drivers/net/ti/cpsw_mdio.h | 2 + > 5 files changed, 196 insertions(+), 205 deletions(-) > Tested dhcp and ping in u-boot on J721S2-EVM, SK-AM62B Tested-by: Ravi Gunasekaran -- Regards, Ravi
Re: [PATCH 01/10] mach-snapdragon: Add support for IPQ9574
Hi Krzysztof,
On Thu, 29 Feb 2024 at 22:50, Krzysztof Kozlowski wrote:
>
> On 26/02/2024 11:07, Varadarajan Narayanan wrote:
> > Signed-off-by: Varadarajan Narayanan
> > ---
> >
> > arch/arm/dts/Makefile |2 +
> > arch/arm/dts/ipq9574-default.dts | 167 +++
> > arch/arm/dts/ipq9574-rdp433-mht-phy.dts | 208 +++
> > arch/arm/dts/ipq9574.dtsi | 771 ++
> > .../include/mach/sysmap-ipq9574.h | 252
> > arch/arm/mach-snapdragon/init_ipq9574.c | 81 +
> > board/qualcomm/ipq9574/Kconfig| 15 +
> > board/qualcomm/ipq9574/Makefile |4 +
> > board/qualcomm/ipq9574/board_init.c | 326
> > board/qualcomm/ipq9574/ipq9574.c | 170 +++
> > board/qualcomm/ipq9574/ipq9574.h | 75 +
> > board/qualcomm/ipq9574/u-boot-x32.lds | 250
> > board/qualcomm/ipq9574/u-boot-x64.lds | 188 +++
> > drivers/clk/qcom/clock-ipq9574.c | 1320 +
> > drivers/pinctrl/qcom/pinctrl-ipq9574.c| 77 +
> > include/configs/ipq9574.h | 111 ++
> > include/dt-bindings/clock/gcc-ipq9574.h | 156 ++
> > include/dt-bindings/net/qti-ipqsoc.h | 20 +
> > include/dt-bindings/pinctrl/pinctrl-ipqsoc.h | 19 +
> > include/dt-bindings/reset/ipq9574-reset.h | 54 +
> > 20 files changed, 4266 insertions(+)
> > create mode 100644 arch/arm/dts/ipq9574-default.dts
> > create mode 100644 arch/arm/dts/ipq9574-rdp433-mht-phy.dts
> > create mode 100644 arch/arm/dts/ipq9574.dtsi
> > create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-ipq9574.h
> > create mode 100644 arch/arm/mach-snapdragon/init_ipq9574.c
> > create mode 100644 board/qualcomm/ipq9574/Kconfig
> > create mode 100644 board/qualcomm/ipq9574/Makefile
> > create mode 100644 board/qualcomm/ipq9574/board_init.c
> > create mode 100644 board/qualcomm/ipq9574/ipq9574.c
> > create mode 100644 board/qualcomm/ipq9574/ipq9574.h
> > create mode 100644 board/qualcomm/ipq9574/u-boot-x32.lds
> > create mode 100644 board/qualcomm/ipq9574/u-boot-x64.lds
> > create mode 100644 drivers/clk/qcom/clock-ipq9574.c
> > create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq9574.c
> > create mode 100644 include/configs/ipq9574.h
> > create mode 100644 include/dt-bindings/clock/gcc-ipq9574.h
> > create mode 100644 include/dt-bindings/net/qti-ipqsoc.h
> > create mode 100644 include/dt-bindings/pinctrl/pinctrl-ipqsoc.h
> > create mode 100644 include/dt-bindings/reset/ipq9574-reset.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index d9725030d5..8931dfa2aa 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -1523,6 +1523,8 @@ dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
> > dtb-$(CONFIG_TARGET_CORSTONE1000) += corstone1000-mps3.dtb \
> > corstone1000-fvp.dtb
> >
> > +dtb-$(CONFIG_TARGET_IPQ9574) += ipq9574-rdp433-mht-phy.dtb
> > +
> > include $(srctree)/scripts/Makefile.dts
> >
> > targets += $(dtb-y)
> > diff --git a/arch/arm/dts/ipq9574-default.dts
> > b/arch/arm/dts/ipq9574-default.dts
> > new file mode 100644
> > index 00..501c9492df
> > --- /dev/null
> > +++ b/arch/arm/dts/ipq9574-default.dts
> > @@ -0,0 +1,167 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights
> > reserved.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "ipq9574.dtsi"
> > +
> > +/ {
> > + config_name = "config-default";
> > +
> > + aliases {
> > + console = _uart2_console;
> > + uart2 = _uart3_additional;
> > + sdhci =
> > + };
> > +
> > + soc: soc {
> > + tlmm: pinctrl@100 {
> > +
> > + sdhci_pinmux: mmc {
> > + pinconfig;
> > + emmc_data {
>
> No, please use upstream DTS.
>
> You imported here a lot of vendor junk. There is no way this will pass
> any System Ready tests if you hand over this DTB to Linux. Plus really,
> that's ugly DTS to look at.
>
> I am not a maintainer of DTS in U-Boot, so up to the folks here, but I
> really recommend to NAK such DTS. It just re-adds all the issues we
> fixed in upstream kernel!
>
> I suggest using dts/upstream/qcom, but if you cannot then please import
> kernel DTS.
Yes, please. There's a lot of effort updating the dts file in u-boot
and using as much as we can verbatim from the upstream repos. Let's
not take any steps backwards
>
> Best regards,
> Krzysztof
>
Re: [PATCH v1 0/5] TEE: minor cleanup
Hi Igor, On Thu, 29 Feb 2024 at 21:11, Igor Opaniuk wrote: > > Hi Ilias, > > On Wed, Feb 14, 2024 at 7:34 PM Igor Opaniuk > wrote: >> >> - Address some spelling errors and typos >> - Support CMD_OPTEE_RPMB for SANDBOX configurations and add python tests >> - Remove common.h inclusion for drivers/tee CI fails on https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/19780 Can you have a look? Thanks /Ilias >> >> Igor Opaniuk (5): >> tee: optee: fix description in Kconfig >> tee: sandbox: fix spelling errors >> cmd: optee_rpmb: build cmd for sandbox >> test: py: add optee_rpmb tests >> tee: remove common.h inclusion >> >> cmd/Kconfig| 4 +++- >> drivers/tee/broadcom/chimp_optee.c | 2 +- >> drivers/tee/optee/Kconfig | 2 +- >> drivers/tee/optee/core.c | 1 - >> drivers/tee/optee/i2c.c| 1 - >> drivers/tee/optee/rpmb.c | 1 - >> drivers/tee/optee/supplicant.c | 2 +- >> drivers/tee/sandbox.c | 10 +- >> drivers/tee/tee-uclass.c | 1 - >> test/py/tests/test_optee_rpmb.py | 20 >> 10 files changed, 31 insertions(+), 13 deletions(-) >> create mode 100644 test/py/tests/test_optee_rpmb.py >> >> -- >> 2.34.1 >> > > Are there currently any comments/objections that can prevent these cosmetic > changes from being applied? If there are - just let me know, thanks > > Regards, > Igor > > -- > Best regards - Atentamente - Meilleures salutations > > Igor Opaniuk > > mailto: igor.opan...@gmail.com > skype: igor.opanyuk > http://ua.linkedin.com/in/iopaniuk
Re: [PATCH 1/2] opos6uldev: make the LCD work again
On 3/1/24 07:02, Sumit Garg wrote:
On Thu, 29 Feb 2024 at 19:31, Tom Rini wrote:
On Thu, Feb 29, 2024 at 08:42:42AM -0500, Tom Rini wrote:
On Thu, Feb 29, 2024 at 11:17:28AM +0530, Sumit Garg wrote:
On Wed, 28 Feb 2024 at 20:50, Tom Rini wrote:
On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
+ Shawn, Krzysztof, Conor
Hi Tom,
On Wed, 28 Feb 2024 at 18:40, Tom Rini wrote:
On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski wrote:
Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with
linux") removed the display timings from the board device tree whereas
they are still needed by the mxsfb driver.
Add the timings back (the correct ones) in the
imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
opos6uldev.env file.
Update the opos6uldev_defconfig file so that the LCD turns on at boot.
Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with linux")
Signed-off-by: Sébastien Szymanski
Huh. This is the commit that did that upstream.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
It's interesting how the timings in linux were always slightly different
from in u-boot.
Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
because this is a recent (rather than ancient) example of one of the
concerns about OF_UPSTREAM.
I rather think about this as an opportunity to improve with
OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
corresponding Linux kernel sub-arch maintainers. Especially once we
move to OF_UPSTREAM and a sub-arch maintainer profile in Linux kernel
to keep them aware that U-Boot should be considered too.
Yes, a more extensive check around when removing information from dts
files would be good.
I think the commit in question can be
summarized as "remove a bunch of explicit HW information because there's
now a Linux Kernel driver that determines that dynamically". What do we
do next? The old information is in a presumably valid binding still, can
we just put it back and comment that consumers outside of Linux use this
still so it's not removed again later? Or am I just missing where we can
instead get this information from the DT still and not need to come up
with a new driver and subsystems?
I can see following two paths forward:
1) Partially revert the Linux kernel commit to add back the display
timings in DT.
2) Extend drivers/video/simple_panel.c in U-Boot to add support for
compatible: "armadeus,st0700-adapt".
If possible then I would be in favour of (2) rather than the current
patch to do this properly.
Well, looking at the kernel drivers/gpu/drm/panel/panel-simple.c driver
and then our drivers/video/simple_panel.c it sure would be nice if it's
just a matter of adding a compatible but I wouldn't be surprised if it
ends up needing more information being passed along too?
Although I am not a LCD panel expert but looking at the kernel driver
code [1], the display timings are rather taken from a static data
structure matching the compatible "armadeus,st0700-adapt".
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c#n901
Yes. My point is that it seems like the situation changed from "device
tree provides timings for the platform" to "driver has timing
information for N displays" and so we'll need to do something clever to
avoid including the structs for 5 panels when we'll only ever
(likely...) see one. And that also yes, we'll probably need to add data
for this panel rather than re-use the PANASONIC_VVX10F004B00 data.
And I'm going
assume there's good reasons for the design change in how the drivers
work in Linux now and note that it might make things more challenging
for us when we do care about space.
I agree it is always going to be challenging to use DT during SPL
stage which is mostly constrained by limited on-chip RAM.
Well, no. The DT way handled this more efficiently, I think I wasn't
clear enough in my reply.
And it's not just SPL, full U-Boot needs to stay small and within flash
partition considerations and I become cranky and question people when
non-generic changes impact platforms that don't need the change.
Okay I can see your point. I suppose this leads us to option (1) to
partially revert the Linux kernel commit [1] to add back the display
timings in DT. Ironically all the folks (developer, U-Boot and Linux
kernel iMX maintainers) were involved in the upstream process for the
Linux kernel commit [1] under question. So I will let them chime in
too.
It is also now possible to have the display timings under the panel node:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/panel/panel-simple.c?h=v6.8-rc6=4a1d0dbc8332231d1d500d7a1d13c45457262a97
Not sure if that could help here.
Regards,
[1]
[PATCH v2] board: rockchip: add Rockchip Toybrick TB-RK3588X board
TB-RK3588X board is a Rockchip Toybrick RK3588 based development board.
Specification:
Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16GB Memory LPDDR4x
Mali G610MC4 GPU
2× MIPI-CSI0 Connector
1x 2Lanes PCIe3.0 Connector
1x SATA3.0 Connector
32GB eMMC Module
2x USB 2.0, 2x USB 3.0
1x HDMI Output, 1x HDMI Input
2x Ethernet Port
Functions work normally:
[1] USB2.0 Host
[2] Ethernet0 with PHY RTL8211F
More information can be obtained from the following websites:
[1] https://t.rock-chips.com/en/wiki/EN/tb-rk3588x_en/index.html
[2] http://t.rock-chips.com/
Kernel commits:
8ffe365f8dc7 ("arm64: dts: rockchip: Add devicetree support for
TB-RK3588X board")
7140387ff49d ("dt-bindings: arm: rockchip: Add Toybrick TB-RK3588X")
Signed-off-by: Elon Zhang
---
Changes since v1:
- Remove BOARD_SPECIFIC_OPTIONS in board Kconfig
---
arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi | 12 +
arch/arm/dts/rk3588-toybrick-x0.dts | 672 ++
arch/arm/mach-rockchip/rk3588/Kconfig | 25 +
board/rockchip/toybrick_rk3588/Kconfig| 12 +
board/rockchip/toybrick_rk3588/MAINTAINERS| 8 +
board/rockchip/toybrick_rk3588/Makefile | 6 +
.../toybrick_rk3588/toybrick-rk3588.c | 39 +
configs/toybrick-rk3588_defconfig | 82 +++
doc/board/rockchip/rockchip.rst | 1 +
include/configs/toybrick_rk3588.h | 15 +
10 files changed, 872 insertions(+)
create mode 100644 arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588-toybrick-x0.dts
create mode 100644 board/rockchip/toybrick_rk3588/Kconfig
create mode 100644 board/rockchip/toybrick_rk3588/MAINTAINERS
create mode 100644 board/rockchip/toybrick_rk3588/Makefile
create mode 100644 board/rockchip/toybrick_rk3588/toybrick-rk3588.c
create mode 100644 configs/toybrick-rk3588_defconfig
create mode 100644 include/configs/toybrick_rk3588.h
diff --git a/arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi
b/arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi
new file mode 100644
index 00..1aeb5410e4
--- /dev/null
+++ b/arch/arm/dts/rk3588-toybrick-x0-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Rockchip Electronics Co., Ltd.
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl",
+ };
+};
diff --git a/arch/arm/dts/rk3588-toybrick-x0.dts
b/arch/arm/dts/rk3588-toybrick-x0.dts
new file mode 100644
index 00..f3f7c1d35e
--- /dev/null
+++ b/arch/arm/dts/rk3588-toybrick-x0.dts
@@ -0,0 +1,672 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "rk3588.dtsi"
+
+/ {
+ model = "Rockchip Toybrick TB-RK3588X Board";
+ compatible = "rockchip,rk3588-toybrick-x0", "rockchip,rk3588";
+
+ aliases {
+ mmc0 =
+ serial2 =
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ press-threshold-microvolt = <17000>;
+ };
+
+ button-vol-down {
+ label = "Volume Down";
+ linux,code = ;
+ press-threshold-microvolt = <417000>;
+ };
+
+ button-menu {
+ label = "Menu";
+ linux,code = ;
+ press-threshold-microvolt = <89>;
+ };
+
+ button-escape {
+ label = "Escape";
+ linux,code = ;
+ press-threshold-microvolt = <1235000>;
+ };
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ power-supply = <_dcin>;
+ pwms = < 0 25000 0>;
+ };
+
+ pcie20_avdd0v85: pcie20-avdd0v85-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie20_avdd0v85";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <85>;
+ regulator-max-microvolt = <85>;
+ vin-supply = <_0v85_s0>;
+ };
+
+ pcie20_avdd1v8: pcie20-avdd1v8-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie20_avdd1v8";
+
RE: [PATCH 1/2] arm: socfpga: arria10: add option to reprogram the FPGA every reboot
> -Original Message-
> From: Michał Barnaś
> Sent: Thursday, February 22, 2024 11:21 PM
> To: u-boot@lists.denx.de
> Cc: Michał Barnaś ; Dinh Nguyen
> ; Marek Vasut ; Simon Glass
> ; Simon Goldschmidt
> ; Chee, Tien Fong
> ; Tom Rini
> Subject: [PATCH 1/2] arm: socfpga: arria10: add option to reprogram the
> FPGA every reboot
>
> Add Kconfig that enables FPGA reprogramming with warm boot on Arria 10.
> This option allows to change the bitstream on the filesystem and apply
> changes with warm reboot without the need for a power cycle.
>
> Signed-off-by: Michał Barnaś
> ---
>
> arch/arm/mach-socfpga/Kconfig | 8
> arch/arm/mach-socfpga/spl_a10.c | 8
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-
> socfpga/Kconfig index 114d243812..89303f1f16 100644
> --- a/arch/arm/mach-socfpga/Kconfig
> +++ b/arch/arm/mach-socfpga/Kconfig
> @@ -80,6 +80,14 @@ config TARGET_SOCFPGA_ARRIA10
> imply FPGA_SOCFPGA
> imply SPL_USE_TINY_PRINTF
>
> +config TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
> + bool "Always reprogram Arria 10 FPGA"
> + depends on TARGET_SOCFPGA_ARRIA10
> + help
> + Arria 10 FPGA is only programmed during the cold boot.
> + This option forces the FPGA to be reprogrammed every reboot,
> + allowing to change the bitstream and apply it with warm reboot.
> +
> config TARGET_SOCFPGA_CYCLONE5
> bool
> select TARGET_SOCFPGA_GEN5
> diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-
> socfpga/spl_a10.c index 9edbbf4a29..d5d3327a42 100644
> --- a/arch/arm/mach-socfpga/spl_a10.c
> +++ b/arch/arm/mach-socfpga/spl_a10.c
> @@ -122,7 +122,11 @@ void spl_board_init(void)
> arch_early_init_r();
>
> /* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins */
> +#ifdef CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
> + if (is_regular_boot_valid()) {
> +#else
> if (is_fpgamgr_user_mode()) {
> +#endif
> ret = config_pins(gd->fdt_blob, "shared");
> if (ret)
> return;
> @@ -130,7 +134,11 @@ void spl_board_init(void)
> ret = config_pins(gd->fdt_blob, "fpga");
> if (ret)
> return;
> +#ifdef CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
> + } else {
> +#else
> } else if (!is_fpgamgr_early_user_mode()) {
> +#endif
> /* Program IOSSM(early IO release) or full FPGA */
> fpgamgr_program(buf, FPGA_BUFSIZ, 0);
>
> --
> 2.44.0.rc1.240.g4c46232300-goog
Reviewed-by: Tien Fong Chee
Regards
Tien Fong
RE: [PATCH 0/2] arm: socfpga: arria10: allow to reprogram FPGA with warm reboot
> -Original Message- > From: Michał Barnaś > Sent: Thursday, February 29, 2024 9:49 PM > To: Dinh Nguyen > Cc: u-boot@lists.denx.de; Marcel Ziswiler ; > Marek Vasut ; Martyn Welch > ; Paweł Anikiel ; Simon > Glass ; Simon Goldschmidt > ; Svyatoslav Ryhel > ; Chee, Tien Fong ; Tom > Rini > Subject: Re: [PATCH 0/2] arm: socfpga: arria10: allow to reprogram FPGA with > warm reboot > > On Thu, Feb 29, 2024 at 2:03 PM Dinh Nguyen wrote: > > > > > > > > On 2/22/24 09:20, Michał Barnaś wrote: > > > > > > By default, the board requires power cycle (cold boot) to program > > > the FPGA with bitstream. This change adds Kconfig that allows to > > > enable reprogramming the FPGA with every boot. This makes the update > > > process of the bitstream on the filesystem to be applied with simple > > > system reboot. > > > > > > > > > > If we want to enable the reprogramming on every boot, would it make > > sense to just do it and not even bother with the Kconfig option? > > > > Dinh > > The FPGA programming part takes quite a long time, so it increases the > reboot time significantly. > I don't think that everyone needs the reprogramming to happen every time. > We need that because our boards are closed in the lab and the power is not > easily accessible, so in case of update to the bitstream, we should be able to > remotely update it with a pure warm reboot. > So I thought that this should be set by Kconfig to not bother other users with > longer reboot times. > > Michał Reprogram should be avoided when FPGA already in user mode, this is for FPGA boot first use case. Full reprogram is slow in SPL, because very small buffer in this small OCRAM can only be used to process the full RBF. Since this is an optional configuration, I don't see any issue with these changes. Tien Fong
[PATCH] mtd: spinand: Add support for XTX SPI NAND
Add support for XTX XT26G0xA and XT26xxxD,the driver is ported from
linux-6.7.1.
---
drivers/mtd/nand/spi/Makefile | 2 +-
drivers/mtd/nand/spi/core.c | 1 +
drivers/mtd/nand/spi/xtx.c| 265 ++
include/linux/mtd/spinand.h | 1 +
4 files changed, 268 insertions(+), 1 deletion(-)
create mode 100755 drivers/mtd/nand/spi/xtx.c
diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index f172f4787f..65b836b34c 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
spinand-objs := core.o esmt.o gigadevice.o macronix.o micron.o paragon.o
-spinand-objs += toshiba.o winbond.o
+spinand-objs += toshiba.o winbond.o xtx.o
obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 8ca33459f9..62c28aa422 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -829,6 +829,7 @@ static const struct spinand_manufacturer
*spinand_manufacturers[] = {
_spinand_manufacturer,
_spinand_manufacturer,
_c8_spinand_manufacturer,
+ _spinand_manufacturer,
};
static int spinand_manufacturer_match(struct spinand_device *spinand,
diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
new file mode 100755
index 00..dde0564c56
--- /dev/null
+++ b/drivers/mtd/nand/spi/xtx.c
@@ -0,0 +1,265 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Author:
+ * Felix Matouschek
+ */
+
+#include
+#ifndef __UBOOT__
+#include
+#include
+#endif
+#include
+
+#define SPINAND_MFR_XTX0x0B
+
+#define XT26G0XA_STATUS_ECC_MASK GENMASK(5, 2)
+#define XT26G0XA_STATUS_ECC_NO_DETECTED(0 << 2)
+#define XT26G0XA_STATUS_ECC_8_CORRECTED(3 << 4)
+#define XT26G0XA_STATUS_ECC_UNCOR_ERROR(2 << 4)
+
+#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
+#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
+#define XT26XXXD_STATUS_ECC_1_7_CORRECTED (1)
+#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
+#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+ SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+ SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+ SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+ SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+ SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int xt26g0xa_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->offset = 48;
+ region->length = 16;
+
+ return 0;
+}
+
+static int xt26g0xa_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->offset = 1;
+ region->length = 47;
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops xt26g0xa_ooblayout = {
+ .ecc = xt26g0xa_ooblayout_ecc,
+ .rfree = xt26g0xa_ooblayout_free,
+};
+
+static int xt26g0xa_ecc_get_status(struct spinand_device *spinand,
+u8 status)
+{
+ status = status & XT26G0XA_STATUS_ECC_MASK;
+
+ switch (status) {
+ case XT26G0XA_STATUS_ECC_NO_DETECTED:
+ return 0;
+ case XT26G0XA_STATUS_ECC_8_CORRECTED:
+ return 8;
+ case XT26G0XA_STATUS_ECC_UNCOR_ERROR:
+ return -EBADMSG;
+ default:
+ break;
+ }
+
+ /* At this point values greater than (2 << 4) are invalid */
+ if (status > XT26G0XA_STATUS_ECC_UNCOR_ERROR)
+ return -EINVAL;
+
+ /* (1 << 2) through (7 << 2) are 1-7 corrected errors */
+ return status >> 2;
+}
+
+static int xt26xxxd_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->offset = mtd->oobsize / 2;
+ region->length = mtd->oobsize / 2;
+
+ return 0;
+}
+
+static int xt26xxxd_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->offset = 2;
+ region->length = mtd->oobsize / 2 - 2;
+
+ return 0;
+}
+
+static const struct
