Re: [u-boot][PATCH v2 2/4] scripts: Makefile.spl: Enable memory drivers to be built for SPL
Tom, On 26/10/2022 02:35, Simon Glass wrote: > Hi Tom, > > On Thu, 20 Oct 2022 at 06:29, Tom Rini wrote: >> >> On Thu, Oct 20, 2022 at 03:23:42PM +0300, Roger Quadros wrote: >>> Hi Tom, >>> >>> On 19/10/2022 15:54, Tom Rini wrote: >>>> On Wed, Oct 19, 2022 at 11:17:35AM +0300, Roger Quadros wrote: >>>>> >>>>> >>>>> On 18/10/2022 20:40, Tom Rini wrote: >>>>>> On Thu, Oct 06, 2022 at 04:23:58PM +0300, Roger Quadros wrote: >>>>>>> We will need ti-gpmc driver for SPL. Allow memory drivers >>>>>>> do be built for SPL. >>>>>>> >>>>>>> Signed-off-by: Roger Quadros >>>>>>> --- >>>>>>> scripts/Makefile.spl | 1 + >>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl >>>>>>> index 3bafeb4fe9..110076b22f 100644 >>>>>>> --- a/scripts/Makefile.spl >>>>>>> +++ b/scripts/Makefile.spl >>>>>>> @@ -114,6 +114,7 @@ libs-$(CONFIG_PARTITIONS) += disk/ >>>>>>> endif >>>>>>> >>>>>>> libs-y += drivers/ >>>>>>> +libs-y += drivers/memory/ >>>>>>> libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/dwc3/ >>>>>>> libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/cdns3/ >>>>>>> libs-y += dts/ >>>>>> >>>>>> This ends up being the wrong approach as it then pulls in >>>>>> drivers/memory/stm32-fmc2-ebi.o on all of those platforms, in SPL, which >>>>>> is not what's intended. We need an SPL_MEMORY symbol and then gate the >>>>>> directory on that. >>>>>> >>> >>> I have a question about how CONFIG_SPL_MEMORY works together with >>> CONFIG_MEMORY. >>> >>> Do we use CONFIG_SPL_MEMORY only to gate the drivers/memory directory >>> inclusion? >>> Then continue to use CONFIG_MEMORY and others to enable/disable driver >>> build for both non-SPL and SPL case? >>> >>> So drivers/memory/Makefile remains as it is? >> >> Well, for consistency code should use IS_ENABLED(MEMORY) which will be >> true for CONFIG_MEMORY or CONFIG_SPL_MEMORY. > > nit: CONFIG_IS_ENABLED(MEMORY) CONFIG_IS_ENABLED* is used in code but not by any Makefile. My question was on what basis do we gate drivers/memory inclusion in build from Makefile. Can CONFIG_MEMORY and CONFIG_SPL_MEMORY co-exist or that should never happen? > > Perhaps we can look at my Kconfig series so it can become > CONFIG(MEMORY) and we can drop all the SPL_TPL_ stuff in Makefiles? > > Regards, > SImon cheers, -roger
[u-boot][PATCH v3 4/4] memory: Add TI GPMC driver
The GPMC is a unified memory controller dedicated for interfacing
with external memory devices like
- Asynchronous SRAM-like memories and ASICs
- Asynchronous, synchronous, and page mode burst NOR flash
- NAND flash
- Pseudo-SRAM devices
This driver will take care of setting up the GPMC based on
the settings specified in the Device tree and then
probe its children.
Signed-off-by: Roger Quadros
---
drivers/memory/Kconfig| 19 +
drivers/memory/Makefile |1 +
drivers/memory/ti-gpmc.c | 1240 +
drivers/memory/ti-gpmc.h | 298
include/linux/mtd/omap_gpmc.h |3 +
5 files changed, 1561 insertions(+)
create mode 100644 drivers/memory/ti-gpmc.c
create mode 100644 drivers/memory/ti-gpmc.h
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index c621f5bba3..56b89f17be 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -41,4 +41,23 @@ config TI_AEMIF
of 256M bytes of any of these memories can be accessed at a given
time via four chip selects with 64M byte access per chip select.
+config TI_GPMC
+ bool "Texas Instruments GPMC driver"
+ depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ depends on MEMORY && CLK && OF_CONTROL
+ help
+ This driver is for the General Purpose Memory Controller (GPMC)
+ present on Texas Instruments SoCs (e.g. OMAP2+). GPMC allows
+ interfacing to a variety of asynchronous as well as synchronous
+ memory drives like NOR, NAND, OneNAND, SRAM.
+
+if TI_GPMC
+config TI_GPMC_DEBUG
+ bool "Debug Texas Instruments GPMC timings"
+ default n
+ help
+ Enable this to print GPMC timings before and after the GPMC registers
+ are programmed. This should not be left enabled on production systems.
+endif
+
endmenu
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index b27f701865..2b196d78c0 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_MEMORY) += memory-uclass.o
obj-$(CONFIG_SANDBOX_MEMORY) += memory-sandbox.o
obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
+obj-$(CONFIG_TI_GPMC) += ti-gpmc.o
diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c
new file mode 100644
index 00..f511a529b1
--- /dev/null
+++ b/drivers/memory/ti-gpmc.c
@@ -0,0 +1,1240 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments GPMC Driver
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ti-gpmc.h"
+
+enum gpmc_clk_domain {
+ GPMC_CD_FCLK,
+ GPMC_CD_CLK
+};
+
+struct gpmc_cs_data {
+ const char *name;
+#define GPMC_CS_RESERVED BIT(0)
+ u32 flags;
+};
+
+struct ti_gpmc {
+ void __iomem *base;
+ u32 cs_num;
+ u32 nr_waitpins;
+ struct clk *l3_clk;
+ u32 capability_flags;
+ struct resource data;
+};
+
+static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
+static unsigned int gpmc_cs_num = GPMC_CS_NUM;
+static unsigned int gpmc_nr_waitpins;
+static unsigned int gpmc_capability;
+static void __iomem *gpmc_base;
+static struct clk *gpmc_l3_clk;
+
+/* Public, as required by nand/raw/omap_gpmc.c */
+const struct gpmc *gpmc_cfg;
+
+/*
+ * The first 1MB of GPMC address space is typically mapped to
+ * the internal ROM. Never allocate the first page, to
+ * facilitate bug detection; even if we didn't boot from ROM.
+ * As GPMC minimum partition size is 16MB we can only start from
+ * there.
+ */
+#define GPMC_MEM_START 0x100
+#define GPMC_MEM_END 0x3FFF
+
+static void gpmc_write_reg(int idx, u32 val)
+{
+ writel_relaxed(val, gpmc_base + idx);
+}
+
+static u32 gpmc_read_reg(int idx)
+{
+ return readl_relaxed(gpmc_base + idx);
+}
+
+static void gpmc_cs_write_reg(int cs, int idx, u32 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ writel_relaxed(val, reg_addr);
+}
+
+static u32 gpmc_cs_read_reg(int cs, int idx)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ return readl_relaxed(reg_addr);
+}
+
+static unsigned long gpmc_get_fclk_period(void)
+{
+ unsigned long rate = clk_get_rate(gpmc_l3_clk);
+
+ rate /= 1000;
+ rate = 10 / rate; /* In picoseconds */
+
+ return rate;
+}
+
+/**
+ * gpmc_get_clk_period - get period of selected clock domain in ps
+ * @cs: Chip Select Region.
+ * @cd: Clock Domain.
+ *
+ * GPMC_CS_CONFIG1 GPMCFCLKDIVIDER for cs has to be setup
+ * prior to calling this function with GPMC_CD_CLK.
+ */
+static unsigned long gpmc_get_clk_period(int cs, enum gpmc_c
[u-boot][PATCH v3 3/4] dt/bindings: memory: Add bindings for TI GPMC driver
GPMC stands for General Purpose Memory Controller and it is present on many Texas Instruments SoCs. It supports a number of Asynchronous and Synchronous interfaces and has various settings to configure the bus interface. The DT bindings define all the various GPMC settings. As the GPMC supports multiple devices on the bus, each device is represented as a child and the respective GPMC settings are situated there. (see ti,gpmc-child.yaml) These binding docs are picked up from the Linux kernel. Signed-off-by: Roger Quadros --- .../memory/ti,gpmc-child.yaml | 252 ++ doc/device-tree-bindings/memory/ti,gpmc.yaml | 190 + 2 files changed, 442 insertions(+) create mode 100644 doc/device-tree-bindings/memory/ti,gpmc-child.yaml create mode 100644 doc/device-tree-bindings/memory/ti,gpmc.yaml diff --git a/doc/device-tree-bindings/memory/ti,gpmc-child.yaml b/doc/device-tree-bindings/memory/ti,gpmc-child.yaml new file mode 100644 index 00..8e541acdb1 --- /dev/null +++ b/doc/device-tree-bindings/memory/ti,gpmc-child.yaml @@ -0,0 +1,252 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ti,gpmc-child.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: device tree bindings for children of the Texas Instruments GPMC + +maintainers: + - Tony Lindgren + - Roger Quadros + +description: + This binding is meant for the child nodes of the GPMC node. The node + represents any device connected to the GPMC bus. It may be a Flash chip, + RAM chip or Ethernet controller, etc. These properties are meant for + configuring the GPMC settings/timings and will accompany the bindings + supported by the respective device. + +properties: + reg: true + +# GPMC Timing properties for child nodes. All are optional and default to 0. + gpmc,sync-clk-ps: +description: Minimum clock period for synchronous mode +default: 0 + +# Chip-select signal timings corresponding to GPMC_CONFIG2: + gpmc,cs-on-ns: +description: Assertion time +default: 0 + + gpmc,cs-rd-off-ns: +description: Read deassertion time +default: 0 + + gpmc,cs-wr-off-ns: +description: Write deassertion time +default: 0 + +# ADV signal timings corresponding to GPMC_CONFIG3: + gpmc,adv-on-ns: +description: Assertion time +default: 0 + + gpmc,adv-rd-off-ns: +description: Read deassertion time +default: 0 + + gpmc,adv-wr-off-ns: +description: Write deassertion time +default: 0 + + gpmc,adv-aad-mux-on-ns: +description: Assertion time for AAD +default: 0 + + gpmc,adv-aad-mux-rd-off-ns: +description: Read deassertion time for AAD +default: 0 + + gpmc,adv-aad-mux-wr-off-ns: +description: Write deassertion time for AAD +default: 0 + +# WE signals timings corresponding to GPMC_CONFIG4: + gpmc,we-on-ns: +description: Assertion time +default: 0 + + gpmc,we-off-ns: +description: Deassertion time +default: 0 + +# OE signals timings corresponding to GPMC_CONFIG4: + gpmc,oe-on-ns: +description: Assertion time +default: 0 + + gpmc,oe-off-ns: +description: Deassertion time +default: 0 + + gpmc,oe-aad-mux-on-ns: +description: Assertion time for AAD +default: 0 + + gpmc,oe-aad-mux-off-ns: +description: Deassertion time for AAD +default: 0 + +# Access time and cycle time timings (in nanoseconds) corresponding to +# GPMC_CONFIG5: + gpmc,page-burst-access-ns: +description: Multiple access word delay +default: 0 + + gpmc,access-ns: +description: Start-cycle to first data valid delay +default: 0 + + gpmc,rd-cycle-ns: +description: Total read cycle time +default: 0 + + gpmc,wr-cycle-ns: +description: Total write cycle time +default: 0 + + gpmc,bus-turnaround-ns: +description: Turn-around time between successive accesses +default: 0 + + gpmc,cycle2cycle-delay-ns: +description: Delay between chip-select pulses +default: 0 + + gpmc,clk-activation-ns: +description: GPMC clock activation time +default: 0 + + gpmc,wait-monitoring-ns: +description: Start of wait monitoring with regard to valid data +default: 0 + +# Boolean timing parameters. If property is present, parameter is enabled +# otherwise disabled. + gpmc,adv-extra-delay: +description: ADV signal is delayed by half GPMC clock +type: boolean + + gpmc,cs-extra-delay: +description: CS signal is delayed by half GPMC clock +type: boolean + + gpmc,cycle2cycle-diffcsen: +description: | + Add "cycle2cycle-delay" between successive accesses + to a different CS +type: boolean + + gpmc,cycle2cycle-samecsen: +description: | + Add "cycle2cycle-delay" between successive accesses + to the same CS +type: boolean + + gpmc,oe-extra-delay: +description: OE signal is delayed by half GPMC clock +type: boolea
[u-boot][PATCH v3 2/4] scripts: Makefile.spl: Enable memory drivers to be built for SPL
Introduce CONFIG_SPL_MEMORY to allow Memory drivers to be built for SPL. Signed-off-by: Roger Quadros --- common/spl/Kconfig | 7 +++ scripts/Makefile.spl | 1 + 2 files changed, 8 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 70d97815f0..186131a699 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -789,6 +789,13 @@ config SPL_DM_MAILBOX this option to build the drivers in drivers/mailbox as part of SPL build. +config SPL_MEMORY + bool "Support Memory controller drivers" + help + Enable support for Memory Controller drivers within SPL. + These devices provide Memory bus interface to various devices like + SRAM, Ethernet adapters, FPGAs, etc. + config SPL_MMC bool "Support MMC" depends on MMC diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 3bafeb4fe9..a1892bff7f 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -114,6 +114,7 @@ libs-$(CONFIG_PARTITIONS) += disk/ endif libs-y += drivers/ +libs-$(CONFIG_SPL_MEMORY) += drivers/memory/ libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/dwc3/ libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/cdns3/ libs-y += dts/ -- 2.17.1
[u-boot][PATCH v3 1/4] dm: memory: Introduce new uclass
Introduce UCLASS_MEMORY for future Memory Controller
device drivers.
Signed-off-by: Roger Quadros
Reviewed-by: Simon Glass
---
arch/sandbox/dts/test.dts | 4
drivers/memory/Kconfig | 17 +
drivers/memory/Makefile | 2 ++
drivers/memory/memory-sandbox.c | 18 ++
drivers/memory/memory-uclass.c | 13 +
include/dm/uclass-id.h | 1 +
test/dm/Makefile| 1 +
test/dm/memory.c| 21 +
8 files changed, 77 insertions(+)
create mode 100644 drivers/memory/memory-sandbox.c
create mode 100644 drivers/memory/memory-uclass.c
create mode 100644 test/dm/memory.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 2761588f0d..d65b2d2dcb 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -926,6 +926,10 @@
};
};
+ memory-controller {
+ compatible = "sandbox,memory";
+ };
+
misc-test {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 7271892763..c621f5bba3 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -4,6 +4,23 @@
menu "Memory Controller drivers"
+config MEMORY
+ bool "Enable Driver Model for Memory Controller drivers"
+ depends on DM
+ help
+ Enable driver model for Memory Controller devices.
+ These devices provide Memory bus interface to various devices like
+ SRAM, Ethernet adapters, FPGAs, etc.
+ For now this uclass has no methods yet.
+
+config SANDBOX_MEMORY
+ bool "Enable Sandbox Memory Controller driver"
+ depends on SANDBOX && MEMORY
+ help
+ This is a driver model based Memory Controller driver for sandbox.
+ Currently it is a stub only, as there are no usable uclass methods
+ yet.
+
config STM32_FMC2_EBI
bool "Support for FMC2 External Bus Interface on STM32MP SoCs"
depends on ARCH_STM32MP
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index fec52efb60..b27f701865 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -1,3 +1,5 @@
+obj-$(CONFIG_MEMORY) += memory-uclass.o
+obj-$(CONFIG_SANDBOX_MEMORY) += memory-sandbox.o
obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
diff --git a/drivers/memory/memory-sandbox.c b/drivers/memory/memory-sandbox.c
new file mode 100644
index 00..f2ede50863
--- /dev/null
+++ b/drivers/memory/memory-sandbox.c
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022
+ * Texas Instruments Incorporated,
+ */
+
+#include
+
+static const struct udevice_id sandbox_memory_match[] = {
+ { .compatible = "sandbox,memory" },
+ { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(sandbox_memory) = {
+ .name = "sandbox_memory",
+ .id = UCLASS_MEMORY,
+ .of_match = sandbox_memory_match,
+};
diff --git a/drivers/memory/memory-uclass.c b/drivers/memory/memory-uclass.c
new file mode 100644
index 00..d6d37fe777
--- /dev/null
+++ b/drivers/memory/memory-uclass.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022
+ * Texas Instruments Incorporated,
+ */
+
+#include
+
+UCLASS_DRIVER(memory) = {
+ .name = "memory",
+ .id = UCLASS_MEMORY,
+ .post_bind = dm_scan_fdt_dev,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index a432e43871..936a16c5d9 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -76,6 +76,7 @@ enum uclass_id {
UCLASS_MASS_STORAGE,/* Mass storage device */
UCLASS_MDIO,/* MDIO bus */
UCLASS_MDIO_MUX,/* MDIO MUX/switch */
+ UCLASS_MEMORY, /* Memory Controller device */
UCLASS_MISC,/* Miscellaneous device */
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 7543df8823..1082e65c41 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -47,6 +47,7 @@ ifneq ($(CONFIG_EFI_PARTITION),)
obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fastboot.o
endif
obj-$(CONFIG_FIRMWARE) += firmware.o
+obj-$(CONFIG_MEMORY) += memory.o
obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock.o
obj-$(CONFIG_DM_I2C) += i2c.o
obj-$(CONFIG_SOUND) += i2s.o
diff --git a/test/dm/memory.c b/test/dm/memory.c
new file mode 100644
index 00..7d9500aa91
--- /dev/null
+++ b/test/dm/memory.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022
+ * Texas Instruments Incorporated,
+ */
+
+#include
+#include
+#include
+#include
+
+static int dm_test_memory(struct unit_test_state *uts)
+{
+ struct udevice *dev
[u-boot][PATCH v3 0/4] Introduce MEMORY uclass and TI GPMC driver
Hi, This series introduces the MEMORY controller uclass for the drivers that exist in drivers/memory directory. With that, we add the TI GPMC Memory controller driver as the first user of this uclass. The GPMC is a unified memory controller dedicated for interfacing with external memory devices like - Asynchronous SRAM-like memories and ASICs - Asynchronous, synchronous, and page mode burst NOR flash - NAND flash - Pseudo-SRAM devices The driver is pulled straight from the Linux kernel and adapted for u-boot. This driver will take care of setting up the GPMC based on the settings specified in the Device tree and then probe its children. cheers, -roger Changelog: v3: - Use CONFIG_MEMORY instead of CONFIG_DM_MEMORY - Introduce CONFIG_SPL_MEMORY and use it to gate inclusion of of drivers/memory for SPL build - Make TI_GPMC depend on OF_CONTROL and CLK as well v2: - Introduce MEMORY uclass Roger Quadros (4): dm: memory: Introduce new uclass scripts: Makefile.spl: Enable memory drivers to be built for SPL dt/bindings: memory: Add bindings for TI GPMC driver memory: Add TI GPMC driver arch/sandbox/dts/test.dts |4 + common/spl/Kconfig|7 + .../memory/ti,gpmc-child.yaml | 252 doc/device-tree-bindings/memory/ti,gpmc.yaml | 190 +++ drivers/memory/Kconfig| 36 + drivers/memory/Makefile |3 + drivers/memory/memory-sandbox.c | 18 + drivers/memory/memory-uclass.c| 13 + drivers/memory/ti-gpmc.c | 1240 + drivers/memory/ti-gpmc.h | 298 include/dm/uclass-id.h|1 + include/linux/mtd/omap_gpmc.h |3 + scripts/Makefile.spl |1 + test/dm/Makefile |1 + test/dm/memory.c | 21 + 15 files changed, 2088 insertions(+) create mode 100644 doc/device-tree-bindings/memory/ti,gpmc-child.yaml create mode 100644 doc/device-tree-bindings/memory/ti,gpmc.yaml create mode 100644 drivers/memory/memory-sandbox.c create mode 100644 drivers/memory/memory-uclass.c create mode 100644 drivers/memory/ti-gpmc.c create mode 100644 drivers/memory/ti-gpmc.h create mode 100644 test/dm/memory.c -- 2.17.1
Re: [u-boot][PATCH v2 2/4] scripts: Makefile.spl: Enable memory drivers to be built for SPL
Hi Tom, On 19/10/2022 15:54, Tom Rini wrote: > On Wed, Oct 19, 2022 at 11:17:35AM +0300, Roger Quadros wrote: >> >> >> On 18/10/2022 20:40, Tom Rini wrote: >>> On Thu, Oct 06, 2022 at 04:23:58PM +0300, Roger Quadros wrote: >>>> We will need ti-gpmc driver for SPL. Allow memory drivers >>>> do be built for SPL. >>>> >>>> Signed-off-by: Roger Quadros >>>> --- >>>> scripts/Makefile.spl | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl >>>> index 3bafeb4fe9..110076b22f 100644 >>>> --- a/scripts/Makefile.spl >>>> +++ b/scripts/Makefile.spl >>>> @@ -114,6 +114,7 @@ libs-$(CONFIG_PARTITIONS) += disk/ >>>> endif >>>> >>>> libs-y += drivers/ >>>> +libs-y += drivers/memory/ >>>> libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/dwc3/ >>>> libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/cdns3/ >>>> libs-y += dts/ >>> >>> This ends up being the wrong approach as it then pulls in >>> drivers/memory/stm32-fmc2-ebi.o on all of those platforms, in SPL, which >>> is not what's intended. We need an SPL_MEMORY symbol and then gate the >>> directory on that. >>> I have a question about how CONFIG_SPL_MEMORY works together with CONFIG_MEMORY. Do we use CONFIG_SPL_MEMORY only to gate the drivers/memory directory inclusion? Then continue to use CONFIG_MEMORY and others to enable/disable driver build for both non-SPL and SPL case? So drivers/memory/Makefile remains as it is? >> >> That's right. I'll fix it up. Will wait for your comments on the rest >> of the series before re-spin. > > Everything else is fine, I was about to merge it (with a > %s/DM_MEMORY/MEMORY) when I saw the stm32 platforms increasing in size > and dug in. > cheers, -roger
Re: [u-boot][PATCH v2 2/4] scripts: Makefile.spl: Enable memory drivers to be built for SPL
On 18/10/2022 20:40, Tom Rini wrote: > On Thu, Oct 06, 2022 at 04:23:58PM +0300, Roger Quadros wrote: >> We will need ti-gpmc driver for SPL. Allow memory drivers >> do be built for SPL. >> >> Signed-off-by: Roger Quadros >> --- >> scripts/Makefile.spl | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl >> index 3bafeb4fe9..110076b22f 100644 >> --- a/scripts/Makefile.spl >> +++ b/scripts/Makefile.spl >> @@ -114,6 +114,7 @@ libs-$(CONFIG_PARTITIONS) += disk/ >> endif >> >> libs-y += drivers/ >> +libs-y += drivers/memory/ >> libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/dwc3/ >> libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/cdns3/ >> libs-y += dts/ > > This ends up being the wrong approach as it then pulls in > drivers/memory/stm32-fmc2-ebi.o on all of those platforms, in SPL, which > is not what's intended. We need an SPL_MEMORY symbol and then gate the > directory on that. > That's right. I'll fix it up. Will wait for your comments on the rest of the series before re-spin. cheers, -roger
Re: [u-boot][PATCH 04/14] mtd: rawnand: omap_gpmc: Optimize NAND reads
Hi Michael,
On 17/10/2022 09:39, Michael Nazzareno Trimarchi wrote:
> Hi Roger
>
> On Sat, Oct 15, 2022 at 3:29 PM Roger Quadros wrote:
>>
>> Hi Michael,
>>
>> On 15/10/2022 10:24, Michael Nazzareno Trimarchi wrote:
>>> Hi
>>>
>>> On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros wrote:
>>>>
>>>> Rename omap_nand_read() to omap_nand_read_buf() to reflect
>>>> actual behaviour.
>>>>
>>>> Use FIFO read address instead of raw read address for reads.
>>>>
>>>> The GPMC automatically converts 32-bit/16-bit reads to NAND
>>>> device specific reads (8/16 bit). Use the largest possible
>>>> read granularity size for more efficient reads.
>>>>
>>>> Signed-off-by: Roger Quadros
>>>> ---
>>>> drivers/mtd/nand/raw/omap_gpmc.c | 49 ++--
>>>> 1 file changed, 28 insertions(+), 21 deletions(-)
>>>>
>>>> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
>>>> b/drivers/mtd/nand/raw/omap_gpmc.c
>>>> index d62c3e6fce..b36fe762b3 100644
>>>> --- a/drivers/mtd/nand/raw/omap_gpmc.c
>>>> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
>>>> @@ -55,6 +55,7 @@ struct omap_nand_info {
>>>> enum omap_ecc ecc_scheme;
>>>> uint8_t cs;
>>>> uint8_t ws; /* wait status pin (0,1) */
>>>> + void __iomem *fifo;
>>>> };
>>>>
>>>> /* We are wasting a bit of memory but al least we are safe */
>>>> @@ -350,6 +351,20 @@ static int omap_calculate_ecc(struct mtd_info *mtd,
>>>> const uint8_t *dat,
>>>> return 0;
>>>> }
>>>>
>>>> +static inline void omap_nand_read_buf(struct mtd_info *mtd, uint8_t *buf,
>>>> int len)
>>>> +{
>>>> + struct nand_chip *chip = mtd_to_nand(mtd);
>>>> + struct omap_nand_info *info = nand_get_controller_data(chip);
>>>> + u32 alignment = ((uintptr_t)buf | len) & 3;
>>>> +
>>>> + if (alignment & 1)
>>>> + readsb(info->fifo, buf, len);
>>>> + else if (alignment & 3)
>>>> + readsw(info->fifo, buf, len >> 1);
>>>> + else
>>>> + readsl(info->fifo, buf, len >> 2);
>>>> +}
>>>> +
>
> Can you optimize more I think here.You can consider the disaligment
> portion and then read at max len. You read more
> than the actual lens but I think it should not be a big problem. In
This will overrun the passed buffer and we don't want to take that risk?
> case of SPL you can use byte read and then can reduce
> the code size here
Apart from some legacy chips SPL size is not a huge problem. So
unless we are sure that we can actually run this driver in SPL
there is no point in doing any SPL optimizations now.
>
> Michael
cheers,
-roger
Re: [u-boot][PATCH 04/14] mtd: rawnand: omap_gpmc: Optimize NAND reads
Hi Michael,
On 15/10/2022 10:24, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros wrote:
>>
>> Rename omap_nand_read() to omap_nand_read_buf() to reflect
>> actual behaviour.
>>
>> Use FIFO read address instead of raw read address for reads.
>>
>> The GPMC automatically converts 32-bit/16-bit reads to NAND
>> device specific reads (8/16 bit). Use the largest possible
>> read granularity size for more efficient reads.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/mtd/nand/raw/omap_gpmc.c | 49 ++--
>> 1 file changed, 28 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
>> b/drivers/mtd/nand/raw/omap_gpmc.c
>> index d62c3e6fce..b36fe762b3 100644
>> --- a/drivers/mtd/nand/raw/omap_gpmc.c
>> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
>> @@ -55,6 +55,7 @@ struct omap_nand_info {
>> enum omap_ecc ecc_scheme;
>> uint8_t cs;
>> uint8_t ws; /* wait status pin (0,1) */
>> + void __iomem *fifo;
>> };
>>
>> /* We are wasting a bit of memory but al least we are safe */
>> @@ -350,6 +351,20 @@ static int omap_calculate_ecc(struct mtd_info *mtd,
>> const uint8_t *dat,
>> return 0;
>> }
>>
>> +static inline void omap_nand_read_buf(struct mtd_info *mtd, uint8_t *buf,
>> int len)
>> +{
>> + struct nand_chip *chip = mtd_to_nand(mtd);
>> + struct omap_nand_info *info = nand_get_controller_data(chip);
>> + u32 alignment = ((uintptr_t)buf | len) & 3;
>> +
>> + if (alignment & 1)
>> + readsb(info->fifo, buf, len);
>> + else if (alignment & 3)
>> + readsw(info->fifo, buf, len >> 1);
>> + else
>> + readsl(info->fifo, buf, len >> 2);
>> +}
>> +
>> #ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
>>
>> #define PREFETCH_CONFIG1_CS_SHIFT 24
>> @@ -415,7 +430,7 @@ static int __read_prefetch_aligned(struct nand_chip
>> *chip, uint32_t *buf, int le
>> cnt = PREFETCH_STATUS_FIFO_CNT(cnt);
>>
>> for (i = 0; i < cnt / 4; i++) {
>> - *buf++ = readl(CONFIG_SYS_NAND_BASE);
>> + *buf++ = readl(info->fifo);
>> len -= 4;
>> }
>> } while (len);
>> @@ -425,16 +440,6 @@ static int __read_prefetch_aligned(struct nand_chip
>> *chip, uint32_t *buf, int le
>> return 0;
>> }
>>
>> -static inline void omap_nand_read(struct mtd_info *mtd, uint8_t *buf, int
>> len)
>> -{
>> - struct nand_chip *chip = mtd_to_nand(mtd);
>> -
>> - if (chip->options & NAND_BUSWIDTH_16)
>> - nand_read_buf16(mtd, buf, len);
>> - else
>> - nand_read_buf(mtd, buf, len);
>> -}
>> -
>> static void omap_nand_read_prefetch(struct mtd_info *mtd, uint8_t *buf, int
>> len)
>> {
>> int ret;
>> @@ -447,7 +452,7 @@ static void omap_nand_read_prefetch(struct mtd_info
>> *mtd, uint8_t *buf, int len)
>> */
>> head = ((uintptr_t)buf) % 4;
>> if (head) {
>> - omap_nand_read(mtd, buf, head);
>> + omap_nand_read_buf(mtd, buf, head);
>> buf += head;
>> len -= head;
>> }
>> @@ -461,10 +466,10 @@ static void omap_nand_read_prefetch(struct mtd_info
>> *mtd, uint8_t *buf, int len)
>> ret = __read_prefetch_aligned(chip, (uint32_t *)buf, len - tail);
>> if (ret < 0) {
>> /* fallback in case the prefetch engine is busy */
>> - omap_nand_read(mtd, buf, len);
>> + omap_nand_read_buf(mtd, buf, len);
>> } else if (tail) {
>> buf += len - tail;
>> - omap_nand_read(mtd, buf, tail);
>> + omap_nand_read_buf(mtd, buf, tail);
>> }
>> }
>> #endif /* CONFIG_NAND_OMAP_GPMC_PREFETCH */
>> @@ -1001,6 +1006,8 @@ int board_nand_init(struct nand_chip *nand)
>> int32_t gpmc_config = 0;
>> int cs = cs_next++;
>> int err = 0;
>> + struct omap_nand_info *info;
>> +
>> /*
>> * xloader/Uboot's gpmc configuration would have configured GPMC for
>> * nand type of memory. The following logic scans and latches
Re: [u-boot][PATCH 10/14] mtd: rawnand: omap_gpmc: support u-boot driver model
On 13/10/2022 14:17, Adam Ford wrote:
> On Wed, Oct 12, 2022 at 6:42 AM Adam Ford wrote:
>>
>> On Wed, Oct 12, 2022 at 1:22 AM Roger Quadros wrote:
>>>
>>> Hi Adam,
>>>
>>> On 11/10/2022 18:01, Adam Ford wrote:
>>>> On Tue, Oct 11, 2022 at 6:52 AM Roger Quadros wrote:
>>>>>
>>>>> Adds driver model support.
>>>>>
>>>>> We need to be able to self initialize the NAND controller/chip
>>>>> at probe and so enable CONFIG_SYS_NAND_SELF_INIT.
>>>>>
>>>>> Doing so requires nand_register() API which is provided by nand.c
>>>>> and needs to be enabled during SPL build via CONFIG_SPL_NAND_INIT.
>>>>> But nand.c also provides nand_init() so we need to get rid of nand_init()
>>>>> in omap_gpmc driver if CONFIG_SPL_NAND_INIT is set.
>>>>>
>>>>> Signed-off-by: Roger Quadros
>>>>> ---
>>>>> drivers/mtd/nand/raw/Kconfig | 1 +
>>>>> drivers/mtd/nand/raw/omap_gpmc.c | 55 +++-
>>>>> 2 files changed, 55 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
>>>>> index bc5cabdfc2..1d23144ce4 100644
>>>>> --- a/drivers/mtd/nand/raw/Kconfig
>>>>> +++ b/drivers/mtd/nand/raw/Kconfig
>>>>> @@ -190,6 +190,7 @@ config NAND_LPC32XX_SLC
>>>>> config NAND_OMAP_GPMC
>>>>> bool "Support OMAP GPMC NAND controller"
>>>>> depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
>>>>> + select SYS_NAND_SELF_INIT if ARCH_K3
>>>>
>>>> I have a question about this down below.
>>>>
>>>>> help
>>>>> Enables omap_gpmc.c driver for OMAPx and AM platforms.
>>>>> GPMC controller is used for parallel NAND flash devices, and can
>>>>> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
>>>>> b/drivers/mtd/nand/raw/omap_gpmc.c
>>>>> index e772a914c8..7192ca9e5a 100644
>>>>> --- a/drivers/mtd/nand/raw/omap_gpmc.c
>>>>> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
>>>>> @@ -7,6 +7,7 @@
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> +#include
>>>>> #include
>>>>>
>>>>> #ifdef CONFIG_ARCH_OMAP2PLUS
>>>>> @@ -1121,7 +1122,7 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
>>>>> hardware, uint32_t eccstrength)
>>>>> * nand_scan about special functionality. See the defines for further
>>>>> * explanation
>>>>> */
>>>>> -int board_nand_init(struct nand_chip *nand)
>>>>> +int gpmc_nand_init(struct nand_chip *nand)
>>>>> {
>>>>> int32_t gpmc_config = 0;
>>>>> int cs = cs_next++;
>>>>> @@ -1201,3 +1202,55 @@ int board_nand_init(struct nand_chip *nand)
>>>>>
>>>>> return 0;
>>>>> }
>>>>> +
>>>>> +static struct nand_chip *nand_chip;/* First NAND chip for SPL use
>>>>> only */
>>>>> +
>>>>> +#if CONFIG_IS_ENABLED(SYS_NAND_SELF_INIT)
>>>>> +
>>>>> +static int gpmc_nand_probe(struct udevice *dev)
>>>>> +{
>>>>> + struct nand_chip *nand = dev_get_priv(dev);
>>>>> + struct mtd_info *mtd = nand_to_mtd(nand);
>>>>> + int ret;
>>>>> +
>>>>> + gpmc_nand_init(nand);
>>>>> +
>>>>> + ret = nand_scan(mtd, CONFIG_SYS_NAND_MAX_CHIPS);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + ret = nand_register(0, mtd);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + if (!nand_chip)
>>>>> + nand_chip = nand;
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static const struct udevice_id gpmc_nand_ids[] = {
>>>>> + { .compatible = "ti,am64-nand" },
>>>>> + { .compatible = "ti,omap2-nand" },
>>>>
>>>> The gpmc_nand_ids reference to omap2, but it
Re: [u-boot][PATCH 10/14] mtd: rawnand: omap_gpmc: support u-boot driver model
Hi Adam,
On 11/10/2022 18:01, Adam Ford wrote:
> On Tue, Oct 11, 2022 at 6:52 AM Roger Quadros wrote:
>>
>> Adds driver model support.
>>
>> We need to be able to self initialize the NAND controller/chip
>> at probe and so enable CONFIG_SYS_NAND_SELF_INIT.
>>
>> Doing so requires nand_register() API which is provided by nand.c
>> and needs to be enabled during SPL build via CONFIG_SPL_NAND_INIT.
>> But nand.c also provides nand_init() so we need to get rid of nand_init()
>> in omap_gpmc driver if CONFIG_SPL_NAND_INIT is set.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/mtd/nand/raw/Kconfig | 1 +
>> drivers/mtd/nand/raw/omap_gpmc.c | 55 +++-
>> 2 files changed, 55 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
>> index bc5cabdfc2..1d23144ce4 100644
>> --- a/drivers/mtd/nand/raw/Kconfig
>> +++ b/drivers/mtd/nand/raw/Kconfig
>> @@ -190,6 +190,7 @@ config NAND_LPC32XX_SLC
>> config NAND_OMAP_GPMC
>> bool "Support OMAP GPMC NAND controller"
>> depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
>> + select SYS_NAND_SELF_INIT if ARCH_K3
>
> I have a question about this down below.
>
>> help
>> Enables omap_gpmc.c driver for OMAPx and AM platforms.
>> GPMC controller is used for parallel NAND flash devices, and can
>> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
>> b/drivers/mtd/nand/raw/omap_gpmc.c
>> index e772a914c8..7192ca9e5a 100644
>> --- a/drivers/mtd/nand/raw/omap_gpmc.c
>> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
>> @@ -7,6 +7,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #ifdef CONFIG_ARCH_OMAP2PLUS
>> @@ -1121,7 +1122,7 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
>> hardware, uint32_t eccstrength)
>> * nand_scan about special functionality. See the defines for further
>> * explanation
>> */
>> -int board_nand_init(struct nand_chip *nand)
>> +int gpmc_nand_init(struct nand_chip *nand)
>> {
>> int32_t gpmc_config = 0;
>> int cs = cs_next++;
>> @@ -1201,3 +1202,55 @@ int board_nand_init(struct nand_chip *nand)
>>
>> return 0;
>> }
>> +
>> +static struct nand_chip *nand_chip;/* First NAND chip for SPL use only
>> */
>> +
>> +#if CONFIG_IS_ENABLED(SYS_NAND_SELF_INIT)
>> +
>> +static int gpmc_nand_probe(struct udevice *dev)
>> +{
>> + struct nand_chip *nand = dev_get_priv(dev);
>> + struct mtd_info *mtd = nand_to_mtd(nand);
>> + int ret;
>> +
>> + gpmc_nand_init(nand);
>> +
>> + ret = nand_scan(mtd, CONFIG_SYS_NAND_MAX_CHIPS);
>> + if (ret)
>> + return ret;
>> +
>> + ret = nand_register(0, mtd);
>> + if (ret)
>> + return ret;
>> +
>> + if (!nand_chip)
>> + nand_chip = nand;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct udevice_id gpmc_nand_ids[] = {
>> + { .compatible = "ti,am64-nand" },
>> + { .compatible = "ti,omap2-nand" },
>
> The gpmc_nand_ids reference to omap2, but it's encapsulated inside the
> SYS_NAND_SELF_INIT ifdef which appears to only be set if K3. Should
> this code be expected to work on OMAP2? I don't think K3 is set for
> OMAP2+. If so, should the SYS_NAND_SELF_INIT be selected if OMAP2 is
> selected?
We want to eventually get this working using driver model and SYS_NAND_SELF_INIT
for OMAP2 as well but just that I didn't work on it yet or test it.
One challenge is that OMAP2 boards tend to either select nand_spl_simple.c
or am335x_spl_bch.c for NAND support at SPL.
We will need to figure out if it is possible to use CONFIG_SPL_NAND_INIT
and this driver instead.
One issue might be that everything doesn't fit in resources available at SPL?
>
> I have a DM3730 that I can test with this. Do you have a repo I can
That would be great. Thanks!
> point to to test? If not, I'll pull the series from patchwork, but I
> need to know what branch to use as a starting point.
You can use this Repo as reference.
https://github.com/rogerq/u-boot/commits/for-v2023.01/am64-nand-base-1.0-test
It has a few patches on top consisting of device tree and u-boot configuration
for AM64 platform. You can ignore the last 2 patches as they are only for a
workaround on early AM64 boards.
If you hit any hurdles, we can discuss how to res
[u-boot][PATCH 14/14] mtd: rawnand: omap_elm: u-boot driver model support
Support u-boot driver model. We still retain
support legacy way of doing things if ELM_BASE
is defined in
We could completely get rid of that if all
platforms defining ELM_BASE get rid of that definition
and enable CONFIG_SYS_NAND_SELF_INIT and are verified
to work.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_elm.c | 33 ++-
.../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6
drivers/mtd/nand/raw/omap_gpmc.c | 12 ++-
3 files changed, 49 insertions(+), 2 deletions(-)
rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
diff --git a/drivers/mtd/nand/raw/omap_elm.c b/drivers/mtd/nand/raw/omap_elm.c
index 35c6dd1f1b..7f4721f617 100644
--- a/drivers/mtd/nand/raw/omap_elm.c
+++ b/drivers/mtd/nand/raw/omap_elm.c
@@ -15,9 +15,14 @@
#include
#include
#include
-#include
#include
+#include
+#include
+#include
+
+#include "omap_elm.h"
+
#define DRIVER_NAME"omap-elm"
#define ELM_DEFAULT_POLY (0)
@@ -180,6 +185,7 @@ void elm_reset(void)
;
}
+#ifdef ELM_BASE
/**
* elm_init - Initialize ELM module
*
@@ -191,3 +197,28 @@ void elm_init(void)
elm_cfg = (struct elm *)ELM_BASE;
elm_reset();
}
+#endif
+
+static int elm_probe(struct udevice *dev)
+{
+ struct resource res;
+
+ dev_read_resource(dev, 0, );
+ elm_cfg = devm_ioremap(dev, res.start, resource_size());
+ elm_reset();
+
+ return 0;
+}
+
+static const struct udevice_id elm_ids[] = {
+ { .compatible = "ti,am3352-elm" },
+ { .compatible = "ti,am64-elm" },
+ { }
+};
+
+U_BOOT_DRIVER(gpmc_elm) = {
+ .name = DRIVER_NAME,
+ .id = UCLASS_MTD,
+ .of_match = elm_ids,
+ .probe = elm_probe,
+};
diff --git a/include/linux/mtd/omap_elm.h b/drivers/mtd/nand/raw/omap_elm.h
similarity index 97%
rename from include/linux/mtd/omap_elm.h
rename to drivers/mtd/nand/raw/omap_elm.h
index f3db00d55d..a7f7bacb15 100644
--- a/include/linux/mtd/omap_elm.h
+++ b/drivers/mtd/nand/raw/omap_elm.h
@@ -74,6 +74,12 @@ int elm_check_error(u8 *syndrome, enum bch_level bch_type,
u32 *error_count,
u32 *error_locations);
int elm_config(enum bch_level level);
void elm_reset(void);
+#ifdef ELM_BASE
void elm_init(void);
+#else
+static inline void elm_init(void)
+{
+}
+#endif
#endif /* __ASSEMBLY__ */
#endif /* __ASM_ARCH_ELM_H */
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index 79b14ce297..68f8d48e87 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -20,7 +20,8 @@
#include
#include
#include
-#include
+
+#include "omap_elm.h"
#ifndef GPMC_MAX_CS
#define GPMC_MAX_CS4
@@ -1248,6 +1249,15 @@ void board_nand_init(void)
struct udevice *dev;
int ret;
+#ifdef CONFIG_NAND_OMAP_ELM
+ ret = uclass_get_device_by_driver(UCLASS_MTD,
+ DM_DRIVER_GET(gpmc_elm), );
+ if (ret && ret != -ENODEV) {
+ pr_err("%s: Failed to get ELM device: %d\n", __func__, ret);
+ return;
+ }
+#endif
+
ret = uclass_get_device_by_driver(UCLASS_MTD,
DM_DRIVER_GET(gpmc_nand), );
if (ret && ret != -ENODEV)
--
2.17.1
[u-boot][PATCH 13/14] dt-bindings: mtd: Add ti, elm DT binding documentation
Adds DT binding documentation for the TI Error Location Module.
This is picked up from the Linux Kernel.
Signed-off-by: Roger Quadros
---
doc/device-tree-bindings/mtd/ti,elm.yaml | 72
1 file changed, 72 insertions(+)
create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
diff --git a/doc/device-tree-bindings/mtd/ti,elm.yaml
b/doc/device-tree-bindings/mtd/ti,elm.yaml
new file mode 100644
index 00..87128c0045
--- /dev/null
+++ b/doc/device-tree-bindings/mtd/ti,elm.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/ti,elm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments Error Location Module (ELM).
+
+maintainers:
+ - Roger Quadros
+
+description:
+ ELM module is used together with GPMC and NAND Flash to detect
+ errors and the location of the error based on BCH algorithms
+ so they can be corrected if possible.
+
+properties:
+ compatible:
+enum:
+ - ti,am3352-elm
+ - ti,am64-elm
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+description: Functional clock.
+
+ clock-names:
+items:
+ - const: fck
+
+ power-domains:
+maxItems: 1
+
+ ti,hwmods:
+description:
+ Name of the HWMOD associated with ELM. This is for legacy
+ platforms only.
+$ref: /schemas/types.yaml#/definitions/string
+deprecated: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,am64-elm
+then:
+ required:
+- clocks
+- clock-names
+- power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+elm: ecc@0 {
+compatible = "ti,am3352-elm";
+reg = <0x0 0x2000>;
+interrupts = <4>;
+};
--
2.17.1
[u-boot][PATCH 11/14] mtd: rawnand: omap_gpmc: Add SPL NAND support
Enables SPL NAND support for ARCH_K3 by enabling
SPL_NAND_INIT and SPL_SYS_NAND_SELF_INIT.
Legacy OMAP2plus platforms still rely on SPL_NAND_AM33XX_BCH
instead.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/Kconfig | 5
drivers/mtd/nand/raw/Makefile| 2 +-
drivers/mtd/nand/raw/omap_gpmc.c | 40
3 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 1d23144ce4..b803759166 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -26,6 +26,9 @@ config TPL_SYS_NAND_SELF_INIT
config TPL_NAND_INIT
bool
+config SPL_NAND_INIT
+ bool
+
config SYS_NAND_DRIVER_ECC_LAYOUT
bool "Omit standard ECC layouts to save space"
help
@@ -191,6 +194,8 @@ config NAND_OMAP_GPMC
bool "Support OMAP GPMC NAND controller"
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
select SYS_NAND_SELF_INIT if ARCH_K3
+ select SPL_NAND_INIT if ARCH_K3
+ select SPL_SYS_NAND_SELF_INIT if ARCH_K3
help
Enables omap_gpmc.c driver for OMAPx and AM platforms.
GPMC controller is used for parallel NAND flash devices, and can
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index a398aa9d88..6fe33d2485 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_amd.o
nand_hynix.o \
nand_macronix.o nand_micron.o \
nand_samsung.o nand_toshiba.o
obj-$(CONFIG_SPL_NAND_IDENT) += nand_ids.o nand_timings.o
-obj-$(CONFIG_TPL_NAND_INIT) += nand.o
+obj-$(CONFIG_$(SPL_TPL_)NAND_INIT) += nand.o
ifeq ($(CONFIG_SPL_ENV_SUPPORT),y)
obj-$(CONFIG_ENV_IS_IN_NAND) += nand_util.o
endif
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index 7192ca9e5a..79b14ce297 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -1254,3 +1254,43 @@ void board_nand_init(void)
pr_err("%s: Failed to get GPMC device: %d\n", __func__, ret);
}
#endif /* CONFIG_SYS_NAND_SELF_INIT */
+
+#if defined(CONFIG_SPL_NAND_INIT)
+
+/* nand_init() is provided by nand.c */
+
+/* Unselect after operation */
+void nand_deselect(void)
+{
+ struct mtd_info *mtd = nand_to_mtd(nand_chip);
+
+ if (nand_chip->select_chip)
+ nand_chip->select_chip(mtd, -1);
+}
+
+static int nand_is_bad_block(int block)
+{
+ struct mtd_info *mtd = nand_to_mtd(nand_chip);
+
+ loff_t ofs = block * CONFIG_SYS_NAND_BLOCK_SIZE;
+
+ return nand_chip->block_bad(mtd, ofs);
+}
+
+static int nand_read_page(int block, int page, uchar *dst)
+{
+ int page_addr = block * CONFIG_SYS_NAND_PAGE_COUNT + page;
+ loff_t ofs = page_addr * CONFIG_SYS_NAND_PAGE_SIZE;
+ int ret;
+ size_t len = CONFIG_SYS_NAND_PAGE_SIZE;
+ struct mtd_info *mtd = nand_to_mtd(nand_chip);
+
+ ret = nand_read(mtd, ofs, , dst);
+ if (ret)
+ printf("nand_read failed %d\n", ret);
+
+ return ret;
+}
+
+#include "nand_spl_loaders.c"
+#endif /* CONFIG_SPL_NAND_INIT */
--
2.17.1
[u-boot][PATCH 12/14] mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
The symbol is required for NAND support in SPL when using OMAP_GPMC driver. Signed-off-by: Roger Quadros --- drivers/mtd/nand/raw/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index b803759166..95fe27c283 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -566,7 +566,8 @@ config SYS_NAND_ONFI_DETECTION config SYS_NAND_PAGE_COUNT hex "NAND chip page count" depends on SPL_NAND_SUPPORT && (NAND_ATMEL || NAND_MXC || \ - SPL_NAND_AM33XX_BCH || SPL_NAND_LOAD || SPL_NAND_SIMPLE) + SPL_NAND_AM33XX_BCH || SPL_NAND_LOAD || SPL_NAND_SIMPLE || \ + NAND_OMAP_GPMC) help Number of pages in the NAND chip. -- 2.17.1
[u-boot][PATCH 09/14] dt-bindings: mtd: Add ti, gpmc-nand DT binding documentation
Add DT binding documentation for the TI GPMC NAND controller.
This is picked up from the Linux Kernel.
Signed-off-by: Roger Quadros
---
.../mtd/ti,gpmc-nand.yaml | 129 ++
1 file changed, 129 insertions(+)
create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
diff --git a/doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
b/doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
new file mode 100644
index 00..4ac198814b
--- /dev/null
+++ b/doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/ti,gpmc-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments GPMC NAND Flash controller.
+
+maintainers:
+ - Tony Lindgren
+ - Roger Quadros
+
+description:
+ GPMC NAND controller/Flash is represented as a child of the
+ GPMC controller node.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - ti,am64-nand
+ - ti,omap2-nand
+
+ reg:
+maxItems: 1
+
+ interrupts:
+items:
+ - description: Interrupt for fifoevent
+ - description: Interrupt for termcount
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+ ti,nand-ecc-opt:
+description: Desired ECC algorithm
+$ref: /schemas/types.yaml#/definitions/string
+enum: [sw, ham1, bch4, bch8, bch16]
+
+ ti,nand-xfer-type:
+description: Data transfer method between controller and chip.
+$ref: /schemas/types.yaml#/definitions/string
+enum: [prefetch-polled, polled, prefetch-dma, prefetch-irq]
+default: prefetch-polled
+
+ ti,elm-id:
+description:
+ phandle to the ELM (Error Location Module).
+$ref: /schemas/types.yaml#/definitions/phandle
+
+ nand-bus-width:
+description:
+ Bus width to the NAND chip
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [8, 16]
+default: 8
+
+ rb-gpios:
+description:
+ GPIO connection to R/B signal from NAND chip
+maxItems: 1
+
+patternProperties:
+ "@[0-9a-f]+$":
+$ref: "/schemas/mtd/partitions/partition.yaml"
+
+allOf:
+ - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml"
+
+required:
+ - compatible
+ - reg
+ - ti,nand-ecc-opt
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+
+gpmc: memory-controller@5000 {
+ compatible = "ti,am3352-gpmc";
+ dmas = < 52 0>;
+ dma-names = "rxtx";
+ clocks = <_gclk>;
+ clock-names = "fck";
+ reg = <0x5000 0x2000>;
+ interrupts = ;
+ gpmc,num-cs = <7>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ ranges = <0 0 0x0800 0x0100>; /* CS0 space. Min partition =
16MB */
+ nand@0,0 {
+compatible = "ti,omap2-nand";
+reg = <0 0 4>; /* device IO registers */
+interrupt-parent = <>;
+interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
+ <1 IRQ_TYPE_NONE>; /* termcount */
+ti,nand-xfer-type = "prefetch-dma";
+ti,nand-ecc-opt = "bch16";
+ti,elm-id = <>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+/* NAND generic properties */
+nand-bus-width = <8>;
+rb-gpios = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
+
+/* GPMC properties*/
+gpmc,device-width = <1>;
+
+partition@0 {
+ label = "NAND.SPL";
+ reg = <0x 0x0004>;
+};
+partition@1 {
+ label = "NAND.SPL.backup1";
+ reg = <0x0004 0x0004>;
+};
+ };
+};
--
2.17.1
[u-boot][PATCH 10/14] mtd: rawnand: omap_gpmc: support u-boot driver model
Adds driver model support.
We need to be able to self initialize the NAND controller/chip
at probe and so enable CONFIG_SYS_NAND_SELF_INIT.
Doing so requires nand_register() API which is provided by nand.c
and needs to be enabled during SPL build via CONFIG_SPL_NAND_INIT.
But nand.c also provides nand_init() so we need to get rid of nand_init()
in omap_gpmc driver if CONFIG_SPL_NAND_INIT is set.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/Kconfig | 1 +
drivers/mtd/nand/raw/omap_gpmc.c | 55 +++-
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index bc5cabdfc2..1d23144ce4 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -190,6 +190,7 @@ config NAND_LPC32XX_SLC
config NAND_OMAP_GPMC
bool "Support OMAP GPMC NAND controller"
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ select SYS_NAND_SELF_INIT if ARCH_K3
help
Enables omap_gpmc.c driver for OMAPx and AM platforms.
GPMC controller is used for parallel NAND flash devices, and can
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index e772a914c8..7192ca9e5a 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_ARCH_OMAP2PLUS
@@ -1121,7 +1122,7 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
hardware, uint32_t eccstrength)
* nand_scan about special functionality. See the defines for further
* explanation
*/
-int board_nand_init(struct nand_chip *nand)
+int gpmc_nand_init(struct nand_chip *nand)
{
int32_t gpmc_config = 0;
int cs = cs_next++;
@@ -1201,3 +1202,55 @@ int board_nand_init(struct nand_chip *nand)
return 0;
}
+
+static struct nand_chip *nand_chip;/* First NAND chip for SPL use only */
+
+#if CONFIG_IS_ENABLED(SYS_NAND_SELF_INIT)
+
+static int gpmc_nand_probe(struct udevice *dev)
+{
+ struct nand_chip *nand = dev_get_priv(dev);
+ struct mtd_info *mtd = nand_to_mtd(nand);
+ int ret;
+
+ gpmc_nand_init(nand);
+
+ ret = nand_scan(mtd, CONFIG_SYS_NAND_MAX_CHIPS);
+ if (ret)
+ return ret;
+
+ ret = nand_register(0, mtd);
+ if (ret)
+ return ret;
+
+ if (!nand_chip)
+ nand_chip = nand;
+
+ return 0;
+}
+
+static const struct udevice_id gpmc_nand_ids[] = {
+ { .compatible = "ti,am64-nand" },
+ { .compatible = "ti,omap2-nand" },
+ { }
+};
+
+U_BOOT_DRIVER(gpmc_nand) = {
+ .name = "gpmc-nand",
+ .id = UCLASS_MTD,
+ .of_match = gpmc_nand_ids,
+ .probe = gpmc_nand_probe,
+ .priv_auto = sizeof(struct nand_chip),
+};
+
+void board_nand_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MTD,
+ DM_DRIVER_GET(gpmc_nand), );
+ if (ret && ret != -ENODEV)
+ pr_err("%s: Failed to get GPMC device: %d\n", __func__, ret);
+}
+#endif /* CONFIG_SYS_NAND_SELF_INIT */
--
2.17.1
[u-boot][PATCH 08/14] mtd: rawnand: omap_gpmc: Reduce .bss usage
Allocate omap_ecclayout on the heap as we have
limited .bss space on AM64 R5 SPL configuration.
Reduces .bss usage by 2984 bytes.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_gpmc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index b5ad66ad49..e772a914c8 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -40,7 +40,6 @@ static u8 bch8_polynomial[] = {0xef, 0x51, 0x2e, 0x09, 0xed,
0x93, 0x9a, 0xc2,
0x97, 0x79, 0xe5, 0x24, 0xb5};
#endif
static uint8_t cs_next;
-static __maybe_unused struct nand_ecclayout omap_ecclayout;
#if defined(CONFIG_NAND_OMAP_GPMC_WSCFG)
static const int8_t wscfg[CONFIG_SYS_MAX_NAND_DEVICE] =
@@ -874,7 +873,7 @@ static void __maybe_unused omap_free_bch(struct mtd_info
*mtd)
static int omap_select_ecc_scheme(struct nand_chip *nand,
enum omap_ecc ecc_scheme, unsigned int pagesize, unsigned int oobsize) {
struct omap_nand_info *info =
nand_get_controller_data(nand);
- struct nand_ecclayout *ecclayout = _ecclayout;
+ struct nand_ecclayout *ecclayout = nand->ecc.layout;
int eccsteps = pagesize / SECTOR_BYTES;
int i;
@@ -1167,7 +1166,9 @@ int board_nand_init(struct nand_chip *nand)
nand->cmd_ctrl = omap_nand_hwcontrol;
nand->options |= NAND_NO_PADDING | NAND_CACHEPRG;
nand->chip_delay = 100;
- nand->ecc.layout = _ecclayout;
+ nand->ecc.layout = kzalloc(sizeof(*nand->ecc.layout), GFP_KERNEL);
+ if (!nand->ecc.layout)
+ return -ENOMEM;
/* configure driver and controller based on NAND device bus-width */
gpmc_config = readl(_cfg->cs[cs].config1);
--
2.17.1
[u-boot][PATCH 05/14] mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
The BCH detection hardware can generate ECC bytes for multiple
sectors in one go. Use that feature.
correct() only corrects one sector at a time so we need to call it
repeatedly for each sector.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_gpmc.c | 325 +--
1 file changed, 223 insertions(+), 102 deletions(-)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index b36fe762b3..b5ad66ad49 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -27,6 +27,9 @@
#define BADBLOCK_MARKER_LENGTH 2
#define SECTOR_BYTES 512
+#define ECCSIZE0_SHIFT 12
+#define ECCSIZE1_SHIFT 22
+#define ECC1RESULTSIZE 0x1
#define ECCCLEAR (0x1 << 8)
#define ECCRESULTREG1 (0x1 << 0)
/* 4 bit padding to make byte aligned, 56 = 52 + 4 */
@@ -187,72 +190,35 @@ static int __maybe_unused omap_correct_data(struct
mtd_info *mtd, uint8_t *dat,
__maybe_unused
static void omap_enable_hwecc(struct mtd_info *mtd, int32_t mode)
{
- struct nand_chip*nand = mtd_to_nand(mtd);
- struct omap_nand_info *info = nand_get_controller_data(nand);
+ struct nand_chip *nand = mtd_to_nand(mtd);
+ struct omap_nand_info *info = nand_get_controller_data(nand);
unsigned int dev_width = (nand->options & NAND_BUSWIDTH_16) ? 1 : 0;
- unsigned int ecc_algo = 0;
- unsigned int bch_type = 0;
- unsigned int eccsize1 = 0x00, eccsize0 = 0x00, bch_wrapmode = 0x00;
- u32 ecc_size_config_val = 0;
- u32 ecc_config_val = 0;
- int cs = info->cs;
+ u32 val;
- /* configure GPMC for specific ecc-scheme */
- switch (info->ecc_scheme) {
- case OMAP_ECC_HAM1_CODE_SW:
- return;
- case OMAP_ECC_HAM1_CODE_HW:
- ecc_algo = 0x0;
- bch_type = 0x0;
- bch_wrapmode = 0x00;
- eccsize0 = 0xFF;
- eccsize1 = 0xFF;
+ /* Clear ecc and enable bits */
+ writel(ECCCLEAR | ECCRESULTREG1, _cfg->ecc_control);
+
+ /* program ecc and result sizes */
+ val = nand->ecc.size >> 1) - 1) << ECCSIZE1_SHIFT) |
+ ECC1RESULTSIZE);
+ writel(val, _cfg->ecc_size_config);
+
+ switch (mode) {
+ case NAND_ECC_READ:
+ case NAND_ECC_WRITE:
+ writel(ECCCLEAR | ECCRESULTREG1, _cfg->ecc_control);
break;
- case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
- case OMAP_ECC_BCH8_CODE_HW:
- ecc_algo = 0x1;
- bch_type = 0x1;
- if (mode == NAND_ECC_WRITE) {
- bch_wrapmode = 0x01;
- eccsize0 = 0; /* extra bits in nibbles per sector */
- eccsize1 = 28; /* OOB bits in nibbles per sector */
- } else {
- bch_wrapmode = 0x01;
- eccsize0 = 26; /* ECC bits in nibbles per sector */
- eccsize1 = 2; /* non-ECC bits in nibbles per sector */
- }
- break;
- case OMAP_ECC_BCH16_CODE_HW:
- ecc_algo = 0x1;
- bch_type = 0x2;
- if (mode == NAND_ECC_WRITE) {
- bch_wrapmode = 0x01;
- eccsize0 = 0; /* extra bits in nibbles per sector */
- eccsize1 = 52; /* OOB bits in nibbles per sector */
- } else {
- bch_wrapmode = 0x01;
- eccsize0 = 52; /* ECC bits in nibbles per sector */
- eccsize1 = 0; /* non-ECC bits in nibbles per sector */
- }
+ case NAND_ECC_READSYN:
+ writel(ECCCLEAR, _cfg->ecc_control);
break;
default:
- return;
+ printf("%s: error: unrecognized Mode[%d]!\n", __func__, mode);
+ break;
}
- /* Clear ecc and enable bits */
- writel(ECCCLEAR | ECCRESULTREG1, _cfg->ecc_control);
- /* Configure ecc size for BCH */
- ecc_size_config_val = (eccsize1 << 22) | (eccsize0 << 12);
- writel(ecc_size_config_val, _cfg->ecc_size_config);
-
- /* Configure device details for BCH engine */
- ecc_config_val = ((ecc_algo << 16) | /* HAM1 | BCHx */
- (bch_type << 12)| /* BCH4/BCH8/BCH16 */
- (bch_wrapmode << 8) | /* wrap mode */
- (dev_width << 7)| /* bus width */
- (0x0 << 4) | /* number of sectors */
- (cs << 1) | /* ECC CS */
- (0x1)); /* enable ECC */
- writel(ecc_config_val, _cfg->ecc_config);
+
+ /* (ECC 1
[u-boot][PATCH 07/14] mtd: rawnand: nand_spl_loaders: Fix cast type build warning
Fixes the below build warning on 64-bit platforms.
drivers/mtd/nand/raw/nand_spl_loaders.c:26:21: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
dst = (void *)((int)dst - page_offset);
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/nand_spl_loaders.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/nand_spl_loaders.c
b/drivers/mtd/nand/raw/nand_spl_loaders.c
index 4befc75c04..156b44d835 100644
--- a/drivers/mtd/nand/raw/nand_spl_loaders.c
+++ b/drivers/mtd/nand/raw/nand_spl_loaders.c
@@ -23,7 +23,7 @@ int nand_spl_load_image(uint32_t offs, unsigned int size,
void *dst)
if (unlikely(page_offset)) {
memmove(dst, dst + page_offset,
CONFIG_SYS_NAND_PAGE_SIZE);
- dst = (void *)((int)dst - page_offset);
+ dst = (void *)(dst - page_offset);
page_offset = 0;
}
dst += CONFIG_SYS_NAND_PAGE_SIZE;
--
2.17.1
[u-boot][PATCH 06/14] mtd: rawnand: nand_base: Allow base driver to be used in SPL without nand_bbt
nand_bbt.c is not being built with the nand_base driver during SPL
build. This results in build failures if we try to access any nand_bbt
related functions.
Don't use any nand_bbt functions for SPL build.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/nand_base.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 4b09a11288..826ae633ce 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -447,7 +447,10 @@ static int nand_default_block_markbad(struct mtd_info
*mtd, loff_t ofs)
static int nand_block_markbad_lowlevel(struct mtd_info *mtd, loff_t ofs)
{
struct nand_chip *chip = mtd_to_nand(mtd);
- int res, ret = 0;
+ int ret = 0;
+#ifndef CONFIG_SPL_BUILD
+ int res;
+#endif
if (!(chip->bbt_options & NAND_BBT_NO_OOB_BBM)) {
struct erase_info einfo;
@@ -465,12 +468,14 @@ static int nand_block_markbad_lowlevel(struct mtd_info
*mtd, loff_t ofs)
nand_release_device(mtd);
}
+#ifndef CONFIG_SPL_BUILD
/* Mark block bad in BBT */
if (chip->bbt) {
res = nand_markbad_bbt(mtd, ofs);
if (!ret)
ret = res;
}
+#endif
if (!ret)
mtd->ecc_stats.badblocks++;
@@ -517,7 +522,11 @@ static int nand_block_isreserved(struct mtd_info *mtd,
loff_t ofs)
if (!chip->bbt)
return 0;
/* Return info from the table */
+#ifndef CONFIG_SPL_BUILD
return nand_isreserved_bbt(mtd, ofs);
+#else
+ return 0;
+#endif
}
/**
@@ -543,7 +552,11 @@ static int nand_block_checkbad(struct mtd_info *mtd,
loff_t ofs, int allowbbt)
return chip->block_bad(mtd, ofs);
/* Return info from the table */
+#ifndef CONFIG_SPL_BUILD
return nand_isbad_bbt(mtd, ofs, allowbbt);
+#else
+ return 0;
+#endif
}
/**
@@ -3752,8 +3765,11 @@ static void nand_set_defaults(struct nand_chip *chip,
int busw)
chip->write_byte = busw ? nand_write_byte16 : nand_write_byte;
if (!chip->read_buf || chip->read_buf == nand_read_buf)
chip->read_buf = busw ? nand_read_buf16 : nand_read_buf;
+
+#ifndef CONFIG_SPL_BUILD
if (!chip->scan_bbt)
chip->scan_bbt = nand_default_bbt;
+#endif
if (!chip->controller) {
chip->controller = >hwcontrol;
--
2.17.1
[u-boot][PATCH 04/14] mtd: rawnand: omap_gpmc: Optimize NAND reads
Rename omap_nand_read() to omap_nand_read_buf() to reflect
actual behaviour.
Use FIFO read address instead of raw read address for reads.
The GPMC automatically converts 32-bit/16-bit reads to NAND
device specific reads (8/16 bit). Use the largest possible
read granularity size for more efficient reads.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_gpmc.c | 49 ++--
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index d62c3e6fce..b36fe762b3 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -55,6 +55,7 @@ struct omap_nand_info {
enum omap_ecc ecc_scheme;
uint8_t cs;
uint8_t ws; /* wait status pin (0,1) */
+ void __iomem *fifo;
};
/* We are wasting a bit of memory but al least we are safe */
@@ -350,6 +351,20 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const
uint8_t *dat,
return 0;
}
+static inline void omap_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int
len)
+{
+ struct nand_chip *chip = mtd_to_nand(mtd);
+ struct omap_nand_info *info = nand_get_controller_data(chip);
+ u32 alignment = ((uintptr_t)buf | len) & 3;
+
+ if (alignment & 1)
+ readsb(info->fifo, buf, len);
+ else if (alignment & 3)
+ readsw(info->fifo, buf, len >> 1);
+ else
+ readsl(info->fifo, buf, len >> 2);
+}
+
#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
#define PREFETCH_CONFIG1_CS_SHIFT 24
@@ -415,7 +430,7 @@ static int __read_prefetch_aligned(struct nand_chip *chip,
uint32_t *buf, int le
cnt = PREFETCH_STATUS_FIFO_CNT(cnt);
for (i = 0; i < cnt / 4; i++) {
- *buf++ = readl(CONFIG_SYS_NAND_BASE);
+ *buf++ = readl(info->fifo);
len -= 4;
}
} while (len);
@@ -425,16 +440,6 @@ static int __read_prefetch_aligned(struct nand_chip *chip,
uint32_t *buf, int le
return 0;
}
-static inline void omap_nand_read(struct mtd_info *mtd, uint8_t *buf, int len)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
-
- if (chip->options & NAND_BUSWIDTH_16)
- nand_read_buf16(mtd, buf, len);
- else
- nand_read_buf(mtd, buf, len);
-}
-
static void omap_nand_read_prefetch(struct mtd_info *mtd, uint8_t *buf, int
len)
{
int ret;
@@ -447,7 +452,7 @@ static void omap_nand_read_prefetch(struct mtd_info *mtd,
uint8_t *buf, int len)
*/
head = ((uintptr_t)buf) % 4;
if (head) {
- omap_nand_read(mtd, buf, head);
+ omap_nand_read_buf(mtd, buf, head);
buf += head;
len -= head;
}
@@ -461,10 +466,10 @@ static void omap_nand_read_prefetch(struct mtd_info *mtd,
uint8_t *buf, int len)
ret = __read_prefetch_aligned(chip, (uint32_t *)buf, len - tail);
if (ret < 0) {
/* fallback in case the prefetch engine is busy */
- omap_nand_read(mtd, buf, len);
+ omap_nand_read_buf(mtd, buf, len);
} else if (tail) {
buf += len - tail;
- omap_nand_read(mtd, buf, tail);
+ omap_nand_read_buf(mtd, buf, tail);
}
}
#endif /* CONFIG_NAND_OMAP_GPMC_PREFETCH */
@@ -1001,6 +1006,8 @@ int board_nand_init(struct nand_chip *nand)
int32_t gpmc_config = 0;
int cs = cs_next++;
int err = 0;
+ struct omap_nand_info *info;
+
/*
* xloader/Uboot's gpmc configuration would have configured GPMC for
* nand type of memory. The following logic scans and latches on to the
@@ -1029,9 +1036,12 @@ int board_nand_init(struct nand_chip *nand)
nand->IO_ADDR_R = (void __iomem *)_cfg->cs[cs].nand_dat;
nand->IO_ADDR_W = (void __iomem *)_cfg->cs[cs].nand_cmd;
- omap_nand_info[cs].control = NULL;
- omap_nand_info[cs].cs = cs;
- omap_nand_info[cs].ws = wscfg[cs];
+
+ info = _nand_info[cs];
+ info->control = NULL;
+ info->cs = cs;
+ info->ws = wscfg[cs];
+ info->fifo = (void __iomem *)CONFIG_SYS_NAND_BASE;
nand_set_controller_data(nand, _nand_info[cs]);
nand->cmd_ctrl = omap_nand_hwcontrol;
nand->options |= NAND_NO_PADDING | NAND_CACHEPRG;
@@ -1062,10 +1072,7 @@ int board_nand_init(struct nand_chip *nand)
#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
nand->read_buf = omap_nand_read_prefetch;
#else
- if (nand->options & NAND_BUSWIDTH_16)
- nand->read_buf = nand_read_buf16;
- else
- nand->read_buf = nand_read_buf;
+ nand->read_buf = omap_nand_read_buf;
#endif
nand->dev_ready = omap_dev_ready;
--
2.17.1
[u-boot][PATCH 03/14] mtd: rawnand: omap_gpmc: Fix build warning on 64-bit platforms
Pointer size cannot be assumed to be 32-bit, so use
use uintptr_t instead of uint32_t.
Fixes the below build warning on 64-bit builds.
drivers/mtd/nand/raw/omap_gpmc.c:439:10: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
head = ((uint32_t) buf) % 4;
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_gpmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index 7e9ccf7878..d62c3e6fce 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -438,14 +438,14 @@ static inline void omap_nand_read(struct mtd_info *mtd,
uint8_t *buf, int len)
static void omap_nand_read_prefetch(struct mtd_info *mtd, uint8_t *buf, int
len)
{
int ret;
- uint32_t head, tail;
+ uintptr_t head, tail;
struct nand_chip *chip = mtd_to_nand(mtd);
/*
* If the destination buffer is unaligned, start with reading
* the overlap byte-wise.
*/
- head = ((uint32_t) buf) % 4;
+ head = ((uintptr_t)buf) % 4;
if (head) {
omap_nand_read(mtd, buf, head);
buf += head;
--
2.17.1
[u-boot][PATCH 02/14] mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms
The GPMC module is present on some K2 and K3 SoCs. Enable building GPMC NAND driver for K2/K3 platforms. Signed-off-by: Roger Quadros --- drivers/mtd/nand/raw/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index ce67d1abde..bc5cabdfc2 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -189,7 +189,7 @@ config NAND_LPC32XX_SLC config NAND_OMAP_GPMC bool "Support OMAP GPMC NAND controller" - depends on ARCH_OMAP2PLUS + depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3 help Enables omap_gpmc.c driver for OMAPx and AM platforms. GPMC controller is used for parallel NAND flash devices, and can -- 2.17.1
[u-boot][PATCH 01/14] mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h
We want to get rid of so don't enforce it for new platforms. This also means GPMC_MAX CS doesn't have to be defined by platform code. Define it locally here for now. Signed-off-by: Roger Quadros --- drivers/mtd/nand/raw/omap_gpmc.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c index 8b9ff4de18..7e9ccf7878 100644 --- a/drivers/mtd/nand/raw/omap_gpmc.c +++ b/drivers/mtd/nand/raw/omap_gpmc.c @@ -8,7 +8,11 @@ #include #include #include + +#ifdef CONFIG_ARCH_OMAP2PLUS #include +#endif + #include #include #include @@ -17,6 +21,10 @@ #include #include +#ifndef GPMC_MAX_CS +#define GPMC_MAX_CS4 +#endif + #define BADBLOCK_MARKER_LENGTH 2 #define SECTOR_BYTES 512 #define ECCCLEAR (0x1 << 8) -- 2.17.1
[u-boot][PATCH 00/14] rawnand: omap_gpmc: driver model support
Hi,
This series adds driver model support for rawnand: omap_gpmc
and omap_elm drivers.
This will enable the driver to be used on K2/K3 platforms as well.
cheers,
-roger
Roger Quadros (14):
mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h
mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms
mtd: rawnand: omap_gpmc: Fix build warning on 64-bit platforms
mtd: rawnand: omap_gpmc: Optimize NAND reads
mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
mtd: rawnand: nand_base: Allow base driver to be used in SPL without
nand_bbt
mtd: rawnand: nand_spl_loaders: Fix cast type build warning
mtd: rawnand: omap_gpmc: Reduce .bss usage
dt-bindings: mtd: Add ti,gpmc-nand DT binding documentation
mtd: rawnand: omap_gpmc: support u-boot driver model
mtd: rawnand: omap_gpmc: Add SPL NAND support
mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
dt-bindings: mtd: Add ti,elm DT binding documentation
mtd: rawnand: omap_elm: u-boot driver model support
doc/device-tree-bindings/mtd/ti,elm.yaml | 72 +++
.../mtd/ti,gpmc-nand.yaml | 129 +
drivers/mtd/nand/raw/Kconfig | 11 +-
drivers/mtd/nand/raw/Makefile | 2 +-
drivers/mtd/nand/raw/nand_base.c | 18 +-
drivers/mtd/nand/raw/nand_spl_loaders.c | 2 +-
drivers/mtd/nand/raw/omap_elm.c | 33 +-
.../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6 +
drivers/mtd/nand/raw/omap_gpmc.c | 500 +-
9 files changed, 637 insertions(+), 136 deletions(-)
create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
--
2.17.1
Re: [u-boot][PATCH] spl: spl_legacy: Fix NAND boot on OMAP3 BeagleBoard
+Dario
On 29/09/2022 13:11, Roger Quadros wrote:
> OMAP3 BeagleBoard NAND boot hangs when spl_load_legacy_img() tries
> to read the header into 'struct hdr' which is allocated on the
> stack.
>
> As the header has already been read once before by spl_nand.c,
> we can avoid the extra header read here by simply passing around
> the pointer to the header.
>
> This fixes NAND boot on OMAP3 BeagleBoard.
>
> Signed-off-by: Roger Quadros
> ---
> common/spl/spl_legacy.c | 19 ---
> common/spl/spl_nand.c | 2 +-
> common/spl/spl_nor.c| 6 +-
> include/spl.h | 7 +--
> 4 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
> index ae8731c782..2e9226c990 100644
> --- a/common/spl/spl_legacy.c
> +++ b/common/spl/spl_legacy.c
> @@ -77,32 +77,29 @@ static inline int spl_image_get_comp(const struct
> image_header *hdr)
>
> int spl_load_legacy_img(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev,
> - struct spl_load_info *load, ulong header)
> + struct spl_load_info *load, ulong offset,
> + struct image_header *hdr)
> {
> __maybe_unused SizeT lzma_len;
> __maybe_unused void *src;
> - struct image_header hdr;
> ulong dataptr;
> int ret;
>
> - /* Read header into local struct */
> - load->read(load, header, sizeof(hdr), );
> -
> /*
>* If the payload is compressed, the decompressed data should be
>* directly write to its load address.
>*/
> - if (spl_image_get_comp() != IH_COMP_NONE)
> + if (spl_image_get_comp(hdr) != IH_COMP_NONE)
> spl_image->flags |= SPL_COPY_PAYLOAD_ONLY;
>
> - ret = spl_parse_image_header(spl_image, bootdev, );
> + ret = spl_parse_image_header(spl_image, bootdev, hdr);
> if (ret)
> return ret;
>
> /* Read image */
> - switch (spl_image_get_comp()) {
> + switch (spl_image_get_comp(hdr)) {
> case IH_COMP_NONE:
> - dataptr = header;
> + dataptr = offset;
>
> /*
>* Image header will be skipped only if SPL_COPY_PAYLOAD_ONLY
> @@ -119,7 +116,7 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
> lzma_len = LZMA_LEN;
>
> /* dataptr points to compressed payload */
> - dataptr = header + sizeof(hdr);
> + dataptr = offset + sizeof(hdr);
>
> debug("LZMA: Decompressing %08lx to %08lx\n",
> dataptr, spl_image->load_addr);
> @@ -143,7 +140,7 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
>
> default:
> debug("Compression method %s is not supported\n",
> - genimg_get_comp_short_name(image_get_comp()));
> + genimg_get_comp_short_name(image_get_comp(hdr)));
> return -EINVAL;
> }
>
> diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
> index 7b7579a2df..5eb67b5468 100644
> --- a/common/spl/spl_nand.c
> +++ b/common/spl/spl_nand.c
> @@ -119,7 +119,7 @@ static int spl_nand_load_element(struct spl_image_info
> *spl_image,
> load.bl_len = 1;
> load.read = spl_nand_legacy_read;
>
> - return spl_load_legacy_img(spl_image, bootdev, , offset);
> + return spl_load_legacy_img(spl_image, bootdev, , offset,
> header);
> } else {
> err = spl_parse_image_header(spl_image, bootdev, header);
> if (err)
> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> index 7986e930d2..f00a5c395b 100644
> --- a/common/spl/spl_nor.c
> +++ b/common/spl/spl_nor.c
> @@ -111,10 +111,14 @@ static int spl_nor_load_image(struct spl_image_info
> *spl_image,
>
> /* Legacy image handling */
> if (IS_ENABLED(CONFIG_SPL_LEGACY_IMAGE_FORMAT)) {
> + struct image_header hdr;
> +
> load.bl_len = 1;
> load.read = spl_nor_load_read;
> + spl_nor_load_read(, spl_nor_get_uboot_base(), sizeof(hdr),
> );
> return spl_load_legacy_img(spl_image, bootdev, ,
> -spl_nor_get_uboot_base());
> +spl_nor_get_uboot_base(),
> +);
> }
>
> return 0;
> diff --git a/include/spl.h b/include/spl.h
> index aac6648f94..7fa5e51c39 100644
> --- a/include/spl.h
> +++ b/include/spl.h
>
Re: [u-boot][PATCH] mtd: nand: Fix SPL build after migration of CONFIG_SYS_NAND_SELF_INIT to Kconfig
Hello Michael,
On 29/09/2022 09:08, Michael Nazzareno Trimarchi wrote:
> Hi
>
> Il mer 28 set 2022, 13:42 Roger Quadros <mailto:rog...@kernel.org>> ha scritto:
>
> This fixes the below build error if nand.c is included in
> an SPL build.
>
> /work/u-boot/drivers/mtd/nand/raw/nand.c: In function ‘nand_init_chip’:
> /work/u-boot/drivers/mtd/nand/raw/nand.c:82:28: error: ‘nand_chip’
> undeclared (first use in this function)
> 82 | struct nand_chip *nand = _chip[i];
> | ^
> /work/u-boot/drivers/mtd/nand/raw/nand.c:82:28: note: each undeclared
> identifier is reported only once for each function it appears in
> /work/u-boot/drivers/mtd/nand/raw/nand.c:84:20: error: ‘base_address’
> undeclared (first use in this function); did you mean ‘base_addr’?
> 84 | ulong base_addr = base_address[i];
> | ^~~~
> | base_addr
>
> Fixes: 068c41f1cc77 ("Finish conversion CONFIG_SYS_NAND_SELF_INIT to
> Kconfig")
> Signed-off-by: Roger Quadros <mailto:rog...@kernel.org>>
> ---
> drivers/mtd/nand/raw/nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/nand.c b/drivers/mtd/nand/raw/nand.c
> index 4b5560dd24..14bca12024 100644
> --- a/drivers/mtd/nand/raw/nand.c
> +++ b/drivers/mtd/nand/raw/nand.c
> @@ -19,7 +19,7 @@ int nand_curr_device = -1;
>
> static struct mtd_info *nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
>
> -#ifndef CONFIG_SYS_NAND_SELF_INIT
> +#if !CONFIG_IS_ENABLED(SYS_NAND_SELF_INIT)
> static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
> static ulong base_address[CONFIG_SYS_MAX_NAND_DEVICE] =
> CONFIG_SYS_NAND_BASE_LIST;
> #endif
>
>
> Reviewed-by: Michael Trimarchi <mailto:mich...@amarulasolutions.com>>
Thanks.
Could you please fix your email client to use plain text format
when responding on u-boot mailing list? ;)
>
> --
> 2.17.1
>
cheers,
-roger
[u-boot][PATCH v2 4/4] memory: Add TI GPMC driver
The GPMC is a unified memory controller dedicated for interfacing
with external memory devices like
- Asynchronous SRAM-like memories and ASICs
- Asynchronous, synchronous, and page mode burst NOR flash
- NAND flash
- Pseudo-SRAM devices
This driver will take care of setting up the GPMC based on
the settings specified in the Device tree and then
probe its children.
Signed-off-by: Roger Quadros
---
drivers/memory/Kconfig| 19 +
drivers/memory/Makefile |1 +
drivers/memory/ti-gpmc.c | 1240 +
drivers/memory/ti-gpmc.h | 298
include/linux/mtd/omap_gpmc.h |3 +
5 files changed, 1561 insertions(+)
create mode 100644 drivers/memory/ti-gpmc.c
create mode 100644 drivers/memory/ti-gpmc.h
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 632feb3aaa..d057c9883b 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -41,4 +41,23 @@ config TI_AEMIF
of 256M bytes of any of these memories can be accessed at a given
time via four chip selects with 64M byte access per chip select.
+config TI_GPMC
+ bool "Texas Instruments GPMC driver"
+ depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ depends on DM_MEMORY
+ help
+ This driver is for the General Purpose Memory Controller (GPMC)
+ present on Texas Instruments SoCs (e.g. OMAP2+). GPMC allows
+ interfacing to a variety of asynchronous as well as synchronous
+ memory drives like NOR, NAND, OneNAND, SRAM.
+
+if TI_GPMC
+config TI_GPMC_DEBUG
+ bool "Debug Texas Instruments GPMC timings"
+ default n
+ help
+ Enable this to print GPMC timings before and after the GPMC registers
+ are programmed. This should not be left enabled on production systems.
+endif
+
endmenu
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 1d68b2b296..7ce0b98e42 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_DM_MEMORY) += memory-uclass.o
obj-$(CONFIG_SANDBOX_MEMORY) += memory-sandbox.o
obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
+obj-$(CONFIG_TI_GPMC) += ti-gpmc.o
diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c
new file mode 100644
index 00..f511a529b1
--- /dev/null
+++ b/drivers/memory/ti-gpmc.c
@@ -0,0 +1,1240 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments GPMC Driver
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ti-gpmc.h"
+
+enum gpmc_clk_domain {
+ GPMC_CD_FCLK,
+ GPMC_CD_CLK
+};
+
+struct gpmc_cs_data {
+ const char *name;
+#define GPMC_CS_RESERVED BIT(0)
+ u32 flags;
+};
+
+struct ti_gpmc {
+ void __iomem *base;
+ u32 cs_num;
+ u32 nr_waitpins;
+ struct clk *l3_clk;
+ u32 capability_flags;
+ struct resource data;
+};
+
+static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
+static unsigned int gpmc_cs_num = GPMC_CS_NUM;
+static unsigned int gpmc_nr_waitpins;
+static unsigned int gpmc_capability;
+static void __iomem *gpmc_base;
+static struct clk *gpmc_l3_clk;
+
+/* Public, as required by nand/raw/omap_gpmc.c */
+const struct gpmc *gpmc_cfg;
+
+/*
+ * The first 1MB of GPMC address space is typically mapped to
+ * the internal ROM. Never allocate the first page, to
+ * facilitate bug detection; even if we didn't boot from ROM.
+ * As GPMC minimum partition size is 16MB we can only start from
+ * there.
+ */
+#define GPMC_MEM_START 0x100
+#define GPMC_MEM_END 0x3FFF
+
+static void gpmc_write_reg(int idx, u32 val)
+{
+ writel_relaxed(val, gpmc_base + idx);
+}
+
+static u32 gpmc_read_reg(int idx)
+{
+ return readl_relaxed(gpmc_base + idx);
+}
+
+static void gpmc_cs_write_reg(int cs, int idx, u32 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ writel_relaxed(val, reg_addr);
+}
+
+static u32 gpmc_cs_read_reg(int cs, int idx)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ return readl_relaxed(reg_addr);
+}
+
+static unsigned long gpmc_get_fclk_period(void)
+{
+ unsigned long rate = clk_get_rate(gpmc_l3_clk);
+
+ rate /= 1000;
+ rate = 10 / rate; /* In picoseconds */
+
+ return rate;
+}
+
+/**
+ * gpmc_get_clk_period - get period of selected clock domain in ps
+ * @cs: Chip Select Region.
+ * @cd: Clock Domain.
+ *
+ * GPMC_CS_CONFIG1 GPMCFCLKDIVIDER for cs has to be setup
+ * prior to calling this function with GPMC_CD_CLK.
+ */
+static unsigned long gpmc_get_clk_period(int cs, enum gpmc_clk_domain cd)
+{
[u-boot][PATCH v2 3/4] dt/bindings: memory: Add bindings for TI GPMC driver
GPMC stands for General Purpose Memory Controller and it is present on many Texas Instruments SoCs. It supports a number of Asynchronous and Synchronous interfaces and has various settings to configure the bus interface. The DT bindings define all the various GPMC settings. As the GPMC supports multiple devices on the bus, each device is represented as a child and the respective GPMC settings are situated there. (see ti,gpmc-child.yaml) These binding docs are picked up from the Linux kernel. Signed-off-by: Roger Quadros --- .../memory/ti,gpmc-child.yaml | 252 ++ doc/device-tree-bindings/memory/ti,gpmc.yaml | 190 + 2 files changed, 442 insertions(+) create mode 100644 doc/device-tree-bindings/memory/ti,gpmc-child.yaml create mode 100644 doc/device-tree-bindings/memory/ti,gpmc.yaml diff --git a/doc/device-tree-bindings/memory/ti,gpmc-child.yaml b/doc/device-tree-bindings/memory/ti,gpmc-child.yaml new file mode 100644 index 00..8e541acdb1 --- /dev/null +++ b/doc/device-tree-bindings/memory/ti,gpmc-child.yaml @@ -0,0 +1,252 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ti,gpmc-child.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: device tree bindings for children of the Texas Instruments GPMC + +maintainers: + - Tony Lindgren + - Roger Quadros + +description: + This binding is meant for the child nodes of the GPMC node. The node + represents any device connected to the GPMC bus. It may be a Flash chip, + RAM chip or Ethernet controller, etc. These properties are meant for + configuring the GPMC settings/timings and will accompany the bindings + supported by the respective device. + +properties: + reg: true + +# GPMC Timing properties for child nodes. All are optional and default to 0. + gpmc,sync-clk-ps: +description: Minimum clock period for synchronous mode +default: 0 + +# Chip-select signal timings corresponding to GPMC_CONFIG2: + gpmc,cs-on-ns: +description: Assertion time +default: 0 + + gpmc,cs-rd-off-ns: +description: Read deassertion time +default: 0 + + gpmc,cs-wr-off-ns: +description: Write deassertion time +default: 0 + +# ADV signal timings corresponding to GPMC_CONFIG3: + gpmc,adv-on-ns: +description: Assertion time +default: 0 + + gpmc,adv-rd-off-ns: +description: Read deassertion time +default: 0 + + gpmc,adv-wr-off-ns: +description: Write deassertion time +default: 0 + + gpmc,adv-aad-mux-on-ns: +description: Assertion time for AAD +default: 0 + + gpmc,adv-aad-mux-rd-off-ns: +description: Read deassertion time for AAD +default: 0 + + gpmc,adv-aad-mux-wr-off-ns: +description: Write deassertion time for AAD +default: 0 + +# WE signals timings corresponding to GPMC_CONFIG4: + gpmc,we-on-ns: +description: Assertion time +default: 0 + + gpmc,we-off-ns: +description: Deassertion time +default: 0 + +# OE signals timings corresponding to GPMC_CONFIG4: + gpmc,oe-on-ns: +description: Assertion time +default: 0 + + gpmc,oe-off-ns: +description: Deassertion time +default: 0 + + gpmc,oe-aad-mux-on-ns: +description: Assertion time for AAD +default: 0 + + gpmc,oe-aad-mux-off-ns: +description: Deassertion time for AAD +default: 0 + +# Access time and cycle time timings (in nanoseconds) corresponding to +# GPMC_CONFIG5: + gpmc,page-burst-access-ns: +description: Multiple access word delay +default: 0 + + gpmc,access-ns: +description: Start-cycle to first data valid delay +default: 0 + + gpmc,rd-cycle-ns: +description: Total read cycle time +default: 0 + + gpmc,wr-cycle-ns: +description: Total write cycle time +default: 0 + + gpmc,bus-turnaround-ns: +description: Turn-around time between successive accesses +default: 0 + + gpmc,cycle2cycle-delay-ns: +description: Delay between chip-select pulses +default: 0 + + gpmc,clk-activation-ns: +description: GPMC clock activation time +default: 0 + + gpmc,wait-monitoring-ns: +description: Start of wait monitoring with regard to valid data +default: 0 + +# Boolean timing parameters. If property is present, parameter is enabled +# otherwise disabled. + gpmc,adv-extra-delay: +description: ADV signal is delayed by half GPMC clock +type: boolean + + gpmc,cs-extra-delay: +description: CS signal is delayed by half GPMC clock +type: boolean + + gpmc,cycle2cycle-diffcsen: +description: | + Add "cycle2cycle-delay" between successive accesses + to a different CS +type: boolean + + gpmc,cycle2cycle-samecsen: +description: | + Add "cycle2cycle-delay" between successive accesses + to the same CS +type: boolean + + gpmc,oe-extra-delay: +description: OE signal is delayed by half GPMC clock +type: boolea
[u-boot][PATCH v2 1/4] dm: memory: Introduce new uclass
Introduce UCLASS_MEMORY for future Memory Controller
device drivers.
Signed-off-by: Roger Quadros
---
arch/sandbox/dts/test.dts | 4
drivers/memory/Kconfig | 17 +
drivers/memory/Makefile | 2 ++
drivers/memory/memory-sandbox.c | 18 ++
drivers/memory/memory-uclass.c | 13 +
include/dm/uclass-id.h | 1 +
test/dm/Makefile| 1 +
test/dm/memory.c| 21 +
8 files changed, 77 insertions(+)
create mode 100644 drivers/memory/memory-sandbox.c
create mode 100644 drivers/memory/memory-uclass.c
create mode 100644 test/dm/memory.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 2761588f0d..d65b2d2dcb 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -926,6 +926,10 @@
};
};
+ memory-controller {
+ compatible = "sandbox,memory";
+ };
+
misc-test {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 7271892763..632feb3aaa 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -4,6 +4,23 @@
menu "Memory Controller drivers"
+config DM_MEMORY
+ bool "Enable Driver Model for Memory Controller drivers"
+ depends on DM
+ help
+ Enable driver model for Memory Controller devices.
+ These devices provide Memory bus interface to various devices like
+ SRAM, Ethernet adapters, FPGAs, etc.
+ For now this uclass has no methods yet.
+
+config SANDBOX_MEMORY
+ bool "Enable Sandbox Memory Controller driver"
+ depends on SANDBOX && DM_MEMORY
+ help
+ This is a driver model based Memory Controller driver for sandbox.
+ Currently it is a stub only, as there are no usable uclass methods
+ yet.
+
config STM32_FMC2_EBI
bool "Support for FMC2 External Bus Interface on STM32MP SoCs"
depends on ARCH_STM32MP
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index fec52efb60..1d68b2b296 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -1,3 +1,5 @@
+obj-$(CONFIG_DM_MEMORY) += memory-uclass.o
+obj-$(CONFIG_SANDBOX_MEMORY) += memory-sandbox.o
obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
diff --git a/drivers/memory/memory-sandbox.c b/drivers/memory/memory-sandbox.c
new file mode 100644
index 00..f2ede50863
--- /dev/null
+++ b/drivers/memory/memory-sandbox.c
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022
+ * Texas Instruments Incorporated,
+ */
+
+#include
+
+static const struct udevice_id sandbox_memory_match[] = {
+ { .compatible = "sandbox,memory" },
+ { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(sandbox_memory) = {
+ .name = "sandbox_memory",
+ .id = UCLASS_MEMORY,
+ .of_match = sandbox_memory_match,
+};
diff --git a/drivers/memory/memory-uclass.c b/drivers/memory/memory-uclass.c
new file mode 100644
index 00..d6d37fe777
--- /dev/null
+++ b/drivers/memory/memory-uclass.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022
+ * Texas Instruments Incorporated,
+ */
+
+#include
+
+UCLASS_DRIVER(memory) = {
+ .name = "memory",
+ .id = UCLASS_MEMORY,
+ .post_bind = dm_scan_fdt_dev,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index a432e43871..936a16c5d9 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -76,6 +76,7 @@ enum uclass_id {
UCLASS_MASS_STORAGE,/* Mass storage device */
UCLASS_MDIO,/* MDIO bus */
UCLASS_MDIO_MUX,/* MDIO MUX/switch */
+ UCLASS_MEMORY, /* Memory Controller device */
UCLASS_MISC,/* Miscellaneous device */
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 7543df8823..01275db2cd 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -47,6 +47,7 @@ ifneq ($(CONFIG_EFI_PARTITION),)
obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fastboot.o
endif
obj-$(CONFIG_FIRMWARE) += firmware.o
+obj-$(CONFIG_DM_MEMORY) += memory.o
obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock.o
obj-$(CONFIG_DM_I2C) += i2c.o
obj-$(CONFIG_SOUND) += i2s.o
diff --git a/test/dm/memory.c b/test/dm/memory.c
new file mode 100644
index 00..7d9500aa91
--- /dev/null
+++ b/test/dm/memory.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022
+ * Texas Instruments Incorporated,
+ */
+
+#include
+#include
+#include
+#include
+
+static int dm_test_memory(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+
+ ut_
[u-boot][PATCH v2 2/4] scripts: Makefile.spl: Enable memory drivers to be built for SPL
We will need ti-gpmc driver for SPL. Allow memory drivers do be built for SPL. Signed-off-by: Roger Quadros --- scripts/Makefile.spl | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 3bafeb4fe9..110076b22f 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -114,6 +114,7 @@ libs-$(CONFIG_PARTITIONS) += disk/ endif libs-y += drivers/ +libs-y += drivers/memory/ libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/dwc3/ libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/cdns3/ libs-y += dts/ -- 2.17.1
[u-boot][PATCH v2 0/4] Introduce MEMORY uclass and TI GPMC driver
Hi, This series introduces the MEMORY controller uclass for the drivers that exist in drivers/memory directory. With that, we add the TI GPMC Memory controller driver as the first user of this uclass. The GPMC is a unified memory controller dedicated for interfacing with external memory devices like - Asynchronous SRAM-like memories and ASICs - Asynchronous, synchronous, and page mode burst NOR flash - NAND flash - Pseudo-SRAM devices The driver is pulled straight from the Linux kernel and adapted for u-boot. This driver will take care of setting up the GPMC based on the settings specified in the Device tree and then probe its children. Roger Quadros (4): dm: memory: Introduce new uclass scripts: Makefile.spl: Enable memory drivers to be built for SPL dt/bindings: memory: Add bindings for TI GPMC driver memory: Add TI GPMC driver arch/sandbox/dts/test.dts |4 + .../memory/ti,gpmc-child.yaml | 252 doc/device-tree-bindings/memory/ti,gpmc.yaml | 190 +++ drivers/memory/Kconfig| 36 + drivers/memory/Makefile |3 + drivers/memory/memory-sandbox.c | 18 + drivers/memory/memory-uclass.c| 13 + drivers/memory/ti-gpmc.c | 1240 + drivers/memory/ti-gpmc.h | 298 include/dm/uclass-id.h|1 + include/linux/mtd/omap_gpmc.h |3 + scripts/Makefile.spl |1 + test/dm/Makefile |1 + test/dm/memory.c | 21 + 14 files changed, 2081 insertions(+) create mode 100644 doc/device-tree-bindings/memory/ti,gpmc-child.yaml create mode 100644 doc/device-tree-bindings/memory/ti,gpmc.yaml create mode 100644 drivers/memory/memory-sandbox.c create mode 100644 drivers/memory/memory-uclass.c create mode 100644 drivers/memory/ti-gpmc.c create mode 100644 drivers/memory/ti-gpmc.h create mode 100644 test/dm/memory.c -- 2.17.1
Re: [u-boot][PATCH 1/3] scripts: Makefile.spl: Enable memory drivers to be built for SPL
Hi, On 01/10/2022 02:48, Simon Glass wrote: > Hi, > > On Fri, 30 Sept 2022 at 14:18, Roger Quadros wrote: >> >> On 30/09/2022 17:00, Tom Rini wrote: >>> On Fri, Sep 30, 2022 at 07:28:51AM -0600, Simon Glass wrote: >>>> Hi Roger, >>>> >>>> On Fri, 30 Sept 2022 at 06:47, Roger Quadros wrote: >>>>> >>>>> Simon, >>>>> >>>>> On 29/09/2022 21:06, Simon Glass wrote: >>>>>> Hi Roger, >>>>>> >>>>>> On Thu, 29 Sept 2022 at 01:03, Roger Quadros wrote: >>>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> On 28/09/2022 19:27, Simon Glass wrote: >>>>>>>> Hi Roger, >>>>>>>> >>>>>>>> On Wed, 28 Sept 2022 at 06:12, Roger Quadros wrote: >>>>>>>>> >>>>>>>>> We will need ti-gpmc driver for SPL. Allow memory drivers >>>>>>>>> do be built for SPL. >>>>>>>>> >>>>>>>>> Signed-off-by: Roger Quadros >>>>>>>>> --- >>>>>>>>> scripts/Makefile.spl | 1 + >>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>> >>>>>>>> Please can you use the existing drivers/ram directory? >>>>>>> >>>>>>> The ti-gpmc driver is not actually a RAM only controller. Although it >>>>>>> can support SRAM. >>>>>>> It is a more general purpose controller that can support different >>>>>>> peripherals. >>>>>>> It is similar to the drivers already existing in the divers/memory >>>>>>> directory. >>>>>>> >>>>>>> I was just trying to keep the file layout similar to that in the Linux >>>>>>> kernel. >>>>>>> >>>>>>> Do you still see a problem with it? >>>>>> >>>>>> Well in this case perhaps the RAM device would be a child of this one? >>>>> >>>>> That's right. >>>>>> >>>>>> But there is no uclass for your new device. One of the drivers in that >>>>>> dir uses UCLASS_NOP and your one seems to use UCLASS_SIMPLE_BUS >>>>>> >>>>>> So let's add a uclass for it and describe exactly what it is for. >>>>> >>>>> Why isn't UCLASS_SIMPLE_BUS sufficient? >>>>> By itself, the GPMC driver doesn't offer any usable functionality. >>>>> It just configures the bus interface and then populates the children. >>>> >>>> That's OK, but in that case it should go in drivers/bus and perhaps >>>> drivers/memory should go away? >>> >>> No, drivers/memory/stm32-fmc2-ebi.c is there and is the equivalent (more >>> or less) of drivers/memory/stm32-fmc2-ebi.c in the linux kernel. So >>> maybe a question is, are we talking about the equivalent of >>> drivers/memory/omap-gpmc.c here? Or something else? >>> >> >> Yes, I just picked up that file and adapted it for u-boot. >> As GPMC is not only for OMAP devices anymore I renamed it to ti-gpmc.c. >> If it helps we can retain the kernel naming. > > In the fullness of time all driver/xxx directories should have a > uclass associated with them. So in this case, do we want to use > UCLASS_BUS and put it in drivers/bus or add a UCLASS_MEMORY and put it > in drivers/memory? I'd opt for UCLASS_MEMORY. cheers, -roger
Re: [u-boot][PATCH 1/3] scripts: Makefile.spl: Enable memory drivers to be built for SPL
On 30/09/2022 17:00, Tom Rini wrote: > On Fri, Sep 30, 2022 at 07:28:51AM -0600, Simon Glass wrote: >> Hi Roger, >> >> On Fri, 30 Sept 2022 at 06:47, Roger Quadros wrote: >>> >>> Simon, >>> >>> On 29/09/2022 21:06, Simon Glass wrote: >>>> Hi Roger, >>>> >>>> On Thu, 29 Sept 2022 at 01:03, Roger Quadros wrote: >>>>> >>>>> Hi Simon, >>>>> >>>>> On 28/09/2022 19:27, Simon Glass wrote: >>>>>> Hi Roger, >>>>>> >>>>>> On Wed, 28 Sept 2022 at 06:12, Roger Quadros wrote: >>>>>>> >>>>>>> We will need ti-gpmc driver for SPL. Allow memory drivers >>>>>>> do be built for SPL. >>>>>>> >>>>>>> Signed-off-by: Roger Quadros >>>>>>> --- >>>>>>> scripts/Makefile.spl | 1 + >>>>>>> 1 file changed, 1 insertion(+) >>>>>> >>>>>> Please can you use the existing drivers/ram directory? >>>>> >>>>> The ti-gpmc driver is not actually a RAM only controller. Although it can >>>>> support SRAM. >>>>> It is a more general purpose controller that can support different >>>>> peripherals. >>>>> It is similar to the drivers already existing in the divers/memory >>>>> directory. >>>>> >>>>> I was just trying to keep the file layout similar to that in the Linux >>>>> kernel. >>>>> >>>>> Do you still see a problem with it? >>>> >>>> Well in this case perhaps the RAM device would be a child of this one? >>> >>> That's right. >>>> >>>> But there is no uclass for your new device. One of the drivers in that >>>> dir uses UCLASS_NOP and your one seems to use UCLASS_SIMPLE_BUS >>>> >>>> So let's add a uclass for it and describe exactly what it is for. >>> >>> Why isn't UCLASS_SIMPLE_BUS sufficient? >>> By itself, the GPMC driver doesn't offer any usable functionality. >>> It just configures the bus interface and then populates the children. >> >> That's OK, but in that case it should go in drivers/bus and perhaps >> drivers/memory should go away? > > No, drivers/memory/stm32-fmc2-ebi.c is there and is the equivalent (more > or less) of drivers/memory/stm32-fmc2-ebi.c in the linux kernel. So > maybe a question is, are we talking about the equivalent of > drivers/memory/omap-gpmc.c here? Or something else? > Yes, I just picked up that file and adapted it for u-boot. As GPMC is not only for OMAP devices anymore I renamed it to ti-gpmc.c. If it helps we can retain the kernel naming. cheers, -roger
Re: [u-boot][PATCH 1/3] scripts: Makefile.spl: Enable memory drivers to be built for SPL
Simon, On 29/09/2022 21:06, Simon Glass wrote: > Hi Roger, > > On Thu, 29 Sept 2022 at 01:03, Roger Quadros wrote: >> >> Hi Simon, >> >> On 28/09/2022 19:27, Simon Glass wrote: >>> Hi Roger, >>> >>> On Wed, 28 Sept 2022 at 06:12, Roger Quadros wrote: >>>> >>>> We will need ti-gpmc driver for SPL. Allow memory drivers >>>> do be built for SPL. >>>> >>>> Signed-off-by: Roger Quadros >>>> --- >>>> scripts/Makefile.spl | 1 + >>>> 1 file changed, 1 insertion(+) >>> >>> Please can you use the existing drivers/ram directory? >> >> The ti-gpmc driver is not actually a RAM only controller. Although it can >> support SRAM. >> It is a more general purpose controller that can support different >> peripherals. >> It is similar to the drivers already existing in the divers/memory directory. >> >> I was just trying to keep the file layout similar to that in the Linux >> kernel. >> >> Do you still see a problem with it? > > Well in this case perhaps the RAM device would be a child of this one? That's right. > > But there is no uclass for your new device. One of the drivers in that > dir uses UCLASS_NOP and your one seems to use UCLASS_SIMPLE_BUS > > So let's add a uclass for it and describe exactly what it is for. Why isn't UCLASS_SIMPLE_BUS sufficient? By itself, the GPMC driver doesn't offer any usable functionality. It just configures the bus interface and then populates the children. cheers, -roger
Re: [u-boot][PATCH 0/3] Introduce TI GPMC memory controller driver
Hi Tom, On 29/09/2022 20:51, Tom Rini wrote: > On Wed, Sep 28, 2022 at 03:11:46PM +0300, Roger Quadros wrote: > >> Hi, >> >> The GPMC is a unified memory controller dedicated for interfacing >> with external memory devices like >> - Asynchronous SRAM-like memories and ASICs >> - Asynchronous, synchronous, and page mode burst NOR flash >> - NAND flash >> - Pseudo-SRAM devices >> >> This driver will take care of setting up the GPMC based on >> the settings specified in the Device tree and then >> probe its children. > > Does this mean we'll be seeing some updates to (or removal of) the > existing nand/gpmc code under arch/arm/mach-omap2 ? > My initial plan was to get AM64 NAND to work without requiring any arch specific code. This should eventually be usable for mach-omap2 as well. We can then get rid of /arch/arm/mach-omap2/mem-common.c I have an omap3-beagle with NAND support with me so I could at least get it working on that board. It should be pretty much the same for all mach-omap2 boards. cheers, -roger
[u-boot][PATCH] spl: spl_legacy: Fix NAND boot on OMAP3 BeagleBoard
OMAP3 BeagleBoard NAND boot hangs when spl_load_legacy_img() tries
to read the header into 'struct hdr' which is allocated on the
stack.
As the header has already been read once before by spl_nand.c,
we can avoid the extra header read here by simply passing around
the pointer to the header.
This fixes NAND boot on OMAP3 BeagleBoard.
Signed-off-by: Roger Quadros
---
common/spl/spl_legacy.c | 19 ---
common/spl/spl_nand.c | 2 +-
common/spl/spl_nor.c| 6 +-
include/spl.h | 7 +--
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
index ae8731c782..2e9226c990 100644
--- a/common/spl/spl_legacy.c
+++ b/common/spl/spl_legacy.c
@@ -77,32 +77,29 @@ static inline int spl_image_get_comp(const struct
image_header *hdr)
int spl_load_legacy_img(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev,
- struct spl_load_info *load, ulong header)
+ struct spl_load_info *load, ulong offset,
+ struct image_header *hdr)
{
__maybe_unused SizeT lzma_len;
__maybe_unused void *src;
- struct image_header hdr;
ulong dataptr;
int ret;
- /* Read header into local struct */
- load->read(load, header, sizeof(hdr), );
-
/*
* If the payload is compressed, the decompressed data should be
* directly write to its load address.
*/
- if (spl_image_get_comp() != IH_COMP_NONE)
+ if (spl_image_get_comp(hdr) != IH_COMP_NONE)
spl_image->flags |= SPL_COPY_PAYLOAD_ONLY;
- ret = spl_parse_image_header(spl_image, bootdev, );
+ ret = spl_parse_image_header(spl_image, bootdev, hdr);
if (ret)
return ret;
/* Read image */
- switch (spl_image_get_comp()) {
+ switch (spl_image_get_comp(hdr)) {
case IH_COMP_NONE:
- dataptr = header;
+ dataptr = offset;
/*
* Image header will be skipped only if SPL_COPY_PAYLOAD_ONLY
@@ -119,7 +116,7 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
lzma_len = LZMA_LEN;
/* dataptr points to compressed payload */
- dataptr = header + sizeof(hdr);
+ dataptr = offset + sizeof(hdr);
debug("LZMA: Decompressing %08lx to %08lx\n",
dataptr, spl_image->load_addr);
@@ -143,7 +140,7 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
default:
debug("Compression method %s is not supported\n",
- genimg_get_comp_short_name(image_get_comp()));
+ genimg_get_comp_short_name(image_get_comp(hdr)));
return -EINVAL;
}
diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index 7b7579a2df..5eb67b5468 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -119,7 +119,7 @@ static int spl_nand_load_element(struct spl_image_info
*spl_image,
load.bl_len = 1;
load.read = spl_nand_legacy_read;
- return spl_load_legacy_img(spl_image, bootdev, , offset);
+ return spl_load_legacy_img(spl_image, bootdev, , offset,
header);
} else {
err = spl_parse_image_header(spl_image, bootdev, header);
if (err)
diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index 7986e930d2..f00a5c395b 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -111,10 +111,14 @@ static int spl_nor_load_image(struct spl_image_info
*spl_image,
/* Legacy image handling */
if (IS_ENABLED(CONFIG_SPL_LEGACY_IMAGE_FORMAT)) {
+ struct image_header hdr;
+
load.bl_len = 1;
load.read = spl_nor_load_read;
+ spl_nor_load_read(, spl_nor_get_uboot_base(), sizeof(hdr),
);
return spl_load_legacy_img(spl_image, bootdev, ,
- spl_nor_get_uboot_base());
+ spl_nor_get_uboot_base(),
+ );
}
return 0;
diff --git a/include/spl.h b/include/spl.h
index aac6648f94..7fa5e51c39 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -353,7 +353,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
* spl_load_legacy_img() - Loads a legacy image from a device.
* @spl_image: Image description to set up
* @load: Structure containing the information required to load data.
- * @header:Pointer to image header (including appended image)
+ * @offset:Pointer to image
+ * @hdr: Pointer to image header
*
* Reads an legacy image from the device. Loads u-boot image to
* specified load address.
@@ -361,7 +362,9 @@ int spl_load_sim
Re: [u-boot][PATCH 1/3] scripts: Makefile.spl: Enable memory drivers to be built for SPL
Hi Simon, On 28/09/2022 19:27, Simon Glass wrote: > Hi Roger, > > On Wed, 28 Sept 2022 at 06:12, Roger Quadros wrote: >> >> We will need ti-gpmc driver for SPL. Allow memory drivers >> do be built for SPL. >> >> Signed-off-by: Roger Quadros >> --- >> scripts/Makefile.spl | 1 + >> 1 file changed, 1 insertion(+) > > Please can you use the existing drivers/ram directory? The ti-gpmc driver is not actually a RAM only controller. Although it can support SRAM. It is a more general purpose controller that can support different peripherals. It is similar to the drivers already existing in the divers/memory directory. I was just trying to keep the file layout similar to that in the Linux kernel. Do you still see a problem with it? > >> >> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl >> index 3bafeb4fe9..110076b22f 100644 >> --- a/scripts/Makefile.spl >> +++ b/scripts/Makefile.spl >> @@ -114,6 +114,7 @@ libs-$(CONFIG_PARTITIONS) += disk/ >> endif >> >> libs-y += drivers/ >> +libs-y += drivers/memory/ >> libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/dwc3/ >> libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/cdns3/ >> libs-y += dts/ >> -- >> 2.17.1 >> > > Regards, > Simon cheers, -roger
[u-boot][PATCH 3/3] memory: Add TI GPMC driver
The GPMC is a unified memory controller dedicated for interfacing
with external memory devices like
- Asynchronous SRAM-like memories and ASICs
- Asynchronous, synchronous, and page mode burst NOR flash
- NAND flash
- Pseudo-SRAM devices
This driver will take care of setting up the GPMC based on
the settings specified in the Device tree and then
probe its children.
Signed-off-by: Roger Quadros
---
drivers/memory/Kconfig| 16 +
drivers/memory/Makefile |1 +
drivers/memory/ti-gpmc.c | 1237 +
drivers/memory/ti-gpmc.h | 298
include/linux/mtd/omap_gpmc.h |3 +
5 files changed, 1555 insertions(+)
create mode 100644 drivers/memory/ti-gpmc.c
create mode 100644 drivers/memory/ti-gpmc.h
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 7271892763..6ce48cebf9 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -24,4 +24,20 @@ config TI_AEMIF
of 256M bytes of any of these memories can be accessed at a given
time via four chip selects with 64M byte access per chip select.
+config TI_GPMC
+ bool "Texas Instruments GPMC driver"
+ depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ help
+ This driver is for the General Purpose Memory Controller (GPMC)
+ present on Texas Instruments SoCs (e.g. OMAP2+). GPMC allows
+ interfacing to a variety of asynchronous as well as synchronous
+ memory drives like NOR, NAND, OneNAND, SRAM.
+
+config TI_GPMC_DEBUG
+ bool "Debug Texas Instruments GPMC timings"
+ default n
+ help
+ Enable this to print GPMC timings before and after the GPMC registers
+ are programmed. This should not be left enabled on production systems.
+
endmenu
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index fec52efb60..0971880fcf 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
+obj-$(CONFIG_TI_GPMC) += ti-gpmc.o
diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c
new file mode 100644
index 00..58133df16b
--- /dev/null
+++ b/drivers/memory/ti-gpmc.c
@@ -0,0 +1,1237 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments GPMC Driver
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ti-gpmc.h"
+
+enum gpmc_clk_domain {
+ GPMC_CD_FCLK,
+ GPMC_CD_CLK
+};
+
+struct gpmc_cs_data {
+ const char *name;
+#define GPMC_CS_RESERVED BIT(0)
+ u32 flags;
+};
+
+struct ti_gpmc {
+ void __iomem *base;
+ u32 cs_num;
+ u32 nr_waitpins;
+ struct clk *l3_clk;
+ u32 capability_flags;
+ struct resource data;
+};
+
+static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
+static unsigned int gpmc_cs_num = GPMC_CS_NUM;
+static unsigned int gpmc_nr_waitpins;
+const struct gpmc *gpmc_cfg;
+static unsigned int gpmc_capability;
+static void __iomem *gpmc_base;
+static struct clk *gpmc_l3_clk;
+
+/*
+ * The first 1MB of GPMC address space is typically mapped to
+ * the internal ROM. Never allocate the first page, to
+ * facilitate bug detection; even if we didn't boot from ROM.
+ * As GPMC minimum partition size is 16MB we can only start from
+ * there.
+ */
+#define GPMC_MEM_START 0x100
+#define GPMC_MEM_END 0x3FFF
+
+static void gpmc_write_reg(int idx, u32 val)
+{
+ writel_relaxed(val, gpmc_base + idx);
+}
+
+static u32 gpmc_read_reg(int idx)
+{
+ return readl_relaxed(gpmc_base + idx);
+}
+
+static void gpmc_cs_write_reg(int cs, int idx, u32 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ writel_relaxed(val, reg_addr);
+}
+
+static u32 gpmc_cs_read_reg(int cs, int idx)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
+ return readl_relaxed(reg_addr);
+}
+
+static unsigned long gpmc_get_fclk_period(void)
+{
+ unsigned long rate = clk_get_rate(gpmc_l3_clk);
+
+ rate /= 1000;
+ rate = 10 / rate; /* In picoseconds */
+
+ return rate;
+}
+
+/**
+ * gpmc_get_clk_period - get period of selected clock domain in ps
+ * @cs: Chip Select Region.
+ * @cd: Clock Domain.
+ *
+ * GPMC_CS_CONFIG1 GPMCFCLKDIVIDER for cs has to be setup
+ * prior to calling this function with GPMC_CD_CLK.
+ */
+static unsigned long gpmc_get_clk_period(int cs, enum gpmc_clk_domain cd)
+{
+ unsigned long tick_ps = gpmc_get_fclk_period();
+ u32 l;
+ int div;
+
+ switch (cd) {
+ case GPMC_CD_CLK:
+ /* get current clk divider */
+
[u-boot][PATCH 2/3] dt/bindings: memory: Add bindings for TI GPMC driver
GPMC stands for General Purpose Memory Controller and it is present on many Texas Instruments SoCs. It supports a number of Asynchronous and Synchronous interfaces and has various settings to configure the bus interface. The DT bindings define all the various GPMC settings. As the GPMC supports multiple devices on the bus, each device is represented as a child and the respective GPMC settings are situated there. (see ti,gpmc-child.yaml) These binding docs are picked up from the Linux kernel. Signed-off-by: Roger Quadros --- .../memory/ti,gpmc-child.yaml | 252 ++ doc/device-tree-bindings/memory/ti,gpmc.yaml | 190 + 2 files changed, 442 insertions(+) create mode 100644 doc/device-tree-bindings/memory/ti,gpmc-child.yaml create mode 100644 doc/device-tree-bindings/memory/ti,gpmc.yaml diff --git a/doc/device-tree-bindings/memory/ti,gpmc-child.yaml b/doc/device-tree-bindings/memory/ti,gpmc-child.yaml new file mode 100644 index 00..8e541acdb1 --- /dev/null +++ b/doc/device-tree-bindings/memory/ti,gpmc-child.yaml @@ -0,0 +1,252 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ti,gpmc-child.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: device tree bindings for children of the Texas Instruments GPMC + +maintainers: + - Tony Lindgren + - Roger Quadros + +description: + This binding is meant for the child nodes of the GPMC node. The node + represents any device connected to the GPMC bus. It may be a Flash chip, + RAM chip or Ethernet controller, etc. These properties are meant for + configuring the GPMC settings/timings and will accompany the bindings + supported by the respective device. + +properties: + reg: true + +# GPMC Timing properties for child nodes. All are optional and default to 0. + gpmc,sync-clk-ps: +description: Minimum clock period for synchronous mode +default: 0 + +# Chip-select signal timings corresponding to GPMC_CONFIG2: + gpmc,cs-on-ns: +description: Assertion time +default: 0 + + gpmc,cs-rd-off-ns: +description: Read deassertion time +default: 0 + + gpmc,cs-wr-off-ns: +description: Write deassertion time +default: 0 + +# ADV signal timings corresponding to GPMC_CONFIG3: + gpmc,adv-on-ns: +description: Assertion time +default: 0 + + gpmc,adv-rd-off-ns: +description: Read deassertion time +default: 0 + + gpmc,adv-wr-off-ns: +description: Write deassertion time +default: 0 + + gpmc,adv-aad-mux-on-ns: +description: Assertion time for AAD +default: 0 + + gpmc,adv-aad-mux-rd-off-ns: +description: Read deassertion time for AAD +default: 0 + + gpmc,adv-aad-mux-wr-off-ns: +description: Write deassertion time for AAD +default: 0 + +# WE signals timings corresponding to GPMC_CONFIG4: + gpmc,we-on-ns: +description: Assertion time +default: 0 + + gpmc,we-off-ns: +description: Deassertion time +default: 0 + +# OE signals timings corresponding to GPMC_CONFIG4: + gpmc,oe-on-ns: +description: Assertion time +default: 0 + + gpmc,oe-off-ns: +description: Deassertion time +default: 0 + + gpmc,oe-aad-mux-on-ns: +description: Assertion time for AAD +default: 0 + + gpmc,oe-aad-mux-off-ns: +description: Deassertion time for AAD +default: 0 + +# Access time and cycle time timings (in nanoseconds) corresponding to +# GPMC_CONFIG5: + gpmc,page-burst-access-ns: +description: Multiple access word delay +default: 0 + + gpmc,access-ns: +description: Start-cycle to first data valid delay +default: 0 + + gpmc,rd-cycle-ns: +description: Total read cycle time +default: 0 + + gpmc,wr-cycle-ns: +description: Total write cycle time +default: 0 + + gpmc,bus-turnaround-ns: +description: Turn-around time between successive accesses +default: 0 + + gpmc,cycle2cycle-delay-ns: +description: Delay between chip-select pulses +default: 0 + + gpmc,clk-activation-ns: +description: GPMC clock activation time +default: 0 + + gpmc,wait-monitoring-ns: +description: Start of wait monitoring with regard to valid data +default: 0 + +# Boolean timing parameters. If property is present, parameter is enabled +# otherwise disabled. + gpmc,adv-extra-delay: +description: ADV signal is delayed by half GPMC clock +type: boolean + + gpmc,cs-extra-delay: +description: CS signal is delayed by half GPMC clock +type: boolean + + gpmc,cycle2cycle-diffcsen: +description: | + Add "cycle2cycle-delay" between successive accesses + to a different CS +type: boolean + + gpmc,cycle2cycle-samecsen: +description: | + Add "cycle2cycle-delay" between successive accesses + to the same CS +type: boolean + + gpmc,oe-extra-delay: +description: OE signal is delayed by half GPMC clock +type: boolea
[u-boot][PATCH 1/3] scripts: Makefile.spl: Enable memory drivers to be built for SPL
We will need ti-gpmc driver for SPL. Allow memory drivers do be built for SPL. Signed-off-by: Roger Quadros --- scripts/Makefile.spl | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 3bafeb4fe9..110076b22f 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -114,6 +114,7 @@ libs-$(CONFIG_PARTITIONS) += disk/ endif libs-y += drivers/ +libs-y += drivers/memory/ libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/dwc3/ libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/cdns3/ libs-y += dts/ -- 2.17.1
[u-boot][PATCH 0/3] Introduce TI GPMC memory controller driver
Hi, The GPMC is a unified memory controller dedicated for interfacing with external memory devices like - Asynchronous SRAM-like memories and ASICs - Asynchronous, synchronous, and page mode burst NOR flash - NAND flash - Pseudo-SRAM devices This driver will take care of setting up the GPMC based on the settings specified in the Device tree and then probe its children. cheers, -roger Roger Quadros (3): scripts: Makefile.spl: Enable memory drivers to be built for SPL dt/bindings: memory: Add bindings for TI GPMC driver memory: Add TI GPMC driver .../memory/ti,gpmc-child.yaml | 252 doc/device-tree-bindings/memory/ti,gpmc.yaml | 190 +++ drivers/memory/Kconfig| 16 + drivers/memory/Makefile |1 + drivers/memory/ti-gpmc.c | 1237 + drivers/memory/ti-gpmc.h | 298 include/linux/mtd/omap_gpmc.h |3 + scripts/Makefile.spl |1 + 8 files changed, 1998 insertions(+) create mode 100644 doc/device-tree-bindings/memory/ti,gpmc-child.yaml create mode 100644 doc/device-tree-bindings/memory/ti,gpmc.yaml create mode 100644 drivers/memory/ti-gpmc.c create mode 100644 drivers/memory/ti-gpmc.h -- 2.17.1
[u-boot][PATCH] mtd: nand: Fix SPL build after migration of CONFIG_SYS_NAND_SELF_INIT to Kconfig
This fixes the below build error if nand.c is included in
an SPL build.
/work/u-boot/drivers/mtd/nand/raw/nand.c: In function ‘nand_init_chip’:
/work/u-boot/drivers/mtd/nand/raw/nand.c:82:28: error: ‘nand_chip’ undeclared
(first use in this function)
82 | struct nand_chip *nand = _chip[i];
|^
/work/u-boot/drivers/mtd/nand/raw/nand.c:82:28: note: each undeclared
identifier is reported only once for each function it appears in
/work/u-boot/drivers/mtd/nand/raw/nand.c:84:20: error: ‘base_address’
undeclared (first use in this function); did you mean ‘base_addr’?
84 | ulong base_addr = base_address[i];
|^~~~
|base_addr
Fixes: 068c41f1cc77 ("Finish conversion CONFIG_SYS_NAND_SELF_INIT to Kconfig")
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/nand.c b/drivers/mtd/nand/raw/nand.c
index 4b5560dd24..14bca12024 100644
--- a/drivers/mtd/nand/raw/nand.c
+++ b/drivers/mtd/nand/raw/nand.c
@@ -19,7 +19,7 @@ int nand_curr_device = -1;
static struct mtd_info *nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
-#ifndef CONFIG_SYS_NAND_SELF_INIT
+#if !CONFIG_IS_ENABLED(SYS_NAND_SELF_INIT)
static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
static ulong base_address[CONFIG_SYS_MAX_NAND_DEVICE] =
CONFIG_SYS_NAND_BASE_LIST;
#endif
--
2.17.1
Re: [PATCH RFC v3 10/11] ti: dtsi: j721e: Use binman to package tispl.bin
On 15/06/2022 09:48, Neha Malcom Francis wrote:
> tispl.bin must be packaged (with ATF, OPTEE, DM and A72 SPL) for J721E.
> Binman picks up and packages entries according to the
> description given in the device tree.
>
> k3-j721e-a72-binman.dtsi has been introduced for A72 specific binman
> node. It is included by k3-j721e-common-proc-board-u-boot.dtsi
>
> Signed-off-by: Neha Malcom Francis
> ---
> arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 +++
> .../k3-j721e-common-proc-board-u-boot.dtsi| 1 +
> board/ti/j721e/Kconfig| 1 +
> 3 files changed, 88 insertions(+)
> create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi
>
> diff --git a/arch/arm/dts/k3-j721e-a72-binman.dtsi
> b/arch/arm/dts/k3-j721e-a72-binman.dtsi
> new file mode 100644
> index 00..beb3424bb9
> --- /dev/null
> +++ b/arch/arm/dts/k3-j721e-a72-binman.dtsi
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +
> +#include
> +
> +#ifdef CONFIG_ARM64
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +};
> +
> + {
> + tispl {
> + filename = "tispl.bin";
> + fit {
> + description = "FIT IMAGE";
> + #address-cells = <1>;
> + images {
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + os = "arm-trusted-firmware";
> + load = ;
> + entry = ;
> + atf-bl31 {
> + };
> + };
> + tee {
> + description = "OPTEE";
> + type = "tee";
> + arch = "arm64";
> + compression = "none";
> + os = "tee";
> + load = <0x9e80>;
> + entry = <0x9e80>;
> + tee-os {
> + };
> + };
> + dm {
> + description = "DM binary";
> + type = "firmware";
> + arch = "arm32";
> + compression = "none";
> + os = "DM";
> + load = <0x8900>;
> + entry = <0x8900>;
> + ti-dm {
> + };
> + };
> + spl {
> + description = "SPL (64-bit)";
> + type = "standalone";
> + os = "U-Boot";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> + entry = ;
> + u-boot-spl-nodtb {
> + };
> + };
> + k3-j721e-common-proc-board.dtb {
how about fdt-1 for node name?
> + description =
> "k3-j721e-common-proc-board";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + blob-ext {
> + filename =
> "spl/dts/k3-j721e-common-proc-board.dtb";
> + };
> + };
> + };
> + configurations {
> + default = "conf";
> + conf {
> + description =
> "k3-j721e-common-proc-board";
> + firmware = "atf";
> + loadables = "tee", "dm", "spl";
> + fdt = "k3-j721e-common-proc-board.dtb";
> + };
> + };
> + };
> + };
> +};
> +#endif
> diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
> index
Re: [PATCH RFC v3 10/11] ti: dtsi: j721e: Use binman to package tispl.bin
Neha,
On 15/06/2022 09:48, Neha Malcom Francis wrote:
> tispl.bin must be packaged (with ATF, OPTEE, DM and A72 SPL) for J721E.
> Binman picks up and packages entries according to the
> description given in the device tree.
>
> k3-j721e-a72-binman.dtsi has been introduced for A72 specific binman
> node. It is included by k3-j721e-common-proc-board-u-boot.dtsi
>
> Signed-off-by: Neha Malcom Francis
> ---
> arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 +++
> .../k3-j721e-common-proc-board-u-boot.dtsi| 1 +
> board/ti/j721e/Kconfig| 1 +
> 3 files changed, 88 insertions(+)
> create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi
>
> diff --git a/arch/arm/dts/k3-j721e-a72-binman.dtsi
> b/arch/arm/dts/k3-j721e-a72-binman.dtsi
> new file mode 100644
> index 00..beb3424bb9
> --- /dev/null
> +++ b/arch/arm/dts/k3-j721e-a72-binman.dtsi
Will this file be used for all j721e-a72 boards or only common processor board?
It should be named accordingly.
You might as well combine the separate r5 and a72 binman files into one file.
You can use CONFIG_TARGET_J721E_R5_EVM and CONFIG_TARGET_J721E_A72_EVM
to selectively enable the required entries.
So, k3-j721e-common-proc-board-binman.dtsi?
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +
> +#include
> +
> +#ifdef CONFIG_ARM64
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +};
> +
#ifdef CONFIG_TARGET_J721E_A72_EVM
> + {
> + tispl {
> + filename = "tispl.bin";
> + fit {
> + description = "FIT IMAGE";
This used to be "Configuration to load ATF and SPL", let's retain the
description.
> + #address-cells = <1>;
> + images {
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + os = "arm-trusted-firmware";
> + load = ;
> + entry = ;
> + atf-bl31 {
> + };
> + };
> + tee {
> + description = "OPTEE";
> + type = "tee";
> + arch = "arm64";
> + compression = "none";
> + os = "tee";
> + load = <0x9e80>;
> + entry = <0x9e80>;
> + tee-os {
> + };
> + };
> + dm {
> + description = "DM binary";
> + type = "firmware";
> + arch = "arm32";
> + compression = "none";
> + os = "DM";
> + load = <0x8900>;
> + entry = <0x8900>;
> + ti-dm {
> + };
> + };
> + spl {
> + description = "SPL (64-bit)";
> + type = "standalone";
> + os = "U-Boot";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> + entry = ;
> + u-boot-spl-nodtb {
> + };
> + };
> + k3-j721e-common-proc-board.dtb {
> + description =
> "k3-j721e-common-proc-board";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + blob-ext {
> + filename =
> "spl/dts/k3-j721e-common-proc-board.dtb";
> + };
> + };
> + };
> + configurations {
> + default = "conf";
"conf-1"?
more confs can be added later
> + conf {
> + description =
>
Re: [PATCH RFC v3 08/11] ti: j721e: Exclude makefile tispl.bin target for J721E
Hi Neha, On 15/06/2022 09:48, Neha Malcom Francis wrote: > tispl.bin is to be packaged (with ATF, OPTEE, DM and A72 SPL) using > binman. The tispl.bin target from the makefile is no longer needed for > J721E. > > Signed-off-by: Neha Malcom Francis > --- > arch/arm/mach-k3/config.mk | 5 + > scripts/Makefile.spl | 2 ++ > 2 files changed, 7 insertions(+) > > diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk > index d706d17788..dd5e42d9df 100644 > --- a/arch/arm/mach-k3/config.mk > +++ b/arch/arm/mach-k3/config.mk > @@ -74,6 +74,7 @@ ifeq ($(CONFIG_SOC_K3_J721E),) > export DM := /dev/null > endif > > +ifndef CONFIG_TARGET_J721E_A72_EVM How about using #ifndef CONFIG_BINMAN instead? Any platform enabling that doesn't want to use the old way. You are still breaking HS functionality with this series correct? That will have to be fixed. One proposal was discussed here https://lore.kernel.org/all/76474ded-a782-f491-eac6-ece3c5f4a...@gmail.com/ We should be able to produce tispl.bin_HS and u-boot.img_HS via binman. You have already covered most of the x509 stuff image in ti-x509-cert etype. Please refer to below script [1] to know what is required to get _HS images. [1] https://git.ti.com/cgit/security-development-tools/core-secdev-k3/tree/scripts/secure-binary-image.sh > ifeq ($(CONFIG_TI_SECURE_DEVICE),y) > SPL_ITS := u-boot-spl-k3_HS.its > $(SPL_ITS): export IS_HS=1 > @@ -98,9 +99,11 @@ cmd_k3_mkits = \ > $(SPL_ITS): FORCE > $(call cmd,k3_mkits) > endif > +endif > > else > > +ifndef CONFIG_TARGET_J721E_A72_EVM > ifeq ($(CONFIG_TI_SECURE_DEVICE),y) > INPUTS-y += u-boot.img_HS > else > @@ -108,4 +111,6 @@ INPUTS-y += u-boot.img > endif > endif > > +endif > + You will have to enclose below line in #ifndef CONFIG_BINMAN as well. > include $(srctree)/arch/arm/mach-k3/config_secure.mk > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index f047d4e094..6104cb8587 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -591,6 +591,8 @@ $(obj)/$(SPL_BIN).multidtb.fit.lzo: > $(obj)/$(SPL_BIN).multidtb.fit > @lzop -f9 $< > $@ > > ifdef CONFIG_ARCH_K3 > +ifndef CONFIG_TARGET_J721E_A72_EVM Is this still being called in-spite of the changes to config.mk? Please use CONFIG_BINMAN instead of CONFIG_TARGET_J721E_A72_EVM > tispl.bin: $(obj)/u-boot-spl-nodtb.bin $(SHRUNK_ARCH_DTB) $(SPL_ITS) FORCE > $(call if_changed,mkfitimage) > endif > +endif cheers, -roger
Re: [u-boot PATCH 2/3] tools/fdtgrep: Include __symbols__ table
On 10/06/2022 16:42, Tom Rini wrote: > On Mon, May 09, 2022 at 10:29:35AM +0300, Roger Quadros wrote: > >> This is required for overlays to work at SPL. >> >> Signed-off-by: Roger Quadros > > This breaks booting my dra7xx_evm and I get no output in SPL. > Thanks for checking. I'll try to debug what's wrong using beagle_x15. Is SPL size increase to blame? Maybe we should enable this only based on some config symbol? cheers, -roger
Re: [PATCH RFC v2 11/11] ti: dtsi: j721e: Use binman to package tispl.bin
On 01/06/2022 15:47, Andrew Davis wrote:
> On 6/1/22 5:55 AM, Roger Quadros wrote:
>>
>>
>> On 01/06/2022 13:42, Neha Malcom Francis wrote:
>>> Hi Roger,
>>>
>>> On 01/06/22 14:53, Roger Quadros wrote:
>>>> Hi,
>>>>
>>>> On 01/06/2022 09:08, Neha Malcom Francis wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On 31/05/22 16:32, Roger Quadros wrote:
>>>>>>
>>>>>>
>>>>>> On 06/05/2022 07:37, Neha Malcom Francis wrote:
>>>>>>> Explicit make commands were earlier used to generate tispl.bin image,
>>>>>>> now it is replaced using binman.
>>>>>>>
>>>>>>> Binman picks up and packages entries according to the description of
>>>>>>> entries given in the binman node in the device tree. The make commands
>>>>>>> that were earlier responsible for generating tispl.bin has been removed.
>>>>>>>
>>>>>>> k3-j721e-a72-binman.dtsi has been introduced for A72 specific binman
>>>>>>> node.
>>>>>>> It can be included in files that require it like
>>>>>>> k3-j721e-common-proc-board-u-boot.dtsi.
>>>>>>>
>>>>>>> Note that make commands for secure devices has also been removed as
>>>>>>> focus is on general purpose devices at present time.
>>>>>>>
>>>>>>> Signed-off-by: Tarun Sahu
>>>>>>> [n-fran...@ti.com: prepared patch for upstreaming]
>>>>>>> Signed-off-by: Neha Malcom Francis
>>>>>>> ---
>>>>>>> arch/arm/dts/k3-j721e-a72-binman.dtsi | 86
>>>>>>> +++
>>>>>>> .../k3-j721e-common-proc-board-u-boot.dtsi | 1 +
>>>>>>> arch/arm/mach-k3/config.mk | 33 ---
>>>>>>> board/ti/j721e/Kconfig | 1 +
>>>>>>> scripts/Makefile.spl | 4 -
>>>>>>> 5 files changed, 88 insertions(+), 37 deletions(-)
>>>>>>> create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>>>>>
>>>>>>> diff --git a/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>>>>> b/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>>>>> new file mode 100644
>>>>>>> index 00..beb3424bb9
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>>>>> @@ -0,0 +1,86 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>> +// Copyright (C) 2022 Texas Instruments Incorporated -
>>>>>>> https://www.ti.com/
>>>>>>> +
>>>>>>> +#include
>>>>>>> +
>>>>>>> +#ifdef CONFIG_ARM64
>>>>>>> +/ {
>>>>>>> + binman: binman {
>>>>>>> + multiple-images;
>>>>>>> + };
>>>>>>> +};
>>>>>>> +
>>>>>>> + {
>>>>>>> + tispl {
>>>>>>> + filename = "tispl.bin";
>>>>>>> + fit {
>>>>>>> + description = "FIT IMAGE";
>>>>>>> + #address-cells = <1>;
>>>>>>> + images {
>>>>>>> + atf {
>>>>>>> + description = "ARM Trusted Firmware";
>>>>>>> + type = "firmware";
>>>>>>> + arch = "arm64";
>>>>>>> + compression = "none";
>>>>>>> + os = "arm-trusted-firmware";
>>>>>>> + load = ;
>>>>>>> + entry = ;
>>>>>>> + atf-bl31 {
>>>>>>> + };
>>>>>>> + };
>>>>>>> + tee {
>>>>>>> + description = "OPTEE";
>>>>>>> + type = "tee";
>>>>>>> + arch = "
Re: [PATCH RFC v2 11/11] ti: dtsi: j721e: Use binman to package tispl.bin
On 01/06/2022 13:42, Neha Malcom Francis wrote:
> Hi Roger,
>
> On 01/06/22 14:53, Roger Quadros wrote:
>> Hi,
>>
>> On 01/06/2022 09:08, Neha Malcom Francis wrote:
>>> Hi Roger,
>>>
>>> On 31/05/22 16:32, Roger Quadros wrote:
>>>>
>>>>
>>>> On 06/05/2022 07:37, Neha Malcom Francis wrote:
>>>>> Explicit make commands were earlier used to generate tispl.bin image,
>>>>> now it is replaced using binman.
>>>>>
>>>>> Binman picks up and packages entries according to the description of
>>>>> entries given in the binman node in the device tree. The make commands
>>>>> that were earlier responsible for generating tispl.bin has been removed.
>>>>>
>>>>> k3-j721e-a72-binman.dtsi has been introduced for A72 specific binman node.
>>>>> It can be included in files that require it like
>>>>> k3-j721e-common-proc-board-u-boot.dtsi.
>>>>>
>>>>> Note that make commands for secure devices has also been removed as
>>>>> focus is on general purpose devices at present time.
>>>>>
>>>>> Signed-off-by: Tarun Sahu
>>>>> [n-fran...@ti.com: prepared patch for upstreaming]
>>>>> Signed-off-by: Neha Malcom Francis
>>>>> ---
>>>>> arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 +++
>>>>> .../k3-j721e-common-proc-board-u-boot.dtsi | 1 +
>>>>> arch/arm/mach-k3/config.mk | 33 ---
>>>>> board/ti/j721e/Kconfig | 1 +
>>>>> scripts/Makefile.spl | 4 -
>>>>> 5 files changed, 88 insertions(+), 37 deletions(-)
>>>>> create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>>>
>>>>> diff --git a/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>>> b/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>>> new file mode 100644
>>>>> index 00..beb3424bb9
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>>> @@ -0,0 +1,86 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>> +// Copyright (C) 2022 Texas Instruments Incorporated -
>>>>> https://www.ti.com/
>>>>> +
>>>>> +#include
>>>>> +
>>>>> +#ifdef CONFIG_ARM64
>>>>> +/ {
>>>>> + binman: binman {
>>>>> + multiple-images;
>>>>> + };
>>>>> +};
>>>>> +
>>>>> + {
>>>>> + tispl {
>>>>> + filename = "tispl.bin";
>>>>> + fit {
>>>>> + description = "FIT IMAGE";
>>>>> + #address-cells = <1>;
>>>>> + images {
>>>>> + atf {
>>>>> + description = "ARM Trusted Firmware";
>>>>> + type = "firmware";
>>>>> + arch = "arm64";
>>>>> + compression = "none";
>>>>> + os = "arm-trusted-firmware";
>>>>> + load = ;
>>>>> + entry = ;
>>>>> + atf-bl31 {
>>>>> + };
>>>>> + };
>>>>> + tee {
>>>>> + description = "OPTEE";
>>>>> + type = "tee";
>>>>> + arch = "arm64";
>>>>> + compression = "none";
>>>>> + os = "tee";
>>>>> + load = <0x9e80>;
>>>>> + entry = <0x9e80>;
>>>>> + tee-os {
>>>>> + };
>>>>> + };
>>>>> + dm {
>>>>> + description = "DM binary";
>>>>> + type = "firmware";
>>>>> + arch = "arm32";
>>>>> + compression = "none";
>&
Re: [PATCH RFC v2 05/11] ti: etype: x509: Add etype for x509 certificate for K3 devices
Neha, On 01/06/2022 12:48, Neha Malcom Francis wrote: > Hi Roger, > > On 01/06/22 14:54, Roger Quadros wrote: >> >> >> On 01/06/2022 09:02, Neha Malcom Francis wrote: >>> Hi Roger, >>> >>> On 31/05/22 14:50, Roger Quadros wrote: >>>> >>>> >>>> On 06/05/2022 07:37, Neha Malcom Francis wrote: >>>>> K3 devices x509 certificate added to certain binaries that allows ROM to >>>> >>>> what binaries? >>>> >>>>> validate the integrity of the image. Etype that generates an x509 >>>>> certificate depending on boot flow added. >>>> >>>> Could you please explain in more detail as to what exactly is happening >>>> here. >>>> >>>> What do you mean by "depending on boot flow"? >>>> >>> >>> I will reformat the commit messages accordingly. >>>>> >>>>> Signed-off-by: Neha Malcom Francis >>>>> --- >>>>> tools/binman/entries.rst | 15 ++ >>>>> tools/binman/etype/x509_cert.py | 248 >>>>> tools/binman/ftest.py | 7 + >>>>> tools/binman/test/232_x509_cert.dts | 18 ++ >>>>> tools/k3_gen_x509_cert.sh | 10 +- >>>>> 5 files changed, 293 insertions(+), 5 deletions(-) >>>>> create mode 100644 tools/binman/etype/x509_cert.py >>>>> create mode 100644 tools/binman/test/232_x509_cert.dts >>>>> >>>>> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst >>>>> index 0c6d82fce8..dfa281e49f 100644 >>>>> --- a/tools/binman/entries.rst >>>>> +++ b/tools/binman/entries.rst >>>>> @@ -1890,6 +1890,21 @@ and kernel are genuine. >>>>> +Entry: x509cert: x509 certificate for K3 devices >>>>> + >>>>> + >>>> >>>> x509 is a generic standard. Can this be made usable by other vendors as >>>> well or >>>> is it very specific to TI? >>>> If this is TI specific then I'd suggest a "ti-" prefix to the entry name. >>>> >>>>> +Properties / Entry arguments: >>>>> + - content: Phandle of binary to sign >>>>> + - output: Name of the final output file >>>> >>>> why do you need output property? >>>> >>> >>> That is not required, I had later changed it to always using >>> certificate.bin. Will make the necessary changes. >>> >>>>> + - key_file: File with key inside it. If not provided, script >>>>> generates RSA degenerate key >>>>> + - core: Target core ID on which image would be running >>>>> + - load: Target load address of the binary in hex >>>>> + >>>>> + Output files: >>>>> + - certificate.bin: Signed certificate binary >>>>> + >>>>> + >>>>> + >>>>> Entry: x86-reset16: x86 16-bit reset code for U-Boot >>>>> >>>>> diff --git a/tools/binman/etype/x509_cert.py >>>>> b/tools/binman/etype/x509_cert.py >>>>> new file mode 100644 >>>>> index 00..0009973155 >>>>> --- /dev/null >>>>> +++ b/tools/binman/etype/x509_cert.py >>>>> @@ -0,0 +1,248 @@ >>>>> +# SPDX-License-Identifier: GPL-2.0+ >>>>> +# Copyright (c) 2018 Google, Inc >>>>> +# Written by Simon Glass >>>>> +# >>>>> + >>>>> +# Support for a x509 certificate for signing K3 devices >>>>> + >>>>> +import os >>>>> +from collections import OrderedDict >>>>> +from subprocess import Popen, PIPE >>>>> +from sys import stderr, stdout >>>>> + >>>>> +import asn1 >>>>> +from Crypto.PublicKey import RSA >>>>> +from cryptography.hazmat.backends import default_backend >>>>> +from cryptography.hazmat.primitives import serialization >>>>> + >>>>> +from binman.etype.collection import Entry_collection >>>>> +from dtoc import fdt_util >>>>> +from patman import tools >>>>> + >>>>>
Re: [PATCH RFC v2 03/11] ti: etype: sysfw: Add entry type for sysfw
On 01/06/2022 08:58, Neha Malcom Francis wrote:
> Hi Roger,
>
> On 31/05/22 14:14, Roger Quadros wrote:
>>
>>
>> On 06/05/2022 07:37, Neha Malcom Francis wrote:
>>> For K3 devices that require a sysfw image, add entry for SYSFW. It can
>>
>> 'can' or 'should'?
>>
>> For binman, 'sysfw' and 'dm' (added in patch 4) are just binary blobs.
>> correct?
>> Why can't you just use blob entry type?
>>
> This was suggested so that there is space for changes that will be required
> when scaling to High Security devices as well.
How will these change for High Security devices?
cheers,
-roger
>
>>> contain system firmware image that can be packaged into sysfw.itb by
>>> binman.
>>>
>>> Signed-off-by: Tarun Sahu
>>> [n-fran...@ti.com: added tests for addition of etype]
>>> Signed-off-by: Neha Malcom Francis
>>
>> cheers,
>> -roger
>>
>>> ---
>>> Makefile | 1 +
>>> tools/binman/entries.rst | 11 +++
>>> tools/binman/etype/ti_sysfw.py | 28
>>> tools/binman/ftest.py | 7 +++
>>> tools/binman/test/232_ti_sysfw.dts | 13 +
>>> 5 files changed, 60 insertions(+)
>>> create mode 100644 tools/binman/etype/ti_sysfw.py
>>> create mode 100644 tools/binman/test/232_ti_sysfw.dts
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 4b347d3603..581fbba4c3 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1338,6 +1338,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
>>> $(BINMAN_DEBUG),-D) \
>>> -a opensbi-path=${OPENSBI} \
>>> -a default-dt=$(default_dt) \
>>> -a scp-path=$(SCP) \
>>> + -a ti-sysfw-path=$(SYSFW) \
>>> -a spl-bss-pad=$(if $(CONFIG_SPL_SEPARATE_BSS),,1) \
>>> -a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
>>> -a spl-dtb=$(CONFIG_SPL_OF_REAL) \
>>> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
>>> index ae4305c99e..6c0f03b34f 100644
>>> --- a/tools/binman/entries.rst
>>> +++ b/tools/binman/entries.rst
>>> @@ -1203,6 +1203,17 @@ This entry holds firmware for an external
>>> platform-specific coprocessor.
>>> +Entry: sysfw: Texas Instruments System Firmware (SYSFW) blob
>>> +
>>> +
>>> +Properties / Entry arguments:
>>> + - ti-sysfw-path: Filename of file to read into the entry, typically
>>> sysfw.bin
>>> +
>>> +This entry contains system firmware necessary for booting of K3
>>> architecture
>>> +devices.
>>> +
>>> +
>>> +
>>> Entry: section: Entry that contains other entries
>>> -
>>> diff --git a/tools/binman/etype/ti_sysfw.py
>>> b/tools/binman/etype/ti_sysfw.py
>>> new file mode 100644
>>> index 00..5b5b307030
>>> --- /dev/null
>>> +++ b/tools/binman/etype/ti_sysfw.py
>>> @@ -0,0 +1,28 @@
>>> +# SPDX-License-Identifier: GPL-2.0+
>>> +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
>>> +#
>>> +# Entry type module for TI SYSFW binary blob
>>> +#
>>> +
>>> +import os
>>> +import struct
>>> +import sys
>>> +import zlib
>>> +
>>> +from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
>>> +from dtoc import fdt_util
>>> +from patman import tools
>>> +
>>> +
>>> +class Entry_ti_sysfw(Entry_blob_named_by_arg):
>>> + """Entry containing Texas Instruments System Firmware (SYSFW) blob
>>> +
>>> + Properties / Entry arguments:
>>> + - ti-sysfw-path: Filename of file to read into the entry,
>>> typically sysfw.bin
>>> +
>>> + This entry contains system firmware necessary for booting of K3
>>> architecture devices.
>>> + """
>>> +
>>> + def __init__(self, section, etype, node):
>>> + super().__init__(section, etype, node, 'ti-sysfw')
>>> + self.external = True
>>> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
>>> index 4ce181a066..ec408de334 100644
>>> --- a/tools/binman/ftest.py
>>> +++ b/tools/binman/ftest.py
>>> @@ -87,6 +
Re: [PATCH RFC v2 05/11] ti: etype: x509: Add etype for x509 certificate for K3 devices
On 01/06/2022 09:02, Neha Malcom Francis wrote: > Hi Roger, > > On 31/05/22 14:50, Roger Quadros wrote: >> >> >> On 06/05/2022 07:37, Neha Malcom Francis wrote: >>> K3 devices x509 certificate added to certain binaries that allows ROM to >> >> what binaries? >> >>> validate the integrity of the image. Etype that generates an x509 >>> certificate depending on boot flow added. >> >> Could you please explain in more detail as to what exactly is happening here. >> >> What do you mean by "depending on boot flow"? >> > > I will reformat the commit messages accordingly. >>> >>> Signed-off-by: Neha Malcom Francis >>> --- >>> tools/binman/entries.rst | 15 ++ >>> tools/binman/etype/x509_cert.py | 248 >>> tools/binman/ftest.py | 7 + >>> tools/binman/test/232_x509_cert.dts | 18 ++ >>> tools/k3_gen_x509_cert.sh | 10 +- >>> 5 files changed, 293 insertions(+), 5 deletions(-) >>> create mode 100644 tools/binman/etype/x509_cert.py >>> create mode 100644 tools/binman/test/232_x509_cert.dts >>> >>> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst >>> index 0c6d82fce8..dfa281e49f 100644 >>> --- a/tools/binman/entries.rst >>> +++ b/tools/binman/entries.rst >>> @@ -1890,6 +1890,21 @@ and kernel are genuine. >>> +Entry: x509cert: x509 certificate for K3 devices >>> + >>> + >> >> x509 is a generic standard. Can this be made usable by other vendors as well >> or >> is it very specific to TI? >> If this is TI specific then I'd suggest a "ti-" prefix to the entry name. >> >>> +Properties / Entry arguments: >>> + - content: Phandle of binary to sign >>> + - output: Name of the final output file >> >> why do you need output property? >> > > That is not required, I had later changed it to always using certificate.bin. > Will make the necessary changes. > >>> + - key_file: File with key inside it. If not provided, script >>> generates RSA degenerate key >>> + - core: Target core ID on which image would be running >>> + - load: Target load address of the binary in hex >>> + >>> + Output files: >>> + - certificate.bin: Signed certificate binary >>> + >>> + >>> + >>> Entry: x86-reset16: x86 16-bit reset code for U-Boot >>> >>> diff --git a/tools/binman/etype/x509_cert.py >>> b/tools/binman/etype/x509_cert.py >>> new file mode 100644 >>> index 00..0009973155 >>> --- /dev/null >>> +++ b/tools/binman/etype/x509_cert.py >>> @@ -0,0 +1,248 @@ >>> +# SPDX-License-Identifier: GPL-2.0+ >>> +# Copyright (c) 2018 Google, Inc >>> +# Written by Simon Glass >>> +# >>> + >>> +# Support for a x509 certificate for signing K3 devices >>> + >>> +import os >>> +from collections import OrderedDict >>> +from subprocess import Popen, PIPE >>> +from sys import stderr, stdout >>> + >>> +import asn1 >>> +from Crypto.PublicKey import RSA >>> +from cryptography.hazmat.backends import default_backend >>> +from cryptography.hazmat.primitives import serialization >>> + >>> +from binman.etype.collection import Entry_collection >>> +from dtoc import fdt_util >>> +from patman import tools >>> + >>> +temp_x509 = "x509-temp.cert" >>> +cert = "certificate.bin" >>> +rand_key = "eckey.pem" >>> +bootcore_opts = 0 >>> +bootcore = 0 >>> +debug_type = 0 >>> + >>> + >>> +class Entry_x509_cert(Entry_collection): >>> + """ An entry which contains a x509 certificate >>> + >>> + Properties / Entry arguments: >>> + - content: Phandle of binary to sign >>> + - key_file: File with key inside it. If not provided, script >>> generates RSA degenerate key >>> + - core: Target core ID on which image would be running >>> + - load: Target load address of the binary in hex >>> + >>> + Output files: >>> + - certificate.bin: Signed certificate binary""" >>> + >
Re: [PATCH RFC v2 11/11] ti: dtsi: j721e: Use binman to package tispl.bin
Hi,
On 01/06/2022 09:08, Neha Malcom Francis wrote:
> Hi Roger,
>
> On 31/05/22 16:32, Roger Quadros wrote:
>>
>>
>> On 06/05/2022 07:37, Neha Malcom Francis wrote:
>>> Explicit make commands were earlier used to generate tispl.bin image,
>>> now it is replaced using binman.
>>>
>>> Binman picks up and packages entries according to the description of
>>> entries given in the binman node in the device tree. The make commands
>>> that were earlier responsible for generating tispl.bin has been removed.
>>>
>>> k3-j721e-a72-binman.dtsi has been introduced for A72 specific binman node.
>>> It can be included in files that require it like
>>> k3-j721e-common-proc-board-u-boot.dtsi.
>>>
>>> Note that make commands for secure devices has also been removed as
>>> focus is on general purpose devices at present time.
>>>
>>> Signed-off-by: Tarun Sahu
>>> [n-fran...@ti.com: prepared patch for upstreaming]
>>> Signed-off-by: Neha Malcom Francis
>>> ---
>>> arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 +++
>>> .../k3-j721e-common-proc-board-u-boot.dtsi | 1 +
>>> arch/arm/mach-k3/config.mk | 33 ---
>>> board/ti/j721e/Kconfig | 1 +
>>> scripts/Makefile.spl | 4 -
>>> 5 files changed, 88 insertions(+), 37 deletions(-)
>>> create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi
>>>
>>> diff --git a/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>> b/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>> new file mode 100644
>>> index 00..beb3424bb9
>>> --- /dev/null
>>> +++ b/arch/arm/dts/k3-j721e-a72-binman.dtsi
>>> @@ -0,0 +1,86 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
>>> +
>>> +#include
>>> +
>>> +#ifdef CONFIG_ARM64
>>> +/ {
>>> + binman: binman {
>>> + multiple-images;
>>> + };
>>> +};
>>> +
>>> + {
>>> + tispl {
>>> + filename = "tispl.bin";
>>> + fit {
>>> + description = "FIT IMAGE";
>>> + #address-cells = <1>;
>>> + images {
>>> + atf {
>>> + description = "ARM Trusted Firmware";
>>> + type = "firmware";
>>> + arch = "arm64";
>>> + compression = "none";
>>> + os = "arm-trusted-firmware";
>>> + load = ;
>>> + entry = ;
>>> + atf-bl31 {
>>> + };
>>> + };
>>> + tee {
>>> + description = "OPTEE";
>>> + type = "tee";
>>> + arch = "arm64";
>>> + compression = "none";
>>> + os = "tee";
>>> + load = <0x9e80>;
>>> + entry = <0x9e80>;
>>> + tee-os {
>>> + };
>>> + };
>>> + dm {
>>> + description = "DM binary";
>>> + type = "firmware";
>>> + arch = "arm32";
>>> + compression = "none";
>>> + os = "DM";
>>> + load = <0x8900>;
>>> + entry = <0x8900>;
>>> + ti-dm {
>>> + };
>>> + };
>>> + spl {
>>> + description = "SPL (64-bit)";
>>> + type = "standalone";
>>> + os = "U-Boot";
>>> + arch = "arm64";
>>> + compression = "none";
>>> + load = ;
>>> + entry = ;
>>> + u-boot-spl-nodtb {
>>> + };
>>> + };
>>> + k3
Re: [PATCH RFC v2 11/11] ti: dtsi: j721e: Use binman to package tispl.bin
On 06/05/2022 07:37, Neha Malcom Francis wrote:
> Explicit make commands were earlier used to generate tispl.bin image,
> now it is replaced using binman.
>
> Binman picks up and packages entries according to the description of
> entries given in the binman node in the device tree. The make commands
> that were earlier responsible for generating tispl.bin has been removed.
>
> k3-j721e-a72-binman.dtsi has been introduced for A72 specific binman node.
> It can be included in files that require it like
> k3-j721e-common-proc-board-u-boot.dtsi.
>
> Note that make commands for secure devices has also been removed as
> focus is on general purpose devices at present time.
>
> Signed-off-by: Tarun Sahu
> [n-fran...@ti.com: prepared patch for upstreaming]
> Signed-off-by: Neha Malcom Francis
> ---
> arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 +++
> .../k3-j721e-common-proc-board-u-boot.dtsi| 1 +
> arch/arm/mach-k3/config.mk| 33 ---
> board/ti/j721e/Kconfig| 1 +
> scripts/Makefile.spl | 4 -
> 5 files changed, 88 insertions(+), 37 deletions(-)
> create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi
>
> diff --git a/arch/arm/dts/k3-j721e-a72-binman.dtsi
> b/arch/arm/dts/k3-j721e-a72-binman.dtsi
> new file mode 100644
> index 00..beb3424bb9
> --- /dev/null
> +++ b/arch/arm/dts/k3-j721e-a72-binman.dtsi
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +
> +#include
> +
> +#ifdef CONFIG_ARM64
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +};
> +
> + {
> + tispl {
> + filename = "tispl.bin";
> + fit {
> + description = "FIT IMAGE";
> + #address-cells = <1>;
> + images {
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + os = "arm-trusted-firmware";
> + load = ;
> + entry = ;
> + atf-bl31 {
> + };
> + };
> + tee {
> + description = "OPTEE";
> + type = "tee";
> + arch = "arm64";
> + compression = "none";
> + os = "tee";
> + load = <0x9e80>;
> + entry = <0x9e80>;
> + tee-os {
> + };
> + };
> + dm {
> + description = "DM binary";
> + type = "firmware";
> + arch = "arm32";
> + compression = "none";
> + os = "DM";
> + load = <0x8900>;
> + entry = <0x8900>;
> + ti-dm {
> + };
> + };
> + spl {
> + description = "SPL (64-bit)";
> + type = "standalone";
> + os = "U-Boot";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> + entry = ;
> + u-boot-spl-nodtb {
> + };
> + };
> + k3-j721e-common-proc-board.dtb {
> + description =
> "k3-j721e-common-proc-board";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + blob-ext {
> + filename =
> "spl/dts/k3-j721e-common-proc-board.dtb";
> + };
> + };
> + };
> + configurations {
> + default = "conf";
> + conf {
> +
Re: [PATCH RFC v2 09/11] ti: x509: Remove shell script used for signing
On 06/05/2022 07:37, Neha Malcom Francis wrote:
> Earlier the k3_gen_x509_cert.sh was used for signing binaries with the
> x509 certificate for Texas Instruments K3 architecture devices. Since
> the signing process is handled by x509 etype now, there is no more
> requirement for this script, hence removing it.
Are you sure this script is not required for any Keystone platforms?
If not, let's just leave it there.
cheers,
-roger
>
> Signed-off-by: Neha Malcom Francis
> ---
> tools/k3_gen_x509_cert.sh | 252 --
> 1 file changed, 252 deletions(-)
> delete mode 100755 tools/k3_gen_x509_cert.sh
>
> diff --git a/tools/k3_gen_x509_cert.sh b/tools/k3_gen_x509_cert.sh
> deleted file mode 100755
> index b6ef5a2de3..00
> --- a/tools/k3_gen_x509_cert.sh
> +++ /dev/null
> @@ -1,252 +0,0 @@
> -#!/bin/bash
> -# SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> -#
> -# Script to add K3 specific x509 cetificate to a binary.
> -#
> -
> -# Variables
> -OUTPUT=tiboot3.bin
> -TEMP_X509=x509-temp.cert
> -CERT=certificate.bin
> -RAND_KEY=eckey.pem
> -LOADADDR=0x41c0
> -BOOTCORE_OPTS=0
> -BOOTCORE=16
> -DEBUG_TYPE=0
> -
> -gen_degen_template() {
> -cat << 'EOF' > degen-template.txt
> -
> -asn1=SEQUENCE:rsa_key
> -
> -[rsa_key]
> -version=INTEGER:0
> -modulus=INTEGER:0xDEGEN_MODULUS
> -pubExp=INTEGER:1
> -privExp=INTEGER:1
> -p=INTEGER:0xDEGEN_P
> -q=INTEGER:0xDEGEN_Q
> -e1=INTEGER:1
> -e2=INTEGER:1
> -coeff=INTEGER:0xDEGEN_COEFF
> -EOF
> -}
> -
> -# Generate x509 Template
> -gen_template() {
> -cat << 'EOF' > x509-template.txt
> - [ req ]
> - distinguished_name = req_distinguished_name
> - x509_extensions= v3_ca
> - prompt = no
> - dirstring_type = nobmp
> -
> - [ req_distinguished_name ]
> - C = US
> - ST = TX
> - L = Dallas
> - O = Texas Instruments Incorporated
> - OU = Processors
> - CN = TI support
> - emailAddress = supp...@ti.com
> -
> - [ v3_ca ]
> - basicConstraints = CA:true
> - 1.3.6.1.4.1.294.1.1 = ASN1:SEQUENCE:boot_seq
> - 1.3.6.1.4.1.294.1.2 = ASN1:SEQUENCE:image_integrity
> - 1.3.6.1.4.1.294.1.3 = ASN1:SEQUENCE:swrv
> -# 1.3.6.1.4.1.294.1.4 = ASN1:SEQUENCE:encryption
> - 1.3.6.1.4.1.294.1.8 = ASN1:SEQUENCE:debug
> -
> - [ boot_seq ]
> - certType = INTEGER:TEST_CERT_TYPE
> - bootCore = INTEGER:TEST_BOOT_CORE
> - bootCoreOpts = INTEGER:TEST_BOOT_CORE_OPTS
> - destAddr = FORMAT:HEX,OCT:TEST_BOOT_ADDR
> - imageSize = INTEGER:TEST_IMAGE_LENGTH
> -
> - [ image_integrity ]
> - shaType = OID:2.16.840.1.101.3.4.2.3
> - shaValue = FORMAT:HEX,OCT:TEST_IMAGE_SHA_VAL
> -
> - [ swrv ]
> - swrv = INTEGER:0
> -
> -# [ encryption ]
> -# initalVector = FORMAT:HEX,OCT:TEST_IMAGE_ENC_IV
> -# randomString = FORMAT:HEX,OCT:TEST_IMAGE_ENC_RS
> -# iterationCnt = INTEGER:TEST_IMAGE_KEY_DERIVE_INDEX
> -# salt = FORMAT:HEX,OCT:TEST_IMAGE_KEY_DERIVE_SALT
> -
> - [ debug ]
> - debugUID =
> FORMAT:HEX,OCT:
> - debugType = INTEGER:TEST_DEBUG_TYPE
> - coreDbgEn = INTEGER:0
> - coreDbgSecEn = INTEGER:0
> -EOF
> -}
> -
> -parse_key() {
> - sed '/\ \ \ \ /s/://g' key.txt | awk '!/\ \ \ \ / {printf("\n%s\n",
> $0)}; /\ \ \ \ / {printf("%s", $0)}' | sed 's/\ \ \ \ //g' | awk
> "/$1:/{getline; print}"
> -}
> -
> -gen_degen_key() {
> -# Generate a 4096 bit RSA Key
> - openssl genrsa -out key.pem 1024 >>/dev/null 2>&1
> - openssl rsa -in key.pem -text -out key.txt >>/dev/null 2>&1
> - DEGEN_MODULUS=$( parse_key 'modulus' )
> - DEGEN_P=$( parse_key 'prime1' )
> - DEGEN_Q=$( parse_key 'prime2' )
> - DEGEN_COEFF=$( parse_key 'coefficient' )
> - gen_degen_template
> -
> - sed -e "s/DEGEN_MODULUS/$DEGEN_MODULUS/"\
> - -e "s/DEGEN_P/$DEGEN_P/" \
> - -e "s/DEGEN_Q/$DEGEN_Q/" \
> - -e "s/DEGEN_COEFF/$DEGEN_COEFF/" \
> - degen-template.txt > degenerateKey.txt
> -
> - openssl asn1parse -genconf degenerateKey.txt -out degenerateKey.der
> >>/dev/null 2>&1
> - openssl rsa -in degenerateKey.der -inform DER -outform PEM -out
> $RAND_KEY >>/dev/null 2>&1
> - KEY=$RAND_KEY
> - #rm key.pem key.txt degen-template.txt degenerateKey.txt
> degenerateKey.der
> -}
> -
> -declare -A options_help
> -usage() {
> - if [ -n "$*" ]; then
> - echo "ERROR: $*"
> - fi
> - echo -n "Usage: $0 "
> - for option in "${!options_help[@]}"
> - do
> - arg=`echo ${options_help[$option]}|cut -d ':' -f1`
> - if [ -n "$arg" ]; then
> - arg=" $arg"
> - fi
> - echo -n "[-$option$arg] "
> - done
> - echo
> - echo -e "\nWhere:"
> - for option in "${!options_help[@]}"
> - do
> - arg=`echo ${options_help[$option]}|cut -d ':' -f1`
> - txt=`echo
Re: [PATCH RFC v2 08/11] ti: tispl.bin: Removed script that packages tispl.bin
On 06/05/2022 07:37, Neha Malcom Francis wrote:
> As tispl.bin is to be packaged (with ATF, OPTEE, DM and A72 SPL) using
> binman, the shell script k3_fit_atf.sh is no longer needed. Removing
This is not true until you have migrated all K3 platforms to use binman.
So let's leave this script here for now.
> this file.
>
> Signed-off-by: Neha Malcom Francis
cheers,
-roger
> ---
> tools/k3_fit_atf.sh | 123
> 1 file changed, 123 deletions(-)
> delete mode 100755 tools/k3_fit_atf.sh
>
> diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
> deleted file mode 100755
> index 7bc07ad074..00
> --- a/tools/k3_fit_atf.sh
> +++ /dev/null
> @@ -1,123 +0,0 @@
> -#!/bin/sh
> -# SPDX-License-Identifier: GPL-2.0+
> -#
> -# script to generate FIT image source for K3 Family boards with
> -# ATF, OPTEE, SPL and multiple device trees (given on the command line).
> -# Inspired from board/sunxi/mksunxi_fit_atf.sh
> -#
> -# usage: $0 [ [ -
> -[ -z "$ATF" ] && ATF="bl31.bin"
> -
> -if [ ! -f $ATF ]; then
> - echo "WARNING ATF file $ATF NOT found, resulting binary is
> non-functional" >&2
> - ATF=/dev/null
> -fi
> -
> -[ -z "$TEE" ] && TEE="bl32.bin"
> -
> -if [ ! -f $TEE ]; then
> - echo "WARNING OPTEE file $TEE NOT found, resulting might be
> non-functional" >&2
> - TEE=/dev/null
> -fi
> -
> -[ -z "$DM" ] && DM="dm.bin"
> -
> -if [ ! -e $DM ]; then
> - echo "WARNING DM file $DM NOT found, resulting might be non-functional"
> >&2
> - DM=/dev/null
> -fi
> -
> -if [ ! -z "$IS_HS" ]; then
> - HS_APPEND=_HS
> -fi
> -
> -cat << __HEADER_EOF
> -/dts-v1/;
> -
> -/ {
> - description = "Configuration to load ATF and SPL";
> - #address-cells = <1>;
> -
> - images {
> - atf {
> - description = "ARM Trusted Firmware";
> - data = /incbin/("$ATF");
> - type = "firmware";
> - arch = "arm64";
> - compression = "none";
> - os = "arm-trusted-firmware";
> - load = <$1>;
> - entry = <$1>;
> - };
> - tee {
> - description = "OPTEE";
> - data = /incbin/("$TEE");
> - type = "tee";
> - arch = "arm64";
> - compression = "none";
> - os = "tee";
> - load = <0x9e80>;
> - entry = <0x9e80>;
> - };
> - dm {
> - description = "DM binary";
> - data = /incbin/("$DM");
> - type = "firmware";
> - arch = "arm32";
> - compression = "none";
> - os = "DM";
> - load = <0x8900>;
> - entry = <0x8900>;
> - };
> - spl {
> - description = "SPL (64-bit)";
> - data = /incbin/("spl/u-boot-spl-nodtb.bin$HS_APPEND");
> - type = "standalone";
> - os = "U-Boot";
> - arch = "arm64";
> - compression = "none";
> - load = <0x8008>;
> - entry = <0x8008>;
> - };
> -__HEADER_EOF
> -
> -# shift through ATF load address in the command line arguments
> -shift
> -
> -for dtname in $*
> -do
> - cat << __FDT_IMAGE_EOF
> - $(basename $dtname) {
> - description = "$(basename $dtname .dtb)";
> - data = /incbin/("$dtname$HS_APPEND");
> - type = "flat_dt";
> - arch = "arm";
> - compression = "none";
> - };
> -__FDT_IMAGE_EOF
> -done
> -
> -cat << __CONF_HEADER_EOF
> - };
> - configurations {
> - default = "$(basename $1)";
> -
> -__CONF_HEADER_EOF
> -
> -for dtname in $*
> -do
> - cat << __CONF_SECTION_EOF
> - $(basename $dtname) {
> - description = "$(basename $dtname .dtb)";
> - firmware = "atf";
> - loadables = "tee", "dm", "spl";
> - fdt = "$(basename $dtname)";
> - };
> -__CONF_SECTION_EOF
> -done
> -
> -cat << __ITS_EOF
> - };
> -};
> -__ITS_EOF
Re: [PATCH RFC v2 07/11] ti: tiboot3.bin: Remove tiboot3.bin target from makefile
On 06/05/2022 07:37, Neha Malcom Francis wrote: > Intention of patch is to move the signing and packaging of tiboot3.bin > image to binman, thus removing target from makefile. > > Also deleting k3_gen_x509_cert.sh which was earlier used to sign a > binary associated with K3 devices with x509 certificate. This > functionality has been replicated in binman with the etype x509_cert. > > Signed-off-by: Neha Malcom Francis > --- > arch/arm/mach-k3/config.mk | 19 --- > 1 file changed, 19 deletions(-) > > diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk > index e6c13c1800..49f80ae79b 100644 > --- a/arch/arm/mach-k3/config.mk > +++ b/arch/arm/mach-k3/config.mk > @@ -46,25 +46,6 @@ INPUTS-y += sec-cfg.bin > endif > endif > > -# tiboot3.bin is mandated by ROM and ROM only supports R5 boot. > -# So restrict tiboot3.bin creation for CPU_V7R. > -ifdef CONFIG_CPU_V7R > -image_check: $(obj)/u-boot-spl.bin FORCE > - @if [ $(IMAGE_SIZE) -gt $(MAX_SIZE) ]; then \ > - echo "===" >&2; \ > - echo "ERROR: Final Image too big. " >&2;\ > - echo "$< size = $(IMAGE_SIZE), max size = $(MAX_SIZE)" >&2; \ > - echo "===" >&2; \ > - exit 1; \ > - fi > - > -tiboot3.bin: image_check FORCE > - $(srctree)/tools/k3_gen_x509_cert.sh -c 16 -b $(obj)/u-boot-spl.bin \ > - -o $@ -l $(CONFIG_SPL_TEXT_BASE) -k $(KEY) > - > -INPUTS-y += tiboot3.bin > -endif > - Instead of removing it unconditionally and breaking build for all this must be placed under #ifndef CONFIG_BINMAN ... #endif > ifdef CONFIG_ARM64 > > ifeq ($(CONFIG_SOC_K3_J721E),) cheers, -roger
Re: [PATCH RFC v2 05/11] ti: etype: x509: Add etype for x509 certificate for K3 devices
On 06/05/2022 07:37, Neha Malcom Francis wrote:
> K3 devices x509 certificate added to certain binaries that allows ROM to
what binaries?
> validate the integrity of the image. Etype that generates an x509
> certificate depending on boot flow added.
Could you please explain in more detail as to what exactly is happening here.
What do you mean by "depending on boot flow"?
>
> Signed-off-by: Neha Malcom Francis
> ---
> tools/binman/entries.rst| 15 ++
> tools/binman/etype/x509_cert.py | 248
> tools/binman/ftest.py | 7 +
> tools/binman/test/232_x509_cert.dts | 18 ++
> tools/k3_gen_x509_cert.sh | 10 +-
> 5 files changed, 293 insertions(+), 5 deletions(-)
> create mode 100644 tools/binman/etype/x509_cert.py
> create mode 100644 tools/binman/test/232_x509_cert.dts
>
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index 0c6d82fce8..dfa281e49f 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -1890,6 +1890,21 @@ and kernel are genuine.
>
>
>
> +Entry: x509cert: x509 certificate for K3 devices
> +
> +
x509 is a generic standard. Can this be made usable by other vendors as well or
is it very specific to TI?
If this is TI specific then I'd suggest a "ti-" prefix to the entry name.
> +Properties / Entry arguments:
> +- content: Phandle of binary to sign
> +- output: Name of the final output file
why do you need output property?
> +- key_file: File with key inside it. If not provided, script
> generates RSA degenerate key
> +- core: Target core ID on which image would be running
> +- load: Target load address of the binary in hex
> +
> +Output files:
> +- certificate.bin: Signed certificate binary
> +
> +
> +
> Entry: x86-reset16: x86 16-bit reset code for U-Boot
>
>
> diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
> new file mode 100644
> index 00..0009973155
> --- /dev/null
> +++ b/tools/binman/etype/x509_cert.py
> @@ -0,0 +1,248 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (c) 2018 Google, Inc
> +# Written by Simon Glass
> +#
> +
> +# Support for a x509 certificate for signing K3 devices
> +
> +import os
> +from collections import OrderedDict
> +from subprocess import Popen, PIPE
> +from sys import stderr, stdout
> +
> +import asn1
> +from Crypto.PublicKey import RSA
> +from cryptography.hazmat.backends import default_backend
> +from cryptography.hazmat.primitives import serialization
> +
> +from binman.etype.collection import Entry_collection
> +from dtoc import fdt_util
> +from patman import tools
> +
> +temp_x509 = "x509-temp.cert"
> +cert = "certificate.bin"
> +rand_key = "eckey.pem"
> +bootcore_opts = 0
> +bootcore = 0
> +debug_type = 0
> +
> +
> +class Entry_x509_cert(Entry_collection):
> +""" An entry which contains a x509 certificate
> +
> +Properties / Entry arguments:
> +- content: Phandle of binary to sign
> +- key_file: File with key inside it. If not provided, script
> generates RSA degenerate key
> +- core: Target core ID on which image would be running
> +- load: Target load address of the binary in hex
> +
> +Output files:
> +- certificate.bin: Signed certificate binary"""
> +
> +def __init__(self, section, etype, node):
> +super().__init__(section, etype, node)
> +self.key_file = fdt_util.GetString(self._node, 'key-file', "")
> +self.core = fdt_util.GetInt(self._node, 'core', 0)
> +self.load_addr = fdt_util.GetInt(self._node, 'load', 0x41c0)
> +
> +def ReadNode(self):
> +super().ReadNode()
> +if self.key_file == "":
> +self.degen_key = True
> +else:
> +self.degen_key = False
> +
> +def _CreateCertificate(self):
> +"""Create certificate for legacy boot flow"""
> +if self.degen_key == True:
> +gen_degen_key()
> +self.key_file = rand_key
> +
> +sha_val = get_sha_val("intermediate-sysfw.bin")
> +bin_size = get_file_size("intermediate-sysfw.bin")
> +addr = "%08x" % self.load_addr
> +if self.core == 0:
> +cert_type = 2
> +elif self.core == 16:
> +cert_type = 1
> +else:
> +cert_type = 2
> +debug_type = 0
> +
> +gen_template()
> +gen_cert(bin_size, sha_val, cert_type, bootcore_opts,
> + self.core, addr, debug_type, self.key_file)
> +
> +return tools.read_file("certificate.bin")
> +
> +def ObtainContents(self):
> +self.image = self.GetContents(False)
> +if self.image is None:
> +return False
> +f = open("intermediate-sysfw.bin", "wb")
> +f.write(self.image)
> +f.close()
> +
Re: [PATCH RFC v2 03/11] ti: etype: sysfw: Add entry type for sysfw
On 06/05/2022 07:37, Neha Malcom Francis wrote:
> For K3 devices that require a sysfw image, add entry for SYSFW. It can
'can' or 'should'?
For binman, 'sysfw' and 'dm' (added in patch 4) are just binary blobs. correct?
Why can't you just use blob entry type?
> contain system firmware image that can be packaged into sysfw.itb by
> binman.
>
> Signed-off-by: Tarun Sahu
> [n-fran...@ti.com: added tests for addition of etype]
> Signed-off-by: Neha Malcom Francis
cheers,
-roger
> ---
> Makefile | 1 +
> tools/binman/entries.rst | 11 +++
> tools/binman/etype/ti_sysfw.py | 28
> tools/binman/ftest.py | 7 +++
> tools/binman/test/232_ti_sysfw.dts | 13 +
> 5 files changed, 60 insertions(+)
> create mode 100644 tools/binman/etype/ti_sysfw.py
> create mode 100644 tools/binman/test/232_ti_sysfw.dts
>
> diff --git a/Makefile b/Makefile
> index 4b347d3603..581fbba4c3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1338,6 +1338,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
> $(BINMAN_DEBUG),-D) \
> -a opensbi-path=${OPENSBI} \
> -a default-dt=$(default_dt) \
> -a scp-path=$(SCP) \
> + -a ti-sysfw-path=$(SYSFW) \
> -a spl-bss-pad=$(if $(CONFIG_SPL_SEPARATE_BSS),,1) \
> -a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
> -a spl-dtb=$(CONFIG_SPL_OF_REAL) \
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index ae4305c99e..6c0f03b34f 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -1203,6 +1203,17 @@ This entry holds firmware for an external
> platform-specific coprocessor.
>
>
>
> +Entry: sysfw: Texas Instruments System Firmware (SYSFW) blob
> +
> +
> +Properties / Entry arguments:
> +- ti-sysfw-path: Filename of file to read into the entry, typically
> sysfw.bin
> +
> +This entry contains system firmware necessary for booting of K3 architecture
> +devices.
> +
> +
> +
> Entry: section: Entry that contains other entries
> -
>
> diff --git a/tools/binman/etype/ti_sysfw.py b/tools/binman/etype/ti_sysfw.py
> new file mode 100644
> index 00..5b5b307030
> --- /dev/null
> +++ b/tools/binman/etype/ti_sysfw.py
> @@ -0,0 +1,28 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +#
> +# Entry type module for TI SYSFW binary blob
> +#
> +
> +import os
> +import struct
> +import sys
> +import zlib
> +
> +from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
> +from dtoc import fdt_util
> +from patman import tools
> +
> +
> +class Entry_ti_sysfw(Entry_blob_named_by_arg):
> +"""Entry containing Texas Instruments System Firmware (SYSFW) blob
> +
> +Properties / Entry arguments:
> +- ti-sysfw-path: Filename of file to read into the entry, typically
> sysfw.bin
> +
> +This entry contains system firmware necessary for booting of K3
> architecture devices.
> +"""
> +
> +def __init__(self, section, etype, node):
> +super().__init__(section, etype, node, 'ti-sysfw')
> +self.external = True
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 4ce181a066..ec408de334 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -87,6 +87,7 @@ ATF_BL31_DATA = b'bl31'
> TEE_OS_DATA = b'this is some tee OS data'
> ATF_BL2U_DATA = b'bl2u'
> OPENSBI_DATA = b'opensbi'
> +TI_SYSFW_DATA = b'sysfw'
> SCP_DATA = b'scp'
> TEST_FDT1_DATA= b'fdt1'
> TEST_FDT2_DATA= b'test-fdt2'
> @@ -195,6 +196,7 @@ class TestFunctional(unittest.TestCase):
> TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
> TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
> TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
> +TestFunctional._MakeInputFile('sysfw.bin', TI_SYSFW_DATA)
> TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
>
> # Add a few .dtb files for testing
> @@ -5522,6 +5524,11 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> """Test an image with a pre-load header with an invalid key"""
> with self.assertRaises(ValueError) as e:
> data = self._DoReadFile('231_pre_load_invalid_key.dts')
> +
> +def testPackTiSysfw(self):
> +"""Test that an image with a SYSFW binary can be created"""
> +data = self._DoReadFile('232_ti_sysfw.dts')
> +self.assertEqual(TI_SYSFW_DATA, data[:len(TI_SYSFW_DATA)])
>
> if __name__ == "__main__":
> unittest.main()
> diff --git a/tools/binman/test/232_ti_sysfw.dts
> b/tools/binman/test/232_ti_sysfw.dts
> new file mode 100644
>
Re: [PATCH RFC v2 00/11] Integration of sysfw, tispl and tiboot3
Hi, On 06/05/2022 07:37, Neha Malcom Francis wrote: > Devices that belong to the K3 architecture require SYSFW which is a FIT > image consisting of a signed system firmware image and board config > binaries. > > Board config binaries are needed to bring up SYSFW during U-Boot SPL > startup. The board config data is given in YAML as input. These board > configs contain board-specific information such as resource management, > power management and security. > > The following series intends to plumb the system firmware generation > into U-Boot using binman for packaging. Thus it will eliminate the need > for additional custom repositories for SYSFW generation and also moves t > owards the community standard build flow. We use binman to package > tiboot3.bin and sysfw.itb images. > > These images also require x509 certificates which are created using the > etype x509-cert. > > The series also plumbs the generation of tispl.bin into the build flow. > This image is required for loading u-boot in K3 devices. The image is > packaged using ATF, OPTEE and DM (Device Manager). > > Please note that the following series has implemented the above for > J721E general purpose board. The board configs and device trees added > are specific to J721E GP devices. > > Also note the introduction of three new etypes: ti-sysfw, ti-dm and > x509-cert. > > On running CI tests on Github, errors were produced during world builds > of keystone2_keystone3 and siemens (I0T2050 which is based on AM65x). > This patch series is intended for only J721E and future work is to expand > to the remaining K3 devices as well. The errors that come are mainly due > to the boards other than J721E trying to generate tispl.bin. You will have to implement it such that none of the existing board build/functionality breaks. Otherwise it will be impossible to get this merged. Is this series tested for High-Security (HS) J721E as well? cheers, -roger > > v2: > - Added etype x509-cert for creating x509 Texas Instruments certificate > binary > - Added packaging of tiboot3.bin > - Packaging of tiboot3.bin and sysfw.itb using new etype x509 > - sysfw --> ti-sysfw > - Reformatted and re-arranged patches > - Removed k3_fit_atf.sh and k3_gen_x509_cert.sh as their functionality > is provided by binman now > > Neha Malcom Francis (11): > j721e_evm: schema: yaml: Add general schema and J721E board config > files > ti: tools: config: Add board config class to generate config binaries > ti: etype: sysfw: Add entry type for sysfw > ti: etype: dm: Add entry type for TI DM > ti: etype: x509: Add etype for x509 certificate for K3 devices > ti: sysfw: Add support for packaging sysfw.itb > ti: tiboot3.bin: Remove tiboot3.bin target from makefile > ti: tispl.bin: Removed script that packages tispl.bin > ti: x509: Remove shell script used for signing > ti: dtsi: j721e: Use binman to package sysfw.itb and tiboot3.bin > ti: dtsi: j721e: Use binman to package tispl.bin > > Makefile |2 + > arch/arm/dts/k3-j721e-a72-binman.dtsi | 86 + > .../k3-j721e-common-proc-board-u-boot.dtsi|1 + > arch/arm/dts/k3-j721e-r5-binman.dtsi | 88 + > .../k3-j721e-r5-common-proc-board-u-boot.dtsi |1 + > arch/arm/mach-k3/config.mk| 64 +- > board/ti/common/schema.yaml | 355 ++ > board/ti/j721e/Kconfig|2 + > board/ti/j721e/config.yaml| 3162 + > scripts/Makefile.spl |4 - > test/py/requirements.txt |1 + > tools/binman/entries.rst | 36 + > tools/binman/etype/ti_dm.py | 23 + > tools/binman/etype/ti_sysfw.py| 28 + > tools/binman/etype/x509_cert.py | 248 ++ > tools/binman/ftest.py | 21 + > tools/binman/test/225_ti_dm.dts | 13 + > tools/binman/test/232_ti_sysfw.dts| 13 + > tools/binman/test/232_x509_cert.dts | 18 + > tools/k3_fit_atf.sh | 123 - > tools/k3_gen_x509_cert.sh | 252 -- > tools/tibcfg_gen.py | 114 + > 22 files changed, 4227 insertions(+), 428 deletions(-) > create mode 100644 arch/arm/dts/k3-j721e-a72-binman.dtsi > create mode 100644 arch/arm/dts/k3-j721e-r5-binman.dtsi > create mode 100644 board/ti/common/schema.yaml > create mode 100644 board/ti/j721e/config.yaml > create mode 100644 tools/binman/etype/ti_dm.py > create mode 100644 tools/binman/etype/ti_sysfw.py > create mode 100644 tools/binman/etype/x509_cert.py > create mode 100644 tools/binman/test/225_ti_dm.dts > create mode 100644 tools/binman/test/232_ti_sysfw.dts > create mode 100644 tools/binman/test/232_x509_cert.dts > delete mode 100755 tools/k3_fit_atf.sh > delete mode 100755 tools/k3_gen_x509_cert.sh > create mode
Re: [u-boot PATCH 3/3] k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin
Hi,
On 27/05/2022 20:50, Alper Nebi Yasak wrote:
> On 26/05/2022 17:15, Tom Rini wrote:
>> On Thu, May 26, 2022 at 10:28:45AM +0300, Roger Quadros wrote:
>>> Any thoughts on how to get the new ti-secure etype work with atf-bl31 and
>>> tee-os etypes so that it can take the data output of those entries and
>>> create
>>> a signed binary with filenames from those entries or atf-bl31-path and
>>> tee-os-path?
>>>
>>> Can something like this work?
>>>
>>> ti-secure {
>>> atf-bl31 {
>>> filename = "bl31.bin";
>>> };
>>> }
>>>
>>> We could probably get rid of filename property from ti-secure etype and use
>>> blob for regular files.
>>>
>>> ti-secure {
>>> blob {
>>> filename = "somefile.ext";
>>> }
>>> }
>
> This would definitely work, see etype/mkimage.py for example. I'd prefer
> to know the file-format details (and maybe replicate them in binman) if
> you could afford to publish them, though...
This is a question to Nishanth/Andrew.
>
>
> Sorry I couldn't look at either series yet, but I see mentions of
> k3_fit_atf.sh, so let me point out another series [1][2] that might also
> interest you:
>
> [1] [RESEND, RFC 0/8] Integration of sysfw and tispl with U-Boot
> https://lore.kernel.org/u-boot/20220406122919.6104-1-n-fran...@ti.com/
>
> [2] [PATCH RFC v2 00/11] Integration of sysfw, tispl and tiboot3
> https://lore.kernel.org/u-boot/20220506043759.8193-1-n-fran...@ti.com/
Thanks for this pointer. I will review those patches and see how we can
consolidate.
cheers,
-roger
Re: [u-boot PATCH 3/3] k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin
On 25/05/2022 18:14, Andrew Davis wrote:
> On 5/25/22 3:30 AM, Roger Quadros wrote:
>> Hi Andrew,
>>
>> On 25/05/2022 01:03, Andrew Davis wrote:
>>> On 5/9/22 2:29 AM, Roger Quadros wrote:
>>>> Introduce k3-am642-evm-binman.dtsi to provide binman configuration.
>>>>
>>>> R5 build is still not converted to use binman so restrict binman.dtsi
>>>> to A53 builds only.
>>>>
>>>> This patch also take care of building Secure (HS) images using
>>>> binman instead of tools/k3_fit_atf.sh if CONFIG_BINMAN is set.
>>>>
>>>> Signed-off-by: Roger Quadros
>>>> ---
>>>> arch/arm/dts/k3-am642-evm-binman.dtsi | 230 ++
>>>> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 3 +
>>>> arch/arm/mach-k3/Kconfig | 1 +
>>>> arch/arm/mach-k3/config.mk | 7 +
>>>> 4 files changed, 241 insertions(+)
>>>> create mode 100644 arch/arm/dts/k3-am642-evm-binman.dtsi
>>>>
>>>> diff --git a/arch/arm/dts/k3-am642-evm-binman.dtsi
>>>> b/arch/arm/dts/k3-am642-evm-binman.dtsi
>>>> new file mode 100644
>>>> index 00..9e85ef41b0
>>>> --- /dev/null
>>>> +++ b/arch/arm/dts/k3-am642-evm-binman.dtsi
>>>> @@ -0,0 +1,230 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
>>>> + */
>>>> +
>>>> +/ {
>>>> + binman: binman {
>>>> + multiple-images;
>>>> + };
>>>> +};
>>>> +
>>>> +#ifdef CONFIG_TARGET_AM642_A53_EVM
>>>> +
>>>> +#ifdef CONFIG_TI_SECURE_DEVICE
>>>> +#define TISPL "tispl.bin_HS"
>>>> +#define UBOOT_IMG "u-boot.img_HS"
>>>> +#else
>>>> +#define TISPL "tispl.bin"
>>>> +#define UBOOT_IMG "u-boot.img"
>>>> +#endif
>>>> +
>>>> +#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
>>>> +#define SPL_AM642_EVM_DTB "spl/dts/k3-am642-evm.dtb"
>>>> +#define SPL_AM642_SK_DTB "spl/dts/k3-am642-sk.dtb"
>>>> +
>>>> +#define UBOOT_NODTB "u-boot-nodtb.bin"
>>>> +#define AM642_EVM_DTB "arch/arm/dts/k3-am642-evm.dtb"
>>>> +#define AM642_SK_DTB "arch/arm/dts/k3-am642-sk.dtb"
>>>> +
>>>> + {
>>>> + ti-spl {
>>>> + filename = TISPL;
>>>> + pad-byte = <0xff>;
>>>> +
>>>> + fit {
>>>> + description = "Configuration to load ATF and SPL";
>>>> + #address-cells = <1>;
>>>> +
>>>> + images {
>>>> +
>>>> + atf {
>>>> + description = "ARM Trusted Firmware";
>>>> + type = "firmware";
>>>> + arch = "arm64";
>>>> + compression = "none";
>>>> + os = "arm-trusted-firmware";
>>>> + load = ;
>>>> + entry = ;
>>>> + atf-bl31 {
>>>> + filename = "bl31.bin";
>>>> + };
>>>
>>>
>>> On HS, bl31.bin and the below TEE and DM images must also be signed
>>> before being packaged into tispl.bin.
>>> Can we add signing here?
>>
>> I'm wondering how this is working as is on HS boards.
>>
>
>
> Today we manually sign those two before we feed them to U-Boot build.
> I'd like to fix that and have them signed along with all the other
> parts here when packaging them together.
>
OK. Then this is new feature. Do you mind if I make a separate patch for it?
But first I need to figure out what to do ;)
>
>> Another thing to note is that the atf and tee entries take into consideration
>> the below environment variables
>> -a atf-bl31-path=${BL31} \
>> -a tee-os-path=${TEE} \
>>
>> How do we continue to support that while adding the signing bits?
>>
>
>
> That's my question also, I'm not sure how we would make the type 'ti-secure'
> while also changing their path names, seems like a limitation currently
> of
Re: [u-boot PATCH 3/3] k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin
Hi Andrew,
On 25/05/2022 01:03, Andrew Davis wrote:
> On 5/9/22 2:29 AM, Roger Quadros wrote:
>> Introduce k3-am642-evm-binman.dtsi to provide binman configuration.
>>
>> R5 build is still not converted to use binman so restrict binman.dtsi
>> to A53 builds only.
>>
>> This patch also take care of building Secure (HS) images using
>> binman instead of tools/k3_fit_atf.sh if CONFIG_BINMAN is set.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/dts/k3-am642-evm-binman.dtsi | 230 ++
>> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 3 +
>> arch/arm/mach-k3/Kconfig | 1 +
>> arch/arm/mach-k3/config.mk | 7 +
>> 4 files changed, 241 insertions(+)
>> create mode 100644 arch/arm/dts/k3-am642-evm-binman.dtsi
>>
>> diff --git a/arch/arm/dts/k3-am642-evm-binman.dtsi
>> b/arch/arm/dts/k3-am642-evm-binman.dtsi
>> new file mode 100644
>> index 00..9e85ef41b0
>> --- /dev/null
>> +++ b/arch/arm/dts/k3-am642-evm-binman.dtsi
>> @@ -0,0 +1,230 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +/ {
>> + binman: binman {
>> + multiple-images;
>> + };
>> +};
>> +
>> +#ifdef CONFIG_TARGET_AM642_A53_EVM
>> +
>> +#ifdef CONFIG_TI_SECURE_DEVICE
>> +#define TISPL "tispl.bin_HS"
>> +#define UBOOT_IMG "u-boot.img_HS"
>> +#else
>> +#define TISPL "tispl.bin"
>> +#define UBOOT_IMG "u-boot.img"
>> +#endif
>> +
>> +#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
>> +#define SPL_AM642_EVM_DTB "spl/dts/k3-am642-evm.dtb"
>> +#define SPL_AM642_SK_DTB "spl/dts/k3-am642-sk.dtb"
>> +
>> +#define UBOOT_NODTB "u-boot-nodtb.bin"
>> +#define AM642_EVM_DTB "arch/arm/dts/k3-am642-evm.dtb"
>> +#define AM642_SK_DTB "arch/arm/dts/k3-am642-sk.dtb"
>> +
>> + {
>> + ti-spl {
>> + filename = TISPL;
>> + pad-byte = <0xff>;
>> +
>> + fit {
>> + description = "Configuration to load ATF and SPL";
>> + #address-cells = <1>;
>> +
>> + images {
>> +
>> + atf {
>> + description = "ARM Trusted Firmware";
>> + type = "firmware";
>> + arch = "arm64";
>> + compression = "none";
>> + os = "arm-trusted-firmware";
>> + load = ;
>> + entry = ;
>> + atf-bl31 {
>> + filename = "bl31.bin";
>> + };
>
>
> On HS, bl31.bin and the below TEE and DM images must also be signed
> before being packaged into tispl.bin.
> Can we add signing here?
I'm wondering how this is working as is on HS boards.
Another thing to note is that the atf and tee entries take into consideration
the below environment variables
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
How do we continue to support that while adding the signing bits?
cheers,
-roger
>
> Andrew
>
>
>> + };
>> +
>> + tee {
>> + description = "OPTEE";
>> + type = "tee";
>> + arch = "arm64";
>> + compression = "none";
>> + os = "tee";
>> + load = <0x9e80>;
>> + entry = <0x9e80>;
>> + tee-os {
>> + filename = "tee-pager_v2.bin";
>> + };
>> + };
>> +
>> + dm {
>> + description = "DM binary";
>> + type = "firmware";
>> + arch = "arm32";
>> + compression = "none";
>> + os = "DM";
>> + load = <0x8900>;
>> + entry = <0x8900>;
>> + blob-ext {
>> + filename = "/dev/null";
>> + };
>> +
[u-boot PATCH 3/3] k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin
Introduce k3-am642-evm-binman.dtsi to provide binman configuration.
R5 build is still not converted to use binman so restrict binman.dtsi
to A53 builds only.
This patch also take care of building Secure (HS) images using
binman instead of tools/k3_fit_atf.sh if CONFIG_BINMAN is set.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-evm-binman.dtsi | 230 ++
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 3 +
arch/arm/mach-k3/Kconfig | 1 +
arch/arm/mach-k3/config.mk| 7 +
4 files changed, 241 insertions(+)
create mode 100644 arch/arm/dts/k3-am642-evm-binman.dtsi
diff --git a/arch/arm/dts/k3-am642-evm-binman.dtsi
b/arch/arm/dts/k3-am642-evm-binman.dtsi
new file mode 100644
index 00..9e85ef41b0
--- /dev/null
+++ b/arch/arm/dts/k3-am642-evm-binman.dtsi
@@ -0,0 +1,230 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+#ifdef CONFIG_TARGET_AM642_A53_EVM
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+#define TISPL "tispl.bin_HS"
+#define UBOOT_IMG "u-boot.img_HS"
+#else
+#define TISPL "tispl.bin"
+#define UBOOT_IMG "u-boot.img"
+#endif
+
+#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
+#define SPL_AM642_EVM_DTB "spl/dts/k3-am642-evm.dtb"
+#define SPL_AM642_SK_DTB "spl/dts/k3-am642-sk.dtb"
+
+#define UBOOT_NODTB "u-boot-nodtb.bin"
+#define AM642_EVM_DTB "arch/arm/dts/k3-am642-evm.dtb"
+#define AM642_SK_DTB "arch/arm/dts/k3-am642-sk.dtb"
+
+ {
+ ti-spl {
+ filename = TISPL;
+ pad-byte = <0xff>;
+
+ fit {
+ description = "Configuration to load ATF and SPL";
+ #address-cells = <1>;
+
+ images {
+
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ os = "arm-trusted-firmware";
+ load = ;
+ entry = ;
+ atf-bl31 {
+ filename = "bl31.bin";
+ };
+ };
+
+ tee {
+ description = "OPTEE";
+ type = "tee";
+ arch = "arm64";
+ compression = "none";
+ os = "tee";
+ load = <0x9e80>;
+ entry = <0x9e80>;
+ tee-os {
+ filename = "tee-pager_v2.bin";
+ };
+ };
+
+ dm {
+ description = "DM binary";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "DM";
+ load = <0x8900>;
+ entry = <0x8900>;
+ blob-ext {
+ filename = "/dev/null";
+ };
+ };
+
+ spl {
+ description = "SPL (64-bit)";
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm64";
+ compression = "none";
+ load = <0x8008>;
+ entry = <0x8008>;
+#ifdef CONFIG_TI_SECURE_DEVICE
+ ti-secure {
+#else
+ blob {
+#endif
+ filename = SPL_NODTB;
+ };
+ };
+
+
[u-boot PATCH 2/3] tools/fdtgrep: Include __symbols__ table
This is required for overlays to work at SPL.
Signed-off-by: Roger Quadros
---
tools/fdtgrep.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/fdtgrep.c b/tools/fdtgrep.c
index 641d6a2e3e..d904f679ae 100644
--- a/tools/fdtgrep.c
+++ b/tools/fdtgrep.c
@@ -1230,6 +1230,10 @@ int main(int argc, char *argv[])
disp.fout = stdout;
}
+ /* include symbol table */
+ if (value_add(, _head, FDT_IS_NODE, 1, "/__symbols__"))
+ usage("Cannot add __symbols__ value");
+
/* Run the grep and output the results */
ret = do_fdtgrep(, filename);
if (disp.output_fname)
--
2.17.1
[u-boot PATCH 1/3] tools: binman: add ti-secure entry type
This entry type is used to create a secured binary
for use with K3 High Security (HS) devices.
This allows us to no longer depend on k3_fit_atf.sh for
A53 SPL and u-boot image generation for HS devices.
We still depend on the availability of an external
tool provided by the TI_SECURE_DEV_PKG environment
variable to secure the binaries.
Signed-off-by: Roger Quadros
---
Makefile| 1 +
tools/binman/entries.rst| 15
tools/binman/etype/ti_secure.py | 59 +
tools/binman/ftest.py | 7
tools/binman/test/225_ti_secure.dts | 14 +++
5 files changed, 96 insertions(+)
create mode 100644 tools/binman/etype/ti_secure.py
create mode 100644 tools/binman/test/225_ti_secure.dts
diff --git a/Makefile b/Makefile
index ad83d60dc3..d9aac41d60 100644
--- a/Makefile
+++ b/Makefile
@@ -1328,6 +1328,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
+ -a ti-secure-dev-pkg-path=${TI_SECURE_DEV_PKG} \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 484cde5c80..c9faad51b6 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1788,3 +1788,18 @@ may be used instead.
+Entry: ti-secure: Entry containing a Secured binary blob
+
+
+Properties / Entry arguments:
+- filename: Filename of file to sign and read into entry
+
+Texas Instruments High-Security (HS) devices need secure binaries to be
+provided. This entry uses an external tool to append a x509 certificate
+to the file provided in the filename property and places it in the entry.
+
+The path for the external tool is fetched from TI_SECURE_DEV_PKG
+environment variable.
+
+
+
diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py
new file mode 100644
index 00..86772994bc
--- /dev/null
+++ b/tools/binman/etype/ti_secure.py
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2022 Texas Instruments Incorporated - https://www.ti.com/
+#
+
+# Support for secure binaries for TI K3 platform
+
+from collections import OrderedDict
+import os
+
+from binman.entry import Entry, EntryArg
+
+from dtoc import fdt_util
+from patman import tools
+
+class Entry_ti_secure(Entry):
+"""An entry which contains a secure binary for High-Security (HS) device
use.
+
+Properties / Entry arguments:
+ - filename: filename of binary file to be secured
+
+Output files:
+- filename_HS - output file generated by secure uility (which is
+used as the entry contents)
+
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node)
+self.filename = fdt_util.GetString(self._node, 'filename')
+self.toolpresent = False
+if not self.filename:
+self.Raise("ti_secure must have a 'filename' property")
+self.toolspath, = self.GetEntryArgsOrProps(
+[EntryArg('ti-secure-dev-pkg-path', str)])
+if not self.toolspath:
+print("WARNING: TI_SECURE_DEV_PKG environment " \
+ "variable must be defined for TI secure devices. " +
+ self.filename + " was NOT secured!")
+return
+
+self.tool = self.toolspath + "/scripts/secure-binary-image.sh"
+self.toolpresent = os.path.exists(self.tool)
+if not self.toolpresent:
+print(self.tool + " not found. " +
+ self.filename + " was NOT secured!")
+
+def ObtainContents(self):
+input_fname = self.filename
+output_fname = input_fname + "_HS"
+args = [
+input_fname, output_fname,
+]
+if self.toolpresent:
+stdout = tools.Run(self.tool, *args)
+else:
+stdout = tools.Run('cp', *args)
+print(output_fname + ' not secured!')
+
+self.SetContents(tools.ReadFile(output_fname))
+return True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 8f00db6945..996e4d9aa6 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -91,6 +91,7 @@ SCP_DATA = b'scp'
TEST_FDT1_DATA= b'fdt1'
TEST_FDT2_DATA= b'test-fdt2'
ENV_DATA = b'var1=1\nvar2="2"'
+TI_UNSECURE_DATA = b'this is some unsecure data'
# Subdirectory of the input dir to use to put test FDTs
TEST_FDT_SUBDIR = 'fdts'
@@ -201,6 +202,7 @@ class TestFunctional(unittest.TestCase):
TEST_FDT2_DAT
[u-boot PATCH 0/3] k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin
Hi, This series introduces ti-secure entry type for binman. It switches from using custom tool tools/k3_fit_atf.sh to binman for generating boot images for AM64 for both HS and non-HS devices. cheers, -roger Roger Quadros (3): tools: binman: add ti-secure entry type tools/fdtgrep: Include __symbols__ table k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin Makefile | 1 + arch/arm/dts/k3-am642-evm-binman.dtsi | 230 ++ arch/arm/dts/k3-am642-evm-u-boot.dtsi | 3 + arch/arm/mach-k3/Kconfig | 1 + arch/arm/mach-k3/config.mk| 7 + tools/binman/entries.rst | 15 ++ tools/binman/etype/ti_secure.py | 59 +++ tools/binman/ftest.py | 7 + tools/binman/test/225_ti_secure.dts | 14 ++ tools/fdtgrep.c | 4 + 10 files changed, 341 insertions(+) create mode 100644 arch/arm/dts/k3-am642-evm-binman.dtsi create mode 100644 tools/binman/etype/ti_secure.py create mode 100644 tools/binman/test/225_ti_secure.dts -- 2.17.1
Re: [u-boot PATCH v2] binman: Add support for TEE BL32
On 20/02/2022 00:12, Simon Glass wrote:
> On Sat, 19 Feb 2022 at 11:50, Roger Quadros wrote:
>>
>> Add an entry for OP-TEE Trusted OS 'BL32' payload.
>> This is required by platforms using Cortex-A cores with TrustZone
>> technology.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> Changelog:
>> v2:
>> - use 'tee-os' for entry name instead of 'bl32'
>> - use ${TEE} instead of ${BL32} for environment variable
>> - Use next available test file number for test device tree
>> - drop size property from test device node.
>>
>> Makefile | 1 +
>> tools/binman/entries.rst | 13 +
>> tools/binman/etype/tee_os.py | 22 ++
>> tools/binman/ftest.py| 7 +++
>> tools/binman/test/220_tee_os.dts | 14 ++
>> 5 files changed, 57 insertions(+)
>> create mode 100644 tools/binman/etype/tee_os.py
>> create mode 100644 tools/binman/test/220_tee_os.dts
>
> Reviewed-by: Simon Glass
>
> I will renumber the test file and add missing-blob-help when applying.
Thank you Simon :)
cheers,
-roger
[u-boot PATCH v2] binman: Add support for TEE BL32
Add an entry for OP-TEE Trusted OS 'BL32' payload.
This is required by platforms using Cortex-A cores with TrustZone
technology.
Signed-off-by: Roger Quadros
---
Changelog:
v2:
- use 'tee-os' for entry name instead of 'bl32'
- use ${TEE} instead of ${BL32} for environment variable
- Use next available test file number for test device tree
- drop size property from test device node.
Makefile | 1 +
tools/binman/entries.rst | 13 +
tools/binman/etype/tee_os.py | 22 ++
tools/binman/ftest.py| 7 +++
tools/binman/test/220_tee_os.dts | 14 ++
5 files changed, 57 insertions(+)
create mode 100644 tools/binman/etype/tee_os.py
create mode 100644 tools/binman/test/220_tee_os.dts
diff --git a/Makefile b/Makefile
index 184223ec63..0968895fcd 100644
--- a/Makefile
+++ b/Makefile
@@ -1326,6 +1326,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
-I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-a atf-bl31-path=${BL31} \
+ -a tee-os-path=${TEE} \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index c47f7df098..b147223661 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -25,6 +25,19 @@ about ATF.
+Entry: tee-os: Entry containing an OP-TEE Trusted OS (TEE) blob
+---
+
+Properties / Entry arguments:
+- tee-os-path: Filename of file to read into entry. This is typically
+called tee-pager.bin
+
+This entry holds the run-time firmware, typically started by U-Boot SPL.
+See the U-Boot README for your architecture or board for how to use it. See
+https://github.com/OP-TEE/optee_os for more information about OP-TEE.
+
+
+
Entry: atf-fip: ARM Trusted Firmware's Firmware Image Package (FIP)
---
diff --git a/tools/binman/etype/tee_os.py b/tools/binman/etype/tee_os.py
new file mode 100644
index 00..6ce4b672de
--- /dev/null
+++ b/tools/binman/etype/tee_os.py
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+#
+# Entry-type module for OP-TEE Trusted OS firmware blob
+#
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+
+class Entry_tee_os(Entry_blob_named_by_arg):
+"""Entry containing an OP-TEE Trusted OS (TEE) blob
+
+Properties / Entry arguments:
+- tee-os-path: Filename of file to read into entry. This is typically
+called tee-pager.bin
+
+This entry holds the run-time firmware, typically started by U-Boot SPL.
+See the U-Boot README for your architecture or board for how to use it. See
+https://github.com/OP-TEE/optee_os for more information about OP-TEE.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'tee-os')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 5400f76c67..b6057da552 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -81,6 +81,7 @@ FSP_M_DATA= b'fsp_m'
FSP_S_DATA= b'fsp_s'
FSP_T_DATA= b'fsp_t'
ATF_BL31_DATA = b'bl31'
+TEE_OS_DATA = b'this is some tee OS data'
ATF_BL2U_DATA = b'bl2u'
OPENSBI_DATA = b'opensbi'
SCP_DATA = b'scp'
@@ -185,6 +186,7 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('compress', COMPRESS_DATA)
TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
+TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
@@ -3877,6 +3879,11 @@ class TestFunctional(unittest.TestCase):
data = self._DoReadFile('169_atf_bl31.dts')
self.assertEqual(ATF_BL31_DATA, data[:len(ATF_BL31_DATA)])
+def testPackTeeOs(self):
+"""Test that an image with an TEE binary can be created"""
+data = self._DoReadFile('220_tee_os.dts')
+self.assertEqual(TEE_OS_DATA, data[:len(TEE_OS_DATA)])
+
def testPackScp(self):
"""Test that an image with an SCP binary can be created"""
data = self._DoReadFile('172_scp.dts')
diff --git a/tools/binman/test/220_tee_os.dts b/tools/binman/test/220_tee_os.dts
new file mode 100644
index 00..6885497294
--- /dev/null
+++ b/tools
Re: [u-boot][PATCH] binman: Add support for TEE BL32
Hi Simon, On 19/02/2022 17:24, Simon Glass wrote: > Hi Roger, > > On Sat, 5 Feb 2022 at 05:29, Roger Quadros wrote: >> >> Hi Simon, >> >> On 04/02/2022 19:17, Simon Glass wrote: >>> Hi Roger, >>> >>> On Fri, 4 Feb 2022 at 06:00, Roger Quadros wrote: >>>> >>>> Add an entry for OP-TEE Trusted OS 'BL32' payload. >>>> This is required by platforms using Cortex-A cores with TrustZone >>>> technology. >>>> >>>> Signed-off-by: Roger Quadros >>>> --- >>>> Makefile | 1 + >>>> tools/binman/entries.rst | 13 + >>>> tools/binman/etype/atf_bl32.py | 22 ++ >>>> tools/binman/ftest.py | 7 +++ >>>> tools/binman/test/170_atf_bl32.dts | 16 >>>> 5 files changed, 59 insertions(+) >>>> create mode 100644 tools/binman/etype/atf_bl32.py >>>> create mode 100644 tools/binman/test/170_atf_bl32.dts > > Did you end up sending an updated patch for this? I cannot see it. Not yet. I'll send it soon. cheers, -roger
Re: [u-boot][PATCH] binman: Add support for TEE BL32
Hi Simon,
On 04/02/2022 19:17, Simon Glass wrote:
> Hi Roger,
>
> On Fri, 4 Feb 2022 at 06:00, Roger Quadros wrote:
>>
>> Add an entry for OP-TEE Trusted OS 'BL32' payload.
>> This is required by platforms using Cortex-A cores with TrustZone
>> technology.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> Makefile | 1 +
>> tools/binman/entries.rst | 13 +
>> tools/binman/etype/atf_bl32.py | 22 ++
>> tools/binman/ftest.py | 7 +++
>> tools/binman/test/170_atf_bl32.dts | 16
>> 5 files changed, 59 insertions(+)
>> create mode 100644 tools/binman/etype/atf_bl32.py
>> create mode 100644 tools/binman/test/170_atf_bl32.dts
>
> Funnily enough I have been fiddling with some patches to replace the
> rockchip SPL_FIT_GENERATOR script and have added an op-tee entry type
> in that. I did not think of op-tee as part of ATF, so didn't call it
> bl32, etc. That is perhaps just because I didn't know that.
>
> So is op-tee always added as part of ATF and with a BL32 name?
In fact at build time the filename is tee-pager_v2.bin.
I just picked the name BL32 but now when I look back it doesn't seem right.
I think tee.bin is a better name.
>
>>
>> diff --git a/Makefile b/Makefile
>> index 184223ec63..5e2f89d742 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1326,6 +1326,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
>> $(BINMAN_DEBUG),-D) \
>> -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \
>> $(foreach f,$(BINMAN_INDIRS),-I $(f)) \
>> -a atf-bl31-path=${BL31} \
>> + -a atf-bl32-path=${BL32} \
>
> Some boards use $(TEE), but I suppose it is fine to use this code word.
Let's use $(TEE) then. It seems more appropriate.
>
>> -a opensbi-path=${OPENSBI} \
>> -a default-dt=$(default_dt) \
>> -a scp-path=$(SCP) \
>> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
>> index c47f7df098..5215df7734 100644
>> --- a/tools/binman/entries.rst
>> +++ b/tools/binman/entries.rst
>> @@ -25,6 +25,19 @@ about ATF.
>>
>>
>>
>> +Entry: atf-bl32: Entry containing an OP-TEE Trusted OS (TEE) BL32 blob
>
> So is bl32 always OP-TEE or could it be something else?
>
>> +-
>> +
>> +Properties / Entry arguments:
>> +- atf-bl32-path: Filename of file to read into entry. This is typically
>> +called bl32.bin or bl32.elf
>> +
>> +This entry holds the run-time firmware, typically started by U-Boot SPL.
>> +See the U-Boot README for your architecture or board for how to use it. See
>> +https://github.com/OP-TEE/optee_os for more information about OP-TEE.
>> +
>> +
>> +
>> Entry: atf-fip: ARM Trusted Firmware's Firmware Image Package (FIP)
>> ---
>>
>> diff --git a/tools/binman/etype/atf_bl32.py b/tools/binman/etype/atf_bl32.py
>> new file mode 100644
>> index 00..e74b4e4428
>> --- /dev/null
>> +++ b/tools/binman/etype/atf_bl32.py
>> @@ -0,0 +1,22 @@
>> +# SPDX-License-Identifier: GPL-2.0+
>> +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
>> +#
>> +# Entry-type module for OP-TEE Trusted OS firmware blob
>> +#
>> +
>> +from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
>> +
>> +class Entry_atf_bl32(Entry_blob_named_by_arg):
>> +"""Entry containing an OP-TEE Trusted OS (TEE) BL32 blob
>> +
>> +Properties / Entry arguments:
>> +- atf-bl32-path: Filename of file to read into entry. This is
>> typically
>> +called bl32.bin or bl32.elf
>> +
>> +This entry holds the run-time firmware, typically started by U-Boot SPL.
>> +See the U-Boot README for your architecture or board for how to use it.
>> See
>> +https://github.com/OP-TEE/optee_os for more information about OP-TEE.
>> +"""
>> +def __init__(self, section, etype, node):
>> +super().__init__(section, etype, node, 'atf-bl32')
>> +self.external = True
>> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
>> index 5400f76c67..9366581bee 100644
>> --- a/tools/binman/ftest.py
>> +++ b/tools/binman/ftest.py
>> @@ -81,6 +81,7 @@ FSP_M_DATA= b'fsp_m'
>> FSP_S_DATA= b'
[u-boot][PATCH] binman: Add support for TEE BL32
Add an entry for OP-TEE Trusted OS 'BL32' payload.
This is required by platforms using Cortex-A cores with TrustZone
technology.
Signed-off-by: Roger Quadros
---
Makefile | 1 +
tools/binman/entries.rst | 13 +
tools/binman/etype/atf_bl32.py | 22 ++
tools/binman/ftest.py | 7 +++
tools/binman/test/170_atf_bl32.dts | 16
5 files changed, 59 insertions(+)
create mode 100644 tools/binman/etype/atf_bl32.py
create mode 100644 tools/binman/test/170_atf_bl32.dts
diff --git a/Makefile b/Makefile
index 184223ec63..5e2f89d742 100644
--- a/Makefile
+++ b/Makefile
@@ -1326,6 +1326,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
-I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-a atf-bl31-path=${BL31} \
+ -a atf-bl32-path=${BL32} \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index c47f7df098..5215df7734 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -25,6 +25,19 @@ about ATF.
+Entry: atf-bl32: Entry containing an OP-TEE Trusted OS (TEE) BL32 blob
+-
+
+Properties / Entry arguments:
+- atf-bl32-path: Filename of file to read into entry. This is typically
+called bl32.bin or bl32.elf
+
+This entry holds the run-time firmware, typically started by U-Boot SPL.
+See the U-Boot README for your architecture or board for how to use it. See
+https://github.com/OP-TEE/optee_os for more information about OP-TEE.
+
+
+
Entry: atf-fip: ARM Trusted Firmware's Firmware Image Package (FIP)
---
diff --git a/tools/binman/etype/atf_bl32.py b/tools/binman/etype/atf_bl32.py
new file mode 100644
index 00..e74b4e4428
--- /dev/null
+++ b/tools/binman/etype/atf_bl32.py
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+#
+# Entry-type module for OP-TEE Trusted OS firmware blob
+#
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+
+class Entry_atf_bl32(Entry_blob_named_by_arg):
+"""Entry containing an OP-TEE Trusted OS (TEE) BL32 blob
+
+Properties / Entry arguments:
+- atf-bl32-path: Filename of file to read into entry. This is typically
+called bl32.bin or bl32.elf
+
+This entry holds the run-time firmware, typically started by U-Boot SPL.
+See the U-Boot README for your architecture or board for how to use it. See
+https://github.com/OP-TEE/optee_os for more information about OP-TEE.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'atf-bl32')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 5400f76c67..9366581bee 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -81,6 +81,7 @@ FSP_M_DATA= b'fsp_m'
FSP_S_DATA= b'fsp_s'
FSP_T_DATA= b'fsp_t'
ATF_BL31_DATA = b'bl31'
+ATF_BL32_DATA = b'bl32'
ATF_BL2U_DATA = b'bl2u'
OPENSBI_DATA = b'opensbi'
SCP_DATA = b'scp'
@@ -185,6 +186,7 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('compress', COMPRESS_DATA)
TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
+TestFunctional._MakeInputFile('bl32.bin', ATF_BL32_DATA)
TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
@@ -3877,6 +3879,11 @@ class TestFunctional(unittest.TestCase):
data = self._DoReadFile('169_atf_bl31.dts')
self.assertEqual(ATF_BL31_DATA, data[:len(ATF_BL31_DATA)])
+def testPackBl32(self):
+"""Test that an image with an ATF BL32 binary can be created"""
+data = self._DoReadFile('170_atf_bl32.dts')
+self.assertEqual(ATF_BL32_DATA, data[:len(ATF_BL32_DATA)])
+
def testPackScp(self):
"""Test that an image with an SCP binary can be created"""
data = self._DoReadFile('172_scp.dts')
diff --git a/tools/binman/test/170_atf_bl32.dts
b/tools/binman/test/170_atf_bl32.dts
new file mode 100644
index 00..8c15c79c86
--- /dev/null
+++ b/tools/binman/test/170_atf_bl32.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+
[PATCH v2] ARM: dts: Fix node status to "okay" on TI boards
As per Device Tree Specification [1], the status parameter of nodes can
be "okay", "disabled", etc. "ok" is not a valid parameter.
U-boot Driver Model does not recognize status="ok" either and treats
the node as disabled.
[1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
Signed-off-by: Roger Quadros
---
Changelog:
v2:
- Updated commit message to refer to DT spec instead of schema.
arch/arm/dts/am3517-evm-ui.dtsi | 4 ++--
arch/arm/dts/am3517-evm.dts | 2 +-
arch/arm/dts/am437x-gp-evm.dts | 2 +-
arch/arm/dts/am43x-epos-evm.dts | 2 +-
arch/arm/dts/am57xx-beagle-x15-common.dtsi | 6 +++---
arch/arm/dts/da850-evm.dts | 2 +-
arch/arm/dts/dra7-evm.dts | 2 +-
arch/arm/dts/dra72-evm-common.dtsi | 6 +++---
arch/arm/dts/keystone-k2e-evm.dts | 2 +-
arch/arm/dts/keystone-k2hk-evm.dts | 2 +-
arch/arm/dts/keystone-k2l-evm.dts | 2 +-
arch/arm/dts/omap3-beagle-xm.dts| 4 ++--
arch/arm/dts/omap3-beagle.dts | 6 +++---
arch/arm/dts/omap3-igep0020-common.dtsi | 2 +-
arch/arm/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 2 +-
arch/arm/dts/omap34xx.dtsi | 2 +-
arch/arm/dts/omap36xx.dtsi | 2 +-
arch/arm/dts/omap4-panda-common.dtsi| 6 +++---
arch/arm/dts/omap4-sdp.dts | 8
arch/arm/dts/omap5-board-common.dtsi| 4 ++--
20 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/arch/arm/dts/am3517-evm-ui.dtsi b/arch/arm/dts/am3517-evm-ui.dtsi
index e841918c1c..54aa2522aa 100644
--- a/arch/arm/dts/am3517-evm-ui.dtsi
+++ b/arch/arm/dts/am3517-evm-ui.dtsi
@@ -186,14 +186,14 @@
};
{
- status = "ok";
+ status = "okay";
#sound-dai-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
};
{
- status = "ok";
+ status = "okay";
#sound-dai-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
index 3527c0f2df..935c471c97 100644
--- a/arch/arm/dts/am3517-evm.dts
+++ b/arch/arm/dts/am3517-evm.dts
@@ -193,7 +193,7 @@
};
{
- status = "ok";
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_dpi_pins>;
diff --git a/arch/arm/dts/am437x-gp-evm.dts b/arch/arm/dts/am437x-gp-evm.dts
index 3c500d52db..21f7691f49 100644
--- a/arch/arm/dts/am437x-gp-evm.dts
+++ b/arch/arm/dts/am437x-gp-evm.dts
@@ -742,7 +742,7 @@
};
{
- status = "ok";
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/dts/am43x-epos-evm.dts b/arch/arm/dts/am43x-epos-evm.dts
index 65f157ed59..b940bc6ccf 100644
--- a/arch/arm/dts/am43x-epos-evm.dts
+++ b/arch/arm/dts/am43x-epos-evm.dts
@@ -752,7 +752,7 @@
};
{
- status = "ok";
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/dts/am57xx-beagle-x15-common.dtsi
b/arch/arm/dts/am57xx-beagle-x15-common.dtsi
index d6b94d528f..1912ea9a15 100644
--- a/arch/arm/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/dts/am57xx-beagle-x15-common.dtsi
@@ -528,13 +528,13 @@
};
{
- status = "ok";
+ status = "okay";
vdda_video-supply = <_reg>;
};
{
- status = "ok";
+ status = "okay";
vdda-supply = <_reg>;
port {
@@ -545,7 +545,7 @@
};
_rc {
- status = "ok";
+ status = "okay";
gpios = < 8 GPIO_ACTIVE_LOW>;
};
diff --git a/arch/arm/dts/da850-evm.dts b/arch/arm/dts/da850-evm.dts
index f04bc3e153..b331cefd18 100644
--- a/arch/arm/dts/da850-evm.dts
+++ b/arch/arm/dts/da850-evm.dts
@@ -405,7 +405,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
- status = "ok";
+ status = "okay";
cs3 {
#address-cells = <2>;
#size-cells = <1>;
diff --git a/arch/arm/dts/dra7-evm.dts b/arch/arm/dts/dra7-evm.dts
index 43de9638e3..8e9a1a80a8 100644
--- a/arch/arm/dts/dra7-evm.dts
+++ b/arch/arm/dts/dra7-evm.dts
@@ -501,7 +501,7 @@
};
{
- status = "ok";
+ status = "okay";
pinctrl-names = "default", "sleep", "active";
pinctrl-0 = <_pins_sleep>;
pinctrl-1 = <_pins_sleep>;
diff --git a/arch/arm/dts/dra72-evm-common.dtsi
b/arch/arm/dts/dra72-evm-common.dtsi
index 2e48
Re: [PATCH] ARM: dts: Fix node status to "okay" on TI boards
Hi Lokesh,
On 23/08/2021 09:23, Lokesh Vutla wrote:
> Hi Roger,
>
> On 20/08/21 4:11 pm, Roger Quadros wrote:
>> As per Device Tree core schema [1], status parameter of nodes can be either
>> "okay" or "disabled".
>>
>> U-boot Driver Model does not recognize status="ok" and treats
>> the node as disabled.
>>
>
> Is Kernel DTS updated? The idea is to not deviate from Kernel dts as much as
> possible.
Yes, on kernel side, most nodes have been updated. There were a few stray left
overs which I have sent patches for. I will send v2 of this series to address
Nishanth's comment.
cheers,
-roger
>
> Thanks and regards,
> Lokesh
>
>> Signed-off-by: Roger Quadros
>
>> ---
>> arch/arm/dts/am3517-evm-ui.dtsi | 4 ++--
>> arch/arm/dts/am3517-evm.dts | 2 +-
>> arch/arm/dts/am437x-gp-evm.dts | 2 +-
>> arch/arm/dts/am43x-epos-evm.dts | 2 +-
>> arch/arm/dts/am57xx-beagle-x15-common.dtsi | 6 +++---
>> arch/arm/dts/da850-evm.dts | 2 +-
>> arch/arm/dts/dra7-evm.dts | 2 +-
>> arch/arm/dts/dra72-evm-common.dtsi | 6 +++---
>> arch/arm/dts/keystone-k2e-evm.dts | 2 +-
>> arch/arm/dts/keystone-k2hk-evm.dts | 2 +-
>> arch/arm/dts/keystone-k2l-evm.dts | 2 +-
>> arch/arm/dts/omap3-beagle-xm.dts| 4 ++--
>> arch/arm/dts/omap3-beagle.dts | 6 +++---
>> arch/arm/dts/omap3-igep0020-common.dtsi | 2 +-
>> arch/arm/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 2 +-
>> arch/arm/dts/omap34xx.dtsi | 2 +-
>> arch/arm/dts/omap36xx.dtsi | 2 +-
>> arch/arm/dts/omap4-panda-common.dtsi| 6 +++---
>> arch/arm/dts/omap4-sdp.dts | 8
>> arch/arm/dts/omap5-board-common.dtsi| 4 ++--
>> 20 files changed, 34 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/arm/dts/am3517-evm-ui.dtsi
>> b/arch/arm/dts/am3517-evm-ui.dtsi
>> index e841918c1c..54aa2522aa 100644
>> --- a/arch/arm/dts/am3517-evm-ui.dtsi
>> +++ b/arch/arm/dts/am3517-evm-ui.dtsi
>> @@ -186,14 +186,14 @@
>> };
>>
>> {
>> -status = "ok";
>> +status = "okay";
>> #sound-dai-cells = <0>;
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> };
>>
>> {
>> -status = "ok";
>> +status = "okay";
>> #sound-dai-cells = <0>;
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
>> index 3527c0f2df..935c471c97 100644
>> --- a/arch/arm/dts/am3517-evm.dts
>> +++ b/arch/arm/dts/am3517-evm.dts
>> @@ -193,7 +193,7 @@
>> };
>>
>> {
>> -status = "ok";
>> +status = "okay";
>>
>> pinctrl-names = "default";
>> pinctrl-0 = <_dpi_pins>;
>> diff --git a/arch/arm/dts/am437x-gp-evm.dts b/arch/arm/dts/am437x-gp-evm.dts
>> index 3c500d52db..21f7691f49 100644
>> --- a/arch/arm/dts/am437x-gp-evm.dts
>> +++ b/arch/arm/dts/am437x-gp-evm.dts
>> @@ -742,7 +742,7 @@
>> };
>>
>> {
>> -status = "ok";
>> +status = "okay";
>>
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> diff --git a/arch/arm/dts/am43x-epos-evm.dts
>> b/arch/arm/dts/am43x-epos-evm.dts
>> index 65f157ed59..b940bc6ccf 100644
>> --- a/arch/arm/dts/am43x-epos-evm.dts
>> +++ b/arch/arm/dts/am43x-epos-evm.dts
>> @@ -752,7 +752,7 @@
>> };
>>
>> {
>> -status = "ok";
>> +status = "okay";
>>
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> diff --git a/arch/arm/dts/am57xx-beagle-x15-common.dtsi
>> b/arch/arm/dts/am57xx-beagle-x15-common.dtsi
>> index d6b94d528f..1912ea9a15 100644
>> --- a/arch/arm/dts/am57xx-beagle-x15-common.dtsi
>> +++ b/arch/arm/dts/am57xx-beagle-x15-common.dtsi
>> @@ -528,13 +528,13 @@
>> };
>>
>> {
>> -status = "ok";
>> +status = "okay";
>>
>> vdda_video-supply = <_reg>;
>> };
>>
>> {
>> -status = "ok";
>> +status = "okay";
[PATCH] ARM: dts: Fix node status to "okay" on TI boards
As per Device Tree core schema [1], status parameter of nodes can be either
"okay" or "disabled".
U-boot Driver Model does not recognize status="ok" and treats
the node as disabled.
Signed-off-by: Roger Quadros
---
arch/arm/dts/am3517-evm-ui.dtsi | 4 ++--
arch/arm/dts/am3517-evm.dts | 2 +-
arch/arm/dts/am437x-gp-evm.dts | 2 +-
arch/arm/dts/am43x-epos-evm.dts | 2 +-
arch/arm/dts/am57xx-beagle-x15-common.dtsi | 6 +++---
arch/arm/dts/da850-evm.dts | 2 +-
arch/arm/dts/dra7-evm.dts | 2 +-
arch/arm/dts/dra72-evm-common.dtsi | 6 +++---
arch/arm/dts/keystone-k2e-evm.dts | 2 +-
arch/arm/dts/keystone-k2hk-evm.dts | 2 +-
arch/arm/dts/keystone-k2l-evm.dts | 2 +-
arch/arm/dts/omap3-beagle-xm.dts| 4 ++--
arch/arm/dts/omap3-beagle.dts | 6 +++---
arch/arm/dts/omap3-igep0020-common.dtsi | 2 +-
arch/arm/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 2 +-
arch/arm/dts/omap34xx.dtsi | 2 +-
arch/arm/dts/omap36xx.dtsi | 2 +-
arch/arm/dts/omap4-panda-common.dtsi| 6 +++---
arch/arm/dts/omap4-sdp.dts | 8
arch/arm/dts/omap5-board-common.dtsi| 4 ++--
20 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/arch/arm/dts/am3517-evm-ui.dtsi b/arch/arm/dts/am3517-evm-ui.dtsi
index e841918c1c..54aa2522aa 100644
--- a/arch/arm/dts/am3517-evm-ui.dtsi
+++ b/arch/arm/dts/am3517-evm-ui.dtsi
@@ -186,14 +186,14 @@
};
{
- status = "ok";
+ status = "okay";
#sound-dai-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
};
{
- status = "ok";
+ status = "okay";
#sound-dai-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
index 3527c0f2df..935c471c97 100644
--- a/arch/arm/dts/am3517-evm.dts
+++ b/arch/arm/dts/am3517-evm.dts
@@ -193,7 +193,7 @@
};
{
- status = "ok";
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_dpi_pins>;
diff --git a/arch/arm/dts/am437x-gp-evm.dts b/arch/arm/dts/am437x-gp-evm.dts
index 3c500d52db..21f7691f49 100644
--- a/arch/arm/dts/am437x-gp-evm.dts
+++ b/arch/arm/dts/am437x-gp-evm.dts
@@ -742,7 +742,7 @@
};
{
- status = "ok";
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/dts/am43x-epos-evm.dts b/arch/arm/dts/am43x-epos-evm.dts
index 65f157ed59..b940bc6ccf 100644
--- a/arch/arm/dts/am43x-epos-evm.dts
+++ b/arch/arm/dts/am43x-epos-evm.dts
@@ -752,7 +752,7 @@
};
{
- status = "ok";
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/dts/am57xx-beagle-x15-common.dtsi
b/arch/arm/dts/am57xx-beagle-x15-common.dtsi
index d6b94d528f..1912ea9a15 100644
--- a/arch/arm/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/dts/am57xx-beagle-x15-common.dtsi
@@ -528,13 +528,13 @@
};
{
- status = "ok";
+ status = "okay";
vdda_video-supply = <_reg>;
};
{
- status = "ok";
+ status = "okay";
vdda-supply = <_reg>;
port {
@@ -545,7 +545,7 @@
};
_rc {
- status = "ok";
+ status = "okay";
gpios = < 8 GPIO_ACTIVE_LOW>;
};
diff --git a/arch/arm/dts/da850-evm.dts b/arch/arm/dts/da850-evm.dts
index f04bc3e153..b331cefd18 100644
--- a/arch/arm/dts/da850-evm.dts
+++ b/arch/arm/dts/da850-evm.dts
@@ -405,7 +405,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
- status = "ok";
+ status = "okay";
cs3 {
#address-cells = <2>;
#size-cells = <1>;
diff --git a/arch/arm/dts/dra7-evm.dts b/arch/arm/dts/dra7-evm.dts
index 43de9638e3..8e9a1a80a8 100644
--- a/arch/arm/dts/dra7-evm.dts
+++ b/arch/arm/dts/dra7-evm.dts
@@ -501,7 +501,7 @@
};
{
- status = "ok";
+ status = "okay";
pinctrl-names = "default", "sleep", "active";
pinctrl-0 = <_pins_sleep>;
pinctrl-1 = <_pins_sleep>;
diff --git a/arch/arm/dts/dra72-evm-common.dtsi
b/arch/arm/dts/dra72-evm-common.dtsi
index 2e485a13df..964e5e9b90 100644
--- a/arch/arm/dts/dra72-evm-common.dtsi
+++ b/arch/arm/dts/dra72-evm-common.dtsi
@@ -430,7 +430,7 @@
};
{
- status = "ok";
+ status = "okay";
Re: status="ok" treated as disabled by DM
On 19/08/2021 14:37, Nishanth Menon wrote: > On 14:03-20210819, Roger Quadros wrote: >> Hi, >> >> If the device tree node has status="ok" then the u-boot DM will treat the >> device as disabled. >> There are still quite many devices using "ok" instead of "okay" or no status >> and those devices will not be bound. >> >> What is the right fix? >> 1) make u-boot DM to treat satus="ok" as enabled. >> 2) fix device tree by changing "ok" to "okay". >> >> cheers, >> -roger > https://github.com/devicetree-org/dt-schema/blob/master/schemas/dt-core.yaml#L36 > > > I believe, the correct fix is (2) change the dt to "okay". > Also in u-boot code it does mention to fix DT node status to "okay". https://elixir.bootlin.com/u-boot/v2021.07/source/lib/fdtdec.c#L278 -- cheers, -roger
status="ok" treated as disabled by DM
Hi, If the device tree node has status="ok" then the u-boot DM will treat the device as disabled. There are still quite many devices using "ok" instead of "okay" or no status and those devices will not be bound. What is the right fix? 1) make u-boot DM to treat satus="ok" as enabled. 2) fix device tree by changing "ok" to "okay". cheers, -roger
Re: [PATCH 0/3] usb: am654: Add support for host mode to the USB port on overlay board
Hi, On 20/11/2020 17:48, Aswath Govindraju wrote: The following series of patches - adds support for host mode to USB3SS0 controller - adds aliases for USB subsystems - adds a workaround to use USB0 in USB 2.0 only mode Aswath Govindraju (3): board: ti: am65x: Set SERDES0 mux to PCIe to use USB 2.0 interface dts: am654-base-board-uboot: Set USB0 dr_mode to host dts: am654-base-board-uboot: Add aliases for USB subsystems For all patches, Acked-by: Roger Quadros arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 4 +++- board/ti/am65x/evm.c | 16 2 files changed, 19 insertions(+), 1 deletion(-) cheers, -roger -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[u-boot PATCH] configs: am65/j72x: Set CONFIG_LOGLEVEL to 7
By default CONFIG_LOGLEVEL seems to be set to 4 which is
too low and doesn't show dev_info/dev_notice/dev_warn
messages on console. This has been deliberately set low
globally to be conservative setting across the board due to
primary bootloader size limitations. It is best to tune
per board config as per user needs.
On K3 we have separate SPL and u-boot configs so we
can afford to set u-boot CONFIG_LOGLEVEL to 7.
On AM65 this patch causes u-boot.img size to change from
932KB to 940KB with 1 line additional print during
MMC boot. i.e. details of Net subsystem
"Net: K3 CPSW: nuss_ver: 0x6BA00102 cpsw_ver: 0x6BA80102 ale_ver: 0x00293904
Ports:1 mdio_freq:100"
Similar 8KB difference was seen on J721E.
Signed-off-by: Roger Quadros
Reviewed-by: Nishanth Menon
---
configs/am65x_evm_a53_defconfig| 1 +
configs/am65x_hs_evm_a53_defconfig | 1 +
configs/j7200_evm_a72_defconfig| 1 +
configs/j721e_evm_a72_defconfig| 1 +
configs/j721e_hs_evm_a72_defconfig | 1 +
5 files changed, 5 insertions(+)
diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 8a94ad1530..941073ce7f 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -30,6 +30,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run
get_overlay_${boot}; run run_kern"
+CONFIG_LOGLEVEL=7
CONFIG_CONSOLE_MUX=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_STACK_R=y
diff --git a/configs/am65x_hs_evm_a53_defconfig
b/configs/am65x_hs_evm_a53_defconfig
index 2c7217afb6..7d467c167e 100644
--- a/configs/am65x_hs_evm_a53_defconfig
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -32,6 +32,7 @@ CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_fit_${boot}; run get_overlaystring; run run_fit"
+CONFIG_LOGLEVEL=7
CONFIG_CONSOLE_MUX=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_STACK_R=y
diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 7c900b1d2e..1d2526b5f1 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -31,6 +31,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run
get_overlay_${boot}; run run_kern"
+CONFIG_LOGLEVEL=7
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_STACK_R=y
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 6de8666956..982e3df2f2 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -30,6 +30,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run
get_overlay_${boot}; run run_kern"
+CONFIG_LOGLEVEL=7
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_STACK_R=y
diff --git a/configs/j721e_hs_evm_a72_defconfig
b/configs/j721e_hs_evm_a72_defconfig
index acbc04359c..28bf56e7e1 100644
--- a/configs/j721e_hs_evm_a72_defconfig
+++ b/configs/j721e_hs_evm_a72_defconfig
@@ -31,6 +31,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; run get_fit_${boot}; run get_overlaystring; run run_fit"
+CONFIG_LOGLEVEL=7
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_STACK_R=y
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 00/10] net: ti: icssg: Add prueth support
Hi Christian, On 26/10/2020 14:37, Christian Gmeiner wrote: Hi all Is there any update regarding this patch series? I am working on revising this driver. Once ready I will post the updated version upstream. cheers, -roger Am Do., 20. Feb. 2020 um 10:19 Uhr schrieb Keerthy : On 18/02/20 10:39 am, Keerthy wrote: The series adds support for icssg_prueth functionality on u-boot. This series is based on top of master branch. rproc init needs to be done from uboot command prompt. The pru/rtu firmware loading is done by prueth driver soon after config paramters are setup. A quick update on this series. It seems newer version of this hardware needs more modifications to this series. Hence please ignore v2. Best Regards, Keerthy Currently only slice0/1 of icssg2 instance on am6-evm is supported. i.e Both slices of icssg2 instance are supported. Prebuilt firmware can be obtained from AM65 procSDK [1] rootfs at /lib/firmware/ti-pruss/am65x*.elf [1] http://software-dl.ti.com/processor-sdk-linux/esd/AM65X/latest/index_FDS.html This tests tftp on prueth. Note: Uboot ethernet driver architecture supports once instance per probe. So only one of the ports are supported per instance. So DT of prueth node should have either ethernet-mii0 or ethernet-mii1. Changes in v2: It has been a while since v1 was posted. Here are the changes: * Removed the usage of misc_init_by_ofnode instead used uclass_get_device_by_ofnode. * Introduced started variable to keep track of the status of the prueth device. * Build Tested on Travis: https://travis-ci.org/Keerthyj/u-boot/builds/651449684 Keerthy (10): net: eth-uclass: eth_get_dev based on SEQ_ALIAS instead of probe order soc: ti: pruss: add a misc driver for PRUSS in TI SoCs remoteproc: pruss: add PRU remoteproc driver net: ti: icssg-prueth: Add ICSSG ethernet driver arm: dts: k3-am65-main: Add msmc_ram node arm: dts: k3-am654-base-board-u-boot: Add icssg specific msmc_ram carveout nodes arm: dts: k3-am65-main: Add scm_conf node arm: dts: k3-am65-main: Add pruss nodes for ICSSG2 arm64: dts: ti: am654-base-board: add ICSSG2 Ethernet support configs: am65x_evm_a53_defconfig: Enable CONFIG_TI_AM64_ICSSG_PRUETH arch/arm/dts/k3-am65-main.dtsi | 191 ++ arch/arm/dts/k3-am65.dtsi| 4 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 129 configs/am65x_evm_a53_defconfig | 3 + drivers/net/ti/Kconfig | 8 + drivers/net/ti/Makefile | 1 + drivers/net/ti/icssg-prueth.c| 652 +++ drivers/net/ti/icssg.h | 36 + drivers/net/ti/icssg_classifier.c| 396 +++ drivers/remoteproc/Kconfig | 11 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/pru_rproc.c | 405 drivers/soc/ti/Kconfig | 12 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/pruss.c | 152 + include/ti-pruss.h | 17 + net/eth-uclass.c | 12 +- 17 files changed, 2027 insertions(+), 4 deletions(-) create mode 100644 drivers/net/ti/icssg-prueth.c create mode 100644 drivers/net/ti/icssg.h create mode 100644 drivers/net/ti/icssg_classifier.c create mode 100644 drivers/remoteproc/pru_rproc.c create mode 100644 drivers/soc/ti/pruss.c create mode 100644 include/ti-pruss.h -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v5 04/10] usb: common: add define of usb_speed_string()
On 17/08/2020 10:51, Roger Quadros wrote:
Hi,
On 17/08/2020 10:40, Chunfeng Yun wrote:
There is only declear of usb_speed_string(), but not define it.
s/declear/declaration
s/not define/no definition of/
Signed-off-by: Chunfeng Yun
---
v5: no changes
v4: new patch
---
drivers/usb/common/common.c | 7 +++
include/linux/usb/ch9.h | 4
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index 76f5a9c..5e5c3c3 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -49,6 +49,13 @@ static const char *const speed_names[] = {
[USB_SPEED_SUPER_PLUS] = "super-speed-plus",
};
+const char *usb_speed_string(enum usb_device_speed speed)
+{
+ if (speed < 0 || speed >= ARRAY_SIZE(speed_names))
+ speed = USB_SPEED_UNKNOWN;
+ return speed_names[speed];
+}
+
But I see it already defined here
https://elixir.bootlin.com/linux/latest/source/drivers/usb/common/common.c#L72
Sorry, I didn't realize this is for u-boot :)
cheers,
-roger
enum usb_device_speed usb_get_maximum_speed(ofnode node)
{
const char *max_speed;
diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index 7d225ee..a8fa5d7 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -959,8 +959,6 @@ enum usb_device_speed {
USB_SPEED_SUPER_PLUS, /* usb 3.1 */
};
-#ifdef __KERNEL__
-
Why do you have to remove this?
/**
* usb_speed_string() - Returns human readable-name of the speed.
* @speed: The speed to return human-readable name for. If it's not
@@ -969,8 +967,6 @@ enum usb_device_speed {
*/
extern const char *usb_speed_string(enum usb_device_speed speed);
-#endif
-
enum usb_device_state {
/* NOTATTACHED isn't in the USB spec, and this state acts
* the same as ATTACHED ... but it's clearer this way.
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v5 04/10] usb: common: add define of usb_speed_string()
Hi,
On 17/08/2020 10:40, Chunfeng Yun wrote:
There is only declear of usb_speed_string(), but not define it.
s/declear/declaration
s/not define/no definition of/
Signed-off-by: Chunfeng Yun
---
v5: no changes
v4: new patch
---
drivers/usb/common/common.c | 7 +++
include/linux/usb/ch9.h | 4
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index 76f5a9c..5e5c3c3 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -49,6 +49,13 @@ static const char *const speed_names[] = {
[USB_SPEED_SUPER_PLUS] = "super-speed-plus",
};
+const char *usb_speed_string(enum usb_device_speed speed)
+{
+ if (speed < 0 || speed >= ARRAY_SIZE(speed_names))
+ speed = USB_SPEED_UNKNOWN;
+ return speed_names[speed];
+}
+
But I see it already defined here
https://elixir.bootlin.com/linux/latest/source/drivers/usb/common/common.c#L72
enum usb_device_speed usb_get_maximum_speed(ofnode node)
{
const char *max_speed;
diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index 7d225ee..a8fa5d7 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -959,8 +959,6 @@ enum usb_device_speed {
USB_SPEED_SUPER_PLUS, /* usb 3.1 */
};
-#ifdef __KERNEL__
-
Why do you have to remove this?
/**
* usb_speed_string() - Returns human readable-name of the speed.
* @speed: The speed to return human-readable name for. If it's not
@@ -969,8 +967,6 @@ enum usb_device_speed {
*/
extern const char *usb_speed_string(enum usb_device_speed speed);
-#endif
-
enum usb_device_state {
/* NOTATTACHED isn't in the USB spec, and this state acts
* the same as ATTACHED ... but it's clearer this way.
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[u-boot PATCH] phy: omap-usb2-phy: disable phy charger detect
From: Bin Liu
AM654x PG1.0 has a silicon bug that D+ is pulled high after POR, which
could cause enumeration failure with some USB hubs. Disabling the
USB2_PHY Charger Detect function will put D+ into the normal state.
Using property "ti,dis-chg-det-quirk" in the DT usb2-phy node to
enable this workaround for AM654x PG1.0.
Signed-off-by: Bin Liu
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Roger Quadros
---
drivers/phy/omap-usb2-phy.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/omap-usb2-phy.c b/drivers/phy/omap-usb2-phy.c
index 0793b97dd5..adc454ddd4 100644
--- a/drivers/phy/omap-usb2-phy.c
+++ b/drivers/phy/omap-usb2-phy.c
@@ -17,6 +17,7 @@
#include
#define OMAP_USB2_CALIBRATE_FALSE_DISCONNECT BIT(0)
+#define OMAP_USB2_DISABLE_CHG_DET BIT(1)
#define OMAP_DEV_PHY_PDBIT(0)
#define OMAP_USB2_PHY_PD BIT(28)
@@ -33,6 +34,10 @@
#define AM654_USB2_VBUS_DET_EN BIT(5)
#define AM654_USB2_VBUSVALID_DET_ENBIT(4)
+#define USB2PHY_CHRG_DET0x14
+#define USB2PHY_USE_CHG_DET_REGBIT(29)
+#define USB2PHY_DIS_CHG_DETBIT(28)
+
DECLARE_GLOBAL_DATA_PTR;
struct omap_usb2_phy {
@@ -160,6 +165,12 @@ static int omap_usb2_phy_init(struct phy *usb_phy)
writel(val, priv->phy_base + USB2PHY_ANA_CONFIG1);
}
+ if (priv->flags & OMAP_USB2_DISABLE_CHG_DET) {
+ val = readl(priv->phy_base + USB2PHY_CHRG_DET);
+ val |= USB2PHY_USE_CHG_DET_REG | USB2PHY_DIS_CHG_DET;
+ writel(val, priv->phy_base + USB2PHY_CHRG_DET);
+ }
+
return 0;
}
@@ -197,13 +208,25 @@ int omap_usb2_phy_probe(struct udevice *dev)
if (!data)
return -EINVAL;
- if (data->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT) {
- priv->phy_base = dev_read_addr_ptr(dev);
+ priv->phy_base = dev_read_addr_ptr(dev);
- if (!priv->phy_base)
- return -EINVAL;
+ if (!priv->phy_base)
+ return -EINVAL;
+
+ if (data->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT)
priv->flags |= OMAP_USB2_CALIBRATE_FALSE_DISCONNECT;
- }
+
+ /*
+* AM654x PG1.0 has a silicon bug that D+ is pulled high after
+* POR, which could cause enumeration failure with some USB hubs.
+* Disabling the USB2_PHY Charger Detect function will put D+
+* into the normal state.
+*
+* Using property "ti,dis-chg-det-quirk" in the DT usb2-phy node
+* to enable this workaround for AM654x PG1.0.
+*/
+ if (dev_read_bool(dev, "ti,dis-chg-det-quirk"))
+ priv->flags |= OMAP_USB2_DISABLE_CHG_DET;
regmap = syscon_regmap_lookup_by_phandle(dev, "syscon-phy-power");
if (!IS_ERR(regmap)) {
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[u-boot PATCH] board: ti: am57xx-idk: Prevent boot for invalid configuation
On am571x-idk there can be following configurations based on Jumper J51
and LCD panel detected.
1) J51 removed (6port): 6 port Ethernet. Disable LCD panel.
2) J51 placed (LCD) + Panel detected: 4 port Ethernet with appropriate LCD.
3) J51 placed (LCD) + Panel not detected/not supported.
Configuration 3 is considered invalid as we can't use display nor ICSS1
ethernet ports due to hardware muxing. Alert the user to fix the
configuration and prevent boot.
Alternative was to allow boot and limit to 4 port Ethernet with no display
but this involved introduction of another DTB for the kernel and was
considered not worth the hassle.
Signed-off-by: Roger Quadros
Acked-by: Suman Anna
---
board/ti/am57xx/board.c | 12
1 file changed, 12 insertions(+)
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index d70ab0c4d0..683d3aa8da 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -706,6 +706,18 @@ void am57x_idk_lcd_detect(void)
}
out:
env_set("idk_lcd", idk_lcd);
+
+ /*
+* On AM571x_IDK, no Display with J51 set to LCD is considered as an
+* invalid configuration and we prevent boot to get user attention.
+*/
+ if (board_is_am571x_idk() && am571x_idk_needs_lcd() &&
+ !strncmp(idk_lcd, "no", 2)) {
+ printf("%s: Invalid HW configuration: display not
detected/supported but J51 is set. Remove J51 to boot without display.\n",
+ __func__);
+ hang();
+ }
+
return;
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[u-boot PATCH] arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge
NB0 is bridge to SRAM and NB1 is bridge to DDR.
To ensure that SRAM transfers are not stalled due to
delays during DDR refreshes, SRAM traffic should be higher
priority (threadmap=2) than DDR traffic (threadmap=0).
This patch does just that.
This is required to fix ICSSG TX lock-ups due to delays in
MSMC transfers due to incorrect Northbridge configuration.
Signed-off-by: Roger Quadros
Acked-by: Andrew F. Davis
Acked-by: Tomi Valkeinen
Acked-by: Benoit Parrot
---
arch/arm/mach-k3/am6_init.c | 14 ++
arch/arm/mach-k3/include/mach/am6_hardware.h | 7 +++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 8d107b870b..9379b95bdb 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -86,6 +86,18 @@ static void store_boot_index_from_rom(void)
bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
}
+static void setup_am654_navss_northbridge(void)
+{
+ /*
+* NB0 is bridge to SRAM and NB1 is bridge to DDR.
+* To ensure that SRAM transfers are not stalled due to
+* delays during DDR refreshes, SRAM traffic should be higher
+* priority (threadmap=2) than DDR traffic (threadmap=0).
+*/
+ writel(0x2, NAVSS0_NBSS_NB0_CFG_BASE + NAVSS_NBSS_THREADMAP);
+ writel(0x0, NAVSS0_NBSS_NB1_CFG_BASE + NAVSS_NBSS_THREADMAP);
+}
+
void board_init_f(ulong dummy)
{
#if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS)
@@ -101,6 +113,8 @@ void board_init_f(ulong dummy)
/* Make all control module registers accessible */
ctrl_mmr_unlock();
+ setup_am654_navss_northbridge();
+
#ifdef CONFIG_CPU_V7R
disable_linefill_optimization();
setup_k3_mpu_regions();
diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h
b/arch/arm/mach-k3/include/mach/am6_hardware.h
index 6df7631545..45a5b31c52 100644
--- a/arch/arm/mach-k3/include/mach/am6_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
@@ -47,4 +47,11 @@
/* MCU SCRATCHPAD usage */
#define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE
+/* NAVSS Northbridge config */
+#defineNAVSS0_NBSS_NB0_CFG_BASE0x03802000
+#defineNAVSS0_NBSS_NB1_CFG_BASE0x03803000
+
+#defineNAVSS_NBSS_PID 0x0
+#defineNAVSS_NBSS_THREADMAP0x10
+
#endif /* __ASM_ARCH_AM6_HARDWARE_H */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[U-Boot] [uboot PATCH 1/4] phy: ti-pipe3: Use TRM recommended settings for SATA DPLL
The AM572x Technical Reference Manual, SPRUHZ6H,
Revised November 2016 [1], shows recommended settings for the
SATA DPLL in Table 26-8. DPLL CLKDCOLDO Recommended Settings.
Use those settings in the driver. The TRM does not show
a value for 20MHz SYS_CLK so we use something close to the
26MHz setting.
[1] - http://www.ti.com/lit/ug/spruhz6h/spruhz6h.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti-pipe3-phy.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/ti-pipe3-phy.c b/drivers/phy/ti-pipe3-phy.c
index e7e78e3c56..f3b071399c 100644
--- a/drivers/phy/ti-pipe3-phy.c
+++ b/drivers/phy/ti-pipe3-phy.c
@@ -346,13 +346,13 @@ static int pipe3_phy_probe(struct udevice *dev)
}
static struct pipe3_dpll_map dpll_map_sata[] = {
- {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */
- {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */
- {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
- {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */
- {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */
- {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */
- { },/* Terminator */
+ {1200, {625, 4, 4, 6, 0} }, /* 12 MHz */
+ {1680, {625, 6, 4, 7, 0} }, /* 16.8 MHz */
+ {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
+ {2000, {750, 9, 4, 6, 0} }, /* 20 MHz */
+ {2600, {750, 12, 4, 6, 0} },/* 26 MHz */
+ {3840, {625, 15, 4, 6, 0} },/* 38.4 MHz */
+ { },/* Terminator */
};
static struct pipe3_dpll_map dpll_map_usb[] = {
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [uboot PATCH 2/4] phy: ti-pipe3: Introduce mode property in driver data
Introduce a mode property in the driver data so that
we don't have to keep using "of_device_is_compatible()"
throughtout the driver.
No functional change.
Signed-off-by: Roger Quadros
---
drivers/phy/ti-pipe3-phy.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/ti-pipe3-phy.c b/drivers/phy/ti-pipe3-phy.c
index f3b071399c..935dc7afb6 100644
--- a/drivers/phy/ti-pipe3-phy.c
+++ b/drivers/phy/ti-pipe3-phy.c
@@ -54,14 +54,18 @@
#define PLL_IDLE_TIME 100 /* in milliseconds */
#define PLL_LOCK_TIME 100 /* in milliseconds */
+enum pipe3_mode { PIPE3_MODE_PCIE = 1,
+ PIPE3_MODE_SATA,
+ PIPE3_MODE_USBSS };
+
struct omap_pipe3 {
void __iomem*pll_ctrl_base;
void __iomem*power_reg;
void __iomem*pll_reset_reg;
struct pipe3_dpll_map *dpll_map;
+ enum pipe3_mode mode;
};
-
struct pipe3_dpll_params {
u16 m;
u8 n;
@@ -75,6 +79,11 @@ struct pipe3_dpll_map {
struct pipe3_dpll_params params;
};
+struct pipe3_data {
+ enum pipe3_mode mode;
+ struct pipe3_dpll_map *dpll_map;
+};
+
static inline u32 omap_pipe3_readl(void __iomem *addr, unsigned offset)
{
return readl(addr + offset);
@@ -317,6 +326,7 @@ static int pipe3_phy_probe(struct udevice *dev)
fdt_addr_t addr;
fdt_size_t sz;
struct omap_pipe3 *pipe3 = dev_get_priv(dev);
+ struct pipe3_data *data;
addr = devfdt_get_addr_size_index(dev, 2, );
if (addr == FDT_ADDR_T_NONE) {
@@ -334,14 +344,16 @@ static int pipe3_phy_probe(struct udevice *dev)
if (!pipe3->power_reg)
return -EINVAL;
- if (device_is_compatible(dev, "ti,phy-pipe3-sata")) {
+ data = (struct pipe3_data *)dev_get_driver_data(dev);
+ pipe3->mode = data->mode;
+ pipe3->dpll_map = data->dpll_map;
+
+ if (pipe3->mode == PIPE3_MODE_SATA) {
pipe3->pll_reset_reg = get_reg(dev, "syscon-pllreset");
if (!pipe3->pll_reset_reg)
return -EINVAL;
}
- pipe3->dpll_map = (struct pipe3_dpll_map *)dev_get_driver_data(dev);
-
return 0;
}
@@ -365,9 +377,19 @@ static struct pipe3_dpll_map dpll_map_usb[] = {
{ },/* Terminator */
};
+static struct pipe3_data data_usb = {
+ .mode = PIPE3_MODE_USBSS,
+ .dpll_map = dpll_map_usb,
+};
+
+static struct pipe3_data data_sata = {
+ .mode = PIPE3_MODE_SATA,
+ .dpll_map = dpll_map_sata,
+};
+
static const struct udevice_id pipe3_phy_ids[] = {
- { .compatible = "ti,phy-pipe3-sata", .data = (ulong)_map_sata },
- { .compatible = "ti,omap-usb3", .data = (ulong)_map_usb},
+ { .compatible = "ti,phy-pipe3-sata", .data = (ulong)_sata },
+ { .compatible = "ti,omap-usb3", .data = (ulong)_usb},
{ }
};
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [uboot PATCH 3/4] phy: ti-pipe3: improve DPLL stability for SATA & USB
For increased DPLL stability use the settings recommended in
the TRM [1] for PHY_RX registers for SATA and USB.
For SATA we need to use spread spectrum settings even
though we don't have spread spectrum enabled. The
suggested non-spread spectrum settings don't work.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti-pipe3-phy.c | 193 +
1 file changed, 193 insertions(+)
diff --git a/drivers/phy/ti-pipe3-phy.c b/drivers/phy/ti-pipe3-phy.c
index 935dc7afb6..b9c8591470 100644
--- a/drivers/phy/ti-pipe3-phy.c
+++ b/drivers/phy/ti-pipe3-phy.c
@@ -50,6 +50,62 @@
#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON 0x3
#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF 0x0
+/* PHY RX Registers */
+#define PIPE3_PHY_RX_ANA_PROGRAMMABILITY 0x000C
+#define INTERFACE_MASK GENMASK(31, 27)
+#define INTERFACE_SHIFT27
+#define INTERFACE_MODE_USBSS BIT(4)
+#define INTERFACE_MODE_SATA_1P5BIT(3)
+#define INTERFACE_MODE_SATA_3P0BIT(2)
+#define INTERFACE_MODE_PCIEBIT(0)
+
+#define LOSD_MASK GENMASK(17, 14)
+#define LOSD_SHIFT 14
+#define MEM_PLLDIV GENMASK(6, 5)
+
+#define PIPE3_PHY_RX_TRIM 0x001C
+#define MEM_DLL_TRIM_SEL_MASK GENMASK(31, 30)
+#define MEM_DLL_TRIM_SHIFT 30
+
+#define PIPE3_PHY_RX_DLL 0x0024
+#define MEM_DLL_PHINT_RATE_MASKGENMASK(31, 30)
+#define MEM_DLL_PHINT_RATE_SHIFT 30
+
+#define PIPE3_PHY_RX_DIGITAL_MODES 0x0028
+#define MEM_HS_RATE_MASK GENMASK(28, 27)
+#define MEM_HS_RATE_SHIFT 27
+#define MEM_OVRD_HS_RATE BIT(26)
+#define MEM_OVRD_HS_RATE_SHIFT 26
+#define MEM_CDR_FASTLOCK BIT(23)
+#define MEM_CDR_FASTLOCK_SHIFT 23
+#define MEM_CDR_LBW_MASK GENMASK(22, 21)
+#define MEM_CDR_LBW_SHIFT 21
+#define MEM_CDR_STEPCNT_MASK GENMASK(20, 19)
+#define MEM_CDR_STEPCNT_SHIFT 19
+#define MEM_CDR_STL_MASK GENMASK(18, 16)
+#define MEM_CDR_STL_SHIFT 16
+#define MEM_CDR_THR_MASK GENMASK(15, 13)
+#define MEM_CDR_THR_SHIFT 13
+#define MEM_CDR_THR_MODE BIT(12)
+#define MEM_CDR_THR_MODE_SHIFT 12
+#define MEM_CDR_2NDO_SDM_MODE BIT(11)
+#define MEM_CDR_2NDO_SDM_MODE_SHIFT11
+
+#define PIPE3_PHY_RX_EQUALIZER 0x0038
+#define MEM_EQLEV_MASK GENMASK(31, 16)
+#define MEM_EQLEV_SHIFT16
+#define MEM_EQFTC_MASK GENMASK(15, 11)
+#define MEM_EQFTC_SHIFT11
+#define MEM_EQCTL_MASK GENMASK(10, 7)
+#define MEM_EQCTL_SHIFT7
+#define MEM_OVRD_EQLEV BIT(2)
+#define MEM_OVRD_EQLEV_SHIFT 2
+#define MEM_OVRD_EQFTC BIT(1)
+#define MEM_OVRD_EQFTC_SHIFT 1
+
+#define SATA_PHY_RX_IO_AND_A2D_OVERRIDES 0x44
+#define MEM_CDR_LOS_SOURCE_MASKGENMASK(10, 9)
+#define MEM_CDR_LOS_SOURCE_SHIFT 9
#define PLL_IDLE_TIME 100 /* in milliseconds */
#define PLL_LOCK_TIME 100 /* in milliseconds */
@@ -58,12 +114,35 @@ enum pipe3_mode { PIPE3_MODE_PCIE = 1,
PIPE3_MODE_SATA,
PIPE3_MODE_USBSS };
+struct pipe3_settings {
+ u8 ana_interface;
+ u8 ana_losd;
+ u8 dig_fastlock;
+ u8 dig_lbw;
+ u8 dig_stepcnt;
+ u8 dig_stl;
+ u8 dig_thr;
+ u8 dig_thr_mode;
+ u8 dig_2ndo_sdm_mode;
+ u8 dig_hs_rate;
+ u8 dig_ovrd_hs_rate;
+ u8 dll_trim_sel;
+ u8 dll_phint_rate;
+ u8 eq_lev;
+ u8 eq_ftc;
+ u8 eq_ctl;
+ u8 eq_ovrd_lev;
+ u8 eq_ovrd_ftc;
+};
+
struct omap_pipe3 {
void __iomem*pll_ctrl_base;
+ void __iomem*phy_rx;
void __iomem*power_reg;
void __iomem*pll_reset_reg;
struct pipe3_dpll_map *dpll_map;
enum pipe3_mode mode;
+ struct pipe3_settings settings;
};
struct pipe3_dpll_params {
@@ -82,6 +161,7 @@ struct pipe3_dpll_map {
struct pipe3_data {
enum pipe3_mode mode;
struct pipe3_dpll_map *dpll_map;
+ struct pipe3_settings settings;
};
static inline u32 omap_pipe3_readl(void __iomem *addr, unsigned offset)
@@ -199,6 +279,60 @@ static void omap_control_pipe3_power(struct omap_pipe3
*pipe3, int on)
writel(val, pipe3->power_reg);
}
+static void ti_pipe3_calibrate(struct omap_pipe3 *phy)
+{
+ u32 val;
+ struct pipe3_settings *s = >settings;
+
+ val = omap_pipe3_readl(phy->phy_rx, PIPE3_PHY_RX_ANA_PROGRAMMABILITY);
+ val &= ~(INTERFACE_MASK | LOSD_MASK | MEM_PLLDIV)
[U-Boot] [uboot PATCH 4/4] phy: ti-pipe3: Fix SATA & USB PHY power up sequence
As per "Table 26-7. SATA PHY Subsystem Low-Level Programming Sequence"
in TRM [1] we need to turn on SATA_PHY_TX before SATA_PHY_RX.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti-pipe3-phy.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/phy/ti-pipe3-phy.c b/drivers/phy/ti-pipe3-phy.c
index b9c8591470..0c59552bb8 100644
--- a/drivers/phy/ti-pipe3-phy.c
+++ b/drivers/phy/ti-pipe3-phy.c
@@ -41,14 +41,14 @@
#define SATA_PLL_SOFT_RESET (1<<18)
/* PHY POWER CONTROL Register */
-#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
-#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT0xE
+#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK GENMASK(21, 14)
+#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
-#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK0xFFC0
-#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT 0x16
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK GENMASK(31, 22)
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT22
-#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON 0x3
-#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF 0x0
+#define PIPE3_PHY_RX_POWERON (0x1 << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT)
+#define PIPE3_PHY_TX_POWERON (0x2 << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT)
/* PHY RX Registers */
#define PIPE3_PHY_RX_ANA_PROGRAMMABILITY 0x000C
@@ -264,19 +264,21 @@ static void omap_control_pipe3_power(struct omap_pipe3
*pipe3, int on)
rate = rate/100;
if (on) {
- val &= ~(OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK);
- val |= OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON <<
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
- val |= rate <<
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
+ val &= ~(PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
+PIPE3_PHY_PWRCTL_CLK_FREQ_MASK);
+ val |= rate << PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
+ writel(val, pipe3->power_reg);
+
+ /* Power up TX before RX for SATA & USB */
+ val |= PIPE3_PHY_TX_POWERON;
+ writel(val, pipe3->power_reg);
+
+ val |= PIPE3_PHY_RX_POWERON;
+ writel(val, pipe3->power_reg);
} else {
- val &= ~OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK;
- val |= OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF <<
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+ val &= ~PIPE3_PHY_PWRCTL_CLK_CMD_MASK;
+ writel(val, pipe3->power_reg);
}
-
- writel(val, pipe3->power_reg);
}
static void ti_pipe3_calibrate(struct omap_pipe3 *phy)
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [uboot PATCH 0/4] phy: ti-pipe3: Match TRM sequence & settings
Hi, We need to follow the TRM sequence and settings to ensure that the DPLL & PHY operates correctly over the entire temperature range. Tested with SATA on dra7-evm. Since this is a bug fix, I will suggest to include it in current -rc. cheers, -roger Roger Quadros (4): phy: ti-pipe3: Use TRM recommended settings for SATA DPLL phy: ti-pipe3: Introduce mode property in driver data phy: ti-pipe3: improve DPLL stability for SATA & USB phy: ti-pipe3: Fix SATA & USB PHY power up sequence drivers/phy/ti-pipe3-phy.c | 281 - 1 file changed, 249 insertions(+), 32 deletions(-) -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: composite: add BOS descriptor support to composite framework
On 24/10/2019 18:44, Jean-Jacques Hiblot wrote:
+ Vignesh and Roger
On 24/10/2019 13:22, Michal Simek wrote:
po 14. 10. 2019 v 14:52 odesílatel Michal Simek
napsal:
From: T Karthik Reddy
To add usb-3.0 support to peripheral device add BOS & SS capability
descriptors to gadget composite framework.
Signed-off-by: T Karthik Reddy
Signed-off-by: Siva Durga Prasad Paladugu
Signed-off-by: Michal Simek
Reviewed-by: Roger Quadros
---
drivers/usb/gadget/composite.c | 61 ++
include/linux/usb/ch9.h | 3 ++
include/linux/usb/gadget.h | 9 +
3 files changed, 67 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index c7e762374752..618a7d5016ee 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -688,6 +688,57 @@ static void composite_setup_complete(struct usb_ep *ep,
struct usb_request *req)
req->status, req->actual, req->length);
}
+static int bos_desc(struct usb_composite_dev *cdev)
+{
+ struct usb_ext_cap_descriptor *usb_ext;
+ struct usb_bos_descriptor *bos = cdev->req->buf;
+
+ bos->bLength = USB_DT_BOS_SIZE;
+ bos->bDescriptorType = USB_DT_BOS;
+
+ bos->wTotalLength = cpu_to_le16(USB_DT_BOS_SIZE);
+ bos->bNumDeviceCaps = 0;
+
+ /*
+ * A SuperSpeed device shall include the USB2.0 extension descriptor
+ * and shall support LPM when operating in USB2.0 HS mode.
+ */
+ usb_ext = cdev->req->buf + le16_to_cpu(bos->wTotalLength);
+ bos->bNumDeviceCaps++;
+ le16_add_cpu(>wTotalLength, USB_DT_USB_EXT_CAP_SIZE);
+ usb_ext->bLength = USB_DT_USB_EXT_CAP_SIZE;
+ usb_ext->bDescriptorType = USB_DT_DEVICE_CAPABILITY;
+ usb_ext->bDevCapabilityType = USB_CAP_TYPE_EXT;
+ usb_ext->bmAttributes =
+ cpu_to_le32(USB_LPM_SUPPORT | USB_BESL_SUPPORT);
+
+ /*
+ * The Superspeed USB Capability descriptor shall be implemented
+ * by all SuperSpeed devices.
+ */
+ if (gadget_is_superspeed(cdev->gadget)) {
+ struct usb_ss_cap_descriptor *ss_cap;
+
+ ss_cap = cdev->req->buf + le16_to_cpu(bos->wTotalLength);
+ bos->bNumDeviceCaps++;
+ le16_add_cpu(>wTotalLength, USB_DT_USB_SS_CAP_SIZE);
+ ss_cap->bLength = USB_DT_USB_SS_CAP_SIZE;
+ ss_cap->bDescriptorType = USB_DT_DEVICE_CAPABILITY;
+ ss_cap->bDevCapabilityType = USB_SS_CAP_TYPE;
+ ss_cap->bmAttributes = 0; /* LTM is not supported yet */
+ ss_cap->wSpeedSupported =
+ cpu_to_le16(USB_LOW_SPEED_OPERATION |
+ USB_FULL_SPEED_OPERATION |
+ USB_HIGH_SPEED_OPERATION |
+ USB_5GBPS_OPERATION);
+ ss_cap->bFunctionalitySupport = USB_LOW_SPEED_OPERATION;
+ ss_cap->bU1devExitLat = USB_DEFAULT_U1_DEV_EXIT_LAT;
+ ss_cap->bU2DevExitLat =
+ cpu_to_le16(USB_DEFAULT_U2_DEV_EXIT_LAT);
+ }
+ return le16_to_cpu(bos->wTotalLength);
+}
+
/*
* The setup() callback implements all the ep0 functionality that's
* not handled lower down, in hardware or the hardware driver(like
@@ -776,12 +827,10 @@ composite_setup(struct usb_gadget *gadget, const struct
usb_ctrlrequest *ctrl)
value = min(w_length, (u16) value);
break;
case USB_DT_BOS:
- /*
- * The USB compliance test (USB 2.0 Command Verifier)
- * issues this request. We should not run into the
- * default path here. But return for now until
- * the superspeed support is added.
- */
+ if (gadget_is_superspeed(cdev->gadget))
+ value = bos_desc(cdev);
+ if (value >= 0)
+ value = min(w_length, (u16)value);
break;
default:
goto unknown;
diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index 264c9712a33a..989a5fcbd966 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -878,6 +878,9 @@ struct usb_ss_cap_descriptor { /* Link Power
Management */
__le16 bU2DevExitLat;
} __attribute__((packed));
+#define USB_DEFAULT_U1_DEV_EXIT_LAT 0x01 /* Less then 1 microsec */
+#define USB_DEFAULT_U2_DEV_EXIT_LAT 0x01F4 /* Less then 500 microsec */
+
#define USB_DT_USB_SS_CAP_SIZE 10
/*
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadge
Re: [U-Boot] [PATCH 00/14] net: ti: icssg: Add prueth support
On 07/08/2019 08:51, Roger Quadros wrote:
> Andreas,
>
> On 06/08/2019 18:35, Andreas Dannenberg wrote:
>> Keerthy,
>>
>> On Tue, Aug 06, 2019 at 04:08:30PM +0530, Keerthy wrote:
>>> The series adds support for icssg_prueth functionality
>>> on u-boot. This series is based on top of master branch.
>>> rproc init needs to be done from uboot command prompt.
>>> The pru/rtu firmware loading is done by prueth driver soon after
>>> config paramters are setup.
>>
>> for everybody's benefit, where does this firmware come from so one can
>> experiment with this patch series?
>>
> From here
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/prueth-fw/prueth-fw-am65x_git.bb
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/emac-lld/emac-lld.inc
>
> http://git.ti.com/keystone-rtos/emac-lld/trees/master/firmware/icss_dualmac/src
Prebuilt firmware can be obtained from AM65 procSDK [1] rootfs at
/lib/firmware/ti-pruss/am65x*.elf
[1]
http://software-dl.ti.com/processor-sdk-linux/esd/AM65X/latest/index_FDS.html
cheers,
-roger
>
>> --
>> Andreas Dannenberg
>> Texas Instruments Inc
>>
>>>
>>> Currently only slice0/1 of icssg2 instance on am6-evm
>>> is supported. i.e Both slices of icssg2 instance are supported.
>>>
>>> On u-boot prompt following commands to test icssg2_port 0 on am654-evm:
>>>
>>> setenv ethact pruss2_eth; setenv serverip 172.24.191.45; fatload mmc 1
>>> ${pru0loadaddr} am65x-pru0-prueth-fw.elf; fatload mmc 1 ${rtu0loadaddr}
>>> am65x-rtu0-prueth-fw.elf; rproc init; setenv autoload no; dhcp; tftp
>>> 0x8200 Image; tftp 0x8300 k3-am654-base-board.dtb; booti 0x8200
>>> - 0x8300
>>>
>>> This tests tftp on prueth.
>>>
>>> Note: Uboot ethernet driver architecture supports once
>>> instance per probe. So only one of the ports are supported
>>> per instance. So DT of prueth node should have either ethernet-mii0
>>> or ethernet-mii1.
>>>
>>> Keerthy (14):
>>> net: eth-uclass: eth_get_dev based on SEQ_ALIAS instead of probe order
>>> net: eth-uclass: call stop only for active devices
>>> misc: uclass: Introduce misc_init_by_ofnode
>>> soc: ti: pruss: add a misc driver for PRUSS in TI SoCs
>>> remoteproc: pruss: add PRU remoteproc driver
>>> net: ti: icssg-prueth: Add ICSSG ethernet driver
>>> net: ti: icssg-prueth: Workaround to shutdown the prueth firmware
>>> arm: dts: k3-am65-main: Add msmc_ram node
>>> arm: dts: k3-am654-base-board-u-boot: Add icssg specific msmc_ram
>>> carveout nodes
>>> arm: dts: k3-am65-main: Add scm_conf node
>>> arm: dts: k3-am65-main: Add pruss nodes for ICSSG2
>>> arm64: dts: ti: am654-base-board: add ICSSG2 Ethernet support
>>> configs: am65x_evm_a53_defconfig: Enable CONFIG_REMOTEPROC_TI_PRU
>>> configs: am65x_evm_a53_defconfig: Enable CONFIG_CMD_REMOTEPROC
>>>
>>> arch/arm/dts/k3-am65-main.dtsi | 212
>>> arch/arm/dts/k3-am65.dtsi| 4 +-
>>> arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 130 +
>>> configs/am65x_evm_a53_defconfig | 5 +
>>> drivers/misc/misc-uclass.c | 25 +
>>> drivers/net/ti/Kconfig | 8 +
>>> drivers/net/ti/Makefile | 1 +
>>> drivers/net/ti/icssg-prueth.c| 525 +++
>>> drivers/net/ti/icssg.h | 31 ++
>>> drivers/net/ti/icssg_classifier.c| 397 ++
>>> drivers/remoteproc/Kconfig | 11 +
>>> drivers/remoteproc/Makefile | 1 +
>>> drivers/remoteproc/pru_rproc.c | 384 ++
>>> drivers/soc/ti/Kconfig | 13 +
>>> drivers/soc/ti/Makefile | 1 +
>>> drivers/soc/ti/pruss.c | 143 +
>>> include/misc.h | 9 +
>>> include/ti-pruss.h | 13 +
>>> net/eth-uclass.c | 7 +-
>>> 19 files changed, 1916 insertions(+), 4 deletions(-)
>>> create mode 100644 drivers/net/ti/icssg-prueth.c
>>> create mode 100644 drivers/net/ti/icssg.h
>>> create mode 100644 drivers/net/ti/icssg_classifier.c
>>> create mode 100644 drivers/remoteproc/pru_rproc.c
>>> create mode 100644 drivers/soc/ti/pruss.c
>>> create mode 100644 include/ti-pruss.h
>>>
>>> --
>>> 2.17.1
>>>
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] net: ti: icssg: Add prueth support
Andreas,
On 06/08/2019 18:35, Andreas Dannenberg wrote:
> Keerthy,
>
> On Tue, Aug 06, 2019 at 04:08:30PM +0530, Keerthy wrote:
>> The series adds support for icssg_prueth functionality
>> on u-boot. This series is based on top of master branch.
>> rproc init needs to be done from uboot command prompt.
>> The pru/rtu firmware loading is done by prueth driver soon after
>> config paramters are setup.
>
> for everybody's benefit, where does this firmware come from so one can
> experiment with this patch series?
>
From here
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/prueth-fw/prueth-fw-am65x_git.bb
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/emac-lld/emac-lld.inc
http://git.ti.com/keystone-rtos/emac-lld/trees/master/firmware/icss_dualmac/src
cheers,
-roger
> --
> Andreas Dannenberg
> Texas Instruments Inc
>
>>
>> Currently only slice0/1 of icssg2 instance on am6-evm
>> is supported. i.e Both slices of icssg2 instance are supported.
>>
>> On u-boot prompt following commands to test icssg2_port 0 on am654-evm:
>>
>> setenv ethact pruss2_eth; setenv serverip 172.24.191.45; fatload mmc 1
>> ${pru0loadaddr} am65x-pru0-prueth-fw.elf; fatload mmc 1 ${rtu0loadaddr}
>> am65x-rtu0-prueth-fw.elf; rproc init; setenv autoload no; dhcp; tftp
>> 0x8200 Image; tftp 0x8300 k3-am654-base-board.dtb; booti 0x8200
>> - 0x8300
>>
>> This tests tftp on prueth.
>>
>> Note: Uboot ethernet driver architecture supports once
>> instance per probe. So only one of the ports are supported
>> per instance. So DT of prueth node should have either ethernet-mii0
>> or ethernet-mii1.
>>
>> Keerthy (14):
>> net: eth-uclass: eth_get_dev based on SEQ_ALIAS instead of probe order
>> net: eth-uclass: call stop only for active devices
>> misc: uclass: Introduce misc_init_by_ofnode
>> soc: ti: pruss: add a misc driver for PRUSS in TI SoCs
>> remoteproc: pruss: add PRU remoteproc driver
>> net: ti: icssg-prueth: Add ICSSG ethernet driver
>> net: ti: icssg-prueth: Workaround to shutdown the prueth firmware
>> arm: dts: k3-am65-main: Add msmc_ram node
>> arm: dts: k3-am654-base-board-u-boot: Add icssg specific msmc_ram
>> carveout nodes
>> arm: dts: k3-am65-main: Add scm_conf node
>> arm: dts: k3-am65-main: Add pruss nodes for ICSSG2
>> arm64: dts: ti: am654-base-board: add ICSSG2 Ethernet support
>> configs: am65x_evm_a53_defconfig: Enable CONFIG_REMOTEPROC_TI_PRU
>> configs: am65x_evm_a53_defconfig: Enable CONFIG_CMD_REMOTEPROC
>>
>> arch/arm/dts/k3-am65-main.dtsi | 212
>> arch/arm/dts/k3-am65.dtsi| 4 +-
>> arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 130 +
>> configs/am65x_evm_a53_defconfig | 5 +
>> drivers/misc/misc-uclass.c | 25 +
>> drivers/net/ti/Kconfig | 8 +
>> drivers/net/ti/Makefile | 1 +
>> drivers/net/ti/icssg-prueth.c| 525 +++
>> drivers/net/ti/icssg.h | 31 ++
>> drivers/net/ti/icssg_classifier.c| 397 ++
>> drivers/remoteproc/Kconfig | 11 +
>> drivers/remoteproc/Makefile | 1 +
>> drivers/remoteproc/pru_rproc.c | 384 ++
>> drivers/soc/ti/Kconfig | 13 +
>> drivers/soc/ti/Makefile | 1 +
>> drivers/soc/ti/pruss.c | 143 +
>> include/misc.h | 9 +
>> include/ti-pruss.h | 13 +
>> net/eth-uclass.c | 7 +-
>> 19 files changed, 1916 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/net/ti/icssg-prueth.c
>> create mode 100644 drivers/net/ti/icssg.h
>> create mode 100644 drivers/net/ti/icssg_classifier.c
>> create mode 100644 drivers/remoteproc/pru_rproc.c
>> create mode 100644 drivers/soc/ti/pruss.c
>> create mode 100644 include/ti-pruss.h
>>
>> --
>> 2.17.1
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot AM335x board.c `ethaddr` changes.
Duane, On 28/11/17 10:07, Duane Leslie wrote: > Roger, > > I’m not clear on the correct way to report bugs in U-Boot, but the change you > signed off in > https://github.com/u-boot/u-boot/commit/f411b5cca48f0eee9443b85e7b75a46356bd2327 > disabled the setting of the `ethaddr` environment variable in the SPL Build > meaning that it is no longer possible to produce a version of the SPL capable > of performing and ethernet network boot. You could just report on the u-boot mailing list, (now in cc). > > I’m not sure what the preferred solution is but I have modified my version so > that `ethaddr` is set to the `macid0` value as follows the ROM ethernet boot, > and I don’t know what the URNDIS ROM driver uses but I loaded `macid1` into > `usbnet_devaddr` as a placeholder. > > It’d be nice to have an official solution to this especially since it allows > remote device recovery of IoT products over ethernet (no host PC required). Could you please post your patch to the u-boot list. Then hopefully someone (Lokesh?) will suggest if anything better can be done. Thanks. > > Regards, > > Duane. -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: ks2: README: Update NAND wording
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 10/08/17 05:29, Franklin S Cooper Jr wrote: > Traditional KS2 devices supported NAND via the AEMIF peripheral. However, > 66AK2G doesn't use the AEMIF but rather the GPMC for NAND. Therefore, > clarify some statements to indicate only certain devices have AEMIF and > in other places just say NAND instead of AEMIF NAND > > Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com> Acked-by: Roger Quadros <rog...@ti.com> > --- > board/ti/ks2_evm/README | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/board/ti/ks2_evm/README b/board/ti/ks2_evm/README > index 5430c7d..a26b7f8 100644 > --- a/board/ti/ks2_evm/README > +++ b/board/ti/ks2_evm/README > @@ -61,7 +61,7 @@ configs/k2g_evm_defconfig > > Supported boot modes: > - SPI NOR boot > - - AEMIF NAND boot > + - AEMIF NAND boot (K2E, K2L and K2HK) > - UART boot > - MMC boot (Only on K2G) > > @@ -69,7 +69,7 @@ Supported image formats: > - u-boot.bin: for loading and running u-boot.bin through > Texas Instruments code composure studio (CCS) and for UART boot. > - u-boot-spi.gph: gpimage for programming SPI NOR flash for SPI NOR boot > - - MLO: gpimage for programming AEMIF NAND flash for NAND boot, MMC boot. > + - MLO: gpimage for programming NAND flash for NAND boot, MMC boot. > > Build instructions: > === > -- cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [u-boot PATCH v5 04/10] ti: common: board_detect: commodify ethaddr environment setting code
On 15/03/17 16:46, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rog...@ti.com> writes:
>>> On Tue, Mar 14, 2017 at 3:05 PM Roger Quadros <rog...@ti.com
>>> <mailto:rog...@ti.com>> wrote:
>>>
>>> +void board_ti_set_ethaddr(int index)
>>> +{
>>> + uint8_t mac_addr[6];
>>> + int i;
>>> + u64 mac1, mac2;
>>> + u8 mac_addr1[6], mac_addr2[6];
>>> + int num_macs;
>>> + /*
>>> +* Export any Ethernet MAC addresses from EEPROM.
>>> +* The 2 MAC addresses in EEPROM define the address range.
>>> +*/
>>> + board_ti_get_eth_mac_addr(0, mac_addr1);
>>> + board_ti_get_eth_mac_addr(1, mac_addr2);
>>> +
>>> + if (is_valid_ethaddr(mac_addr1) && is_valid_ethaddr(mac_addr2))
>>> {
>>> + mac1 = mac_to_u64(mac_addr1);
>>> + mac2 = mac_to_u64(mac_addr2);
>>> +
>>> + /* must contain an address range */
>>> + num_macs = mac2 - mac1 + 1;
>>> + if (num_macs <= 0)
>>> + return;
>>>
>>>
>>> seems like there's still one minor improvement here:
>>>
>>> If num_macs < 0, then it could be that mac1 and mac2 are swapped.
>>>
>>> Perhaps test for that ?
>>>
>>> if (num_macs == 0)
>>> bail();
>>>
>>> if (num_macs < 0) {
>>> if ((mac1 - mac2 + 1) < 50) {
>>> num_macs = mac1 - mac2 + 1;
>>> mac1 ^= mac2;
>>> mac2 ^= mac1;
>>> mac1 ^= mac2;
>>> [...]
>>>
>>> don't know how much this may help, it's a judgment call, I suppose
>>
>> We don't have any boards with swapped mac1 and mac2. We'd like to
>
> in that case, why would (mac2-mac1+1) ever be < 0?
>
For incorrectly programmed boards in pre-production probably.
--
cheers,
-roger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [u-boot PATCH v5 04/10] ti: common: board_detect: commodify ethaddr environment setting code
Hi,
On 14/03/17 17:54, Felipe Balbi wrote:
> Hi,
>
> On Tue, Mar 14, 2017 at 3:05 PM Roger Quadros <rog...@ti.com
> <mailto:rog...@ti.com>> wrote:
>
> +void board_ti_set_ethaddr(int index)
> +{
> + uint8_t mac_addr[6];
> + int i;
> + u64 mac1, mac2;
> + u8 mac_addr1[6], mac_addr2[6];
> + int num_macs;
> + /*
> +* Export any Ethernet MAC addresses from EEPROM.
> +* The 2 MAC addresses in EEPROM define the address range.
> +*/
> + board_ti_get_eth_mac_addr(0, mac_addr1);
> + board_ti_get_eth_mac_addr(1, mac_addr2);
> +
> + if (is_valid_ethaddr(mac_addr1) && is_valid_ethaddr(mac_addr2)) {
> + mac1 = mac_to_u64(mac_addr1);
> + mac2 = mac_to_u64(mac_addr2);
> +
> + /* must contain an address range */
> + num_macs = mac2 - mac1 + 1;
> + if (num_macs <= 0)
> + return;
>
>
> seems like there's still one minor improvement here:
>
> If num_macs < 0, then it could be that mac1 and mac2 are swapped.
>
> Perhaps test for that ?
>
> if (num_macs == 0)
> bail();
>
> if (num_macs < 0) {
> if ((mac1 - mac2 + 1) < 50) {
> num_macs = mac1 - mac2 + 1;
> mac1 ^= mac2;
> mac2 ^= mac1;
> mac1 ^= mac2;
> [...]
>
> don't know how much this may help, it's a judgment call, I suppose
We don't have any boards with swapped mac1 and mac2. We'd like to
keep it that way and catch any new boards with eeprom errors early so I'd
rather not have this enhancement.
--
cheers,
-roger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [u-boot PATCH v5 04/10] ti: common: board_detect: commodify ethaddr environment setting code
Keystone and OMAP platforms will need this to set ethernet
MAC addresses from board EEPROM.
Signed-off-by: Roger Quadros <rog...@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvu...@ti.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
---
v5:
- Set upto 50 MAC addresses if more than 50 are provided in board EEPROM.
board/ti/common/board_detect.c | 62 ++
board/ti/common/board_detect.h | 12
2 files changed, 74 insertions(+)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index a5dba94..c55e24e 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -314,3 +314,65 @@ void __maybe_unused set_board_info_env(char *name)
else
setenv("board_serial", unknown);
}
+
+static u64 mac_to_u64(u8 mac[6])
+{
+ int i;
+ u64 addr = 0;
+
+ for (i = 0; i < 6; i++) {
+ addr <<= 8;
+ addr |= mac[i];
+ }
+
+ return addr;
+}
+
+static void u64_to_mac(u64 addr, u8 mac[6])
+{
+ mac[5] = addr;
+ mac[4] = addr >> 8;
+ mac[3] = addr >> 16;
+ mac[2] = addr >> 24;
+ mac[1] = addr >> 32;
+ mac[0] = addr >> 40;
+}
+
+void board_ti_set_ethaddr(int index)
+{
+ uint8_t mac_addr[6];
+ int i;
+ u64 mac1, mac2;
+ u8 mac_addr1[6], mac_addr2[6];
+ int num_macs;
+ /*
+* Export any Ethernet MAC addresses from EEPROM.
+* The 2 MAC addresses in EEPROM define the address range.
+*/
+ board_ti_get_eth_mac_addr(0, mac_addr1);
+ board_ti_get_eth_mac_addr(1, mac_addr2);
+
+ if (is_valid_ethaddr(mac_addr1) && is_valid_ethaddr(mac_addr2)) {
+ mac1 = mac_to_u64(mac_addr1);
+ mac2 = mac_to_u64(mac_addr2);
+
+ /* must contain an address range */
+ num_macs = mac2 - mac1 + 1;
+ if (num_macs <= 0)
+ return;
+
+ if (num_macs > 50) {
+ printf("%s: Too many MAC addresses: %d. Limiting to
50\n",
+ __func__, num_macs);
+ num_macs = 50;
+ }
+
+ for (i = 0; i < num_macs; i++) {
+ u64_to_mac(mac1 + i, mac_addr);
+ if (is_valid_ethaddr(mac_addr)) {
+ eth_setenv_enetaddr_by_index("eth", i + index,
+mac_addr);
+ }
+ }
+ }
+}
diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
index 52b0075..88b0a59 100644
--- a/board/ti/common/board_detect.h
+++ b/board/ti/common/board_detect.h
@@ -193,4 +193,16 @@ u64 board_ti_get_emif2_size(void);
*/
void set_board_info_env(char *name);
+/**
+ * board_ti_set_ethaddr- Sets the ethaddr environment from EEPROM
+ * @index: The first ethaddr environment variable to set
+ *
+ * EEPROM should be already read before calling this function.
+ * The EEPROM contains 2 MAC addresses which define the MAC address
+ * range (i.e. first and last MAC address).
+ * This function sets the ethaddr environment variable for all
+ * the available MAC addresses starting from ethaddr.
+ */
+void board_ti_set_ethaddr(int index);
+
#endif /* __BOARD_DETECT_H */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
