Re: [U-Boot] [PATCH v5 2/4] doc: bindings: Add description for MDIO MUX dts nodes
On 7/12/2019 9:44 AM, Bin Meng wrote: Hi Alex, On Fri, Jul 12, 2019 at 2:39 PM Alex Marginean wrote: Adds a short bindings document describing the expected structure of a MDIO MUX dts node. This is based on Linux binding and the example is in fact copied from there. Signed-off-by: Alex Marginean Acked-by: Joe Hershberger Reviewed-by: Bin Meng --- Changes in v2: - no change Changes in v3: - no change, just fighting with the email server Changes in v4: - pulled in full binding example from Linux, added a note on why mdio-parent-bus is currently required in U-boot but not in Linux Changes in v5: - fixed a few typos, a multi-line comment format doc/device-tree-bindings/net/mdio-mux.txt | 138 ++ 1 file changed, 138 insertions(+) create mode 100644 doc/device-tree-bindings/net/mdio-mux.txt diff --git a/doc/device-tree-bindings/net/mdio-mux.txt b/doc/device-tree-bindings/net/mdio-mux.txt new file mode 100644 index 00..b87efe9535 --- /dev/null +++ b/doc/device-tree-bindings/net/mdio-mux.txt @@ -0,0 +1,138 @@ +The expected structure of an MDIO MUX device tree node is described here. This +is heavily based on current Linux specification. +One notable difference to Linux is that mdio-parent-bus is currently required +by U-boot, not optional as is in Linux. Current U-boot MDIO MUX udevice class Sorry but I was saying "U-Boot" :) too nitpicking I am :) oops, I'll send a v6 :) [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] bug.h: Drop filename from BUG/WARNING logs if building for TPL/SPL
Hi Andreas, On Fri, Jul 12, 2019 at 3:12 AM Andreas Dannenberg wrote: > > Yamada-san, > > On Fri, Jul 12, 2019 at 02:29:02AM +0900, Masahiro Yamada wrote: > > On Fri, Jul 12, 2019 at 12:34 AM Andreas Dannenberg > > wrote: > > > > > > On Wed, Jul 10, 2019 at 04:30:44PM -0500, Andreas Dannenberg wrote: > > > > On several platforms space is very tight when building for SPL or TPL. > > > > To claw back a few bytes to be used for code remove the __FILE__ name > > > > from the BUG() and WARN() type macros. Since those macros still print > > > > the function name plus a line number this should not really affect > > > > the ability to backtrace an actual BUG/WARN message to a specific > > > > piece of code. > > > > > > > > Signed-off-by: Andreas Dannenberg > > > > --- > > > > > > > > I was looking for a way to shave off a few bytes from the SPL code size > > > > (TI AM335x) and looking at the hexdump of the SPL I found well why not > > > > further reduce some strings down in size... I was already aware of the > > > > recent compiler optimizations to drop some of the irrelevant path from > > > > the __FILE__ macro but I wanted to go one step beyond this. Dropping > > > > all the path from __FILE__ via preprocessor macro can't be easily done > > > > as others have already found so I decided to drop __FILE__ altogether > > > > (code below) and was excited about the improvements I got... > > > > > > Just some quick examples about the savings... > > > > > > Using buildman "bloat" reporting (-B) I see the SPL .text size for AM335x > > > to be reduced by 12 bytes. And for AM43xx the size goes down by 52 > > > bytes. The benefit of the proposed change really depends on a) whether a > > > given platform uses SPL, and b) how many calls to BUG/WARN it has. The > > > USB drivers in AM335x/AM43xx are really the "heavy hitters" here. I'm > > > sure I could find additional examples/platforms to highlight savings if > > > needed. > > > > > > Anyways I'm not proud of the proposed change but merely wanted to see > > > with this RFC if there isn't any way to do further optimizations on the > > > __FILE__ topic that are not overly intrusive specifically as it comes to > > > SPL. > > > > > > Commit 1eb2e71edd55e16562e3912881c449db69623352 > > was not enough to solve your problem. > > > > Correct? > > Correct. This is a great commit and I saw what all went into it and it > goes a long way in addressing the general concern and doing much needed > cleanup but I wanted to go beyond this. > > Consider this example, if I use a WARN_ON() deep in the arch folder of > one of the SoCs, I would get this on the console... > > WARNING at arch/arm/mach-k3/am6_init.c:192/board_init_f()! > > ...and now, with the proposed change, it would boil down to this... > > WARNING at 192@board_init_f()! > > > If we could just keep the base filename itself that would still be a > good size reduction, and keep the output somewhat consistent with the > original behavior, but I spent quite some time researching but without > some extreme "magic" there didn't seem to be an universal solution... > > > Also some additional background why I am even looking into this. One of > our platforms (AM335x) has a regression building on Travis CI with some > of our pending patches applied. Interestingly, this only happens on > Travis, which still uses GCC 7.3.0 for arm (why?). With newer, more > efficient compilers there is no such issue. OK, then. Thanks for explanation. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 2/4] doc: bindings: Add description for MDIO MUX dts nodes
Adds a short bindings document describing the expected structure of a MDIO
MUX dts node. This is based on Linux binding and the example is in fact
copied from there.
Signed-off-by: Alex Marginean
Acked-by: Joe Hershberger
Reviewed-by: Bin Meng
---
Changes in v2:
- no change
Changes in v3:
- no change, just fighting with the email server
Changes in v4:
- pulled in full binding example from Linux, added a note on why
mdio-parent-bus is currently required in U-boot but not in Linux
Changes in v5:
- fixed a few typos, a multi-line comment format
Changes in v6:
- re-fixed U-Boot name typo
doc/device-tree-bindings/net/mdio-mux.txt | 138 ++
1 file changed, 138 insertions(+)
create mode 100644 doc/device-tree-bindings/net/mdio-mux.txt
diff --git a/doc/device-tree-bindings/net/mdio-mux.txt
b/doc/device-tree-bindings/net/mdio-mux.txt
new file mode 100644
index 00..b87efe9535
--- /dev/null
+++ b/doc/device-tree-bindings/net/mdio-mux.txt
@@ -0,0 +1,138 @@
+The expected structure of an MDIO MUX device tree node is described here. This
+is heavily based on current Linux specification.
+One notable difference to Linux is that mdio-parent-bus is currently required
+by U-Boot, not optional as is in Linux. Current U-Boot MDIO MUX udevice class
+implementation does not have specific support for MDIOs with an integrated MUX,
+the property should be made optional if such support is added.
+
+The MDIO buses downstream of the MUX should be described in the device tree as
+child nodes as indicated below.
+
+Required properties:
+mdio-parent-bus = a phandle to the MDIO bus used to perform actual I/O. This
is
+ typically a real MDIO device, unless there are cascaded
MUXes.
+#address-cells = <1>, each MDIO group is identified by one 32b value.
+#size-cells = <0>
+
+Other properties:
+The properties described here are sufficient for MDIO MUX DM class code, but
+MUX drivers may define additional properties, either required or optional.
+
+Required properties in child nodes:
+reg = value to be configured on the MUX to select the respective downstream
+ MDIO.
+
+Child nodes should normally contain PHY nodes, referenced by phandle from
+ethernet nodes of the eth interfaces using these PHYs.
+
+Example structure, extracted from Linux bindings document:
+
+ /* The parent MDIO bus. */
+ smi1: mdio@118001900 {
+ compatible = "cavium,octeon-3860-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x11800 0x1900 0x0 0x40>;
+ };
+ /*
+* An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
+* pair of GPIO lines. Child busses 2 and 3 populated with 4
+* PHYs each.
+*/
+ mdio-mux {
+ compatible = "mdio-mux-gpio";
+ gpios = <&gpio1 3 0>, <&gpio1 4 0>;
+ mdio-parent-bus = <&smi1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mdio@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy11: ethernet-phy@1 {
+ reg = <1>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <10 8>; /* Pin 10, active low */
+ };
+ phy12: ethernet-phy@2 {
+ reg = <2>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <10 8>; /* Pin 10, active low */
+ };
+ phy13: ethernet-phy@3 {
+ reg = <3>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <10 8>; /* Pin 10, active low */
+ };
+ phy14: ethernet-phy@4 {
+ reg = <4>;
[U-Boot] [PATCH v6 1/4] net: add MDIO_MUX DM class
Adds a class for MDIO MUXes, which control access to a series of
downstream child MDIOs.
MDIO MUX drivers are required to implement a select function used to switch
between child buses.
MUX children are registered as MDIO buses and they can be used just like
regular MDIOs.
Signed-off-by: Alex Marginean
Reviewed-by: Bin Meng
Acked-by: Joe Hershberger
---
Changes in v2:
- no change
Changes in v3:
- no change, just fighting with the email server
Changes in v4:
- fixed a couple of typos
Changes in v5:
- no change
Changes in v6:
- no change
drivers/net/Kconfig| 12 +++
include/dm/uclass-id.h | 1 +
include/miiphy.h | 20
net/Makefile | 1 +
net/mdio-mux-uclass.c | 232 +
5 files changed, 266 insertions(+)
create mode 100644 net/mdio-mux-uclass.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c4f4e04ff8..f09f8c5f52 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -24,6 +24,18 @@ config DM_MDIO
This is currently implemented in net/mdio-uclass.c
Look in include/miiphy.h for details.
+config DM_MDIO_MUX
+ bool "Enable Driver Model for MDIO MUX devices"
+ depends on DM_MDIO
+ help
+ Enable driver model for MDIO MUX devices
+
+ Adds UCLASS_MDIO_MUX DM class supporting MDIO MUXes. Useful for
+ systems that support DM_MDIO and integrate one or multiple muxes on
+ the MDIO bus.
+ This is currently implemented in net/mdio-mux-uclass.c
+ Look in include/miiphy.h for details.
+
config MDIO_SANDBOX
depends on DM_MDIO && SANDBOX
default y
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 90667e62cf..b859a9ec04 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -59,6 +59,7 @@ enum uclass_id {
UCLASS_MAILBOX, /* Mailbox controller */
UCLASS_MASS_STORAGE,/* Mass storage device */
UCLASS_MDIO,/* MDIO bus */
+ UCLASS_MDIO_MUX,/* MDIO MUX/switch */
UCLASS_MISC,/* Miscellaneous device */
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
diff --git a/include/miiphy.h b/include/miiphy.h
index e6dd441983..9b97d09f18 100644
--- a/include/miiphy.h
+++ b/include/miiphy.h
@@ -167,4 +167,24 @@ struct phy_device *dm_mdio_phy_connect(struct udevice
*dev, int addr,
#endif
+#ifdef CONFIG_DM_MDIO_MUX
+
+/* indicates none of the child buses is selected */
+#define MDIO_MUX_SELECT_NONE -1
+
+/**
+ * struct mdio_mux_ops - MDIO MUX operations
+ *
+ * @select: Selects a child bus
+ * @deselect: Clean up selection. Optional, can be NULL
+ */
+struct mdio_mux_ops {
+ int (*select)(struct udevice *mux, int cur, int sel);
+ int (*deselect)(struct udevice *mux, int sel);
+};
+
+#define mdio_mux_get_ops(dev) ((struct mdio_mux_ops *)(dev)->driver->ops)
+
+#endif
+
#endif
diff --git a/net/Makefile b/net/Makefile
index 6251ff3991..826544f05f 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -16,6 +16,7 @@ else
obj-$(CONFIG_NET) += eth_legacy.o
endif
obj-$(CONFIG_DM_MDIO) += mdio-uclass.o
+obj-$(CONFIG_DM_MDIO_MUX) += mdio-mux-uclass.o
obj-$(CONFIG_NET) += eth_common.o
obj-$(CONFIG_CMD_LINK_LOCAL) += link_local.o
obj-$(CONFIG_NET) += net.o
diff --git a/net/mdio-mux-uclass.c b/net/mdio-mux-uclass.c
new file mode 100644
index 00..e425207d6e
--- /dev/null
+++ b/net/mdio-mux-uclass.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019
+ * Alex Marginean, NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MDIO_MUX_CHILD_DRV_NAME"mdio-mux-bus-drv"
+
+/**
+ * struct mdio_mux_perdev_priv - Per-device class data for MDIO MUX DM
+ *
+ * @parent_mdio: Parent DM MDIO device, this is called for actual MDIO I/O
after
+ * setting up the mux. Typically this is a real MDIO device,
+ * unless there are cascaded muxes.
+ * @selected:Current child bus selection. Defaults to -1
+ */
+struct mdio_mux_perdev_priv {
+ struct udevice *mdio_parent;
+ int selected;
+};
+
+/*
+ * This source file uses three types of devices, as follows:
+ * - mux is the hardware MDIO MUX which selects between the existing child MDIO
+ * buses, this is the device relevant for MDIO MUX class of drivers.
+ * - ch is a child MDIO bus, this is just a representation of a mux selection,
+ * not a real piece of hardware.
+ * - mdio_parent is the actual MDIO bus called to perform reads/writes after
+ * the MUX is configured. Typically this is a real MDIO device, unless there
+ * are cascaded muxes.
+ */
+
+/**
+ * struct mdio_mux_ch_data - Per-device data for child MDIOs
+ *
+ * @sel: Selection value used by the MDIO MUX to access this child MDIO bus
+ */
+struct mdio_mux_ch_data {
+ int sel;
+};
+
+static
[U-Boot] [PATCH v6 3/4] test: dm_mdio: add a 2nd register to the emulated PHY
This 2nd register is used by the follow-up MDIO MUX test.
Signed-off-by: Alex Marginean
Reviewed-by: Bin Meng
Acked-by: Joe Hershberger
---
Changes in v2:
- no change
Changes in v3:
- no change, just fighting with the email server
Changes in v4:
- no change
Changes in v5:
- no change
Changes in v6:
- no change
drivers/net/mdio_sandbox.c | 16 +---
test/dm/mdio.c | 3 +++
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/mdio_sandbox.c b/drivers/net/mdio_sandbox.c
index 07515e078c..df053f5381 100644
--- a/drivers/net/mdio_sandbox.c
+++ b/drivers/net/mdio_sandbox.c
@@ -9,11 +9,11 @@
#include
#define SANDBOX_PHY_ADDR 5
-#define SANDBOX_PHY_REG0
+#define SANDBOX_PHY_REG_CNT2
struct mdio_sandbox_priv {
int enabled;
- u16 reg;
+ u16 reg[SANDBOX_PHY_REG_CNT];
};
static int mdio_sandbox_read(struct udevice *dev, int addr, int devad, int reg)
@@ -27,10 +27,10 @@ static int mdio_sandbox_read(struct udevice *dev, int addr,
int devad, int reg)
return -ENODEV;
if (devad != MDIO_DEVAD_NONE)
return -ENODEV;
- if (reg != SANDBOX_PHY_REG)
+ if (reg < 0 || reg > SANDBOX_PHY_REG_CNT)
return -ENODEV;
- return priv->reg;
+ return priv->reg[reg];
}
static int mdio_sandbox_write(struct udevice *dev, int addr, int devad, int
reg,
@@ -45,10 +45,10 @@ static int mdio_sandbox_write(struct udevice *dev, int
addr, int devad, int reg,
return -ENODEV;
if (devad != MDIO_DEVAD_NONE)
return -ENODEV;
- if (reg != SANDBOX_PHY_REG)
+ if (reg < 0 || reg > SANDBOX_PHY_REG_CNT)
return -ENODEV;
- priv->reg = val;
+ priv->reg[reg] = val;
return 0;
}
@@ -56,8 +56,10 @@ static int mdio_sandbox_write(struct udevice *dev, int addr,
int devad, int reg,
static int mdio_sandbox_reset(struct udevice *dev)
{
struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+ int i;
- priv->reg = 0;
+ for (i = 0; i < SANDBOX_PHY_REG_CNT; i++)
+ priv->reg[i] = 0;
return 0;
}
diff --git a/test/dm/mdio.c b/test/dm/mdio.c
index 5b66255f7d..dc229aed6d 100644
--- a/test/dm/mdio.c
+++ b/test/dm/mdio.c
@@ -13,6 +13,9 @@
/* macros copied over from mdio_sandbox.c */
#define SANDBOX_PHY_ADDR 5
+#define SANDBOX_PHY_REG_CNT2
+
+/* test using 1st register, 0 */
#define SANDBOX_PHY_REG0
#define TEST_REG_VALUE 0xabcd
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 4/4] test: dm: add a test for MDIO MUX DM uclass
Adds a test using a makeshift MDIO MUX. The test is based on the existing
MDIO test. It uses the last emulated PHY register to verify MUX selection.
Signed-off-by: Alex Marginean
Acked-by: Joe Hershberger
Reviewed-by: Bin Meng
---
Changes in v2:
- no change
Changes in v3:
- no change, just fighting with the email server
Changes in v4:
- a more explicit comment on why relative ordering between mdio-test and
mdio-mux-test nodes in test.dts matters.
Changes in v5:
- no change
Changes in v6:
- no change
arch/Kconfig | 1 +
arch/sandbox/dts/test.dts | 23 +++-
drivers/net/Kconfig| 10
drivers/net/Makefile | 1 +
drivers/net/mdio_mux_sandbox.c | 97 ++
test/dm/Makefile | 1 +
test/dm/mdio_mux.c | 80
7 files changed, 212 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/mdio_mux_sandbox.c
create mode 100644 test/dm/mdio_mux.c
diff --git a/arch/Kconfig b/arch/Kconfig
index a6b2de8527..6dd0874d7c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -123,6 +123,7 @@ config SANDBOX
imply PCH
imply PHYLIB
imply DM_MDIO
+ imply DM_MDIO_MUX
config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dd50a951a8..a88cf75652 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -808,7 +808,28 @@
dma-names = "m2m", "tx0", "rx0";
};
- mdio-test {
+ /*
+* keep mdio-mux ahead of mdio so that the mux is removed first at the
+* end of the test. If parent mdio is removed first, clean-up of the
+* mux will trigger a 2nd probe of parent-mdio, leaving parent-mdio
+* active at the end of the test. That it turn doesn't allow the mdio
+* class to be destroyed, triggering an error.
+*/
+ mdio-mux-test {
+ compatible = "sandbox,mdio-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mdio-parent-bus = <&mdio>;
+
+ mdio-ch-test@0 {
+ reg = <0>;
+ };
+ mdio-ch-test@1 {
+ reg = <1>;
+ };
+ };
+
+ mdio: mdio-test {
compatible = "sandbox,mdio";
};
};
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f09f8c5f52..4d85fb1716 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -46,6 +46,16 @@ config MDIO_SANDBOX
This driver is used in for testing in test/dm/mdio.c
+config MDIO_MUX_SANDBOX
+ depends on DM_MDIO_MUX && MDIO_SANDBOX
+ default y
+ bool "Sandbox: Mocked MDIO-MUX driver"
+ help
+ This driver implements dummy select/deselect ops mimicking a MUX on
+ the MDIO bux. It uses mdio_sandbox driver as parent MDIO.
+
+ This driver is used for testing in test/dm/mdio.c
+
menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 1247b39a54..97119cec7c 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -79,3 +79,4 @@ obj-y += mscc_eswitch/
obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
+obj-$(CONFIG_MDIO_MUX_SANDBOX) += mdio_mux_sandbox.o
diff --git a/drivers/net/mdio_mux_sandbox.c b/drivers/net/mdio_mux_sandbox.c
new file mode 100644
index 00..3dba4d18a1
--- /dev/null
+++ b/drivers/net/mdio_mux_sandbox.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019
+ * Alex Marginean, NXP
+ */
+
+#include
+#include
+#include
+
+/* macros copied over from mdio_sandbox.c */
+#define SANDBOX_PHY_ADDR 5
+#define SANDBOX_PHY_REG_CNT2
+
+struct mdio_mux_sandbox_priv {
+ int enabled;
+ int sel;
+};
+
+static int mdio_mux_sandbox_mark_selection(struct udevice *dev, int sel)
+{
+ struct udevice *mdio;
+ struct mdio_ops *ops;
+ int err;
+
+ /*
+* find the sandbox parent mdio and write a register on the PHY there
+* so the mux test can verify selection.
+*/
+ err = uclass_get_device_by_name(UCLASS_MDIO, "mdio-test", &mdio);
+ if (err)
+ return err;
+ ops = mdio_get_ops(mdio);
+ return ops->write(mdio, SANDBOX_PHY_ADDR, MDIO_DEVAD_NONE,
+ SANDBOX_PHY_REG_CNT - 1, (u16)sel);
+}
+
+static int mdio_mux_sandbox_select(struct udevice *dev, int cur, int sel)
+{
+ struct mdio_mux_sandbox_priv *priv = dev_get_priv(dev);
+
+ if (!priv->enabled)
+ return -ENODEV;
+
+ if (cur != priv->sel)
+ return -EINVAL;
+
+ priv->sel = sel;
+ mdio_mux_sandbox_mark_selection(dev, priv->se
Re: [U-Boot] imx7d: CPU core issue in secure mode
Hi Peng, Am Freitag, 12. Juli 2019, 05:38:21 CEST schrieb Peng Fan: > Try "setenv bootm_boot_mode nonsec" in U-Boot stage. Unfortunately this does not help. I tried the following setups: CONFIG_SECURE_BOOT=y CONFIG_CPU_V7_HAS_NONSEC=y CONFIG_CPU_V7_HAS_VIRT=y CONFIG_ARCH_SUPPORT_PSCI=y CONFIG_ARMV7_NONSEC=y CONFIG_ARMV7_BOOT_SEC_DEFAULT=y CONFIG_ARMV7_VIRT=y CONFIG_ARMV7_PSCI=y CONFIG_ARMV7_PSCI_NR_CPUS=2 CONFIG_FSL_CAAM=y CONFIG_SYS_FSL_HAS_SEC=y CONFIG_SYS_FSL_SEC_COMPAT_4=y # CONFIG_SYS_FSL_SEC_BE is not set CONFIG_SYS_FSL_SEC_COMPAT=4 CONFIG_SYS_FSL_SEC_LE=y Booting with bootm_boot_mode=nonsec U-Boot 2019.07 (Jul 12 2019 - 10:02:31 +0200) CPU: Freescale i.MX7D rev1.3 1000 MHz (running at 792 MHz) .. SEC0: RNG instantiated .. [0.00] Booting Linux on physical CPU 0x0 [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] percpu: Embedded 16 pages/cpu s34380 r8192 d22964 u65536 [0.00] pcpu-alloc: s34380 r8192 d22964 u65536 alloc=16*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 .. [0.00] psci: probing for conduit method from DT. [0.00] psci: PSCIv1.0 detected in firmware. [0.00] psci: Using standard PSCI v0.2 function IDs [0.00] psci: Trusted OS migration not required [0.00] psci: SMC Calling Convention v1.0 .. [0.002872] CPU: Testing write buffer coherency: ok [0.003224] CPU0: update cpu_capacity 1024 [0.003234] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.004687] smp: Bringing up secondary CPUs ... [0.005424] CPU1: update cpu_capacity 1024 [0.005432] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.005553] smp: Brought up 1 node, 2 CPUs [0.005568] CPU: All CPU(s) started in HYP mode. [0.005571] CPU: Virtualization extensions available. .. [0.185229] caam 3090.caam: device ID = 0x0a160300 (Era 8) [0.185240] caam 3090.caam: job rings = 3, qi = 0 [0.186894] caam_jr 30901000.jr0: failed to flush job ring 0 [0.192721] caam_jr: probe of 30901000.jr0 failed with error -5 [0.192846] caam_jr 30902000.jr1: failed to flush job ring 1 [0.198796] caam_jr: probe of 30902000.jr1 failed with error -5 [0.198989] caam_jr 30903000.jr1: failed to flush job ring 2 [0.204957] caam_jr: probe of 30903000.jr1 failed with error -5 [0.212619] Job Ring Device allocation for transform failed Same configuration with setenv bootm_boot_mode=sec [0.00] Booting Linux on physical CPU 0x0 [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] percpu: Embedded 16 pages/cpu s34380 r8192 d22964 u65536 [0.00] pcpu-alloc: s34380 r8192 d22964 u65536 alloc=16*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.002866] CPU: Testing write buffer coherency: ok [0.003217] CPU0: update cpu_capacity 1024 [0.003226] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.004673] smp: Bringing up secondary CPUs ... [0.005174] smp: Brought up 1 node, 1 CPU [0.005188] CPU: All CPU(s) started in SVC mode. .. [0.185631] caam 3090.caam: device ID = 0x0a160300 (Era 8) [0.185643] caam 3090.caam: job rings = 3, qi = 0 [0.196909] caam algorithms registered in /proc/crypto [0.199620] caam_jr 30901000.jr0: registering rng-caam => only 1 CPU core up. Now I tried to disable the CAAM driver and secure boot support in U-Boot # CONFIG_SECURE_BOOT is not set CONFIG_CPU_V7_HAS_NONSEC=y CONFIG_CPU_V7_HAS_VIRT=y CONFIG_ARCH_SUPPORT_PSCI=y CONFIG_ARMV7_NONSEC=y CONFIG_ARMV7_BOOT_SEC_DEFAULT=y CONFIG_ARMV7_VIRT=y CONFIG_ARMV7_PSCI=y CONFIG_ARMV7_PSCI_NR_CPUS=2 # CONFIG_FSL_CAAM is not set CONFIG_SYS_FSL_SEC_COMPAT_4=y # CONFIG_SYS_FSL_SEC_BE is not set CONFIG_SYS_FSL_SEC_LE=y and booting with bootm_boot_mode=nonsec [0.185233] caam 3090.caam: Entropy delay = 3200 [0.212342] caam 3090.caam: failed to acquire DECO 0 [0.217689] caam 3090.caam: failed to instantiate RNG => both CPU cores are up in nonsec mode Am I missing something? Thank you and best regards Tobias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 7/9] riscv: sifive: fu540: Setup ethaddr env variable using OTP
On Thu, Jul 11, 2019 at 3:49 PM Ramon Fried wrote:
>
>
>
> On July 11, 2019 7:28:59 AM GMT+03:00, Anup Patel wrote:
> >
> >
> >> -Original Message-
> >> From: Troy Benjegerdes
> >> Sent: Wednesday, July 10, 2019 10:45 PM
> >> To: Anup Patel ; Sagar Karandikar
> >> ; Joey Hewitt
> >> Cc: Rick Chen ; Bin Meng ;
> >> Lukas Auer ; Simon Glass
> >> ; Ramon Fried ; Joe
> >> Hershberger ; Palmer Dabbelt
> >> ; Paul Walmsley ; Atish
> >> Patra ; Alistair Francis
> >;
> >> U-Boot Mailing List
> >> Subject: Re: [PATCH v7 7/9] riscv: sifive: fu540: Setup ethaddr env
> >variable
> >> using OTP
> >>
> >>
> >>
> >> > On Jun 23, 2019, at 11:03 PM, Anup Patel
> >wrote:
> >> >
> >> > This patch extends SiFive FU540 board support to setup ethaddr env
> >> > variable based on board serialnum read from OTP.
> >> >
> >> > Signed-off-by: Anup Patel
> >> > ---
> >> > board/sifive/fu540/fu540.c | 122
> >> +
> >> > configs/sifive_fu540_defconfig | 1 +
> >> > 2 files changed, 123 insertions(+)
> >> >
> >> > diff --git a/board/sifive/fu540/fu540.c
> >b/board/sifive/fu540/fu540.c
> >> > index 5adc4a3d4a..11daf1a75a 100644
> >> > --- a/board/sifive/fu540/fu540.c
> >> > +++ b/board/sifive/fu540/fu540.c
> >> > @@ -8,6 +8,128 @@
> >> >
> >> > #include
> >> > #include
> >> > +#include
> >> > +#include
> >> > +
> >> > +#ifdef CONFIG_MISC_INIT_R
> >> > +
> >> > +#define FU540_OTP_BASE_ADDR 0x1007
> >> > +
> >> > +struct fu540_otp_regs {
> >> > + u32 pa; /* Address input */
> >> > + u32 paio; /* Program address input */
> >> > + u32 pas;/* Program redundancy cell selection input */
> >> > + u32 pce;/* OTP Macro enable input */
> >> > + u32 pclk; /* Clock input */
> >> > + u32 pdin; /* Write data input */
> >> > + u32 pdout; /* Read data output */
> >> > + u32 pdstb; /* Deep standby mode enable input (active low) */
> >> > + u32 pprog; /* Program mode enable input */
> >> > + u32 ptc;/* Test column enable input */
> >> > + u32 ptm;/* Test mode enable input */
> >> > + u32 ptm_rep;/* Repair function test mode enable input */
> >> > + u32 ptr;/* Test row enable input */
> >> > + u32 ptrim; /* Repair function enable input */
> >> > + u32 pwe;/* Write enable input (defines program cycle) */
> >> > +} __packed;
> >> > +
> >> > +#define BYTES_PER_FUSE4
> >> > +#define NUM_FUSES 0x1000
> >> > +
> >> > +static int fu540_otp_read(int offset, void *buf, int size) {
> >> > + struct fu540_otp_regs *regs = (void __iomem
> >> *)FU540_OTP_BASE_ADDR;
> >> > + unsigned int i;
> >> > + int fuseidx = offset / BYTES_PER_FUSE;
> >> > + int fusecount = size / BYTES_PER_FUSE;
> >> > + u32 fusebuf[fusecount];
> >> > +
> >> > + /* check bounds */
> >> > + if (offset < 0 || size < 0)
> >> > + return -EINVAL;
> >> > + if (fuseidx >= NUM_FUSES)
> >> > + return -EINVAL;
> >> > + if ((fuseidx + fusecount) > NUM_FUSES)
> >> > + return -EINVAL;
> >> > +
> >> > + /* init OTP */
> >> > + writel(0x01, ®s->pdstb); /* wake up from stand-by */
> >> > + writel(0x01, ®s->ptrim); /* enable repair function */
> >> > + writel(0x01, ®s->pce); /* enable input */
> >> > +
> >> > + /* read all requested fuses */
> >> > + for (i = 0; i < fusecount; i++, fuseidx++) {
> >> > + writel(fuseidx, ®s->pa);
> >> > +
> >> > + /* cycle clock to read */
> >> > + writel(0x01, ®s->pclk);
> >> > + mdelay(1);
> >> > + writel(0x00, ®s->pclk);
> >> > + mdelay(1);
> >> > +
> >> > + /* read the value */
> >> > + fusebuf[i] = readl(®s->pdout);
> >> > + }
> >> > +
> >> > + /* shut down */
> >> > + writel(0, ®s->pce);
> >> > + writel(0, ®s->ptrim);
> >> > + writel(0, ®s->pdstb);
> >> > +
> >> > + /* copy out */
> >> > + memcpy(buf, fusebuf, size);
> >> > +
> >> > + return 0;
> >> > +}
> >> > +
> >> > +static u32 fu540_read_serialnum(void) {
> >> > + int ret;
> >> > + u32 serial[2] = {0};
> >> > +
> >> > + for (int i = 0xfe * 4; i > 0; i -= 8) {
> >> > + ret = fu540_otp_read(i, serial, sizeof(serial));
> >> > + if (ret) {
> >> > + printf("%s: error reading from OTP\n", __func__);
> >> > + break;
> >> > + }
> >> > + if (serial[0] == ~serial[1])
> >> > + return serial[0];
> >> > + }
> >> > +
> >> > + return 0;
> >> > +}
> >>
> >> Please take a look at the DM-enabled SiFive OTP driver submitted by
> >Joey
> >> Hewitt at https://github.com/sifive/HiFive_U-
> >> Boot/commit/6d842765de142b61f847852da7a9ce0d081d770c
> >>
> >> This Joey's version also sets the ‘serial#’ environment variable,
> >while this
> >> patch only sets ‘ethaddr'
> >
> >I am not sure if "serial#" environment variable is a standard U-Boot
> >way of advertising serial number of underlying Host.
> it's standard.
> >
> >Where is this used?
> looks at fast
Re: [U-Boot] [PATCH 19/20] psci: Fix warnings when compiling with W=1
Hi,
> From: Patrick DELAUNAY
> Sent: vendredi 21 juin 2019 15:27
>
> This patch solves the following warnings:
> arch/arm/mach-stm32mp/psci.c:
>
> warning: no previous prototype for ‘psci_set_state’ [-Wmissing-prototypes]
> warning: no previous prototype for ‘psci_arch_cpu_entry’
> [-Wmissing-prototypes]
> warning: no previous prototype for ‘psci_features’ [-Wmissing-prototypes]
> warning: no previous prototype for ‘psci_version’ [-Wmissing-prototypes]
> warning: no previous prototype for ‘psci_affinity_info’ [-Wmissing-prototypes]
> warning: no previous prototype for ‘psci_migrate_info_type’ [-Wmissing-
> prototypes]
> warning: no previous prototype for ‘psci_cpu_on’ [-Wmissing-prototypes]
> warning: no previous prototype for ‘psci_cpu_off’ [-Wmissing-prototypes]
> warning: no previous prototype for ‘psci_system_reset’ [-Wmissing-prototypes]
> warning: no previous prototype for ‘psci_system_off’ [-Wmissing-prototypes]
>
> Signed-off-by: Patrick Delaunay
After rebase this patch cause compilation issue with sunci platform: it need to
be updated
+arch/arm/cpu/armv7/sunxi/psci.c:279:15: error: conflicting types for
'psci_cpu_off'
> ---
>
> arch/arm/include/asm/system.h | 14 ++
> arch/arm/mach-imx/mx7/psci-mx7.c| 2 +-
> arch/arm/mach-stm32mp/psci.c| 18 +-
> arch/arm/mach-uniphier/arm32/psci.c | 4 ++--
> 4 files changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index
> aed2e3c..ac4fc11 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -516,6 +516,20 @@ enum {
> */
> void mmu_page_table_flush(unsigned long start, unsigned long stop);
>
> +#ifdef CONFIG_ARMV7_PSCI
> +u32 psci_version(void);
> +s32 psci_features(u32 function_id, u32 psci_fid);
> +s32 psci_cpu_off(void);
> +s32 psci_cpu_on(u32 function_id, u32 target_cpu, u32 pc,
> + u32 context_id);
> +s32 psci_affinity_info(u32 function_id, u32 target_affinity,
> +u32 lowest_affinity_level);
> +u32 psci_migrate_info_type(void);
> +void __noreturn psci_system_off(void);
> +void __noreturn psci_system_reset(void);
> +s32 psci_features(u32 function_id, u32 psci_fid); #endif
> +
> #endif /* __ASSEMBLY__ */
>
> #define arch_align_stack(x) (x)
> diff --git a/arch/arm/mach-imx/mx7/psci-mx7.c b/arch/arm/mach-imx/mx7/psci-
> mx7.c
> index 34ba0a9..c98d2e9 100644
> --- a/arch/arm/mach-imx/mx7/psci-mx7.c
> +++ b/arch/arm/mach-imx/mx7/psci-mx7.c
> @@ -298,7 +298,7 @@ __secure s32 psci_affinity_info(u32 __always_unused
> function_id,
> return psci_state[cpu];
> }
>
> -__secure s32 psci_migrate_info_type(u32 function_id)
> +__secure u32 psci_migrate_info_type(void)
> {
> /* Trusted OS is either not present or does not require migration */
> return 2;
> diff --git a/arch/arm/mach-stm32mp/psci.c b/arch/arm/mach-stm32mp/psci.c
> index 139bb09..1d91b2d 100644
> --- a/arch/arm/mach-stm32mp/psci.c
> +++ b/arch/arm/mach-stm32mp/psci.c
> @@ -30,7 +30,7 @@ u8 psci_state[STM32MP1_PSCI_NR_CPUS] __secure_data
> = {
>PSCI_AFFINITY_LEVEL_ON,
>PSCI_AFFINITY_LEVEL_OFF};
>
> -void __secure psci_set_state(int cpu, u8 state)
> +static inline void psci_set_state(int cpu, u8 state)
> {
> psci_state[cpu] = state;
> dsb();
> @@ -67,7 +67,7 @@ void __secure psci_arch_cpu_entry(void)
> writel(0x, TAMP_BACKUP_MAGIC_NUMBER); }
>
> -int __secure psci_features(u32 function_id, u32 psci_fid)
> +s32 __secure psci_features(u32 function_id, u32 psci_fid)
> {
> switch (psci_fid) {
> case ARM_PSCI_0_2_FN_PSCI_VERSION:
> @@ -82,12 +82,12 @@ int __secure psci_features(u32 function_id, u32 psci_fid)
> return ARM_PSCI_RET_NI;
> }
>
> -unsigned int __secure psci_version(u32 function_id)
> +u32 __secure psci_version(void)
> {
> return ARM_PSCI_VER_1_0;
> }
>
> -int __secure psci_affinity_info(u32 function_id, u32 target_affinity,
> +s32 __secure psci_affinity_info(u32 function_id, u32 target_affinity,
> u32 lowest_affinity_level)
> {
> u32 cpu = target_affinity & MPIDR_AFF0; @@ -104,7 +104,7 @@ int
> __secure psci_affinity_info(u32 function_id, u32 target_affinity,
> return psci_state[cpu];
> }
>
> -int __secure psci_migrate_info_type(u32 function_id)
> +u32 __secure psci_migrate_info_type(void)
> {
> /*
>* in Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
> @@ -116,7 +116,7 @@ int __secure psci_migrate_info_type(u32 function_id)
> return 2;
> }
>
> -int __secure psci_cpu_on(u32 function_id, u32 target_cpu, u32 pc,
> +s32 __secure psci_cpu_on(u32 function_id, u32 target_cpu, u32 pc,
>u32 context_id)
> {
> u32 cpu = target_cpu & MPIDR_AFF0;
> @@ -161,7 +161,7 @@ int __secure psci_cpu_on(u32 function_id, u32
> target_cpu, u32 pc,
> return ARM_PSCI_RET_SUCCESS;
> }
>
> -int __secure psci_cpu_
Re: [U-Boot] [PATCH v4 0/4] Add 'bcb' command to read/modify/write Android BCB
Hi Sam,
On Tue, Jul 09, 2019 at 03:20:01PM +0300, Sam Protsenko wrote:
> Tom, Simon,
>
> Can we please handle this series and apply it to master? A lot of
> Android-related patches depend on this, so if all comments are
> addressed in v4 and there are no further concerns, it would be great
> to have it merged ASAP so we can handle more patches while merge
> window is still open.
>
> Thanks!
Due to whatever reason, v3 has been pushed to master instead of v4:
https://gitlab.denx.de/u-boot/u-boot/commit/0381b713d1c3 ("include:
android_bootloader_message.h: Minimize the diff to AOSP")
https://gitlab.denx.de/u-boot/u-boot/commit/db7b7a05b267 ("cmd: Add 'bcb'
command to read/modify/write BCB fields")
https://gitlab.denx.de/u-boot/u-boot/commit/9bdf0e8fef86 ("doc: relocate/rename
Android README and add BCB overview")
I will submit the v3-to-v4 diff in a separate patch.
I hope we can avoid unnecessary work like this in future.
--
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] watchdog: omap_wdt: Disable DM watchdog support in SPL
From: Suniel Mahesh
This patch disables DM watchdog support for SPL builds and uses
the legacy omap watchdog on TI AM335x chipsets.
The following build error is reported if DM watchdog support was enabled in SPL:
CC spl/drivers/usb/gadget/rndis.o
LD spl/drivers/usb/gadget/built-in.o
LD spl/drivers/usb/musb-new/built-in.o
LD spl/drivers/built-in.o
LD spl/u-boot-spl
arm-linux-ld.bfd: u-boot-spl section .u_boot_list will not fit in region .sram
arm-linux-ld.bfd: region .sram overflowed by 440 bytes
make[1]: *** [spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl] Error 2
Tested on BeagleboneBlack board.
Signed-off-by: Suniel Mahesh
---
Notes:
- CONFIG_WATCHDOG replaces CONFIG_HW_WATCHDOG, earlier WATCHDOG_RESET
macro used to point to hw_watchdog_reset() in include/watchdog.h.
Now since we use CONFIG_WATCHDOG, here WATCHDOG_RESET macro points to
watchdog_reset(). This watchdog_reset() is not defined anywhere and needs
to be defined. Fixed this by simply calling hw_watchdog_reset() in
watchdog_reset() (driver/watchdog/omap_wdt.c). Hope this is ok
- CONFIG_SPL_DM is disabled in board defconfig file. Hope this
is ok
- there are 13 boards I think which are using AM335X SOC. All
these board defconfig files to be changed if this gets accepted
to follow DM/DT WDT in u-boot and non DM/DT in spl.
- This patch series is heavily dependant on:
https://patchwork.ozlabs.org/patch/1112591/
waiting for it to get applied.
---
arch/arm/mach-omap2/boot-common.c | 2 +-
configs/am335x_evm_defconfig | 1 +
drivers/watchdog/omap_wdt.c | 7 +++
include/watchdog.h| 2 +-
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/boot-common.c
b/arch/arm/mach-omap2/boot-common.c
index c8b8ac6..c9549aa 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -208,7 +208,7 @@ void spl_board_init(void)
#if defined(CONFIG_AM33XX) && defined(CONFIG_SPL_MUSB_NEW_SUPPORT)
arch_misc_init();
#endif
-#if defined(CONFIG_HW_WATCHDOG)
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
hw_watchdog_init();
#endif
#ifdef CONFIG_AM33XX
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index fa6b030..c0f7ccc 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -60,6 +60,7 @@ CONFIG_TIMER=y
CONFIG_OMAP_TIMER=y
CONFIG_WDT=y
CONFIG_WDT_OMAP3=y
+# CONFIG_SPL_WDT is not set
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_DM_USB_GADGET=y
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 86f7cf1..d5857be 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -138,7 +138,14 @@ void hw_watchdog_init(void)
while ((readl(&wdt->wdtwwps)) & WDT_WWPS_PEND_WSPR)
;
}
+
+void watchdog_reset(void)
+{
+ hw_watchdog_reset();
+}
+
#else
+
static int omap3_wdt_reset(struct udevice *dev)
{
struct omap3_wdt_priv *priv = dev_get_priv(dev);
diff --git a/include/watchdog.h b/include/watchdog.h
index 3a357de..41c9aa7 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -77,7 +77,7 @@ int init_func_watchdog_reset(void);
* Prototypes from $(CPU)/cpu.c.
*/
-#if defined(CONFIG_HW_WATCHDOG) && !defined(__ASSEMBLY__)
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) &&
!defined(__ASSEMBLY__)
void hw_watchdog_init(void);
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] watchdog: omap_wdt: Convert watchdog driver to use DT and DM
From: Suniel Mahesh
This patch adds device tree and driver model watchdog support,
converts the legacy omap watchdog driver to driver model for
TI AM335x chipsets. The following compile warning is removed:
= WARNING ==
This board does not use CONFIG_WDT (DM watchdog support).
Please update the board to use CONFIG_WDT before the
v2019.10 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.
DM watchdog support if enabled in SPL, spl image doesn't fit into
SRAM because of size constraints and build breaks with an overflow.
For this reason DM watchdog support should be disabled in SPL. The
driver code should be adjusted accordingly to serve this purpose.
Tested on BeagleboneBlack board.
Signed-off-by: Suniel Mahesh
---
Notes:
- DM watchdog support if enabled in SPL, spl image doesn't
fit into SRAM because of size constraints.
- Disabling DM watchdog support in SPL, another patch follows.
- This patch series is heavily dependant on:
https://patchwork.ozlabs.org/patch/1112591/
waiting for it to get applied.
---
arch/arm/include/asm/ti-common/omap_wdt.h | 5 ++
configs/am335x_evm_defconfig | 2 +
drivers/watchdog/Kconfig | 10 ++-
drivers/watchdog/Makefile | 1 +
drivers/watchdog/omap_wdt.c | 114 ++
5 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/ti-common/omap_wdt.h
b/arch/arm/include/asm/ti-common/omap_wdt.h
index 7d72e3a..fbc421b 100644
--- a/arch/arm/include/asm/ti-common/omap_wdt.h
+++ b/arch/arm/include/asm/ti-common/omap_wdt.h
@@ -56,4 +56,9 @@ struct wd_timer {
unsigned int wdt_unfr; /* offset 0x100 */
};
+struct omap3_wdt_priv {
+ struct wd_timer *regs;
+ unsigned int wdt_trgr_pattern;
+};
+
#endif /* __OMAP_WDT_H__ */
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index ff96f19..fa6b030 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -58,6 +58,8 @@ CONFIG_DM_SPI=y
CONFIG_OMAP3_SPI=y
CONFIG_TIMER=y
CONFIG_OMAP_TIMER=y
+CONFIG_WDT=y
+CONFIG_WDT_OMAP3=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_DM_USB_GADGET=y
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e5a7bb3..93ebc47 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -37,7 +37,7 @@ config OMAP_WATCHDOG
bool "TI OMAP watchdog driver"
depends on ARCH_OMAP2PLUS
select HW_WATCHDOG
- default y if AM33XX
+ default y if !AM33XX
help
Say Y here to enable the OMAP3+ watchdog driver.
@@ -122,6 +122,14 @@ config WDT_MTK
The watchdog timer is stopped when initialized.
It performs full SoC reset.
+config WDT_OMAP3
+bool "TI OMAP watchdog timer support"
+depends on WDT && ARCH_OMAP2PLUS
+default y if AM33XX
+help
+ This enables OMAP3+ watchdog timer driver, which can be
+ found on some TI chipsets and inline with driver model.
+
config WDT_ORION
bool "Orion watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 97aa6a8..c40667a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
+obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 343adb0..86f7cf1 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -42,10 +42,14 @@
#include
#include
#include
+#include
+#include
+#include
/* Hardware timeout in seconds */
#define WDT_HW_TIMEOUT 60
+#if !CONFIG_IS_ENABLED(WDT)
static unsigned int wdt_trgr_pattern = 0x1234;
void hw_watchdog_reset(void)
@@ -134,3 +138,113 @@ void hw_watchdog_init(void)
while ((readl(&wdt->wdtwwps)) & WDT_WWPS_PEND_WSPR)
;
}
+#else
+static int omap3_wdt_reset(struct udevice *dev)
+{
+ struct omap3_wdt_priv *priv = dev_get_priv(dev);
+
+ priv->wdt_trgr_pattern = 0x1234;
+/*
+ * Somebody just triggered watchdog reset and write to WTGR register
+ * is in progress. It is resetting right now, no need to trigger it
+ * again
+ */
+ if ((readl(&priv->regs->wdtwwps)) & WDT_WWPS_PEND_WTGR)
+ return 0;
+
+ priv->wdt_trgr_pattern = ~(priv->wdt_trgr_pattern);
+ writel(priv->wdt_trgr_pattern, &priv->regs->wdtwtgr);
+/*
+ * Don't wait for posted write to complete, i.e. don't check
+ * WDT_WWPS_PEND_WTGR bit in WWPS register. There is no writes to
+ * W
Re: [U-Boot] [PATCH v5 1/1] cmd: part: Add 'number' sub-command
Hi Tom,
On Fri, Jun 14, 2019 at 5:22 PM Sam Protsenko
wrote:
>
> Hi Igor,
>
> Once again:
>
> Reviewed-by: Sam Protsenko
>
> Thanks!
>
> On Fri, Jun 14, 2019 at 5:01 PM Igor Opaniuk wrote:
> >
> > From: Ruslan Trofymenko
> >
> > This sub-command serves for getting the partition index from
> > partition name. Also it can be used to test the existence of specified
> > partition.
> >
> > Use case:
> > For example, in most CI environments this U-Boot command for automatic
> > testing of Linux rootfs is used:
> >
> > => setenv bootpart 1:f
> >
> > where 0xf is "userdata" partition. But the number of "userdata"
> > partition can be changed any time, when partition table is changed.
> >
> > So it would be nice to get rid of that 0xf magic number and use
> > partition name instead, like this:
> >
> > => part number mmc 1 userdata part_num
> > => setenv bootpart 1:${part_num}
> >
> > Signed-off-by: Ruslan Trofymenko
> > Signed-off-by: Igor Opaniuk
> > Reviewed-by: Alistair Strachan
> > Reviewed-by: Sam Protsenko
> > Reviewed-by: Simon Glass
> > ---
> >
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> > cmd/part.c | 16 +++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/part.c b/cmd/part.c
> > index bfb6488b0f..653e13ced1 100644
> > --- a/cmd/part.c
> > +++ b/cmd/part.c
> > @@ -24,6 +24,7 @@
> > enum cmd_part_info {
> > CMD_PART_INFO_START = 0,
> > CMD_PART_INFO_SIZE,
> > + CMD_PART_INFO_NUMBER
> > };
> >
> > static int do_part_uuid(int argc, char * const argv[])
> > @@ -149,6 +150,9 @@ static int do_part_info(int argc, char * const argv[],
> > enum cmd_part_info param)
> > case CMD_PART_INFO_SIZE:
> > snprintf(buf, sizeof(buf), LBAF, info.size);
> > break;
> > + case CMD_PART_INFO_NUMBER:
> > + snprintf(buf, sizeof(buf), "%d", part);
> > + break;
> > default:
> > printf("** Unknown cmd_part_info value: %d\n", param);
> > return 1;
> > @@ -172,6 +176,11 @@ static int do_part_size(int argc, char * const argv[])
> > return do_part_info(argc, argv, CMD_PART_INFO_SIZE);
> > }
> >
> > +static int do_part_number(int argc, char * const argv[])
> > +{
> > + return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
> > +}
> > +
> > static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> > argv[])
> > {
> > if (argc < 2)
> > @@ -185,6 +194,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int
> > argc, char * const argv[])
> > return do_part_start(argc - 2, argv + 2);
> > else if (!strcmp(argv[1], "size"))
> > return do_part_size(argc - 2, argv + 2);
> > + else if (!strcmp(argv[1], "number"))
> > + return do_part_number(argc - 2, argv + 2);
> >
> > return CMD_RET_USAGE;
> > }
> > @@ -206,5 +217,8 @@ U_BOOT_CMD(
> > " part can be either partition number or partition name\n"
> > "part size\n"
> > "- set environment variable to the size of the partition (in
> > blocks)\n"
> > - " part can be either partition number or partition name"
> > + " part can be either partition number or partition name\n"
> > + "part number\n"
> > + "- set environment variable to the partition number using the
> > partition name\n"
> > + " part must be specified as partition name"
> > );
> > --
> > 2.17.1
> >
Are there any objections from your side to get this patch applied?
If there are any comments/suggestions, please let me know!
Thanks!
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] imx8: Jump from alias to OCRAM address at SPL init
When running SPL on iMX8, the A core starts at address 0 which is a alias to OCRAM 0x10. The alias only map first 96KB of OCRAM, so this require the SPL size can't beyond 96KB. But when using SPL DM, the size increase significantly and may exceed 96KB. So to fix the problem, we will change SPL linker address to OCRAM address 0x10. And then jump to the absolute address not the PC relative address for entering OCRAM. Signed-off-by: Ye Li --- arch/arm/Kconfig | 1 + arch/arm/include/asm/arch-imx8/boot0.h | 21 + 2 files changed, 22 insertions(+) create mode 100644 arch/arm/include/asm/arch-imx8/boot0.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 01ff57c..6ea21b7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -755,6 +755,7 @@ config ARCH_IMX8 select ARM64 select DM select OF_CONTROL + select ENABLE_ARM_SOC_BOOT0_HOOK config ARCH_IMX8M bool "NXP i.MX8M platform" diff --git a/arch/arm/include/asm/arch-imx8/boot0.h b/arch/arm/include/asm/arch-imx8/boot0.h new file mode 100644 index 000..5ce781a --- /dev/null +++ b/arch/arm/include/asm/arch-imx8/boot0.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2019 NXP + */ + +#if defined(CONFIG_SPL_BUILD) + /* +* We use absolute address not PC relative address to jump. +* When running SPL on iMX8, the A core starts at address 0, a alias to OCRAM 0x10, +* our linker address for SPL is from 0x10. So using absolute address can jump to +* the OCRAM address from the alias. +* The alias only map first 96KB of OCRAM, so this require the SPL size can't beyond 96KB. +* But when using SPL DM, the size increase significantly and may exceed 96KB. +* That's why we have to jump to OCRAM. +*/ + + ldr x0, =reset + br x0 +#else + b reset +#endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] imx8qm/qxp: Set SPL TEXT base to OCRAM base
Modify the SPL TEXT base from OCRAM alias to OCRAM base 0x10, so we can use full OCRAM not limit to 96KB Signed-off-by: Ye Li --- configs/imx8qm_mek_defconfig | 1 + configs/imx8qxp_mek_defconfig | 1 + include/configs/imx8qm_mek.h | 1 - 3 files changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/imx8qm_mek_defconfig b/configs/imx8qm_mek_defconfig index a4d2619..544a5d9 100644 --- a/configs/imx8qm_mek_defconfig +++ b/configs/imx8qm_mek_defconfig @@ -3,6 +3,7 @@ CONFIG_SPL_SYS_ICACHE_OFF=y CONFIG_SPL_SYS_DCACHE_OFF=y CONFIG_ARCH_IMX8=y CONFIG_SYS_TEXT_BASE=0x8002 +CONFIG_SPL_TEXT_BASE=0x10 CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig index 92927e3..73d6d13 100644 --- a/configs/imx8qxp_mek_defconfig +++ b/configs/imx8qxp_mek_defconfig @@ -3,6 +3,7 @@ CONFIG_SPL_SYS_ICACHE_OFF=y CONFIG_SPL_SYS_DCACHE_OFF=y CONFIG_ARCH_IMX8=y CONFIG_SYS_TEXT_BASE=0x8002 +CONFIG_SPL_TEXT_BASE=0x10 CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y diff --git a/include/configs/imx8qm_mek.h b/include/configs/imx8qm_mek.h index d06ed61..148a4ff 100644 --- a/include/configs/imx8qm_mek.h +++ b/include/configs/imx8qm_mek.h @@ -10,7 +10,6 @@ #include #ifdef CONFIG_SPL_BUILD -#define CONFIG_SPL_TEXT_BASE 0x0 #define CONFIG_SPL_MAX_SIZE(124 * 1024) #define CONFIG_SYS_MONITOR_LEN (1024 * 1024) #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] env: ti: Increase boot partition
Hi Sam
On Tue, Jul 2, 2019 at 8:56 PM Sam Protsenko wrote:
>
> linux-mainline with multi_v7_defconfig + Android configs takes more
> space than regular TI Android kernel. Let's increase boot partition
> twice, so that boot_fit.img (with new zImage in it) can fit into "boot"
> partition.
>
> Signed-off-by: Sam Protsenko
> ---
> include/environment/ti/boot.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
> index 05bdbbc23e..a6b245b1c7 100644
> --- a/include/environment/ti/boot.h
> +++ b/include/environment/ti/boot.h
> @@ -38,7 +38,7 @@
> "name=uboot-env,start=2432K,size=256K,uuid=${uuid_gpt_reserved};" \
> "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
> "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
> - "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
> + "name=boot,size=20M,uuid=${uuid_gpt_boot};" \
> "name=system,size=1024M,uuid=${uuid_gpt_system};" \
> "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
> VBMETA_PART \
> --
> 2.20.1
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: am57xx: Allow bootm to load larger kernels
Hi Sam, On Tue, Jul 2, 2019 at 8:56 PM Sam Protsenko wrote: > > linux-mainline with multi_v7_defconfig + Android configs takes more > space than regular TI Android kernel and bootm will fail to load it. > Let's increase max kernel size up to 64 MiB to make it possible to run > such kernel. > > Signed-off-by: Sam Protsenko > --- > include/configs/am57xx_evm.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h > index 2c651aab17..9a39cd6351 100644 > --- a/include/configs/am57xx_evm.h > +++ b/include/configs/am57xx_evm.h > @@ -24,6 +24,8 @@ > #define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) > #define CONFIG_SYS_REDUNDAND_ENVIRONMENT > > +#define CONFIG_SYS_BOOTM_LEN SZ_64M > + > #define CONSOLEDEV "ttyO2" > #define CONFIG_SYS_NS16550_COM1UART1_BASE /* Base EVM > has UART0 */ > #define CONFIG_SYS_NS16550_COM2UART2_BASE /* UART2 */ > -- > 2.20.1 > Reviewed-by: Igor Opaniuk -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB
Hi, On Mon 27 May 19, 00:50, André Przywara wrote: > On 17/04/2019 12:28, Jagan Teki wrote: > > On Mon, Apr 15, 2019 at 1:52 PM Paul Kocialkowski > > wrote: > > Hi, > > >> Le vendredi 12 avril 2019 à 14:49 +0530, Jagan Teki a écrit : > >>> On Thu, Mar 14, 2019 at 4:08 PM Paul Kocialkowski > >>> wrote: > Recent Allwinner platforms (starting with the H3) only use the MUSB > controller for peripheral mode and use HCI for host mode. As a result, > extra steps need to be taken to properly route USB signals to one or > the other. More precisely, the following is required: > * Routing the pins to either HCI/MUSB (controlled by PHY); > * Enabling USB PHY passby in HCI mode (controlled by PMU). > > The current code will enable passby for each PHY and reroute PHY0 to > MUSB, which is inconsistent and results in broken USB peripheral support. > > Passby on PHY0 must only be enabled when we want to use HCI. Since > host/device mode detection is not available from the PHY code and > because U-Boot does not support changing the mode dynamically anyway, > we can just mux the controller to MUSB if it is enabled and mux it to > HCI otherwise. > > This fixes USB peripheral support for platforms with PHY0 dual-route, > especially H3/H5 and V3s. > > Signed-off-by: Paul Kocialkowski > --- > drivers/phy/allwinner/phy-sun4i-usb.c | 14 +- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c > b/drivers/phy/allwinner/phy-sun4i-usb.c > index f206fa3f5d48..4f1c7e519d71 100644 > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > @@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy) > data->cfg->disc_thresh, > PHY_DISCON_TH_LEN); > } > > +#ifdef CONFIG_USB_MUSB_SUNXI > + /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB */ > + if (usb_phy->id != 0) > + sun4i_usb_phy_passby(phy, true); > + > + /* Route PHY0 to MUSB to allow USB gadget */ > + if (data->cfg->phy0_dual_route) > + sun4i_usb_phy0_reroute(data, true); > +#else > sun4i_usb_phy_passby(phy, true); > > - sun4i_usb_phy0_reroute(data, true); > + /* Route PHY0 to HCI to allow USB host */ > + if (data->cfg->phy0_dual_route) > + sun4i_usb_phy0_reroute(data, false); > +#endif > >>> > >>> I think we can manage this route and passby dynamically by detecting > >>> id since we have dr_mode verify the MUSB host or peripheral via > >>> usb_get_dr_mode, any chance to try that way? > >> > >> Oh, I didn't know that U-Boot has support for usb_get_dr_mode these > >> days. Thanks! > >> > >> So far, the sunxi port has been using Kconfig to distinguish between > >> host/device (unless I'm mistaken?) so I feel like this should be a > >> separate follow-up patch to convert the sunxi MUSB glue + PHY to > >> detecting dr_mode using usb_get_dr_mode. This feels like a significant > >> rework, too. > > > > Yes. > > > >> > >> Also, how should we handle the OTG case? I'm not sure we can support > >> having both musb host and gadget built-in at this point. But that would > >> certainly be welcome as part of the rework, too. > >> > >> What do you think? > > > > You mean handling dr_mode at runtime. > > > > If yes, It is bit new where we can register the musb as UCLASS_MISC > > wrapper and decide to bind driver for host and peripheral by decoding > > dr_mode. and indeed host should register with UCLASS_USB and > > peripheral with UCLASS_USB_GADGET_GENERIC. > > > > I tried this wrapper before, not placed in-between because of other > > work but TI musb has similar code to manage this > > drivers/usb/musb-new/ti-musb.c > > Before we go wild with any fancy rework, can we possibly take this patch > as it? As I realised, this is basically a better version of the patch I > sent two weeks ago [1]. I tried Paul's patch back then, but was missing > the phys property in the DT, which I addressed in patch 2/2. > > So I would appreciate if we can take this patch, as it solves a real > problem (upper USB port not working) on many Pine64 boards (given the > small DT change is in place). And on those boards the OTG functionality > is not really feasible anyway, as VBUS is either permanently enabled or > at least tied to the other host port's supply, so we can't turn it off > for peripheral mode. Looks like nothing has moved forward on this (quite significant) fixup. Could we please merge it as soon as time allows? Cheers and thanks in advance, Paul > Cheers, > Andre. > > [1] https://lists.denx.de/pipermail/u-boot/2019-May/369521.html -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engin
Re: [U-Boot] [RESEND PATCH v2 03/15] arm: socfpga: Move Stratix10 and Agilex reset manager common code
On Thu, Jul 11, 2019 at 12:48 AM Ley Foon Tan wrote: > > On Tue, Jul 9, 2019 at 12:57 PM Simon Goldschmidt > wrote: > > > > Am 04.07.2019 um 10:56 schrieb Ley Foon Tan: > > > Move Stratix10 and Agilex reset manager common code to reset_manager.h. > > > > Hmm, I'd feel better if this was in a file common to these two > > architectures, not in such a generic file. Do you have some kind of > > internal code name that would describe "Stratix10 and Agilex"? If so, > > adding a file with such a name might be clearer...? > No, we don't have internal code name for "Stratix10 and Agilex". > How about "_soc64" for common between Stratix1o and Agilex? 64 is 64 bit > system. If you think future 64 bit SoCs will reuse the same structures as Stratix and Agilex (which I could not tell) then this might be an appropriate name, yes. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: socfpga: gen5: don't zero bss in board_init_f()
On 7/12/19 7:29 AM, Simon Goldschmidt wrote: > On Fri, Jul 12, 2019 at 7:15 AM Marek Vasut wrote: >> >> On 7/11/19 9:18 PM, Simon Goldschmidt wrote: >>> The socfpga gen5 SPL manually zeroed bss in board_init_f(). Now that the >>> DDR driver does not use bss any more, bss is not used before board_init_r() >>> and we can remove this hack. >>> >>> Signed-off-by: Simon Goldschmidt >>> --- >>> >>> arch/arm/mach-socfpga/spl_gen5.c | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/arch/arm/mach-socfpga/spl_gen5.c >>> b/arch/arm/mach-socfpga/spl_gen5.c >>> index 87b76b47de..47e63709ad 100644 >>> --- a/arch/arm/mach-socfpga/spl_gen5.c >>> +++ b/arch/arm/mach-socfpga/spl_gen5.c >>> @@ -79,8 +79,6 @@ void board_init_f(ulong dummy) >>> writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN, >>> &sysmgr_regs->eccgrp_ocram); >>> >>> - memset(__bss_start, 0, __bss_end - __bss_start); >>> - >>> socfpga_sdram_remap_zero(); >>> socfpga_pl310_clear(); >> >> So who will zero out the BSS ? > > BSS is zeroed by crt0.S, but after board_init_f(), before board_init_r(). > Socfpga just had this double-zeroing because it invalidly used BSS in > board_init_f(). Can you add that to the commit message and resend just this patch ? I applied the other one. > Some weeks ago on this list, we've had a discussion whether it would be good > to > generally allow such early usage of BSS, possibly via a config option (socfpga > is not the only platform affected). The outcome was negative and so I've > started > this patch. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: do not reboot via SRAM
On 7/12/19 8:00 AM, Simon Goldschmidt wrote:
> On Fri, Jul 12, 2019 at 7:27 AM Marek Vasut wrote:
>>
>> On 7/12/19 7:20 AM, Simon Goldschmidt wrote:
>>> On Fri, Jul 12, 2019 at 7:15 AM Marek Vasut wrote:
On 7/10/19 9:06 PM, Simon Goldschmidt wrote:
> This removes the code that enables the Boot ROM to just jump to SRAM
> instead of loading SPL from the original boot source on warm reboot.
>
> The reason for removing this is that it is insecure: SRAM might be
> overwritten at the time the warm reboot is done. Instead, use the default
> behaviour of loading SPL from the configured boot source medium.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Changes in v2:
> - remove the compatibility code restoring the old "reboot from SRAM"
> behaviour via an env var callback as it turned out such a hack should
> not be included by default
> - (v1 patch subject was: "arm: socfpga: control reboot from SRAM via env
> callback")
>
> arch/arm/mach-socfpga/misc_gen5.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
> b/arch/arm/mach-socfpga/misc_gen5.c
> index 71547d81ab..38bff8a450 100644
> --- a/arch/arm/mach-socfpga/misc_gen5.c
> +++ b/arch/arm/mach-socfpga/misc_gen5.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -182,15 +183,6 @@ int arch_early_init_r(void)
> {
> int i;
>
> - /*
> - * Write magic value into magic register to unlock support for
> - * issuing warm reset. The ancient kernel code expects this
> - * value to be written into the register by the bootloader, so
> - * to support that old code, we write it here instead of in the
> - * reset_cpu() function just before resetting the CPU.
> - */
> - writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
Does this break ancient altera kernel versions ? Do we care ?
>>>
>>> You mean ancient kernels built from non-mainline sources? I don't really
>>> care,
>>> no.
>>>
>>> However, this *might* break boards like my older hw revisions that set qspi
>>> into
>>> four byte mode. But given that, depending on the situation, those *are*
>>> already
>>> broken, I think removing this code is still the correct thing to do.
>>>
>>> The bonus is that you'll notice on the very first try that 'reboot' doesn't
>>> work. Whereas before,t it worked at the start and then might break in some
>>> specific situation you'll not be able to test.
>>
>> Does reboot still work in mainline Linux with this ?
>> I am somewhat reluctant to apply this patch, since I recall there was
>> some weird reason this write was added, but I don't remember what it was.
>
> I can understand being reluctant about this. I can tell you my board reboots
> OK,
> so does socfpga_socrates. There are, however, two types of boards that might
> not
> reboot ok:
>
> a) boards with broken reset circuits (where the qspi chip does not get
> reset on reboot) that set the qspi into 4 byte mode (so the boot rom cannot
> load
> SPL from flash)
>
> b) if I remember correctly the discussion with Dalon some months ago: boards
> that have 'csel=0' and set a very high clock rate as input clock to the qspi
> hardware: boot rom sees 'csel=0' and thinks the input clock rate is slow
> (while
> it actually is high since warm reboot doesn't change the clocks). So it uses a
> small divider and this might result in a transfer speed higher than the flash
> chip can handle.
>
> My position to 'a' is that yes, we break such boards but they should just
> write
> the magic on their own, which can even be done with a U-Boot script.
>
> 'b' boards are a bit more delicate. I can't tell how widely this is used. I
> think all mainline boards other than socfgpa_socrates boot from mmc, not from
> qspi. And socfgpa_socrates should not be affected as it has csel='11'.
At least vining-fpga boots from QSPI NOR. IS1 I think too. csel=0 is
quite common, because it's recommended by Altera.
> One fix for these 'b' boards is to reboot 'cold', not 'warm'. Unfortunately,
> up to now, warm reboot is the default for Linux. It can be overridden by
> passing
> "reboot=hard" on the kernel command line. I think I've reached consent with
> Dinh
> to change the behaviour to let 'cold' reboot be the standard (which does reset
> clocks, so boot rom correctly handles 'csel=0'), but that won't be active
> until
> Linux v5.4, I guess (haven't found the time to post the patch, yet).
>
> However, the current state is just not safe: if reboot is triggered by a
> watchdog, e.g. because the cpu runs invalid code, how can we rely on the SRAM
> being in the correct state? We'll want to load SPL from flash.
Doesn't the bootrom check some checksum of the blob in SRAM, an
Re: [U-Boot] [RESEND PATCH v2 08/15] arm: socfpga: agilex: Add clock manager support
On Thu, Jul 11, 2019 at 1:08 AM Ley Foon Tan wrote:
>
> On Tue, Jul 9, 2019 at 1:16 PM Simon Goldschmidt
> wrote:
> >
> > Am 04.07.2019 um 10:56 schrieb Ley Foon Tan:
> > > Add clock manager support for Agilex.
> > >
> > > Signed-off-by: Ley Foon Tan
> > >
> > > ---
> > > v2:
> > > - Get clocks from clock DM.
> >
> > Wait, can you explain this a bit more? If you get clocks from DM, why is
> > this arch-specific driver needed at all? Can't you just convert the
> > callers into calling into the right clock driver directly?
> >
> This mainly is a wrapper to call clock DM function to get clock
> frequency and print clock summary in SPL, call in
> cm_print_clock_quick_summary().
>
> Each driver like MMC driver will not use this.
Then maybe you can improve the commit message so that
I don't think this is a DM_CLK implementation that lives in
'arch' :-)
Regards,
Simon
>
> Regards
> Ley Foon
>
> >
> > > ---
> > > arch/arm/mach-socfpga/Makefile| 4 +
> > > arch/arm/mach-socfpga/clock_manager_agilex.c | 87 +++
> > > .../include/mach/clock_manager_agilex.h | 2 +
> > > 3 files changed, 93 insertions(+)
> > > create mode 100644 arch/arm/mach-socfpga/clock_manager_agilex.c
> > >
> > > diff --git a/arch/arm/mach-socfpga/Makefile
> > > b/arch/arm/mach-socfpga/Makefile
> > > index 11370cf4c4..5bb36d07df 100644
> > > --- a/arch/arm/mach-socfpga/Makefile
> > > +++ b/arch/arm/mach-socfpga/Makefile
> > > @@ -40,6 +40,10 @@ obj-y += wrap_pinmux_config_s10.o
> > > obj-y += wrap_pll_config_s10.o
> > > endif
> > >
> > > +ifdef CONFIG_TARGET_SOCFPGA_AGILEX
> > > +obj-y+= clock_manager_agilex.o
> > > +endif
> > > +
> > > ifdef CONFIG_SPL_BUILD
> > > ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > > obj-y += spl_gen5.o
> > > diff --git a/arch/arm/mach-socfpga/clock_manager_agilex.c
> > > b/arch/arm/mach-socfpga/clock_manager_agilex.c
> > > new file mode 100644
> > > index 00..5159415fbf
> > > --- /dev/null
> > > +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> > > @@ -0,0 +1,87 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (C) 2019 Intel Corporation
> > > + *
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > +
> > > +static const struct socfpga_system_manager *sysmgr_regs =
> > > + (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
> > > +
> > > +static ulong cm_get_rate_dm(u32 id)
> > > +{
> > > + struct udevice *dev;
> > > + struct clk clk;
> > > + ulong rate;
> > > + int ret;
> > > +
> > > + ret = uclass_get_device_by_driver(UCLASS_CLK,
> > > + DM_GET_DRIVER(socfpga_agilex_clk),
> > > + &dev);
> > > + if (ret)
> > > + return 0;
> > > +
> > > + clk.id = id;
> > > + ret = clk_request(dev, &clk);
> > > + if (ret < 0)
> > > + return 0;
> > > +
> > > + rate = clk_get_rate(&clk);
> > > +
> > > + clk_free(&clk);
> > > +
> > > + if ((rate == (unsigned long)-ENOSYS) ||
> > > + (rate == (unsigned long)-ENXIO) ||
> > > + (rate == (unsigned long)-EIO)) {
> > > + debug("%s id %u: clk_get_rate err: %ld\n",
> > > + __func__, id, rate);
> > > + return 0;
> > > + }
> > > +
> > > + return rate;
> > > +}
> > > +
> > > +static u32 cm_get_rate_dm_khz(u32 id)
> > > +{
> > > + return cm_get_rate_dm(id) / 1000;
> > > +}
> > > +
> > > +unsigned long cm_get_mpu_clk_hz(void)
> > > +{
> > > + return cm_get_rate_dm(STRATIX10_MPU_CLK);
> > > +}
> > > +
> > > +unsigned int cm_get_l4_sys_free_clk_hz(void)
> > > +{
> > > + return cm_get_rate_dm(STRATIX10_L4_SYS_FREE_CLK);
> > > +}
> > > +
> > > +u32 cm_get_qspi_controller_clk_hz(void)
> > > +{
> > > + return readl(&sysmgr_regs->boot_scratch_cold0);
> > > +}
> > > +
> > > +void cm_print_clock_quick_summary(void)
> > > +{
> > > + printf("MPU %10d kHz\n",
> > > +cm_get_rate_dm_khz(STRATIX10_MPU_CLK));
> > > + printf("L4 Main %8d kHz\n",
> > > +cm_get_rate_dm_khz(STRATIX10_L4_MAIN_CLK));
> > > + printf("L4 sys free %8d kHz\n",
> > > +cm_get_rate_dm_khz(STRATIX10_L4_SYS_FREE_CLK));
> > > + printf("L4 MP %8d kHz\n",
> > > +cm_get_rate_dm_khz(STRATIX10_L4_MP_CLK));
> > > + printf("L4 SP %8d kHz\n",
> > > +cm_get_rate_dm_khz(STRATIX10_L4_SP_CLK));
> > > + printf("SDMMC %8d kHz\n",
> > > +cm_get_rate_dm_khz(STRATIX10_SDMMC_CLK));
> > > +}
> > > diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
> > > b/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
> > > index bf5e7c8775..c4d27bad72 100644
> > > --- a/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
> > > +++ b/
Re: [U-Boot] [PATCH 2/2] arm: socfpga: gen5: don't zero bss in board_init_f()
On Fri, Jul 12, 2019 at 12:29 PM Marek Vasut wrote: > > On 7/12/19 7:29 AM, Simon Goldschmidt wrote: > > On Fri, Jul 12, 2019 at 7:15 AM Marek Vasut wrote: > >> > >> On 7/11/19 9:18 PM, Simon Goldschmidt wrote: > >>> The socfpga gen5 SPL manually zeroed bss in board_init_f(). Now that the > >>> DDR driver does not use bss any more, bss is not used before > >>> board_init_r() > >>> and we can remove this hack. > >>> > >>> Signed-off-by: Simon Goldschmidt > >>> --- > >>> > >>> arch/arm/mach-socfpga/spl_gen5.c | 2 -- > >>> 1 file changed, 2 deletions(-) > >>> > >>> diff --git a/arch/arm/mach-socfpga/spl_gen5.c > >>> b/arch/arm/mach-socfpga/spl_gen5.c > >>> index 87b76b47de..47e63709ad 100644 > >>> --- a/arch/arm/mach-socfpga/spl_gen5.c > >>> +++ b/arch/arm/mach-socfpga/spl_gen5.c > >>> @@ -79,8 +79,6 @@ void board_init_f(ulong dummy) > >>> writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN, > >>> &sysmgr_regs->eccgrp_ocram); > >>> > >>> - memset(__bss_start, 0, __bss_end - __bss_start); > >>> - > >>> socfpga_sdram_remap_zero(); > >>> socfpga_pl310_clear(); > >> > >> So who will zero out the BSS ? > > > > BSS is zeroed by crt0.S, but after board_init_f(), before board_init_r(). > > Socfpga just had this double-zeroing because it invalidly used BSS in > > board_init_f(). > > Can you add that to the commit message and resend just this patch ? I > applied the other one. Sure. > > > Some weeks ago on this list, we've had a discussion whether it would be > > good to > > generally allow such early usage of BSS, possibly via a config option > > (socfpga > > is not the only platform affected). The outcome was negative and so I've > > started > > this patch. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] toradex: configblock: initialize MMC before switching partition
From: Stefan Agner
If the module is in serial downloader mode, we do no longer read the
environment from eMMC. Therefor, the eMMC is unitialized when trying
to read the config block. Use mmc_init to initialize the selected
MMC device before using it.
Note: In case the MMC has already been initialized, the mmc_init
detects that and returns immediately.
Signed-off-by: Stefan Agner
Acked-by: Max Krummenacher
Signed-off-by: Marcel Ziswiler
Reviewed-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
---
Changes in v2:
- Added my S-b and others R-bs.
board/toradex/common/tdx-cfg-block.c | 4
1 file changed, 4 insertions(+)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index f69c4433b2..67e0557f67 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -129,6 +129,10 @@ static int tdx_cfg_block_mmc_storage(u8 *config_block, int
write)
ret = -ENODEV;
goto out;
}
+ if (mmc_init(mmc)) {
+ puts("MMC init failed\n");
+ return -EINVAL;
+ }
if (part != mmc_get_blk_desc(mmc)->hwpart) {
if (blk_select_hwpart_devnum(IF_TYPE_MMC, dev, part)) {
puts("MMC partition switch failed\n");
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] toradex: configblock: apalis-imx8 and colibri-imx8x fixes
This series fixes some shortcomings of the current apalis-imx8 and colibri-imx8x SKU handling. Changes in v2: - Added my S-b and others R-bs. - Avoid line continuations as pointed out by Max. Marcel Ziswiler (4): toradex: configblock: generic wi-fi/bt handling toradex: configblock: fix colibri imx8x target toradex: configblock: fix apalis imx8 target toradex: configblock: avoid line continuations Stefan Agner (1): toradex: configblock: initialize MMC before switching partition board/toradex/common/tdx-cfg-block.c | 66 +++- 1 file changed, 46 insertions(+), 20 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] toradex: configblock: avoid line continuations
From: Marcel Ziswiler
Fix issue as reported by checkpatch.pl. Leave long lines as line
continuation in text output is not recommended.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
---
Changes in v2:
- Avoid line continuations as pointed out by Max.
- Added R-bs.
board/toradex/common/tdx-cfg-block.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index a7909d3898..c19d7611c2 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -511,8 +511,7 @@ static int do_cfgblock_create(cmd_tbl_t *cmdtp, int flag,
int argc,
* On NAND devices, recreation is only allowed if the page is
* empty (config block invalid...)
*/
- printf("NAND erase block %d need to be erased before creating" \
- " a Toradex config block\n",
+ printf("NAND erase block %d need to be erased before creating a
Toradex config block\n",
CONFIG_TDX_CFG_BLOCK_OFFSET /
get_nand_dev_by_index(0)->erasesize);
goto out;
@@ -521,8 +520,7 @@ static int do_cfgblock_create(cmd_tbl_t *cmdtp, int flag,
int argc,
* On NOR devices, recreation is only allowed if the sector is
* empty and write protection is off (config block invalid...)
*/
- printf("NOR sector at offset 0x%02x need to be erased and " \
- "unprotected before creating a Toradex config block\n",
+ printf("NOR sector at offset 0x%02x need to be erased and
unprotected before creating a Toradex config block\n",
CONFIG_TDX_CFG_BLOCK_OFFSET);
goto out;
#else
@@ -633,9 +631,8 @@ static int do_cfgblock(cmd_tbl_t *cmdtp, int flag, int argc,
return CMD_RET_USAGE;
}
-U_BOOT_CMD(
- cfgblock, 4, 0, do_cfgblock,
- "Toradex config block handling commands",
- "create [-y] [barcode] - (Re-)create Toradex config block\n"
- "cfgblock reload - Reload Toradex config block from flash"
+U_BOOT_CMD(cfgblock, 4, 0, do_cfgblock,
+ "Toradex config block handling commands",
+ "create [-y] [barcode] - (Re-)create Toradex config block\n"
+ "cfgblock reload - Reload Toradex config block from flash"
);
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] toradex: configblock: fix apalis imx8 target
From: Marcel Ziswiler
The Apalis iMX8 was missing the interactive part should a customer have
bricked his module and want to re-create the configuration block. Fix
this.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
---
Changes in v2:
- Added R-bs.
board/toradex/common/tdx-cfg-block.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 9146cbac94..a7909d3898 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -7,6 +7,7 @@
#include "tdx-cfg-block.h"
#if defined(CONFIG_TARGET_APALIS_IMX6) || \
+ defined(CONFIG_TARGET_APALIS_IMX8) || \
defined(CONFIG_TARGET_COLIBRI_IMX6) || \
defined(CONFIG_TARGET_COLIBRI_IMX8X)
#include
@@ -355,7 +356,19 @@ static int get_cfgblock_interactive(void)
tdx_hw_tag.prodid = COLIBRI_IMX7D;
else if (!strcmp("imx7s", soc))
tdx_hw_tag.prodid = COLIBRI_IMX7S;
- else if (is_cpu_type(MXC_CPU_IMX8QXP)) {
+ else if (is_cpu_type(MXC_CPU_IMX8QM)) {
+ if (it == 'y' || it == 'Y') {
+ if (wb == 'y' || wb == 'Y')
+ tdx_hw_tag.prodid = APALIS_IMX8QM_WIFI_BT_IT;
+ else
+ tdx_hw_tag.prodid = APALIS_IMX8QM_IT;
+ } else {
+ if (wb == 'y' || wb == 'Y')
+ tdx_hw_tag.prodid = APALIS_IMX8QP_WIFI_BT;
+ else
+ tdx_hw_tag.prodid = APALIS_IMX8QP;
+ }
+ } else if (is_cpu_type(MXC_CPU_IMX8QXP)) {
if (it == 'y' || it == 'Y') {
if (wb == 'y' || wb == 'Y')
tdx_hw_tag.prodid = COLIBRI_IMX8QXP_WIFI_BT_IT;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] toradex: configblock: generic wi-fi/bt handling
From: Marcel Ziswiler
Make the interactive Wi-Fi/BT handling generic by pulling it out of the
Colibri iMX6ULL interactive part to be re-used for Apalis iMX8 and
Colibri iMX8X.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
---
Changes in v2:
- Avoid line continuation as reported by checkpatch.
- Added R-bs.
board/toradex/common/tdx-cfg-block.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 67e0557f67..451f8d4c11 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -291,6 +291,7 @@ static int get_cfgblock_interactive(void)
char message[CONFIG_SYS_CBSIZE];
char *soc;
char it = 'n';
+ char wb = 'n';
int len;
/* Unknown module by default */
@@ -300,10 +301,17 @@ static int get_cfgblock_interactive(void)
sprintf(message, "Is the module the 312 MHz version? [y/N] ");
else
sprintf(message, "Is the module an IT version? [y/N] ");
-
len = cli_readline(message);
it = console_buffer[0];
+#if defined(CONFIG_TARGET_APALIS_IMX8) || \
+ defined(CONFIG_TARGET_COLIBRI_IMX6ULL) || \
+ defined(CONFIG_TARGET_COLIBRI_IMX8X)
+ sprintf(message, "Does the module have Wi-Fi / Bluetooth? [y/N] ");
+ len = cli_readline(message);
+ wb = console_buffer[0];
+#endif
+
soc = env_get("soc");
if (!strcmp("mx6", soc)) {
#ifdef CONFIG_TARGET_APALIS_IMX6
@@ -331,12 +339,6 @@ static int get_cfgblock_interactive(void)
tdx_hw_tag.prodid = COLIBRI_IMX6S;
}
#elif CONFIG_TARGET_COLIBRI_IMX6ULL
- char wb = 'n';
-
- sprintf(message, "Does the module have Wi-Fi / Bluetooth? " \
-"[y/N] ");
- len = cli_readline(message);
- wb = console_buffer[0];
if (it == 'y' || it == 'Y') {
if (wb == 'y' || wb == 'Y')
tdx_hw_tag.prodid = COLIBRI_IMX6ULL_WIFI_BT_IT;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: do not reboot via SRAM
On Fri, Jul 12, 2019 at 12:29 PM Marek Vasut wrote:
>
> On 7/12/19 8:00 AM, Simon Goldschmidt wrote:
> > On Fri, Jul 12, 2019 at 7:27 AM Marek Vasut wrote:
> >>
> >> On 7/12/19 7:20 AM, Simon Goldschmidt wrote:
> >>> On Fri, Jul 12, 2019 at 7:15 AM Marek Vasut wrote:
>
> On 7/10/19 9:06 PM, Simon Goldschmidt wrote:
> > This removes the code that enables the Boot ROM to just jump to SRAM
> > instead of loading SPL from the original boot source on warm reboot.
> >
> > The reason for removing this is that it is insecure: SRAM might be
> > overwritten at the time the warm reboot is done. Instead, use the
> > default
> > behaviour of loading SPL from the configured boot source medium.
> >
> > Signed-off-by: Simon Goldschmidt
> > ---
> >
> > Changes in v2:
> > - remove the compatibility code restoring the old "reboot from SRAM"
> > behaviour via an env var callback as it turned out such a hack should
> > not be included by default
> > - (v1 patch subject was: "arm: socfpga: control reboot from SRAM via env
> > callback")
> >
> > arch/arm/mach-socfpga/misc_gen5.c | 10 +-
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/misc_gen5.c
> > b/arch/arm/mach-socfpga/misc_gen5.c
> > index 71547d81ab..38bff8a450 100644
> > --- a/arch/arm/mach-socfpga/misc_gen5.c
> > +++ b/arch/arm/mach-socfpga/misc_gen5.c
> > @@ -6,6 +6,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -182,15 +183,6 @@ int arch_early_init_r(void)
> > {
> > int i;
> >
> > - /*
> > - * Write magic value into magic register to unlock support for
> > - * issuing warm reset. The ancient kernel code expects this
> > - * value to be written into the register by the bootloader, so
> > - * to support that old code, we write it here instead of in the
> > - * reset_cpu() function just before resetting the CPU.
> > - */
> > - writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
>
> Does this break ancient altera kernel versions ? Do we care ?
> >>>
> >>> You mean ancient kernels built from non-mainline sources? I don't really
> >>> care,
> >>> no.
> >>>
> >>> However, this *might* break boards like my older hw revisions that set
> >>> qspi into
> >>> four byte mode. But given that, depending on the situation, those *are*
> >>> already
> >>> broken, I think removing this code is still the correct thing to do.
> >>>
> >>> The bonus is that you'll notice on the very first try that 'reboot'
> >>> doesn't
> >>> work. Whereas before,t it worked at the start and then might break in some
> >>> specific situation you'll not be able to test.
> >>
> >> Does reboot still work in mainline Linux with this ?
> >> I am somewhat reluctant to apply this patch, since I recall there was
> >> some weird reason this write was added, but I don't remember what it was.
> >
> > I can understand being reluctant about this. I can tell you my board
> > reboots OK,
> > so does socfpga_socrates. There are, however, two types of boards that
> > might not
> > reboot ok:
> >
> > a) boards with broken reset circuits (where the qspi chip does not get
> > reset on reboot) that set the qspi into 4 byte mode (so the boot rom cannot
> > load
> > SPL from flash)
> >
> > b) if I remember correctly the discussion with Dalon some months ago: boards
> > that have 'csel=0' and set a very high clock rate as input clock to the qspi
> > hardware: boot rom sees 'csel=0' and thinks the input clock rate is slow
> > (while
> > it actually is high since warm reboot doesn't change the clocks). So it
> > uses a
> > small divider and this might result in a transfer speed higher than the
> > flash
> > chip can handle.
> >
> > My position to 'a' is that yes, we break such boards but they should just
> > write
> > the magic on their own, which can even be done with a U-Boot script.
> >
> > 'b' boards are a bit more delicate. I can't tell how widely this is used. I
> > think all mainline boards other than socfgpa_socrates boot from mmc, not
> > from
> > qspi. And socfgpa_socrates should not be affected as it has csel='11'.
>
> At least vining-fpga boots from QSPI NOR. IS1 I think too. csel=0 is
> quite common, because it's recommended by Altera.
Oh, ok.
>
> > One fix for these 'b' boards is to reboot 'cold', not 'warm'. Unfortunately,
> > up to now, warm reboot is the default for Linux. It can be overridden by
> > passing
> > "reboot=hard" on the kernel command line. I think I've reached consent with
> > Dinh
> > to change the behaviour to let 'cold' reboot be the standard (which does
> > reset
> > clocks, so boot rom correctly handles 'csel=0'), but that won't be active
> > until
> > Linux v5.4, I guess (haven't found the
[U-Boot] [PATCH v2 3/5] toradex: configblock: fix colibri imx8x target
From: Marcel Ziswiler
The Colibri iMX8X target got re-named late in the cycle which we forgot
to reflect here. Furthermore, it was missing the interactive part should
a customer have bricked his module and want to re-create the
configuration block. Fix this.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
---
Changes in v2:
- Added R-bs.
board/toradex/common/tdx-cfg-block.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 451f8d4c11..9146cbac94 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -8,7 +8,7 @@
#if defined(CONFIG_TARGET_APALIS_IMX6) || \
defined(CONFIG_TARGET_COLIBRI_IMX6) || \
- defined(CONFIG_TARGET_COLIBRI_IMX8QXP)
+ defined(CONFIG_TARGET_COLIBRI_IMX8X)
#include
#else
#define is_cpu_type(cpu) (0)
@@ -355,9 +355,19 @@ static int get_cfgblock_interactive(void)
tdx_hw_tag.prodid = COLIBRI_IMX7D;
else if (!strcmp("imx7s", soc))
tdx_hw_tag.prodid = COLIBRI_IMX7S;
- else if (is_cpu_type(MXC_CPU_IMX8QXP))
- tdx_hw_tag.prodid = COLIBRI_IMX8QXP_WIFI_BT_IT;
- else if (!strcmp("tegra20", soc)) {
+ else if (is_cpu_type(MXC_CPU_IMX8QXP)) {
+ if (it == 'y' || it == 'Y') {
+ if (wb == 'y' || wb == 'Y')
+ tdx_hw_tag.prodid = COLIBRI_IMX8QXP_WIFI_BT_IT;
+ else
+ tdx_hw_tag.prodid = COLIBRI_IMX8QXP_IT;
+ } else {
+ if (wb == 'y' || wb == 'Y')
+ tdx_hw_tag.prodid = COLIBRI_IMX8DX_WIFI_BT;
+ else
+ tdx_hw_tag.prodid = COLIBRI_IMX8DX;
+ }
+ } else if (!strcmp("tegra20", soc)) {
if (it == 'y' || it == 'Y')
if (gd->ram_size == 0x1000)
tdx_hw_tag.prodid = COLIBRI_T20_256MB_IT;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB
On Fri, 12 Jul 2019 11:44:38 +0200 Paul Kocialkowski wrote: Hi, > On Mon 27 May 19, 00:50, André Przywara wrote: > > On 17/04/2019 12:28, Jagan Teki wrote: > > > On Mon, Apr 15, 2019 at 1:52 PM Paul Kocialkowski > > > wrote: > > > > Hi, > > > > >> Le vendredi 12 avril 2019 à 14:49 +0530, Jagan Teki a écrit : > > >>> On Thu, Mar 14, 2019 at 4:08 PM Paul Kocialkowski > > >>> wrote: > > Recent Allwinner platforms (starting with the H3) only use the MUSB > > controller for peripheral mode and use HCI for host mode. As a result, > > extra steps need to be taken to properly route USB signals to one or > > the other. More precisely, the following is required: > > * Routing the pins to either HCI/MUSB (controlled by PHY); > > * Enabling USB PHY passby in HCI mode (controlled by PMU). > > > > The current code will enable passby for each PHY and reroute PHY0 to > > MUSB, which is inconsistent and results in broken USB peripheral > > support. > > > > Passby on PHY0 must only be enabled when we want to use HCI. Since > > host/device mode detection is not available from the PHY code and > > because U-Boot does not support changing the mode dynamically anyway, > > we can just mux the controller to MUSB if it is enabled and mux it to > > HCI otherwise. > > > > This fixes USB peripheral support for platforms with PHY0 dual-route, > > especially H3/H5 and V3s. > > > > Signed-off-by: Paul Kocialkowski > > --- > > drivers/phy/allwinner/phy-sun4i-usb.c | 14 +- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c > > b/drivers/phy/allwinner/phy-sun4i-usb.c > > index f206fa3f5d48..4f1c7e519d71 100644 > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > > @@ -302,9 +302,21 @@ static int sun4i_usb_phy_init(struct phy *phy) > > data->cfg->disc_thresh, > > PHY_DISCON_TH_LEN); > > } > > > > +#ifdef CONFIG_USB_MUSB_SUNXI > > + /* Needed for HCI and conflicts with MUSB, keep PHY0 on MUSB */ > > + if (usb_phy->id != 0) > > + sun4i_usb_phy_passby(phy, true); > > + > > + /* Route PHY0 to MUSB to allow USB gadget */ > > + if (data->cfg->phy0_dual_route) > > + sun4i_usb_phy0_reroute(data, true); > > +#else > > sun4i_usb_phy_passby(phy, true); > > > > - sun4i_usb_phy0_reroute(data, true); > > + /* Route PHY0 to HCI to allow USB host */ > > + if (data->cfg->phy0_dual_route) > > + sun4i_usb_phy0_reroute(data, false); > > +#endif > > >>> > > >>> I think we can manage this route and passby dynamically by detecting > > >>> id since we have dr_mode verify the MUSB host or peripheral via > > >>> usb_get_dr_mode, any chance to try that way? > > >> > > >> Oh, I didn't know that U-Boot has support for usb_get_dr_mode these > > >> days. Thanks! > > >> > > >> So far, the sunxi port has been using Kconfig to distinguish between > > >> host/device (unless I'm mistaken?) so I feel like this should be a > > >> separate follow-up patch to convert the sunxi MUSB glue + PHY to > > >> detecting dr_mode using usb_get_dr_mode. This feels like a significant > > >> rework, too. > > > > > > Yes. > > > > > >> > > >> Also, how should we handle the OTG case? I'm not sure we can support > > >> having both musb host and gadget built-in at this point. But that would > > >> certainly be welcome as part of the rework, too. > > >> > > >> What do you think? > > > > > > You mean handling dr_mode at runtime. > > > > > > If yes, It is bit new where we can register the musb as UCLASS_MISC > > > wrapper and decide to bind driver for host and peripheral by decoding > > > dr_mode. and indeed host should register with UCLASS_USB and > > > peripheral with UCLASS_USB_GADGET_GENERIC. > > > > > > I tried this wrapper before, not placed in-between because of other > > > work but TI musb has similar code to manage this > > > drivers/usb/musb-new/ti-musb.c > > > > Before we go wild with any fancy rework, can we possibly take this patch > > as it? As I realised, this is basically a better version of the patch I > > sent two weeks ago [1]. I tried Paul's patch back then, but was missing > > the phys property in the DT, which I addressed in patch 2/2. > > > > So I would appreciate if we can take this patch, as it solves a real > > problem (upper USB port not working) on many Pine64 boards (given the > > small DT change is in place). And on those boards the OTG functionality > > is not really feasible anyway, as VBUS is either permanently enabled or > > at least tied to the other host port's supply, so we can't turn it off > > for peripheral mode. > > L
Re: [U-Boot] [RESEND PATCH v2 07/15] clk: agilex: Add clock driver for Agilex.
On Thu, Jul 11, 2019 at 1:03 AM Ley Foon Tan wrote:
>
> On Tue, Jul 9, 2019 at 1:13 PM Simon Goldschmidt
> wrote:
> >
> > Am 04.07.2019 um 10:56 schrieb Ley Foon Tan:
> > > Add clock manager driver for Agilex. Provides clock initialization
> > > and get_rate functions.
> >
> > Thanks for adding this to the patchset. This is quite a big change, I
> > don't have the time currently to review it. Just a question to the
> > message above: does 'clock' initialization mean it reads the
> > initialization values from devicetree instead of reading them from qts
> > header files? If so, is the code better integrated then the A10 code?
> For S10 and Agilex, the initialization values is from handoff in FPGA
> image, not from device tree as A10.
> It is much simpler than A10 implementation.
> >
> > And further asked, if this works for Agilex, and you added
> > "stratix10-clock.h", does this work for S10, too?
> Actually "stratix10-clock.h" is from Linux tree,
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/dt-bindings/clock/stratix10-clock.h
> I can add Linux commit ID in commit message.
You already did that. My question was: does this clock driver work for
Stratix10, too, given the name of the file you imported?
Regards,
Simon
>
> >
> > And what are the dependencies to Quartus versions here (e.g. for S10)?
> No dependency. Index used in stratix10-clock.h is software defined
> index not in HW.
> >
> > Regards,
> > Simon
> >
> > >
> > > stratix10-clock.h is from Linux commit ID 89727949ea1e.
> > >
> > > Signed-off-by: Chee Hong Ang
> > > Signed-off-by: Ley Foon Tan
> > >
> > > ---
> > > v2:
> > > - Convert Clock driver to DM
> > > ---
> > > .../mach-socfpga/include/mach/clock_manager.h | 2 +
> > > .../include/mach/clock_manager_agilex.h | 327 ++
> > > drivers/clk/altera/Makefile | 1 +
> > > drivers/clk/altera/clk-agilex.c | 568 ++
> > > include/dt-bindings/clock/stratix10-clock.h | 84 +++
> > > 5 files changed, 982 insertions(+)
> > > create mode 100644
> > > arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
> > > create mode 100644 drivers/clk/altera/clk-agilex.c
> > > create mode 100644 include/dt-bindings/clock/stratix10-clock.h
> > >
> > > diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > index dd80e3a767..a3d5de59d2 100644
> > > --- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > +++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > @@ -18,6 +18,8 @@ void cm_print_clock_quick_summary(void);
> > > #include
> > > #elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > > #include
> > > +#elif defined(CONFIG_TARGET_SOCFPGA_AGILEX)
> > > +#include
> > > #endif
> > >
> > > #endif /* _CLOCK_MANAGER_H_ */
> > > diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
> > > b/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
> > > new file mode 100644
> > > index 00..bf5e7c8775
> > > --- /dev/null
> > > +++ b/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
> > > @@ -0,0 +1,327 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Copyright (C) 2019 Intel Corporation
> > > + */
> > > +
> > > +#ifndef _CLOCK_MANAGER_AGILEX_
> > > +#define _CLOCK_MANAGER_AGILEX_
> > > +
> > > +#define CM_REG_READL(plat, reg) \
> > > + readl(plat->regs + (reg))
> > > +
> > > +#define CM_REG_WRITEL(plat, data, reg) \
> > > + writel(data, plat->regs + (reg))
> > > +
> > > +#define CM_REG_CLRBITS(plat, mask, reg) \
> > > + clrbits_le32(plat->regs + (reg), (mask))
> > > +
> > > +#define CM_REG_SETBITS(plat, mask, reg) \
> > > + setbits_le32(plat->regs + (reg), (mask))
> > > +
> > > +#define CM_REG_CLRSETBITS(plat, mask, data, reg) \
> > > + clrsetbits_le32(plat->regs + (reg), (mask), (data))
> > > +
> > > +const unsigned int cm_get_osc_clk_hz(void);
> > > +const unsigned int cm_get_intosc_clk_hz(void);
> > > +const unsigned int cm_get_fpga_clk_hz(void);
> > > +
> > > +#define CLKMGR_EOSC1_HZ 2500
> > > +#define CLKMGR_INTOSC_HZ 4
> > > +#define CLKMGR_FPGA_CLK_HZ 5000
> > > +
> > > +/* Clock configuration accessors */
> > > +const struct cm_config * const cm_get_default_config(void);
> > > +
> > > +struct cm_config {
> > > + /* main group */
> > > + u32 main_pll_mpuclk;
> > > + u32 main_pll_nocclk;
> > > + u32 main_pll_nocdiv;
> > > + u32 main_pll_pllglob;
> > > + u32 main_pll_fdbck;
> > > + u32 main_pll_pllc0;
> > > + u32 main_pll_pllc1;
> > > + u32 main_pll_pllc2;
> > > + u32 main_pll_pllc3;
> > > + u32 main_pll_pllm;
> > > +
> > > + /* peripheral group */
> > > + u32 per_pll_emacctl;
> > > + u32 per_pll_gpiodiv;
> > > +
[U-Boot] [PATCH v1 2/2] board: colibri_imx7: reserve DDR memory for Cortex-M4
From: Igor Opaniuk
i.MX 7's Cortex-M4 core can run from DDR and uses DDR memory for
the rpmsg communication. Both use cases need a fixed location of
memory reserved. For the rpmsg use case the reserved area needs
to be in sync with the kernel's hardcoded vring descriptor location.
Use the linux,usable-memory property to carve out 1MB of memory
in case the M4 core is running. Also make sure that the i.MX 7
specific rpmsg driver does not get loaded in case we do not carve
out memory.
Signed-off-by: Stefan Agner
Signed-off-by: Igor Opaniuk
Signed-off-by: Igor Opaniuk
---
arch/arm/include/asm/mach-imx/sys_proto.h | 2 ++
board/toradex/colibri_imx7/colibri_imx7.c | 37 +++
2 files changed, 39 insertions(+)
diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 4925dd7894..775cd3df40 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -113,6 +113,8 @@ void init_src(void);
void init_snvs(void);
void imx_wdog_disable_powerdown(void);
+int arch_auxiliary_core_check_up(u32 core_id);
+
int board_mmc_get_env_dev(int devno);
int nxp_board_rev(void);
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c
b/board/toradex/colibri_imx7/colibri_imx7.c
index 0eb83474c4..6059088bda 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -333,6 +333,43 @@ int checkboard(void)
#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
int ft_board_setup(void *blob, bd_t *bd)
{
+#if defined(CONFIG_IMX_BOOTAUX)
+ int up;
+
+ up = arch_auxiliary_core_check_up(0);
+ if (up) {
+ int ret;
+ int areas = 1;
+ u64 start[2], size[2];
+
+ /*
+* Reserve 1MB of memory for M4 (1MiB is also the minimum
+* alignment for Linux due to MMU section size restrictions).
+*/
+ start[0] = gd->bd->bi_dram[0].start;
+ size[0] = SZ_256M - SZ_1M;
+
+ /* If needed, create a second entry for memory beyond 256M */
+ if (gd->bd->bi_dram[0].size > SZ_256M) {
+ start[1] = gd->bd->bi_dram[0].start + SZ_256M;
+ size[1] = gd->bd->bi_dram[0].size - SZ_256M;
+ areas = 2;
+ }
+
+ ret = fdt_set_usable_memory(blob, start, size, areas);
+ if (ret) {
+ eprintf("Cannot set usable memory\n");
+ return ret;
+ }
+ } else {
+ int off;
+
+ off = fdt_node_offset_by_compatible(blob, -1,
+ "fsl,imx7d-rpmsg");
+ if (off > 0)
+ fdt_status_disabled(blob, off);
+ }
+#endif
#if defined(CONFIG_FDT_FIXUP_PARTITIONS)
static const struct node_info nodes[] = {
{ "fsl,imx7d-gpmi-nand", MTD_DEV_TYPE_NAND, }, /* NAND flash */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 06/15] arm: socfpga: agilex: Add system manager support
On Thu, Jul 11, 2019 at 12:56 AM Ley Foon Tan wrote:
>
> On Tue, Jul 9, 2019 at 1:09 PM Simon Goldschmidt
> wrote:
> >
> > Am 04.07.2019 um 10:56 schrieb Ley Foon Tan:
> > > Add system manager support for Agilex.
> > >
> > > Signed-off-by: Ley Foon Tan
> > >
> > > ---
> > > v2:
> > > - Include system_manager_s10_agilex_common.h in system_manager_agilex.h
> > > ---
> > > .../include/mach/system_manager.h | 2 +
> > > .../include/mach/system_manager_agilex.h | 129 ++
> > > .../mach/system_manager_s10_agilex_common.h | 3 +-
> > > 3 files changed, 133 insertions(+), 1 deletion(-)
> > > create mode 100644
> > > arch/arm/mach-socfpga/include/mach/system_manager_agilex.h
> >
> > See my reply to 05/15: I'd strongly suggest to come up with a name for
> > S10/Agilex common things. Because seeing how much these have in common,
> > it seems like people at Altera/Intel are so satisfied with that design
> > that it could stay with us for some hardware-releases to come...
> >
> > >
> > > diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h
> > > b/arch/arm/mach-socfpga/include/mach/system_manager.h
> > > index 7e76df74b7..79e3777e39 100644
> > > --- a/arch/arm/mach-socfpga/include/mach/system_manager.h
> > > +++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
> > > @@ -8,6 +8,8 @@
> > >
> > > #if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > > #include
> > > +#elif defined(CONFIG_TARGET_SOCFPGA_AGILEX)
> > > +#include
> > > #else
> > > #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGPINMUX BIT(0)
> > > #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGIO BIT(1)
> > > diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_agilex.h
> > > b/arch/arm/mach-socfpga/include/mach/system_manager_agilex.h
> > > new file mode 100644
> > > index 00..e84eed9754
> > > --- /dev/null
> > > +++ b/arch/arm/mach-socfpga/include/mach/system_manager_agilex.h
> > > @@ -0,0 +1,129 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Copyright (C) 2019 Intel Corporation
> > > + */
> > > +
> > > +#ifndef _SYSTEM_MANAGER_AGILEX_
> > > +#define _SYSTEM_MANAGER_AGILEX_
> > > +
> > > +struct socfpga_system_manager {
> >
> > And here, see my reply to 03/15: why do we need a complete different
> > struct here? It seems like only some of the struct members change
> > between S10 and Agilex?
> Yes, some of registers are different between Stratix 10 and Agilex.
> We need add some #ifdef in struct if want share between them. But,
> this will make code hard to read too. Unless we want convert struct to
> #define offset.
>
> What is your preferable way?
That depends. I think here, you're using only some registers of a rather big
struct. Plus the registers you actually use are same for Stratix10 and Agilex.
If my analysis is correct, I think here, defines would be better than structs.
Regards,
Simon
>
> Regards
> Ley Foon
> >
> > > + /* System Manager Module */
> > > + u32 siliconid1; /* 0x00 */
> > > + u32 siliconid2;
> > > + u32 wddbg;
> > > + u32 _pad_0xc;
> > > + u32 mpu_status; /* 0x10 */
> > > + u32 mpu_ace;
> > > + u32 _pad_0x18_0x1c[2];
> > > + u32 dma;/* 0x20 */
> > > + u32 dma_periph;
> > > + /* SDMMC Controller Group */
> > > + u32 sdmmcgrp_ctrl;
> > > + u32 sdmmcgrp_l3master;
> > > + /* NAND Flash Controller Register Group */
> > > + u32 nandgrp_bootstrap; /* 0x30 */
> > > + u32 nandgrp_l3master;
> > > + /* USB Controller Group */
> > > + u32 usb0_l3master;
> > > + u32 usb1_l3master;
> > > + /* EMAC Group */
> > > + u32 emac_gbl; /* 0x40 */
> > > + u32 emac0;
> > > + u32 emac1;
> > > + u32 emac2;
> > > + u32 emac0_ace; /* 0x50 */
> > > + u32 emac1_ace;
> > > + u32 emac2_ace;
> > > + u32 nand_axuser;
> > > + u32 _pad_0x60_0x64[2]; /* 0x60 */
> > > + /* FPGA interface Group */
> > > + u32 fpgaintf_en_1;
> > > + u32 fpgaintf_en_2;
> > > + u32 fpgaintf_en_3; /* 0x70 */
> > > + u32 dma_l3master;
> > > + u32 etr_l3master;
> > > + u32 _pad_0x7c;
> > > + u32 sec_ctrl_slt; /* 0x80 */
> > > + u32 osc_trim;
> > > + u32 _pad_0x88_0x8c[2];
> > > + /* ECC Group */
> > > + u32 ecc_intmask_value; /* 0x90 */
> > > + u32 ecc_intmask_set;
> > > + u32 ecc_intmask_clr;
> > > + u32 ecc_intstatus_serr;
> > > + u32 ecc_intstatus_derr; /* 0xa0 */
> > > + u32 _pad_0xa4_0xac[3];
> > > + u32 noc_addr_remap; /* 0xb0 */
> > > + u32 hmc_clk;
> > > + u32 io_pa_ctrl;
> > > + u32 _pad_0xbc;
[U-Boot] [PATCH v1 1/2] common: fdt_support: add support for setting usable memory
From: Igor Opaniuk
Add support for setting linux,usable-memory property in the memory
node of device tree for the kernel [1].
This property holds a base address and size, describing a
limited region in which memory may be considered available for use by
the kernel. Memory outside of this range is not available for use.
[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
Signed-off-by: Igor Opaniuk
Signed-off-by: Sanchayan Maity
Signed-off-by: Stefan Agner
Signed-off-by: Igor Opaniuk
---
common/fdt_support.c | 35 +++
include/fdt_support.h | 2 ++
2 files changed, 37 insertions(+)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index f31e9b0cc5..57413c7a4d 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -473,6 +473,41 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size)
return fdt_fixup_memory_banks(blob, &start, &size, 1);
}
+int fdt_set_usable_memory(void *blob, u64 start[], u64 size[], int areas)
+{
+ int err, nodeoffset;
+ int len;
+ u8 tmp[8 * 16]; /* Up to 64-bit address + 64-bit size */
+
+ if (areas > 8) {
+ printf("%s: num areas %d exceeds hardcoded limit %d\n",
+ __func__, areas, 8);
+ return -1;
+ }
+
+ err = fdt_check_header(blob);
+ if (err < 0) {
+ printf("%s: %s\n", __func__, fdt_strerror(err));
+ return err;
+ }
+
+ /* find or create "/memory" node. */
+ nodeoffset = fdt_find_or_add_subnode(blob, 0, "memory");
+ if (nodeoffset < 0)
+ return nodeoffset;
+
+ len = fdt_pack_reg(blob, tmp, start, size, areas);
+
+ err = fdt_setprop(blob, nodeoffset, "linux,usable-memory", tmp, len);
+ if (err < 0) {
+ printf("WARNING: could not set %s %s.\n",
+ "reg", fdt_strerror(err));
+ return err;
+ }
+
+ return 0;
+}
+
void fdt_fixup_ethernet(void *fdt)
{
int i = 0, j, prop;
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 27fe564f0b..a868b6710e 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -102,6 +102,8 @@ static inline int fdt_fixup_memory_banks(void *blob, u64
start[], u64 size[],
}
#endif
+int fdt_set_usable_memory(void *blob, u64 start[], u64 size[], int banks);
+
void fdt_fixup_ethernet(void *fdt);
int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
const void *val, int len, int create);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/2] android: colibri_imx7: reserve DDR memory for Cortex-M4
i.MX 7's Cortex-M4 core can run from DDR and uses DDR memory for the rpmsg communication. Both use cases need a fixed location of memory reserved. For the rpmsg use case the reserved area needs to be in sync with the kernel's hardcoded vring descriptor location. Introduce support for adding linux,usable-memory property to carve out 1MB of memory in case the M4 core is running. Also make sure that the i.MX 7 specific rpmsg driver does not get loaded in case we do not carve out memory. Igor Opaniuk (2): common: fdt_support: add support for setting usable memory board: colibri_imx7: reserve DDR memory for Cortex-M4 arch/arm/include/asm/mach-imx/sys_proto.h | 2 ++ board/toradex/colibri_imx7/colibri_imx7.c | 37 +++ common/fdt_support.c | 35 + include/fdt_support.h | 2 ++ 4 files changed, 76 insertions(+) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] android: colibri_imx7: reserve DDR memory for Cortex-M4
On Fri, Jul 12, 2019 at 1:50 PM Igor Opaniuk wrote: > > i.MX 7's Cortex-M4 core can run from DDR and uses DDR memory for > the rpmsg communication. Both use cases need a fixed location of > memory reserved. For the rpmsg use case the reserved area needs > to be in sync with the kernel's hardcoded vring descriptor location. > > Introduce support for adding linux,usable-memory property to carve > out 1MB of memory in case the M4 core is running. Also make sure > that the i.MX 7 specific rpmsg driver does not get loaded in case > we do not carve out memory. > > Igor Opaniuk (2): > common: fdt_support: add support for setting usable memory > board: colibri_imx7: reserve DDR memory for Cortex-M4 > > arch/arm/include/asm/mach-imx/sys_proto.h | 2 ++ > board/toradex/colibri_imx7/colibri_imx7.c | 37 +++ > common/fdt_support.c | 35 + > include/fdt_support.h | 2 ++ > 4 files changed, 76 insertions(+) > > -- > 2.17.1 > Please, don't pay attention to "android" keyword in the title (actually nothing related to android), it's just a glitch. -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_selftest: do not call CloseEvent() after ExitBootServices()
Boot services are not available after calling ExitBootServices(). So we
should not try to close an event here.
Signed-off-by: Heinrich Schuchardt
---
.../efi_selftest_exitbootservices.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_exitbootservices.c
b/lib/efi_selftest/efi_selftest_exitbootservices.c
index f1a136044d..4fecd1b415 100644
--- a/lib/efi_selftest/efi_selftest_exitbootservices.c
+++ b/lib/efi_selftest/efi_selftest_exitbootservices.c
@@ -55,28 +55,6 @@ static int setup(const efi_handle_t handle,
return EFI_ST_SUCCESS;
}
-/*
- * Tear down unit test.
- *
- * Close the event created in setup.
- *
- * @return:EFI_ST_SUCCESS for success
- */
-static int teardown(void)
-{
- efi_status_t ret;
-
- if (event_notify) {
- ret = boottime->close_event(event_notify);
- event_notify = NULL;
- if (ret != EFI_SUCCESS) {
- efi_st_error("could not close event\n");
- return EFI_ST_FAILURE;
- }
- }
- return EFI_ST_SUCCESS;
-}
-
/*
* Execute unit test.
*
@@ -107,5 +85,4 @@ EFI_UNIT_TEST(exitbootservices) = {
.phase = EFI_SETUP_BEFORE_BOOTTIME_EXIT,
.setup = setup,
.execute = execute,
- .teardown = teardown,
};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] imx8qm/qxp: Set SPL TEXT base to OCRAM base
On Fri, 12 Jul 2019 at 12:34, Ye Li wrote: > > Modify the SPL TEXT base from OCRAM alias to OCRAM base 0x10, so > we can use full OCRAM not limit to 96KB > > Signed-off-by: Ye Li Reviewed-by: Oleksandr Suvorov > --- > configs/imx8qm_mek_defconfig | 1 + > configs/imx8qxp_mek_defconfig | 1 + > include/configs/imx8qm_mek.h | 1 - > 3 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configs/imx8qm_mek_defconfig b/configs/imx8qm_mek_defconfig > index a4d2619..544a5d9 100644 > --- a/configs/imx8qm_mek_defconfig > +++ b/configs/imx8qm_mek_defconfig > @@ -3,6 +3,7 @@ CONFIG_SPL_SYS_ICACHE_OFF=y > CONFIG_SPL_SYS_DCACHE_OFF=y > CONFIG_ARCH_IMX8=y > CONFIG_SYS_TEXT_BASE=0x8002 > +CONFIG_SPL_TEXT_BASE=0x10 > CONFIG_SPL_GPIO_SUPPORT=y > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig > index 92927e3..73d6d13 100644 > --- a/configs/imx8qxp_mek_defconfig > +++ b/configs/imx8qxp_mek_defconfig > @@ -3,6 +3,7 @@ CONFIG_SPL_SYS_ICACHE_OFF=y > CONFIG_SPL_SYS_DCACHE_OFF=y > CONFIG_ARCH_IMX8=y > CONFIG_SYS_TEXT_BASE=0x8002 > +CONFIG_SPL_TEXT_BASE=0x10 > CONFIG_SPL_GPIO_SUPPORT=y > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/include/configs/imx8qm_mek.h b/include/configs/imx8qm_mek.h > index d06ed61..148a4ff 100644 > --- a/include/configs/imx8qm_mek.h > +++ b/include/configs/imx8qm_mek.h > @@ -10,7 +10,6 @@ > #include > > #ifdef CONFIG_SPL_BUILD > -#define CONFIG_SPL_TEXT_BASE 0x0 > #define CONFIG_SPL_MAX_SIZE(124 * 1024) > #define CONFIG_SYS_MONITOR_LEN (1024 * 1024) > #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR > -- > 2.7.4 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Best regards Oleksandr Suvorov cryo...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] common: fdt_support: add support for setting usable memory
On Fri, 12 Jul 2019 at 13:51, Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Add support for setting linux,usable-memory property in the memory
> node of device tree for the kernel [1].
>
> This property holds a base address and size, describing a
> limited region in which memory may be considered available for use by
> the kernel. Memory outside of this range is not available for use.
>
> [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>
> Signed-off-by: Igor Opaniuk
> Signed-off-by: Sanchayan Maity
> Signed-off-by: Stefan Agner
> Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> ---
>
> common/fdt_support.c | 35 +++
> include/fdt_support.h | 2 ++
> 2 files changed, 37 insertions(+)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index f31e9b0cc5..57413c7a4d 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -473,6 +473,41 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size)
> return fdt_fixup_memory_banks(blob, &start, &size, 1);
> }
>
> +int fdt_set_usable_memory(void *blob, u64 start[], u64 size[], int areas)
> +{
> + int err, nodeoffset;
> + int len;
> + u8 tmp[8 * 16]; /* Up to 64-bit address + 64-bit size */
> +
> + if (areas > 8) {
> + printf("%s: num areas %d exceeds hardcoded limit %d\n",
> + __func__, areas, 8);
> + return -1;
> + }
> +
> + err = fdt_check_header(blob);
> + if (err < 0) {
> + printf("%s: %s\n", __func__, fdt_strerror(err));
> + return err;
> + }
> +
> + /* find or create "/memory" node. */
> + nodeoffset = fdt_find_or_add_subnode(blob, 0, "memory");
> + if (nodeoffset < 0)
> + return nodeoffset;
> +
> + len = fdt_pack_reg(blob, tmp, start, size, areas);
> +
> + err = fdt_setprop(blob, nodeoffset, "linux,usable-memory", tmp, len);
> + if (err < 0) {
> + printf("WARNING: could not set %s %s.\n",
> + "reg", fdt_strerror(err));
> + return err;
> + }
> +
> + return 0;
> +}
> +
> void fdt_fixup_ethernet(void *fdt)
> {
> int i = 0, j, prop;
> diff --git a/include/fdt_support.h b/include/fdt_support.h
> index 27fe564f0b..a868b6710e 100644
> --- a/include/fdt_support.h
> +++ b/include/fdt_support.h
> @@ -102,6 +102,8 @@ static inline int fdt_fixup_memory_banks(void *blob, u64
> start[], u64 size[],
> }
> #endif
>
> +int fdt_set_usable_memory(void *blob, u64 start[], u64 size[], int banks);
> +
> void fdt_fixup_ethernet(void *fdt);
> int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
> const void *val, int len, int create);
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best regards
Oleksandr Suvorov
cryo...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx8: Jump from alias to OCRAM address at SPL init
On Fri, 12 Jul 2019 at 12:34, Ye Li wrote: > > When running SPL on iMX8, the A core starts at address 0 > which is a alias to OCRAM 0x10. > The alias only map first 96KB of OCRAM, so this require the > SPL size can't beyond 96KB. But when using SPL DM, the size increase > significantly and may exceed 96KB. > So to fix the problem, we will change SPL linker address to OCRAM > address 0x10. And then jump to the absolute address not the PC relative > address for entering OCRAM. > > Signed-off-by: Ye Li Reviewed-by: Oleksandr Suvorov > --- > arch/arm/Kconfig | 1 + > arch/arm/include/asm/arch-imx8/boot0.h | 21 + > 2 files changed, 22 insertions(+) > create mode 100644 arch/arm/include/asm/arch-imx8/boot0.h > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 01ff57c..6ea21b7 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -755,6 +755,7 @@ config ARCH_IMX8 > select ARM64 > select DM > select OF_CONTROL > + select ENABLE_ARM_SOC_BOOT0_HOOK > > config ARCH_IMX8M > bool "NXP i.MX8M platform" > diff --git a/arch/arm/include/asm/arch-imx8/boot0.h > b/arch/arm/include/asm/arch-imx8/boot0.h > new file mode 100644 > index 000..5ce781a > --- /dev/null > +++ b/arch/arm/include/asm/arch-imx8/boot0.h > @@ -0,0 +1,21 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright 2019 NXP > + */ > + > +#if defined(CONFIG_SPL_BUILD) > + /* > +* We use absolute address not PC relative address to jump. > +* When running SPL on iMX8, the A core starts at address 0, a alias > to OCRAM 0x10, > +* our linker address for SPL is from 0x10. So using absolute > address can jump to > +* the OCRAM address from the alias. > +* The alias only map first 96KB of OCRAM, so this require the SPL > size can't beyond 96KB. > +* But when using SPL DM, the size increase significantly and may > exceed 96KB. > +* That's why we have to jump to OCRAM. > +*/ > + > + ldr x0, =reset > + br x0 > +#else > + b reset > +#endif > -- > 2.7.4 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Best regards Oleksandr Suvorov Toradex AG Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 4800 (main line) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/5] Fixes and improvements in BCB and Android docs
Resubmit the diff between [1] and [2] of the BCB/Android series, since
the former has been pushed to master instead of the latter.
[1] https://patchwork.ozlabs.org/cover/1104242/
("[v3,0/3] Add 'bcb' command to read/modify/write Android BCB")
[2] https://patchwork.ozlabs.org/cover/1128661/
("[v4,0/4] Add 'bcb' command to read/modify/write Android BCB")
Eugeniu Rosca (5):
doc: Move README.android-fastboot-protocol to doc/android/
treewide: Fix stale references of Android docs
cmd: bcb: Fix duplicated handling in two case-branches
cmd: bcb: Use strcmp() instead of strncmp() for string literals
cmd: bcb: Apply non-functional refinements
cmd/Kconfig | 2 +-
cmd/bcb.c | 68 +--
.../fastboot-protocol.txt}| 0
doc/android/fastboot.txt | 2 +-
test/py/tests/test_avb.py | 2 +-
5 files changed, 36 insertions(+), 38 deletions(-)
rename doc/{README.android-fastboot-protocol => android/fastboot-protocol.txt}
(100%)
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/5] doc: Move README.android-fastboot-protocol to doc/android/
Commit 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB
overview") missed relocating README.android-fastboot-protocol. Fix it.
Fixes: 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB overview")
Signed-off-by: Eugeniu Rosca
---
.../fastboot-protocol.txt}| 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename doc/{README.android-fastboot-protocol => android/fastboot-protocol.txt}
(100%)
diff --git a/doc/README.android-fastboot-protocol
b/doc/android/fastboot-protocol.txt
similarity index 100%
rename from doc/README.android-fastboot-protocol
rename to doc/android/fastboot-protocol.txt
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] cmd: bcb: Fix duplicated handling in two case-branches
Fix warning V1037 reported by PVS-Studio Static Analyzer:
Two or more case-branches perform the same actions. Check lines: 49, 53
Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
Signed-off-by: Eugeniu Rosca
---
cmd/bcb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index 2bd5a744deb5..3b1c7434e287 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -46,9 +46,6 @@ static int bcb_is_misused(int argc, char *const argv[])
switch (cmd) {
case BCB_CMD_LOAD:
- if (argc != 3)
- goto err;
- break;
case BCB_CMD_FIELD_SET:
if (argc != 3)
goto err;
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/5] treewide: Fix stale references of Android docs
Commit 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB
overview") left some obsolete references of Android documents/paths.
This has been pointed out by Sam (thanks!) in:
https://patchwork.ozlabs.org/patch/1104245/#2208134
Fixes: 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB overview")
Reported-by: Sam Protsenko
Suggested-by: Sam Protsenko
Signed-off-by: Eugeniu Rosca
---
cmd/Kconfig | 2 +-
doc/android/fastboot.txt | 2 +-
test/py/tests/test_avb.py | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3afb760a816f..3cf8233df62e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -707,7 +707,7 @@ config CMD_FASTBOOT
Android devices. Fastboot requires either the network stack
enabled or support for acting as a USB device.
- See doc/README.android-fastboot for more information.
+ See doc/android/fastboot.txt for more information.
config CMD_FDC
bool "fdcboot - Boot from floppy device"
diff --git a/doc/android/fastboot.txt b/doc/android/fastboot.txt
index 431191c473f2..dcf824713f94 100644
--- a/doc/android/fastboot.txt
+++ b/doc/android/fastboot.txt
@@ -6,7 +6,7 @@ Overview
The protocol that is used over USB and UDP is described in the
-``README.android-fastboot-protocol`` file in the same directory.
+``fastboot-protocol.txt`` file in the same directory.
The current implementation supports the following standard commands:
diff --git a/test/py/tests/test_avb.py b/test/py/tests/test_avb.py
index 2bb75ed6e2a2..813242343555 100644
--- a/test/py/tests/test_avb.py
+++ b/test/py/tests/test_avb.py
@@ -8,7 +8,7 @@
This tests Android Verified Boot 2.0 support in U-boot:
For additional details about how to build proper vbmeta partition
-check doc/README.avb2
+check doc/android/avb2.txt
For configuration verification:
- Corrupt boot partition and check for failure
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] cmd: bcb: Use strcmp() instead of strncmp() for string literals
Quote from https://patchwork.ozlabs.org/patch/1104244/#2210814:
--8<---
strncmp() is chosen for the sake of paranoid/defensive programming.
Indeed, strncmp() is not really needed when comparing a variable
with a string literal. We expect strcmp() to behave safely even if the
string variable is not NUL-terminated.
In the same scenario, Linux v5.2-rc7 uses both strcmp() and strncmp(),
but the frequency of strcmp() is higher:
$ git --version
git version 2.22.0
$ (Linux 5.2-rc7) git grep -En 'strncmp\([^"]*"[[:alnum:]]+"' | wc -l
1066
$ (Linux 5.2-rc7) git grep -En 'strcmp\([^"]*"[[:alnum:]]+"' | wc -l
1968
A quick "strcmp vs strncmp" object size test shows that strcmp()
generates smaller memory footprint (gcc-8, x86_64):
$ (U-Boot) size cmd/bcb-strncmp.o cmd/bcb-strcmp.o
textdata bss dec hex filename
3373 4002048582116bd cmd/bcb-strncmp.o
3314 400204857621682 cmd/bcb-strcmp.o
So, overall, I agree to use strcmp() whenever variables are compared
with string literals.
--8<---
Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
Reported-by: Simon Glass
Signed-off-by: Eugeniu Rosca
---
cmd/bcb.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index 3b1c7434e287..c7138a5179a9 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -24,17 +24,17 @@ static struct bootloader_message bcb = { { 0 } };
static int bcb_cmd_get(char *cmd)
{
- if (!strncmp(cmd, "load", sizeof("load")))
+ if (!strcmp(cmd, "load"))
return BCB_CMD_LOAD;
- if (!strncmp(cmd, "set", sizeof("set")))
+ if (!strcmp(cmd, "set"))
return BCB_CMD_FIELD_SET;
- if (!strncmp(cmd, "clear", sizeof("clear")))
+ if (!strcmp(cmd, "clear"))
return BCB_CMD_FIELD_CLEAR;
- if (!strncmp(cmd, "test", sizeof("test")))
+ if (!strcmp(cmd, "test"))
return BCB_CMD_FIELD_TEST;
- if (!strncmp(cmd, "store", sizeof("store")))
+ if (!strcmp(cmd, "store"))
return BCB_CMD_STORE;
- if (!strncmp(cmd, "dump", sizeof("dump")))
+ if (!strcmp(cmd, "dump"))
return BCB_CMD_FIELD_DUMP;
else
return -1;
@@ -85,21 +85,21 @@ err:
static int bcb_field_get(char *name, char **field, int *size)
{
- if (!strncmp(name, "command", sizeof("command"))) {
- *field = bcb.command;
- *size = sizeof(bcb.command);
- } else if (!strncmp(name, "status", sizeof("status"))) {
- *field = bcb.status;
- *size = sizeof(bcb.status);
- } else if (!strncmp(name, "recovery", sizeof("recovery"))) {
- *field = bcb.recovery;
- *size = sizeof(bcb.recovery);
- } else if (!strncmp(name, "stage", sizeof("stage"))) {
- *field = bcb.stage;
- *size = sizeof(bcb.stage);
- } else if (!strncmp(name, "reserved", sizeof("reserved"))) {
- *field = bcb.reserved;
- *size = sizeof(bcb.reserved);
+ if (!strcmp(name, "command")) {
+ *fieldp = bcb.command;
+ *sizep = sizeof(bcb.command);
+ } else if (!strcmp(name, "status")) {
+ *fieldp = bcb.status;
+ *sizep = sizeof(bcb.status);
+ } else if (!strcmp(name, "recovery")) {
+ *fieldp = bcb.recovery;
+ *sizep = sizeof(bcb.recovery);
+ } else if (!strcmp(name, "stage")) {
+ *fieldp = bcb.stage;
+ *sizep = sizeof(bcb.stage);
+ } else if (!strcmp(name, "reserved")) {
+ *fieldp = bcb.reserved;
+ *sizep = sizeof(bcb.reserved);
} else {
printf("Error: Unknown bcb field '%s'\n", name);
return -1;
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] board: colibri_imx7: reserve DDR memory for Cortex-M4
On Fri, 12 Jul 2019 at 13:50, Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> i.MX 7's Cortex-M4 core can run from DDR and uses DDR memory for
> the rpmsg communication. Both use cases need a fixed location of
> memory reserved. For the rpmsg use case the reserved area needs
> to be in sync with the kernel's hardcoded vring descriptor location.
>
> Use the linux,usable-memory property to carve out 1MB of memory
> in case the M4 core is running. Also make sure that the i.MX 7
> specific rpmsg driver does not get loaded in case we do not carve
> out memory.
>
> Signed-off-by: Stefan Agner
> Signed-off-by: Igor Opaniuk
>
> Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> ---
>
> arch/arm/include/asm/mach-imx/sys_proto.h | 2 ++
> board/toradex/colibri_imx7/colibri_imx7.c | 37 +++
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h
> b/arch/arm/include/asm/mach-imx/sys_proto.h
> index 4925dd7894..775cd3df40 100644
> --- a/arch/arm/include/asm/mach-imx/sys_proto.h
> +++ b/arch/arm/include/asm/mach-imx/sys_proto.h
> @@ -113,6 +113,8 @@ void init_src(void);
> void init_snvs(void);
> void imx_wdog_disable_powerdown(void);
>
> +int arch_auxiliary_core_check_up(u32 core_id);
> +
> int board_mmc_get_env_dev(int devno);
>
> int nxp_board_rev(void);
> diff --git a/board/toradex/colibri_imx7/colibri_imx7.c
> b/board/toradex/colibri_imx7/colibri_imx7.c
> index 0eb83474c4..6059088bda 100644
> --- a/board/toradex/colibri_imx7/colibri_imx7.c
> +++ b/board/toradex/colibri_imx7/colibri_imx7.c
> @@ -333,6 +333,43 @@ int checkboard(void)
> #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
> int ft_board_setup(void *blob, bd_t *bd)
> {
> +#if defined(CONFIG_IMX_BOOTAUX)
> + int up;
> +
> + up = arch_auxiliary_core_check_up(0);
> + if (up) {
> + int ret;
> + int areas = 1;
> + u64 start[2], size[2];
> +
> + /*
> +* Reserve 1MB of memory for M4 (1MiB is also the minimum
> +* alignment for Linux due to MMU section size restrictions).
> +*/
> + start[0] = gd->bd->bi_dram[0].start;
> + size[0] = SZ_256M - SZ_1M;
> +
> + /* If needed, create a second entry for memory beyond 256M */
> + if (gd->bd->bi_dram[0].size > SZ_256M) {
> + start[1] = gd->bd->bi_dram[0].start + SZ_256M;
> + size[1] = gd->bd->bi_dram[0].size - SZ_256M;
> + areas = 2;
> + }
> +
> + ret = fdt_set_usable_memory(blob, start, size, areas);
> + if (ret) {
> + eprintf("Cannot set usable memory\n");
> + return ret;
> + }
> + } else {
> + int off;
> +
> + off = fdt_node_offset_by_compatible(blob, -1,
> + "fsl,imx7d-rpmsg");
> + if (off > 0)
> + fdt_status_disabled(blob, off);
> + }
> +#endif
> #if defined(CONFIG_FDT_FIXUP_PARTITIONS)
> static const struct node_info nodes[] = {
> { "fsl,imx7d-gpmi-nand", MTD_DEV_TYPE_NAND, }, /* NAND flash
> */
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best regards
Oleksandr Suvorov
Toradex AG
Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500
4800 (main line)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] armv8: ls1028aqds: switch LS1028A QDS board to I2C DM
Replace legacy I2C_EARLY_INIT with dm-pre-reloc dts property.
Signed-off-by: Alex Marginean
---
Depends on this patch series:
https://patchwork.ozlabs.org/project/uboot/list/?series=118778
arch/arm/dts/fsl-ls1028a-qds.dts | 1 +
include/configs/ls1028aqds.h | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1028a-qds.dts b/arch/arm/dts/fsl-ls1028a-qds.dts
index e308989a00..717ab0a994 100644
--- a/arch/arm/dts/fsl-ls1028a-qds.dts
+++ b/arch/arm/dts/fsl-ls1028a-qds.dts
@@ -37,6 +37,7 @@
&i2c0 {
status = "okay";
+ u-boot,dm-pre-reloc;
fpga@66 {
#address-cells = <1>;
diff --git a/include/configs/ls1028aqds.h b/include/configs/ls1028aqds.h
index be018ef2be..b0e9441a48 100644
--- a/include/configs/ls1028aqds.h
+++ b/include/configs/ls1028aqds.h
@@ -16,7 +16,6 @@
#define CONFIG_DIMM_SLOTS_PER_CTLR 2
#define CONFIG_QIXIS_I2C_ACCESS
-#define CONFIG_SYS_I2C_EARLY_INIT
/*
* QIXIS Definitions
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] configs: ls1028aqds: enable I2C and GPIO DM
LS1028A was already converted to I2C/GPIO DM, move the QDS board over too. Signed-off-by: Alex Marginean --- configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 5 - configs/ls1028aqds_tfa_defconfig | 5 - 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index 4a2b354008..76c9af5ef3 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_TARGET_LS1028AQDS=y +CONFIG_SYS_MALLOC_F_LEN=0x6000 CONFIG_SECURE_BOOT=y CONFIG_SYS_FSL_SDHC_CLK_DIV=1 CONFIG_TFABOOT=y @@ -8,7 +9,6 @@ CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -# CONFIG_SYS_MALLOC_F is not set CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y @@ -31,6 +31,9 @@ CONFIG_NETCONSOLE=y CONFIG_DM=y CONFIG_SCSI_AHCI=y CONFIG_SATA_CEVA=y +CONFIG_DM_GPIO=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index b315910414..7c98474d73 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_TARGET_LS1028AQDS=y +CONFIG_SYS_MALLOC_F_LEN=0x6000 CONFIG_SYS_FSL_SDHC_CLK_DIV=1 CONFIG_TFABOOT=y CONFIG_NR_DRAM_BANKS=2 @@ -7,7 +8,6 @@ CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -# CONFIG_SYS_MALLOC_F is not set CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y @@ -34,6 +34,9 @@ CONFIG_DM=y CONFIG_SCSI_AHCI=y CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y +CONFIG_DM_GPIO=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] doc: Move README.android-fastboot-protocol to doc/android/
Hi Eugeniu,
On Fri, Jul 12, 2019 at 2:21 PM Eugeniu Rosca wrote:
>
> Commit 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB
> overview") missed relocating README.android-fastboot-protocol. Fix it.
>
> Fixes: 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB
> overview")
> Signed-off-by: Eugeniu Rosca
> ---
> .../fastboot-protocol.txt}| 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename doc/{README.android-fastboot-protocol =>
> android/fastboot-protocol.txt} (100%)
>
> diff --git a/doc/README.android-fastboot-protocol
> b/doc/android/fastboot-protocol.txt
> similarity index 100%
> rename from doc/README.android-fastboot-protocol
> rename to doc/android/fastboot-protocol.txt
> --
> 2.22.0
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] treewide: Fix stale references of Android docs
On Fri, Jul 12, 2019 at 2:21 PM Eugeniu Rosca wrote:
>
> Commit 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB
> overview") left some obsolete references of Android documents/paths.
>
> This has been pointed out by Sam (thanks!) in:
> https://patchwork.ozlabs.org/patch/1104245/#2208134
>
> Fixes: 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB
> overview")
> Reported-by: Sam Protsenko
> Suggested-by: Sam Protsenko
> Signed-off-by: Eugeniu Rosca
> ---
> cmd/Kconfig | 2 +-
> doc/android/fastboot.txt | 2 +-
> test/py/tests/test_avb.py | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 3afb760a816f..3cf8233df62e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -707,7 +707,7 @@ config CMD_FASTBOOT
> Android devices. Fastboot requires either the network stack
> enabled or support for acting as a USB device.
>
> - See doc/README.android-fastboot for more information.
> + See doc/android/fastboot.txt for more information.
>
> config CMD_FDC
> bool "fdcboot - Boot from floppy device"
> diff --git a/doc/android/fastboot.txt b/doc/android/fastboot.txt
> index 431191c473f2..dcf824713f94 100644
> --- a/doc/android/fastboot.txt
> +++ b/doc/android/fastboot.txt
> @@ -6,7 +6,7 @@ Overview
>
>
> The protocol that is used over USB and UDP is described in the
> -``README.android-fastboot-protocol`` file in the same directory.
> +``fastboot-protocol.txt`` file in the same directory.
>
> The current implementation supports the following standard commands:
>
> diff --git a/test/py/tests/test_avb.py b/test/py/tests/test_avb.py
> index 2bb75ed6e2a2..813242343555 100644
> --- a/test/py/tests/test_avb.py
> +++ b/test/py/tests/test_avb.py
> @@ -8,7 +8,7 @@
> This tests Android Verified Boot 2.0 support in U-boot:
>
> For additional details about how to build proper vbmeta partition
> -check doc/README.avb2
> +check doc/android/avb2.txt
>
> For configuration verification:
> - Corrupt boot partition and check for failure
> --
> 2.22.0
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] cmd: bcb: Fix duplicated handling in two case-branches
On Fri, Jul 12, 2019 at 2:21 PM Eugeniu Rosca wrote:
>
> Fix warning V1037 reported by PVS-Studio Static Analyzer:
> Two or more case-branches perform the same actions. Check lines: 49, 53
>
> Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
> Signed-off-by: Eugeniu Rosca
> ---
> cmd/bcb.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/cmd/bcb.c b/cmd/bcb.c
> index 2bd5a744deb5..3b1c7434e287 100644
> --- a/cmd/bcb.c
> +++ b/cmd/bcb.c
> @@ -46,9 +46,6 @@ static int bcb_is_misused(int argc, char *const argv[])
>
> switch (cmd) {
> case BCB_CMD_LOAD:
> - if (argc != 3)
> - goto err;
> - break;
> case BCB_CMD_FIELD_SET:
> if (argc != 3)
> goto err;
> --
> 2.22.0
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] cmd: bcb: Apply non-functional refinements
These have been reported by Simon in [1] and fixed in [2].
However, since [1] has already been pushed to u-boot/master, the
improvements incorporated in [2] are now extracted and resubmitted.
[1] https://patchwork.ozlabs.org/patch/1104244/#2200259
[2] https://patchwork.ozlabs.org/cover/1128661/
("[v4,0/4] Add 'bcb' command to read/modify/write Android BCB")
Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
Reported-by: Simon Glass
Signed-off-by: Eugeniu Rosca
---
cmd/bcb.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index c7138a5179a9..9626f2c69e34 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -83,7 +83,7 @@ err:
return -1;
}
-static int bcb_field_get(char *name, char **field, int *size)
+static int bcb_field_get(char *name, char **fieldp, int *sizep)
{
if (!strcmp(name, "command")) {
*fieldp = bcb.command;
@@ -108,8 +108,8 @@ static int bcb_field_get(char *name, char **field, int
*size)
return 0;
}
-static int
-do_bcb_load(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+static int do_bcb_load(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
{
struct blk_desc *desc;
disk_partition_t info;
@@ -119,28 +119,28 @@ do_bcb_load(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
ret = blk_get_device_by_str("mmc", argv[1], &desc);
if (ret < 0)
- goto err_1;
+ goto err_read_fail;
part = simple_strtoul(argv[2], &endp, 0);
if (*endp == '\0') {
ret = part_get_info(desc, part, &info);
if (ret)
- goto err_1;
+ goto err_read_fail;
} else {
part = part_get_info_by_name(desc, argv[2], &info);
if (part < 0) {
ret = part;
- goto err_1;
+ goto err_read_fail;
}
}
cnt = DIV_ROUND_UP(sizeof(struct bootloader_message), info.blksz);
if (cnt > info.size)
- goto err_2;
+ goto err_too_small;
if (blk_dread(desc, info.start, cnt, &bcb) != cnt) {
ret = -EIO;
- goto err_1;
+ goto err_read_fail;
}
bcb_dev = desc->devnum;
@@ -148,10 +148,10 @@ do_bcb_load(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
debug("%s: Loaded from mmc %d:%d\n", __func__, bcb_dev, bcb_part);
return CMD_RET_SUCCESS;
-err_1:
+err_read_fail:
printf("Error: mmc %s:%s read failed (%d)\n", argv[1], argv[2], ret);
goto err;
-err_2:
+err_too_small:
printf("Error: mmc %s:%s too small!", argv[1], argv[2]);
goto err;
err:
@@ -304,7 +304,8 @@ static int do_bcb(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
return CMD_RET_USAGE;
if (bcb_is_misused(argc, argv)) {
- /* We try to improve the user experience by reporting the
+ /*
+* We try to improve the user experience by reporting the
* root-cause of misusage, so don't return CMD_RET_USAGE,
* since the latter prints out the full-blown help text
*/
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/6] android: implement A/B boot process
On Fri, Jul 5, 2019 at 3:37 PM Igor Opaniuk wrote: > > *** This patch series depends on [4], [5], [6] and should be > applied after these paticular patches. > > This patch series adds support for Android A/B boot process [1]. > Main steps of A/B boot process are: > - A/B metadata integrity check > - looking for the current slot (where the system should be > booting from) > - getting the name of the current boot partition (boot_a or boot_b) > and loading the corresponding Android boot image > - getting the name of the current system partition (system_a or > system_b) and passing of its full name via kernel command line > (like 'root=/dev/mmcblk1p11') > - passing current slot via kernel command line (like > 'androidboot.slot_suffix=_a') and via A/B metadata (e.g. via > misc partition) > - A/B metadata processing: setting the boot success flag for > current slot, handling the retry counter, etc > > A/B metadata is organized according to Android reference [2] and stored > on 'misc' partition. On the first A/B boot process, when 'misc' > partition doesn't contain required data, default A/B metadata will be > created and stored in 'misc' partition. In the end of the Android boot, > 'update_verifier' and 'update_engine' services are processing the > A/B metadata through the Boot Control HAL. To confirm the boot was > successful using current slot, "boot success" flag must be set on > Android side. > > To enable Android A/B support in U-Boot: > 1. Set the following config options: > > CONFIG_ANDROID_AB=y > CONFIG_CMD_AB_SELECT=y > > 2. Change the disk layout so that it has sloted boot partitions. > E.g. instead of 'boot' and 'system' partitions there should be > 'boot_a', 'boot_b', 'system_a' and 'system_b' partitions. > > To be able to actually test this patch series, the A/B features must > be implemented and enabled in Android as well (see [1] for details). > > Documentation and corresponding test for A/B boot is present here. The > last patch in this series integrates A/B boot support on AM57xx based > boards (though it's not enabled by default). Future users of A/B boot > feature can use it as a reference. > > This series is a part of previous submission [3] by Alex Deymo. It > contains only A/B feature that was stripped out from there with some > modifications for using with "bootm" command preferred in upstream. > > Changes in v5: > * Move tests to android subdir > * In new version of sgdisk (0.8.10.2) short options don't work. That can > be a regression in sgdisk, but anyway let's use long options, because > otherwise the test fails. > * Fix boot part size (preserve the new value). > * Move doc to proper place > * Handle ret values properly for blk_dread()/blk_dwrite properly using > IS_ERR_VALUE() macro > > Changes in v4: > * Removed android_bl_msg.h and re-used the one, which was > introduced by Eugeniu Rosca in [4] and [5]. > * Initially we had intention to use "bcb" command and scripting for > providing proper boot sequence logic (slot selection, decrementing the > counter for each slot), but found out that it's better to keep using > a dedicated command ab_select to avoid huge amount of scripting in > the headers in includes/config for each platform. > * Removed ANDROID_ prefix in multiple macros. > * Addressed comments from Simon > > Changes in v3: > * Minor fixes in the ab metadata handling (added additional sanity checks). > * As Ruslan Trofymenko left Linaro and won't address comments anymore, > continue (added my S-b tag) upstreaming patches on my own. > > Changes in v2: > * 'android_ab_select' command is renamed to 'ab_select' command and > moved to separate 'Android support commands' menu > * For am57xx boards slotted sections (e.g. system_a and system_b) are > added to the default sections if CONFIG_CMD_AB_SELECT flag is > defined > * Returned function error codes are clarified (errno using) > * Some types constants and files are renamed > * Assertion condition is clarified in test case > * 'debug' calls are changed to 'log_debug' > * The Guide is clarified by the results of changes > > [1] https://source.android.com/devices/tech/ota/ab/ab_implement > [2] > bootable/recovery/bootloader_message/include/bootloader_message/bootloader_message.h > [3] https://lists.denx.de/pipermail/u-boot/2017-April/285841.html > [4] https://patchwork.ozlabs.org/patch/1080394/ > [5] https://patchwork.ozlabs.org/patch/1104243/ > [6] https://patchwork.ozlabs.org/patch/1116012/ > > > Ruslan Trofymenko (6): > disk: part: Extend API to get partition info > common: Implement A/B metadata > cmd: Add 'ab_select' command > test/py: Add base test case for A/B updates > doc: android: Add simple guide for A/B updates > env: am57xx: Implement A/B boot process > > cmd/Kconfig | 15 ++ > cmd/Makefile | 1 +
Re: [U-Boot] [PATCH v3 4/4] test: pci_ep: add basic pci_ep tests
On Fri, Jul 12, 2019 at 5:23 AM Tom Rini wrote: > On Thu, Jul 11, 2019 at 06:04:55PM -0400, Tom Rini wrote: > > On Sat, Apr 27, 2019 at 11:15:24AM +0300, Ramon Fried wrote: > > > > > Add basic PCI endpoint sandbox testing. > > > > > > Signed-off-by: Ramon Fried > > > Reviewed-by: Simon Glass > > > > Applied to u-boot/master, thanks! > > This is however now breaking: > https://travis-ci.org/u-boot/u-boot/jobs/557569099 > > -- > Tom > I don't know even where to start here. Simon, can you look at the log ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] board: Add support for iMXQXP AI_ML board
Hi Manivannan,
On Thu, Jul 11, 2019 at 3:07 PM Manivannan Sadhasivam
wrote:
>
> This commit adds initial board support for iMXQXP AI_ML board from
iMXQXP --> i.MX8QXP
> Einfochips. This board is one of the 96Boards Consumer Edition and AI boards
> of the 96Boards family based on i.MXQXP SoC from NXP/Freescale.
i.MXQXP -> i.MX8QXP
> --- /dev/null
> +++ b/board/einfochips/imx8qxp_ai_ml/README
> @@ -0,0 +1,49 @@
> +U-Boot for the Einfochips i.MX8QXP AI_ML board
> +
> +Quick Start
> +===
> +
> +- Build the ARM Trusted firmware binary
The first instruction here is to build the ATF...
> +- Get scfw_tcm.bin and ahab-container.img
> +- Build U-Boot
> +- Flash the binary into the SD card
> +- Boot
> +
> +Get and Build the ARM Trusted firmware
> +==
> +
> +$ git clone https://source.codeaurora.org/external/imx/imx-atf
and later it is described how to get the ATF.
Looks like the order needs to be inverted.
> +void detail_board_ddr_info(void)
> +{
> + puts("\nDDR");
Is this function really useful as its only purpose is to print "DDR" ?
> +}
> +
> +/*
> + * Board specific reset that is system reset.
> + */
You could use single line comment style instead.
> +#ifdef CONFIG_SPL_LOAD_FIT
> +int board_fit_config_name_match(const char *name)
> +{
> + /* Just empty function now - can't decide what to choose */
> + debug("%s: %s\n", __func__, name);
It seems you don't need this function then.
> +CONFIG_ARM=y
> +CONFIG_SPL_SYS_ICACHE_OFF=y
> +CONFIG_SPL_SYS_DCACHE_OFF=y
Why do you turn off the caches?
> +CONFIG_PHY_GIGE=y
> +CONFIG_FEC_MXC_SHARE_MDIO=y
> +CONFIG_FEC_MXC_MDIO_BASE=0x5B04
Just wondering why CONFIG_FEC_MXC_MDIO_BASE is set in a board config file?
Shouldn't this base address be retrieved from device tree?
> +/* Flat Device Tree Definitions */
> +#define CONFIG_OF_BOARD_SETUP
> +
> +#define CONFIG_FSL_ESDHC
> +#define CONFIG_FSL_USDHC
> +#define CONFIG_SYS_FSL_ESDHC_ADDR 0
> +#define USDHC1_BASE_ADDR0x5B01
> +#define USDHC2_BASE_ADDR0x5B02
These base addresses should not be needed as they can be retrieved
from device tree.
> +#define CONFIG_ENV_OVERWRITE
> +
> +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> +
> +/* Initial environment variables */
> +#define CONFIG_EXTRA_ENV_SETTINGS \
> + "script=boot.scr\0" \
> + "image=Image\0" \
> + "panel=NULL\0" \
If you don't need the variable 'panel', then there is no need to define it.
> +#define CONFIG_BOOTCOMMAND \
> + "mmc dev ${mmcdev}; if mmc rescan; then " \
> + "if run loadbootscript; then " \
> + "run bootscript; " \
> + "else " \
> + "if run loadimage; then " \
> + "run mmcboot; " \
> + "else run netboot; " \
> + "fi; " \
> + "fi; " \
> + "else booti ${loadaddr} - ${fdt_addr}; fi"
You may consider to use distro_boot for this community board. It makes
easier for Linux distros to support it.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4] armv8: ls1028a: The ls1028a platform supports the I2C driver model
On 7/10/2019 4:16 PM, Chuanhua Han wrote: DM_I2C_COMPAT is a compatibility layer that allows using the non-DM I2C API when DM_I2C is used.When DM_I2C_COMPAT is not enabled for compilation, a compilation error will be generated. This patch solves the problem that the i2c-related api of the ls1028a platform does not support dm. I wouldn't mention DM_I2C_COMPAT at all in the commit message, it's not currently enabled and after this patch set it's not needed either. You could just mention that the patch is updating ls1028a board init code to support DM_I2C. Signed-off-by: Chuanhua Han --- depends on: - https://patchwork.ozlabs.org/project/uboot/list/?series=113364 - https://patchwork.ozlabs.org/project/uboot/list/?series=110856 - https://patchwork.ozlabs.org/project/uboot/list/?series=109677 Changes in v4: - No change. Changes in v3: - No change. Changes in v2: - No change. arch/arm/cpu/armv8/fsl-layerscape/Kconfig |8 board/freescale/ls1028a/ls1028a.c |8 include/configs/ls1028a_common.h |3 --- include/configs/ls1028ardb.h |1 - 4 files changed, 8 insertions(+), 12 deletions(-) code changes look OK to me. Reviewed-by: Alex Marginean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] gpio: do not include on ARCH_LS1028A
On 7/10/2019 4:16 PM, Chuanhua Han wrote: As no gpio.h is defined for this architecture, to avoid compilation failure, do not include for arch ls1028a. Signed-off-by: Chuanhua Han --- depends on: - https://patchwork.ozlabs.org/project/uboot/list/?series=113364 - https://patchwork.ozlabs.org/project/uboot/list/?series=110856 - https://patchwork.ozlabs.org/project/uboot/list/?series=109677 Changes in v4: - No change. Changes in v3: - No change. Changes in v2: - No change. arch/arm/include/asm/gpio.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Reviewed-by: Alex Marginean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] configs: ls1028a: enable DM support for pcf2127 rtc
On 7/10/2019 4:16 PM, Chuanhua Han wrote: Enable related configs to support pcf2127 rtc DM feature for ls1028ardb board. Signed-off-by: Chuanhua Han --- depends on: - https://patchwork.ozlabs.org/project/uboot/list/?series=113364 - https://patchwork.ozlabs.org/project/uboot/list/?series=110856 - https://patchwork.ozlabs.org/project/uboot/list/?series=109677 Changes in v4: - Add configuration options for i2c dm to set default bus number Settings. Changes in v3: - No change. Changes in v2: - Enable secure boot defconfig to support pcf2127 rtc DM feature for ls1028ardb board. configs/ls1028ardb_tfa_SECURE_BOOT_defconfig |11 ++- configs/ls1028ardb_tfa_defconfig |11 ++- 2 files changed, 20 insertions(+), 2 deletions(-) Reviewed-by: Alex Marginean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] armv8: dts: ls1028ardb: Add slave nodes under the i2c0 controller
On 7/10/2019 4:16 PM, Chuanhua Han wrote: This patch adds some slave nodes to support the i2c dm on the device side under the i2c0 controller. Signed-off-by: Chuanhua Han --- depends on: - https://patchwork.ozlabs.org/project/uboot/list/?series=113364 - https://patchwork.ozlabs.org/project/uboot/list/?series=110856 - https://patchwork.ozlabs.org/project/uboot/list/?series=109677 Changes in v4: - No change. Changes in v3: - Delete unnecessary i2c slave nodes. Changes in v2: - Delete unnecessary aliases about i2c. arch/arm/dts/fsl-ls1028a-rdb.dts | 20 1 files changed, 20 insertions(+), 0 deletions(-) Reviewed-by: Alex Marginean Thank you! Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] cmd: bcb: Use strcmp() instead of strncmp() for string literals
Hi Eugeniu,
On Fri, Jul 12, 2019 at 2:21 PM Eugeniu Rosca wrote:
>
> Quote from https://patchwork.ozlabs.org/patch/1104244/#2210814:
>
> --8<---
> strncmp() is chosen for the sake of paranoid/defensive programming.
> Indeed, strncmp() is not really needed when comparing a variable
> with a string literal. We expect strcmp() to behave safely even if the
> string variable is not NUL-terminated.
>
> In the same scenario, Linux v5.2-rc7 uses both strcmp() and strncmp(),
> but the frequency of strcmp() is higher:
>
> $ git --version
> git version 2.22.0
> $ (Linux 5.2-rc7) git grep -En 'strncmp\([^"]*"[[:alnum:]]+"' | wc -l
> 1066
> $ (Linux 5.2-rc7) git grep -En 'strcmp\([^"]*"[[:alnum:]]+"' | wc -l
> 1968
>
> A quick "strcmp vs strncmp" object size test shows that strcmp()
> generates smaller memory footprint (gcc-8, x86_64):
>
> $ (U-Boot) size cmd/bcb-strncmp.o cmd/bcb-strcmp.o
>textdata bss dec hex filename
>3373 4002048582116bd cmd/bcb-strncmp.o
>3314 400204857621682 cmd/bcb-strcmp.o
>
> So, overall, I agree to use strcmp() whenever variables are compared
> with string literals.
> --8<---
>
> Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
> Reported-by: Simon Glass
> Signed-off-by: Eugeniu Rosca
> ---
> cmd/bcb.c | 42 +-
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/cmd/bcb.c b/cmd/bcb.c
> index 3b1c7434e287..c7138a5179a9 100644
> --- a/cmd/bcb.c
> +++ b/cmd/bcb.c
> @@ -24,17 +24,17 @@ static struct bootloader_message bcb = { { 0 } };
>
> static int bcb_cmd_get(char *cmd)
> {
> - if (!strncmp(cmd, "load", sizeof("load")))
> + if (!strcmp(cmd, "load"))
> return BCB_CMD_LOAD;
> - if (!strncmp(cmd, "set", sizeof("set")))
> + if (!strcmp(cmd, "set"))
> return BCB_CMD_FIELD_SET;
> - if (!strncmp(cmd, "clear", sizeof("clear")))
> + if (!strcmp(cmd, "clear"))
> return BCB_CMD_FIELD_CLEAR;
> - if (!strncmp(cmd, "test", sizeof("test")))
> + if (!strcmp(cmd, "test"))
> return BCB_CMD_FIELD_TEST;
> - if (!strncmp(cmd, "store", sizeof("store")))
> + if (!strcmp(cmd, "store"))
> return BCB_CMD_STORE;
> - if (!strncmp(cmd, "dump", sizeof("dump")))
> + if (!strcmp(cmd, "dump"))
> return BCB_CMD_FIELD_DUMP;
> else
> return -1;
> @@ -85,21 +85,21 @@ err:
>
> static int bcb_field_get(char *name, char **field, int *size)
> {
> - if (!strncmp(name, "command", sizeof("command"))) {
> - *field = bcb.command;
> - *size = sizeof(bcb.command);
> - } else if (!strncmp(name, "status", sizeof("status"))) {
> - *field = bcb.status;
> - *size = sizeof(bcb.status);
> - } else if (!strncmp(name, "recovery", sizeof("recovery"))) {
> - *field = bcb.recovery;
> - *size = sizeof(bcb.recovery);
> - } else if (!strncmp(name, "stage", sizeof("stage"))) {
> - *field = bcb.stage;
> - *size = sizeof(bcb.stage);
> - } else if (!strncmp(name, "reserved", sizeof("reserved"))) {
> - *field = bcb.reserved;
> - *size = sizeof(bcb.reserved);
> + if (!strcmp(name, "command")) {
> + *fieldp = bcb.command;
> + *sizep = sizeof(bcb.command);
> + } else if (!strcmp(name, "status")) {
> + *fieldp = bcb.status;
> + *sizep = sizeof(bcb.status);
> + } else if (!strcmp(name, "recovery")) {
> + *fieldp = bcb.recovery;
> + *sizep = sizeof(bcb.recovery);
> + } else if (!strcmp(name, "stage")) {
> + *fieldp = bcb.stage;
> + *sizep = sizeof(bcb.stage);
> + } else if (!strcmp(name, "reserved")) {
> + *fieldp = bcb.reserved;
> + *sizep = sizeof(bcb.reserved);
> } else {
> printf("Error: Unknown bcb field '%s'\n", name);
> return -1;
> --
> 2.22.0
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] cmd: bcb: Use strcmp() instead of strncmp() for string literals
Hi Igor,
On Fri, Jul 12, 2019 at 02:54:19PM +0300, Igor Opaniuk wrote:
> > static int bcb_field_get(char *name, char **field, int *size)
> > {
> > - if (!strncmp(name, "command", sizeof("command"))) {
> > - *field = bcb.command;
> > + if (!strcmp(name, "command")) {
> > + *fieldp = bcb.command;
Many thanks for the recent reviews!
There is a small issue committed by my autopilot, i.e. I didn't do the
best partitioning of the patches, such that they could provoke a build
breakage during git bisecting (see the intermixed usage of field and
fieldp variables above). I will fix it in v2, adding your Reviewed-by
in the other patches.
Thanks again!
--
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] cmd: bcb: Apply non-functional refinements
On Fri, Jul 12, 2019 at 2:26 PM Eugeniu Rosca wrote:
>
> These have been reported by Simon in [1] and fixed in [2].
> However, since [1] has already been pushed to u-boot/master, the
> improvements incorporated in [2] are now extracted and resubmitted.
minor: could you please add more details about particular issues that
were addressed in this commit, because current commit message
contains only some insights of a glitch in the merge workflow instead of
overview of changes.
>
> [1] https://patchwork.ozlabs.org/patch/1104244/#2200259
> [2] https://patchwork.ozlabs.org/cover/1128661/
>("[v4,0/4] Add 'bcb' command to read/modify/write Android BCB")
>
> Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
> Reported-by: Simon Glass
> Signed-off-by: Eugeniu Rosca
> ---
> cmd/bcb.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/cmd/bcb.c b/cmd/bcb.c
> index c7138a5179a9..9626f2c69e34 100644
> --- a/cmd/bcb.c
> +++ b/cmd/bcb.c
> @@ -83,7 +83,7 @@ err:
> return -1;
> }
>
> -static int bcb_field_get(char *name, char **field, int *size)
> +static int bcb_field_get(char *name, char **fieldp, int *sizep)
> {
> if (!strcmp(name, "command")) {
> *fieldp = bcb.command;
> @@ -108,8 +108,8 @@ static int bcb_field_get(char *name, char **field, int
> *size)
> return 0;
> }
>
> -static int
> -do_bcb_load(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +static int do_bcb_load(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> {
> struct blk_desc *desc;
> disk_partition_t info;
> @@ -119,28 +119,28 @@ do_bcb_load(cmd_tbl_t *cmdtp, int flag, int argc, char
> * const argv[])
>
> ret = blk_get_device_by_str("mmc", argv[1], &desc);
> if (ret < 0)
> - goto err_1;
> + goto err_read_fail;
>
> part = simple_strtoul(argv[2], &endp, 0);
> if (*endp == '\0') {
> ret = part_get_info(desc, part, &info);
> if (ret)
> - goto err_1;
> + goto err_read_fail;
> } else {
> part = part_get_info_by_name(desc, argv[2], &info);
> if (part < 0) {
> ret = part;
> - goto err_1;
> + goto err_read_fail;
> }
> }
>
> cnt = DIV_ROUND_UP(sizeof(struct bootloader_message), info.blksz);
> if (cnt > info.size)
> - goto err_2;
> + goto err_too_small;
>
> if (blk_dread(desc, info.start, cnt, &bcb) != cnt) {
> ret = -EIO;
> - goto err_1;
> + goto err_read_fail;
> }
>
> bcb_dev = desc->devnum;
> @@ -148,10 +148,10 @@ do_bcb_load(cmd_tbl_t *cmdtp, int flag, int argc, char
> * const argv[])
> debug("%s: Loaded from mmc %d:%d\n", __func__, bcb_dev, bcb_part);
>
> return CMD_RET_SUCCESS;
> -err_1:
> +err_read_fail:
> printf("Error: mmc %s:%s read failed (%d)\n", argv[1], argv[2], ret);
> goto err;
> -err_2:
> +err_too_small:
> printf("Error: mmc %s:%s too small!", argv[1], argv[2]);
> goto err;
> err:
> @@ -304,7 +304,8 @@ static int do_bcb(cmd_tbl_t *cmdtp, int flag, int argc,
> char *const argv[])
> return CMD_RET_USAGE;
>
> if (bcb_is_misused(argc, argv)) {
> - /* We try to improve the user experience by reporting the
> + /*
> +* We try to improve the user experience by reporting the
> * root-cause of misusage, so don't return CMD_RET_USAGE,
> * since the latter prints out the full-blown help text
> */
> --
> 2.22.0
>
With my comment addressed:
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/16] stm32mp1: call regulators_enable_boot_on in board_init
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > U-Boot activates regulators by reading the "regulator-boot-on" > property in DT; it is requested by M4 early Boot feature. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > board/st/stm32mp1/stm32mp1.c | 4 > 1 file changed, 4 insertions(+) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/16] stm32mp1: deactivate WATCHDOG in defconfig
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Deactivate WATCHDOG by default in u-boot to avoid issue to boot kernel and > rootfs without the needed daemon to reload it. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > configs/stm32mp15_basic_defconfig | 2 -- > configs/stm32mp15_trusted_defconfig | 2 -- > 2 files changed, 4 deletions(-) Applied to u-boot-stm32/master, thanks! Patrick > -- > 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/16] stm32mp1: syscon: remove etzpc support
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Support for ETZPC is removed as this device is not present in Linux kernel > device > tree. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > arch/arm/mach-stm32mp/include/mach/stm32.h | 1 - > arch/arm/mach-stm32mp/syscon.c | 1 - > 2 files changed, 2 deletions(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/16] stm32mp1: syscon: remove stgen
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Reduce difference with kernel Linux device tree. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > arch/arm/dts/stm32mp157-u-boot.dtsi| 7 --- > arch/arm/mach-stm32mp/include/mach/stm32.h | 2 +- > arch/arm/mach-stm32mp/syscon.c | 1 - > drivers/clk/clk_stm32mp1.c | 3 +-- > 4 files changed, 2 insertions(+), 11 deletions(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/16] stm32mp1: export get_cpu_package function
Hi, > To: u-boot@lists.denx.de > Cc: Patrick DELAUNAY ; U-Boot STM32 st...@st-md-mailman.stormreply.com>; Patrice CHOTARD > ; Albert Aribaud > Subject: [PATCH v2 06/16] stm32mp1: export get_cpu_package function > Importance: High > > Prepare update of package information update in Linux device tree. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > arch/arm/mach-stm32mp/cpu.c| 7 +-- > arch/arm/mach-stm32mp/include/mach/sys_proto.h | 9 + > 2 files changed, 10 insertions(+), 6 deletions(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/16] dt-bindings: pinctrl: stm32: add new entry for package information
Hi, > From: Patrick DELAUNAY > > Add "st,package" entry. Possibles values are: > -STM32MP_PKG_AA for LFBGA448 (18*18) package -STM32MP_PKG_AB for > LFBGA354 (16*16) package -STM32MP_PKG_AC for TFBGA361 (12*12) > package -STM32MP_PKG_AD for TFBGA257 (10*10) package > > see Linux commit 966d9b928f626a54a0c27c0fdae1e3dfe9bab416 > for v5.2-rc1 > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > .../pinctrl/st,stm32-pinctrl.txt | 101 > ++--- > include/dt-bindings/pinctrl/stm32-pinfunc.h| 6 ++ > 2 files changed, 94 insertions(+), 13 deletions(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/16] stm32mp1: update package information in device tree
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > arch/arm/Kconfig | 1 + > arch/arm/mach-stm32mp/Makefile | 1 + > arch/arm/mach-stm32mp/fdt.c| 45 > ++ > 3 files changed, 47 insertions(+) > create mode 100644 arch/arm/mach-stm32mp/fdt.c > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/16] stm32mp1: update device tree with ETZPC status
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > U-Boot should disable nodes in device tree if needed according ETZPC status in > ft_system_setup(). > > ETZPC itself use an array on addresses to do the match between the status bits > and the node. > > Signed-off-by: Benjamin Gaignard > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > arch/arm/mach-stm32mp/Kconfig | 7 ++ > arch/arm/mach-stm32mp/fdt.c | 178 > ++ > 2 files changed, 185 insertions(+) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/16] stm32mp1: add stboard command
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Allow to update board identification in OTP 59. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > board/st/stm32mp1/Kconfig | 7 ++ > board/st/stm32mp1/Makefile | 1 + > board/st/stm32mp1/cmd_stboard.c | 145 > > 3 files changed, 153 insertions(+) > create mode 100644 board/st/stm32mp1/cmd_stboard.c > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/16] stm32mp1: key: add stm32key command
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Add dedicated command to register in fuse a public hash key provided by keygen > tool. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > arch/arm/mach-stm32mp/Kconfig| 8 +++ > arch/arm/mach-stm32mp/Makefile | 1 + > arch/arm/mach-stm32mp/cmd_stm32key.c | 101 > +++ > 3 files changed, 110 insertions(+) > create mode 100644 arch/arm/mach-stm32mp/cmd_stm32key.c > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/16] stm32mp1: update README
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Add latest information and correct some information. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > board/st/stm32mp1/README | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: spi-mem: Fix read data size issue
On 10/07/19 2:53 PM, Ye Li wrote:
> When slave drivers don't set the max_read_size, the spi-mem should directly
> use data.nbytes and not limit to any size. But current logic will limit to
> the max_write_size.
>
Indeed. Thanks for catching this!
Acked-by: Vignesh Raghavendra
> Signed-off-by: Ye Li
> ---
> drivers/spi/spi-mem.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index b86eee7..be440fe 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -423,12 +423,14 @@ int spi_mem_adjust_op_size(struct spi_slave *slave,
> struct spi_mem_op *op)
> 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,
> + if (op->data.dir == SPI_MEM_DATA_IN) {
> + if (slave->max_read_size)
> + op->data.nbytes = min(op->data.nbytes,
> slave->max_read_size);
> - else if (slave->max_write_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;
>
--
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/16] stm32mp1: cosmetic: remove unnecessary include
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Remove post.h include as it is used in spl.c > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > board/st/stm32mp1/spl.c | 1 - > 1 file changed, 1 deletion(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/16] stm32mp1: configs: Add CONFIG_OF_SPL_REMOVE_PROPS
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Removes unused device tree property in SPL to reduce the SPL size by 1kB > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > configs/stm32mp15_basic_defconfig | 1 + > 1 file changed, 1 insertion(+) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/16] stm32mp1: add check for presence of environment in boot device
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > For boot from flash, check presence of default environment to force save env. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > include/configs/stm32mp1.h | 4 > 1 file changed, 4 insertions(+) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/16] stm32mp1: force boot_net_usb_start
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Prevent USB enumeration and avoid unnecessary delay in bootcmd_pxe as > Ethernet device is not attached to USB. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: None > > include/configs/stm32mp1.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/16] ARM: dts: stm32mp1: sync device tree with v5.2-rc4
Hi, > From: Patrick DELAUNAY > Sent: vendredi 5 juillet 2019 17:20 > > Synchronize device tree with v5.2-rc4 label and update the associated u-boot > dtsi. > > Signed-off-by: Patrick Delaunay > --- > > Changes in v2: > - missing alignment on ethernet@5800a000 > - set ethernet0 phy-mode to "rgmii-id" for dk1 > (needed modification not yet upstreamed) > > arch/arm/dts/stm32mp15-ddr.dtsi | 2 +- > arch/arm/dts/stm32mp157-pinctrl.dtsi | 270 > ++- > arch/arm/dts/stm32mp157-u-boot.dtsi | 60 --- > arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 4 - > arch/arm/dts/stm32mp157a-dk1.dts | 32 ++-- > arch/arm/dts/stm32mp157c-dk2.dts | 1 + > arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 15 +- > arch/arm/dts/stm32mp157c-ed1.dts | 205 +-- > arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi | 3 - > arch/arm/dts/stm32mp157c-ev1.dts | 12 +- > arch/arm/dts/stm32mp157c.dtsi| 215 +--- > 11 files changed, 541 insertions(+), 278 deletions(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] mx6: clock: Allow enable_ipu_clock() to be built for SPL code
Allow enable_ipu_clock() to be built for SPL code. This is done
in preparation for configuring the NoC registers on i.MX6QP in SPL.
Signed-off-by: Fabio Estevam
---
arch/arm/mach-imx/mx6/clock.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-imx/mx6/clock.c b/arch/arm/mach-imx/mx6/clock.c
index 366a4e3c6b..5af1ae7cf3 100644
--- a/arch/arm/mach-imx/mx6/clock.c
+++ b/arch/arm/mach-imx/mx6/clock.c
@@ -1275,6 +1275,22 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
return 0;
}
+#ifndef CONFIG_MX6SX
+void enable_ipu_clock(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ int reg;
+ reg = readl(&mxc_ccm->CCGR3);
+ reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK;
+ writel(reg, &mxc_ccm->CCGR3);
+
+ if (is_mx6dqp()) {
+ setbits_le32(&mxc_ccm->CCGR6, MXC_CCM_CCGR6_PRG_CLK0_MASK);
+ setbits_le32(&mxc_ccm->CCGR3, MXC_CCM_CCGR3_IPU2_IPU_MASK);
+ }
+}
+#endif
+
#ifndef CONFIG_SPL_BUILD
/*
* Dump some core clockes.
@@ -1311,22 +1327,6 @@ int do_mx6_showclocks(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
return 0;
}
-#ifndef CONFIG_MX6SX
-void enable_ipu_clock(void)
-{
- struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
- int reg;
- reg = readl(&mxc_ccm->CCGR3);
- reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK;
- writel(reg, &mxc_ccm->CCGR3);
-
- if (is_mx6dqp()) {
- setbits_le32(&mxc_ccm->CCGR6, MXC_CCM_CCGR6_PRG_CLK0_MASK);
- setbits_le32(&mxc_ccm->CCGR3, MXC_CCM_CCGR3_IPU2_IPU_MASK);
- }
-}
-#endif
-
#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6D) || defined(CONFIG_MX6DL) || \
defined(CONFIG_MX6S)
static void disable_ldb_di_clock_sources(void)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] mx6: clock: Use setbits_le32()
The code can be made simpler by using setbits_le32(), so switch
to it.
Signed-off-by: Fabio Estevam
---
arch/arm/mach-imx/mx6/clock.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/mx6/clock.c b/arch/arm/mach-imx/mx6/clock.c
index 5af1ae7cf3..9951f79106 100644
--- a/arch/arm/mach-imx/mx6/clock.c
+++ b/arch/arm/mach-imx/mx6/clock.c
@@ -1279,10 +1279,8 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
void enable_ipu_clock(void)
{
struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
- int reg;
- reg = readl(&mxc_ccm->CCGR3);
- reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK;
- writel(reg, &mxc_ccm->CCGR3);
+
+ setbits_le32(&mxc_ccm->CCGR3, MXC_CCM_CCGR3_IPU1_IPU_MASK);
if (is_mx6dqp()) {
setbits_le32(&mxc_ccm->CCGR6, MXC_CCM_CCGR6_PRG_CLK0_MASK);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] mx6: clock: Introduce disable_ipu_clock()
Introduce disable_ipu_clock(). This is done in preparation for
configuring the NoC registers on i.MX6QP in SPL.
Afer the NoC registers are set the IPU clocks can be disabled.
Signed-off-by: Fabio Estevam
---
arch/arm/include/asm/arch-mx6/clock.h | 1 +
arch/arm/mach-imx/mx6/clock.c | 12
2 files changed, 13 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index a9481a5fea..f7760541a4 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -71,6 +71,7 @@ int enable_pcie_clock(void);
int enable_i2c_clk(unsigned char enable, unsigned i2c_num);
int enable_spi_clk(unsigned char enable, unsigned spi_num);
void enable_ipu_clock(void);
+void disable_ipu_clock(void);
int enable_fec_anatop_clock(int fec_id, enum enet_freq freq);
void enable_enet_clk(unsigned char enable);
int enable_lcdif_clock(u32 base_addr, bool enable);
diff --git a/arch/arm/mach-imx/mx6/clock.c b/arch/arm/mach-imx/mx6/clock.c
index 9951f79106..e1e21e37a8 100644
--- a/arch/arm/mach-imx/mx6/clock.c
+++ b/arch/arm/mach-imx/mx6/clock.c
@@ -1287,6 +1287,18 @@ void enable_ipu_clock(void)
setbits_le32(&mxc_ccm->CCGR3, MXC_CCM_CCGR3_IPU2_IPU_MASK);
}
}
+
+void disable_ipu_clock(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ clrbits_le32(&mxc_ccm->CCGR3, MXC_CCM_CCGR3_IPU1_IPU_MASK);
+
+ if (is_mx6dqp()) {
+ clrbits_le32(&mxc_ccm->CCGR6, MXC_CCM_CCGR6_PRG_CLK0_MASK);
+ clrbits_le32(&mxc_ccm->CCGR3, MXC_CCM_CCGR3_IPU2_IPU_MASK);
+ }
+}
#endif
#ifndef CONFIG_SPL_BUILD
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] mx6: Allow configuring the NoC registers on i.MX6QP
The NoC registers on i.MX6QP needs to be configured, otherwise some
usecases in the kernel behave incorrectly, such as rotation and resize.
Currently the NoC registers are not configured in the kernel, so
configure them in U-Boot like it is done in the NXP U-Boot tree.
Signed-off-by: Fabio Estevam
---
arch/arm/mach-imx/mx6/soc.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index e80f1d484b..8de42408c7 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -365,6 +365,35 @@ static void init_bandgap(void)
}
}
+static void noc_setup(void)
+{
+ enable_ipu_clock();
+
+ writel(0x8201, 0xbb0608);
+ /* Bypass IPU1 QoS generator */
+ writel(0x0002, 0x00bb048c);
+ /* Bypass IPU2 QoS generator */
+ writel(0x0002, 0x00bb050c);
+ /* Bandwidth THR for of PRE0 */
+ writel(0x0200, 0x00bb0690);
+ /* Bandwidth THR for of PRE1 */
+ writel(0x0200, 0x00bb0710);
+ /* Bandwidth THR for of PRE2 */
+ writel(0x0200, 0x00bb0790);
+ /* Bandwidth THR for of PRE3 */
+ writel(0x0200, 0x00bb0810);
+ /* Saturation THR for of PRE0 */
+ writel(0x0010, 0x00bb0694);
+ /* Saturation THR for of PRE1 */
+ writel(0x0010, 0x00bb0714);
+ /* Saturation THR for of PRE2 */
+ writel(0x0010, 0x00bb0794);
+ /* Saturation THR for of PRE */
+ writel(0x0010, 0x00bb0814);
+
+ disable_ipu_clock();
+}
+
int arch_cpu_init(void)
{
struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
@@ -442,6 +471,9 @@ int arch_cpu_init(void)
init_src();
+ if (is_mx6dqp())
+ noc_setup();
+
return 0;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] stm32mp1: reorder some CONFIG in stm32mp1.h
Hi, > From: Patrick DELAUNAY > Sent: mardi 2 juillet 2019 13:26 > > Change config not directly linked to CONFIG_DISTRO_DEFAULTS. > Allow to deactivate CONFIG_SYS_MTDPARTS_RUNTIME when > CONFIG_MTDPARTS_DEFAULT is defined in defconfig. > > Signed-off-by: Patrick Delaunay > --- > > include/configs/stm32mp1.h | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] stm32mp1: add configuration op-tee
Hi, > From: Patrick DELAUNAY > Sent: mardi 2 juillet 2019 13:26 > > Add support of Trusted boot chain with OP-TEE > - reserved 32MB at the end of the DDR for OP-TEE > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/Kconfig | 12 - > board/st/stm32mp1/MAINTAINERS | 1 + > board/st/stm32mp1/README | 29 --- > board/st/stm32mp1/stm32mp1.c | 4 +- > configs/stm32mp15_optee_defconfig | 103 > ++ > include/configs/stm32mp1.h| 13 + > 6 files changed, 153 insertions(+), 9 deletions(-) create mode 100644 > configs/stm32mp15_optee_defconfig > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] stm32mp1: activate OF_BOARD_SETUP and FDT_FIXUP_PARTITIONS
Hi, > From: Patrick DELAUNAY > Sent: mardi 2 juillet 2019 13:26 > > Update kernel MTD partition in device tree with U-Boot information. > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/Kconfig | 1 + > board/st/stm32mp1/stm32mp1.c| 18 ++ > configs/stm32mp15_basic_defconfig | 1 + > configs/stm32mp15_optee_defconfig | 1 + > configs/stm32mp15_trusted_defconfig | 1 + > 5 files changed, 22 insertions(+) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: dts: stm32: Use kernel qspi compatible string for stm32f7-uboot.dtsi
Hi, > From: Patrice CHOTARD > Sent: vendredi 28 juin 2019 15:03 > > For STM32 QSPI driver, "st,stm32-qspi" compatible string was first introduced > in > U-boot. But later in kernel side, "st,stm32f469-qspi" > was used. > To simplify, align U-boot QSPI compatible string with kernel one. > > Signed-off-by: Patrice Chotard > --- > > arch/arm/dts/stm32f7-u-boot.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM: dts: stm32: Use kernel qspi compatible string for stm32f469-disco-uboot.dtsi
Hi, > From: Patrice CHOTARD > Sent: vendredi 28 juin 2019 15:03 > > For STM32 QSPI driver, "st,stm32-qspi" compatible string was first introduced > in > U-boot. But later in kernel side, "st,stm32f469-qspi" > was used. > To simplify, align U-boot QSPI compatible string with kernel one. > > Signed-off-by: Patrice Chotard > --- > > arch/arm/dts/stm32f469-disco-u-boot.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] spi: stm32_qspi: Remove "st, stm32-qspi" compatible string
Hi, > From: Patrice CHOTARD > Sent: vendredi 28 juin 2019 15:03 > > "st,stm32-qspi" is no more used, remove it. > > Signed-off-by: Patrice Chotard > --- > > drivers/spi/stm32_qspi.c | 1 - > 1 file changed, 1 deletion(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] doc: device-tree-bindings: alignment with v5.2-rc6 for spi-stm32-qspi.txt
Hi, > From: Patrice CHOTARD > Sent: vendredi 28 juin 2019 15:03 > > Align doc/device-tree-bindings/spi/spi-stm32-qspi.txt with kernel v5.2-rc6 > > Signed-off-by: Patrice Chotard > > --- > > .../spi/spi-stm32-qspi.txt| 71 ++- > 1 file changed, 38 insertions(+), 33 deletions(-) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mailbox: introduce stm32-ipcc driver
Hi, > From: Fabien DESSENNE > Sent: mardi 14 mai 2019 11:21 > > On STM32 family, the IPCC peripheral allows the communication between 2 > processors offering doorbells mechanism. > > Signed-off-by: Fabien Dessenne > Signed-off-by: Loic Pallardy > --- > drivers/mailbox/Kconfig | 7 ++ > drivers/mailbox/Makefile | 1 + > drivers/mailbox/stm32-ipcc.c | 167 > +++ > 3 files changed, 175 insertions(+) > create mode 100644 drivers/mailbox/stm32-ipcc.c > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] MAINTAINERS: Add stm32 mailbox IPPC driver
Hi, > From: Fabien DESSENNE > Sent: mardi 14 mai 2019 11:21 > > Signed-off-by: Fabien Dessenne > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] configs: stm32mp15: enable IPCC mailbox
Hi, > From: Fabien DESSENNE > Sent: mardi 14 mai 2019 11:21 > > Activate the ipcc mailbox for stm32mp15 configs. > > Signed-off-by: Fabien Dessenne > --- > configs/stm32mp15_basic_defconfig | 2 ++ > configs/stm32mp15_trusted_defconfig | 2 ++ > 2 files changed, 4 insertions(+) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] treewide: Fix stale references of Android docs
Commit 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB
overview") left some obsolete references of Android documents/paths.
This has been pointed out by Sam (thanks!) in:
https://patchwork.ozlabs.org/patch/1104245/#2208134
Fixes: 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB overview")
Reported-by: Sam Protsenko
Suggested-by: Sam Protsenko
Signed-off-by: Eugeniu Rosca
Reviewed-by: Igor Opaniuk
---
v2:
- Added 'Reviewed-by: Igor Opaniuk' from v1
v1:
- https://patchwork.ozlabs.org/patch/1131305/
---
cmd/Kconfig | 2 +-
doc/android/fastboot.txt | 2 +-
test/py/tests/test_avb.py | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3afb760a816f..3cf8233df62e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -707,7 +707,7 @@ config CMD_FASTBOOT
Android devices. Fastboot requires either the network stack
enabled or support for acting as a USB device.
- See doc/README.android-fastboot for more information.
+ See doc/android/fastboot.txt for more information.
config CMD_FDC
bool "fdcboot - Boot from floppy device"
diff --git a/doc/android/fastboot.txt b/doc/android/fastboot.txt
index 431191c473f2..dcf824713f94 100644
--- a/doc/android/fastboot.txt
+++ b/doc/android/fastboot.txt
@@ -6,7 +6,7 @@ Overview
The protocol that is used over USB and UDP is described in the
-``README.android-fastboot-protocol`` file in the same directory.
+``fastboot-protocol.txt`` file in the same directory.
The current implementation supports the following standard commands:
diff --git a/test/py/tests/test_avb.py b/test/py/tests/test_avb.py
index 2bb75ed6e2a2..813242343555 100644
--- a/test/py/tests/test_avb.py
+++ b/test/py/tests/test_avb.py
@@ -8,7 +8,7 @@
This tests Android Verified Boot 2.0 support in U-boot:
For additional details about how to build proper vbmeta partition
-check doc/README.avb2
+check doc/android/avb2.txt
For configuration verification:
- Corrupt boot partition and check for failure
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] Fixes and improvements in BCB and Android docs
Resubmit the diff between [1] and [2] of the BCB/Android series, since
the former has been pushed to master instead of the latter.
[1] https://patchwork.ozlabs.org/cover/1104242/
("[v3,0/3] Add 'bcb' command to read/modify/write Android BCB")
[2] https://patchwork.ozlabs.org/cover/1128661/
("[v4,0/4] Add 'bcb' command to read/modify/write Android BCB")
v2:
- Ensured git bisectability for the series
- [Igor Opaniuk] Enriched patch description
- No series-wide changes in the contents
v1:
- https://patchwork.ozlabs.org/cover/1131295/
Eugeniu Rosca (5):
doc: Move README.android-fastboot-protocol to doc/android/
treewide: Fix stale references of Android docs
cmd: bcb: Fix duplicated handling in two case-branches
cmd: bcb: Use strcmp() instead of strncmp() for string literals
cmd: bcb: Apply non-functional refinements
cmd/Kconfig | 2 +-
cmd/bcb.c | 68 +--
.../fastboot-protocol.txt}| 0
doc/android/fastboot.txt | 2 +-
test/py/tests/test_avb.py | 2 +-
5 files changed, 36 insertions(+), 38 deletions(-)
rename doc/{README.android-fastboot-protocol => android/fastboot-protocol.txt}
(100%)
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] cmd: bcb: Use strcmp() instead of strncmp() for string literals
Quote from https://patchwork.ozlabs.org/patch/1104244/#2210814:
--8<---
strncmp() is chosen for the sake of paranoid/defensive programming.
Indeed, strncmp() is not really needed when comparing a variable
with a string literal. We expect strcmp() to behave safely even if the
string variable is not NUL-terminated.
In the same scenario, Linux v5.2-rc7 uses both strcmp() and strncmp(),
but the frequency of strcmp() is higher:
$ git --version
git version 2.22.0
$ (Linux 5.2-rc7) git grep -En 'strncmp\([^"]*"[[:alnum:]]+"' | wc -l
1066
$ (Linux 5.2-rc7) git grep -En 'strcmp\([^"]*"[[:alnum:]]+"' | wc -l
1968
A quick "strcmp vs strncmp" object size test shows that strcmp()
generates smaller memory footprint (gcc-8, x86_64):
$ (U-Boot) size cmd/bcb-strncmp.o cmd/bcb-strcmp.o
textdata bss dec hex filename
3373 4002048582116bd cmd/bcb-strncmp.o
3314 400204857621682 cmd/bcb-strcmp.o
So, overall, I agree to use strcmp() whenever variables are compared
with string literals.
--8<---
Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
Reported-by: Simon Glass
Signed-off-by: Eugeniu Rosca
---
v2:
- Fixed accidental rename of field/size variables in bcb_field_get()
v1:
- https://patchwork.ozlabs.org/patch/1131306/
---
cmd/bcb.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index 3b1c7434e287..fa9fdeeb0dfc 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -24,17 +24,17 @@ static struct bootloader_message bcb = { { 0 } };
static int bcb_cmd_get(char *cmd)
{
- if (!strncmp(cmd, "load", sizeof("load")))
+ if (!strcmp(cmd, "load"))
return BCB_CMD_LOAD;
- if (!strncmp(cmd, "set", sizeof("set")))
+ if (!strcmp(cmd, "set"))
return BCB_CMD_FIELD_SET;
- if (!strncmp(cmd, "clear", sizeof("clear")))
+ if (!strcmp(cmd, "clear"))
return BCB_CMD_FIELD_CLEAR;
- if (!strncmp(cmd, "test", sizeof("test")))
+ if (!strcmp(cmd, "test"))
return BCB_CMD_FIELD_TEST;
- if (!strncmp(cmd, "store", sizeof("store")))
+ if (!strcmp(cmd, "store"))
return BCB_CMD_STORE;
- if (!strncmp(cmd, "dump", sizeof("dump")))
+ if (!strcmp(cmd, "dump"))
return BCB_CMD_FIELD_DUMP;
else
return -1;
@@ -85,19 +85,19 @@ err:
static int bcb_field_get(char *name, char **field, int *size)
{
- if (!strncmp(name, "command", sizeof("command"))) {
+ if (!strcmp(name, "command")) {
*field = bcb.command;
*size = sizeof(bcb.command);
- } else if (!strncmp(name, "status", sizeof("status"))) {
+ } else if (!strcmp(name, "status")) {
*field = bcb.status;
*size = sizeof(bcb.status);
- } else if (!strncmp(name, "recovery", sizeof("recovery"))) {
+ } else if (!strcmp(name, "recovery")) {
*field = bcb.recovery;
*size = sizeof(bcb.recovery);
- } else if (!strncmp(name, "stage", sizeof("stage"))) {
+ } else if (!strcmp(name, "stage")) {
*field = bcb.stage;
*size = sizeof(bcb.stage);
- } else if (!strncmp(name, "reserved", sizeof("reserved"))) {
+ } else if (!strcmp(name, "reserved")) {
*field = bcb.reserved;
*size = sizeof(bcb.reserved);
} else {
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] doc: Move README.android-fastboot-protocol to doc/android/
Commit 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB
overview") missed relocating README.android-fastboot-protocol. Fix it.
Fixes: 9bdf0e8fef86 ("doc: relocate/rename Android README and add BCB overview")
Signed-off-by: Eugeniu Rosca
Reviewed-by: Igor Opaniuk
---
v2:
- Added 'Reviewed-by: Igor Opaniuk' from v1
v1:
- https://patchwork.ozlabs.org/patch/1131298/
---
.../fastboot-protocol.txt}| 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename doc/{README.android-fastboot-protocol => android/fastboot-protocol.txt}
(100%)
diff --git a/doc/README.android-fastboot-protocol
b/doc/android/fastboot-protocol.txt
similarity index 100%
rename from doc/README.android-fastboot-protocol
rename to doc/android/fastboot-protocol.txt
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] cmd: bcb: Fix duplicated handling in two case-branches
Fix warning V1037 reported by PVS-Studio Static Analyzer:
Two or more case-branches perform the same actions. Check lines: 49, 53
Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
Signed-off-by: Eugeniu Rosca
Reviewed-by: Igor Opaniuk
---
v2:
- Added 'Reviewed-by: Igor Opaniuk' from v1
v1:
- https://patchwork.ozlabs.org/patch/1131301/
---
cmd/bcb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index 2bd5a744deb5..3b1c7434e287 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -46,9 +46,6 @@ static int bcb_is_misused(int argc, char *const argv[])
switch (cmd) {
case BCB_CMD_LOAD:
- if (argc != 3)
- goto err;
- break;
case BCB_CMD_FIELD_SET:
if (argc != 3)
goto err;
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: dts: stm32: Add ipcc mailbox support on stm32mp1
Hi, > From: Fabien DESSENNE > Sent: mardi 14 mai 2019 11:21 > > Add IPCC mailbox support on stm32mp157 eval and disco boards. > > Signed-off-by: Fabien Dessenne > --- > arch/arm/dts/stm32mp157a-dk1.dts | 4 arch/arm/dts/stm32mp157c- > ed1.dts | 4 > arch/arm/dts/stm32mp157c.dtsi| 13 + > 3 files changed, 21 insertions(+) > Applied to u-boot-stm32/master, thanks! Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
