Re: [U-Boot] [PATCH v1 06/15] dm: clk: imx: Add support for controlling imx6q clocks via Driver Model
On Tue, Jan 29, 2019 at 12:46 PM Lukasz Majewski wrote:
>
> Hi Stefano, Fabio,
>
> > Hi Lukasz,
> >
> > On 21/01/19 15:19, Lukasz Majewski wrote:
> > > Hi Fabio,
> > >
> > >> Hi Lukasz,
> > >>
> > >> On Sat, Jan 19, 2019 at 7:15 AM Lukasz Majewski
> > >> wrote:
> > >>> +static ulong imx6q_clk_get_rate(struct clk *clk)
> > >>> +{
> > >>> + ulong rate = 0;
> > >>> +
> > >>> + debug("%s(#%lu)\n", __func__, clk->id);
> > >>> +
> > >>> + switch (clk->id) {
> > >>> + case IMX6QDL_CLK_ECSPI1:
> > >>> + case IMX6QDL_CLK_ECSPI2:
> > >>> + case IMX6QDL_CLK_ECSPI3:
> > >>> + case IMX6QDL_CLK_ECSPI4:
> > >>> + return imx6_get_cspi_clk();
> > >>> +
> > >>> + case IMX6QDL_CLK_USDHC1:
> > >>> + case IMX6QDL_CLK_USDHC2:
> > >>> + case IMX6QDL_CLK_USDHC3:
> > >>> + case IMX6QDL_CLK_USDHC4:
> > >>> + return imx6_get_usdhc_clk(clk->id -
> > >>> IMX6QDL_CLK_USDHC1);
> > >>
> > >> I don't think this scales well as this needs to grow for all other
> > >> peripherals and for each port instance.
> > >
> >
> > I am hiiting the same doubts as Fabio when I reviewed Peng's patches
> > with clocks for i.MX8M. The current approach was introduced some years
> > ago with i.MX5, but it does not fit well now and it does not scale.
> >
> >
> > > The rationale regarding this approach:
> > >
> > > 1. Reuse the clock.c code for iMX6Q as much as possible.
> > >
> > > 2, This code is based on the clk-imx8q.c file - hence the question
> > > why the Linux clock API was not ported for this new SoC?.
> >
> > Many reasons, first there was already a set of functions to get / set
> > clocks coming from previos i.MX platforms, and this API was simply
> > reused. And nobody was in charge to port the clock API.
> >
> > >
> > >>
> > >> If we are adding a clock driver for mx6, why don't we add it just
> > >> like the kernel one?
> > >
> > > I can try to port the Linux code, but IMHO it would be feasible to
> > > port only relevant (ECSPI, USDHC) parts of it (not all as I cannot
> > > test it all properly).
> >
> > Fully agree. Further parts will be added on demand. Less is better. I
> > disagree to add not tested code.
>
> The work is in progress - I will add the same directory structure as
> Linux's Common Clock Framework [CCF]. I shall finish in 2-3 days.
>
> There are a few problems to tackle (when porting code from Linux):
Just to add my experience with previous CLK support series[1]. Do we
really need to port it from Linux, because I'm thinking we can manage
it as simple as other SoC support in U-Boot.(I have few clocks
addition on this series other than ENET)
What do you think?
[1] https://patchwork.ozlabs.org/cover/950964/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 06/15] dm: clk: imx: Add support for controlling imx6q clocks via Driver Model
Hi Stefano, Fabio,
> Hi Lukasz,
>
> On 21/01/19 15:19, Lukasz Majewski wrote:
> > Hi Fabio,
> >
> >> Hi Lukasz,
> >>
> >> On Sat, Jan 19, 2019 at 7:15 AM Lukasz Majewski
> >> wrote:
> >>> +static ulong imx6q_clk_get_rate(struct clk *clk)
> >>> +{
> >>> + ulong rate = 0;
> >>> +
> >>> + debug("%s(#%lu)\n", __func__, clk->id);
> >>> +
> >>> + switch (clk->id) {
> >>> + case IMX6QDL_CLK_ECSPI1:
> >>> + case IMX6QDL_CLK_ECSPI2:
> >>> + case IMX6QDL_CLK_ECSPI3:
> >>> + case IMX6QDL_CLK_ECSPI4:
> >>> + return imx6_get_cspi_clk();
> >>> +
> >>> + case IMX6QDL_CLK_USDHC1:
> >>> + case IMX6QDL_CLK_USDHC2:
> >>> + case IMX6QDL_CLK_USDHC3:
> >>> + case IMX6QDL_CLK_USDHC4:
> >>> + return imx6_get_usdhc_clk(clk->id -
> >>> IMX6QDL_CLK_USDHC1);
> >>
> >> I don't think this scales well as this needs to grow for all other
> >> peripherals and for each port instance.
> >
>
> I am hiiting the same doubts as Fabio when I reviewed Peng's patches
> with clocks for i.MX8M. The current approach was introduced some years
> ago with i.MX5, but it does not fit well now and it does not scale.
>
>
> > The rationale regarding this approach:
> >
> > 1. Reuse the clock.c code for iMX6Q as much as possible.
> >
> > 2, This code is based on the clk-imx8q.c file - hence the question
> > why the Linux clock API was not ported for this new SoC?.
>
> Many reasons, first there was already a set of functions to get / set
> clocks coming from previos i.MX platforms, and this API was simply
> reused. And nobody was in charge to port the clock API.
>
> >
> >>
> >> If we are adding a clock driver for mx6, why don't we add it just
> >> like the kernel one?
> >
> > I can try to port the Linux code, but IMHO it would be feasible to
> > port only relevant (ECSPI, USDHC) parts of it (not all as I cannot
> > test it all properly).
>
> Fully agree. Further parts will be added on demand. Less is better. I
> disagree to add not tested code.
The work is in progress - I will add the same directory structure as
Linux's Common Clock Framework [CCF]. I shall finish in 2-3 days.
There are a few problems to tackle (when porting code from Linux):
1. As it is now - for IMX6Q we need a static table to store clock
pointers. It is around 1KiB of SRAM/SDRAM. This is _a_lot_ for SPL.
For u-boot proper this is not a huge problem.
2. The SPL shall use OF_PLATDATA, as we do need clock management mostly
in SPL. Moreover, I do think that SPL will be bigger (this is a _real_
problem, IMHO).
3. The CCF design needs to be fitted into U-Boot's Driver Model - this
is achievable. The most annoying problem is the lack of .get_rate()
method in the CCF's API.
4. The CCF driver for imx6q uses
clks: ccm@020c4000 {
}
Node as a "manager". In its probe we create other (proper) clocks
(hierarchy). Also, this driver is a starting point for getting access
to other clocks.
As said above - I will first post the CCF port very similar to
Barebox/Linux. Afterwards, we can decide if and how we optimise it.
>
> >
> >>
> >> Barebox imports the clock driver from the kernel and it is much
> >> cleaner:
> >> https://git.pengutronix.de/cgit/barebox/tree/drivers/clk/imx/clk-imx6.c
> >
> > Yes, it has been trimmed (...a bit...) when compared to original
> > v4.20 :-) .
> >
> Best regards,
> Stefano
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpTAU33mjyMR.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] soc: ti: k3: add navss ringacc driver
From: Grygorii Strashko The Ring Accelerator (RINGACC or RA) provides hardware acceleration to enable straightforward passing of work between a producer and a consumer. There is one RINGACC module per NAVSS on TI AM65x SoCs. The RINGACC converts constant-address read and write accesses to equivalent read or write accesses to a circular data structure in memory. The RINGACC eliminates the need for each DMA controller which needs to access ring elements from having to know the current state of the ring (base address, current offset). The DMA controller performs a read or write access to a specific address range (which maps to the source interface on the RINGACC) and the RINGACC replaces the address for the transaction with a new address which corresponds to the head or tail element of the ring (head for reads, tail for writes). Since the RINGACC maintains the state, multiple DMA controllers or channels are allowed to coherently share the same rings as applicable. The RINGACC is able to place data which is destined towards software into cached memory directly. Supported ring modes: - Ring Mode - Messaging Mode - Credentials Mode - Queue Manager Mode TI-SCI integration: Texas Instrument's System Control Interface (TI-SCI) Message Protocol now has control over Ringacc module resources management (RM) and Rings configuration. The Ringacc driver manages Rings allocation by itself now and requests TI-SCI firmware to allocate and configure specific Rings only. It's done this way because, Linux driver implements two stage Rings allocation and configuration (allocate ring and configure ring) while TI-SCI Message Protocol supports only one combined operation (allocate+configure). Signed-off-by: Grygorii Strashko Signed-off-by: Vignesh R --- drivers/Kconfig |2 + drivers/soc/Kconfig |5 + drivers/soc/Makefile|1 + drivers/soc/ti/Kconfig | 20 + drivers/soc/ti/Makefile |5 + drivers/soc/ti/k3-navss-ringacc.c | 1096 +++ include/linux/soc/ti/k3-navss-ringacc.h | 246 + 7 files changed, 1375 insertions(+) create mode 100644 drivers/soc/Kconfig create mode 100644 drivers/soc/ti/Kconfig create mode 100644 drivers/soc/ti/Makefile create mode 100644 drivers/soc/ti/k3-navss-ringacc.c create mode 100644 include/linux/soc/ti/k3-navss-ringacc.h diff --git a/drivers/Kconfig b/drivers/Kconfig index e9fbadd13d5a..1eedb3462b0a 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -96,6 +96,8 @@ source "drivers/smem/Kconfig" source "drivers/sound/Kconfig" +source "drivers/soc/Kconfig" + source "drivers/spi/Kconfig" source "drivers/spmi/Kconfig" diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig new file mode 100644 index ..7b4e4d613088 --- /dev/null +++ b/drivers/soc/Kconfig @@ -0,0 +1,5 @@ +menu "SOC (System On Chip) specific Drivers" + +source "drivers/soc/ti/Kconfig" + +endmenu diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 42037f99d587..8b7ead546e1c 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -3,3 +3,4 @@ # Makefile for the U-Boot SOC specific device drivers. obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/ +obj-$(CONFIG_SOC_TI) += ti/ diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig new file mode 100644 index ..8c0f3c07b23f --- /dev/null +++ b/drivers/soc/ti/Kconfig @@ -0,0 +1,20 @@ +# SPDX-License-Identifier: GPL-2.0+ + +menuconfig SOC_TI + bool "TI SOC drivers support" + +if SOC_TI + +config TI_K3_NAVSS_RINGACC + bool "K3 Ring accelerator Sub System" + depends on ARCH_K3 + select MISC + help + Say y here to support the K3 AM65x Ring accelerator module. + The Ring Accelerator (RINGACC or RA) provides hardware acceleration + to enable straightforward passing of work between a producer + and a consumer. There is one RINGACC module per NAVSS on TI AM65x SoCs + If unsure, say N. + + +endif # SOC_TI diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile new file mode 100644 index ..63e21aaad40f --- /dev/null +++ b/drivers/soc/ti/Makefile @@ -0,0 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# TI K3 SOC drivers +# +obj-$(CONFIG_TI_K3_NAVSS_RINGACC) += k3-navss-ringacc.o diff --git a/drivers/soc/ti/k3-navss-ringacc.c b/drivers/soc/ti/k3-navss-ringacc.c new file mode 100644 index ..aeee9da47602 --- /dev/null +++ b/drivers/soc/ti/k3-navss-ringacc.c @@ -0,0 +1,1096 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * TI K3 AM65x NAVSS Ring accelerator Manager (RA) subsystem driver + * + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define set_bit(bit, bitmap) __set_bit(bit, bitmap) +#define clear_bit(bit, bitmap) __clear_bit(bit,
[U-Boot] [PATCH v3 3/7] soc: ti: k3: add CPPI5 description and helpers
From: Grygorii Strashko
Add TI Communications Port Programming Interface (CPPI) 5
interface description and helpers
Signed-off-by: Grygorii Strashko
Signed-off-by: Vignesh R
---
include/linux/soc/ti/cppi5.h | 995 +++
1 file changed, 995 insertions(+)
create mode 100644 include/linux/soc/ti/cppi5.h
diff --git a/include/linux/soc/ti/cppi5.h b/include/linux/soc/ti/cppi5.h
new file mode 100644
index ..34038b31f702
--- /dev/null
+++ b/include/linux/soc/ti/cppi5.h
@@ -0,0 +1,995 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * CPPI5 descriptors interface
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
+ */
+
+#ifndef __TI_CPPI5_H__
+#define __TI_CPPI5_H__
+
+#include
+#include
+
+/**
+ * Descriptor header, present in all types of descriptors
+ */
+struct cppi5_desc_hdr_t {
+ u32 pkt_info0; /* Packet info word 0 (n/a in Buffer desc) */
+ u32 pkt_info1; /* Packet info word 1 (n/a in Buffer desc) */
+ u32 pkt_info2; /* Packet info word 2 Buffer reclamation info */
+ u32 src_dst_tag; /* Packet info word 3 (n/a in Buffer desc) */
+} __packed;
+
+/**
+ * Host-mode packet and buffer descriptor definition
+ */
+struct cppi5_host_desc_t {
+ struct cppi5_desc_hdr_t hdr;
+ u64 next_desc; /* w4/5: Linking word */
+ u64 buf_ptr;/* w6/7: Buffer pointer */
+ u32 buf_info1; /* w8: Buffer valid data length */
+ u32 org_buf_len; /* w9: Original buffer length */
+ u64 org_buf_ptr; /* w10/11: Original buffer pointer */
+ u32 epib[0];/* Extended Packet Info Data (optional, 4 words) */
+ /*
+* Protocol Specific Data (optional, 0-128 bytes in multiples of 4),
+* and/or Other Software Data (0-N bytes, optional)
+*/
+} __packed;
+
+#define CPPI5_DESC_MIN_ALIGN (16U)
+
+#define CPPI5_INFO0_HDESC_EPIB_SIZE(16U)
+#define CPPI5_INFO0_HDESC_PSDATA_MAX_SIZE (128U)
+
+#define CPPI5_INFO0_HDESC_TYPE_SHIFT (30U)
+#define CPPI5_INFO0_HDESC_TYPE_MASKGENMASK(31, 30)
+#define CPPI5_INFO0_DESC_TYPE_VAL_HOST (1U)
+#define CPPI5_INFO0_DESC_TYPE_VAL_MONO (2U)
+#define CPPI5_INFO0_DESC_TYPE_VAL_TR (3U)
+#define CPPI5_INFO0_HDESC_EPIB_PRESENT BIT(29)
+/*
+ * Protocol Specific Words location:
+ * 0 - located in the descriptor,
+ * 1 = located in the SOP Buffer immediately prior to the data.
+ */
+#define CPPI5_INFO0_HDESC_PSINFO_LOCATION BIT(28)
+#define CPPI5_INFO0_HDESC_PSINFO_SIZE_SHIFT(22U)
+#define CPPI5_INFO0_HDESC_PSINFO_SIZE_MASK GENMASK(27, 22)
+#define CPPI5_INFO0_HDESC_PKTLEN_SHIFT (0)
+#define CPPI5_INFO0_HDESC_PKTLEN_MASK GENMASK(21, 0)
+
+#define CPPI5_INFO1_DESC_PKTERROR_SHIFT(28U)
+#define CPPI5_INFO1_DESC_PKTERROR_MASK GENMASK(31, 28)
+#define CPPI5_INFO1_HDESC_PSFLGS_SHIFT (24U)
+#define CPPI5_INFO1_HDESC_PSFLGS_MASK GENMASK(27, 24)
+#define CPPI5_INFO1_DESC_PKTID_SHIFT (14U)
+#define CPPI5_INFO1_DESC_PKTID_MASKGENMASK(23, 14)
+#define CPPI5_INFO1_DESC_FLOWID_SHIFT (0)
+#define CPPI5_INFO1_DESC_FLOWID_MASK GENMASK(13, 0)
+
+#define CPPI5_INFO2_HDESC_PKTTYPE_SHIFT(27U)
+#define CPPI5_INFO2_HDESC_PKTTYPE_MASK GENMASK(31, 27)
+/* Return Policy: 0 - Entire packet 1 - Each buffer */
+#define CPPI5_INFO2_HDESC_RETPOLICYBIT(18)
+/*
+ * Early Return:
+ * 0 = desc pointers should be returned after all reads have been completed
+ * 1 = desc pointers should be returned immediately upon fetching
+ * the descriptor and beginning to transfer data.
+ */
+#define CPPI5_INFO2_HDESC_EARLYRET BIT(17)
+/*
+ * Return Push Policy:
+ * 0 = Descriptor must be returned to tail of queue
+ * 1 = Descriptor must be returned to head of queue
+ */
+#define CPPI5_INFO2_DESC_RETPUSHPOLICY BIT(16)
+#define CPPI5_INFO2_DESC_RETQ_SHIFT(0)
+#define CPPI5_INFO2_DESC_RETQ_MASK GENMASK(15, 0)
+
+#define CPPI5_INFO3_DESC_SRCTAG_SHIFT (16U)
+#define CPPI5_INFO3_DESC_SRCTAG_MASK GENMASK(31, 16)
+#define CPPI5_INFO3_DESC_DSTTAG_SHIFT (0)
+#define CPPI5_INFO3_DESC_DSTTAG_MASK GENMASK(15, 0)
+
+#define CPPI5_BUFINFO1_HDESC_DATA_LEN_SHIFT(0)
+#define CPPI5_BUFINFO1_HDESC_DATA_LEN_MASK GENMASK(27, 0)
+
+#define CPPI5_OBUFINFO0_HDESC_BUF_LEN_SHIFT(0)
+#define CPPI5_OBUFINFO0_HDESC_BUF_LEN_MASK GENMASK(27, 0)
+
+/*
+ * Host Packet Descriptor Extended Packet Info Block
+ */
+struct cppi5_desc_epib_t {
+ u32 timestamp; /* w0: application specific timestamp */
+ u32 sw_info0; /* w1: Software Info 0 */
+ u32 sw_info1; /* w2: Software Info 1 */
+ u32 sw_info2; /* w3: Software Info 2 */
+};
+
+/**
+ * Monolithic-mode packet descriptor
+ */
+struct cppi5_monolithic_desc_t {
+ struct cppi5_desc_hdr_t hdr;
+ u32 epib[0];/* Ext
[U-Boot] [PATCH v3 5/7] soc: keystone: Merge into TI specific directory
Merge drivers/soc/keystone/ into drivers/soc/ti/
and convert CONFIG_TI_KEYSTONE_SERDES into Kconfig.
Signed-off-by: Vignesh R
---
arch/arm/mach-keystone/Kconfig | 8
drivers/soc/Makefile | 1 -
drivers/soc/keystone/Makefile | 3 ---
drivers/soc/ti/Kconfig | 6 ++
drivers/soc/ti/Makefile| 5 ++---
drivers/soc/{keystone => ti}/keystone_serdes.c | 0
include/configs/ti_armv7_keystone2.h | 3 ---
scripts/config_whitelist.txt | 1 -
8 files changed, 16 insertions(+), 11 deletions(-)
delete mode 100644 drivers/soc/keystone/Makefile
rename drivers/soc/{keystone => ti}/keystone_serdes.c (100%)
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index d24596eccb0d..e06eba5aea1f 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -9,18 +9,24 @@ config TARGET_K2HK_EVM
select SPL_BOARD_INIT if SPL
select CMD_DDR3
imply DM_I2C
+ imply SOC_TI
+ imply TI_KEYSTONE_SERDES
config TARGET_K2E_EVM
bool "TI Keystone 2 Edison EVM"
select SPL_BOARD_INIT if SPL
select CMD_DDR3
imply DM_I2C
+ imply SOC_TI
+ imply TI_KEYSTONE_SERDES
config TARGET_K2L_EVM
bool "TI Keystone 2 Lamar EVM"
select SPL_BOARD_INIT if SPL
select CMD_DDR3
imply DM_I2C
+ imply SOC_TI
+ imply TI_KEYSTONE_SERDES
config TARGET_K2G_EVM
bool "TI Keystone 2 Galileo EVM"
@@ -29,6 +35,8 @@ config TARGET_K2G_EVM
select TI_I2C_BOARD_DETECT
select CMD_DDR3
imply DM_I2C
+ imply SOC_TI
+ imply TI_KEYSTONE_SERDES
endchoice
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 8b7ead546e1c..ce253b7aa886 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -2,5 +2,4 @@
#
# Makefile for the U-Boot SOC specific device drivers.
-obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
obj-$(CONFIG_SOC_TI) += ti/
diff --git a/drivers/soc/keystone/Makefile b/drivers/soc/keystone/Makefile
deleted file mode 100644
index dfebb143e09b..
--- a/drivers/soc/keystone/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-
-obj-$(CONFIG_TI_KEYSTONE_SERDES) += keystone_serdes.o
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 8c0f3c07b23f..e4f88344487e 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -16,5 +16,11 @@ config TI_K3_NAVSS_RINGACC
and a consumer. There is one RINGACC module per NAVSS on TI AM65x SoCs
If unsure, say N.
+config TI_KEYSTONE_SERDES
+ bool "Keystone SerDes driver for ethernet"
+ depends on ARCH_KEYSTONE
+ help
+SerDes driver for Keystone SoC used for ethernet support on TI
+K2 platforms.
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 63e21aaad40f..4ec04ee1257e 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0+
-#
-# TI K3 SOC drivers
-#
+
obj-$(CONFIG_TI_K3_NAVSS_RINGACC) += k3-navss-ringacc.o
+obj-$(CONFIG_TI_KEYSTONE_SERDES) += keystone_serdes.o
diff --git a/drivers/soc/keystone/keystone_serdes.c
b/drivers/soc/ti/keystone_serdes.c
similarity index 100%
rename from drivers/soc/keystone/keystone_serdes.c
rename to drivers/soc/ti/keystone_serdes.c
diff --git a/include/configs/ti_armv7_keystone2.h
b/include/configs/ti_armv7_keystone2.h
index 0c7d66486832..6d8536a815f8 100644
--- a/include/configs/ti_armv7_keystone2.h
+++ b/include/configs/ti_armv7_keystone2.h
@@ -134,9 +134,6 @@
#define CONFIG_KSNET_SERDES_SGMII2_BASEKS2_SGMII_SERDES2_BASE
#define CONFIG_KSNET_SERDES_LANES_PER_SGMIIKS2_LANES_PER_SGMII_SERDES
-/* SerDes */
-#define CONFIG_TI_KEYSTONE_SERDES
-
#define CONFIG_AEMIF_CNTRL_BASEKS2_AEMIF_CNTRL_BASE
/* I2C Configuration */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index c05fc379645e..7a667ccbc3d2 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4420,7 +4420,6 @@ CONFIG_THOR_RESET_OFF
CONFIG_THUNDERX
CONFIG_TIMESTAMP
CONFIG_TIZEN
-CONFIG_TI_KEYSTONE_SERDES
CONFIG_TI_KSNAV
CONFIG_TI_SPI_MMAP
CONFIG_TMU_TIMER
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 6/7] arm64: dts: ti: k3-am65: add mcu navss nodes
From: Grygorii Strashko
Add DT node for MCU NAVSS its components to get DMA working on AM654
SoC.
Signed-off-by: Grygorii Strashko
Signed-off-by: Vignesh R
---
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 46
1 file changed, 46 insertions(+)
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 143eb6d63092..5a934b106d04 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -4,6 +4,7 @@
*/
#include
+#include
/ {
chosen {
@@ -63,6 +64,51 @@
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x>;
};
+
+ navss_mcu: navss-mcu {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ti,sci-dev-id = <119>;
+
+ mcu_ringacc: ringacc@2b80 {
+ compatible = "ti,am654-navss-ringacc";
+ reg = <0x0 0x2b80 0x0 0x40>,
+ <0x0 0x2b00 0x0 0x40>,
+ <0x0 0x2859 0x0 0x100>,
+ <0x0 0x2a50 0x0 0x4>;
+ reg-names = "rt", "fifos",
+ "proxy_gcfg", "proxy_target";
+ ti,num-rings = <286>;
+ ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
+ ti,dma-ring-reset-quirk;
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <195>;
+ };
+
+ mcu_udmap: udmap@285c {
+ compatible = "ti,k3-navss-udmap";
+ reg = <0x0 0x285c 0x0 0x100>,
+ <0x0 0x2a80 0x0 0x4>,
+ <0x0 0x2aa0 0x0 0x4>;
+ reg-names = "gcfg", "rchanrt", "tchanrt";
+ #dma-cells = <3>;
+
+ ti,ringacc = <&mcu_ringacc>;
+ ti,psil-base = <0x6000>;
+
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <194>;
+
+ ti,sci-rm-range-tchan = <0x1>, /* TX_HCHAN */
+ <0x2>; /* TX_CHAN */
+ ti,sci-rm-range-rchan = <0x3>, /* RX_HCHAN */
+ <0x4>; /* RX_CHAN */
+ ti,sci-rm-range-rflow = <0x5>; /* GP RFLOW */
+ };
+ };
};
&cbass_wakeup {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/7] firmware: ti_sci: Add support for NAVSS resource management
From: Grygorii Strashko
Texas Instruments' System Control Interface (TI-SCI) Message Protocol
abstracts management of NAVSS resources, like PSI-L pairing and
unpairing, UDMAP tx/rx/flow configuration and Rings.
This patch adds support for requesting and configuring such resources
from TI-SCI firmware.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Grygorii Strashko
Reviewed-by: Tom Rini
Signed-off-by: Vignesh R
---
arch/arm/dts/k3-am65-wakeup.dtsi | 2 +-
drivers/firmware/ti_sci.c | 760 -
drivers/firmware/ti_sci.h | 642 +
include/linux/soc/ti/ti_sci_protocol.h | 300 ++
4 files changed, 1692 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/k3-am65-wakeup.dtsi b/arch/arm/dts/k3-am65-wakeup.dtsi
index 8d7b47f9dfbf..1f591ef8bb9e 100644
--- a/arch/arm/dts/k3-am65-wakeup.dtsi
+++ b/arch/arm/dts/k3-am65-wakeup.dtsi
@@ -7,7 +7,7 @@
&cbass_wakeup {
dmsc: dmsc {
- compatible = "ti,k2g-sci";
+ compatible = "ti,am654-sci";
ti,host-id = <12>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 91481260411a..ec78a520e702 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,16 +32,37 @@ struct ti_sci_xfer {
u8 rx_len;
};
+/**
+ * struct ti_sci_rm_type_map - Structure representing TISCI Resource
+ * management representation of dev_ids.
+ * @dev_id:TISCI device ID
+ * @type: Corresponding id as identified by TISCI RM.
+ *
+ * Note: This is used only as a work around for using RM range apis
+ * for AM654 SoC. For future SoCs dev_id will be used as type
+ * for RM range APIs. In order to maintain ABI backward compatibility
+ * type is not being changed for AM654 SoC.
+ */
+struct ti_sci_rm_type_map {
+ u32 dev_id;
+ u16 type;
+};
+
/**
* struct ti_sci_desc - Description of SoC integration
- * @host_id: Host identifier representing the compute entity
- * @max_rx_timeout_us: Timeout for communication with SoC (in Microseconds)
- * @max_msg_size: Maximum size of data per message that can be handled.
+ * @default_host_id: Host identifier representing the compute entity
+ * @max_rx_timeout_ms: Timeout for communication with SoC (in Milliseconds)
+ * @max_msgs: Maximum number of messages that can be pending
+ * simultaneously in the system
+ * @max_msg_size: Maximum size of data per message that can be handled.
+ * @rm_type_map: RM resource type mapping structure.
*/
struct ti_sci_desc {
- u8 host_id;
- int max_rx_timeout_us;
+ u8 default_host_id;
+ int max_rx_timeout_ms;
+ int max_msgs;
int max_msg_size;
+ struct ti_sci_rm_type_map *rm_type_map;
};
/**
@@ -136,7 +158,7 @@ static inline int ti_sci_get_response(struct ti_sci_info
*info,
int ret;
/* Receive the response */
- ret = mbox_recv(chan, msg, info->desc->max_rx_timeout_us);
+ ret = mbox_recv(chan, msg, info->desc->max_rx_timeout_ms);
if (ret) {
dev_err(info->dev, "%s: Message receive failed. ret = %d\n",
__func__, ret);
@@ -1441,6 +1463,147 @@ static int ti_sci_cmd_core_reboot(const struct
ti_sci_handle *handle)
return ret;
}
+static int ti_sci_get_resource_type(struct ti_sci_info *info, u16 dev_id,
+ u16 *type)
+{
+ struct ti_sci_rm_type_map *rm_type_map = info->desc->rm_type_map;
+ bool found = false;
+ int i;
+
+ /* If map is not provided then assume dev_id is used as type */
+ if (!rm_type_map) {
+ *type = dev_id;
+ return 0;
+ }
+
+ for (i = 0; rm_type_map[i].dev_id; i++) {
+ if (rm_type_map[i].dev_id == dev_id) {
+ *type = rm_type_map[i].type;
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * ti_sci_get_resource_range - Helper to get a range of resources assigned
+ *to a host. Resource is uniquely identified by
+ *type and subtype.
+ * @handle:Pointer to TISCI handle.
+ * @dev_id:TISCI device ID.
+ * @subtype: Resource assignment subtype that is being requested
+ * from the given device.
+ * @s_host:Host processor ID to which the resources are allocated
+ * @range_start: Start index of the resource range
+ * @range_num: Number of resources in the range
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_get_resource
[U-Boot] [PATCH v3 0/7] AM65x: Add DMA support
This series adds DMA support for TI's AM654 SoC.
v3:
Minor comment/whitespace cleanups as pointed out by Tom Rini
v2:
Align DT bindings with latest proposed bindings as pointed out by Peter.
Merge drivers/soc/keystone into drivers/soc/ti
Background:
The AM65x TRM (http://www.ti.com/lit/pdf/spruid7b) describes the Data Movement
Architecture which is implmented by the k3-udma driver.
This DMA architecture is a big departure from 'traditional' architecture where
we had either EDMA or sDMA as system DMA.
Packet DMAs were used as dedicated DMAs to service only networking (K2)
or USB (am335x) while other peripherals were serviced by EDMA.
In AM65x the UDMA (Unified DMA) is used for all data movment within the SoC,
tasked to service all peripherals (UART, McSPI, McASP, networking, etc).
The NAVSS/UDMA is built around CPPI5 (Communications Port Programming Interface)
and it supports Packet mode (similar to CPPI4.1 in K2 for networking) and
TR mode (similar to EDMA descriptor).
The data movement is done within a PSI-L fabric, all peripherals (including the
UDMA-P). peripherals are not addressed by their I/O register as with traditional
DMAs but with their PSI-L thread ID.
To be able to use the DMA the following generic steps need to be taken:
- configure a DMA channel (tchan for TX, rchan for RX)
- channel mode: Packet or TR mode
- for memcpy a tchan and rchan pair is used.
- for packet mode RX we also need to configure a receive flow to configure the
packet receiption
- the source and destination threads must be paired
- at minimum one pair of rings need to be configured:
- tx: transfer ring and transfer completion ring
- rx: free descriptor ring and receive ring
When the channel setup is completed we only interract with the rings:
- TX: push a descriptor to t_ring and wait for it to be pushed to the tc_ring by
the UDMA-P
- RX: push a descriptor to the fd_ring and wait for UDMA-P to push it back to
the r_ring.
Resources Management and configuration of channel and ring is handled by
sending TI-SCI msgs to remote core.
Patches are based on kernel patches here:
https://patchwork.kernel.org/cover/10612465/
Grygorii Strashko (5):
firmware: ti_sci: Add support for NAVSS resource management
soc: ti: k3: add navss ringacc driver
soc: ti: k3: add CPPI5 description and helpers
arm64: dts: ti: k3-am65: add mcu navss nodes
configs: am65x_evm_a53: Enable DMA related configs
Vignesh R (2):
dma: ti: add driver to K3 UDMA
soc: keystone: Merge into ti specific directory
arch/arm/dts/k3-am65-wakeup.dtsi |2 +-
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 46 +
arch/arm/mach-keystone/Kconfig|8 +
configs/am65x_evm_a53_defconfig |4 +-
drivers/Kconfig |2 +
drivers/dma/Kconfig |2 +
drivers/dma/Makefile |2 +
drivers/dma/ti/Kconfig| 14 +
drivers/dma/ti/Makefile |3 +
drivers/dma/ti/k3-udma-hwdef.h| 184 ++
drivers/dma/ti/k3-udma.c | 1737 +
drivers/firmware/ti_sci.c | 760 +++-
drivers/firmware/ti_sci.h | 642 ++
drivers/soc/Kconfig |5 +
drivers/soc/Makefile |2 +-
drivers/soc/keystone/Makefile |3 -
drivers/soc/ti/Kconfig| 26 +
drivers/soc/ti/Makefile |4 +
drivers/soc/ti/k3-navss-ringacc.c | 1096 +++
.../soc/{keystone => ti}/keystone_serdes.c|0
include/configs/ti_armv7_keystone2.h |3 -
include/dt-bindings/dma/k3-udma.h | 31 +
include/linux/soc/ti/cppi5.h | 995 ++
include/linux/soc/ti/k3-navss-ringacc.h | 246 +++
include/linux/soc/ti/ti-udma.h| 24 +
include/linux/soc/ti/ti_sci_protocol.h| 300 +++
scripts/config_whitelist.txt |1 -
27 files changed, 6121 insertions(+), 21 deletions(-)
create mode 100644 drivers/dma/ti/Kconfig
create mode 100644 drivers/dma/ti/Makefile
create mode 100644 drivers/dma/ti/k3-udma-hwdef.h
create mode 100644 drivers/dma/ti/k3-udma.c
create mode 100644 drivers/soc/Kconfig
delete mode 100644 drivers/soc/keystone/Makefile
create mode 100644 drivers/soc/ti/Kconfig
create mode 100644 drivers/soc/ti/Makefile
create mode 100644 drivers/soc/ti/k3-navss-ringacc.c
rename drivers/soc/{keystone => ti}/keystone_serdes.c (100%)
create mode 100644 include/dt-bindings/dma/k3-udma.h
create mode 100644 include/linux/soc/ti/cppi5.h
create mode 100644 include/linux/soc/ti/k3-navss-ringacc.h
create mode 100644 include/linux/soc/ti/ti-udma.h
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 7/7] configs: am65x_evm_a53: Enable DMA related configs
From: Grygorii Strashko Enable TI K3 AM65x PSI-L, Ring Accelerator and UDMA drivers Signed-off-by: Grygorii Strashko Signed-off-by: Vignesh R --- configs/am65x_evm_a53_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index a17cf7cb5040..9ce22157c92d 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -48,10 +48,11 @@ CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_CLK_TI_SCI=y +CONFIG_DMA_CHANNELS=y +CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y -CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_K3_ARASAN=y @@ -67,5 +68,6 @@ CONFIG_REMOTEPROC_K3=y CONFIG_DM_RESET=y CONFIG_RESET_TI_SCI=y CONFIG_DM_SERIAL=y +CONFIG_SOC_TI=y CONFIG_SYSRESET=y CONFIG_SYSRESET_TI_SCI=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 16/20] mtd: spi: Add lightweight SPI flash stack for SPL
Add a tiny SPI flash stack that just supports reading data/images from
SPI flash. This is useful for boards that have SPL size constraints and
would need to use SPI flash framework just to read images/data from
flash. There is approximately 1.5 to 2KB savings with this.
Based on prior work of reducing spi flash id table by
Simon Goldschmidt
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
common/spl/Kconfig | 11 +-
drivers/mtd/spi/Makefile | 10 +-
drivers/mtd/spi/sf_internal.h | 2 +
drivers/mtd/spi/spi-nor-core.c | 266 +--
drivers/mtd/spi/spi-nor-ids.c | 297
drivers/mtd/spi/spi-nor-tiny.c | 810 +
6 files changed, 1132 insertions(+), 264 deletions(-)
create mode 100644 drivers/mtd/spi/spi-nor-ids.c
create mode 100644 drivers/mtd/spi/spi-nor-tiny.c
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 2e1dd2705a62..416f5933b0d9 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -732,9 +732,18 @@ config SPL_SPI_FLASH_SUPPORT
if SPL_SPI_FLASH_SUPPORT
+config SPL_SPI_FLASH_TINY
+ bool "Enable low footprint SPL SPI Flash support"
+ depends on !SPI_FLASH_BAR
+ help
+Enable lightweight SPL SPI Flash support that supports just reading
+data/images from flash. No support to write/erase flash. Enable
+this if you have SPL size limitations and don't need full
+fledged SPI flash support.
+
config SPL_SPI_FLASH_SFDP_SUPPORT
bool "SFDP table parsing support for SPI NOR flashes"
- depends on !SPI_FLASH_BAR
+ depends on !SPI_FLASH_BAR && !SPL_SPI_FLASH_TINY
help
Enable support for parsing and auto discovery of parameters for
SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 70058d3df2b9..f99f6cb16e29 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -4,12 +4,20 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_DM_SPI_FLASH) += sf-uclass.o
+spi-nor-y := sf_probe.o spi-nor-ids.o
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
+ifeq ($(CONFIG_SPL_SPI_FLASH_TINY),y)
+spi-nor-y += spi-nor-tiny.o
+else
+spi-nor-y += spi-nor-core.o
+endif
+else
+spi-nor-y += spi-nor-core.o
endif
-obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o
+obj-$(CONFIG_SPI_FLASH) += spi-nor.o
obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index fd00e0d1b23b..a6bf734830a7 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -16,7 +16,9 @@
#define SPI_NOR_MAX_ADDR_WIDTH 4
struct flash_info {
+#if !CONFIG_IS_ENABLED(SPI_FLASH_TINY)
char*name;
+#endif
/*
* This array stores the ID bytes.
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index dbaaf45c7e1e..80633f8fd070 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -879,284 +879,26 @@ static int stm_is_locked(struct spi_nor *nor, loff_t
ofs, uint64_t len)
}
#endif /* CONFIG_SPI_FLASH_STMICRO */
-/* Used when the "_ext_id" is two bytes at most */
-#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
- .id = { \
- ((_jedec_id) >> 16) & 0xff, \
- ((_jedec_id) >> 8) & 0xff, \
- (_jedec_id) & 0xff, \
- ((_ext_id) >> 8) & 0xff,\
- (_ext_id) & 0xff, \
- }, \
- .id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))),
\
- .sector_size = (_sector_size), \
- .n_sectors = (_n_sectors), \
- .page_size = 256, \
- .flags = (_flags),
-
-#define INFO6(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)\
- .id = { \
- ((_jedec_id) >> 16) & 0xff, \
- ((_jedec_id) >> 8) & 0xff, \
- (_jedec_id) & 0xff, \
- ((_ext_id) >> 16) & 0xff, \
- ((_ext_id) >> 8) & 0xff,\
- (_ext_id) & 0xff, \
- },
[U-Boot] [PATCH v3 4/7] dma: ti: add driver to K3 UDMA
The UDMA-P is intended to perform similar (but significantly upgraded) functions as the packet-oriented DMA used on previous SoC devices. The UDMA-P module supports the transmission and reception of various packet types. The UDMA-P also supports acting as both a UTC and UDMA-C for its internal channels. Channels in the UDMA-P can be configured to be either Packet-Based or Third-Party channels on a channel by channel basis. The initial driver supports: - MEM_TO_MEM (TR mode) - DEV_TO_MEM (Packet mode) - MEM_TO_DEV (Packet mode) Signed-off-by: Peter Ujfalusi Signed-off-by: Grygorii Strashko Signed-off-by: Vignesh R --- drivers/dma/Kconfig |2 + drivers/dma/Makefile |2 + drivers/dma/ti/Kconfig| 14 + drivers/dma/ti/Makefile |3 + drivers/dma/ti/k3-udma-hwdef.h| 184 +++ drivers/dma/ti/k3-udma.c | 1737 + include/dt-bindings/dma/k3-udma.h | 31 + include/linux/soc/ti/ti-udma.h| 24 + 8 files changed, 1997 insertions(+) create mode 100644 drivers/dma/ti/Kconfig create mode 100644 drivers/dma/ti/Makefile create mode 100644 drivers/dma/ti/k3-udma-hwdef.h create mode 100644 drivers/dma/ti/k3-udma.c create mode 100644 include/dt-bindings/dma/k3-udma.h create mode 100644 include/linux/soc/ti/ti-udma.h diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 1820676d7a18..4f37ba7d35eb 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -57,4 +57,6 @@ config APBH_DMA_BURST8 endif +source "drivers/dma/ti/Kconfig" + endmenu # menu "DMA Support" diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index b5f9147e0a54..afab324461b9 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -13,3 +13,5 @@ obj-$(CONFIG_SANDBOX_DMA) += sandbox-dma-test.o obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o obj-$(CONFIG_TI_EDMA3) += ti-edma3.o obj-$(CONFIG_DMA_LPC32XX) += lpc32xx_dma.o + +obj-y += ti/ diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig new file mode 100644 index ..3d5498326c42 --- /dev/null +++ b/drivers/dma/ti/Kconfig @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0+ + +if ARCH_K3 + +config TI_K3_NAVSS_UDMA +bool "Texas Instruments UDMA" +depends on ARCH_K3 +select DMA +select TI_K3_NAVSS_RINGACC +select TI_K3_NAVSS_PSILCFG +default n +help + Support for UDMA used in K3 devices. +endif diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile new file mode 100644 index ..de2f9ac91a46 --- /dev/null +++ b/drivers/dma/ti/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0+ + +obj-$(CONFIG_TI_K3_NAVSS_UDMA) += k3-udma.o diff --git a/drivers/dma/ti/k3-udma-hwdef.h b/drivers/dma/ti/k3-udma-hwdef.h new file mode 100644 index ..c88399a815ea --- /dev/null +++ b/drivers/dma/ti/k3-udma-hwdef.h @@ -0,0 +1,184 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com + * + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ + +#ifndef K3_NAVSS_UDMA_HWDEF_H_ +#define K3_NAVSS_UDMA_HWDEF_H_ + +#define UDMA_PSIL_DST_THREAD_ID_OFFSET 0x8000 + +/* Global registers */ +#define UDMA_REV_REG 0x0 +#define UDMA_PERF_CTL_REG 0x4 +#define UDMA_EMU_CTL_REG 0x8 +#define UDMA_PSIL_TO_REG 0x10 +#define UDMA_UTC_CTL_REG 0x1c +#define UDMA_CAP_REG(i)(0x20 + (i * 4)) +#define UDMA_RX_FLOW_ID_FW_OES_REG 0x80 +#define UDMA_RX_FLOW_ID_FW_STATUS_REG 0x88 + +/* RX Flow regs */ +#define UDMA_RFLOW_RFA_REG 0x0 +#define UDMA_RFLOW_RFB_REG 0x4 +#define UDMA_RFLOW_RFC_REG 0x8 +#define UDMA_RFLOW_RFD_REG 0xc +#define UDMA_RFLOW_RFE_REG 0x10 +#define UDMA_RFLOW_RFF_REG 0x14 +#define UDMA_RFLOW_RFG_REG 0x18 +#define UDMA_RFLOW_RFH_REG 0x1c + +#define UDMA_RFLOW_REG(x) (UDMA_RFLOW_RF##x##_REG) + +/* TX chan regs */ +#define UDMA_TCHAN_TCFG_REG0x0 +#define UDMA_TCHAN_TCREDIT_REG 0x4 +#define UDMA_TCHAN_TCQ_REG 0x14 +#define UDMA_TCHAN_TOES_REG(i) (0x20 + (i) * 4) +#define UDMA_TCHAN_TEOES_REG 0x60 +#define UDMA_TCHAN_TPRI_CTRL_REG 0x64 +#define UDMA_TCHAN_THREAD_ID_REG 0x68 +#define UDMA_TCHAN_TFIFO_DEPTH_REG 0x70 +#define UDMA_TCHAN_TST_SCHED_REG 0x80 + +/* RX chan regs */ +#define UDMA_RCHAN_RCFG_REG0x0 +#define UDMA_RCHAN_RCQ_REG 0x14 +#define UDMA_RCHAN_ROES_REG(i) (0x20 + (i) * 4) +#define UDMA_RCHAN_REOES_REG 0x60 +#define UDMA_RCHAN_RPRI_CTRL_REG 0x64 +#define UDMA_RCHAN_THREAD_ID_REG 0x68 +#define UDMA_RCHAN_RST_SCHED_REG 0x8
[U-Boot] [PATCH v3 18/20] configs: Remove SF_DUAL_FLASH
SF_DUAL_FLASH claims to enable support for SF_DUAL_STACKED_FLASH and SF_DUAL_PARALLEL_FLASH. But, in current U-Boot code, grepping for above enums yield no user and therefore support seems to be incomplete. Remove these configs so as to avoid confusion. Signed-off-by: Vignesh R --- configs/topic_miamilite_defconfig | 1 - configs/topic_miamiplus_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - .../xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 - .../xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 - configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - doc/SPI/README.dual-flash | 92 --- include/configs/socfpga_stratix10_socdk.h | 1 - 17 files changed, 108 deletions(-) delete mode 100644 doc/SPI/README.dual-flash diff --git a/configs/topic_miamilite_defconfig b/configs/topic_miamilite_defconfig index e4d52f6a915e..95fa7678d639 100644 --- a/configs/topic_miamilite_defconfig +++ b/configs/topic_miamilite_defconfig @@ -40,7 +40,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_DEBUG_UART_ZYNQ=y diff --git a/configs/topic_miamiplus_defconfig b/configs/topic_miamiplus_defconfig index f742838d7c1f..6d753c0326a1 100644 --- a/configs/topic_miamiplus_defconfig +++ b/configs/topic_miamiplus_defconfig @@ -39,7 +39,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set # CONFIG_NETDEVICES is not set diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig b/configs/xilinx_zynqmp_mini_qspi_defconfig index 3ec435e7ffe7..911d1beed2e1 100644 --- a/configs/xilinx_zynqmp_mini_qspi_defconfig +++ b/configs/xilinx_zynqmp_mini_qspi_defconfig @@ -54,7 +54,6 @@ CONFIG_SPL_DM_SEQ_ALIAS=y # CONFIG_MMC is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y diff --git a/configs/xilinx_zynqmp_zc1232_revA_defconfig b/configs/xilinx_zynqmp_zc1232_revA_defconfig index 983e61e48e1a..35952d38157d 100644 --- a/configs/xilinx_zynqmp_zc1232_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1232_revA_defconfig @@ -38,7 +38,6 @@ CONFIG_MISC=y # CONFIG_MMC is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y diff --git a/configs/xilinx_zynqmp_zc1254_revA_defconfig b/configs/xilinx_zynqmp_zc1254_revA_defconfig index 10d3489b6905..9c412ebf9544 100644 --- a/configs/xilinx_zynqmp_zc1254_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1254_revA_defconfig @@ -38,7 +38,6 @@ CONFIG_MISC=y # CONFIG_MMC is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y diff --git a/configs/xilinx_zynqmp_zc1275_revA_defconfig b/configs/xilinx_zynqmp_zc1275_revA_defconfig index 9ac3dd85f196..d1108b8e7d89 100644 --- a/configs/xilinx_zynqmp_zc1275_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1275_revA_defconfig @@ -38,7 +38,6 @@ CONFIG_MISC=y # CONFIG_MMC is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y diff --git a/configs/xilinx_zynqmp_zc1275_revB_defconfig b/configs/xilinx_zynqmp_zc1275_revB_defconfig index c154b15871f1..e5e4eb2b745e 100644 --- a/configs/xilinx_zynqmp_zc1275_revB_defconfig +++ b/configs/xilinx_zynqmp_zc1275_revB_defconfig @@ -42,7 +42,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig index f2caac790a1a..dd6f50df4ee4 100644 --- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig @@ -62,7 +62,6 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig b/configs/xi
[U-Boot] [PATCH v3 13/20] mtd: spi: sf_probe: Add "jedec, spi-nor" compatible string
Linux uses "jedec,spi-nor" as compatible string for JEDEC compatible SPI Flash device nodes. Therefore make U-Boot also to look for the same compatible string so that we can use Linux DTS files as is. Signed-off-by: Vignesh R Tested-by: Simon Goldschmidt Tested-by: Stefan Roese Tested-by: Horatiu Vultur https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 19/20] configs: Don't use SPI_FLASH_BAR as default
Now that new SPI NOR layer uses stateless 4 byte opcodes by default, don't enable SPI_FLASH_BAR. For SPI controllers that cannot support 4-byte addressing, (stm32_qspi.c, fsl_qspi.c, mtk_qspi.c, ich.c, renesas_rpc_spi.c) add an imply clause to enable SPI_FLASH_BAR so as to not break functionality. Signed-off-by: Vignesh R Tested-by: Simon Goldschmidt Tested-by: Stefan Roese Tested-by: Horatiu Vultur --- arch/arm/mach-omap2/am33xx/Kconfig | 1 - configs/alt_defconfig| 1 - configs/am57xx_evm_defconfig | 1 - configs/am57xx_hs_evm_defconfig | 1 - configs/ap121_defconfig | 1 - configs/ap143_defconfig | 1 - configs/avnet_ultra96_rev1_defconfig | 1 - configs/axs101_defconfig | 1 - configs/axs103_defconfig | 1 - configs/bg0900_defconfig | 1 - configs/blanche_defconfig| 1 - configs/cl-som-am57x_defconfig | 1 - configs/clearfog_defconfig | 1 - configs/cm_t43_defconfig | 1 - configs/db-88f6820-amc_defconfig | 1 - configs/display5_defconfig | 1 - configs/display5_factory_defconfig | 1 - configs/dra7xx_evm_defconfig | 1 - configs/dra7xx_hs_evm_defconfig | 1 - configs/ds109_defconfig | 1 - configs/ds414_defconfig | 1 - configs/evb-rv1108_defconfig | 1 - configs/gose_defconfig | 1 - configs/helios4_defconfig| 1 - configs/k2g_evm_defconfig| 1 - configs/k2g_hs_evm_defconfig | 1 - configs/koelsch_defconfig| 1 - configs/lager_defconfig | 1 - configs/maxbcm_defconfig | 1 - configs/mt7629_rfb_defconfig | 1 - configs/mx6sxsabreauto_defconfig | 1 - configs/mx6sxsabresd_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig| 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/mx6ull_14x14_evk_defconfig | 1 - configs/mx6ull_14x14_evk_plugin_defconfig| 1 - configs/mx7dsabresd_qspi_defconfig | 1 - configs/porter_defconfig | 1 - configs/r8a77970_eagle_defconfig | 1 - configs/silk_defconfig | 1 - configs/socfpga_arria5_defconfig | 1 - configs/socfpga_cyclone5_defconfig | 1 - configs/socfpga_is1_defconfig| 1 - configs/socfpga_sockit_defconfig | 1 - configs/socfpga_socrates_defconfig | 1 - configs/socfpga_sr1500_defconfig | 1 - configs/socfpga_stratix10_defconfig | 1 - configs/stout_defconfig | 1 - configs/topic_miami_defconfig| 1 - configs/topic_miamilite_defconfig| 1 - configs/topic_miamiplus_defconfig| 1 - configs/xilinx_versal_virt_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig| 1 - configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 - configs/xilinx_zynqmp_zcu100_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu102_rev1_0_defconfig| 1 - configs/xilinx_zynqmp_zcu102_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu111_revA_defconfig | 1 - configs/zynq_cc108_defconfig | 1 - configs/zynq_cse_qspi_defconfig | 1 - configs/zynq_dlc20_rev1_0_defconfig | 1 - configs/zynq_microzed_defconfig | 1 - configs/zynq_minized_defconfig | 1 - configs/zynq_z_turn_defconfig| 1 - configs/zynq_zc702_defconfig | 1 - configs/zynq_zc706_defconfig | 1 - configs/zynq_zc770_xm010_defconfig | 1 - configs/zynq_zc770_xm013_defconfig | 1 - configs/zynq_zed_defconfig | 1 - configs/zynq_zybo_defconfig | 1 - configs/zynq_zybo_z7_defconfig | 1 - doc/SPI/README.ti_qspi_dra_test |
[U-Boot] [PATCH v3 12/20] mtd: spi: spi-nor-core: Add back U-Boot specific features
For legacy reasons, we will have to keep around U-Boot specific
SPI_FLASH_BAR and SPI_TX_BYTE. Add them back to the new framework
Signed-off-by: Vignesh R
---
drivers/mtd/spi/spi-nor-core.c | 162 -
include/linux/mtd/spi-nor.h| 9 ++
2 files changed, 168 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 97ec8e8e7a19..c3f6929db506 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -291,6 +291,7 @@ static struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd)
return mtd->priv;
}
+#ifndef CONFIG_SPI_FLASH_BAR
static u8 spi_nor_convert_opcode(u8 opcode, const u8 table[][2], size_t size)
{
size_t i;
@@ -365,6 +366,7 @@ static void spi_nor_set_4byte_opcodes(struct spi_nor *nor,
nor->program_opcode = spi_nor_convert_3to4_program(nor->program_opcode);
nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
}
+#endif /* !CONFIG_SPI_FLASH_BAR */
/* Enable/disable 4-byte addressing mode. */
static int set_4byte(struct spi_nor *nor, const struct flash_info *info,
@@ -499,6 +501,79 @@ static int spi_nor_wait_till_ready(struct spi_nor *nor)
DEFAULT_READY_WAIT_JIFFIES);
}
+#ifdef CONFIG_SPI_FLASH_BAR
+/*
+ * This "clean_bar" is necessary in a situation when one was accessing
+ * spi flash memory > 16 MiB by using Bank Address Register's BA24 bit.
+ *
+ * After it the BA24 bit shall be cleared to allow access to correct
+ * memory region after SW reset (by calling "reset" command).
+ *
+ * Otherwise, the BA24 bit may be left set and then after reset, the
+ * ROM would read/write/erase SPL from 16 MiB * bank_sel address.
+ */
+static int clean_bar(struct spi_nor *nor)
+{
+ u8 cmd, bank_sel = 0;
+
+ if (nor->bank_curr == 0)
+ return 0;
+ cmd = nor->bank_write_cmd;
+ nor->bank_curr = 0;
+ write_enable(nor);
+
+ return nor->write_reg(nor, cmd, &bank_sel, 1);
+}
+
+static int write_bar(struct spi_nor *nor, u32 offset)
+{
+ u8 cmd, bank_sel;
+ int ret;
+
+ bank_sel = offset / SZ_16M;
+ if (bank_sel == nor->bank_curr)
+ goto bar_end;
+
+ cmd = nor->bank_write_cmd;
+ write_enable(nor);
+ ret = nor->write_reg(nor, cmd, &bank_sel, 1);
+ if (ret < 0) {
+ debug("SF: fail to write bank register\n");
+ return ret;
+ }
+
+bar_end:
+ nor->bank_curr = bank_sel;
+ return nor->bank_curr;
+}
+
+static int read_bar(struct spi_nor *nor, const struct flash_info *info)
+{
+ u8 curr_bank = 0;
+ int ret;
+
+ switch (JEDEC_MFR(info)) {
+ case SNOR_MFR_SPANSION:
+ nor->bank_read_cmd = SPINOR_OP_BRRD;
+ nor->bank_write_cmd = SPINOR_OP_BRWR;
+ break;
+ default:
+ nor->bank_read_cmd = SPINOR_OP_RDEAR;
+ nor->bank_write_cmd = SPINOR_OP_WREAR;
+ }
+
+ ret = nor->read_reg(nor, nor->bank_read_cmd,
+ &curr_bank, 1);
+ if (ret) {
+ debug("SF: fail to read bank addr register\n");
+ return ret;
+ }
+ nor->bank_curr = curr_bank;
+
+ return 0;
+}
+#endif
+
/*
* Initiate the erasure of a single sector
*/
@@ -543,6 +618,11 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
len = instr->len;
while (len) {
+#ifdef CONFIG_SPI_FLASH_BAR
+ ret = write_bar(nor, addr);
+ if (ret < 0)
+ return ret;
+#endif
write_enable(nor);
ret = spi_nor_erase_sector(nor, addr);
@@ -557,9 +637,12 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
goto erase_err;
}
+erase_err:
+#ifdef CONFIG_SPI_FLASH_BAR
+ ret = clean_bar(nor);
+#endif
write_disable(nor);
-erase_err:
return ret;
}
@@ -1144,8 +1227,23 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
from, size_t len,
while (len) {
loff_t addr = from;
+ size_t read_len = len;
- ret = nor->read(nor, addr, len, buf);
+#ifdef CONFIG_SPI_FLASH_BAR
+ u32 remain_len;
+
+ ret = write_bar(nor, addr);
+ if (ret < 0)
+ return log_ret(ret);
+ remain_len = (SZ_16M * (nor->bank_curr + 1)) - addr;
+
+ if (len < remain_len)
+ read_len = len;
+ else
+ read_len = remain_len;
+#endif
+
+ ret = nor->read(nor, addr, read_len, buf);
if (ret == 0) {
/* We shouldn't see 0-length reads */
ret = -EIO;
@@ -1162,18 +1260,49 @@ static int spi_nor_read(struct mtd_info *mtd, lof
[U-Boot] [PATCH v3 20/20] MAINTAINERS: Add an entry for SPI NOR
Add myself as co-maintainer for U-Boot SPI NOR subsystem. Signed-off-by: Vignesh R --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 33f1127e50a4..e06089133731 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -668,6 +668,15 @@ F: drivers/mtd/spi/ F: drivers/spi/ F: include/spi* +SPI-NOR +M: Jagan Teki +M: Vignesh R +S: Maintained +F: drivers/mtd/spi/ +F: include/spi_flash.h +F: include/linux/mtd/cfi.h +F: include/linux/mtd/spi-nor.h + SPMI M: Mateusz Kulikowski S: Maintained -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 15/20] mtd: spi: Remove unused files
spi_flash and spi_flash_ids are no longer needed after SPI NOR
migration. Remove them.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/mtd/spi/spi_flash.c | 1337 ---
drivers/mtd/spi/spi_flash_ids.c | 211 -
2 files changed, 1548 deletions(-)
delete mode 100644 drivers/mtd/spi/spi_flash.c
delete mode 100644 drivers/mtd/spi/spi_flash_ids.c
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
deleted file mode 100644
index 0c2392f28a43..
--- a/drivers/mtd/spi/spi_flash.c
+++ /dev/null
@@ -1,1337 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * SPI Flash Core
- *
- * Copyright (C) 2015 Jagan Teki
- * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc.
- * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik
- * Copyright (C) 2008 Atmel Corporation
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "sf_internal.h"
-
-static void spi_flash_addr(u32 addr, u8 *cmd)
-{
- /* cmd[0] is actual command */
- cmd[1] = addr >> 16;
- cmd[2] = addr >> 8;
- cmd[3] = addr >> 0;
-}
-
-static int read_sr(struct spi_flash *flash, u8 *rs)
-{
- int ret;
- u8 cmd;
-
- cmd = CMD_READ_STATUS;
- ret = spi_flash_read_common(flash, &cmd, 1, rs, 1);
- if (ret < 0) {
- debug("SF: fail to read status register\n");
- return ret;
- }
-
- return 0;
-}
-
-static int read_fsr(struct spi_flash *flash, u8 *fsr)
-{
- int ret;
- const u8 cmd = CMD_FLAG_STATUS;
-
- ret = spi_flash_read_common(flash, &cmd, 1, fsr, 1);
- if (ret < 0) {
- debug("SF: fail to read flag status register\n");
- return ret;
- }
-
- return 0;
-}
-
-static int write_sr(struct spi_flash *flash, u8 ws)
-{
- u8 cmd;
- int ret;
-
- cmd = CMD_WRITE_STATUS;
- ret = spi_flash_write_common(flash, &cmd, 1, &ws, 1);
- if (ret < 0) {
- debug("SF: fail to write status register\n");
- return ret;
- }
-
- return 0;
-}
-
-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
-static int read_cr(struct spi_flash *flash, u8 *rc)
-{
- int ret;
- u8 cmd;
-
- cmd = CMD_READ_CONFIG;
- ret = spi_flash_read_common(flash, &cmd, 1, rc, 1);
- if (ret < 0) {
- debug("SF: fail to read config register\n");
- return ret;
- }
-
- return 0;
-}
-
-static int write_cr(struct spi_flash *flash, u8 wc)
-{
- u8 data[2];
- u8 cmd;
- int ret;
-
- ret = read_sr(flash, &data[0]);
- if (ret < 0)
- return ret;
-
- cmd = CMD_WRITE_STATUS;
- data[1] = wc;
- ret = spi_flash_write_common(flash, &cmd, 1, &data, 2);
- if (ret) {
- debug("SF: fail to write config register\n");
- return ret;
- }
-
- return 0;
-}
-#endif
-
-int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash)
-{
- u8 status;
- int ret;
-
- ret = read_sr(flash, &status);
- if (ret)
- return ret;
-
- return (status >> 2) & 7;
-}
-
-#ifdef CONFIG_SPI_FLASH_BAR
-/*
- * This "clean_bar" is necessary in a situation when one was accessing
- * spi flash memory > 16 MiB by using Bank Address Register's BA24 bit.
- *
- * After it the BA24 bit shall be cleared to allow access to correct
- * memory region after SW reset (by calling "reset" command).
- *
- * Otherwise, the BA24 bit may be left set and then after reset, the
- * ROM would read/write/erase SPL from 16 MiB * bank_sel address.
- */
-static int clean_bar(struct spi_flash *flash)
-{
- u8 cmd, bank_sel = 0;
-
- if (flash->bank_curr == 0)
- return 0;
- cmd = flash->bank_write_cmd;
- flash->bank_curr = 0;
-
- return spi_flash_write_common(flash, &cmd, 1, &bank_sel, 1);
-}
-
-static int write_bar(struct spi_flash *flash, u32 offset)
-{
- u8 cmd, bank_sel;
- int ret;
-
- bank_sel = offset / (SPI_FLASH_16MB_BOUN << flash->shift);
- if (bank_sel == flash->bank_curr)
- goto bar_end;
-
- cmd = flash->bank_write_cmd;
- ret = spi_flash_write_common(flash, &cmd, 1, &bank_sel, 1);
- if (ret < 0) {
- debug("SF: fail to write bank register\n");
- return ret;
- }
-
-bar_end:
- flash->bank_curr = bank_sel;
- return flash->bank_curr;
-}
-
-static int read_bar(struct spi_flash *flash, const struct spi_flash_info *info)
-{
- u8 curr_bank = 0;
- int ret;
-
- if (flash->size <= SPI_FLASH_16MB_BOUN)
- goto bar_end;
-
- switch (JEDEC_MFR(info)) {
- case SPI_FLASH_CFI_MFR_SPANSION:
- flash->bank_read_cmd = CMD_BANKADDR_BRRD;
- flash->b
[U-Boot] [PATCH v3 17/20] spl: Kconfig: Enable SPI_FLASH_TINY by default for SPL
SPL only needs to be able to read from SPI Flash to load next stage and does not really need write/erase etc. Therefore in order to reduce SPI Flash code size in SPL, enable SPI_FLASH_TINY, that only supports reading from SPI flash, as default. Note: Since, SPI_FLASH_TINY does not support SPI_FLASH_BAR, SPI_FLASH_TINY is not enabled for boards with SPI controllers that cannot support 4 byte addressing. Signed-off-by: Vignesh R --- common/spl/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 416f5933b0d9..39a38a138b6b 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -735,6 +735,7 @@ if SPL_SPI_FLASH_SUPPORT config SPL_SPI_FLASH_TINY bool "Enable low footprint SPL SPI Flash support" depends on !SPI_FLASH_BAR + default y if SPI_FLASH help Enable lightweight SPL SPI Flash support that supports just reading data/images from flash. No support to write/erase flash. Enable -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 14/20] mtd: spi: Switch to new SPI NOR framework
Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
use new interfaces/definitions
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/mtd/spi/Kconfig| 2 +
drivers/mtd/spi/Makefile | 4 +-
drivers/mtd/spi/sandbox.c | 36 +++---
drivers/mtd/spi/sf_dataflash.c | 11 +-
drivers/mtd/spi/sf_internal.h | 225 ++---
drivers/mtd/spi/sf_probe.c | 32 +++--
drivers/mtd/spi/spi-nor-core.c | 59 +
drivers/spi/stm32_qspi.c | 4 +-
include/spi_flash.h| 105 ---
9 files changed, 113 insertions(+), 365 deletions(-)
diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 4ba95d58b371..e3b40fc157d6 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -27,6 +27,8 @@ config SPI_FLASH_SANDBOX
config SPI_FLASH
bool "Legacy SPI Flash Interface support"
+ depends on SPI
+ select SPI_MEM
help
Enable the legacy SPI flash support. This will include basic
standard support for things like probing, read / write, and
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index b4c7e1c98bd5..70058d3df2b9 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -9,7 +9,7 @@ ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
endif
-obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi_flash.o spi_flash_ids.o sf.o
-obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o
+obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o
+obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
diff --git a/drivers/mtd/spi/sandbox.c b/drivers/mtd/spi/sandbox.c
index 7b9891cb981c..084c66e9840b 100644
--- a/drivers/mtd/spi/sandbox.c
+++ b/drivers/mtd/spi/sandbox.c
@@ -92,7 +92,7 @@ struct sandbox_spi_flash {
/* The current flash status (see STAT_XXX defines above) */
u16 status;
/* Data describing the flash we're emulating */
- const struct spi_flash_info *data;
+ const struct flash_info *data;
/* The file on disk to serv up data from */
int fd;
};
@@ -122,7 +122,7 @@ static int sandbox_sf_probe(struct udevice *dev)
/* spec = idcode:file */
struct sandbox_spi_flash *sbsf = dev_get_priv(dev);
size_t len, idname_len;
- const struct spi_flash_info *data;
+ const struct flash_info *data;
struct sandbox_spi_flash_plat_data *pdata = dev_get_platdata(dev);
struct sandbox_state *state = state_get_current();
struct dm_spi_slave_platdata *slave_plat;
@@ -155,7 +155,7 @@ static int sandbox_sf_probe(struct udevice *dev)
idname_len = strlen(spec);
debug("%s: device='%s'\n", __func__, spec);
- for (data = spi_flash_ids; data->name; data++) {
+ for (data = spi_nor_ids; data->name; data++) {
len = strlen(data->name);
if (idname_len != len)
continue;
@@ -243,43 +243,43 @@ static int sandbox_sf_process_cmd(struct
sandbox_spi_flash *sbsf, const u8 *rx,
sbsf->cmd = rx[0];
switch (sbsf->cmd) {
- case CMD_READ_ID:
+ case SPINOR_OP_RDID:
sbsf->state = SF_ID;
sbsf->cmd = SF_ID;
break;
- case CMD_READ_ARRAY_FAST:
+ case SPINOR_OP_READ_FAST:
sbsf->pad_addr_bytes = 1;
- case CMD_READ_ARRAY_SLOW:
- case CMD_PAGE_PROGRAM:
+ case SPINOR_OP_READ:
+ case SPINOR_OP_PP:
sbsf->state = SF_ADDR;
break;
- case CMD_WRITE_DISABLE:
+ case SPINOR_OP_WRDI:
debug(" write disabled\n");
sbsf->status &= ~STAT_WEL;
break;
- case CMD_READ_STATUS:
+ case SPINOR_OP_RDSR:
sbsf->state = SF_READ_STATUS;
break;
- case CMD_READ_STATUS1:
+ case SPINOR_OP_RDSR2:
sbsf->state = SF_READ_STATUS1;
break;
- case CMD_WRITE_ENABLE:
+ case SPINOR_OP_WREN:
debug(" write enabled\n");
sbsf->status |= STAT_WEL;
break;
- case CMD_WRITE_STATUS:
+ case SPINOR_OP_WRSR:
sbsf->state = SF_WRITE_STATUS;
break;
default: {
int flags = sbsf->data->flags;
/* we only support erase here */
- if (sbsf->cmd == CMD_ERASE_CHIP) {
+ if (sbsf->cmd == SPINOR_OP_CHIP_ERASE) {
sbsf->erase_size = sbsf->data->sector_size *
sbsf->data->n_sectors;
- } else if (sbsf->cmd == CMD_ERASE_4K && (flags & SECT_4K)) {
+ } else if (sbsf->cmd == SPINOR_
[U-Boot] [PATCH v3 11/20] mtd: spi: spi-nor-core: Add SFDP support
Sync Serial Flash Discoverable Parameters (SFDP) parsing support from
Linux. This allows auto detection and configuration of Flash parameters.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
common/spl/Kconfig | 13 +-
drivers/mtd/spi/Kconfig| 14 +-
drivers/mtd/spi/spi-nor-core.c | 629 -
3 files changed, 649 insertions(+), 7 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 54b0dc34f595..2e1dd2705a62 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -730,13 +730,24 @@ config SPL_SPI_FLASH_SUPPORT
lines). This enables the drivers in drivers/mtd/spi as part of an
SPL build. This normally requires SPL_SPI_SUPPORT.
+if SPL_SPI_FLASH_SUPPORT
+
+config SPL_SPI_FLASH_SFDP_SUPPORT
+ bool "SFDP table parsing support for SPI NOR flashes"
+ depends on !SPI_FLASH_BAR
+ help
+Enable support for parsing and auto discovery of parameters for
+SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
+tables as per JESD216 standard in SPL.
+
config SPL_SPI_LOAD
bool "Support loading from SPI flash"
- depends on SPL_SPI_FLASH_SUPPORT
help
Enable support for loading next stage, U-Boot or otherwise, from
SPI NOR in U-Boot SPL.
+endif # SPL_SPI_FLASH_SUPPORT
+
config SPL_SPI_SUPPORT
bool "Support SPI drivers"
help
diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 76d5a1d11527..4ba95d58b371 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -34,9 +34,18 @@ config SPI_FLASH
If unsure, say N
+if SPI_FLASH
+
+config SPI_FLASH_SFDP_SUPPORT
+ bool "SFDP table parsing support for SPI NOR flashes"
+ depends on !SPI_FLASH_BAR
+ help
+Enable support for parsing and auto discovery of parameters for
+SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
+tables as per JESD216 standard.
+
config SPI_FLASH_BAR
bool "SPI flash Bank/Extended address register support"
- depends on SPI_FLASH
help
Enable the SPI flash Bank/Extended address register support.
Bank/Extended address registers are used to access the flash
@@ -44,13 +53,10 @@ config SPI_FLASH_BAR
config SF_DUAL_FLASH
bool "SPI DUAL flash memory support"
- depends on SPI_FLASH
help
Enable this option to support two flash memories connected to a single
controller. Currently Xilinx Zynq qspi supports this.
-if SPI_FLASH
-
config SPI_FLASH_ATMEL
bool "Atmel SPI flash support"
help
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 570383464193..97ec8e8e7a19 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -81,6 +81,7 @@ struct flash_info {
* to support memory size above 128Mib.
*/
#define NO_CHIP_ERASE BIT(12) /* Chip does not support chip erase */
+#define SPI_NOR_SKIP_SFDP BIT(13) /* Skip parsing of SFDP tables */
#define USE_CLSR BIT(14) /* use CLSR command */
int (*quad_enable)(struct spi_nor *nor);
@@ -1411,6 +1412,39 @@ static int spansion_read_cr_quad_enable(struct spi_nor
*nor)
return 0;
}
+
+#if CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT)
+/**
+ * spansion_no_read_cr_quad_enable() - set QE bit in Configuration Register.
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Set the Quad Enable (QE) bit in the Configuration Register.
+ * This function should be used with QSPI memories not supporting the Read
+ * Configuration Register (35h) instruction.
+ *
+ * bit 1 of the Configuration Register is the QE bit for Spansion like QSPI
+ * memories.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spansion_no_read_cr_quad_enable(struct spi_nor *nor)
+{
+ u8 sr_cr[2];
+ int ret;
+
+ /* Keep the current value of the Status Register. */
+ ret = read_sr(nor);
+ if (ret < 0) {
+ dev_dbg(nor->dev, "error while reading status register\n");
+ return -EINVAL;
+ }
+ sr_cr[0] = ret;
+ sr_cr[1] = CR_QUAD_EN_SPAN;
+
+ return write_sr_cr(nor, sr_cr);
+}
+
+#endif /* CONFIG_SPI_FLASH_SFDP_SUPPORT */
#endif /* CONFIG_SPI_FLASH_SPANSION */
struct spi_nor_read_command {
@@ -1500,6 +1534,573 @@ spi_nor_set_pp_settings(struct spi_nor_pp_command *pp,
pp->proto = proto;
}
+#if CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT)
+/*
+ * Serial Flash Discoverable Parameters (SFDP) parsing.
+ */
+
+/**
+ * spi_nor_read_sfdp() - read Serial Flash Discoverable Parameters.
+ * @nor: pointer to a 'struct spi_nor'
+ * @addr: offset in the SFDP area to start reading data from
+ * @len: number of bytes to r
[U-Boot] [PATCH v3 08/20] mtd: spi: Port SPI NOR framework from Linux
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not
support 4 byte addressing opcodes, SFDP table parsing and different types of
quad mode enable sequences. Many newer flashes no longer support BANK
registers used by sf layer to a access >16MB of flash address space.
So, sync SPI NOR framework from Linux v4.19 that supports all the
above features. Start with basic sync up that brings in basic framework
subsequent commits will bring in more features.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
Jagan, this patch is still 1.7K lines. But half of it is just flash ids
table and associated macros. Apart from that, it should be easier
to review.
drivers/mtd/spi/spi-nor-core.c | 1722
include/linux/mtd/cfi.h| 32 +
include/linux/mtd/spi-nor.h| 410
3 files changed, 2164 insertions(+)
create mode 100644 drivers/mtd/spi/spi-nor-core.c
create mode 100644 include/linux/mtd/cfi.h
create mode 100644 include/linux/mtd/spi-nor.h
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
new file mode 100644
index ..19171766ce82
--- /dev/null
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -0,0 +1,1722 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Based on m25p80.c, by Mike Lavender (m...@steroidmicros.com), with
+ * influence from lart.c (Abraham Van Der Merwe) and mtd_dataflash.c
+ *
+ * Copyright (C) 2005, Intec Automation Inc.
+ * Copyright (C) 2014, Freescale Semiconductor, Inc.
+ *
+ * Synced from Linux v4.19
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Define max times to check status register before we give up. */
+
+/*
+ * For everything but full-chip erase; probably could be much smaller, but kept
+ * around for safety for now
+ */
+
+#define HZ CONFIG_SYS_HZ
+
+#define DEFAULT_READY_WAIT_JIFFIES (40UL * HZ)
+
+#define SPI_NOR_MAX_ID_LEN 6
+#define SPI_NOR_MAX_ADDR_WIDTH 4
+
+struct flash_info {
+ char*name;
+
+ /*
+* This array stores the ID bytes.
+* The first three bytes are the JEDIC ID.
+* JEDEC ID zero means "no ID" (mostly older chips).
+*/
+ u8 id[SPI_NOR_MAX_ID_LEN];
+ u8 id_len;
+
+ /* The size listed here is what works with SPINOR_OP_SE, which isn't
+* necessarily called a "sector" by the vendor.
+*/
+ unsigned intsector_size;
+ u16 n_sectors;
+
+ u16 page_size;
+ u16 addr_width;
+
+ u16 flags;
+#define SECT_4KBIT(0) /* SPINOR_OP_BE_4K works
uniformly */
+#define SPI_NOR_NO_ERASE BIT(1) /* No erase command needed */
+#define SST_WRITE BIT(2) /* use SST byte programming */
+#define SPI_NOR_NO_FR BIT(3) /* Can't do fastread */
+#define SECT_4K_PMCBIT(4) /* SPINOR_OP_BE_4K_PMC works uniformly
*/
+#define SPI_NOR_DUAL_READ BIT(5) /* Flash supports Dual Read */
+#define SPI_NOR_QUAD_READ BIT(6) /* Flash supports Quad Read */
+#define USE_FSRBIT(7) /* use flag status register */
+#define SPI_NOR_HAS_LOCK BIT(8) /* Flash supports lock/unlock via SR */
+#define SPI_NOR_HAS_TB BIT(9) /*
+* Flash SR has Top/Bottom (TB) protect
+* bit. Must be used with
+* SPI_NOR_HAS_LOCK.
+*/
+#defineSPI_S3ANBIT(10) /*
+* Xilinx Spartan 3AN In-System Flash
+* (MFR cannot be used for probing
+* because it has the same value as
+* ATMEL flashes)
+*/
+#define SPI_NOR_4B_OPCODES BIT(11) /*
+* Use dedicated 4byte address op codes
+* to support memory size above 128Mib.
+*/
+#define NO_CHIP_ERASE BIT(12) /* Chip does not support chip erase */
+#define USE_CLSR BIT(14) /* use CLSR command */
+
+ int (*quad_enable)(struct spi_nor *nor);
+};
+
+#define JEDEC_MFR(info)((info)->id[0])
+
+static int spi_nor_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
+{
+ return -EINVAL;
+}
+
+static int spi_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
+{
+ return -EINVAL;
+}
+
+static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t len,
+u_char *buf)
+{
+ return -EINVAL;
+}
+
+static ssize_t spi_
Re: [U-Boot] [RFC 1/9] Arm: dts: imx7d-pico: Import Linux pico-pi dts
> Le 28 janv. 2019 à 07:53, Jun Nie a écrit : > > Joris Offouga 于2019年1月25日周五 下午8:27写道： >> >> Le 25/01/2019 à 02:19, Jun Nie a écrit : Joris Offouga 于2019年1月24日周四 下午9:07写道： >> Le 24/01/2019 à 13:54, Jun Nie a écrit : >> Joris Offouga 于2019年1月24日周四 下午6:30写道： >> Le 24/01/2019 à 11:02, Jun Nie a écrit : >> Hi Joris, >> >> I've been told that this board exhibits this same problem even >> without >> the DM conversion. >> >> "PMIC: PFUZE3000 DEV_ID=0x0 REV_ID=0xfffb >> read error from device: 9df65458 register: 0x69! >> write error to device: 9df65458 register: 0x23! >> write error to device: 9df65458 register: 0x31!" > The result before DM conversion is : > > PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11 > > Did you have this problem with the warp7 ? No. Jun - do you see the above error on the pico ? >>> No. The only line I see about PMIC is: >>> PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11 >>> >>> Jun >> Yes it is the line that appears before the conversion >> >> Jun - do you have the pico board ? >> >> Can you help me with the conversion ? >> >> Joris > OK, I can try it. Where can I find a git branch with these patches? Non, fork the repo and I create a branch on my repo you go? If you have a preference, tell me >>> Right, you create a branch, I will clone and test on it. >> >> I create a branch pico-imx7d/convert_dm on my github repo : >> >> https://github.com/jorisoffouga/u-boot/tree/pico-imx7d/convert_dm > > Hi Joris, > > I burn u-boot.img to offset 69KB, but SPL does not boot into u-boot > according to log. Not sure Hi Jun You have the same behavior as me. For the spl I think it should copy Otavio and Fabio who put it in place. > > U-Boot SPL 2019.01-00273-g3006f29-dirty (Jan 27 2019 - 22:19:00 +0800) > Trying to boot from MMC1 > > If I replace SPL with DCD file for early initilization, I see below > log. Suppose it is due to i2c failure. > > 4474 U-Boot 2019.01-00274-gca08248-dirty (Jan 27 2019 - 22:28:17 +0800) > 4475 > 4476 CPU: Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz) > 4477 CPU: Commercial temperature grade (0C to 95C) at 27C > 4478 Reset cause: POR > 4479 Model: TechNexion PICO-IMX7D Board and PI baseboard > 4480 Board: i.MX7D PICOSOM > 4481 DRAM: 512 MiB > 4482 read error from device: 9df54458 register: 0x3! > 4483 PMIC: PFUZE3000 DEV_ID=0x0 REV_ID=0xfffb > 4484 read error from device: 9df54458 register: 0x69! > 4485 write error to device: 9df54458 register: 0x23! > 4486 write error to device: 9df54458 register: 0x31! > 4487 write error to device: 9df54458 register: 0x21! > 4488 write error to device: 9df54458 register: 0x2f! > 4489 read error from device: 9df54458 register: 0x2e! > 4490 write error to device: 9df54458 register: 0x2e! > 4491 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 > 4492 Loading Environment from MMC... OK > 4493 In:serial@30a7 > 4494 Out: serial@30a7 > 4495 Err: serial@30a7 > 4496 Net: gpio@3025: dir_output: error: gpio GPIO6_11 not reserved > 4497 gpio@3025: set_value: error: gpio GPIO6_11 not reserved > 4498 Board Net Initialization Failed > 4499 No ethernet found. > 4500 Hit any key to stop autoboot: 2 ^H^H^H 1 ^H^H^H 0 > 4501 Saving Environment to MMC... Writing to MMC(0)... OK > 4502 switch to partitions #0, OK > 4503 mmc0(part 0) is current device > 4504 Scanning mmc 0:1... > 4505 Found U-Boot script /boot.scr > 4506 830 bytes read in 3 ms (269.5 KiB/s) > 4507 ## Executing script at 8080 > > Jun Joris > >>> >>> Jun >> Joris >>> Joris > Jun ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 06/20] spi: Add non DM version of SPI_MEM
Add non DM version of SPI_MEM to support easy migration to new SPI NOR
framework. This can be removed once DM_SPI conversion is complete.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/spi/Kconfig| 4 +-
drivers/spi/Makefile | 1 +
drivers/spi/spi-mem-nodm.c | 105 +
3 files changed, 108 insertions(+), 2 deletions(-)
create mode 100644 drivers/spi/spi-mem-nodm.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index de4d62dd8fd1..df4c1a447842 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -16,8 +16,6 @@ config DM_SPI
typically use driver-private data instead of extending the
spi_slave structure.
-if DM_SPI
-
config SPI_MEM
bool "SPI memory extension"
help
@@ -25,6 +23,8 @@ config SPI_MEM
This extension is meant to simplify interaction with SPI memories
by providing an high-level interface to send memory-like commands.
+if DM_SPI
+
config ALTERA_SPI
bool "Altera SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 4acec3ea17d7..39026712931b 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SOFT_SPI) += soft_spi.o
obj-$(CONFIG_SPI_MEM) += spi-mem.o
else
obj-y += spi.o
+obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o
endif
diff --git a/drivers/spi/spi-mem-nodm.c b/drivers/spi/spi-mem-nodm.c
new file mode 100644
index ..4447d4499135
--- /dev/null
+++ b/drivers/spi/spi-mem-nodm.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+
+int spi_mem_exec_op(struct spi_slave *slave,
+ const struct spi_mem_op *op)
+{
+ unsigned int pos = 0;
+ const u8 *tx_buf = NULL;
+ u8 *rx_buf = NULL;
+ u8 *op_buf;
+ int op_len;
+ u32 flag;
+ int ret;
+ int i;
+
+ if (op->data.nbytes) {
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ rx_buf = op->data.buf.in;
+ else
+ tx_buf = op->data.buf.out;
+ }
+
+ op_len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
+ op_buf = calloc(1, op_len);
+
+ ret = spi_claim_bus(slave);
+ if (ret < 0)
+ return ret;
+
+ op_buf[pos++] = op->cmd.opcode;
+
+ if (op->addr.nbytes) {
+ for (i = 0; i < op->addr.nbytes; i++)
+ op_buf[pos + i] = op->addr.val >>
+ (8 * (op->addr.nbytes - i - 1));
+
+ pos += op->addr.nbytes;
+ }
+
+ if (op->dummy.nbytes)
+ memset(op_buf + pos, 0xff, op->dummy.nbytes);
+
+ /* 1st transfer: opcode + address + dummy cycles */
+ flag = SPI_XFER_BEGIN;
+ /* Make sure to set END bit if no tx or rx data messages follow */
+ if (!tx_buf && !rx_buf)
+ flag |= SPI_XFER_END;
+
+ ret = spi_xfer(slave, op_len * 8, op_buf, NULL, flag);
+ if (ret)
+ return ret;
+
+ /* 2nd transfer: rx or tx data path */
+ if (tx_buf || rx_buf) {
+ ret = spi_xfer(slave, op->data.nbytes * 8, tx_buf,
+ rx_buf, SPI_XFER_END);
+ if (ret)
+ return ret;
+ }
+
+ spi_release_bus(slave);
+
+ for (i = 0; i < pos; i++)
+ debug("%02x ", op_buf[i]);
+ debug("| [%dB %s] ",
+ tx_buf || rx_buf ? op->data.nbytes : 0,
+ tx_buf || rx_buf ? (tx_buf ? "out" : "in") : "-");
+ for (i = 0; i < op->data.nbytes; i++)
+ debug("%02x ", tx_buf ? tx_buf[i] : rx_buf[i]);
+ debug("[ret %d]\n", ret);
+
+ free(op_buf);
+
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+int spi_mem_adjust_op_size(struct spi_slave *slave,
+ struct spi_mem_op *op)
+{
+ unsigned int len;
+
+ len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
+ if (slave->max_write_size && len > slave->max_write_size)
+ return -EINVAL;
+
+ if (op->data.dir == SPI_MEM_DATA_IN && slave->max_read_size)
+ op->data.nbytes = min(op->data.nbytes,
+ slave->max_read_size);
+ else if (slave->max_write_size)
+ op->data.nbytes = min(op->data.nbytes,
+ slave->max_write_size - len);
+
+ if (!op->data.nbytes)
+ return -EINVAL;
+
+ return 0;
+}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 04/20] spi: spi-mem: Extend spi_mem_adjust_op_size() to honor max xfer size
Extend spi_mem_adjust_op_size() to take spi->max_write_size and
spi->max_read_size into account.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/spi/spi-mem.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 1da20b8de5c4..334af682dc65 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -412,6 +412,25 @@ int spi_mem_adjust_op_size(struct spi_slave *slave, struct
spi_mem_op *op)
if (ops->mem_ops && ops->mem_ops->adjust_op_size)
return ops->mem_ops->adjust_op_size(slave, op);
+ if (!ops->mem_ops || !ops->mem_ops->exec_op) {
+ unsigned int len;
+
+ len = sizeof(op->cmd.opcode) + op->addr.nbytes +
+ op->dummy.nbytes;
+ if (slave->max_write_size && len > slave->max_write_size)
+ return -EINVAL;
+
+ if (op->data.dir == SPI_MEM_DATA_IN && slave->max_read_size)
+ op->data.nbytes = min(op->data.nbytes,
+ slave->max_read_size);
+ else if (slave->max_write_size)
+ op->data.nbytes = min(op->data.nbytes,
+ slave->max_write_size - len);
+
+ if (!op->data.nbytes)
+ return -EINVAL;
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size);
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 09/20] mtd: spi: spi-nor-core: Add SPI MEM support
Many SPI controllers have special MMIO interfaces which provide
accelerated read/write access but require knowledge of flash parameters
to make use of it. Recent spi-mem layer provides a way to support such
controllers.
Therefore, add spi-mem support to spi-nor-core as a way to support SPI
controllers with MMIO interface. SPI MEM layer takes care of translating
spi_mem_ops to spi_xfer()s in case of legacy SPI controllers.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/mtd/spi/spi-nor-core.c | 97 --
1 file changed, 93 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 19171766ce82..633b7226f37f 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -88,26 +88,115 @@ struct flash_info {
#define JEDEC_MFR(info)((info)->id[0])
+static int spi_nor_read_write_reg(struct spi_nor *nor, struct spi_mem_op
+ *op, void *buf)
+{
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ op->data.buf.in = buf;
+ else
+ op->data.buf.out = buf;
+ return spi_mem_exec_op(nor->spi, op);
+}
+
static int spi_nor_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
{
- return -EINVAL;
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_IN(len, NULL, 1));
+ int ret;
+
+ ret = spi_nor_read_write_reg(nor, &op, val);
+ if (ret < 0)
+ dev_dbg(&flash->spimem->spi->dev, "error %d reading %x\n", ret,
+ code);
+
+ return ret;
}
static int spi_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
{
- return -EINVAL;
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(len, NULL, 1));
+
+ return spi_nor_read_write_reg(nor, &op, buf);
}
static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t len,
u_char *buf)
{
- return -EINVAL;
+ struct spi_mem_op op =
+ SPI_MEM_OP(SPI_MEM_OP_CMD(nor->read_opcode, 1),
+ SPI_MEM_OP_ADDR(nor->addr_width, from, 1),
+ SPI_MEM_OP_DUMMY(nor->read_dummy, 1),
+ SPI_MEM_OP_DATA_IN(len, buf, 1));
+ size_t remaining = len;
+ int ret;
+
+ /* get transfer protocols. */
+ op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->read_proto);
+ op.addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->read_proto);
+ op.dummy.buswidth = op.addr.buswidth;
+ op.data.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
+
+ /* convert the dummy cycles to the number of bytes */
+ op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
+
+ while (remaining) {
+ op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
+ ret = spi_mem_adjust_op_size(nor->spi, &op);
+ if (ret)
+ return ret;
+
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret)
+ return ret;
+
+ op.addr.val += op.data.nbytes;
+ remaining -= op.data.nbytes;
+ op.data.buf.in += op.data.nbytes;
+ }
+
+ return len;
}
static ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len,
const u_char *buf)
{
- return -EINVAL;
+ struct spi_mem_op op =
+ SPI_MEM_OP(SPI_MEM_OP_CMD(nor->program_opcode, 1),
+ SPI_MEM_OP_ADDR(nor->addr_width, to, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(len, buf, 1));
+ size_t remaining = len;
+ int ret;
+
+ /* get transfer protocols. */
+ op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->write_proto);
+ op.addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->write_proto);
+ op.data.buswidth = spi_nor_get_protocol_data_nbits(nor->write_proto);
+
+ if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
+ op.addr.nbytes = 0;
+
+ while (remaining) {
+ op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
+ ret = spi_mem_adjust_op_size(nor->spi, &op);
+ if (ret)
+ return ret;
+
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if
[U-Boot] [PATCH v3 07/20] sh: bitops: add hweight*() macros
Add hweight*() macros required for moving to new SF layer Signed-off-by: Vignesh R --- arch/sh/include/asm/bitops.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/sh/include/asm/bitops.h b/arch/sh/include/asm/bitops.h index 8cb8385d76db..765f28f116bc 100644 --- a/arch/sh/include/asm/bitops.h +++ b/arch/sh/include/asm/bitops.h @@ -153,6 +153,10 @@ static inline int ffs (int x) } #define PLATFORM_FFS +#define hweight32(x) generic_hweight32(x) +#define hweight16(x) generic_hweight16(x) +#define hweight8(x) generic_hweight8(x) + #endif /* __KERNEL__ */ #endif /* __ASM_SH_BITOPS_H */ -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 05/20] spi: spi-mem: Claim SPI bus before spi mem access
It is necessary to call spi_claim_bus() before starting any SPI
transactions and this restriction would also apply when calling spi-mem
operations. Therefore claim and release bus before requesting transfer
via exec_op.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/spi/spi-mem.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 334af682dc65..1bb0987edb72 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -210,6 +210,10 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct
spi_mem_op *op)
if (!spi_mem_supports_op(slave, op))
return -ENOTSUPP;
+ ret = spi_claim_bus(slave);
+ if (ret < 0)
+ return ret;
+
if (ops->mem_ops) {
#ifndef __UBOOT__
/*
@@ -232,6 +236,7 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct
spi_mem_op *op)
mutex_lock(&ctlr->io_mutex);
#endif
ret = ops->mem_ops->exec_op(slave, op);
+
#ifndef __UBOOT__
mutex_unlock(&ctlr->io_mutex);
mutex_unlock(&ctlr->bus_lock_mutex);
@@ -245,8 +250,10 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct
spi_mem_op *op)
* read path) and expect the core to use the regular SPI
* interface in other cases.
*/
- if (!ret || ret != -ENOTSUPP)
+ if (!ret || ret != -ENOTSUPP) {
+ spi_release_bus(slave);
return ret;
+ }
}
#ifndef __UBOOT__
@@ -333,10 +340,6 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct
spi_mem_op *op)
op_len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
op_buf = calloc(1, op_len);
- ret = spi_claim_bus(slave);
- if (ret < 0)
- return ret;
-
op_buf[pos++] = op->cmd.opcode;
if (op->addr.nbytes) {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 10/20] mtd: spi: spi-nor-core: Add 4 Byte addressing support
Sync changes from Linux SPI NOR framework to add 4 byte addressing
support. This is required in order to support flashes like MT35x
that no longer support legacy Bank Address Register(BAR) way of accessing
>16MB region.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/mtd/spi/spi-nor-core.c | 141 +
1 file changed, 141 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 633b7226f37f..570383464193 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -290,6 +290,126 @@ static struct spi_nor *mtd_to_spi_nor(struct mtd_info
*mtd)
return mtd->priv;
}
+static u8 spi_nor_convert_opcode(u8 opcode, const u8 table[][2], size_t size)
+{
+ size_t i;
+
+ for (i = 0; i < size; i++)
+ if (table[i][0] == opcode)
+ return table[i][1];
+
+ /* No conversion found, keep input op code. */
+ return opcode;
+}
+
+static u8 spi_nor_convert_3to4_read(u8 opcode)
+{
+ static const u8 spi_nor_3to4_read[][2] = {
+ { SPINOR_OP_READ, SPINOR_OP_READ_4B },
+ { SPINOR_OP_READ_FAST, SPINOR_OP_READ_FAST_4B },
+ { SPINOR_OP_READ_1_1_2, SPINOR_OP_READ_1_1_2_4B },
+ { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B },
+ { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B },
+ { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B },
+
+ { SPINOR_OP_READ_1_1_1_DTR, SPINOR_OP_READ_1_1_1_DTR_4B },
+ { SPINOR_OP_READ_1_2_2_DTR, SPINOR_OP_READ_1_2_2_DTR_4B },
+ { SPINOR_OP_READ_1_4_4_DTR, SPINOR_OP_READ_1_4_4_DTR_4B },
+ };
+
+ return spi_nor_convert_opcode(opcode, spi_nor_3to4_read,
+ ARRAY_SIZE(spi_nor_3to4_read));
+}
+
+static u8 spi_nor_convert_3to4_program(u8 opcode)
+{
+ static const u8 spi_nor_3to4_program[][2] = {
+ { SPINOR_OP_PP, SPINOR_OP_PP_4B },
+ { SPINOR_OP_PP_1_1_4, SPINOR_OP_PP_1_1_4_4B },
+ { SPINOR_OP_PP_1_4_4, SPINOR_OP_PP_1_4_4_4B },
+ };
+
+ return spi_nor_convert_opcode(opcode, spi_nor_3to4_program,
+ ARRAY_SIZE(spi_nor_3to4_program));
+}
+
+static u8 spi_nor_convert_3to4_erase(u8 opcode)
+{
+ static const u8 spi_nor_3to4_erase[][2] = {
+ { SPINOR_OP_BE_4K, SPINOR_OP_BE_4K_4B },
+ { SPINOR_OP_BE_32K, SPINOR_OP_BE_32K_4B },
+ { SPINOR_OP_SE, SPINOR_OP_SE_4B },
+ };
+
+ return spi_nor_convert_opcode(opcode, spi_nor_3to4_erase,
+ ARRAY_SIZE(spi_nor_3to4_erase));
+}
+
+static void spi_nor_set_4byte_opcodes(struct spi_nor *nor,
+ const struct flash_info *info)
+{
+ /* Do some manufacturer fixups first */
+ switch (JEDEC_MFR(info)) {
+ case SNOR_MFR_SPANSION:
+ /* No small sector erase for 4-byte command set */
+ nor->erase_opcode = SPINOR_OP_SE;
+ nor->mtd.erasesize = info->sector_size;
+ break;
+
+ default:
+ break;
+ }
+
+ nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
+ nor->program_opcode = spi_nor_convert_3to4_program(nor->program_opcode);
+ nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
+}
+
+/* Enable/disable 4-byte addressing mode. */
+static int set_4byte(struct spi_nor *nor, const struct flash_info *info,
+int enable)
+{
+ int status;
+ bool need_wren = false;
+ u8 cmd;
+
+ switch (JEDEC_MFR(info)) {
+ case SNOR_MFR_ST:
+ case SNOR_MFR_MICRON:
+ /* Some Micron need WREN command; all will accept it */
+ need_wren = true;
+ case SNOR_MFR_MACRONIX:
+ case SNOR_MFR_WINBOND:
+ if (need_wren)
+ write_enable(nor);
+
+ cmd = enable ? SPINOR_OP_EN4B : SPINOR_OP_EX4B;
+ status = nor->write_reg(nor, cmd, NULL, 0);
+ if (need_wren)
+ write_disable(nor);
+
+ if (!status && !enable &&
+ JEDEC_MFR(info) == SNOR_MFR_WINBOND) {
+ /*
+* On Winbond W25Q256FV, leaving 4byte mode causes
+* the Extended Address Register to be set to 1, so all
+* 3-byte-address reads come from the second 16M.
+* We must clear the register to enable normal behavior.
+*/
+ write_enable(nor);
+ nor->cmd_buf[0] = 0;
+ nor->write_reg(nor, SPINOR_OP_WREAR, nor->cmd_buf, 1);
+ write
[U-Boot] [PATCH v3 02/20] bitops: Fix GENMASK definition for Sandbox
In arch/sandbox/include/asm/types.h we have Therefore for 32 bit Sandbox build BITS_PER_LONG turns out to be 32 as CONFIG_PHYS64 is not set This messes up the current logic of GENMASK macro due to mismatch b/w size of unsigned long (64 bit) and that of BITS_PER_LONG. Fix this by using CONFIG_SANDBOX_BITS_PER_LONG which is set to 64/32 based on the host machine on which its being compiled. Without this patch: GENMASK(14,0) => 0x7fff After this patch: GENMASK(14,0) => 0x7fff Signed-off-by: Vignesh R --- include/linux/bitops.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/bitops.h b/include/linux/bitops.h index a47f6d17bb5f..259df43fb00f 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -21,8 +21,13 @@ * position @h. For example * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. */ +#ifdef CONFIG_SANDBOX +#define GENMASK(h, l) \ + (((~0UL) << (l)) & (~0UL >> (CONFIG_SANDBOX_BITS_PER_LONG - 1 - (h +#else #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h +#endif #define GENMASK_ULL(h, l) \ (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 03/20] spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes
SPI controllers support all types of SPI modes including dual/quad bus
widths. Therefore remove constraint wrt SPI mode from spi-mem layer.
Signed-off-by: Vignesh R
Tested-by: Simon Goldschmidt
Tested-by: Stefan Roese
Tested-by: Horatiu Vultur
---
drivers/spi/spi-mem.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index af9aef009a73..1da20b8de5c4 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -323,15 +323,6 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct
spi_mem_op *op)
return -EIO;
#else
- /* U-Boot does not support parallel SPI data lanes */
- if ((op->cmd.buswidth != 1) ||
- (op->addr.nbytes && op->addr.buswidth != 1) ||
- (op->dummy.nbytes && op->dummy.buswidth != 1) ||
- (op->data.nbytes && op->data.buswidth != 1)) {
- printf("Dual/Quad raw SPI transfers not supported\n");
- return -ENOTSUPP;
- }
-
if (op->data.nbytes) {
if (op->data.dir == SPI_MEM_DATA_IN)
rx_buf = op->data.buf.in;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 00/20] SF: Migrate to Linux SPI NOR framework
Here is the v3 of SPI NOR migration(github branch at [1]). I have retained Tested-by from v2 as this is just re split of patches and minor fixups. Travis ci reports all green. Change log: Since v2: Split sync up patches into smaller versions so that its easier for review. Address comments by Jagan and Simon Goldschmidt on v2. Make SPI_FLASH_TINY(read only SF stack) as default for SPL build to offset against size increase due to new code. Since v1: Remove #ifindef __UBOOT__ Add back BAR support, but dont enable as default for all platform (see 10/11 for more details) Enable SPI_FLASH_TINY on boards where there is SPL size constraint as seen on travis ci builds. Drop sf_mtd changes for now as it seems to cause issues. v1: https://patchwork.ozlabs.org/cover/1012146/ Since RFC v2: Fix issues reported by Simon Goldschmidt wrt 4 use of byte addressing opcode Fix issues in compiling SFDP code Re organize file names and Makefile to simply spi-nor-tiny inclusion Remove SPI_FLASH_BAR and SF_DUAL_FLASH as these are no longer used RFC v2: https://patchwork.ozlabs.org/cover/1007589/ Since RFC v1: Add lightweight SPI flash stack for boards with SPL size constraints Provide non DM version of spi-mem Fix build issues on different platforms as reported by travis-ci on v1 RFC v1: https://patchwork.ozlabs.org/cover/1004689/ Background: U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space. Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that. This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top. So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier. Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1] For clean build on some platforms, depends on CONFIG_SPI_FLASH migration to defconfigs [2] [1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v3 [2] https://patchwork.ozlabs.org/patch/1007485/ Vignesh R (20): configs: Move CONFIG_SPI_FLASH into defconfigs bitops: Fix GENMASK definition for Sandbox spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes spi: spi-mem: Extend spi_mem_adjust_op_size() to honor max xfer size spi: spi-mem: Claim SPI bus before spi mem access spi: Add non DM version of SPI_MEM sh: bitops: add hweight*() macros mtd: spi: Port SPI NOR framework from Linux mtd: spi: spi-nor-core: Add SPI MEM support mtd: spi: spi-nor-core: Add 4 Byte addressing support mtd: spi: spi-nor-core: Add SFDP support mtd: spi: spi-nor-core: Add back U-Boot specific features mtd: spi: sf_probe: Add "jedec,spi-nor" compatible string mtd: spi: Switch to new SPI NOR framework mtd: spi: Remove unused files mtd: spi: Add lightweight SPI flash stack for SPL spl: Kconfig: Enable SPI_FLASH_TINY by default for SPL configs: Remove SF_DUAL_FLASH configs: Don't use SPI_FLASH_BAR as default MAINTAINERS: Add an entry for SPI NOR MAINTAINERS |9 + arch/arm/mach-omap2/am33xx/Kconfig|1 - arch/sh/include/asm/bitops.h |4 + common/spl/Kconfig| 23 +- configs/alt_defconfig |1 - configs/am57xx_evm_defconfig |1 - configs/am57xx_hs_evm_defconfig |1 - configs/ap121_defconfig |1 - configs/ap143_defconfig |1 - configs/avnet_ultra96_rev1_defconfig |1 - configs/axs101_defconfig |1 - configs/axs103_defconfig |1 - configs/bg0900_defconfig |1 - configs/blanche_defconfig |1 - configs/cgtqmx6eval_defconfig |1 + configs/chromebit_mickey_defconfig|1 + configs/chromebook_jerry_defconfig|1 + configs/chromebook_minnie_defconfig |1 + configs/cl-som-am57x_defconfig|1 - configs/clearfog_defconfig|1 - configs/cm_t43_defconfig |1 - configs/db-88f6820-amc_defconfig |1 - configs/display5_defconfig|1 - configs/display5_factory_defconfig|1 - configs/dra7xx_evm_defconfig |1 - configs/dra7xx_hs_evm_defconfig |1 - configs/ds109_defconfig
[U-Boot] [PATCH v3 01/20] configs: Move CONFIG_SPI_FLASH into defconfigs
Completely move CONFIG_SPI_FLASH from remaining board header files to defconfigs Signed-off-by: Vignesh R --- configs/cgtqmx6eval_defconfig| 1 + configs/chromebit_mickey_defconfig | 1 + configs/chromebook_jerry_defconfig | 1 + configs/chromebook_minnie_defconfig | 1 + configs/evb-rk3036_defconfig | 1 + configs/evb-rk3128_defconfig | 1 + configs/evb-rk3288_defconfig | 1 + configs/evb-rk3328_defconfig | 1 + configs/fennec-rk3288_defconfig | 1 + configs/firefly-rk3288_defconfig | 1 + configs/kylin-rk3036_defconfig | 1 + configs/ls2080aqds_SECURE_BOOT_defconfig | 1 + configs/ls2080aqds_defconfig | 1 + configs/ls2080aqds_nand_defconfig| 1 + configs/ls2080aqds_qspi_defconfig| 1 + configs/ls2080aqds_sdcard_defconfig | 1 + configs/miqi-rk3288_defconfig| 1 + configs/phycore-rk3288_defconfig | 1 + configs/popmetal-rk3288_defconfig| 1 + configs/rock2_defconfig | 1 + configs/rock_defconfig | 1 + configs/tinker-rk3288_defconfig | 1 + configs/turris_omnia_defconfig | 1 + configs/vyasa-rk3288_defconfig | 1 + include/configs/cgtqmx6eval.h| 1 - include/configs/ls2080aqds.h | 2 -- include/configs/rk3036_common.h | 1 - include/configs/rk3128_common.h | 1 - include/configs/rk3188_common.h | 1 - include/configs/rk3288_common.h | 1 - include/configs/rk3328_common.h | 1 - include/configs/turris_omnia.h | 1 - 32 files changed, 24 insertions(+), 9 deletions(-) diff --git a/configs/cgtqmx6eval_defconfig b/configs/cgtqmx6eval_defconfig index 7f4c8de8f121..e6484b721954 100644 --- a/configs/cgtqmx6eval_defconfig +++ b/configs/cgtqmx6eval_defconfig @@ -55,6 +55,7 @@ CONFIG_DFU_SF=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x1200 CONFIG_FSL_ESDHC=y +CONFIG_SPI_FLASH=y CONFIG_PHYLIB=y CONFIG_MII=y CONFIG_SPI=y diff --git a/configs/chromebit_mickey_defconfig b/configs/chromebit_mickey_defconfig index 1c20dcd882d0..d74596dffd7a 100644 --- a/configs/chromebit_mickey_defconfig +++ b/configs/chromebit_mickey_defconfig @@ -60,6 +60,7 @@ CONFIG_CROS_EC_SPI=y CONFIG_PWRSEQ=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y # CONFIG_SPL_PINCTRL_FULL is not set diff --git a/configs/chromebook_jerry_defconfig b/configs/chromebook_jerry_defconfig index 94a1af01be06..06744e34abbf 100644 --- a/configs/chromebook_jerry_defconfig +++ b/configs/chromebook_jerry_defconfig @@ -62,6 +62,7 @@ CONFIG_CROS_EC_SPI=y CONFIG_PWRSEQ=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y # CONFIG_SPL_PINCTRL_FULL is not set diff --git a/configs/chromebook_minnie_defconfig b/configs/chromebook_minnie_defconfig index cb7f52f040fd..565871496414 100644 --- a/configs/chromebook_minnie_defconfig +++ b/configs/chromebook_minnie_defconfig @@ -61,6 +61,7 @@ CONFIG_CROS_EC_SPI=y CONFIG_PWRSEQ=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y # CONFIG_SPL_PINCTRL_FULL is not set diff --git a/configs/evb-rk3036_defconfig b/configs/evb-rk3036_defconfig index 439e69138636..33eaa062f5b8 100644 --- a/configs/evb-rk3036_defconfig +++ b/configs/evb-rk3036_defconfig @@ -42,6 +42,7 @@ CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_LED=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH=y CONFIG_PINCTRL=y CONFIG_PINCTRL_ROCKCHIP_RK3036=y # CONFIG_SPL_DM_SERIAL is not set diff --git a/configs/evb-rk3128_defconfig b/configs/evb-rk3128_defconfig index 00bf907ff132..d318478267ee 100644 --- a/configs/evb-rk3128_defconfig +++ b/configs/evb-rk3128_defconfig @@ -29,6 +29,7 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH=y CONFIG_PHY=y CONFIG_PINCTRL=y CONFIG_PINCTRL_ROCKCHIP_RK3128=y diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig index 980f7f7b3d61..eb4edd7c15e6 100644 --- a/configs/evb-rk3288_defconfig +++ b/configs/evb-rk3288_defconfig @@ -52,6 +52,7 @@ CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig index 10a5f09b313a..ad675173b61a 100644 --- a/configs/evb-rk3328_defconfig +++ b/configs/evb-rk3328_defconfig @@ -32,6 +32,7 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SPI_FLASH=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y diff --git a/configs/fennec-rk3288_defconfig b/configs/fennec-rk3288_defconfig index 2795ad82b063..df307f95be2d 100644 --- a/configs/fennec-rk3288_defconfig +++ b/configs/fennec-rk3288_defco
[U-Boot] [PATCH v6.1] cmd: env: add "-e" option for handling UEFI variables
# This is a replacement of my patch#1[1] with minor updates.
# The other patches are the exact same as in v6.
# [1] https://lists.denx.de/pipermail/u-boot/2019-January/356035.html
"env [print|set] -e" allows for handling uefi variables without
knowing details about mapping to corresponding u-boot variables.
Signed-off-by: AKASHI Takahiro
---
MAINTAINERS | 1 +
cmd/Kconfig | 6 +
cmd/Makefile | 1 +
cmd/nvedit.c | 28 +++-
cmd/nvedit_efi.c | 340 ++
include/command.h | 4 +
6 files changed, 379 insertions(+), 1 deletion(-)
create mode 100644 cmd/nvedit_efi.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ae825014bda9..22ac686ab2d6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -438,6 +438,7 @@ F: lib/efi*/
F: test/py/tests/test_efi*
F: test/unicode_ut.c
F: cmd/bootefi.c
+F: cmd/nvedit_efi.c
F: tools/file2include.c
FPGA
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ea1a325eb301..c66333598d31 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -53,6 +53,12 @@ config SYS_PROMPT
This string is displayed in the command line to the left of the
cursor.
+config CMD_NVEDIT_EFI
+ bool
+ depends on EFI_LOADER
+ default y
+ imply HEXDUMP
+
menu "Autoboot options"
config AUTOBOOT
diff --git a/cmd/Makefile b/cmd/Makefile
index 15ae4d250f50..142e0ee222ca 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_CMD_MTD) += mtd.o
obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
obj-$(CONFIG_CMD_NAND) += nand.o
obj-$(CONFIG_CMD_NET) += net.o
+obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
obj-$(CONFIG_CMD_ONENAND) += onenand.o
obj-$(CONFIG_CMD_OSD) += osd.o
obj-$(CONFIG_CMD_PART) += part.o
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index ce746bbf1b3e..7973d7add5fc 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -119,6 +119,11 @@ static int do_env_print(cmd_tbl_t *cmdtp, int flag, int
argc,
int rcode = 0;
int env_flag = H_HIDE_DOT;
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+ if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
+ return do_env_print_efi(cmdtp, flag, --argc, ++argv);
+#endif
+
if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'a') {
argc--;
argv++;
@@ -216,6 +221,12 @@ static int _do_env_set(int flag, int argc, char * const
argv[], int env_flag)
ENTRY e, *ep;
debug("Initial value for argc=%d\n", argc);
+
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+ if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
+ return do_env_set_efi(NULL, flag, --argc, ++argv);
+#endif
+
while (argc > 1 && **(argv + 1) == '-') {
char *arg = *++argv;
@@ -1263,14 +1274,21 @@ static char env_help_text[] =
"env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import
environment\n"
#endif
"env print [-a | name ...] - print environment\n"
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+ "env print -e [name ...] - print UEFI environment\n"
+#endif
#if defined(CONFIG_CMD_RUN)
"env run var [...] - run commands in an environment variable\n"
#endif
#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
"env save - save environment\n"
#endif
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+ "env set [-e | -f] name [arg ...]\n";
+#else
"env set [-f] name [arg ...]\n";
#endif
+#endif
U_BOOT_CMD(
env, CONFIG_SYS_MAXARGS, 1, do_env,
@@ -1295,6 +1313,10 @@ U_BOOT_CMD_COMPLETE(
printenv, CONFIG_SYS_MAXARGS, 1,do_env_print,
"print environment variables",
"[-a]\n- print [all] values of all environment variables\n"
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+ "printenv -e [ ...]\n"
+ "- print UEFI variable 'name' or all the variables\n"
+#endif
"printenv name ...\n"
"- print value of environment variable 'name'",
var_complete
@@ -1322,7 +1344,11 @@ U_BOOT_CMD_COMPLETE(
U_BOOT_CMD_COMPLETE(
setenv, CONFIG_SYS_MAXARGS, 0, do_env_set,
"set environment variables",
- "[-f] name value ...\n"
+#if defined(CONFIG_CMD_NVEDIT_EFI)
+ "-e [ ...]\n"
+ "- set UEFI variable 'name' to 'value' ...'\n"
+#endif
+ "setenv [-f] name value ...\n"
"- [forcibly] set environment variable 'name' to 'value ...'\n"
"setenv [-f] name\n"
"- [forcibly] delete environment variable 'name'",
diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
new file mode 100644
index ..64225e2247af
--- /dev/null
+++ b/cmd/nvedit_efi.c
@@ -0,0 +1,340 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Integrate UEFI variables to u-boot env interface
+ *
+ * Copyright (c) 2018 AKASHI Takahiro, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * From efi_variable.c,
+ *
+ * Mapping between UEFI variables and u-boot variable
[U-Boot] [PATCH] mmc: tmio: renesas: Add 1uS delay after DMA completion on older IPs
The internal DMAC asserts DMA transfer end bit too early on older version of the TMIO IPs which use bit 17 for DTRAEND. Add 1uS delay after the completion of DMA transfer and before invalidating the cache to let the DMAC fully complete the transfer. Otherwise, it could happen that the last few bytes of a transferred data are not available. A test case to trigger this behavior is the following command, ran on the U-Boot command line, with Sandisk 16 GiB UHS-I card inserted into SDHI slot 0 and with first partition being of type FAT: => while true ; do mmc rescan ; fstype mmc 0:1 ; done Signed-off-by: Marek Vasut Cc: Masahiro Yamada --- drivers/mmc/tmio-common.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c index 0b6a284f2e..2421915a07 100644 --- a/drivers/mmc/tmio-common.c +++ b/drivers/mmc/tmio-common.c @@ -367,6 +367,9 @@ static int tmio_sd_dma_xfer(struct udevice *dev, struct mmc_data *data) ret = tmio_sd_dma_wait_for_irq(dev, poll_flag, data->blocks); + if (poll_flag == TMIO_SD_DMA_INFO1_END_RD) + udelay(1); + __dma_unmap_single(dma_addr, len, dir); return ret; -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: tmio: Make DMA transfer end bit configurable
Different versions of the SDHI core use either bit 17 or bit 20 for the
DTRAEND indication, which can differ even between SoC revisions. Make
the DTRAEND bit position part of the driver private data, so that the
probe function can set this accordingly. Set this to 20 on Socionext
SoCs and either 17 or 20 on Renesas SoCs, depending on the SoC.
Signed-off-by: Marek Vasut
Cc: Masahiro Yamada
---
drivers/mmc/renesas-sdhi.c | 10 ++
drivers/mmc/tmio-common.c | 8 +++-
drivers/mmc/tmio-common.h | 1 +
drivers/mmc/uniphier-sd.c | 1 +
4 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 733b6d62f5..a556acd5cb 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -462,6 +462,16 @@ static void renesas_sdhi_filter_caps(struct udevice *dev)
priv->nrtaps = 4;
else
priv->nrtaps = 8;
+
+ /* H3 ES1.x and M3W ES1.0 uses bit 17 for DTRAEND */
+ if (((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795) &&
+ (rmobile_get_cpu_rev_integer() <= 1)) ||
+ ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) &&
+ (rmobile_get_cpu_rev_integer() == 1) &&
+ (rmobile_get_cpu_rev_fraction() == 0)))
+ priv->read_poll_flag = TMIO_SD_DMA_INFO1_END_RD;
+ else
+ priv->read_poll_flag = TMIO_SD_DMA_INFO1_END_RD2;
}
static int renesas_sdhi_probe(struct udevice *dev)
diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c
index 201492001f..0b6a284f2e 100644
--- a/drivers/mmc/tmio-common.c
+++ b/drivers/mmc/tmio-common.c
@@ -347,12 +347,10 @@ static int tmio_sd_dma_xfer(struct udevice *dev, struct
mmc_data *data)
/*
* The DMA READ completion flag position differs on Socionext
* and Renesas SoCs. It is bit 20 on Socionext SoCs and using
-* bit 17 is a hardware bug and forbidden. It is bit 17 on
-* Renesas SoCs and bit 20 does not work on them.
+* bit 17 is a hardware bug and forbidden. It is either bit 17
+* or bit 20 on Renesas SoCs, depending on SoC.
*/
- poll_flag = (priv->caps & TMIO_SD_CAP_RCAR) ?
- TMIO_SD_DMA_INFO1_END_RD :
- TMIO_SD_DMA_INFO1_END_RD2;
+ poll_flag = priv->read_poll_flag;
tmp |= TMIO_SD_DMA_MODE_DIR_RD;
} else {
buf = (void *)data->src;
diff --git a/drivers/mmc/tmio-common.h b/drivers/mmc/tmio-common.h
index 192026ce3e..58ce3d65b0 100644
--- a/drivers/mmc/tmio-common.h
+++ b/drivers/mmc/tmio-common.h
@@ -119,6 +119,7 @@ struct tmio_sd_priv {
void __iomem*regbase;
unsigned intversion;
u32 caps;
+ u32 read_poll_flag;
#define TMIO_SD_CAP_NONREMOVABLE BIT(0) /* Nonremovable e.g. eMMC */
#define TMIO_SD_CAP_DMA_INTERNAL BIT(1) /* have internal DMA engine */
#define TMIO_SD_CAP_DIV1024BIT(2) /* divisor 1024 is available */
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index 6539880ab5..8f89bda233 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -47,6 +47,7 @@ static int uniphier_sd_probe(struct udevice *dev)
struct tmio_sd_priv *priv = dev_get_priv(dev);
priv->clk_get_rate = uniphier_sd_clk_get_rate;
+ priv->read_poll_flag = TMIO_SD_DMA_INFO1_END_RD2;
#ifndef CONFIG_SPL_BUILD
int ret;
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/7] cmd: env: add "-e" option for handling UEFI variables
On Fri, Jan 25, 2019 at 01:42:17PM +0100, Alexander Graf wrote:
>
>
> On 24.01.19 12:04, AKASHI Takahiro wrote:
> > "env [print|set] -e" allows for handling uefi variables without
> > knowing details about mapping to corresponding u-boot variables.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > MAINTAINERS | 1 +
> > cmd/Kconfig | 6 +
> > cmd/Makefile | 1 +
> > cmd/nvedit.c | 28 +++-
> > cmd/nvedit_efi.c | 319 ++
> > include/command.h | 4 +
> > 6 files changed, 358 insertions(+), 1 deletion(-)
> > create mode 100644 cmd/nvedit_efi.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ae825014bda9..22ac686ab2d6 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -438,6 +438,7 @@ F: lib/efi*/
> > F: test/py/tests/test_efi*
> > F: test/unicode_ut.c
> > F: cmd/bootefi.c
> > +F: cmd/nvedit_efi.c
> > F: tools/file2include.c
> >
> > FPGA
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index ea1a325eb301..812a7eb9b74b 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -53,6 +53,12 @@ config SYS_PROMPT
> > This string is displayed in the command line to the left of the
> > cursor.
> >
> > +config CMD_NVEDIT_EFI
> > + bool
> > + depends on EFI_LOADER
> > + default y if EFI_LOADER
>
> No need for the "if EFI_LOADER" here. You only ever get to run the
> default path when EFI_LOADER is set due to the depends on line before.
Right.
> > + imply HEXDUMP
> > +
> > menu "Autoboot options"
> >
> > config AUTOBOOT
> > diff --git a/cmd/Makefile b/cmd/Makefile
> > index 15ae4d250f50..142e0ee222ca 100644
> > --- a/cmd/Makefile
> > +++ b/cmd/Makefile
> > @@ -98,6 +98,7 @@ obj-$(CONFIG_CMD_MTD) += mtd.o
> > obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
> > obj-$(CONFIG_CMD_NAND) += nand.o
> > obj-$(CONFIG_CMD_NET) += net.o
> > +obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
> > obj-$(CONFIG_CMD_ONENAND) += onenand.o
> > obj-$(CONFIG_CMD_OSD) += osd.o
> > obj-$(CONFIG_CMD_PART) += part.o
> > diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> > index ce746bbf1b3e..7973d7add5fc 100644
> > --- a/cmd/nvedit.c
> > +++ b/cmd/nvedit.c
> > @@ -119,6 +119,11 @@ static int do_env_print(cmd_tbl_t *cmdtp, int flag,
> > int argc,
> > int rcode = 0;
> > int env_flag = H_HIDE_DOT;
> >
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > + if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
> > + return do_env_print_efi(cmdtp, flag, --argc, ++argv);
> > +#endif
> > +
> > if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'a') {
> > argc--;
> > argv++;
> > @@ -216,6 +221,12 @@ static int _do_env_set(int flag, int argc, char *
> > const argv[], int env_flag)
> > ENTRY e, *ep;
> >
> > debug("Initial value for argc=%d\n", argc);
> > +
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > + if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
> > + return do_env_set_efi(NULL, flag, --argc, ++argv);
> > +#endif
> > +
> > while (argc > 1 && **(argv + 1) == '-') {
> > char *arg = *++argv;
> >
> > @@ -1263,14 +1274,21 @@ static char env_help_text[] =
> > "env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import
> > environment\n"
> > #endif
> > "env print [-a | name ...] - print environment\n"
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > + "env print -e [name ...] - print UEFI environment\n"
> > +#endif
> > #if defined(CONFIG_CMD_RUN)
> > "env run var [...] - run commands in an environment variable\n"
> > #endif
> > #if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
> > "env save - save environment\n"
> > #endif
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > + "env set [-e | -f] name [arg ...]\n";
> > +#else
> > "env set [-f] name [arg ...]\n";
> > #endif
> > +#endif
> >
> > U_BOOT_CMD(
> > env, CONFIG_SYS_MAXARGS, 1, do_env,
> > @@ -1295,6 +1313,10 @@ U_BOOT_CMD_COMPLETE(
> > printenv, CONFIG_SYS_MAXARGS, 1,do_env_print,
> > "print environment variables",
> > "[-a]\n- print [all] values of all environment variables\n"
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > + "printenv -e [ ...]\n"
> > + "- print UEFI variable 'name' or all the variables\n"
> > +#endif
> > "printenv name ...\n"
> > "- print value of environment variable 'name'",
> > var_complete
> > @@ -1322,7 +1344,11 @@ U_BOOT_CMD_COMPLETE(
> > U_BOOT_CMD_COMPLETE(
> > setenv, CONFIG_SYS_MAXARGS, 0, do_env_set,
> > "set environment variables",
> > - "[-f] name value ...\n"
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > + "-e [ ...]\n"
> > + "- set UEFI variable 'name' to 'value' ...'\n"
> > +#endif
> > + "setenv [-f] name value ...\n"
> > "- [forcibly] set environment variable 'name' to 'value ...'\n"
> > "setenv [-f] name\n"
> > "- [forcibly] delete environment variable 'name'",
> > diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
> >
Re: [U-Boot] [RFC 1/3] dm: blk: add UCLASS_PARTITION
On Tue, 29 Jan 2019, AKASHI Takahiro wrote: My $.25 -- IMHO, block device partitions in Device Tree is _NOT_ a very good idea. What if one decided to re-partition his drive? Or just use bigger or smaller drive? Would he has to re-write DTS file and re-compile everything? And such change is not something extraordinary, it is a routine action. IMHO partitions do _NOT_ belong to Block Device. That's what partition tables are. It _MIGHT_ make sense for some particular devices such as MTD that don't have partition tables but _NOT_ for Block Devices in general. UCLASS_PARTITION device will be created as a child node of UCLASS_BLK device. Signed-off-by: AKASHI Takahiro --- ** * KSI@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/7] cmd: add efidebug for efi environment
Alex, On Fri, Jan 25, 2019 at 12:56:52PM +0100, Alexander Graf wrote: > > > On 24.01.19 12:04, AKASHI Takahiro wrote: > > This patch set is a collection of patches to enhance efi user interfaces > > /commands. It will help improve user experience on efi boot and make it > > more usable *without* edk2's shell utility. > > > > Let's see how it works: > > => efidebug boot add 1 SHELL scsi 1:1 /Shell.efi "" > > => efidebug boot add 2 HELLO scsi 1:1 /hello.efi "" > > => efidebug boot dump > > Boot0001: > > attributes: A-- (0x0001) > > label: SHELL > > file_path: > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,MBR,0x086246ba,0x800,0x4)/\\Shell.efi > > data: > > Boot0002: > > attributes: A-- (0x0001) > > label: HELLO > > file_path: > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,MBR,0x086246ba,0x800,0x4)/\\hello.efi > > data: > > > > => efidebug boot order 1 2 > > => efidebug boot order > > 1: Boot0001: SHELL > > 2: Boot0002: HELLO > > > > => run -e Boot0002 (or bootefi bootmgr - 2) ; '-' means no dtb specified > > WARNING: booting without device tree > > Booting: HELLO > > ## Starting EFI application at 7db8b040 ... > > Hello, world! > > ## Application terminated, r = 0 > > > > => env set -e PlatformLang en ; important! > > => env print -e > > Boot0001: BS|RT, DataSize = 0x79 > > : 01 00 00 00 66 00 53 00 48 00 45 00 4c 00 4c 00 > > f.S.H.E.L.L. > > 0010: 00 00 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab > > ...s.J.. > > 0020: 82 e8 28 f3 62 8b 03 02 08 00 01 00 00 00 04 01 > > ..(.b... > > 0030: 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 > > *... > > 0040: 04 00 00 00 00 00 ba 46 62 08 00 00 00 00 00 00 > > ...Fb... > > 0050: 00 00 00 00 00 00 01 01 04 04 1c 00 5c 00 5c 00 > > \.\. > > 0060: 53 00 68 00 65 00 6c 00 6c 00 2e 00 65 00 66 00 > > S.h.e.l.l...e.f. > > 0070: 69 00 00 00 7f ff 04 00 00 i > > Boot0002: BS|RT, DataSize = 0x79 > > : 01 00 00 00 66 00 48 00 45 00 4c 00 4c 00 4f 00 > > f.H.E.L.L.O. > > 0010: 00 00 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab > > ...s.J.. > > 0020: 82 e8 28 f3 62 8b 03 02 08 00 01 00 00 00 04 01 > > ..(.b... > > 0030: 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 > > *... > > 0040: 04 00 00 00 00 00 ba 46 62 08 00 00 00 00 00 00 > > ...Fb... > > 0050: 00 00 00 00 00 00 01 01 04 04 1c 00 5c 00 5c 00 > > \.\. > > 0060: 68 00 65 00 6c 00 6c 00 6f 00 2e 00 65 00 66 00 > > h.e.l.l.o...e.f. > > 0070: 69 00 00 00 7f ff 04 00 00 i > > BootOrder: BS|RT, DataSize = 0x4 > > : 01 00 02 00 > > PlatformLang: BS|RT, DataSize = 0x2 > > : 65 6een > > > > => run -e Boot0001 or bootefi bootmgr > > > >(UEFI shell ...) > > > > "env set" command now supports UEFI shell-like syntax: > > > > => env set -e foo =S\"akashi\" =0x012345 =Habcdef > > => env print -e foo > > foo: BS|RT, DataSize = 0xd > > : 61 6b 61 73 68 69 45 23 01 00 ab cd ef akashiE#. > > > > Other useful sub commands are: > > => efidebug devices ; print uefi devices > > => efidebug drivers ; print uefi drivers > > => efidebug dh ; print uefi handles > > => efidebug images ; print loaded images > > => efidebug memmap ; dump uefi memory map > > > > Enjoy! > > Did this patch set successfully pass Travis tests? Could you please > point me to the results? Not yet, probably next time? It may take some time for me to set up travis. -Takahiro Akashi > > Thanks, > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 3/3] drivers: align block device drivers with DM-efi integration
Efi_disk_create() should be hook up at every creation of block device
at each driver. Associated blk_desc must be properly set up before
calling this function.
Signed-off-by: AKASHI Takahiro
---
common/usb_storage.c | 27 +--
drivers/scsi/scsi.c | 22 ++
lib/efi_driver/efi_block_device.c | 30 +-
3 files changed, 56 insertions(+), 23 deletions(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index 8c889bb1a648..ff895c0e4557 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -46,6 +46,10 @@
#include
#include
+/* FIXME */
+extern int efi_disk_create(struct udevice *dev);
+extern int blk_create_partitions(struct udevice *parent);
+
#undef BBB_COMDAT_TRACE
#undef BBB_XPORT_TRACE
@@ -227,8 +231,27 @@ static int usb_stor_probe_device(struct usb_device *udev)
ret = usb_stor_get_info(udev, data, blkdev);
if (ret == 1) {
- usb_max_devs++;
- debug("%s: Found device %p\n", __func__, udev);
+ ret = efi_disk_create(dev);
+ if (ret) {
+ debug("Cannot create efi_disk device\n");
+ ret = device_unbind(dev);
+ if (ret)
+ return ret;
+ } else {
+ usb_max_devs++;
+ ret = blk_create_partitions(dev);
+ if (ret < 0) {
+ debug("Cannot create disk partition
device\n");
+ /* TODO: undo create */
+
+ ret = device_unbind(dev);
+ if (ret)
+ return ret;
+ }
+ usb_max_devs += ret;
+ debug("%s: Found device %p, partitions:%d\n",
+ __func__, udev, ret);
+ }
} else {
debug("usb_stor_get_info: Invalid device\n");
ret = device_unbind(dev);
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index df47e2fc78bd..f0f8cbc0bf26 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -11,6 +11,10 @@
#include
#include
+/* FIXME */
+int efi_disk_create(struct udevice *dev);
+int blk_create_partitions(struct udevice *parent);
+
#if !defined(CONFIG_DM_SCSI)
# ifdef CONFIG_SCSI_DEV_LIST
# define SCSI_DEV_LIST CONFIG_SCSI_DEV_LIST
@@ -593,9 +597,27 @@ static int do_scsi_scan_one(struct udevice *dev, int id,
int lun, bool verbose)
memcpy(&bdesc->product, &bd.product, sizeof(bd.product));
memcpy(&bdesc->revision, &bd.revision, sizeof(bd.revision));
+ ret = efi_disk_create(bdev);
+ if (ret) {
+ debug("Can't create efi_disk device\n");
+ ret = device_unbind(bdev);
+
+ return ret;
+ }
+ ret = blk_create_partitions(bdev);
+ if (ret < 0) {
+ debug("Can't create efi_disk partitions\n");
+ /* TODO: undo create */
+
+ ret = device_unbind(bdev);
+
+ return ret;
+ }
+
if (verbose) {
printf(" Device %d: ", 0);
dev_print(bdesc);
+ debug("Found %d partitions\n", ret);
}
return 0;
}
diff --git a/lib/efi_driver/efi_block_device.c
b/lib/efi_driver/efi_block_device.c
index 3f147cf60879..4ab3402d6768 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -32,6 +32,10 @@
#include
#include
+/* FIXME */
+extern int efi_disk_create(struct udevice *dev);
+extern int blk_create_partitions(struct udevice *parent);
+
/*
* EFI attributes of the udevice handled by this driver.
*
@@ -102,24 +106,6 @@ static ulong efi_bl_write(struct udevice *dev, lbaint_t
blknr, lbaint_t blkcnt,
return blkcnt;
}
-/*
- * Create partions for the block device.
- *
- * @handle EFI handle of the block device
- * @devudevice of the block device
- */
-static int efi_bl_bind_partitions(efi_handle_t handle, struct udevice *dev)
-{
- struct blk_desc *desc;
- const char *if_typename;
-
- desc = dev_get_uclass_platdata(dev);
- if_typename = blk_get_if_type_name(desc->if_type);
-
- return efi_disk_create_partitions(handle, desc, if_typename,
- desc->devnum, dev->name);
-}
-
/*
* Create a block device for a handle
*
@@ -168,15 +154,17 @@ static int efi_bl_bind(efi_handle_t handle, void
*interface)
platdata->handle = handle;
platdata->io = interface;
+ ret = efi_disk_create(bdev);
+ if (ret)
+
[U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk
efi_disk_create() will initialize efi_disk attributes for each device,
either UCLASS_BLK or UCLASS_PARTITION.
Currently (temporarily), efi_disk_obj structure is embedded into
blk_desc to hold efi-specific attributes.
Signed-off-by: AKASHI Takahiro
---
drivers/block/blk-uclass.c | 9 ++
drivers/core/device.c | 3 +
include/blk.h | 24 +
include/dm/device.h| 4 +
lib/efi_loader/efi_disk.c | 192 ++---
5 files changed, 174 insertions(+), 58 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index d4ca30f23fc1..28c45d724113 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -657,6 +657,9 @@ UCLASS_DRIVER(blk) = {
.per_device_platdata_auto_alloc_size = sizeof(struct blk_desc),
};
+/* FIXME */
+extern int efi_disk_create(struct udevice *dev);
+
U_BOOT_DRIVER(blk_partition) = {
.name = "blk_partition",
.id = UCLASS_PARTITION,
@@ -695,6 +698,12 @@ int blk_create_partitions(struct udevice *parent)
part_data->partnum = part;
part_data->gpt_part_info = info;
+ ret = efi_disk_create(dev);
+ if (ret) {
+ device_unbind(dev);
+ return ret;
+ }
+
disks++;
}
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 0d15e5062b66..8625fccb0dcb 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -67,6 +67,9 @@ static int device_bind_common(struct udevice *parent, const
struct driver *drv,
dev->parent = parent;
dev->driver = drv;
dev->uclass = uc;
+#ifdef CONFIG_EFI_LOADER
+ INIT_LIST_HEAD(&dev->efi_obj.protocols);
+#endif
dev->seq = -1;
dev->req_seq = -1;
diff --git a/include/blk.h b/include/blk.h
index d0c033aece0f..405f6f790d66 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -8,6 +8,7 @@
#define BLK_H
#include
+#include
#ifdef CONFIG_SYS_64BIT_LBA
typedef uint64_t lbaint_t;
@@ -53,6 +54,26 @@ enum sig_type {
SIG_TYPE_COUNT /* Number of signature types */
};
+/* FIXME */
+/**
+ * struct efi_disk_obj - EFI disk object
+ *
+ * @ops: EFI disk I/O protocol interface
+ * @media: block I/O media information
+ * @dp:device path to the block device
+ * @part: partition
+ * @volume:simple file system protocol of the partition
+ * @offset:offset into disk for simple partition
+ */
+struct efi_disk_obj {
+ struct efi_block_io ops;
+ struct efi_block_io_media media;
+ struct efi_device_path *dp;
+ unsigned int part;
+ struct efi_simple_file_system_protocol *volume;
+ lbaint_t offset;
+};
+
/*
* With driver model (CONFIG_BLK) this is uclass platform data, accessible
* with dev_get_uclass_platdata(dev)
@@ -92,6 +113,9 @@ struct blk_desc {
* device. Once these functions are removed we can drop this field.
*/
struct udevice *bdev;
+#ifdef CONFIG_EFI_LOADER
+ struct efi_disk_obj efi_disk;
+#endif
#else
unsigned long (*block_read)(struct blk_desc *block_dev,
lbaint_t start,
diff --git a/include/dm/device.h b/include/dm/device.h
index 27a6d7b9fdb0..121bfb46b1a0 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -146,6 +147,9 @@ struct udevice {
#ifdef CONFIG_DEVRES
struct list_head devres_head;
#endif
+#ifdef CONFIG_EFI_LOADER
+ struct efi_object efi_obj;
+#endif
};
/* Maximum sequence number supported */
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index c037526ad2d0..84fa0ddfba14 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -14,33 +14,6 @@
const efi_guid_t efi_block_io_guid = BLOCK_IO_GUID;
-/**
- * struct efi_disk_obj - EFI disk object
- *
- * @header:EFI object header
- * @ops: EFI disk I/O protocol interface
- * @ifname:interface name for block device
- * @dev_index: device index of block device
- * @media: block I/O media information
- * @dp:device path to the block device
- * @part: partition
- * @volume:simple file system protocol of the partition
- * @offset:offset into disk for simple partition
- * @desc: internal block device descriptor
- */
-struct efi_disk_obj {
- struct efi_object header;
- struct efi_block_io ops;
- const char *ifname;
- int dev_index;
- struct efi_block_io_media media;
- struct efi_device_path *dp;
- unsigned int part;
- struct efi_simple_file_system_protocol *volume;
- lbaint_t offset;
- struct blk_desc *desc;
-};
-
static efi_status_t EFIAPI efi_disk_reset(struct efi_block_io *this,
char extended_verification)
{
@@ -6
[U-Boot] [RFC 0/3] dm, efi: integrate efi_disk into DM
This patch set came from the past discussion[1] on my "removable device support" patch and is intended to be an attempt to integrate efi_disk (more precisely, EFI_BLOCK_IO_PROTOCOL-capable efi object) into u-boot's Driver Model as much seamlessly as possible [1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html Basic idea is * create UCLASS_PARTITION * enumerate all the partitions when a block device is probed * hook up a creation of UCLASS_BLK or UCLASS_PARTITION device to efi handler for efi_disk attributes to be properly set up Since this patch is a prototype (or POC, proof-of-concept), the aim here is to discuss further about how in a better shape we will be able to merge the two worlds. Example operation: (Two scsi disks, one with no partition, one with two partitions) U-Boot 2019.01-rc3-00024-ga81a6f87ad48 (Jan 29 2019 - 10:56:45 +0900) DRAM: 1 GiB In:pl011@900 Out: pl011@900 Err: pl011@900 Net: No ethernet found. Hit any key to stop autoboot: 0 => efi devices Device Device Path 7ef01350 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) => scsi rescan Reset SCSI scanning bus for devices... Target spinup took 0 ms. Target spinup took 0 ms. SATA link 2 timeout. SATA link 3 timeout. SATA link 4 timeout. SATA link 5 timeout. AHCI 0001. 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode flags: 64bit ncq only Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 16.0 MB = 0.0 GB (32768 x 512) Device 0: (1:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 256.0 MB = 0.2 GB (524288 x 512) => efi devices Device Device Path 7ef01350 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) 7ef0b2c0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0) 7ef0b7b0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0) 7ef0c760 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(-1,MBR,0x086246ba,0x17ff56048,0x7eeeb770) 7ef0cb50 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(-1,MBR,0x086246ba,0x17ff56048,0x7eeeb770) => dm tree Classindex Probed DriverName --- root0 [ + ] root_driver root_driver ... pci 0 [ + ] pci_generic_ecam |-- pcie@1000 pci_generi 0 [ ] pci_generic_drv | |-- pci_0:0.0 virtio 32 [ ] virtio-pci.l | |-- virtio-pci.l#0 ahci0 [ + ] ahci_pci | `-- ahci_pci scsi0 [ + ] ahci_scsi | `-- ahci_scsi blk 0 [ ] scsi_blk | |-- ahci_scsi.id0lun0 blk 1 [ ] scsi_blk | `-- ahci_scsi.id1lun0 partition 0 [ ] blk_partition | |-- ahci_scsi.id1lun0:1 partition 1 [ ] blk_partition | `-- ahci_scsi.id1lun0:2 ... Thanks, -Takahiro Akashi AKASHI Takahiro (3): dm: blk: add UCLASS_PARTITION efi_loader: associate BLK/PARTITION device to efi_disk drivers: align block device drivers with DM-efi integration common/usb_storage.c | 27 - drivers/block/blk-uclass.c| 61 ++ drivers/core/device.c | 3 + drivers/scsi/scsi.c | 22 include/blk.h | 24 include/dm/device.h | 4 + include/dm/uclass-id.h| 1 + lib/efi_driver/efi_block_device.c | 30 ++--- lib/efi_loader/efi_disk.c | 192 +- 9 files changed, 283 insertions(+), 81 deletions(-) -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 1/3] dm: blk: add UCLASS_PARTITION
UCLASS_PARTITION device will be created as a child node of
UCLASS_BLK device.
Signed-off-by: AKASHI Takahiro
---
drivers/block/blk-uclass.c | 52 ++
include/dm/uclass-id.h | 1 +
2 files changed, 53 insertions(+)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index baaf431e5e0c..d4ca30f23fc1 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
static const char *if_typename_str[IF_TYPE_COUNT] = {
[IF_TYPE_IDE] = "ide",
@@ -654,3 +656,53 @@ UCLASS_DRIVER(blk) = {
.post_probe = blk_post_probe,
.per_device_platdata_auto_alloc_size = sizeof(struct blk_desc),
};
+
+U_BOOT_DRIVER(blk_partition) = {
+ .name = "blk_partition",
+ .id = UCLASS_PARTITION,
+ .platdata_auto_alloc_size = sizeof(struct disk_part),
+};
+
+UCLASS_DRIVER(partition) = {
+ .id = UCLASS_PARTITION,
+ .name = "partition",
+};
+
+#if defined(CONFIG_PARTITIONS) && defined(CONFIG_HAVE_BLOCK_DEVICE)
+int blk_create_partitions(struct udevice *parent)
+{
+ int part;
+ struct blk_desc *desc = dev_get_uclass_platdata(parent);
+ disk_partition_t info;
+ struct disk_part *part_data;
+ char devname[32];
+ struct udevice *dev;
+ int disks = 0, ret;
+
+ /* Add devices for each partition */
+ for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+ if (part_get_info(desc, part, &info))
+ continue;
+ snprintf(devname, sizeof(devname), "%s:%d", parent->name,
+part);
+
+ ret = device_bind_driver(parent, "blk_partition",
+strdup(devname), &dev);
+ if (ret)
+ return ret;
+
+ part_data = dev_get_uclass_platdata(dev);
+ part_data->partnum = part;
+ part_data->gpt_part_info = info;
+
+ disks++;
+ }
+
+ return disks;
+}
+#else
+int blk_create_partitions(struct udevice *dev)
+{
+ return 0;
+}
+#endif
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index f3bafb3c6353..e02b5f8fda42 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -65,6 +65,7 @@ enum uclass_id {
UCLASS_NVME,/* NVM Express device */
UCLASS_PANEL, /* Display panel, such as an LCD */
UCLASS_PANEL_BACKLIGHT, /* Backlight controller for panel */
+ UCLASS_PARTITION, /* Logical disk partition device */
UCLASS_PCH, /* x86 platform controller hub */
UCLASS_PCI, /* PCI bus */
UCLASS_PCI_GENERIC, /* Generic PCI bus device */
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot and USB 3.0
Hi, On Tue, Jan 29, 2019 at 1:32 AM DJM-Avalesta wrote: > > Dear Bin Meng, > > I have a version of U-Boot, on my Jetson TX2 hardware, which does not support > USB 3.0. > > > U-Boot 2016.07-g9c3b9a4 > > (May 17 2018 - 00:08:48 -0700) > > Can you please use latest U-Boot instead? That will be much easier. > Is it possible to apply one or more of your patches to this version to > implement support for USB 3.0? > Technically it's doable. > > Many thanks for your help. > > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time
Simon, On Mon, Jan 28, 2019 at 05:46:21PM -0700, Simon Glass wrote: > Hi, > > On Mon, 28 Jan 2019 at 01:55, AKASHI Takahiro > wrote: > > > > On Fri, Jan 25, 2019 at 10:31:20AM +0100, Alexander Graf wrote: > > > > > > > > > On 25.01.19 10:18, AKASHI Takahiro wrote: > > > > On Fri, Jan 25, 2019 at 09:52:31AM +0100, Alexander Graf wrote: > > > >> > > > >> > > > >> On 25.01.19 09:27, AKASHI Takahiro wrote: > > > >>> Alex, > > > >>> > > > >>> On Wed, Jan 23, 2019 at 10:51:29AM +0100, Alexander Graf wrote: > > > On 01/22/2019 08:39 PM, Simon Glass wrote: > > > > Hi Alex, > > > > > > > > On Tue, 22 Jan 2019 at 22:08, Alexander Graf wrote: > > > >> > > > >> > > > >> On 22.01.19 09:29, AKASHI Takahiro wrote: > > > >>> Alex, Simon, > > > >>> > > > >>> Apologies for my slow response on this matter, > > > >>> > > > >>> On Fri, Jan 11, 2019 at 08:57:05AM +0100, Alexander Graf wrote: > > > > > > On 11.01.19 05:29, AKASHI Takahiro wrote: > > > > Alex, Heinrich and Simon, > > > > > > > > Thank you for your comments, they are all valuable but also > > > > make me > > > > confused as different people have different requirements :) > > > > I'm not sure that all of us share the same *ultimate* goal here. > > > The shared ultimate goal is to "merge" (as Simon put it) dm and > > > efi objects. > > > >>> I don't still understand what "merge" means very well. > > > >> It basically means that "struct efi_object" moves into "struct > > > >> udevice". > > > >> Every udevice instance of type UCLASS_BLK would expose the block > > > >> and > > > >> device_path protocols. > > > >> > > > >> This will be a slightly bigger rework, but eventually allows us to > > > >> basically get rid of efi_init_obj_list() I think. > > > > I envisaged something like: > > > > > > > > - EFI objects have their own UCLASS_EFI uclass > > > > > > ... and then we need to create our own sub object model around the > > > UCLASS_EFI devices again. I' not convinced that's a great idea yet > > > :). I > > > really see little reason not to just expose every dm device as EFI > > > handle. > > > Things would plug in quite naturally I think. > > > >>> > > > >>> You said that the ultimate goal is to remove all efi_object data. > > > >>> Do you think that all the existing efi_object can be mapped to > > > >>> one of existing u-boot uclass devices? > > > >>> > > > >>> If so, what would be an real entity of a UEFI handle? > > > >>> struct udevice *? > > > >>> > > > >>> But Simon seems not to agree to adding any UEFI-specific members > > > >>> in struct udevice. > > > >> > > > >> I think we'll have to experiment with both approaches. I personally > > > >> would like to have struct udevice * be the UEFI handle, yes. > > > >> > > > >>> > > > But either way, someone would need to sit down and prototype things > > > to be > > > sure. > > > > > > >>> > > > >>> The most simplest prototype would include > > > >>> * event mechanism (just registration and execution of hook/handler) > > > >>> event: udevice creation (and deletion) > > > >>> * efi_disk hook for udevice(UCLASS_BLK) creation > > > >>> * modified block device's enumeration code, say, scsi_scan(), > > > >>> to add an event hook at udevice creation > > > >>> * removing efi_disk_register() from efi_init_obj_list() > > > >>> * Optionally(?) UCLASS_PARTITION > > > >>> (Partition udevices would be created in part_init().) > > > >> > > > >> Almost. > > > >> > > > >> The simplest prototype would be to add a struct efi_object into struct > > > >> udevice. Then whenever we're looping over efi_obj_list in the code, we > > > >> additionally loop over all udevices to find the handle. > > > > > > > > Ah, yes. You're going further :) > > > > > > > >> Then, we could slowly give the uclasses explicit knowledge of uefi > > > >> protocols. So most of the logic of efi_disk_register() would move into > > > >> (or get called by) drivers/block/blk-uclass.c:blk_create_device(). > > > > > > > > Via event? Otherwise, we cannot decouple u-boot and UEFI world. > > > > > > For a prototype, just make it explicit and see how far that gets us. > > > > > > >> Instead of creating diskobj and adding calling efi_add_handle(), we > > > >> could then just use existing data structure from the udevice (and its > > > >> platdata). > > > > > > > > I don't have good confidence that we can remove struct efi_disk_obj, > > > > at least, for the time being as some of its members are quite > > > > UEFI-specific. > > > > > > Maybe we can move them into struct blk_desc? It's a matter of > > > experimenting I guess. > > > > > > > > > > >> > > > >> Does this make sense? Less events, more implicity :). > > > > > > > > I'll go for it. > > > > > > Thanks a lot :). Feel free to pick an easier target for starters too if > > > y
Re: [U-Boot] [PATCH 07/10] clk: imx8: add i.MX8QM clk driver
> -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: 2019年1月28日 22:24 > To: Stefano Babic > Cc: Peng Fan ; Fabio Estevam > ; u-boot@lists.denx.de; dl-uboot-imx > ; Lukasz Majewski > Subject: Re: [U-Boot] [PATCH 07/10] clk: imx8: add i.MX8QM clk driver > > Hi Stefano, > > On Mon, Jan 28, 2019 at 12:04 PM Stefano Babic wrote: > > > Ok - I see you decide to split the code on depend of the SOC type. > > Nevertheless, even if defines are different, it seems to me that there > > is still a lot of common code (_imx8_clk_enable is very similar). Do > > we need really a separate file for each MX8 variant ? Which are the > > blocking points that avoid to do this ? I am looking at the patch, but > > I do not find such as issue. Can you explain it ? > > I am also concerned about the current i.MX clock driver status in U-Boot and I > expressed this during my review of Lukasz's patch that added a imx6 clock > driver. > > It does not scale well as we can see by the huge switch statement in this > patch. Of course this would need to grow when new peripherals clocks are > added. > > I think a better approach would be to use the same scheme as done in the > kernel with common clock framework. > > Barebox folows this same approach. For example: > > i.MX8M clock driver: > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.p > engutronix.de%2Fcgit%2Fbarebox%2Ftree%2Fdrivers%2Fclk%2Fimx%2Fclk-i > mx8mq.c&data=02%7C01%7Cpeng.fan%40nxp.com%7C124a7ae228794 > 2551ea208d6852c3c0a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C > 0%7C636842822364000869&sdata=6xwmlVrr2MGKkRCNUFZTBcec9KP > RNoID%2FBWTU5HFKcg%3D&reserved=0 > > i.MX6Q clock driver: > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.p > engutronix.de%2Fcgit%2Fbarebox%2Ftree%2Fdrivers%2Fclk%2Fimx%2Fclk-i > mx6.c&data=02%7C01%7Cpeng.fan%40nxp.com%7C124a7ae22879425 > 51ea208d6852c3c0a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0% > 7C636842822364000869&sdata=m6%2FRa8HY9M1aPXy45%2Bp0aa9Xit > 6cMUVqBw%2F4UVTSOz0%3D&reserved=0 > > It allows syncing with the kernel clock driver more easily and it makes it > easier to maintain several i.MX SoCs in the long term. I thought about this before, but this will increase SPL code side a lot when SPL DM clk used. Regards, Peng. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] clk: imx8: add i.MX8QM clk driver
Hi Stefano > > + > > > > Ok - I see you decide to split the code on depend of the SOC type. > Nevertheless, even if defines are different, it seems to me that there is > still a > lot of common code (_imx8_clk_enable is very similar). Do we need really a > separate file for each MX8 variant ? Which are the blocking points that avoid > to do this ? I am looking at the patch, but I do not find such as issue. Can > you > explain it ? I do not want to mix i.MX8QXP and QM currently, although it looks most same logic except the macros. Linux side code still not merged by upstream, there will be some change there I think. Then I think uboot side code also need some restructure following Linux change. Another one is there are many variants, not only QXP/QM, add all the macros in one file will make it not elegant and end up of more and more ifdef in one file. Thanks, Peng. > > Regards, > Stefano > > > -- > == > === > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > == > === ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
Hi Alex,
On Mon, 28 Jan 2019 at 13:08, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:47, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:39, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:36, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:31, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:24, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:13, Simon Glass wrote:
> > Hi,
> >
> > On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
> >>
> >> Our selftest will soon test the actual runtime reset function
> >> rather than
> >> the boot time one. For this, we need to ensure that the runtime
> >> version
> >> actually succeeds on x86 to keep our travis tests work.
> >>
> >> So this patch implements an x86 runtime reset function. It is
> >> missing
> >> shutdown functionality today, but OSs usually implement that via
> >> ACPI
> >> and this function does more than the stub from before, so it's at
> >> least
> >> an improvement.
> >>
> >> Signed-off-by: Alexander Graf
> >> ---
> >> drivers/sysreset/sysreset_x86.c | 23 +++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/sysreset/sysreset_x86.c
> >> b/drivers/sysreset/sysreset_x86.c
> >> index 20b958cfd4..efed45ccb7 100644
> >> --- a/drivers/sysreset/sysreset_x86.c
> >> +++ b/drivers/sysreset/sysreset_x86.c
> >> @@ -10,6 +10,29 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> +
> >> +#ifdef CONFIG_EFI_LOADER
> >> +void __efi_runtime EFIAPI efi_reset_system(
> >> + enum efi_reset_type reset_type,
> >> + efi_status_t reset_status,
> >> + unsigned long data_size, void *reset_data)
> >> +{
> >> + u32 value = 0;
> >> +
> >> + if (reset_type == EFI_RESET_COLD)
> >> + value = SYS_RST | RST_CPU | FULL_RST;
> >> + else if (reset_type == EFI_RESET_WARM)
> >> + value = SYS_RST | RST_CPU;
> >
> > The EFI should use the sysreset driver and sysreset_walk() or
> > similar,
> > rather than having a function called directly.
>
> It can't. At this point all of DM is long gone. We're in runtime
> space here.
> >>>
> >>> This has come up before. We'll end up with a lot of duplication if we
> >>> cannot solve this. I think the run-time code will need to be built and
> >>> linked separately so that all necessary code is pulled in.
> >>
> >> It's mostly a question of size. We can even transform all of U-Boot
> >> into
> >> huge runtime services if we keep the relocation tables around and apply
> >> relocations manually for everything.
> >>
> >> The problem is that if we do that, we'll become even bigger than we are
> >> now, no?
> >
> > I did a change to build U-Boot as a library, perhaps it could build on
> > that. The 'run-time U-Boot' won't be any bigger than the code that is
> > actually used. Also I don't think memory usage is a concern in systems
> > that use UEFI :-)
>
> It is, we're already exploding some constraints today. Furthermore, by
> moving all of U-Boot into RTS you obviously waste a few MB of RAM while
> Linux is up. And it's much harder to review that the code is only doing
> what you want it to do.
> >>>
> >>> My suggest is not to move all of U-Boot into RTS. It is to build an
> >>> RTS version of U-Boot with just those things that are needed, a bit
> >>> like TPL or SPL.
> >>
> >> Yes, but the "loaded binary" to boot the system is then BTS + RTS. So if
> >> U-Boot is 1MB and the RTS U-Boot build is 0.5MB, you need to store and
> >> load 1.5MB from SD card or SPI or wherever your U-Boot is stored.
> >
> > Yes that's right. Although I suspect it is only about half that. E.g.
> > Raspberry Pi 2 is 431KB. I'd hope that RTS would be very small?
> >
> >>
> >>
> >> By morphing all of U-Boot over, the runtime cost is higher (1MB rather
> >> than 0.5MB used while Linux is up), but the boot time cost is smaller
> >> (only 1MB on storage).
> >>
> >>> I did not invent the run-time aspect of EFI, but I feel we are trying
> >>> to support it with a hack.
> >>
> >> Well, it is a hack in edk2 as well. RTS are a terrible idea in my book.
> >>
Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time
Hi, On Mon, 28 Jan 2019 at 01:55, AKASHI Takahiro wrote: > > On Fri, Jan 25, 2019 at 10:31:20AM +0100, Alexander Graf wrote: > > > > > > On 25.01.19 10:18, AKASHI Takahiro wrote: > > > On Fri, Jan 25, 2019 at 09:52:31AM +0100, Alexander Graf wrote: > > >> > > >> > > >> On 25.01.19 09:27, AKASHI Takahiro wrote: > > >>> Alex, > > >>> > > >>> On Wed, Jan 23, 2019 at 10:51:29AM +0100, Alexander Graf wrote: > > On 01/22/2019 08:39 PM, Simon Glass wrote: > > > Hi Alex, > > > > > > On Tue, 22 Jan 2019 at 22:08, Alexander Graf wrote: > > >> > > >> > > >> On 22.01.19 09:29, AKASHI Takahiro wrote: > > >>> Alex, Simon, > > >>> > > >>> Apologies for my slow response on this matter, > > >>> > > >>> On Fri, Jan 11, 2019 at 08:57:05AM +0100, Alexander Graf wrote: > > > > On 11.01.19 05:29, AKASHI Takahiro wrote: > > > Alex, Heinrich and Simon, > > > > > > Thank you for your comments, they are all valuable but also make > > > me > > > confused as different people have different requirements :) > > > I'm not sure that all of us share the same *ultimate* goal here. > > The shared ultimate goal is to "merge" (as Simon put it) dm and > > efi objects. > > >>> I don't still understand what "merge" means very well. > > >> It basically means that "struct efi_object" moves into "struct > > >> udevice". > > >> Every udevice instance of type UCLASS_BLK would expose the block and > > >> device_path protocols. > > >> > > >> This will be a slightly bigger rework, but eventually allows us to > > >> basically get rid of efi_init_obj_list() I think. > > > I envisaged something like: > > > > > > - EFI objects have their own UCLASS_EFI uclass > > > > ... and then we need to create our own sub object model around the > > UCLASS_EFI devices again. I' not convinced that's a great idea yet :). > > I > > really see little reason not to just expose every dm device as EFI > > handle. > > Things would plug in quite naturally I think. > > >>> > > >>> You said that the ultimate goal is to remove all efi_object data. > > >>> Do you think that all the existing efi_object can be mapped to > > >>> one of existing u-boot uclass devices? > > >>> > > >>> If so, what would be an real entity of a UEFI handle? > > >>> struct udevice *? > > >>> > > >>> But Simon seems not to agree to adding any UEFI-specific members > > >>> in struct udevice. > > >> > > >> I think we'll have to experiment with both approaches. I personally > > >> would like to have struct udevice * be the UEFI handle, yes. > > >> > > >>> > > But either way, someone would need to sit down and prototype things to > > be > > sure. > > > > >>> > > >>> The most simplest prototype would include > > >>> * event mechanism (just registration and execution of hook/handler) > > >>> event: udevice creation (and deletion) > > >>> * efi_disk hook for udevice(UCLASS_BLK) creation > > >>> * modified block device's enumeration code, say, scsi_scan(), > > >>> to add an event hook at udevice creation > > >>> * removing efi_disk_register() from efi_init_obj_list() > > >>> * Optionally(?) UCLASS_PARTITION > > >>> (Partition udevices would be created in part_init().) > > >> > > >> Almost. > > >> > > >> The simplest prototype would be to add a struct efi_object into struct > > >> udevice. Then whenever we're looping over efi_obj_list in the code, we > > >> additionally loop over all udevices to find the handle. > > > > > > Ah, yes. You're going further :) > > > > > >> Then, we could slowly give the uclasses explicit knowledge of uefi > > >> protocols. So most of the logic of efi_disk_register() would move into > > >> (or get called by) drivers/block/blk-uclass.c:blk_create_device(). > > > > > > Via event? Otherwise, we cannot decouple u-boot and UEFI world. > > > > For a prototype, just make it explicit and see how far that gets us. > > > > >> Instead of creating diskobj and adding calling efi_add_handle(), we > > >> could then just use existing data structure from the udevice (and its > > >> platdata). > > > > > > I don't have good confidence that we can remove struct efi_disk_obj, > > > at least, for the time being as some of its members are quite > > > UEFI-specific. > > > > Maybe we can move them into struct blk_desc? It's a matter of > > experimenting I guess. > > > > > > > >> > > >> Does this make sense? Less events, more implicity :). > > > > > > I'll go for it. > > > > Thanks a lot :). Feel free to pick an easier target for starters too if > > you prefer. > > Prototyping is done :) > Since it was so easy and simple, now I'm thinking of implementing > UCLASS_PARTITION. But it is not so straightforward as I expected, > and it won't bring us lots of advantages. > (I think that blk_desc should also support a partition in its own.) blk_desc is in UCLASS_BLK. So we alr
Re: [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote: > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini wrote: > > > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote: > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford wrote: > > > > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack wrote: > > > > > > > > > > Hello Adam, > > > > > > > > > > On 23.01.2019 22:13, Adam Ford wrote: > > > > > > By removing EXT support from SPL, it makes room for the extra > > > > > > overhead of enabling OF_CONTROL in SPL. With SPL_OF_CONTROL > > > > > > enabled, extra options need to be added to the device tree to > > > > > > tell it which portions of the tree are needed early in boot time > > > > > > > > > > > > Unfortunately, with these options as-is, the system doesn't boot > > > > > > nor does it display anything on the UART. I don't have a debugger > > > > > > readily available, but I have seen others with AM33x boards which > > > > > > are similar to OMAP3 boards. This is posted as an RFC just in case > > > > > > anyone has any suggestions on what might be missing. > > > > > > > > > > > On an AM335x board I had problems when moving from embedded to > > > > > separate > > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a > > > > > try. > > > > > If this works you could go back to CONFIG_OF_SEPARATE and probably > > > > > give > > > > > CONFIG_SPL_SEPARATE_BSS a try. > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did > > > > > help me quite a lot. > > > > > > > > I had to turn off DM_SERIAL temporarily to get some debugging going. > > > > I 'think' there is something wrong with fetching data from the device > > > > tree. > > > > > > > > I tried both OF_EMBDED and OF_SEPARATE without luck. SPL_SEPARATE_BSS > > > > is set. > > > > > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 > > > > -0600) > > > > Trying to boot from MMC1 > > > > uclass_find_device_by_seq: 0 0 > > > >- not found > > > > uclass_find_device_by_seq: 1 0 > > > >- not found > > > > spl: could not find mmc device 0. error: -19 > > > > SPL: failed to boot from all boot devices > > > > ### ERROR ### Please RESET the board ### > > > > > > > > I can see the mmc0 device is appearing in my SPL dtb file. > > > > > > > > I am not sure what these values are support to be, but I was able to > > > > do a dump of my spl device tree: > > > > > > > > dtc -I dtb -O dts spl/u-boot-spl.dtb > > > > > > Looking at Tom's defconfig file changes for the beagle, I noticed he > > > disabled Falcon mode. As soon as I disabled Falcon mode, I was able > > > to get my device tree based SPL to initialize both serial and MMC. > > > With Falcon mode enabled, it immediately stops booting and/or showing > > > anything. There seems to be some correlation, because disabling it > > > again make it work. > > > > > > With DM_SERIAL off, I can see the dumps to the screen and with the > > > debugging enabled, I can see that it is not able to locate the MMC > > > device. I am going to assume that if it cannot find the MMC device, > > > it probably cannot find the serial device which may explain why > > > disabling DM_SERIAL in SPL with Falcon mode on shows text. > > > > > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG > > > with Falcon working? I'd really like to keep that enabled by default. > > > > Note that I disabled Falcon for the space savings to keep MLO small > > enough, not that I noticed it failing to work. Given that with my > > patches what does work is loading an un-patched-for-DM-and-SPL u-boot > > and doesn't work is booting the u-boot.img I just built if there's not > > some overlap there. Perhaps the addresses being used for > > BSS/malloc/whatever are stomping on the image and that's wrecking > > things? > > > > Is there an easy way to debug memory utilization? We're not quite > getting to the point of loading u-boot.img since it cannot find the > MMC driver. > > Interestingly enough, when I rebased my quasi-working image with the > master, it died. I can still build DM_SPL without SPL_OF_CONTROL but > now even with Falcon disabled, any attempts to build with > SPL_OF_CONTROL fail. > I even tried using OF_PLATDATA hoping it might reduce the memory footprint. > > I'm going to go back to 2019.01 and run some tests, but any pointers > on how to debug memory allocation might be helpful. When I've had to do this before I've written them out, picked values that must fit the hardware and rest of the situation and confirmed or denied my hypothesis. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ihs_video_out: Fix error handling
On Mon, 28 Jan 2019 09:50:58 +0100 Mario Six mario@gdsys.cc wrote: > The ihs_video_out driver's error handling is incorrect in two places > (one is a missing negation, and in one place a error should be ignored). > > Fix these two instances. > > Signed-off-by: Mario Six > --- > drivers/video/ihs_video_out.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
On Mon, Jan 28, 2019 at 9:14 AM Tom Rini wrote: > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote: > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford wrote: > > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack wrote: > > > > > > > > Hello Adam, > > > > > > > > On 23.01.2019 22:13, Adam Ford wrote: > > > > > By removing EXT support from SPL, it makes room for the extra > > > > > overhead of enabling OF_CONTROL in SPL. With SPL_OF_CONTROL > > > > > enabled, extra options need to be added to the device tree to > > > > > tell it which portions of the tree are needed early in boot time > > > > > > > > > > Unfortunately, with these options as-is, the system doesn't boot > > > > > nor does it display anything on the UART. I don't have a debugger > > > > > readily available, but I have seen others with AM33x boards which > > > > > are similar to OMAP3 boards. This is posted as an RFC just in case > > > > > anyone has any suggestions on what might be missing. > > > > > > > > > On an AM335x board I had problems when moving from embedded to separate > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try. > > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give > > > > CONFIG_SPL_SEPARATE_BSS a try. > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did > > > > help me quite a lot. > > > > > > I had to turn off DM_SERIAL temporarily to get some debugging going. > > > I 'think' there is something wrong with fetching data from the device > > > tree. > > > > > > I tried both OF_EMBDED and OF_SEPARATE without luck. SPL_SEPARATE_BSS is > > > set. > > > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600) > > > Trying to boot from MMC1 > > > uclass_find_device_by_seq: 0 0 > > >- not found > > > uclass_find_device_by_seq: 1 0 > > >- not found > > > spl: could not find mmc device 0. error: -19 > > > SPL: failed to boot from all boot devices > > > ### ERROR ### Please RESET the board ### > > > > > > I can see the mmc0 device is appearing in my SPL dtb file. > > > > > > I am not sure what these values are support to be, but I was able to > > > do a dump of my spl device tree: > > > > > > dtc -I dtb -O dts spl/u-boot-spl.dtb > > > > Looking at Tom's defconfig file changes for the beagle, I noticed he > > disabled Falcon mode. As soon as I disabled Falcon mode, I was able > > to get my device tree based SPL to initialize both serial and MMC. > > With Falcon mode enabled, it immediately stops booting and/or showing > > anything. There seems to be some correlation, because disabling it > > again make it work. > > > > With DM_SERIAL off, I can see the dumps to the screen and with the > > debugging enabled, I can see that it is not able to locate the MMC > > device. I am going to assume that if it cannot find the MMC device, > > it probably cannot find the serial device which may explain why > > disabling DM_SERIAL in SPL with Falcon mode on shows text. > > > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG > > with Falcon working? I'd really like to keep that enabled by default. > > Note that I disabled Falcon for the space savings to keep MLO small > enough, not that I noticed it failing to work. Given that with my > patches what does work is loading an un-patched-for-DM-and-SPL u-boot > and doesn't work is booting the u-boot.img I just built if there's not > some overlap there. Perhaps the addresses being used for > BSS/malloc/whatever are stomping on the image and that's wrecking > things? > Is there an easy way to debug memory utilization? We're not quite getting to the point of loading u-boot.img since it cannot find the MMC driver. Interestingly enough, when I rebased my quasi-working image with the master, it died. I can still build DM_SPL without SPL_OF_CONTROL but now even with Falcon disabled, any attempts to build with SPL_OF_CONTROL fail. I even tried using OF_PLATDATA hoping it might reduce the memory footprint. I'm going to go back to 2019.01 and run some tests, but any pointers on how to debug memory allocation might be helpful. adam > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] videomodes: Relax EDID validation checks for hsync/vsync pulse width
On Thu, 17 Jan 2019 11:29:55 +0200 Priit Laes pl...@plaes.org wrote: ... > Signed-off-by: Priit Laes > --- > drivers/video/videomodes.c | 2 -- > 1 file changed, 2 deletions(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: video: Fix return value issue
On Fri, 4 Jan 2019 09:11:05 + Ye Li ye...@nxp.com wrote: > When framebuffer driver init is failed, we should return the err value not 0. > So the video init can exit immediately. > > Signed-off-by: Ye Li > --- > arch/arm/mach-imx/video.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 10/11] arm: meson64: enable console mux and console env by default
On Tue, 15 Jan 2019 17:17:58 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > From: Maxime Jourdan > > With the recent addition of the meson VPU driver, enable the following > config entries by default for meson-64 targets: CONFIG_CONSOLE_MUX, > CONFIG_SYS_CONSOLE_IS_IN_ENV. > > This allows outputting the console via video if CONFIG_VIDEO_MESON is > selected. > > Signed-off-by: Maxime Jourdan > Signed-off-by: Neil Armstrong Reviewed-by: Anatolij Gustschin -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 11/11] arm: libretech-cc: enable video by default
On Tue, 15 Jan 2019 17:17:59 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > From: Maxime Jourdan > > libretech-cc being the main device tested with CONFIG_VIDEO_MESON, let's > enable it by default. > > Also enable: > - CONFIG_SYS_WHITE_ON_BLACK for prettiness > - CONFIG_VIDEO_DT_SIMPLEFB for framebuffer sharing with kernel > > Signed-off-by: Maxime Jourdan > Signed-off-by: Neil Armstrong Reviewed-by: Anatolij Gustschin -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 09/11] configs: meson64: use vidconsole and usbkbd if enabled
On Tue, 15 Jan 2019 17:17:57 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > Allows displaying the console via video and using a USB keyboard. > > Also enables CONFIG_SPLASH_SCREEN if using video. > > Signed-off-by: Neil Armstrong > Signed-off-by: Maxime Jourdan Reviewed-by: Anatolij Gustschin -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
On 28.01.19 20:47, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:39, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:36, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
On 28.01.19 20:31, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:24, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
On 28.01.19 20:13, Simon Glass wrote:
> Hi,
>
> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
>>
>> Our selftest will soon test the actual runtime reset function rather
>> than
>> the boot time one. For this, we need to ensure that the runtime
>> version
>> actually succeeds on x86 to keep our travis tests work.
>>
>> So this patch implements an x86 runtime reset function. It is missing
>> shutdown functionality today, but OSs usually implement that via ACPI
>> and this function does more than the stub from before, so it's at
>> least
>> an improvement.
>>
>> Signed-off-by: Alexander Graf
>> ---
>> drivers/sysreset/sysreset_x86.c | 23 +++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/sysreset/sysreset_x86.c
>> b/drivers/sysreset/sysreset_x86.c
>> index 20b958cfd4..efed45ccb7 100644
>> --- a/drivers/sysreset/sysreset_x86.c
>> +++ b/drivers/sysreset/sysreset_x86.c
>> @@ -10,6 +10,29 @@
>> #include
>> #include
>> #include
>> +#include
>> +
>> +#ifdef CONFIG_EFI_LOADER
>> +void __efi_runtime EFIAPI efi_reset_system(
>> + enum efi_reset_type reset_type,
>> + efi_status_t reset_status,
>> + unsigned long data_size, void *reset_data)
>> +{
>> + u32 value = 0;
>> +
>> + if (reset_type == EFI_RESET_COLD)
>> + value = SYS_RST | RST_CPU | FULL_RST;
>> + else if (reset_type == EFI_RESET_WARM)
>> + value = SYS_RST | RST_CPU;
>
> The EFI should use the sysreset driver and sysreset_walk() or similar,
> rather than having a function called directly.
It can't. At this point all of DM is long gone. We're in runtime space
here.
>>>
>>> This has come up before. We'll end up with a lot of duplication if we
>>> cannot solve this. I think the run-time code will need to be built and
>>> linked separately so that all necessary code is pulled in.
>>
>> It's mostly a question of size. We can even transform all of U-Boot into
>> huge runtime services if we keep the relocation tables around and apply
>> relocations manually for everything.
>>
>> The problem is that if we do that, we'll become even bigger than we are
>> now, no?
>
> I did a change to build U-Boot as a library, perhaps it could build on
> that. The 'run-time U-Boot' won't be any bigger than the code that is
> actually used. Also I don't think memory usage is a concern in systems
> that use UEFI :-)
It is, we're already exploding some constraints today. Furthermore, by
moving all of U-Boot into RTS you obviously waste a few MB of RAM while
Linux is up. And it's much harder to review that the code is only doing
what you want it to do.
>>>
>>> My suggest is not to move all of U-Boot into RTS. It is to build an
>>> RTS version of U-Boot with just those things that are needed, a bit
>>> like TPL or SPL.
>>
>> Yes, but the "loaded binary" to boot the system is then BTS + RTS. So if
>> U-Boot is 1MB and the RTS U-Boot build is 0.5MB, you need to store and
>> load 1.5MB from SD card or SPI or wherever your U-Boot is stored.
>
> Yes that's right. Although I suspect it is only about half that. E.g.
> Raspberry Pi 2 is 431KB. I'd hope that RTS would be very small?
>
>>
>>
>> By morphing all of U-Boot over, the runtime cost is higher (1MB rather
>> than 0.5MB used while Linux is up), but the boot time cost is smaller
>> (only 1MB on storage).
>>
>>> I did not invent the run-time aspect of EFI, but I feel we are trying
>>> to support it with a hack.
>>
>> Well, it is a hack in edk2 as well. RTS are a terrible idea in my book.
>> But they're there and we need to support at least reset/shutdown and
>> *maybe* some sort of runtime variables.
>
> Yes, but at some point this all becomes unmanageable. I think we
> should adjust the approach now.
So how would we transfer device information from one piece to the next?
How would we ensure that we don't reinitialize everything?
Adding anot
Re: [U-Boot] [PATCH u-boot 08/11] arm: meson: board-gx: Setup VPU in fdt
On Tue, 15 Jan 2019 17:17:56 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > From: Maxime Jourdan > > If VIDEO_MESON is enabled, we need to setup the fdt for the framebuffer. > > Call meson_vpu_rsv_fb() which reserves the framebuffer memory region for > EFI, and sets up simple-framebuffer nodes if simplefb support is > enabled. > > Signed-off-by: Maxime Jourdan > Signed-off-by: Neil Armstrong Reviewed-by: Anatolij Gustschin -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 01/11] power: domain: meson-gx-pwrc-vpu: add missing depends
On Tue, 15 Jan 2019 17:17:49 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > From: Maxime Jourdan > > MESON_GX_VPU_POWER_DOMAIN should depend on POWER_DOMAIN. > > Signed-off-by: Maxime Jourdan > Signed-off-by: Neil Armstrong Reviewed-by: Anatolij Gustschin -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 04/11] video: Add Meson Video Processing Unit Driver
On Tue, 15 Jan 2019 17:17:52 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > This adds video output support for Amlogic GXBB/GXL/GXM chips. > The supported ports are CVBS and HDMI (based on DW_HDMI). > > When using HDMI, only DMT modes are supported. > > There is support for simple-framebuffer (CONFIG_VIDEO_DT_SIMPLEFB) > > Signed-off-by: Neil Armstrong > Signed-off-by: Jorge Ramire-Ortiz > Signed-off-by: Maxime Jourdan Reviewed-by: Anatolij Gustschin Please see minor comment below. > diff --git a/drivers/video/meson/meson_canvas.c > b/drivers/video/meson/meson_canvas.c ... > +/* DMC Registers */ > +#define DMC_CAV_LUT_DATAL0x48 /* 0x12 offset in data sheet */ > +#define CANVAS_WIDTH_LBIT29 > +#define CANVAS_WIDTH_LWID 3 > +#define DMC_CAV_LUT_DATAH0x4c /* 0x13 offset in data sheet */ > +#define CANVAS_WIDTH_HBIT 0 > +#define CANVAS_HEIGHT_BIT 9 > +#define CANVAS_BLKMODE_BIT 24 > +#define DMC_CAV_LUT_ADDR 0x50 /* 0x14 offset in data sheet */ > +#define CANVAS_LUT_WR_EN(0x2 << 8) > +#define CANVAS_LUT_RD_EN(0x1 << 8) Some define values are not aligned by tab here. -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
Hi Alex,
On Mon, 28 Jan 2019 at 12:39, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:36, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:31, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:24, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:13, Simon Glass wrote:
> >>> Hi,
> >>>
> >>> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
>
> Our selftest will soon test the actual runtime reset function rather
> than
> the boot time one. For this, we need to ensure that the runtime
> version
> actually succeeds on x86 to keep our travis tests work.
>
> So this patch implements an x86 runtime reset function. It is missing
> shutdown functionality today, but OSs usually implement that via ACPI
> and this function does more than the stub from before, so it's at
> least
> an improvement.
>
> Signed-off-by: Alexander Graf
> ---
> drivers/sysreset/sysreset_x86.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/sysreset/sysreset_x86.c
> b/drivers/sysreset/sysreset_x86.c
> index 20b958cfd4..efed45ccb7 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -10,6 +10,29 @@
> #include
> #include
> #include
> +#include
> +
> +#ifdef CONFIG_EFI_LOADER
> +void __efi_runtime EFIAPI efi_reset_system(
> + enum efi_reset_type reset_type,
> + efi_status_t reset_status,
> + unsigned long data_size, void *reset_data)
> +{
> + u32 value = 0;
> +
> + if (reset_type == EFI_RESET_COLD)
> + value = SYS_RST | RST_CPU | FULL_RST;
> + else if (reset_type == EFI_RESET_WARM)
> + value = SYS_RST | RST_CPU;
> >>>
> >>> The EFI should use the sysreset driver and sysreset_walk() or similar,
> >>> rather than having a function called directly.
> >>
> >> It can't. At this point all of DM is long gone. We're in runtime space
> >> here.
> >
> > This has come up before. We'll end up with a lot of duplication if we
> > cannot solve this. I think the run-time code will need to be built and
> > linked separately so that all necessary code is pulled in.
>
> It's mostly a question of size. We can even transform all of U-Boot into
> huge runtime services if we keep the relocation tables around and apply
> relocations manually for everything.
>
> The problem is that if we do that, we'll become even bigger than we are
> now, no?
> >>>
> >>> I did a change to build U-Boot as a library, perhaps it could build on
> >>> that. The 'run-time U-Boot' won't be any bigger than the code that is
> >>> actually used. Also I don't think memory usage is a concern in systems
> >>> that use UEFI :-)
> >>
> >> It is, we're already exploding some constraints today. Furthermore, by
> >> moving all of U-Boot into RTS you obviously waste a few MB of RAM while
> >> Linux is up. And it's much harder to review that the code is only doing
> >> what you want it to do.
> >
> > My suggest is not to move all of U-Boot into RTS. It is to build an
> > RTS version of U-Boot with just those things that are needed, a bit
> > like TPL or SPL.
>
> Yes, but the "loaded binary" to boot the system is then BTS + RTS. So if
> U-Boot is 1MB and the RTS U-Boot build is 0.5MB, you need to store and
> load 1.5MB from SD card or SPI or wherever your U-Boot is stored.
Yes that's right. Although I suspect it is only about half that. E.g.
Raspberry Pi 2 is 431KB. I'd hope that RTS would be very small?
>
>
> By morphing all of U-Boot over, the runtime cost is higher (1MB rather
> than 0.5MB used while Linux is up), but the boot time cost is smaller
> (only 1MB on storage).
>
> > I did not invent the run-time aspect of EFI, but I feel we are trying
> > to support it with a hack.
>
> Well, it is a hack in edk2 as well. RTS are a terrible idea in my book.
> But they're there and we need to support at least reset/shutdown and
> *maybe* some sort of runtime variables.
Yes, but at some point this all becomes unmanageable. I think we
should adjust the approach now.
>
>
> >>> The problem with the current approach is that everything becomes
> >>> parallel to DM, duplicating existing code, and that is complicated
> >>> too.
> >>
> >> No, not everything. Only reset/shutdown. Well, and m
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
On 28.01.19 20:36, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:31, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
On 28.01.19 20:24, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:13, Simon Glass wrote:
>>> Hi,
>>>
>>> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
Our selftest will soon test the actual runtime reset function rather
than
the boot time one. For this, we need to ensure that the runtime version
actually succeeds on x86 to keep our travis tests work.
So this patch implements an x86 runtime reset function. It is missing
shutdown functionality today, but OSs usually implement that via ACPI
and this function does more than the stub from before, so it's at least
an improvement.
Signed-off-by: Alexander Graf
---
drivers/sysreset/sysreset_x86.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/sysreset/sysreset_x86.c
b/drivers/sysreset/sysreset_x86.c
index 20b958cfd4..efed45ccb7 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -10,6 +10,29 @@
#include
#include
#include
+#include
+
+#ifdef CONFIG_EFI_LOADER
+void __efi_runtime EFIAPI efi_reset_system(
+ enum efi_reset_type reset_type,
+ efi_status_t reset_status,
+ unsigned long data_size, void *reset_data)
+{
+ u32 value = 0;
+
+ if (reset_type == EFI_RESET_COLD)
+ value = SYS_RST | RST_CPU | FULL_RST;
+ else if (reset_type == EFI_RESET_WARM)
+ value = SYS_RST | RST_CPU;
>>>
>>> The EFI should use the sysreset driver and sysreset_walk() or similar,
>>> rather than having a function called directly.
>>
>> It can't. At this point all of DM is long gone. We're in runtime space
>> here.
>
> This has come up before. We'll end up with a lot of duplication if we
> cannot solve this. I think the run-time code will need to be built and
> linked separately so that all necessary code is pulled in.
It's mostly a question of size. We can even transform all of U-Boot into
huge runtime services if we keep the relocation tables around and apply
relocations manually for everything.
The problem is that if we do that, we'll become even bigger than we are
now, no?
>>>
>>> I did a change to build U-Boot as a library, perhaps it could build on
>>> that. The 'run-time U-Boot' won't be any bigger than the code that is
>>> actually used. Also I don't think memory usage is a concern in systems
>>> that use UEFI :-)
>>
>> It is, we're already exploding some constraints today. Furthermore, by
>> moving all of U-Boot into RTS you obviously waste a few MB of RAM while
>> Linux is up. And it's much harder to review that the code is only doing
>> what you want it to do.
>
> My suggest is not to move all of U-Boot into RTS. It is to build an
> RTS version of U-Boot with just those things that are needed, a bit
> like TPL or SPL.
Yes, but the "loaded binary" to boot the system is then BTS + RTS. So if
U-Boot is 1MB and the RTS U-Boot build is 0.5MB, you need to store and
load 1.5MB from SD card or SPI or wherever your U-Boot is stored.
By morphing all of U-Boot over, the runtime cost is higher (1MB rather
than 0.5MB used while Linux is up), but the boot time cost is smaller
(only 1MB on storage).
> I did not invent the run-time aspect of EFI, but I feel we are trying
> to support it with a hack.
Well, it is a hack in edk2 as well. RTS are a terrible idea in my book.
But they're there and we need to support at least reset/shutdown and
*maybe* some sort of runtime variables.
>>> The problem with the current approach is that everything becomes
>>> parallel to DM, duplicating existing code, and that is complicated
>>> too.
>>
>> No, not everything. Only reset/shutdown. Well, and maybe variable
>> services. Which may use SPI. Meh.
>
> That should be a fairly small build, then.
It still adds to the binary size.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
Hi Alex,
On Mon, 28 Jan 2019 at 12:34, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:31, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:24, Simon Glass wrote:
> >>> Hi Alex,
> >>>
> >>> On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:13, Simon Glass wrote:
> > Hi,
> >
> > On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
> >>
> >> Our selftest will soon test the actual runtime reset function rather
> >> than
> >> the boot time one. For this, we need to ensure that the runtime version
> >> actually succeeds on x86 to keep our travis tests work.
> >>
> >> So this patch implements an x86 runtime reset function. It is missing
> >> shutdown functionality today, but OSs usually implement that via ACPI
> >> and this function does more than the stub from before, so it's at least
> >> an improvement.
> >>
> >> Signed-off-by: Alexander Graf
> >> ---
> >> drivers/sysreset/sysreset_x86.c | 23 +++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/sysreset/sysreset_x86.c
> >> b/drivers/sysreset/sysreset_x86.c
> >> index 20b958cfd4..efed45ccb7 100644
> >> --- a/drivers/sysreset/sysreset_x86.c
> >> +++ b/drivers/sysreset/sysreset_x86.c
> >> @@ -10,6 +10,29 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> +
> >> +#ifdef CONFIG_EFI_LOADER
> >> +void __efi_runtime EFIAPI efi_reset_system(
> >> + enum efi_reset_type reset_type,
> >> + efi_status_t reset_status,
> >> + unsigned long data_size, void *reset_data)
> >> +{
> >> + u32 value = 0;
> >> +
> >> + if (reset_type == EFI_RESET_COLD)
> >> + value = SYS_RST | RST_CPU | FULL_RST;
> >> + else if (reset_type == EFI_RESET_WARM)
> >> + value = SYS_RST | RST_CPU;
> >
> > The EFI should use the sysreset driver and sysreset_walk() or similar,
> > rather than having a function called directly.
>
> It can't. At this point all of DM is long gone. We're in runtime space
> here.
> >>>
> >>> This has come up before. We'll end up with a lot of duplication if we
> >>> cannot solve this. I think the run-time code will need to be built and
> >>> linked separately so that all necessary code is pulled in.
> >>
> >> It's mostly a question of size. We can even transform all of U-Boot into
> >> huge runtime services if we keep the relocation tables around and apply
> >> relocations manually for everything.
> >>
> >> The problem is that if we do that, we'll become even bigger than we are
> >> now, no?
> >
> > I did a change to build U-Boot as a library, perhaps it could build on
> > that. The 'run-time U-Boot' won't be any bigger than the code that is
> > actually used. Also I don't think memory usage is a concern in systems
> > that use UEFI :-)
>
> It is, we're already exploding some constraints today. Furthermore, by
> moving all of U-Boot into RTS you obviously waste a few MB of RAM while
> Linux is up. And it's much harder to review that the code is only doing
> what you want it to do.
My suggest is not to move all of U-Boot into RTS. It is to build an
RTS version of U-Boot with just those things that are needed, a bit
like TPL or SPL.
I did not invent the run-time aspect of EFI, but I feel we are trying
to support it with a hack.
>
> > The problem with the current approach is that everything becomes
> > parallel to DM, duplicating existing code, and that is complicated
> > too.
>
> No, not everything. Only reset/shutdown. Well, and maybe variable
> services. Which may use SPI. Meh.
That should be a fairly small build, then.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
On 28.01.19 20:31, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:24, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
On 28.01.19 20:13, Simon Glass wrote:
> Hi,
>
> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
>>
>> Our selftest will soon test the actual runtime reset function rather than
>> the boot time one. For this, we need to ensure that the runtime version
>> actually succeeds on x86 to keep our travis tests work.
>>
>> So this patch implements an x86 runtime reset function. It is missing
>> shutdown functionality today, but OSs usually implement that via ACPI
>> and this function does more than the stub from before, so it's at least
>> an improvement.
>>
>> Signed-off-by: Alexander Graf
>> ---
>> drivers/sysreset/sysreset_x86.c | 23 +++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/sysreset/sysreset_x86.c
>> b/drivers/sysreset/sysreset_x86.c
>> index 20b958cfd4..efed45ccb7 100644
>> --- a/drivers/sysreset/sysreset_x86.c
>> +++ b/drivers/sysreset/sysreset_x86.c
>> @@ -10,6 +10,29 @@
>> #include
>> #include
>> #include
>> +#include
>> +
>> +#ifdef CONFIG_EFI_LOADER
>> +void __efi_runtime EFIAPI efi_reset_system(
>> + enum efi_reset_type reset_type,
>> + efi_status_t reset_status,
>> + unsigned long data_size, void *reset_data)
>> +{
>> + u32 value = 0;
>> +
>> + if (reset_type == EFI_RESET_COLD)
>> + value = SYS_RST | RST_CPU | FULL_RST;
>> + else if (reset_type == EFI_RESET_WARM)
>> + value = SYS_RST | RST_CPU;
>
> The EFI should use the sysreset driver and sysreset_walk() or similar,
> rather than having a function called directly.
It can't. At this point all of DM is long gone. We're in runtime space
here.
>>>
>>> This has come up before. We'll end up with a lot of duplication if we
>>> cannot solve this. I think the run-time code will need to be built and
>>> linked separately so that all necessary code is pulled in.
>>
>> It's mostly a question of size. We can even transform all of U-Boot into
>> huge runtime services if we keep the relocation tables around and apply
>> relocations manually for everything.
>>
>> The problem is that if we do that, we'll become even bigger than we are
>> now, no?
>
> I did a change to build U-Boot as a library, perhaps it could build on
> that. The 'run-time U-Boot' won't be any bigger than the code that is
> actually used. Also I don't think memory usage is a concern in systems
> that use UEFI :-)
It is, we're already exploding some constraints today. Furthermore, by
moving all of U-Boot into RTS you obviously waste a few MB of RAM while
Linux is up. And it's much harder to review that the code is only doing
what you want it to do.
> The problem with the current approach is that everything becomes
> parallel to DM, duplicating existing code, and that is complicated
> too.
No, not everything. Only reset/shutdown. Well, and maybe variable
services. Which may use SPI. Meh.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
Hi Alex,
On Mon, 28 Jan 2019 at 12:27, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:24, Simon Glass wrote:
> > Hi Alex,
> >
> > On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
> >>
> >>
> >>
> >> On 28.01.19 20:13, Simon Glass wrote:
> >>> Hi,
> >>>
> >>> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
>
> Our selftest will soon test the actual runtime reset function rather than
> the boot time one. For this, we need to ensure that the runtime version
> actually succeeds on x86 to keep our travis tests work.
>
> So this patch implements an x86 runtime reset function. It is missing
> shutdown functionality today, but OSs usually implement that via ACPI
> and this function does more than the stub from before, so it's at least
> an improvement.
>
> Signed-off-by: Alexander Graf
> ---
> drivers/sysreset/sysreset_x86.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/sysreset/sysreset_x86.c
> b/drivers/sysreset/sysreset_x86.c
> index 20b958cfd4..efed45ccb7 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -10,6 +10,29 @@
> #include
> #include
> #include
> +#include
> +
> +#ifdef CONFIG_EFI_LOADER
> +void __efi_runtime EFIAPI efi_reset_system(
> + enum efi_reset_type reset_type,
> + efi_status_t reset_status,
> + unsigned long data_size, void *reset_data)
> +{
> + u32 value = 0;
> +
> + if (reset_type == EFI_RESET_COLD)
> + value = SYS_RST | RST_CPU | FULL_RST;
> + else if (reset_type == EFI_RESET_WARM)
> + value = SYS_RST | RST_CPU;
> >>>
> >>> The EFI should use the sysreset driver and sysreset_walk() or similar,
> >>> rather than having a function called directly.
> >>
> >> It can't. At this point all of DM is long gone. We're in runtime space
> >> here.
> >
> > This has come up before. We'll end up with a lot of duplication if we
> > cannot solve this. I think the run-time code will need to be built and
> > linked separately so that all necessary code is pulled in.
>
> It's mostly a question of size. We can even transform all of U-Boot into
> huge runtime services if we keep the relocation tables around and apply
> relocations manually for everything.
>
> The problem is that if we do that, we'll become even bigger than we are
> now, no?
I did a change to build U-Boot as a library, perhaps it could build on
that. The 'run-time U-Boot' won't be any bigger than the code that is
actually used. Also I don't think memory usage is a concern in systems
that use UEFI :-)
The problem with the current approach is that everything becomes
parallel to DM, duplicating existing code, and that is complicated
too.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
On 28.01.19 20:24, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
>>
>>
>>
>> On 28.01.19 20:13, Simon Glass wrote:
>>> Hi,
>>>
>>> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
Our selftest will soon test the actual runtime reset function rather than
the boot time one. For this, we need to ensure that the runtime version
actually succeeds on x86 to keep our travis tests work.
So this patch implements an x86 runtime reset function. It is missing
shutdown functionality today, but OSs usually implement that via ACPI
and this function does more than the stub from before, so it's at least
an improvement.
Signed-off-by: Alexander Graf
---
drivers/sysreset/sysreset_x86.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/sysreset/sysreset_x86.c
b/drivers/sysreset/sysreset_x86.c
index 20b958cfd4..efed45ccb7 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -10,6 +10,29 @@
#include
#include
#include
+#include
+
+#ifdef CONFIG_EFI_LOADER
+void __efi_runtime EFIAPI efi_reset_system(
+ enum efi_reset_type reset_type,
+ efi_status_t reset_status,
+ unsigned long data_size, void *reset_data)
+{
+ u32 value = 0;
+
+ if (reset_type == EFI_RESET_COLD)
+ value = SYS_RST | RST_CPU | FULL_RST;
+ else if (reset_type == EFI_RESET_WARM)
+ value = SYS_RST | RST_CPU;
>>>
>>> The EFI should use the sysreset driver and sysreset_walk() or similar,
>>> rather than having a function called directly.
>>
>> It can't. At this point all of DM is long gone. We're in runtime space here.
>
> This has come up before. We'll end up with a lot of duplication if we
> cannot solve this. I think the run-time code will need to be built and
> linked separately so that all necessary code is pulled in.
It's mostly a question of size. We can even transform all of U-Boot into
huge runtime services if we keep the relocation tables around and apply
relocations manually for everything.
The problem is that if we do that, we'll become even bigger than we are
now, no?
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] arm: socfpga: move SDR reset handling to driver
On 1/28/19 8:17 PM, Simon Goldschmidt wrote: > Am 28.01.2019 um 20:02 schrieb Marek Vasut: >> On 1/28/19 1:38 PM, Simon Goldschmidt wrote: >>> On Mon, Jan 28, 2019 at 12:59 PM Marek Vasut wrote: On 1/28/19 12:49 PM, Simon Goldschmidt wrote: > On Mon, Jan 28, 2019 at 12:30 PM Marek Vasut wrote: >> >> On 1/27/19 9:47 AM, Simon Goldschmidt wrote: >>> Am 26.01.2019 um 09:58 schrieb Marek Vasut: On 1/25/19 9:30 PM, Simon Goldschmidt wrote: > To clean up reset handling for socfpga gen5, let's move the > code snippet > taking the DDR controller out of reset from SPL to the DDR driver. > > Signed-off-by: Simon Goldschmidt > --- > > arch/arm/mach-socfpga/spl_gen5.c | 1 - > drivers/ddr/altera/sdram_gen5.c | 4 > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-socfpga/spl_gen5.c > b/arch/arm/mach-socfpga/spl_gen5.c > index ccdc661d05..f9bea892b1 100644 > --- a/arch/arm/mach-socfpga/spl_gen5.c > +++ b/arch/arm/mach-socfpga/spl_gen5.c > @@ -98,7 +98,6 @@ void board_init_f(ulong dummy) > socfpga_bridges_reset(1); > } > - socfpga_per_reset(SOCFPGA_RESET(SDR), 0); > socfpga_per_reset(SOCFPGA_RESET(UART0), 0); > socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0); > diff --git a/drivers/ddr/altera/sdram_gen5.c > b/drivers/ddr/altera/sdram_gen5.c > index 821060459c..bd54c420f8 100644 > --- a/drivers/ddr/altera/sdram_gen5.c > +++ b/drivers/ddr/altera/sdram_gen5.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -434,6 +435,9 @@ int sdram_mmr_init_full(unsigned int > sdr_phy_reg) > SDR_CTRLGRP_DRAMADDRW_ROWBITS_LSB; > int ret; > + /* release DDR from reset */ > + socfpga_per_reset(SOCFPGA_RESET(SDR), 0); > + Can the reset framework do this ? >>> >>> Hmm, it probably could, but I see that as a diferent patch. The >>> altera >>> DDR driver currently does not work with devicetree, so using the >>> reset >>> framework here would be a bigger patch, I think. >>> >>> Can we do that later and clean up this by just moving the code? >> >> How much effort is it to switch this driver over to DM ? > > I really don't know. Searching through drivers/ddr does not seem to > give me > an example of a DTS-enabled ddr driver. Given that, I'd rather just > push this > patch now. While it's true that it doesn't clean up everything, it's > not as if it > would make things worse. That's a valid point. I guess you can add DRAM uclass and just probe the driver, which should be all that's needed. >>> >>> Hmm, there *is* a UCLASS_RAM, but its drivers are in 'drivers/ram'. >>> Is there >>> any reason those are separated from 'drivers/ddr'? >> >> I don't think so, seems like these two directories should be merged. > > Yes, I think so too by now. > > I'll see if I can change this patch to use UCLASS_RAM. A patch/series to > merge drivers/ddr wih drivers/ram should be separate. Sounds good. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
Hi Alex,
On Mon, 28 Jan 2019 at 12:15, Alexander Graf wrote:
>
>
>
> On 28.01.19 20:13, Simon Glass wrote:
> > Hi,
> >
> > On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
> >>
> >> Our selftest will soon test the actual runtime reset function rather than
> >> the boot time one. For this, we need to ensure that the runtime version
> >> actually succeeds on x86 to keep our travis tests work.
> >>
> >> So this patch implements an x86 runtime reset function. It is missing
> >> shutdown functionality today, but OSs usually implement that via ACPI
> >> and this function does more than the stub from before, so it's at least
> >> an improvement.
> >>
> >> Signed-off-by: Alexander Graf
> >> ---
> >> drivers/sysreset/sysreset_x86.c | 23 +++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/sysreset/sysreset_x86.c
> >> b/drivers/sysreset/sysreset_x86.c
> >> index 20b958cfd4..efed45ccb7 100644
> >> --- a/drivers/sysreset/sysreset_x86.c
> >> +++ b/drivers/sysreset/sysreset_x86.c
> >> @@ -10,6 +10,29 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> +
> >> +#ifdef CONFIG_EFI_LOADER
> >> +void __efi_runtime EFIAPI efi_reset_system(
> >> + enum efi_reset_type reset_type,
> >> + efi_status_t reset_status,
> >> + unsigned long data_size, void *reset_data)
> >> +{
> >> + u32 value = 0;
> >> +
> >> + if (reset_type == EFI_RESET_COLD)
> >> + value = SYS_RST | RST_CPU | FULL_RST;
> >> + else if (reset_type == EFI_RESET_WARM)
> >> + value = SYS_RST | RST_CPU;
> >
> > The EFI should use the sysreset driver and sysreset_walk() or similar,
> > rather than having a function called directly.
>
> It can't. At this point all of DM is long gone. We're in runtime space here.
This has come up before. We'll end up with a lot of duplication if we
cannot solve this. I think the run-time code will need to be built and
linked separately so that all necessary code is pulled in.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] arm: socfpga: move SDR reset handling to driver
Am 28.01.2019 um 20:02 schrieb Marek Vasut: On 1/28/19 1:38 PM, Simon Goldschmidt wrote: On Mon, Jan 28, 2019 at 12:59 PM Marek Vasut wrote: On 1/28/19 12:49 PM, Simon Goldschmidt wrote: On Mon, Jan 28, 2019 at 12:30 PM Marek Vasut wrote: On 1/27/19 9:47 AM, Simon Goldschmidt wrote: Am 26.01.2019 um 09:58 schrieb Marek Vasut: On 1/25/19 9:30 PM, Simon Goldschmidt wrote: To clean up reset handling for socfpga gen5, let's move the code snippet taking the DDR controller out of reset from SPL to the DDR driver. Signed-off-by: Simon Goldschmidt --- arch/arm/mach-socfpga/spl_gen5.c | 1 - drivers/ddr/altera/sdram_gen5.c | 4 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c index ccdc661d05..f9bea892b1 100644 --- a/arch/arm/mach-socfpga/spl_gen5.c +++ b/arch/arm/mach-socfpga/spl_gen5.c @@ -98,7 +98,6 @@ void board_init_f(ulong dummy) socfpga_bridges_reset(1); } -socfpga_per_reset(SOCFPGA_RESET(SDR), 0); socfpga_per_reset(SOCFPGA_RESET(UART0), 0); socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0); diff --git a/drivers/ddr/altera/sdram_gen5.c b/drivers/ddr/altera/sdram_gen5.c index 821060459c..bd54c420f8 100644 --- a/drivers/ddr/altera/sdram_gen5.c +++ b/drivers/ddr/altera/sdram_gen5.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -434,6 +435,9 @@ int sdram_mmr_init_full(unsigned int sdr_phy_reg) SDR_CTRLGRP_DRAMADDRW_ROWBITS_LSB; int ret; +/* release DDR from reset */ +socfpga_per_reset(SOCFPGA_RESET(SDR), 0); + Can the reset framework do this ? Hmm, it probably could, but I see that as a diferent patch. The altera DDR driver currently does not work with devicetree, so using the reset framework here would be a bigger patch, I think. Can we do that later and clean up this by just moving the code? How much effort is it to switch this driver over to DM ? I really don't know. Searching through drivers/ddr does not seem to give me an example of a DTS-enabled ddr driver. Given that, I'd rather just push this patch now. While it's true that it doesn't clean up everything, it's not as if it would make things worse. That's a valid point. I guess you can add DRAM uclass and just probe the driver, which should be all that's needed. Hmm, there *is* a UCLASS_RAM, but its drivers are in 'drivers/ram'. Is there any reason those are separated from 'drivers/ddr'? I don't think so, seems like these two directories should be merged. Yes, I think so too by now. I'll see if I can change this patch to use UCLASS_RAM. A patch/series to merge drivers/ddr wih drivers/ram should be separate. Regads, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
On 28.01.19 20:13, Simon Glass wrote:
> Hi,
>
> On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
>>
>> Our selftest will soon test the actual runtime reset function rather than
>> the boot time one. For this, we need to ensure that the runtime version
>> actually succeeds on x86 to keep our travis tests work.
>>
>> So this patch implements an x86 runtime reset function. It is missing
>> shutdown functionality today, but OSs usually implement that via ACPI
>> and this function does more than the stub from before, so it's at least
>> an improvement.
>>
>> Signed-off-by: Alexander Graf
>> ---
>> drivers/sysreset/sysreset_x86.c | 23 +++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/sysreset/sysreset_x86.c
>> b/drivers/sysreset/sysreset_x86.c
>> index 20b958cfd4..efed45ccb7 100644
>> --- a/drivers/sysreset/sysreset_x86.c
>> +++ b/drivers/sysreset/sysreset_x86.c
>> @@ -10,6 +10,29 @@
>> #include
>> #include
>> #include
>> +#include
>> +
>> +#ifdef CONFIG_EFI_LOADER
>> +void __efi_runtime EFIAPI efi_reset_system(
>> + enum efi_reset_type reset_type,
>> + efi_status_t reset_status,
>> + unsigned long data_size, void *reset_data)
>> +{
>> + u32 value = 0;
>> +
>> + if (reset_type == EFI_RESET_COLD)
>> + value = SYS_RST | RST_CPU | FULL_RST;
>> + else if (reset_type == EFI_RESET_WARM)
>> + value = SYS_RST | RST_CPU;
>
> The EFI should use the sysreset driver and sysreset_walk() or similar,
> rather than having a function called directly.
It can't. At this point all of DM is long gone. We're in runtime space here.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] arm: socfpga: move SDR reset handling to driver
On 1/28/19 1:38 PM, Simon Goldschmidt wrote: > On Mon, Jan 28, 2019 at 12:59 PM Marek Vasut wrote: >> >> On 1/28/19 12:49 PM, Simon Goldschmidt wrote: >>> On Mon, Jan 28, 2019 at 12:30 PM Marek Vasut wrote: On 1/27/19 9:47 AM, Simon Goldschmidt wrote: > Am 26.01.2019 um 09:58 schrieb Marek Vasut: >> On 1/25/19 9:30 PM, Simon Goldschmidt wrote: >>> To clean up reset handling for socfpga gen5, let's move the code snippet >>> taking the DDR controller out of reset from SPL to the DDR driver. >>> >>> Signed-off-by: Simon Goldschmidt >>> --- >>> >>> arch/arm/mach-socfpga/spl_gen5.c | 1 - >>> drivers/ddr/altera/sdram_gen5.c | 4 >>> 2 files changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/arm/mach-socfpga/spl_gen5.c >>> b/arch/arm/mach-socfpga/spl_gen5.c >>> index ccdc661d05..f9bea892b1 100644 >>> --- a/arch/arm/mach-socfpga/spl_gen5.c >>> +++ b/arch/arm/mach-socfpga/spl_gen5.c >>> @@ -98,7 +98,6 @@ void board_init_f(ulong dummy) >>> socfpga_bridges_reset(1); >>> } >>> -socfpga_per_reset(SOCFPGA_RESET(SDR), 0); >>> socfpga_per_reset(SOCFPGA_RESET(UART0), 0); >>> socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0); >>> diff --git a/drivers/ddr/altera/sdram_gen5.c >>> b/drivers/ddr/altera/sdram_gen5.c >>> index 821060459c..bd54c420f8 100644 >>> --- a/drivers/ddr/altera/sdram_gen5.c >>> +++ b/drivers/ddr/altera/sdram_gen5.c >>> @@ -7,6 +7,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -434,6 +435,9 @@ int sdram_mmr_init_full(unsigned int sdr_phy_reg) >>> SDR_CTRLGRP_DRAMADDRW_ROWBITS_LSB; >>> int ret; >>> +/* release DDR from reset */ >>> +socfpga_per_reset(SOCFPGA_RESET(SDR), 0); >>> + >> >> Can the reset framework do this ? > > Hmm, it probably could, but I see that as a diferent patch. The altera > DDR driver currently does not work with devicetree, so using the reset > framework here would be a bigger patch, I think. > > Can we do that later and clean up this by just moving the code? How much effort is it to switch this driver over to DM ? >>> >>> I really don't know. Searching through drivers/ddr does not seem to give me >>> an example of a DTS-enabled ddr driver. Given that, I'd rather just push >>> this >>> patch now. While it's true that it doesn't clean up everything, it's >>> not as if it >>> would make things worse. >> >> That's a valid point. >> >> I guess you can add DRAM uclass and just probe the driver, which should >> be all that's needed. > > Hmm, there *is* a UCLASS_RAM, but its drivers are in 'drivers/ram'. Is there > any reason those are separated from 'drivers/ddr'? I don't think so, seems like these two directories should be merged. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
Hi,
On Mon, 28 Jan 2019 at 08:42, Alexander Graf wrote:
>
> Our selftest will soon test the actual runtime reset function rather than
> the boot time one. For this, we need to ensure that the runtime version
> actually succeeds on x86 to keep our travis tests work.
>
> So this patch implements an x86 runtime reset function. It is missing
> shutdown functionality today, but OSs usually implement that via ACPI
> and this function does more than the stub from before, so it's at least
> an improvement.
>
> Signed-off-by: Alexander Graf
> ---
> drivers/sysreset/sysreset_x86.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> index 20b958cfd4..efed45ccb7 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -10,6 +10,29 @@
> #include
> #include
> #include
> +#include
> +
> +#ifdef CONFIG_EFI_LOADER
> +void __efi_runtime EFIAPI efi_reset_system(
> + enum efi_reset_type reset_type,
> + efi_status_t reset_status,
> + unsigned long data_size, void *reset_data)
> +{
> + u32 value = 0;
> +
> + if (reset_type == EFI_RESET_COLD)
> + value = SYS_RST | RST_CPU | FULL_RST;
> + else if (reset_type == EFI_RESET_WARM)
> + value = SYS_RST | RST_CPU;
The EFI should use the sysreset driver and sysreset_walk() or similar,
rather than having a function called directly.
> +
> + /* TODO EFI_RESET_PLATFORM_SPECIFIC and EFI_RESET_SHUTDOWN */
> +
> + if (value)
> + outb(value, IO_PORT_RESET);
> +
> + while (1) { }
> +}
> +#endif
>
> static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type)
> {
> --
> 2.12.3
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
On 1/28/19 4:42 PM, Alexander Graf wrote:
> Our selftest will soon test the actual runtime reset function rather than
> the boot time one. For this, we need to ensure that the runtime version
> actually succeeds on x86 to keep our travis tests work.
>
> So this patch implements an x86 runtime reset function. It is missing
> shutdown functionality today, but OSs usually implement that via ACPI
> and this function does more than the stub from before, so it's at least
> an improvement.
>
> Signed-off-by: Alexander Graf
> ---
> drivers/sysreset/sysreset_x86.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> index 20b958cfd4..efed45ccb7 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -10,6 +10,29 @@
> #include
> #include
> #include
> +#include
> +
> +#ifdef CONFIG_EFI_LOADER
> +void __efi_runtime EFIAPI efi_reset_system(
> + enum efi_reset_type reset_type,
> + efi_status_t reset_status,
> + unsigned long data_size, void *reset_data)
> +{
> + u32 value = 0;
> +
> + if (reset_type == EFI_RESET_COLD)
> + value = SYS_RST | RST_CPU | FULL_RST;
> + else if (reset_type == EFI_RESET_WARM)
> + value = SYS_RST | RST_CPU;
It would preferable to do a reset for EFI_RESET_PLATFORM_SPECIFIC
instead of falling in to a loop.
For EFI_RESET_SHUTDOWN this patch only puts a single CPU core into an
endless loop but does not do anything for the remaining cores. Resetting
the whole CPU would be an alternative.
> +
> + /* TODO EFI_RESET_PLATFORM_SPECIFIC and EFI_RESET_SHUTDOWN */
> +
> + if (value)
> + outb(value, IO_PORT_RESET);
Best regards
Heinrich
> +
> + while (1) { }
> +}
> +#endif
>
> static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type)
> {
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] efi_loader: Patch RTS at ExitBootServices
On 1/28/19 4:42 PM, Alexander Graf wrote: > While discussing something compeltely different, Ard pointed out > that it might be legal to omit calling SetVirtualAddressMap altogether. > > While that sounds great, we currently rely on that call to remove > all function pointers to code that we do not support outside of > boot services. > > So let's patch out those bits already on the call to ExitBootServices, > so that we can successfully run even when an OS chooses to omit > any call to SetVirtualAddressMap. This patch series is related to a parallel patch in Linux: efi: arm/arm64: allow SetVirtualAddressMap() to be omitted https://www.spinics.net/lists/linux-efi/msg15457.html Please, mention it in the next version of the patch series. The Python test_efi_selftest() has to be adjusted: 23 m = u_boot_console.p.expect(['resetting', 'U-Boot']) Please, add the missing patch to the series. Best regards Heinrich > > --- > > v1 -> v2: > > - Add missing icache invalidation > - New patch: x86: Add efi runtime reset > > Alexander Graf (2): > x86: Add efi runtime reset > efi_loader: Patch non-runtime code out at ExitBootServices already > > drivers/sysreset/sysreset_x86.c | 23 +++ > include/efi_loader.h| 2 ++ > lib/efi_loader/efi_boottime.c | 1 + > lib/efi_loader/efi_runtime.c| 29 - > 4 files changed, 46 insertions(+), 9 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/7] defconfigs: Add config for DRA7xx High Security EVM with USB Boot support
On 1/26/19 9:51 PM, Tom Rini wrote: > On Thu, Jan 17, 2019 at 01:43:06PM -0600, Andrew F. Davis wrote: > >> Add a new defconfig file for the DRA7xx High Security EVM. This config >> is specific for the case of USB booting. >> >> Signed-off-by: Andrew F. Davis >> Reviewed-by: Tom Rini > > OK, this an the am57xx_hs_evm_usb config no longer build on top of tree. > Can you please rebase the last 3 parts of this series? Thanks! > No problem, sent. Andrew ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 5/5] doc: ti-secure: Add ULO info for AM57xx/DRA7xx secure devices from TI
Booting from UART and USB on HS devices is now supported for this platform. Update documentation for the same. Signed-off-by: Andrew F. Davis Reviewed-by: Tom Rini --- doc/README.ti-secure | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/doc/README.ti-secure b/doc/README.ti-secure index 4b5380c0f3..76950253ac 100644 --- a/doc/README.ti-secure +++ b/doc/README.ti-secure @@ -108,7 +108,8 @@ Booting of U-Boot SPL Invoking the script for DRA7xx/AM57xx Secure Devices - create-boot-image.sh + create-boot-image.sh \ + is a value that specifies the type of the image to generate OR the action the image generation tool will take. Valid @@ -116,7 +117,6 @@ Booting of U-Boot SPL X-LOADER - Generates an image for NOR or QSPI boot modes MLO - Generates an image for SD/MMC/eMMC boot modes ULO - Generates an image for USB/UART peripheral boot modes - Note: ULO is not yet used by the u-boot build process is the full path and filename of the public world boot loader binary file (for this platform, this is always u-boot-spl.bin). @@ -130,9 +130,13 @@ Booting of U-Boot SPL the device ROM bootloader requires for loading from the FAT partition of an SD card (same as on non-secure devices) + u-boot-spl_HS_ULO - boot image for USB/UART peripheral boot modes u-boot-spl_HS_X-LOADER - boot image for all other flash memories including QSPI and NOR flash +is the address at which SOC ROM should load the + + Invoking the script for Keystone2 Secure Devices = -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/5] defconfigs: Add config for DRA7xx High Security EVM with USB Boot support
Add a new defconfig file for the DRA7xx High Security EVM. This config
is specific for the case of USB booting.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
MAINTAINERS | 1 +
configs/dra7xx_hs_evm_usb_defconfig | 113
2 files changed, 114 insertions(+)
create mode 100644 configs/dra7xx_hs_evm_usb_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 33f1127e50..cdf5a67321 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -690,6 +690,7 @@ F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
F: configs/am57xx_hs_evm_defconfig
F: configs/dra7xx_hs_evm_defconfig
+F: configs/dra7xx_hs_evm_usb_defconfig
F: configs/k2hk_hs_evm_defconfig
F: configs/k2e_hs_evm_defconfig
F: configs/k2g_hs_evm_defconfig
diff --git a/configs/dra7xx_hs_evm_usb_defconfig
b/configs/dra7xx_hs_evm_usb_defconfig
new file mode 100644
index 00..378b3d791c
--- /dev/null
+++ b/configs/dra7xx_hs_evm_usb_defconfig
@@ -0,0 +1,113 @@
+CONFIG_ARM=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_SYS_MALLOC_F_LEN=0x18000
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0
+CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200
+CONFIG_TI_SECURE_EMIF_PROTECTED_REGION_SIZE=0x01c0
+CONFIG_ISW_ENTRY_ADDR=0x40306d50
+CONFIG_TARGET_DRA7XX_EVM=y
+CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_ARMV7_LPAE=y
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS0,115200
androidboot.console=ttyS0 androidboot.hardware=jacinto6evmboard"
+# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_MISC_INIT_R is not set
+CONFIG_VERSION_VARIABLE=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_DMA_SUPPORT=y
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_DFU=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="dra7-evm"
+CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm dra76-evm"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_UNCOMPRESS_SZ=0x9000
+CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_DEVICE_REMOVE=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_DWC_AHCI=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_DFU_SF=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x8200
+CONFIG_FASTBOOT_BUF_SIZE=0x2F00
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_DM_GPIO=y
+CONFIG_PCF8575_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_SPL_MMC_HS200_SUPPORT=y
+CONFIG_MMC_OMAP_HS=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_DM_ETH=y
+CONFIG_PHY_GIGE=y
+CONFIG_MII=y
+CONFIG_DRIVER_TI_CPSW=y
+CONFIG_SPL_PHY=y
+CONFIG_PIPE3_PHY=y
+CONFIG_OMAP_USB2_PHY=y
+CONFIG_PMIC_PALMAS=y
+CONFIG_PMIC_LP873X=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_REGULATOR_PALMAS=y
+CONFIG_DM_REGULATOR_LP873X=y
+CONFIG_DM_SCSI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_SPL_DM_USB_GADGET=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/5] defconfigs: dra7xx_hs_evm: Sync HS and non-HS defconfigs
Additions have been made to the non-HS defconfig without the same being made to the HS defconfig, sync them. Signed-off-by: Andrew F. Davis --- configs/dra7xx_hs_evm_defconfig | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig index 735be5506a..f9983f4805 100644 --- a/configs/dra7xx_hs_evm_defconfig +++ b/configs/dra7xx_hs_evm_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_OMAP2PLUS=y CONFIG_TI_SECURE_DEVICE=y CONFIG_TI_COMMON_CMD_OPTIONS=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x18000 CONFIG_OMAP54XX=y CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0 CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200 @@ -37,13 +37,18 @@ CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="dra7-evm" CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm dra76-evm" +CONFIG_SPL_MULTI_DTB_FIT=y +CONFIG_SPL_MULTI_DTB_FIT_UNCOMPRESS_SZ=0x9000 +CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_DM=y CONFIG_SPL_DM=y +CONFIG_SPL_DM_DEVICE_REMOVE=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y +CONFIG_SPL_OF_TRANSLATE=y CONFIG_DWC_AHCI=y CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y @@ -62,6 +67,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_IO_VOLTAGE=y CONFIG_MMC_UHS_SUPPORT=y CONFIG_MMC_HS200_SUPPORT=y +CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_OMAP_HS=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/5] defconfigs: Add config for AM57xx High Security EVM with USB/UART Boot support
Add a new defconfig file for the AM57xx High Security EVM. This config
is specific for the case of USB/UART booting.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
MAINTAINERS | 1 +
configs/am57xx_hs_evm_usb_defconfig | 98 +
2 files changed, 99 insertions(+)
create mode 100644 configs/am57xx_hs_evm_usb_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index cdf5a67321..6f026024a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -689,6 +689,7 @@ F: configs/am335x_hs_evm_defconfig
F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
F: configs/am57xx_hs_evm_defconfig
+F: configs/am57xx_hs_evm_usb_defconfig
F: configs/dra7xx_hs_evm_defconfig
F: configs/dra7xx_hs_evm_usb_defconfig
F: configs/k2hk_hs_evm_defconfig
diff --git a/configs/am57xx_hs_evm_usb_defconfig
b/configs/am57xx_hs_evm_usb_defconfig
new file mode 100644
index 00..6e4580ae39
--- /dev/null
+++ b/configs/am57xx_hs_evm_usb_defconfig
@@ -0,0 +1,98 @@
+CONFIG_ARM=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0
+CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200
+CONFIG_TI_SECURE_EMIF_PROTECTED_REGION_SIZE=0x01c0
+CONFIG_ISW_ENTRY_ADDR=0x40306d50
+CONFIG_TARGET_AM57XX_EVM=y
+CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_ARMV7_LPAE=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS2,115200
androidboot.console=ttyS2 androidboot.hardware=beagle_x15board"
+# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_MISC_INIT_R is not set
+CONFIG_VERSION_VARIABLE=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_DMA_SUPPORT=y
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_USB_GADGET=y
+CONFIG_SPL_DFU=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+# CONFIG_CMD_PMIC is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15"
+CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1
am57xx-beagle-x15-revc am572x-idk am571x-idk am574x-idk"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SCSI_AHCI=y
+# CONFIG_BLK is not set
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x8200
+CONFIG_FASTBOOT_BUF_SIZE=0x2F00
+CONFIG_FASTBOOT_USB_DEV=1
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_OMAP_HS=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_MII=y
+CONFIG_DRIVER_TI_CPSW=y
+CONFIG_PHY=y
+CONFIG_PIPE3_PHY=y
+CONFIG_OMAP_USB2_PHY=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_PALMAS=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PALMAS=y
+CONFIG_DM_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_TI_QSPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_SPL_DM_USB_GADGET=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/5] defconfigs: am57xx_hs_evm: Sync HS and non-HS defconfigs
Additions have been made to the non-HS defconfig without the same being made to the HS defconfig, sync them. Signed-off-by: Andrew F. Davis --- configs/am57xx_hs_evm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig index 6924b0bd06..7bdf8dc64d 100644 --- a/configs/am57xx_hs_evm_defconfig +++ b/configs/am57xx_hs_evm_defconfig @@ -32,6 +32,7 @@ CONFIG_SPL_DMA_SUPPORT=y CONFIG_SPL_SPI_LOAD=y # CONFIG_CMD_FLASH is not set # CONFIG_CMD_SETEXPR is not set +# CONFIG_CMD_PMIC is not set CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15" -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/5] Add USB boot to HS DRA7xx/AM57xx
Hello all,
This series adds USB boot support to HS DRA7xx/AM57xx platforms.
Thanks,
Andrew
Changes from v3:
- Rebase on upstream
- Sync defconfigs
Changes from v2:
- Only use ISW_ENTRY_ADDR for system with a set default
Changes from v1:
- Drop explicit UART boot support from DRA7xx as this cannot be tested
Andrew F. Davis (5):
defconfigs: dra7xx_hs_evm: Sync HS and non-HS defconfigs
defconfigs: am57xx_hs_evm: Sync HS and non-HS defconfigs
defconfigs: Add config for DRA7xx High Security EVM with USB Boot
support
defconfigs: Add config for AM57xx High Security EVM with USB/UART Boot
support
doc: ti-secure: Add ULO info for AM57xx/DRA7xx secure devices from TI
MAINTAINERS | 2 ++
configs/am57xx_hs_evm_defconfig | 1 +
...hs_evm_defconfig => am57xx_hs_evm_usb_defconfig} | 6 ++
configs/dra7xx_hs_evm_defconfig | 8 +++-
...hs_evm_defconfig => dra7xx_hs_evm_usb_defconfig} | 13 -
doc/README.ti-secure| 8 ++--
6 files changed, 34 insertions(+), 4 deletions(-)
copy configs/{am57xx_hs_evm_defconfig => am57xx_hs_evm_usb_defconfig} (94%)
copy configs/{dra7xx_hs_evm_defconfig => dra7xx_hs_evm_usb_defconfig} (87%)
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4] arm64: mvebu: Add basic support for uDPU board
This adds initial support for micro-DPU (uDPU) board which is based on
Armada-3720 SoC.
micro-DPU is the single-port FTTdp "distribution point unit" made by Methode
Electronics
which offers complete modularity with replaceable SFP modules both for uplink
and downlink
(G.hn over twisted-pair, G.hn over coax, 1G and 2.5G Ethernet over Cat-5e
cable).
On-board features:
- 512 MiB DDR3
- 2 x 2.5G SFP via HSGMII SERDES interface to the A3720 SoC
- USB 2.0 Type-C connector
- 4GB eMMC
- ETSI TS 101548 reverse powering via twisted pair (RJ45) or coax (F Type)
Cc: Luka Perkov
Cc: Luis Torres
Cc: Scott Roberts
Cc: Paul Arola
Cc: Stefan Roese
Signed-off-by: Vladimir Vid
---
v4 changes:
- moved u-boot specific properties to armada-3720-uDPU-u-boot.dtsi
- added additional 'u-boot,dm-pre-reloc' on sdhci1 (eMMC)
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/armada-3720-uDPU-u-boot.dtsi | 13 ++
arch/arm/dts/armada-3720-uDPU.dts | 200
board/Marvell/mvebu_armada-37xx/MAINTAINERS | 5 +
configs/uDPU_defconfig | 94 +
5 files changed, 313 insertions(+)
create mode 100644 arch/arm/dts/armada-3720-uDPU-u-boot.dtsi
create mode 100644 arch/arm/dts/armada-3720-uDPU.dts
create mode 100644 configs/uDPU_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5c3225bcbf..9e1e1ad8e9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -95,6 +95,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-3720-db.dtb \
armada-3720-espressobin.dtb \
armada-3720-turris-mox.dtb \
+ armada-3720-uDPU.dts\
armada-375-db.dtb \
armada-388-clearfog.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/dts/armada-3720-uDPU-u-boot.dtsi
b/arch/arm/dts/armada-3720-uDPU-u-boot.dtsi
new file mode 100644
index 00..ef178bdc86
--- /dev/null
+++ b/arch/arm/dts/armada-3720-uDPU-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+&spi0 {
+ u-boot,dm-pre-reloc;
+
+ spi-flash@0 {
+ u-boot,dm-pre-reloc;
+ };
+};
+
+&sdhci1 {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/armada-3720-uDPU.dts
b/arch/arm/dts/armada-3720-uDPU.dts
new file mode 100644
index 00..683dac2a7c
--- /dev/null
+++ b/arch/arm/dts/armada-3720-uDPU.dts
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree for the uDPU board.
+ * Based on Marvell Armada 3720 development board (DB-88F3720-DDR3)
+ * Copyright (C) 2016 Marvell
+ * Copyright (C) 2018 Methode
+ * Copyright (C) 2018 Telus
+ *
+ * Vladimir Vid
+ */
+
+/dts-v1/;
+
+#include "armada-37xx.dtsi"
+#include "armada-3720-uDPU-u-boot.dtsi"
+
+/ {
+ model = "Methode uDPU Board";
+ compatible = "methode,udpu";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "console=ttyMV0,115200
earlycon=ar3700_uart,0xd0012000";
+ };
+
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ spi0 = &spi0;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x 0x 0x 0x2000>;
+ };
+
+ mdio: mdio@32004 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy0: ethernet-phy@0 {
+reg = <0>;
+ };
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+
+ scsi: scsi {
+ compatible = "marvell,mvebu-scsi";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ max-id = <1>;
+ max-lun = <1>;
+ status = "okay";
+ };
+
+ i2c1: i2c@11080 {
+ compatible = "marvell,armada-3700-i2c", "simple-bus";
+ reg = <0x0 0x11080 0x0 0x80>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ status = "okay";
+ };
+
+ uart1: serial@12200 {
+ compatible = "marvell,armada-3700-uart-ext";
+ reg = <0x0 0x12200 0x0 0x30>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ interrupts = ;
+ status = "okay";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ };
+
+ vcc_sd_reg0: regulator@0 {
+ compatible = "regulator-gpio";
+ regulator-name = "vcc_sd0";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-type = "voltage";
+ states = <180 0x1
+
Re: [U-Boot] [PATCH v3 0/5] spi-flash: switch to "jedec, spi-nor" binding
Hi Jagan, Tom, On 15/01/2019 13:59, Neil Armstrong wrote: > There is no reason not to use the Linux "jedec,spi-nor" binding in u-boot. > This patchset : > - adds this compatible into sf_probe and will avoid changing the > device tree files to add a u-boot specific compatible to probe a spi flash. > - switches all DTS/DTSI files to "jedec,spi-nor" > - remove the "spi-flash" compatible from sf-probe > - switch GENERIC_SPI_FLASH to jedec,spi-nor in fdtdec > - switches dt bindings examples files to "jedec,spi-nor" How this patchset could go in this release ? Should Jagan take it ? Thanks, Neil > > Changes since v2: > - collected tags > - extracted x86 dts changed and merged it with the fdtdec change > - updated for new boards > > Neil Armstrong (5): > mtd: sf_probe: add jedec,spi-nor compatible > dts: switch spi-flash to jedec,spi-nor compatible > x86: dts: switch spi-flash to jedec,spi-nor compatible > mtd: sf_probe: remove spi-flash compatible > doc: device-tree-bindings: switch from spi-flash to jedec,spi-nor > > arch/arc/dts/axs10x_mb.dtsi| 2 +- > arch/arc/dts/hsdk.dts | 2 +- > arch/arm/dts/am335x-brppt1-spi.dts | 2 +- > arch/arm/dts/am437x-idk-evm.dts| 2 +- > arch/arm/dts/am437x-sk-evm.dts | 2 +- > arch/arm/dts/armada-3720-db.dts| 2 +- > arch/arm/dts/armada-3720-espressobin.dts | 2 +- > arch/arm/dts/armada-3720-turris-mox.dts| 2 +- > arch/arm/dts/armada-385-amc.dts| 2 +- > arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi | 2 +- > arch/arm/dts/armada-38x-controlcenterdc.dts| 4 ++-- > arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 2 +- > arch/arm/dts/armada-8040-clearfog-gt-8k.dts| 2 +- > arch/arm/dts/armada-xp-theadorable.dts | 2 +- > arch/arm/dts/at91-sama5d2_xplained.dts | 2 +- > arch/arm/dts/at91-sama5d4_xplained.dts | 2 +- > arch/arm/dts/at91-sama5d4ek.dts| 2 +- > arch/arm/dts/at91sam9n12ek.dts | 2 +- > arch/arm/dts/at91sam9x5ek.dtsi | 2 +- > arch/arm/dts/bk4r1.dts | 4 ++-- > arch/arm/dts/da850-evm-u-boot.dtsi | 2 +- > arch/arm/dts/exynos5250-snow.dts | 2 +- > arch/arm/dts/exynos5250-spring.dts | 2 +- > arch/arm/dts/exynos5420-peach-pit.dts | 2 +- > arch/arm/dts/fsl-ls1012a-2g5rdb.dts| 2 +- > arch/arm/dts/fsl-ls1012a-frdm.dtsi | 2 +- > arch/arm/dts/fsl-ls1012a-frwy.dts | 2 +- > arch/arm/dts/fsl-ls1012a-qds.dtsi | 8 > arch/arm/dts/fsl-ls1012a-rdb.dtsi | 2 +- > arch/arm/dts/fsl-ls1043a-qds.dtsi | 8 > arch/arm/dts/fsl-ls1043a-rdb.dts | 2 +- > arch/arm/dts/fsl-ls1046a-qds.dtsi | 8 > arch/arm/dts/fsl-ls1046a-rdb.dts | 4 ++-- > arch/arm/dts/fsl-ls1088a-qds.dts | 10 +- > arch/arm/dts/fsl-ls1088a-rdb.dts | 4 ++-- > arch/arm/dts/fsl-ls2080a-qds.dts | 8 > arch/arm/dts/fsl-ls2080a-rdb.dts | 2 +- > arch/arm/dts/fsl-ls2081a-rdb.dts | 6 +++--- > arch/arm/dts/fsl-ls2088a-rdb-qspi.dts | 6 +++--- > arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi | 4 ++-- > arch/arm/dts/imx6sx-sdb-u-boot.dtsi| 4 ++-- > arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi | 2 +- > arch/arm/dts/imx6ul-9x9-evk-u-boot.dtsi| 2 +- > arch/arm/dts/imx6ull-14x14-evk.dts | 2 +- > arch/arm/dts/imx7d-sdb-qspi-u-boot.dtsi| 2 +- > arch/arm/dts/keystone-k2e-evm.dts | 2 +- > arch/arm/dts/keystone-k2g-evm.dts | 4 ++-- > arch/arm/dts/keystone-k2g-ice.dts | 2 +- > arch/arm/dts/keystone-k2hk-evm.dts | 2 +- > arch/arm/dts/keystone-k2l-evm.dts | 2 +- > arch/arm/dts/kirkwood-atl-sbx81lifkw.dts | 2 +- > arch/arm/dts/kirkwood-atl-sbx81lifxcat.dts | 2 +- > arch/arm/dts/kirkwood-dreamplug.dts| 2 +- > arch/arm/dts/kirkwood-lsxl.dtsi| 2 +- > arch/arm/dts/kirkwood-netxbig.dtsi | 2 +- > arch/arm/dts/kirkwood-ns2-common.dtsi | 2 +- > arch/arm/dts/kirkwood-synology.dtsi| 2 +- > arch/arm/dts/ls1021a-iot.dtsi | 4 ++-- > arch/arm/dts/ls1021a-qds.dtsi | 2 +- >
Re: [U-Boot] [PATCH u-boot 03/11] video: dw_hdmi: add support for color conversion
On Tue, 15 Jan 2019 17:17:51 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > From: Jorge Ramirez-Ortiz > > Some IPs like the meson VPU can only feed a particular pixel format to > dw_hdmi. As of now, the driver is hardcoded to use RGB888 as input. > > This commit enables different pixel format inputs, with the appropriate > CSC configuration. > > Signed-off-by: Jorge Ramire-Ortiz > Signed-off-by: Maxime Jourdan > Signed-off-by: Neil Armstrong Reviewed-by: Anatolij Gustschin -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 02/11] video: dw_hdmi: support SoC specific read/write ops
Hi Neil, On Tue, 15 Jan 2019 17:17:50 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > From: Jorge Ramirez-Ortiz > > Some IPs like the meson VPU have a specific way to write to dw_hdmi > registers. Make it configurable. > > Signed-off-by: Jorge Ramirez-Ortiz > [added commit description] > Signed-off-by: Maxime Jourdan > Signed-off-by: Neil Armstrong Reviewed-by: Anatolij Gustschin -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] efi_loader: Patch non-runtime code out at ExitBootServices already
While discussing something compeltely different, Ard pointed out
that it might be legal to omit calling SetVirtualAddressMap altogether.
While that sounds great, we currently rely on that call to remove
all function pointers to code that we do not support outside of
boot services.
So let's patch out those bits already on the call to ExitBootServices,
so that we can successfully run even when an OS chooses to omit
any call to SetVirtualAddressMap.
Reported-by: Ard Biesheuvel
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Add missing icache invalidation
---
include/efi_loader.h | 2 ++
lib/efi_loader/efi_boottime.c | 1 +
lib/efi_loader/efi_runtime.c | 29 -
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 9dd933dae7..2a40b09693 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -310,6 +310,8 @@ void efi_save_gd(void);
void efi_restore_gd(void);
/* Call this to relocate the runtime section to an address space */
void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map);
+/* Call this when we start to live in a runtime only world */
+void efi_runtime_detach(ulong offset);
/* Call this to set the current device name */
void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
/* Add a new object to the object list. */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index fc26d6adc1..8cb2979bab 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1917,6 +1917,7 @@ static efi_status_t EFIAPI
efi_exit_boot_services(efi_handle_t image_handle,
bootm_disable_interrupts();
/* Disable boot time services */
+ efi_runtime_detach((ulong)gd->relocaddr);
systab.con_in_handle = NULL;
systab.con_in = NULL;
systab.con_out_handle = NULL;
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 636dfdab39..17d22d429e 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -276,16 +276,12 @@ struct efi_runtime_detach_list_struct {
void *patchto;
};
-static const struct efi_runtime_detach_list_struct efi_runtime_detach_list[] =
{
+static struct efi_runtime_detach_list_struct efi_runtime_detach_list[] = {
{
/* do_reset is gone */
.ptr = &efi_runtime_services.reset_system,
.patchto = efi_reset_system,
}, {
- /* invalidate_*cache_all are gone */
- .ptr = &efi_runtime_services.set_virtual_address_map,
- .patchto = &efi_unimplemented,
- }, {
/* RTC accessors are gone */
.ptr = &efi_runtime_services.get_time,
.patchto = &efi_get_time,
@@ -328,7 +324,15 @@ static bool efi_runtime_tobedetached(void *p)
return false;
}
-static void efi_runtime_detach(ulong offset)
+/**
+ * efi_runtime_detach() - Remove any dependency on non-runtime sections
+ *
+ * This function patches all remaining code to be self-sufficient inside
+ * runtime sections. Any calls to non-runtime will be removed after this.
+ *
+ * @offset:relocaddr for pre-set_v_a_space, offset to VA after
+ */
+__efi_runtime void efi_runtime_detach(ulong offset)
{
int i;
ulong patchoff = offset - (ulong)gd->relocaddr;
@@ -344,6 +348,8 @@ static void efi_runtime_detach(ulong offset)
/* Update CRC32 */
efi_update_table_header_crc32(&efi_runtime_services.hdr);
+
+invalidate_icache_all();
}
/* Relocate EFI runtime to uboot_reloc_base = offset */
@@ -430,19 +436,25 @@ void efi_runtime_relocate(ulong offset, struct
efi_mem_desc *map)
* @virtmap: virtual address mapping information
* Return: status code
*/
-static efi_status_t EFIAPI efi_set_virtual_address_map(
+static __efi_runtime efi_status_t EFIAPI efi_set_virtual_address_map(
unsigned long memory_map_size,
unsigned long descriptor_size,
uint32_t descriptor_version,
struct efi_mem_desc *virtmap)
{
+ static __efi_runtime_data bool is_patched;
int n = memory_map_size / descriptor_size;
int i;
int rt_code_sections = 0;
+ if (is_patched)
+ return EFI_INVALID_PARAMETER;
+
EFI_ENTRY("%lx %lx %x %p", memory_map_size, descriptor_size,
descriptor_version, virtmap);
+ is_patched = true;
+
/*
* TODO:
* Further down we are cheating. While really we should implement
@@ -514,8 +526,7 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
map->physical_start + gd->relocaddr;
efi_runtime_relocate(new_offset, map);
- /* Once we're virtual, we can no longer handle
-
[U-Boot] [PATCH v2 0/2] efi_loader: Patch RTS at ExitBootServices
While discussing something compeltely different, Ard pointed out that it might be legal to omit calling SetVirtualAddressMap altogether. While that sounds great, we currently rely on that call to remove all function pointers to code that we do not support outside of boot services. So let's patch out those bits already on the call to ExitBootServices, so that we can successfully run even when an OS chooses to omit any call to SetVirtualAddressMap. --- v1 -> v2: - Add missing icache invalidation - New patch: x86: Add efi runtime reset Alexander Graf (2): x86: Add efi runtime reset efi_loader: Patch non-runtime code out at ExitBootServices already drivers/sysreset/sysreset_x86.c | 23 +++ include/efi_loader.h| 2 ++ lib/efi_loader/efi_boottime.c | 1 + lib/efi_loader/efi_runtime.c| 29 - 4 files changed, 46 insertions(+), 9 deletions(-) -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
Our selftest will soon test the actual runtime reset function rather than
the boot time one. For this, we need to ensure that the runtime version
actually succeeds on x86 to keep our travis tests work.
So this patch implements an x86 runtime reset function. It is missing
shutdown functionality today, but OSs usually implement that via ACPI
and this function does more than the stub from before, so it's at least
an improvement.
Signed-off-by: Alexander Graf
---
drivers/sysreset/sysreset_x86.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
index 20b958cfd4..efed45ccb7 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -10,6 +10,29 @@
#include
#include
#include
+#include
+
+#ifdef CONFIG_EFI_LOADER
+void __efi_runtime EFIAPI efi_reset_system(
+ enum efi_reset_type reset_type,
+ efi_status_t reset_status,
+ unsigned long data_size, void *reset_data)
+{
+ u32 value = 0;
+
+ if (reset_type == EFI_RESET_COLD)
+ value = SYS_RST | RST_CPU | FULL_RST;
+ else if (reset_type == EFI_RESET_WARM)
+ value = SYS_RST | RST_CPU;
+
+ /* TODO EFI_RESET_PLATFORM_SPECIFIC and EFI_RESET_SHUTDOWN */
+
+ if (value)
+ outb(value, IO_PORT_RESET);
+
+ while (1) { }
+}
+#endif
static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type)
{
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 19/26] configs: mx6sabresd: Add SPL FIT and DM support
On 19-01-18 10:30:24, Tom Rini wrote: > On Fri, Jan 18, 2019 at 03:26:42PM +, Abel Vesa wrote: > > On 19-01-18 13:16:07, Fabio Estevam wrote: > > > Hi Abel, > > > > > > On Fri, Jan 18, 2019 at 12:59 PM Abel Vesa wrote: > > > > > > > +CONFIG_OF_CONTROL=y > > > > +CONFIG_SPL_OF_CONTROL=y > > > > +CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd" > > > > > > Does this mean that only imx6q-sabresd variant is supported after this > > > series is applied? > > > > > > We still need to support imx6dl/imx6qp sabresd in the same binary as > > > we currently do today. > > > > Hmmm, so all the dtbs get built, trouble is we need to specify which dtb > > gets > > used by SPL. This is why the DEFAULT_DEVICE_TREE gets set. > > > > A solution to do what you're asking is to have a dtb in SPL that works for > > all socs (dl/qp/q) for each board (sabreauto/sabresd). I'm afraid it might > > get too big to fit in sram. I'll give it a try tomorrow. > > > > As for the u-boot proper, in order to have one u-boot.itb file that works > > on all socs we need to support MULTI_FIT in u-boot proper and make u-boot > > chose from the fit table the right dtb. I'll try to do that for the next > > version of this patchset. I'll keep you up to date with the development. > > Please note that this isn't the first family to have this problem. > Please see the TI Keystone 2 families and CONFIG_DTB_RESELECT as I would > swear we can go from a "good enough for all" to "correct for what we're > on" DTB in both SPL and U-Boot. And then yes, you end up compressing > the DTBs too so that we can fit things into limited space. And if we > still run into problems, which we might well still, lets talk. And it > might indeed end up making the most sense to make up a "just enough for > SPL for everyone" DTB or set of DTBs too. > OK, so I finally managed to get the multi dtb support in SPL. Added all three dtbs (for 6q, 6qp and 6dl) but the 6dl doesn't wanna boot anymore. The 6q and 6qp boot up just fine. The final SPL is 75K so it obviously doesn't fit in the 64K ocram the 6dl has. Once I enable the GZIP options (SPL_GZIP and SPL_MULTI_DTB_FIT_GZIP) I get this: u-boot-spl section `.rodata' will not fit in region `.sram' region `.sram' overflowed by 12708 bytes Same thing happens with LZO: u-boot-spl section `.data' will not fit in region `.sram' region `.sram' overflowed by 1396 bytes A solution would be to split the q/qp and dl into two separate defconfigs (and implicitly two different binaries). Btw, I don't understand why the dtbs (the fit table to be exact) do not overflow the ocram limit. I mean, I know why, but I believe that is incorrect. The fit table gets appended at the end so it builds fine. But I guess it should fail. Let me know what you guys think. > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/3] linker: Modify linker scripts to be more generic
On Tue, Jan 22, 2019 at 05:09:26PM -0500, Tom Rini wrote: > Make use of "IMAGE_MAX_SIZE" and "IMAGE_TEXT_BASE" rather than > CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE. This lets us re-use the > same script for both SPL and TPL. Add logic to scripts/Makefile.spl to > pass in the right value when preprocessing the script. > > Cc: Stefano Babic > Cc: Fabio Estevam > Cc: Jagan Teki > Cc: Maxime Ripard > Cc: Andreas Bießmann > Cc: Philipp Tomsich > Cc: Michal Simek > Cc: Daniel Schwierzeck > Cc: York Sun > Cc: Bin Meng > Cc: Heiko Schocher > Cc: Adam Ford > Signed-off-by: Tom Rini > Reviewed-by: Daniel Schwierzeck > Tested-by: Daniel Schwierzeck > Tested-by: Adam Ford #da850evm & omap3_logic_somlv > Reviewed-by: Simon Goldschmidt After some ugly hacks to buildman to save off linker scripts so I could diff before/after: Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/3] rockchip: Add TPL_MAX_SIZE for RK3288
On Tue, Jan 22, 2019 at 05:09:25PM -0500, Tom Rini wrote: > Per Kever Yang, 32768 is a reasonable max size for TPL on RK3288. > > Cc: Kever Yang > Cc: Philipp Tomsich > Signed-off-by: Tom Rini > Reviewed-by: Kever Yang Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] PowerPC: Stop re-using CONFIG_SPL_TEXT_BASE for TPL
On Tue, Jan 22, 2019 at 05:09:24PM -0500, Tom Rini wrote: > Rather than checking for CONFIG_TPL_BUILD and then re-defining > CONFIG_SPL_TEXT_BASE make use of CONFIG_TPL_TEXT_BASE directly. > > Cc: York Sun > Cc: Po Liu > Cc: Qiang Zhao > Cc: Timur Tabi > Signed-off-by: Tom Rini After some ugly hacks to buildman to save off linker scripts so I could diff before/after: Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Patch non-runtime code out at ExitBootServices already
On 26.01.19 10:31, Heinrich Schuchardt wrote: > On 1/25/19 10:43 PM, Ard Biesheuvel wrote: >> On Fri, 25 Jan 2019 at 19:21, Heinrich Schuchardt wrote: >>> >>> On 1/23/19 6:33 PM, Alexander Graf wrote: While discussing something compeltely different, Ard pointed out that it might be legal to omit calling SetVirtualAddressMap altogether. While that sounds great, we currently rely on that call to remove all function pointers to code that we do not support outside of boot services. So let's patch out those bits already on the call to ExitBootServices, so that we can successfully run even when an OS chooses to omit any call to SetVirtualAddressMap. >>> >>> Such an operating system would not be allowed to use any virtual >>> addresses at any time because runtime drivers would not be informed >>> about the mapping. >>> >> >> No. The OS would be permitted to invoke the runtime services at their >> original offset. >> >> For arm64, this is trivially achievable, since we already use userland >> mappings for the runtime services. On 32-bit architectures, it is more >> complicated, since the boot time mapping of peripherals and/or memory >> may conflict with the kernel's layout of the address space (e.g., if >> your NOR flash lives above 0xc000, you *have* to remap it for the >> runtime services to be able to use it). >> >> >> >>> Does such an operating system exist? >>> Or is this only a hypothetical case? >>> Reported-by: Ard Biesheuvel Signed-off-by: Alexander Graf >>> >>> I am missing a description of the side effects of the change, e.g. >>> >>> Our EFI unit tests call the Reset() service. >>> >>> So Python tests will fail on systems that do not implement Reset() in a >>> runtime compatible manner. >>> >> >> All runtime services (except SetVirtualAddresMap() and >> ConvertPointer(), obviously) may be used at runtime with or without >> installing a virtual address mapping. >> > > With this patch in place Travis CI testing fails: > > After 'bootefi selftest' this output is not ejected: > m = u_boot_console.p.expect(['resetting', 'U-Boot']) > > And after the reset U-Boot crashes (observed for qemu-arm64_defconfig). I just tried this out on the x86_64 variant. There reset does not occur, because at the point in time when we trigger the reset, ExitBootServices() has already been called. I would call that intentional - we patch the reset function away now because x86 doesn't provide an explicit efi enabled reset function. The arm breakage is related to a missing icache flush. I'll fix that one up. Thanks, Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote: > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford wrote: > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack wrote: > > > > > > Hello Adam, > > > > > > On 23.01.2019 22:13, Adam Ford wrote: > > > > By removing EXT support from SPL, it makes room for the extra > > > > overhead of enabling OF_CONTROL in SPL. With SPL_OF_CONTROL > > > > enabled, extra options need to be added to the device tree to > > > > tell it which portions of the tree are needed early in boot time > > > > > > > > Unfortunately, with these options as-is, the system doesn't boot > > > > nor does it display anything on the UART. I don't have a debugger > > > > readily available, but I have seen others with AM33x boards which > > > > are similar to OMAP3 boards. This is posted as an RFC just in case > > > > anyone has any suggestions on what might be missing. > > > > > > > On an AM335x board I had problems when moving from embedded to separate > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try. > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give > > > CONFIG_SPL_SEPARATE_BSS a try. > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did > > > help me quite a lot. > > > > I had to turn off DM_SERIAL temporarily to get some debugging going. > > I 'think' there is something wrong with fetching data from the device > > tree. > > > > I tried both OF_EMBDED and OF_SEPARATE without luck. SPL_SEPARATE_BSS is > > set. > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600) > > Trying to boot from MMC1 > > uclass_find_device_by_seq: 0 0 > >- not found > > uclass_find_device_by_seq: 1 0 > >- not found > > spl: could not find mmc device 0. error: -19 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > I can see the mmc0 device is appearing in my SPL dtb file. > > > > I am not sure what these values are support to be, but I was able to > > do a dump of my spl device tree: > > > > dtc -I dtb -O dts spl/u-boot-spl.dtb > > Looking at Tom's defconfig file changes for the beagle, I noticed he > disabled Falcon mode. As soon as I disabled Falcon mode, I was able > to get my device tree based SPL to initialize both serial and MMC. > With Falcon mode enabled, it immediately stops booting and/or showing > anything. There seems to be some correlation, because disabling it > again make it work. > > With DM_SERIAL off, I can see the dumps to the screen and with the > debugging enabled, I can see that it is not able to locate the MMC > device. I am going to assume that if it cannot find the MMC device, > it probably cannot find the serial device which may explain why > disabling DM_SERIAL in SPL with Falcon mode on shows text. > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG > with Falcon working? I'd really like to keep that enabled by default. Note that I disabled Falcon for the space savings to keep MLO small enough, not that I noticed it failing to work. Given that with my patches what does work is loading an un-patched-for-DM-and-SPL u-boot and doesn't work is booting the u-boot.img I just built if there's not some overlap there. Perhaps the addresses being used for BSS/malloc/whatever are stomping on the image and that's wrecking things? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
On Fri, Jan 25, 2019 at 3:39 PM Adam Ford wrote:
>
> On Thu, Jan 24, 2019 at 7:19 AM Felix Brack wrote:
> >
> > Hello Adam,
> >
> > On 23.01.2019 22:13, Adam Ford wrote:
> > > By removing EXT support from SPL, it makes room for the extra
> > > overhead of enabling OF_CONTROL in SPL. With SPL_OF_CONTROL
> > > enabled, extra options need to be added to the device tree to
> > > tell it which portions of the tree are needed early in boot time
> > >
> > > Unfortunately, with these options as-is, the system doesn't boot
> > > nor does it display anything on the UART. I don't have a debugger
> > > readily available, but I have seen others with AM33x boards which
> > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > anyone has any suggestions on what might be missing.
> > >
> > On an AM335x board I had problems when moving from embedded to separate
> > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > CONFIG_SPL_SEPARATE_BSS a try.
> > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > help me quite a lot.
>
> I had to turn off DM_SERIAL temporarily to get some debugging going.
> I 'think' there is something wrong with fetching data from the device
> tree.
>
> I tried both OF_EMBDED and OF_SEPARATE without luck. SPL_SEPARATE_BSS is set.
>
> U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> Trying to boot from MMC1
> uclass_find_device_by_seq: 0 0
>- not found
> uclass_find_device_by_seq: 1 0
>- not found
> spl: could not find mmc device 0. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> I can see the mmc0 device is appearing in my SPL dtb file.
>
> I am not sure what these values are support to be, but I was able to
> do a dump of my spl device tree:
>
> dtc -I dtb -O dts spl/u-boot-spl.dtb
Looking at Tom's defconfig file changes for the beagle, I noticed he
disabled Falcon mode. As soon as I disabled Falcon mode, I was able
to get my device tree based SPL to initialize both serial and MMC.
With Falcon mode enabled, it immediately stops booting and/or showing
anything. There seems to be some correlation, because disabling it
again make it work.
With DM_SERIAL off, I can see the dumps to the screen and with the
debugging enabled, I can see that it is not able to locate the MMC
device. I am going to assume that if it cannot find the MMC device,
it probably cannot find the serial device which may explain why
disabling DM_SERIAL in SPL with Falcon mode on shows text.
Might someone have any suggestions as to how to get both SPL_OF_CONFIG
with Falcon working? I'd really like to keep that enabled by default.
adam
>
>
> /dts-v1/;
>
> / {
> compatible = "ti,am3517-evm\0ti,am3517\0ti,omap3";
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> model = "TI AM3517 EVM (AM3517/05 TMDSEVM3517)";
>
> chosen {
> stdout-path = "/ocp@6800/serial@4902";
> };
>
> aliases {
> i2c0 = "/ocp@6800/i2c@4807";
> serial0 = "/ocp@6800/serial@4806a000";
> serial1 = "/ocp@6800/serial@4806c000";
> serial2 = "/ocp@6800/serial@4902";
> };
>
> ocp@6800 {
> compatible = "ti,omap3-l3-smx\0simple-bus";
> reg = < 0x6800 0x1 >;
> interrupts = < 0x09 0x0a >;
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> ranges;
> ti,hwmods = "l3_main";
> u-boot,dm-spl;
>
> l4@4800 {
> compatible = "ti,omap3-l4-core\0simple-bus";
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> ranges = < 0x00 0x4800 0x100 >;
> u-boot,dm-spl;
>
> scm@2000 {
> compatible = "ti,omap3-scm\0simple-bus";
> reg = < 0x2000 0x2000 >;
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> ranges = < 0x00 0x2000 0x2000 >;
> u-boot,dm-spl;
>
> scm_conf@270 {
> compatible = "syscon\0simple-bus";
> reg = < 0x270 0x330 >;
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> ranges = < 0x00 0x270 0x330 >;
> u-boot,dm-spl;
> phandle = < 0x05 >;
> };
> };
> };
>
> gpio@4831 {
> compatible = "ti,omap3-gpio";
> reg = < 0x4831 0x200 >;
> interrupts = < 0x1d >;
> ti,hwmods = "gpio1";
> ti,gpio-always-on;
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xec >;
> };
>
> gpio@4905 {
> compatible = "ti,omap3-gpio";
> reg = < 0x4905 0x200 >;
> interrupts = < 0x1e >;
> ti,hwmods = "gpio2";
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xd0 >;
> };
>
> gpio@49052000 {
> compatible = "ti,omap3-gpio";
> reg = < 0x49052000 0x200 >;
> interrupts = < 0x1f >;
> ti,hwmods = "gpio3";
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xd4 >;
> };
>
> gpio@49054000 {
> compatible = "ti,omap3-gpio";
> reg = < 0x49054000 0x200 >;
> inte
Re: [U-Boot] [PATCH v1 06/15] dm: clk: imx: Add support for controlling imx6q clocks via Driver Model
Hi Lukasz,
On 21/01/19 15:19, Lukasz Majewski wrote:
> Hi Fabio,
>
>> Hi Lukasz,
>>
>> On Sat, Jan 19, 2019 at 7:15 AM Lukasz Majewski wrote:
>>
>>> +static ulong imx6q_clk_get_rate(struct clk *clk)
>>> +{
>>> + ulong rate = 0;
>>> +
>>> + debug("%s(#%lu)\n", __func__, clk->id);
>>> +
>>> + switch (clk->id) {
>>> + case IMX6QDL_CLK_ECSPI1:
>>> + case IMX6QDL_CLK_ECSPI2:
>>> + case IMX6QDL_CLK_ECSPI3:
>>> + case IMX6QDL_CLK_ECSPI4:
>>> + return imx6_get_cspi_clk();
>>> +
>>> + case IMX6QDL_CLK_USDHC1:
>>> + case IMX6QDL_CLK_USDHC2:
>>> + case IMX6QDL_CLK_USDHC3:
>>> + case IMX6QDL_CLK_USDHC4:
>>> + return imx6_get_usdhc_clk(clk->id -
>>> IMX6QDL_CLK_USDHC1);
>>
>> I don't think this scales well as this needs to grow for all other
>> peripherals and for each port instance.
>
I am hiiting the same doubts as Fabio when I reviewed Peng's patches
with clocks for i.MX8M. The current approach was introduced some years
ago with i.MX5, but it does not fit well now and it does not scale.
> The rationale regarding this approach:
>
> 1. Reuse the clock.c code for iMX6Q as much as possible.
>
> 2, This code is based on the clk-imx8q.c file - hence the question
> why the Linux clock API was not ported for this new SoC?.
Many reasons, first there was already a set of functions to get / set
clocks coming from previos i.MX platforms, and this API was simply
reused. And nobody was in charge to port the clock API.
>
>>
>> If we are adding a clock driver for mx6, why don't we add it just like
>> the kernel one?
>
> I can try to port the Linux code, but IMHO it would be feasible to port
> only relevant (ECSPI, USDHC) parts of it (not all as I cannot test it
> all properly).
Fully agree. Further parts will be added on demand. Less is better. I
disagree to add not tested code.
>
>>
>> Barebox imports the clock driver from the kernel and it is much
>> cleaner:
>> https://git.pengutronix.de/cgit/barebox/tree/drivers/clk/imx/clk-imx6.c
>
> Yes, it has been trimmed (...a bit...) when compared to original
> v4.20 :-) .
>
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: Check the PL310 version for applying errata
Hi Ye,
On 07/01/19 10:29, Ye Li wrote:
> Apply errata based on PL310 version instead of compile
> time. Also set Prefetch offset to 15, since it improves
> memcpy performance by 35%. Don't enable Incr double
> Linefill enable since it adversely affects memcpy
> performance by about 32MB/s and reads by 90MB/s. Tested
> with 4K to 16MB sized src and dst aligned buffer.
>
> Signed-off-by: Nitin Garg
> Signed-off-by: Ye Li
> ---
> arch/arm/include/asm/pl310.h | 5 +
> arch/arm/mach-imx/cache.c| 18 ++
> 2 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/include/asm/pl310.h b/arch/arm/include/asm/pl310.h
> index 3624362..b83978b 100644
> --- a/arch/arm/include/asm/pl310.h
> +++ b/arch/arm/include/asm/pl310.h
> @@ -19,6 +19,11 @@
> #define L310_AUX_CTRL_DATA_PREFETCH_MASK (1 << 28)
> #define L310_AUX_CTRL_INST_PREFETCH_MASK (1 << 29)
>
> +#define L2X0_CACHE_ID_PART_MASK (0xf << 6)
> +#define L2X0_CACHE_ID_PART_L310 (3 << 6)
> +#define L2X0_CACHE_ID_RTL_MASK 0x3f
> +#define L2X0_CACHE_ID_RTL_R3P2 0x8
> +
> struct pl310_regs {
> u32 pl310_cache_id;
> u32 pl310_cache_type;
> diff --git a/arch/arm/mach-imx/cache.c b/arch/arm/mach-imx/cache.c
> index 82257f3..75e1f54 100644
> --- a/arch/arm/mach-imx/cache.c
> +++ b/arch/arm/mach-imx/cache.c
> @@ -82,7 +82,7 @@ void v7_outer_cache_enable(void)
> {
> struct pl310_regs *const pl310 = (struct pl310_regs *)L2_PL310_BASE;
> struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
> - unsigned int val;
> + unsigned int val, cache_id;
>
>
> /*
> @@ -112,22 +112,24 @@ void v7_outer_cache_enable(void)
>
> val = readl(&pl310->pl310_prefetch_ctrl);
>
> - /* Turn on the L2 I/D prefetch */
> - val |= 0x3000;
> + /* Turn on the L2 I/D prefetch, double linefill */
> + /* Set prefetch offset with any value except 23 as per errata 765569 */
> + val |= 0x700f;
>
> /*
>* The L2 cache controller(PL310) version on the i.MX6D/Q is r3p1-50rel0
> - * The L2 cache controller(PL310) version on the i.MX6DL/SOLO/SL is r3p2
> + * The L2 cache controller(PL310) version on the i.MX6DL/SOLO/SL/SX/DQP
> + * is r3p2.
>* But according to ARM PL310 errata: 752271
>* ID: 752271: Double linefill feature can cause data corruption
>* Fault Status: Present in: r3p0, r3p1, r3p1-50rel0. Fixed in r3p2
>* Workaround: The only workaround to this erratum is to disable the
>* double linefill feature. This is the default behavior.
>*/
> -
> -#ifndef CONFIG_MX6Q
> - val |= 0x4080;
> -#endif
> + cache_id = readl(&pl310->pl310_cache_id);
> + if (((cache_id & L2X0_CACHE_ID_PART_MASK) == L2X0_CACHE_ID_PART_L310)
> + && ((cache_id & L2X0_CACHE_ID_RTL_MASK) < L2X0_CACHE_ID_RTL_R3P2))
> + val &= ~(1 << 30);
Very good idea !
Reviewd-by: Stefano Babic
Best regards,
Stefano Babic
> writel(val, &pl310->pl310_prefetch_ctrl);
>
> val = readl(&pl310->pl310_power_ctrl);
>
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V3 6/6] bcm968580: enable watchdog and reboot with watchdog
Enable watchdog and reboot with watchdog in the configuration. Signed-off-by: Philippe Reynes --- configs/bcm968580_ram_defconfig | 2 ++ 1 file changed, 2 insertions(+) Changelog: v2: - add a commit message (thanks Marek) v3: - no change diff --git a/configs/bcm968580_ram_defconfig b/configs/bcm968580_ram_defconfig index 56e0a56..b23f960 100644 --- a/configs/bcm968580_ram_defconfig +++ b/configs/bcm968580_ram_defconfig @@ -31,5 +31,7 @@ CONFIG_DM_SERIAL=y CONFIG_SERIAL_SEARCH_ALL=y CONFIG_BCM6345_SERIAL=y CONFIG_SYSRESET=y +CONFIG_SYSRESET_WATCHDOG=y +CONFIG_WDT_BCM6345=y CONFIG_REGEX=y # CONFIG_GENERATE_SMBIOS_TABLE is not set -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V3 4/6] dt: bcm6858: add watchdog
This commit add watchdog and sysreset watchdog
in the bcm6858 device tree.
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm6858.dtsi | 17 +
1 file changed, 17 insertions(+)
Changelog:
v2:
- add a commit message (thanks Marek)
v3:
- no change
diff --git a/arch/arm/dts/bcm6858.dtsi b/arch/arm/dts/bcm6858.dtsi
index d78d34d..23b80c6 100644
--- a/arch/arm/dts/bcm6858.dtsi
+++ b/arch/arm/dts/bcm6858.dtsi
@@ -81,5 +81,22 @@
status = "disabled";
};
+
+ wdt1: watchdog@ff802780 {
+ compatible = "brcm,bcm6345-wdt";
+ reg = <0x0 0xff802780 0x0 0x14>;
+ clocks = <&periph_osc>;
+ };
+
+ wdt2: watchdog@ff8027c0 {
+ compatible = "brcm,bcm6345-wdt";
+ reg = <0x0 0xff8027c0 0x0 0x14>;
+ clocks = <&periph_osc>;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdt1>;
+ };
};
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V3 5/6] bcm968380gerg: enable watchdog and reboot with watchdog
Enable watchdog and reboot with watchdog in the configuration. Signed-off-by: Philippe Reynes --- configs/bcm968380gerg_ram_defconfig | 2 ++ 1 file changed, 2 insertions(+) Changelog: v2: - add a commit message (thanks Marek) v3: - no change diff --git a/configs/bcm968380gerg_ram_defconfig b/configs/bcm968380gerg_ram_defconfig index fdecc0f..d98fe51 100644 --- a/configs/bcm968380gerg_ram_defconfig +++ b/configs/bcm968380gerg_ram_defconfig @@ -46,4 +46,6 @@ CONFIG_RESET_BCM6345=y # CONFIG_SPL_SERIAL_PRESENT is not set CONFIG_DM_SERIAL=y CONFIG_BCM6345_SERIAL=y +CONFIG_SYSRESET_WATCHDOG=y +CONFIG_WDT_BCM6345=y CONFIG_LZO=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
