Re: [U-Boot] [PATCH v3 1/4] sunxi: clock: Fix EHCI and OHCI clocks on A64
On 06/08/2018 04:23 AM, Vasily Khoruzhick wrote:
> EHCI0 is bit 24, EHCI1 - 25, OHCI0 - 28, OHCI1 - 29
>
> Fixes commit fef73766d9ad ("sunxi: clock: Fix OHCI clock gating for H3/H5")
>
> Signed-off-by: Vasily Khoruzhick
> ---
> arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index 8acf79fbba..8afeaf872e 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -280,8 +280,10 @@ struct sunxi_ccm_reg {
> #define AHB_GATE_OFFSET_USB_EHCI126
> #define AHB_GATE_OFFSET_USB_EHCI024
> #elif defined(CONFIG_MACH_SUN50I)
> -#define AHB_GATE_OFFSET_USB_OHCI029
> -#define AHB_GATE_OFFSET_USB_EHCI025
> +#define AHB_GATE_OFFSET_USB_OHCI028
> +#define AHB_GATE_OFFSET_USB_OHCI129
> +#define AHB_GATE_OFFSET_USB_EHCI024
> +#define AHB_GATE_OFFSET_USB_EHCI125
> #else
> #define AHB_GATE_OFFSET_USB_OHCI130
> #define AHB_GATE_OFFSET_USB_OHCI029
>
Applied all 4, thanks.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] sunxi: clock: Fix EHCI and OHCI clocks on A64
On Thu, Jun 7, 2018 at 7:23 PM, Vasily Khoruzhick wrote:
> EHCI0 is bit 24, EHCI1 - 25, OHCI0 - 28, OHCI1 - 29
>
> Fixes commit fef73766d9ad ("sunxi: clock: Fix OHCI clock gating for H3/H5")
>
> Signed-off-by: Vasily Khoruzhick
Any feedback on this patch series?
> ---
> arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index 8acf79fbba..8afeaf872e 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -280,8 +280,10 @@ struct sunxi_ccm_reg {
> #define AHB_GATE_OFFSET_USB_EHCI1 26
> #define AHB_GATE_OFFSET_USB_EHCI0 24
> #elif defined(CONFIG_MACH_SUN50I)
> -#define AHB_GATE_OFFSET_USB_OHCI0 29
> -#define AHB_GATE_OFFSET_USB_EHCI0 25
> +#define AHB_GATE_OFFSET_USB_OHCI0 28
> +#define AHB_GATE_OFFSET_USB_OHCI1 29
> +#define AHB_GATE_OFFSET_USB_EHCI0 24
> +#define AHB_GATE_OFFSET_USB_EHCI1 25
> #else
> #define AHB_GATE_OFFSET_USB_OHCI1 30
> #define AHB_GATE_OFFSET_USB_OHCI0 29
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: sdhci: Fix MMC HS200 tuning command failures
Hi Masahiro,
Not sure why it caused issue now, i used git send-email to sent this patch
and always uses the same to send patches. One more thing is i didn't get
your reply mail on my official mail id, and i don't have any clue on what
caused the issue. I may need to check with our IT on both these.
I will talk to Michal, if he can send this patch on my behalf till my
e-mail issue got resolved
Thanks,
Siva
On Tue, Jun 12, 2018 at 5:57 PM, Masahiro Yamada <
yamada.masah...@socionext.com> wrote:
> 2018-06-12 21:00 GMT+09:00 Siva Durga Prasad Paladugu
> :
> > This patch fixes the mmc tuning command failures
> > when tuning pattern data needs to read back for
> > comparision against the excpected bit pattern.
> >
>
> Typo:
>
> excpected -> expected
>
>
> Reported-by: Masahiro Yamada
>
>
> > Signed-off-by: Siva Durga Prasad Paladugu com>
>
>
> This patch does not apply.
>
> I think all the tabs have been replaced with spaces.
>
> What did you use for sending this patch?
> If you used your mailer, it is a bad idea.
>
> I recommend to use 'git send-email' (or patman).
>
>
>
>
>
>
>
> > ---
> > drivers/mmc/sdhci.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > index 40e28ab..cdeba91 100644
> > --- a/drivers/mmc/sdhci.c
> > +++ b/drivers/mmc/sdhci.c
> > @@ -161,8 +161,8 @@ static int sdhci_send_command(struct mmc *mmc,
> struct mmc_cmd *cmd,
> > /* We shouldn't wait for data inihibit for stop commands, even
> >though they might use busy signaling */
> > if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION ||
> > - cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
> > - cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200)
> > + ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
> > + cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200) && !data))
> > mask &= ~SDHCI_DATA_INHIBIT;
> >
> > while (sdhci_readl(host, SDHCI_PRESENT_STATE) & mask) {
> > @@ -184,8 +184,8 @@ static int sdhci_send_command(struct mmc *mmc,
> struct mmc_cmd *cmd,
> > sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
> >
> > mask = SDHCI_INT_RESPONSE;
> > - if (cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
> > - cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200)
> > + if ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
> > +cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200) && !data)
> > mask = SDHCI_INT_DATA_AVAIL;
> >
> > if (!(cmd->resp_type & MMC_RSP_PRESENT))
> > --
> > 2.7.4
> >
> > This email and any attachments are intended for the sole use of the
> named recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are not
> the intended recipient, do not read, copy, or forward this email message or
> any attachments. Delete this email message and any attachments immediately.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
>
>
> --
> Best Regards
> Masahiro Yamada
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] dm: mdio: add a uclass for MDIO
From: Ken Ma
Add a uclass which provides access to MDIO busses and includes
operations required by MDIO.
The implementation is based on the existing mii/phy/mdio data
structures and APIs.
This patch also adds device tree binding for MDIO bus.
Signed-off-by: Ken Ma
Reviewed-by: s...@chromium.org, joe.hershber...@ni.com
---
Changes in v3:
- Move mdio uclass implementation to driver/net folder;
- Replace flat-tree functions with livetree functions and update codes
and comments to be consistent with driver-model codes style;
- Put struct mii_dev to uclass platdata to avoid the mdio alloc and
let driver model framework to alloc the memroy automatically,
meanwhile the mii bus link initialization is added,
Changes in v2: None
MAINTAINERS | 1 +
doc/device-tree-bindings/net/mdio-bus.txt | 54 ++
drivers/Kconfig | 2 +
drivers/net/Makefile | 1 +
drivers/net/mdio/Kconfig | 18 +
drivers/net/mdio/Makefile | 6 ++
drivers/net/mdio/mdio-uclass.c| 112 ++
include/dm/uclass-id.h| 1 +
include/net/mdio.h| 62 +
9 files changed, 257 insertions(+)
create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt
create mode 100644 drivers/net/mdio/Kconfig
create mode 100644 drivers/net/mdio/Makefile
create mode 100644 drivers/net/mdio/mdio-uclass.c
create mode 100644 include/net/mdio.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 642c448..9e1fc83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -335,6 +335,7 @@ M: Simon Glass
S: Maintained
T: git git://git.denx.de/u-boot-dm.git
F: drivers/core/
+F: drivers/net/mdio/
F: include/dm/
F: test/dm/
diff --git a/doc/device-tree-bindings/net/mdio-bus.txt
b/doc/device-tree-bindings/net/mdio-bus.txt
new file mode 100644
index 000..68d8b25
--- /dev/null
+++ b/doc/device-tree-bindings/net/mdio-bus.txt
@@ -0,0 +1,54 @@
+MDIO (Management Data Input/Output) busses
+
+MDIO busses can be described with a node for the MDIO master device
+and a set of child nodes for each phy on the bus.
+
+The MDIO node requires the following properties:
+- #address-cells - number of cells required to define phy address on
+the MDIO bus.
+- #size-cells - should be zero.
+- compatible - name of MDIO bus controller following generic names
+recommended practice.
+- reg- address and length of the MDIO register.
+
+Optional property:
+- mdio-name - MDIO bus name
+
+The child nodes of the MDIO driver are the individual PHY devices
+connected to this MDIO bus. They must have a "reg" property given the
+PHY address on the MDIO bus.
+- reg - (required) phy address in MDIO bus.
+
+Example for cp110 MDIO node at the SoC level:
+ cp0_mdio: mdio@12a200 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x12a200 0x10>;
+ mdio-name = "cp0-mdio";
+ };
+
+ cp0_xmdio: mdio@12a600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,xmdio";
+ reg = <0x12a600 0x200>;
+ mdio-name = "cp0-xmdio";
+ };
+
+And at the board level, example for armada-8040-mcbin board:
+ _mdio {
+ ge_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+
+ _xmdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+
+ phy8: ethernet-phy@8 {
+ reg = <8>;
+ };
+ };
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9e21b28..0e0982c 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -54,6 +54,8 @@ source "drivers/mtd/Kconfig"
source "drivers/net/Kconfig"
+source "drivers/net/mdio/Kconfig"
+
source "drivers/nvme/Kconfig"
source "drivers/pci/Kconfig"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 584bfdf..1cda03f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -70,3 +70,4 @@ obj-$(CONFIG_VSC9953) += vsc9953.o
obj-$(CONFIG_PIC32_ETH) += pic32_mdio.o pic32_eth.o
obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
obj-$(CONFIG_FSL_PFE) += pfe_eth/
+obj-$(CONFIG_MDIO) += mdio/
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
new file mode 100644
index 000..533cc4a
--- /dev/null
+++ b/drivers/net/mdio/Kconfig
@@ -0,0 +1,18 @@
+#
+# MDIO infrastructure and drivers
+#
+
+menu "MDIO Support"
+
+config MDIO
+ bool "Enable MDIO(Management Data Input/Output) drivers"
+ depends on DM
+ help
+ Enable driver model for MDIO access.
+ Drivers provide methods to management data
+ Input/Output.
+ MDIO uclass provides interfaces
[U-Boot] [PATCH v3 0/2] Add MDIO driver model support
From: Ken Ma Changes in v3: - Move mdio uclass implementation to driver/net folder; - Replace flat-tree functions with livetree functions and update codes and comments to be consistent with driver-model codes style; - Put struct mii_dev to uclass platdata to avoid the mdio alloc and let driver model framework to alloc the memroy automatically, meanwhile the mii bus link initialization is added, - Move marvell mdio driver to driver/net/mdio folder; - Update codes according to mdio uclass implementation updates. Changes in v2: - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. Ken Ma (2): dm: mdio: add a uclass for MDIO mdio: add marvell MDIO driver MAINTAINERS | 2 + arch/arm/Kconfig | 1 + doc/device-tree-bindings/net/marvell-mdio.txt | 18 ++ doc/device-tree-bindings/net/mdio-bus.txt | 54 ++ drivers/Kconfig | 2 + drivers/net/Makefile | 1 + drivers/net/mdio/Kconfig | 28 +++ drivers/net/mdio/Makefile | 7 + drivers/net/mdio/mdio-uclass.c| 112 drivers/net/mdio/mvmdio.c | 234 ++ include/dm/uclass-id.h| 1 + include/net/mdio.h| 62 +++ 12 files changed, 522 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt create mode 100644 drivers/net/mdio/Kconfig create mode 100644 drivers/net/mdio/Makefile create mode 100644 drivers/net/mdio/mdio-uclass.c create mode 100644 drivers/net/mdio/mvmdio.c create mode 100644 include/net/mdio.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] mdio: add marvell MDIO driver
From: Ken Ma This patch adds a separate driver for the MDIO interface of the Marvell Ethernet controllers based on driver model. There are two reasons to have a separate driver rather than including it inside the MAC driver itself: *) The MDIO interface is shared by all Ethernet ports, so a driver must guarantee non-concurrent accesses to this MDIO interface. The most logical way is to have a separate driver that handles this single MDIO interface, used by all Ethernet ports. *) The MDIO interface is the same between the existing mv643xx_eth driver and the new mvneta/mvpp2 driver. Even though it is for now only used by the mvneta/mvpp2 driver, it will in the future be used by the mv643xx_eth driver as well. This driver supports SMI IEEE for 802.3 Clause 22 and XSMI for IEEE 802.3 Clause 45. This patch also adds device tree binding for marvell MDIO driver. Signed-off-by: Ken Ma Reviewed-by: Chris Packham --- Changes in v3: - Move marvell mdio driver to driver/net/mdio folder; - Update codes according to mdio uclass implementation updates. Changes in v2: - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. MAINTAINERS | 1 + arch/arm/Kconfig | 1 + doc/device-tree-bindings/net/marvell-mdio.txt | 18 ++ drivers/net/mdio/Kconfig | 10 ++ drivers/net/mdio/Makefile | 1 + drivers/net/mdio/mvmdio.c | 234 ++ 6 files changed, 265 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 drivers/net/mdio/mvmdio.c diff --git a/MAINTAINERS b/MAINTAINERS index 9e1fc83..d8584f9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -137,6 +137,7 @@ T: git git://git.denx.de/u-boot-marvell.git F: arch/arm/mach-kirkwood/ F: arch/arm/mach-mvebu/ F: drivers/ata/ahci_mvebu.c +F: drivers/net/mdio/mvmdio.c ARM MARVELL PXA M: Marek Vasut diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index dde422b..e52b164 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -432,6 +432,7 @@ config ARCH_MVEBU select DM_SPI select DM_SPI_FLASH select SPI + select MDIO config TARGET_DEVKIT3250 bool "Support devkit3250" diff --git a/doc/device-tree-bindings/net/marvell-mdio.txt b/doc/device-tree-bindings/net/marvell-mdio.txt new file mode 100644 index 000..55db435 --- /dev/null +++ b/doc/device-tree-bindings/net/marvell-mdio.txt @@ -0,0 +1,18 @@ +* Marvell MDIO Ethernet Controller interface + +The Ethernet controllers of the Marvel Armada 3700 and Armada 7k/8k +have an identical unit that provides an interface with the MDIO bus. +This driver handles this MDIO interface. + +Mandatory properties: +SoC specific: + - #address-cells: Must be <1>. + - #size-cells: Must be <0>. + - compatible: Should be "marvell,orion-mdio" (for SMI) + "marvell,xmdio" (for XSMI) + - reg: Base address and size SMI/XMSI bus. + +Optional properties: + - mdio-name - MDIO bus name + +For example, please refer to "mdio-bus.txt". diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig index 533cc4a..d1a31e6 100644 --- a/drivers/net/mdio/Kconfig +++ b/drivers/net/mdio/Kconfig @@ -15,4 +15,14 @@ config MDIO udevice or mii bus from its child phy node or an ethernet udevice which the phy belongs to. +config MVMDIO + bool "Marvell MDIO interface support" + depends on MDIO + select PHYLIB + help + This driver supports the MDIO interface found in the network + interface units of the Marvell EBU SoCs (Kirkwood, Orion5x, + Dove, Armada 370, Armada XP, Armada 37xx and Armada7K/8K/8KP). + + This driver is used by the MVPP2 and MVNETA drivers. endmenu diff --git a/drivers/net/mdio/Makefile b/drivers/net/mdio/Makefile index 45ae502..8b2e5a4 100644 --- a/drivers/net/mdio/Makefile +++ b/drivers/net/mdio/Makefile @@ -4,3 +4,4 @@ # Author: Ken Ma obj-$(CONFIG_MDIO) += mdio-uclass.o +obj-$(CONFIG_MVMDIO) += mvmdio.o diff --git a/drivers/net/mdio/mvmdio.c b/drivers/net/mdio/mvmdio.c new file mode 100644 index 000..0fb45ce --- /dev/null +++ b/drivers/net/mdio/mvmdio.c @@ -0,0 +1,234 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Marvell International Ltd. + * Author: Ken Ma + */ + +#include +#include +#include +#include +#include +#include +#include + +#define MVMDIO_SMI_DATA_SHIFT 0 +#define MVMDIO_SMI_PHY_ADDR_SHIFT 16 +#define MVMDIO_SMI_PHY_REG_SHIFT 21 +#define MVMDIO_SMI_READ_OPERATION BIT(26) +#define MVMDIO_SMI_WRITE_OPERATION 0 +#define MVMDIO_SMI_READ_VALID BIT(27) +#define MVMDIO_SMI_BUSYBIT(28) +
Re: [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
On 06/13/2018 06:38 AM, Peng Fan wrote: > Hi Marek, > >> -Original Message- >> From: Marek Vasut [mailto:marek.va...@gmail.com] >> Sent: 2018年6月13日 12:35 >> To: Peng Fan ; jh80.ch...@samsung.com >> Cc: Kishon Vijay Abraham I ; u-boot@lists.denx.de >> Subject: Re: [U-Boot] [PATCH V3 1/2] mmc: add HS400 support >> >> On 05/19/2018 02:54 PM, Peng Fan wrote: >>> Add HS400 support. >>> Selecting HS400 needs first select HS199 according to spec, so use a >>> dedicated function for HS400. >>> Add HS400 related macros. >>> Remove the restriction of only using the low 6 bits of >>> EXT_CSD_CARD_TYPE, using all the 8 bits. >>> >>> Signed-off-by: Peng Fan >>> Cc: Jaehoon Chung >>> Cc: Jean-Jacques Hiblot >>> Cc: Stefano Babic >>> Cc: Simon Glass >>> Cc: Kishon Vijay Abraham I >>> Cc: Bin Meng >> >> Which controller do you use to test the HS400 ? > > It is i.MX8QXP/QM. The QXP support is in patch reviewing process. I see. I'll try this on the Renesas Gen3 SDHI controller. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] mdio: add marvell MDIO driver
From: Ken Ma This patch adds a separate driver for the MDIO interface of the Marvell Ethernet controllers based on driver model. There are two reasons to have a separate driver rather than including it inside the MAC driver itself: *) The MDIO interface is shared by all Ethernet ports, so a driver must guarantee non-concurrent accesses to this MDIO interface. The most logical way is to have a separate driver that handles this single MDIO interface, used by all Ethernet ports. *) The MDIO interface is the same between the existing mv643xx_eth driver and the new mvneta/mvpp2 driver. Even though it is for now only used by the mvneta/mvpp2 driver, it will in the future be used by the mv643xx_eth driver as well. This driver supports SMI IEEE for 802.3 Clause 22 and XSMI for IEEE 802.3 Clause 45. This patch also adds device tree binding for marvell MDIO driver. Signed-off-by: Ken Ma Reviewed-by: Chris Packham --- Changes in v3: - Move marvell mdio driver to driver/net/mdio folder; - Update codes according to mdio uclass implementation updates. Changes in v2: - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. MAINTAINERS | 1 + arch/arm/Kconfig | 1 + doc/device-tree-bindings/net/marvell-mdio.txt | 18 ++ drivers/net/mdio/Kconfig | 10 ++ drivers/net/mdio/Makefile | 1 + drivers/net/mdio/mvmdio.c | 234 ++ 6 files changed, 265 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 drivers/net/mdio/mvmdio.c diff --git a/MAINTAINERS b/MAINTAINERS index 9e1fc83..d8584f9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -137,6 +137,7 @@ T: git git://git.denx.de/u-boot-marvell.git F: arch/arm/mach-kirkwood/ F: arch/arm/mach-mvebu/ F: drivers/ata/ahci_mvebu.c +F: drivers/net/mdio/mvmdio.c ARM MARVELL PXA M: Marek Vasut diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index dde422b..e52b164 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -432,6 +432,7 @@ config ARCH_MVEBU select DM_SPI select DM_SPI_FLASH select SPI + select MDIO config TARGET_DEVKIT3250 bool "Support devkit3250" diff --git a/doc/device-tree-bindings/net/marvell-mdio.txt b/doc/device-tree-bindings/net/marvell-mdio.txt new file mode 100644 index 000..55db435 --- /dev/null +++ b/doc/device-tree-bindings/net/marvell-mdio.txt @@ -0,0 +1,18 @@ +* Marvell MDIO Ethernet Controller interface + +The Ethernet controllers of the Marvel Armada 3700 and Armada 7k/8k +have an identical unit that provides an interface with the MDIO bus. +This driver handles this MDIO interface. + +Mandatory properties: +SoC specific: + - #address-cells: Must be <1>. + - #size-cells: Must be <0>. + - compatible: Should be "marvell,orion-mdio" (for SMI) + "marvell,xmdio" (for XSMI) + - reg: Base address and size SMI/XMSI bus. + +Optional properties: + - mdio-name - MDIO bus name + +For example, please refer to "mdio-bus.txt". diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig index 533cc4a..d1a31e6 100644 --- a/drivers/net/mdio/Kconfig +++ b/drivers/net/mdio/Kconfig @@ -15,4 +15,14 @@ config MDIO udevice or mii bus from its child phy node or an ethernet udevice which the phy belongs to. +config MVMDIO + bool "Marvell MDIO interface support" + depends on MDIO + select PHYLIB + help + This driver supports the MDIO interface found in the network + interface units of the Marvell EBU SoCs (Kirkwood, Orion5x, + Dove, Armada 370, Armada XP, Armada 37xx and Armada7K/8K/8KP). + + This driver is used by the MVPP2 and MVNETA drivers. endmenu diff --git a/drivers/net/mdio/Makefile b/drivers/net/mdio/Makefile index 45ae502..8b2e5a4 100644 --- a/drivers/net/mdio/Makefile +++ b/drivers/net/mdio/Makefile @@ -4,3 +4,4 @@ # Author: Ken Ma obj-$(CONFIG_MDIO) += mdio-uclass.o +obj-$(CONFIG_MVMDIO) += mvmdio.o diff --git a/drivers/net/mdio/mvmdio.c b/drivers/net/mdio/mvmdio.c new file mode 100644 index 000..0fb45ce --- /dev/null +++ b/drivers/net/mdio/mvmdio.c @@ -0,0 +1,234 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Marvell International Ltd. + * Author: Ken Ma + */ + +#include +#include +#include +#include +#include +#include +#include + +#define MVMDIO_SMI_DATA_SHIFT 0 +#define MVMDIO_SMI_PHY_ADDR_SHIFT 16 +#define MVMDIO_SMI_PHY_REG_SHIFT 21 +#define MVMDIO_SMI_READ_OPERATION BIT(26) +#define MVMDIO_SMI_WRITE_OPERATION 0 +#define MVMDIO_SMI_READ_VALID BIT(27) +#define MVMDIO_SMI_BUSYBIT(28) +
[U-Boot] [PATCH v3 1/2] dm: mdio: add a uclass for MDIO
From: Ken Ma
Add a uclass which provides access to MDIO busses and includes
operations required by MDIO.
The implementation is based on the existing mii/phy/mdio data
structures and APIs.
This patch also adds evice tree binding for MDIO bus.
Signed-off-by: Ken Ma
Reviewed-by: s...@chromium.org, joe.hershber...@ni.com
---
Changes in v3:
- Move mdio uclass implementation to driver/net folder;
- Replace flat-tree functions with livetree functions and update codes
and comments to be consistent with driver-model codes style;
- Put struct mii_dev to uclass platdata to avoid the mdio alloc and
let driver model framework to alloc the memroy automatically,
meanwhile the mii bus link initialization is added,
Changes in v2: None
MAINTAINERS | 1 +
doc/device-tree-bindings/net/mdio-bus.txt | 54 ++
drivers/Kconfig | 2 +
drivers/net/Makefile | 1 +
drivers/net/mdio/Kconfig | 18 +
drivers/net/mdio/Makefile | 6 ++
drivers/net/mdio/mdio-uclass.c| 112 ++
include/dm/uclass-id.h| 1 +
include/net/mdio.h| 62 +
9 files changed, 257 insertions(+)
create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt
create mode 100644 drivers/net/mdio/Kconfig
create mode 100644 drivers/net/mdio/Makefile
create mode 100644 drivers/net/mdio/mdio-uclass.c
create mode 100644 include/net/mdio.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 642c448..9e1fc83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -335,6 +335,7 @@ M: Simon Glass
S: Maintained
T: git git://git.denx.de/u-boot-dm.git
F: drivers/core/
+F: drivers/net/mdio/
F: include/dm/
F: test/dm/
diff --git a/doc/device-tree-bindings/net/mdio-bus.txt
b/doc/device-tree-bindings/net/mdio-bus.txt
new file mode 100644
index 000..68d8b25
--- /dev/null
+++ b/doc/device-tree-bindings/net/mdio-bus.txt
@@ -0,0 +1,54 @@
+MDIO (Management Data Input/Output) busses
+
+MDIO busses can be described with a node for the MDIO master device
+and a set of child nodes for each phy on the bus.
+
+The MDIO node requires the following properties:
+- #address-cells - number of cells required to define phy address on
+the MDIO bus.
+- #size-cells - should be zero.
+- compatible - name of MDIO bus controller following generic names
+recommended practice.
+- reg- address and length of the MDIO register.
+
+Optional property:
+- mdio-name - MDIO bus name
+
+The child nodes of the MDIO driver are the individual PHY devices
+connected to this MDIO bus. They must have a "reg" property given the
+PHY address on the MDIO bus.
+- reg - (required) phy address in MDIO bus.
+
+Example for cp110 MDIO node at the SoC level:
+ cp0_mdio: mdio@12a200 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x12a200 0x10>;
+ mdio-name = "cp0-mdio";
+ };
+
+ cp0_xmdio: mdio@12a600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,xmdio";
+ reg = <0x12a600 0x200>;
+ mdio-name = "cp0-xmdio";
+ };
+
+And at the board level, example for armada-8040-mcbin board:
+ _mdio {
+ ge_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+
+ _xmdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+
+ phy8: ethernet-phy@8 {
+ reg = <8>;
+ };
+ };
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9e21b28..0e0982c 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -54,6 +54,8 @@ source "drivers/mtd/Kconfig"
source "drivers/net/Kconfig"
+source "drivers/net/mdio/Kconfig"
+
source "drivers/nvme/Kconfig"
source "drivers/pci/Kconfig"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 584bfdf..1cda03f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -70,3 +70,4 @@ obj-$(CONFIG_VSC9953) += vsc9953.o
obj-$(CONFIG_PIC32_ETH) += pic32_mdio.o pic32_eth.o
obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
obj-$(CONFIG_FSL_PFE) += pfe_eth/
+obj-$(CONFIG_MDIO) += mdio/
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
new file mode 100644
index 000..533cc4a
--- /dev/null
+++ b/drivers/net/mdio/Kconfig
@@ -0,0 +1,18 @@
+#
+# MDIO infrastructure and drivers
+#
+
+menu "MDIO Support"
+
+config MDIO
+ bool "Enable MDIO(Management Data Input/Output) drivers"
+ depends on DM
+ help
+ Enable driver model for MDIO access.
+ Drivers provide methods to management data
+ Input/Output.
+ MDIO uclass provides interfaces
[U-Boot] [PATCH v3 0/2] Add MDIO driver model support
From: Ken Ma Changes in v3: - Move mdio uclass implementation to driver/net folder; - Replace flat-tree functions with livetree functions and update codes and comments to be consistent with driver-model codes style; - Put struct mii_dev to uclass platdata to avoid the mdio alloc and let driver model framework to alloc the memroy automatically, meanwhile the mii bus link initialization is added, - Move marvell mdio driver to driver/net/mdio folder; - Update codes according to mdio uclass implementation updates. Changes in v2: - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. Ken Ma (2): dm: mdio: add a uclass for MDIO mdio: add marvell MDIO driver MAINTAINERS | 2 + arch/arm/Kconfig | 1 + doc/device-tree-bindings/net/marvell-mdio.txt | 18 ++ doc/device-tree-bindings/net/mdio-bus.txt | 54 ++ drivers/Kconfig | 2 + drivers/net/Makefile | 1 + drivers/net/mdio/Kconfig | 28 +++ drivers/net/mdio/Makefile | 7 + drivers/net/mdio/mdio-uclass.c| 112 drivers/net/mdio/mvmdio.c | 234 ++ include/dm/uclass-id.h| 1 + include/net/mdio.h| 62 +++ 12 files changed, 522 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt create mode 100644 drivers/net/mdio/Kconfig create mode 100644 drivers/net/mdio/Makefile create mode 100644 drivers/net/mdio/mdio-uclass.c create mode 100644 drivers/net/mdio/mvmdio.c create mode 100644 include/net/mdio.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
Hi Marek, > -Original Message- > From: Marek Vasut [mailto:marek.va...@gmail.com] > Sent: 2018年6月13日 12:35 > To: Peng Fan ; jh80.ch...@samsung.com > Cc: Kishon Vijay Abraham I ; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH V3 1/2] mmc: add HS400 support > > On 05/19/2018 02:54 PM, Peng Fan wrote: > > Add HS400 support. > > Selecting HS400 needs first select HS199 according to spec, so use a > > dedicated function for HS400. > > Add HS400 related macros. > > Remove the restriction of only using the low 6 bits of > > EXT_CSD_CARD_TYPE, using all the 8 bits. > > > > Signed-off-by: Peng Fan > > Cc: Jaehoon Chung > > Cc: Jean-Jacques Hiblot > > Cc: Stefano Babic > > Cc: Simon Glass > > Cc: Kishon Vijay Abraham I > > Cc: Bin Meng > > Which controller do you use to test the HS400 ? It is i.MX8QXP/QM. The QXP support is in patch reviewing process. -Peng. > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
On 05/19/2018 02:54 PM, Peng Fan wrote: > Add HS400 support. > Selecting HS400 needs first select HS199 according to spec, so use > a dedicated function for HS400. > Add HS400 related macros. > Remove the restriction of only using the low 6 bits of > EXT_CSD_CARD_TYPE, using all the 8 bits. > > Signed-off-by: Peng Fan > Cc: Jaehoon Chung > Cc: Jean-Jacques Hiblot > Cc: Stefano Babic > Cc: Simon Glass > Cc: Kishon Vijay Abraham I > Cc: Bin Meng Which controller do you use to test the HS400 ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
On 05/24/2018 02:23 PM, Peng Fan wrote: > Hi Fabio, > >> -Original Message- >> From: Fabio Estevam [mailto:feste...@gmail.com] >> Sent: 2018年5月19日 22:39 >> To: Peng Fan >> Cc: Jaehoon Chung ; Kishon Vijay Abraham I >> ; U-Boot-Denx >> Subject: Re: [U-Boot] [PATCH V3 1/2] mmc: add HS400 support >> >> On Sat, May 19, 2018 at 9:54 AM, Peng Fan wrote: >>> Add HS400 support. >>> Selecting HS400 needs first select HS199 according to spec, so use >> >> I think you meant HS200 instead? > Yes HS200, thanks. > > Jaehoon, would you mind help fix the typo if no more comments? Bump ? This patch would be useful upstream, IMO it looks OK too. Jaehoon, what is going on ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 9/9] MAINTAINERS: Add entries for Actions Semi OWL family
Add myself as the Maintainer for Actions Semi OWL family and its relevant board, drivers. Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 642c448093..0f70cb04fe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -145,6 +145,15 @@ T: git git://git.denx.de/u-boot-pxa.git F: arch/arm/cpu/pxa/ F: arch/arm/include/asm/arch-pxa/ +ARM OWL +M: Manivannan Sadhasivam +S: Maintained +F: arch/arm/include/asm/arch-owl/ +F: arch/arm/mach-owl/ +F: board/ucRobotics/ +F: drivers/clk/owl/ +F: drivers/serial/serial_owl.c + ARM RENESAS RMOBILE/R-CAR M: Nobuhiro Iwamatsu M: Marek Vasut -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 8/9] serial: Add Actions Semi OWL UART support
This commit adds Actions Semi OWL family UART support. This driver
relies on baudrate configured by primary bootloaders.
Signed-off-by: Manivannan Sadhasivam
---
drivers/serial/Kconfig | 8 +++
drivers/serial/Makefile | 1 +
drivers/serial/serial_owl.c | 136
3 files changed, 145 insertions(+)
create mode 100644 drivers/serial/serial_owl.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 2940bd05dc..766e5ced03 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -625,6 +625,14 @@ config MSM_SERIAL
for example APQ8016 and MSM8916.
Single baudrate is supported in current implementation (115200).
+config OWL_SERIAL
+ bool "Actions Semi OWL UART"
+ depends on DM_SERIAL && ARCH_OWL
+ help
+ If you have a Actions Semi OWL based board and want to use the on-chip
+ serial port, say Y to this option. If unsure, say N.
+ Single baudrate is supported in current implementation (115200).
+
config PXA_SERIAL
bool "PXA serial port support"
help
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index e66899489e..9fa81d855d 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_MSM_SERIAL) += serial_msm.o
obj-$(CONFIG_MVEBU_A3700_UART) += serial_mvebu_a3700.o
obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o
obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o
+obj-$(CONFIG_OWL_SERIAL) += serial_owl.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial_owl.c b/drivers/serial/serial_owl.c
new file mode 100644
index 00..6fd97e2502
--- /dev/null
+++ b/drivers/serial/serial_owl.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semi OWL SoCs UART driver
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* UART Registers */
+#defineOWL_UART_CTL(0x)
+#defineOWL_UART_RXDAT (0x0004)
+#defineOWL_UART_TXDAT (0x0008)
+#defineOWL_UART_STAT (0x000C)
+
+/* UART_CTL Register Definitions */
+#defineOWL_UART_CTL_PRS_NONE GENMASK(6, 4)
+#defineOWL_UART_CTL_STPS BIT(2)
+#defineOWL_UART_CTL_DWLS 3
+
+/* UART_STAT Register Definitions */
+#defineOWL_UART_STAT_TFES BIT(10) /* TX FIFO Empty Status
*/
+#defineOWL_UART_STAT_RFFS BIT(9) /* RX FIFO full Status
*/
+#defineOWL_UART_STAT_TFFU BIT(6) /* TX FIFO full Status
*/
+#defineOWL_UART_STAT_RFEM BIT(5) /* RX FIFO Empty Status
*/
+
+struct owl_serial_priv {
+ phys_addr_t base;
+};
+
+int owl_serial_setbrg(struct udevice *dev, int baudrate)
+{
+ /* Driver supports only fixed baudrate */
+ return 0;
+}
+
+static int owl_serial_getc(struct udevice *dev)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+
+ if (readl(priv->base + OWL_UART_STAT) & OWL_UART_STAT_RFEM)
+ return -EAGAIN;
+
+ return (int)(readl(priv->base + OWL_UART_RXDAT));
+}
+
+static int owl_serial_putc(struct udevice *dev,const char ch)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+
+ if (readl(priv->base + OWL_UART_STAT) & OWL_UART_STAT_TFFU)
+ return -EAGAIN;
+
+ writel(ch, priv->base + OWL_UART_TXDAT);
+
+ return 0;
+}
+
+static int owl_serial_pending(struct udevice *dev, boolinput)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+ unsigned int stat = readl(priv->base + OWL_UART_STAT);
+
+ if (input)
+ return !(stat & OWL_UART_STAT_RFEM);
+ else
+ return !(stat & OWL_UART_STAT_TFES);
+}
+
+static int owl_serial_probe(struct udevice *dev)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+ struct clk clk;
+ u32 uart_ctl;
+ int ret;
+
+ /* Set data, parity and stop bits */
+ uart_ctl = readl(priv->base + OWL_UART_CTL);
+ uart_ctl &= ~(OWL_UART_CTL_PRS_NONE);
+ uart_ctl &= ~(OWL_UART_CTL_STPS);
+ uart_ctl |= OWL_UART_CTL_DWLS;
+ writel(uart_ctl, priv->base + OWL_UART_CTL);
+
+ /* Enable UART clock */
+ ret = clk_get_by_index(dev, 0, );
+ if (ret < 0)
+ return ret;
+
+ ret = clk_enable();
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int owl_serial_ofdata_to_platdata(structudevice *dev)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+
+ priv->base = dev_read_addr(dev);
+ if (priv->base == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ return 0;
+}
+
+static const struct dm_serial_ops
[U-Boot] [PATCH v2 7/9] arm: dts: bubblegum_96: Enable UART5 for serial console
This commit enables UART5 found in S900 SoC for serial console support.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/dts/bubblegum_96.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/dts/bubblegum_96.dts b/arch/arm/dts/bubblegum_96.dts
index 4e34ebaa49..5b58d15594 100644
--- a/arch/arm/dts/bubblegum_96.dts
+++ b/arch/arm/dts/bubblegum_96.dts
@@ -12,8 +12,20 @@
model = "Bubblegum-96";
compatible = "ucrobotics,bubblegum-96", "actions,s900";
+ aliases {
+ serial5 =
+ };
+
+ chosen {
+ stdout-path = "serial5:115200n8";
+ };
+
memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>;
};
};
+
+ {
+ status = "okay";
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/9] arm: dts: s900: Add UART node
This commit adds UART node for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/dts/s900.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
index e9d47b1ff1..2bbb30a5a8 100644
--- a/arch/arm/dts/s900.dtsi
+++ b/arch/arm/dts/s900.dtsi
@@ -32,6 +32,14 @@
#size-cells = <0x2>;
ranges;
+ uart5: serial@e012a000 {
+ u-boot,dm-pre-reloc;
+ compatible = "actions,s900-serial";
+ reg = <0x0 0xe012a000 0x0 0x1000>;
+ clocks = < CLOCK_UART5>;
+ status = "disabled";
+ };
+
cmu: clock-controller@e016 {
u-boot,dm-pre-reloc;
compatible = "actions,s900-cmu";
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/9] clk: Add Actions Semi OWL clock support
This commit adds Actions Semi OWL family base clock and S900 SoC specific
clock support. For S900 peripheral clock support, only UART clock has been
added for now.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/include/asm/arch-owl/clk_s900.h | 57 +
arch/arm/include/asm/arch-owl/regs_s900.h | 64 ++
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/owl/Kconfig | 12 ++
drivers/clk/owl/Makefile | 3 +
drivers/clk/owl/clk_s900.c| 138 ++
7 files changed, 276 insertions(+)
create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
create mode 100644 drivers/clk/owl/Kconfig
create mode 100644 drivers/clk/owl/Makefile
create mode 100644 drivers/clk/owl/clk_s900.c
diff --git a/arch/arm/include/asm/arch-owl/clk_s900.h
b/arch/arm/include/asm/arch-owl/clk_s900.h
new file mode 100644
index 00..88e88f77f8
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/clk_s900.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S900 Clock Definitions
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ *
+ */
+
+#ifndef _OWL_CLK_S900_H_
+#define _OWL_CLK_S900_H_
+
+#include
+
+struct owl_clk_priv {
+ phys_addr_t base;
+};
+
+/* BUSCLK register definitions */
+#define CMU_PDBGDIV_8 7
+#define CMU_PDBGDIV_SHIFT 26
+#define CMU_PDBGDIV_DIV(CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
+#define CMU_PERDIV_8 7
+#define CMU_PERDIV_SHIFT 20
+#define CMU_PERDIV_DIV (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
+#define CMU_NOCDIV_2 1
+#define CMU_NOCDIV_SHIFT 19
+#define CMU_NOCDIV_DIV (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
+#define CMU_DMMCLK_SRC_APLL2
+#define CMU_DMMCLK_SRC_SHIFT 10
+#define CMU_DMMCLK_SRC (CMU_DMMCLK_SRC_APLL << CMU_DMMCLK_SRC_SHIFT)
+#define CMU_APBCLK_DIV BIT(8)
+#define CMU_NOCCLK_SRC BIT(7)
+#define CMU_AHBCLK_DIV BIT(4)
+#define CMU_CORECLK_MASK 3
+#define CMU_CORECLK_CPLL BIT(1)
+#define CMU_CORECLK_HOSC BIT(0)
+
+/* COREPLL register definitions */
+#define CMU_COREPLL_EN BIT(9)
+#define CMU_COREPLL_HOSC_ENBIT(8)
+#define CMU_COREPLL_OUT(1104 / 24)
+
+/* DEVPLL register definitions */
+#define CMU_DEVPLL_CLK BIT(12)
+#define CMU_DEVPLL_EN BIT(8)
+#define CMU_DEVPLL_OUT (660 / 6)
+
+/* UARTCLK register definitions */
+#define CMU_UARTCLK_SRC_DEVPLL BIT(16)
+
+/* DEVCLKEN1 register definitions */
+#define CMU_DEVCLKEN1_UART5BIT(21)
+
+#define PLL_STABILITY_WAIT_US 50
+
+#endif
diff --git a/arch/arm/include/asm/arch-owl/regs_s900.h
b/arch/arm/include/asm/arch-owl/regs_s900.h
new file mode 100644
index 00..9e9106ddaa
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/regs_s900.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S900 Register Definitions
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ *
+ */
+
+#ifndef _OWL_REGS_S900_H_
+#define _OWL_REGS_S900_H_
+
+/* CMU registers */
+#define CMU_COREPLL(0x)
+#define CMU_DEVPLL (0x0004)
+#define CMU_DDRPLL (0x0008)
+#define CMU_NANDPLL(0x000C)
+#define CMU_DISPLAYPLL (0x0010)
+#define CMU_AUDIOPLL (0x0014)
+#define CMU_TVOUTPLL (0x0018)
+#define CMU_BUSCLK (0x001C)
+#define CMU_SENSORCLK (0x0020)
+#define CMU_LCDCLK (0x0024)
+#define CMU_DSICLK (0x0028)
+#define CMU_CSICLK (0x002C)
+#define CMU_DECLK (0x0030)
+#define CMU_BISPCLK(0x0034)
+#define CMU_IMXCLK (0x0038)
+#define CMU_HDECLK (0x003C)
+#define CMU_VDECLK (0x0040)
+#define CMU_VCECLK (0x0044)
+#define CMU_NANDCCLK (0x004C)
+#define CMU_SD0CLK (0x0050)
+#define CMU_SD1CLK (0x0054)
+#define CMU_SD2CLK (0x0058)
+#define CMU_UART0CLK (0x005C)
+#define CMU_UART1CLK (0x0060)
+#define CMU_UART2CLK (0x0064)
+#define CMU_PWM0CLK(0x0070)
+#define CMU_PWM1CLK(0x0074)
+#define CMU_PWM2CLK(0x0078)
+#define CMU_PWM3CLK(0x007C)
+#define CMU_USBPLL
[U-Boot] [PATCH v2 3/9] dt-bindings: clock: Add S900 CMU register definitions
This commit adds Actions Semi S900 CMU register definitions to clock bindings. Signed-off-by: Manivannan Sadhasivam --- include/dt-bindings/clock/s900_cmu.h | 77 1 file changed, 77 insertions(+) create mode 100644 include/dt-bindings/clock/s900_cmu.h diff --git a/include/dt-bindings/clock/s900_cmu.h b/include/dt-bindings/clock/s900_cmu.h new file mode 100644 index 00..2685a6df4a --- /dev/null +++ b/include/dt-bindings/clock/s900_cmu.h @@ -0,0 +1,77 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2015 Actions Semi Co., Ltd. + * Copyright (C) 2018 Manivannan Sadhasivam + * + */ + +#ifndef _DT_BINDINGS_CLOCK_S900_CMU_H_ +#define _DT_BINDINGS_CLOCK_S900_CMU_H_ + +/* Module Clock ID */ +#define CLOCK_DDRCH1 0 +#define CLOCK_DMAC 1 +#define CLOCK_DDRCH0 2 +#define CLOCK_BROM 3 +#define CLOCK_NANDC0 4 +#define CLOCK_SD0 5 +#define CLOCK_SD1 6 +#define CLOCK_SD2 7 +#define CLOCK_DE 8 +#define CLOCK_LVDS 9 +#define CLOCK_EDP 10 +#define CLOCK_NANDC1 11 +#define CLOCK_DSI 12 +#define CLOCK_CSI0 13 +#define CLOCK_BISP 14 +#define CLOCK_CSI1 15 +#define CLOCK_SD3 16 +#define CLOCK_I2C4 17 +#define CLOCK_GPIO 18 +#define CLOCK_DMM 19 +#define CLOCK_I2STX20 +#define CLOCK_I2SRX21 +#define CLOCK_HDMIA22 +#define CLOCK_SPDIF23 +#define CLOCK_PCM0 24 +#define CLOCK_VDE 25 +#define CLOCK_VCE 26 +#define CLOCK_HDE 27 +#define CLOCK_SHARESRAM28 +#define CLOCK_CMU_DDR1 29 +#define CLOCK_GPU3D30 +#define CLOCK_CMUDDR0 31 +#define CLOCK_SPEED32 +#define CLOCK_I2C5 33 +#define CLOCK_THERMAL 34 +#define CLOCK_HDMI 35 +#define CLOCK_PWM4 36 +#define CLOCK_PWM5 37 +#define CLOCK_UART038 +#define CLOCK_UART139 +#define CLOCK_UART240 +#define CLOCK_IRC 41 +#define CLOCK_SPI0 42 +#define CLOCK_SPI1 43 +#define CLOCK_SPI2 44 +#define CLOCK_SPI3 45 +#define CLOCK_I2C0 46 +#define CLOCK_I2C1 47 +#define CLOCK_PCM1 48 +#define CLOCK_IMX 49 +#define CLOCK_UART650 +#define CLOCK_UART351 +#define CLOCK_UART452 +#define CLOCK_UART553 +#define CLOCK_ETHERNET 54 +#define CLOCK_PWM0 55 +#define CLOCK_PWM1 56 +#define CLOCK_PWM2 57 +#define CLOCK_PWM3 58 +#define CLOCK_TIMER59 +#define CLOCK_SE 60 +#define CLOCK_HDCP2TX 61 +#define CLOCK_I2C2 62 +#define CLOCK_I2C3 63 + +#endif -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/9] arm: dts: s900: Add Clock Management Unit (CMU) nodes
This commit adds Clock Management Unit (CMU) nodes for Actions Semi
S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/dts/s900.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
index 3bd14b82d4..e9d47b1ff1 100644
--- a/arch/arm/dts/s900.dtsi
+++ b/arch/arm/dts/s900.dtsi
@@ -6,18 +6,40 @@
// Copyright (C) 2018 Manivannan Sadhasivam
/dts-v1/;
+#include
/ {
compatible = "actions,s900";
#address-cells = <0x2>;
#size-cells = <0x2>;
+ losc: losc {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+
+ diff24M: diff24M {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ #clock-cells = <0>;
+ };
+
soc {
u-boot,dm-pre-reloc;
compatible = "simple-bus";
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;
+
+ cmu: clock-controller@e016 {
+ u-boot,dm-pre-reloc;
+ compatible = "actions,s900-cmu";
+ reg = <0x0 0xe016 0x0 0x1000>;
+ clocks = <>, <>;
+ clock-names = "losc", "diff24M";
+ #clock-cells = <1>;
+ };
};
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/9] board: Add uCRobotics Bubblegum-96 board support
This commit adds uCRobotics Bubblegum-96 board support. This board is
one of the 96Boards Consumer Edition platform based on Actions Semi
S900 SoC.
Features:
- Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
- 2GiB RAM
- 8GiB eMMC, uSD slot
- WiFi, Bluetooth and GPS module
- 2x Host, 1x Device USB port
- HDMI
- 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
U-Boot will be loaded by ATF at EL2 execution level. Relevant driver
support will be added in further commits.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/Kconfig | 1 +
arch/arm/dts/bubblegum_96.dts| 19 +++
arch/arm/mach-owl/Kconfig| 21
board/ucRobotics/bubblegum_96/Kconfig| 15 ++
board/ucRobotics/bubblegum_96/MAINTAINERS| 6 +++
board/ucRobotics/bubblegum_96/Makefile | 3 ++
board/ucRobotics/bubblegum_96/bubblegum_96.c | 56
configs/bubblegum_96_defconfig | 22
include/configs/bubblegum_96.h | 43 +++
9 files changed, 186 insertions(+)
create mode 100644 arch/arm/dts/bubblegum_96.dts
create mode 100644 board/ucRobotics/bubblegum_96/Kconfig
create mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
create mode 100644 board/ucRobotics/bubblegum_96/Makefile
create mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c
create mode 100644 configs/bubblegum_96_defconfig
create mode 100644 include/configs/bubblegum_96.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec0bb5a42b..6e203f96aa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1431,6 +1431,7 @@ source "board/spear/spear600/Kconfig"
source "board/spear/x600/Kconfig"
source "board/st/stv0991/Kconfig"
source "board/tcl/sl50/Kconfig"
+source "board/ucRobotics/bubblegum_96/Kconfig"
source "board/birdland/bav335x/Kconfig"
source "board/timll/devkit3250/Kconfig"
source "board/toradex/colibri_pxa270/Kconfig"
diff --git a/arch/arm/dts/bubblegum_96.dts b/arch/arm/dts/bubblegum_96.dts
new file mode 100644
index 00..4e34ebaa49
--- /dev/null
+++ b/arch/arm/dts/bubblegum_96.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Device Tree Source for Bubblegum-96
+//
+// Copyright (C) 2015 Actions Semi Co., Ltd.
+// Copyright (C) 2018 Manivannan Sadhasivam
+
+/dts-v1/;
+#include "s900.dtsi"
+
+/ {
+ model = "Bubblegum-96";
+ compatible = "ucrobotics,bubblegum-96", "actions,s900";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+};
diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
index f695c16d1e..199e772988 100644
--- a/arch/arm/mach-owl/Kconfig
+++ b/arch/arm/mach-owl/Kconfig
@@ -3,4 +3,25 @@ if ARCH_OWL
config SYS_SOC
default "owl"
+choice
+prompt "Actions Semi OWL SoCs board select"
+optional
+
+config TARGET_BUBBLEGUM_96
+ bool "96Boards Bubblegum-96"
+ help
+ Support for 96Boards Bubblegum-96. This board complies with
+ 96Board Consumer Edition Specification. Features:
+ - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
+ - 2GiB RAM
+ - 8GiB eMMC, uSD slot
+ - WiFi, Bluetooth and GPS module
+ - 2x Host, 1x Device USB port
+ - HDMI
+ - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
+
+endchoice
+
+source "board/ucRobotics/bubblegum_96/Kconfig"
+
endif
diff --git a/board/ucRobotics/bubblegum_96/Kconfig
b/board/ucRobotics/bubblegum_96/Kconfig
new file mode 100644
index 00..2dd40d9b6a
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_BUBBLEGUM_96
+
+config SYS_BOARD
+ default "bubblegum_96"
+
+config SYS_VENDOR
+ default "ucRobotics"
+
+config SYS_SOC
+ default "s900"
+
+config SYS_CONFIG_NAME
+ default "bubblegum_96"
+
+endif
diff --git a/board/ucRobotics/bubblegum_96/MAINTAINERS
b/board/ucRobotics/bubblegum_96/MAINTAINERS
new file mode 100644
index 00..d0cb7278c6
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/MAINTAINERS
@@ -0,0 +1,6 @@
+BUBBLEGUM_96 BOARD
+M: Manivannan Sadhasivam
+S: Maintained
+F: board/ucRobotics/bubblegum_96/
+F: include/configs/bubblegum_96.h
+F: configs/bubblegum_96_defconfig
diff --git a/board/ucRobotics/bubblegum_96/Makefile
b/board/ucRobotics/bubblegum_96/Makefile
new file mode 100644
index 00..c4b524def2
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y := bubblegum_96.o
diff --git a/board/ucRobotics/bubblegum_96/bubblegum_96.c
b/board/ucRobotics/bubblegum_96/bubblegum_96.c
new file mode 100644
index 00..a4c202da19
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/bubblegum_96.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bubblegum-96 Boards Support
+ *
+ *
[U-Boot] [PATCH v2 1/9] arm: Add support for Actions Semi OWL SoC family
This commit adds Actions Semi OWL SoC family support with S900 as the
first target SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/Kconfig| 9 +
arch/arm/Makefile | 1 +
arch/arm/dts/s900.dtsi | 23 +++
arch/arm/mach-owl/Kconfig | 6 ++
arch/arm/mach-owl/Makefile | 3 +++
arch/arm/mach-owl/sysmap-s900.c | 32
6 files changed, 74 insertions(+)
create mode 100644 arch/arm/dts/s900.dtsi
create mode 100644 arch/arm/mach-owl/Kconfig
create mode 100644 arch/arm/mach-owl/Makefile
create mode 100644 arch/arm/mach-owl/sysmap-s900.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422bc5d..ec0bb5a42b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -699,6 +699,13 @@ config ARCH_MX5
select BOARD_EARLY_INIT_F
imply MXC_GPIO
+config ARCH_OWL
+ bool "Actions Semi OWL SoCs"
+ select ARM64
+ select DM
+ select DM_SERIAL
+ select OF_CONTROL
+
config ARCH_QEMU
bool "QEMU Virtual Platform"
select DM
@@ -1335,6 +1342,8 @@ source "arch/arm/cpu/armv8/fsl-layerscape/Kconfig"
source "arch/arm/mach-orion5x/Kconfig"
+source "arch/arm/mach-owl/Kconfig"
+
source "arch/arm/mach-rmobile/Kconfig"
source "arch/arm/mach-meson/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 680c6e8516..f15b2287df 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -66,6 +66,7 @@ machine-$(CONFIG_ARCH_MVEBU) += mvebu
# TODO: rename CONFIG_ORION5X -> CONFIG_ARCH_ORION5X
machine-$(CONFIG_ORION5X) += orion5x
machine-$(CONFIG_ARCH_OMAP2PLUS) += omap2
+machine-$(CONFIG_ARCH_OWL) += owl
machine-$(CONFIG_ARCH_S5PC1XX) += s5pc1xx
machine-$(CONFIG_ARCH_SUNXI) += sunxi
machine-$(CONFIG_ARCH_SNAPDRAGON) += snapdragon
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
new file mode 100644
index 00..3bd14b82d4
--- /dev/null
+++ b/arch/arm/dts/s900.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Device Tree Source for Actions Semi S900 SoC
+//
+// Copyright (C) 2015 Actions Semi Co., Ltd.
+// Copyright (C) 2018 Manivannan Sadhasivam
+
+/dts-v1/;
+
+/ {
+ compatible = "actions,s900";
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+
+ soc {
+ u-boot,dm-pre-reloc;
+ compatible = "simple-bus";
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+ ranges;
+ };
+};
+
diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
new file mode 100644
index 00..f695c16d1e
--- /dev/null
+++ b/arch/arm/mach-owl/Kconfig
@@ -0,0 +1,6 @@
+if ARCH_OWL
+
+config SYS_SOC
+ default "owl"
+
+endif
diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
new file mode 100644
index 00..1b43dc2921
--- /dev/null
+++ b/arch/arm/mach-owl/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += sysmap-s900.o
diff --git a/arch/arm/mach-owl/sysmap-s900.c b/arch/arm/mach-owl/sysmap-s900.c
new file mode 100644
index 00..f78b639740
--- /dev/null
+++ b/arch/arm/mach-owl/sysmap-s900.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semi S900 Memory map
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ */
+
+#include
+#include
+
+static struct mm_region s900_mem_map[] = {
+ {
+ .virt = 0x0UL, /* DDR */
+ .phys = 0x0UL, /* DDR */
+ .size = 0x8000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0xE000UL, /* Peripheral block */
+ .phys = 0xE000UL, /* Peripheral block */
+ .size = 0x0800UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
+struct mm_region *mem_map = s900_mem_map;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/9] Add SoC and Board support for Bubblegum-96
This patchset adds SoC support for Actions Semi S900 SoC and ucRobotics Bubblegum-96 board along with UART and Clock drivers. S900 SoC consists of 4 ARM Cortex-A53 cores up to 1.8GHz with Imagination Power VR G6230 GPU. More information on this SoC can be found in Actions Semi product page: http://www.actions-semi.com/en/productview.aspx?id=204 Bubblegum-96 board is one of the 96Boards Consumer Edition platform based on S900 SoC. This board has 2GB LPDDR3 operating at 533 MHz and 8GB eMMC along with other peripherals required by 96Boards Consumer Edition Specification. More information on this board can be found in 96Boards product page. https://www.96boards.org/product/bubblegum-96/ Most of the code is based on Actions tree found here: https://github.com/96boards-bubblegum/u-boot/ With this patchset, Bubblegum-96 board can boot into U-Boot shell. Thanks, Mani Changes in v2: * Removed clk_owl.c and moved all clk code to clk_s900.c as per Simon's review comments. * Added missing Signed-off by tag for one patch. * Moved arch/arm/mach-owl/Kconfig changes from clk patch to board support patch. Manivannan Sadhasivam (9): arm: Add support for Actions Semi OWL SoC family board: Add uCRobotics Bubblegum-96 board support dt-bindings: clock: Add S900 CMU register definitions arm: dts: s900: Add Clock Management Unit (CMU) nodes clk: Add Actions Semi OWL clock support arm: dts: s900: Add UART node arm: dts: bubblegum_96: Enable UART5 for serial console serial: Add Actions Semi OWL UART support MAINTAINERS: Add entries for Actions Semi OWL family MAINTAINERS | 9 ++ arch/arm/Kconfig | 10 ++ arch/arm/Makefile| 1 + arch/arm/dts/bubblegum_96.dts| 31 + arch/arm/dts/s900.dtsi | 53 +++ arch/arm/include/asm/arch-owl/clk_s900.h | 57 arch/arm/include/asm/arch-owl/regs_s900.h| 64 + arch/arm/mach-owl/Kconfig| 27 arch/arm/mach-owl/Makefile | 3 + arch/arm/mach-owl/sysmap-s900.c | 32 + board/ucRobotics/bubblegum_96/Kconfig| 15 ++ board/ucRobotics/bubblegum_96/MAINTAINERS| 6 + board/ucRobotics/bubblegum_96/Makefile | 3 + board/ucRobotics/bubblegum_96/bubblegum_96.c | 56 configs/bubblegum_96_defconfig | 22 +++ drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/owl/Kconfig | 12 ++ drivers/clk/owl/Makefile | 3 + drivers/clk/owl/clk_s900.c | 138 +++ drivers/serial/Kconfig | 8 ++ drivers/serial/Makefile | 1 + drivers/serial/serial_owl.c | 136 ++ include/configs/bubblegum_96.h | 43 ++ include/dt-bindings/clock/s900_cmu.h | 77 +++ 25 files changed, 809 insertions(+) create mode 100644 arch/arm/dts/bubblegum_96.dts create mode 100644 arch/arm/dts/s900.dtsi create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h create mode 100644 arch/arm/mach-owl/Kconfig create mode 100644 arch/arm/mach-owl/Makefile create mode 100644 arch/arm/mach-owl/sysmap-s900.c create mode 100644 board/ucRobotics/bubblegum_96/Kconfig create mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS create mode 100644 board/ucRobotics/bubblegum_96/Makefile create mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c create mode 100644 configs/bubblegum_96_defconfig create mode 100644 drivers/clk/owl/Kconfig create mode 100644 drivers/clk/owl/Makefile create mode 100644 drivers/clk/owl/clk_s900.c create mode 100644 drivers/serial/serial_owl.c create mode 100644 include/configs/bubblegum_96.h create mode 100644 include/dt-bindings/clock/s900_cmu.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V4 1/2] ARM: image: Add option for ignoring ep bit 3
Add option to the booti_setup() which indicates to it that the caller
requires the image to be relocated to the beginning of the RAM and
that the information whether the image can be located anywhere in RAM
at 2 MiB aligned boundary or not is to be ignored. This is useful ie.
in case the Image is wrapped in another envelope, ie. fitImage and not
relocating it but moving it would corrupt the envelope.
Signed-off-by: Marek Vasut
Cc: Bin Chen
Cc: Masahiro Yamada
Cc: Tom Rini
---
V2: Rename ignore_ep to force_reloc
V3: No change
V4: - Add stdbool.h include
- Switch force_reloc to bool
---
arch/arm/lib/image.c | 5 +++--
cmd/booti.c | 2 +-
include/image.h | 5 -
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/lib/image.c b/arch/arm/lib/image.c
index 1a04e2b875..699bf44e70 100644
--- a/arch/arm/lib/image.c
+++ b/arch/arm/lib/image.c
@@ -26,7 +26,8 @@ struct Image_header {
uint32_tres5;
};
-int booti_setup(ulong image, ulong *relocated_addr, ulong *size)
+int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
+ bool force_reloc)
{
struct Image_header *ih;
uint64_t dst;
@@ -63,7 +64,7 @@ int booti_setup(ulong image, ulong *relocated_addr, ulong
*size)
* images->ep. Otherwise, relocate the image to the base of RAM
* since memory below it is not accessible via the linear mapping.
*/
- if (le64_to_cpu(ih->flags) & BIT(3))
+ if (!force_reloc && (le64_to_cpu(ih->flags) & BIT(3)))
dst = image - text_offset;
else
dst = gd->bd->bi_dram[0].start;
diff --git a/cmd/booti.c b/cmd/booti.c
index 45fbb99b68..04353b68ec 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -37,7 +37,7 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
debug("* kernel: cmdline image address = 0x%08lx\n", ld);
}
- ret = booti_setup(ld, _addr, _size);
+ ret = booti_setup(ld, _addr, _size, false);
if (ret != 0)
return 1;
diff --git a/include/image.h b/include/image.h
index 95d5934344..420b8ff576 100644
--- a/include/image.h
+++ b/include/image.h
@@ -17,6 +17,7 @@
#include "compiler.h"
#include
+#include
/* Define this to avoid #ifdefs later on */
struct lmb;
@@ -881,9 +882,11 @@ int bootz_setup(ulong image, ulong *start, ulong *end);
* @image: Address of image
* @start: Returns start address of image
* @size : Returns size image
+ * @force_reloc: Ignore image->ep field, always place image to RAM start
* @return 0 if OK, 1 if the image was not recognised
*/
-int booti_setup(ulong image, ulong *relocated_addr, ulong *size);
+int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
+ bool force_reloc);
/***/
/* New uImage format specific code (prefixed with fit_) */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V4 2/2] bootm: Handle kernel_noload on arm64
The ARM64 has 2 MiB alignment requirement for the kernel. When using
fitImage, this requirement may by violated, the kernel will thus be
executed from unaligned address and fail to boot. Do what booti does
and run booti_setup() for kernel_noload images on arm64 to obtain a
suitable aligned address to which the image shall be relocated.
Signed-off-by: Marek Vasut
Cc: Bin Chen
Cc: Masahiro Yamada
Cc: Tom Rini
---
V2: Protect the ARM64 booti bit with if IS_ENABLED(CMD_BOOTI)
V3: Use if() instead of #ifdef
V4: Switch force_reloc to bool
---
common/bootm.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index e789f6818a..e517d9f118 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -202,8 +202,23 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag, int
argc,
}
if (images.os.type == IH_TYPE_KERNEL_NOLOAD) {
- images.os.load = images.os.image_start;
- images.ep += images.os.load;
+ if (CONFIG_IS_ENABLED(CMD_BOOTI) &&
+ images.os.arch == IH_ARCH_ARM64) {
+ ulong image_addr;
+ ulong image_size;
+
+ ret = booti_setup(images.os.image_start, _addr,
+ _size, true);
+ if (ret != 0)
+ return 1;
+
+ images.os.type = IH_TYPE_KERNEL;
+ images.os.load = image_addr;
+ images.ep = image_addr;
+ } else {
+ images.os.load = images.os.image_start;
+ images.ep += images.os.image_start;
+ }
}
images.os.start = map_to_sysmem(os_hdr);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-sh/master
The following changes since commit 813d1fb56dc0af9567feb86cd71c49f14662044b: Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08 10:08:20 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to 0a52b00627c4fb6b100745c97910b75c99f3f4a9: ARM: rmobile: Fix environment placement on Draak (2018-06-10 16:34:43 +0200) Marek Vasut (8): pinctrl: renesas: Sync Gen2 PFC tables with Linux v4.17 pinctrl: renesas: Sync Gen3 PFC tables with Linux v4.17 ARM: rmobile: Sync Gen2 DTS with Linux v4.17 ARM: rmobile: Sync Gen3 DTS with Linux v4.17 ARM: rmobile: Zap CONFIG_SYS_CLK_FREQ where applicable ARM: rmobile: Point load address to more sane area on Gen2 ARM: rmobile: Point load address to more sane area on Gen3 ARM: rmobile: Fix environment placement on Draak arch/arm/dts/r8a7790-lager.dts | 310 +- arch/arm/dts/r8a7790.dtsi | 2877 +++--- arch/arm/dts/r8a7791-koelsch.dts | 259 ++- arch/arm/dts/r8a7791-porter.dts| 151 --- arch/arm/dts/r8a7791.dtsi | 3008 ++-- arch/arm/dts/r8a7792.dtsi | 587 + arch/arm/dts/r8a7793-gose.dts | 262 +++- arch/arm/dts/r8a7793.dtsi | 2409 +-- arch/arm/dts/r8a7794-alt.dts | 56 ++- arch/arm/dts/r8a7794-silk.dts | 189 ++--- arch/arm/dts/r8a7794.dtsi | 2416 +-- arch/arm/dts/r8a7795.dtsi | 602 +- arch/arm/dts/r8a7796.dtsi | 556 ++-- arch/arm/dts/r8a77965.dtsi | 127 +- arch/arm/dts/r8a77970-eagle.dts| 66 +-- arch/arm/dts/r8a77970.dtsi | 328 -- arch/arm/dts/r8a77995-draak.dts| 124 ++ arch/arm/dts/r8a77995.dtsi | 423 +- arch/arm/dts/salvator-common.dtsi | 85 +++- arch/arm/dts/ulcb.dtsi | 22 +- drivers/pinctrl/renesas/pfc-r8a7790.c |8 +- drivers/pinctrl/renesas/pfc-r8a7791.c | 84 +++- drivers/pinctrl/renesas/pfc-r8a7794.c | 473 + drivers/pinctrl/renesas/pfc-r8a7795.c | 1968 ++-- drivers/pinctrl/renesas/pfc-r8a7796.c | 1048 +++-- drivers/pinctrl/renesas/pfc-r8a77970.c | 873 - drivers/pinctrl/renesas/pfc-r8a77990.c | 3446 ++- drivers/pinctrl/renesas/pfc-r8a77995.c | 695 +- drivers/pinctrl/renesas/sh_pfc.h |5 +- include/configs/draak.h|6 +- include/configs/ebisu.h|4 - include/configs/rcar-gen2-common.h |3 +- include/configs/rcar-gen3-common.h |3 +- include/configs/salvator-x.h |4 - include/configs/ulcb.h |4 - 35 files changed, 16030 insertions(+), 7451 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] rockchip: Reduce prerequisites from the host
Hi Vicente, Could you share why you don't want to use python, can convert the script to C? Thanks, - Kever On 06/02/2018 12:46 AM, Vicente Bergas wrote: > From: Vicente Bergas > > This patch series remove the dependency on python and dtc from the host > for the Sapphire board. > > It does not conform to the U-Boot coding style. It has been posted here for > informational purposes only. If there is interest in merging it, feel free > to modify it at will, it is in the public domain. > > Vicente Bergas (4): > [U-Boot] add make_fit_atf in tools > [U-Boot] rockchip: rk3399: use make_fit_atf instead of make_fit_atf.py > [U-Boot] rockchip: rk3399: disable CONFIG_SPL_OF_PLATDATA > [U-Boot] rockchip: rk3399: set CONFIG_MKIMAGE_DTC_PATH > > configs/evb-rk3399_defconfig | 4 +- > tools/Makefile | 2 + > tools/make_fit_atf.c | 360 +++ > 3 files changed, 364 insertions(+), 2 deletions(-) > create mode 100644 tools/make_fit_atf.c > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] rockchip: rk3399: set CONFIG_MKIMAGE_DTC_PATH
Hi Vicente, On 06/02/2018 12:46 AM, Vicente Bergas wrote: > From: Vicente Bergas > > U-Boot has a built-in dtc. Using it removes one dependency from the host. > > Signed-off-by: Vicente Bergas Looks good to me, thanks. Reviewed-by: Kever Yang Thanks, - Kever > --- > configs/evb-rk3399_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig > index 3f87722866..d1540ad6d1 100644 > --- a/configs/evb-rk3399_defconfig > +++ b/configs/evb-rk3399_defconfig > @@ -27,6 +27,7 @@ CONFIG_CMD_USB=y > CONFIG_CMD_TIME=y > CONFIG_SPL_OF_CONTROL=y > CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names > interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" > +CONFIG_MKIMAGE_DTC_PATH="scripts/dtc/dtc" > CONFIG_ENV_IS_IN_MMC=y > CONFIG_NET_RANDOM_ETHADDR=y > CONFIG_REGMAP=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] rockchip: rk3399: disable CONFIG_SPL_OF_PLATDATA
Hi Vicente, On 06/02/2018 12:46 AM, Vicente Bergas wrote: > From: Vicente Bergas > > It has been tested with this option disabled and it works fine. > The benefit of doing so is that this is the last dependency on python to > build U-Boot for the Sapphire board. I just not understand why remove the dependency on python is so important, there already many modules depend on python. The most important is I would like to enable "CONFIG_SPL_OF_PLATDATA" instead of remove it. Yes, it works fine without it, but I believe it works better/faster with it. Thanks, - Kever > > Signed-off-by: Vicente Bergas > --- > configs/evb-rk3399_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig > index 69a4cc2239..3f87722866 100644 > --- a/configs/evb-rk3399_defconfig > +++ b/configs/evb-rk3399_defconfig > @@ -27,7 +27,6 @@ CONFIG_CMD_USB=y > CONFIG_CMD_TIME=y > CONFIG_SPL_OF_CONTROL=y > CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names > interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" > -CONFIG_SPL_OF_PLATDATA=y > CONFIG_ENV_IS_IN_MMC=y > CONFIG_NET_RANDOM_ETHADDR=y > CONFIG_REGMAP=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 1/2] rockchip: make_fit_atf: use elf entry point
On Wed, Jun 13, 2018 at 4:45 AM, Kever Yang wrote:
> Hi Yousaf,
>
> You patch looks good, but I don't know why the script always work
> for me,
>
> and I don't met the abort, where do you get the BL31?
It looks similar to what I was seeing previously and haven't had a
chance to get to the bottom of.
Peter
> Thanks,
> - Kever
> On 06/08/2018 04:47 PM, Mian Yousaf Kaukab wrote:
>> make_fit_atf.py uses physical address of first segment as the
>> entry point to bl31. It is incorrect and causes following abort
>> when bl31_entry() is called:
>>
>> U-Boot SPL board initTrying to boot from MMC1
>> "Synchronous Abort" handler, esr 0x0200
>> elr: lr : ff8c7e8c
>> x 0: ff8e x 1:
>> x 2: x 3: ff8e0180
>> x 4: x 5:
>> x 6: 0030 x 7: ff8e0188
>> x 8: 01e0 x 9:
>> x10: 0007fcdc x11: 002881b8
>> x12: 01a2 x13: 0198
>> x14: 0007fdcc x15: 002881b8
>> x16: 003c0724 x17: 003c0718
>> x18: 0007fe80 x19: ff8e
>> x20: 0020 x21: ff8e
>> x22: x23: 0007fe30
>> x24: ff8d1c3c x25: ff8d5000
>> x26: deadbeef x27: 04a0
>> x28: 009c x29: 0007fd90
>>
>> Fix it by using the entry point from the elf header.
>>
>> Signed-off-by: Mian Yousaf Kaukab
>> ---
>> arch/arm/mach-rockchip/make_fit_atf.py | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-rockchip/make_fit_atf.py
>> b/arch/arm/mach-rockchip/make_fit_atf.py
>> index 6b3d9201c9..b88a5e1f16 100755
>> --- a/arch/arm/mach-rockchip/make_fit_atf.py
>> +++ b/arch/arm/mach-rockchip/make_fit_atf.py
>> @@ -53,7 +53,7 @@ DT_END="""
>> };
>> """
>>
>> -def append_atf_node(file, atf_index, phy_addr):
>> +def append_atf_node(file, atf_index, phy_addr, elf_entry):
>> """
>> Append ATF DT node to input FIT dts file.
>> """
>> @@ -67,7 +67,7 @@ def append_atf_node(file, atf_index, phy_addr):
>> print >> file, '\t\t\tcompression = "none";'
>> print >> file, '\t\t\tload = <0x%08x>;' % phy_addr
>> if atf_index == 1:
>> -print >> file, '\t\t\tentry = <0x%08x>;' % phy_addr
>> +print >> file, '\t\t\tentry = <0x%08x>;' % elf_entry
>> print >> file, '\t\t};'
>> print >> file, ''
>>
>> @@ -141,12 +141,13 @@ def generate_atf_fit_dts(fit_file_name,
>> bl31_file_name, uboot_file_name, dtbs_fi
>>
>> with open(bl31_file_name) as bl31_file:
>> bl31 = ELFFile(bl31_file)
>> +elf_entry = bl31.header['e_entry']
>> for i in range(bl31.num_segments()):
>> seg = bl31.get_segment(i)
>> if ('PT_LOAD' == seg.__getitem__(ELF_SEG_P_TYPE)):
>> paddr = seg.__getitem__(ELF_SEG_P_PADDR)
>> p= seg.__getitem__(ELF_SEG_P_PADDR)
>> -append_atf_node(fit_file, i+1, paddr)
>> +append_atf_node(fit_file, i+1, paddr, elf_entry)
>> atf_cnt = i+1
>> append_fdt_node(fit_file, dtbs_file_name)
>> print >> fit_file, '%s' % DT_IMAGES_NODE_END
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 1/2] rockchip: make_fit_atf: use elf entry point
Hi Yousaf,
Could you have a look at this patch:
https://patchwork.ozlabs.org/patch/924244/
Thanks,
- Kever
On 06/08/2018 04:47 PM, Mian Yousaf Kaukab wrote:
> make_fit_atf.py uses physical address of first segment as the
> entry point to bl31. It is incorrect and causes following abort
> when bl31_entry() is called:
>
> U-Boot SPL board initTrying to boot from MMC1
> "Synchronous Abort" handler, esr 0x0200
> elr: lr : ff8c7e8c
> x 0: ff8e x 1:
> x 2: x 3: ff8e0180
> x 4: x 5:
> x 6: 0030 x 7: ff8e0188
> x 8: 01e0 x 9:
> x10: 0007fcdc x11: 002881b8
> x12: 01a2 x13: 0198
> x14: 0007fdcc x15: 002881b8
> x16: 003c0724 x17: 003c0718
> x18: 0007fe80 x19: ff8e
> x20: 0020 x21: ff8e
> x22: x23: 0007fe30
> x24: ff8d1c3c x25: ff8d5000
> x26: deadbeef x27: 04a0
> x28: 009c x29: 0007fd90
>
> Fix it by using the entry point from the elf header.
>
> Signed-off-by: Mian Yousaf Kaukab
> ---
> arch/arm/mach-rockchip/make_fit_atf.py | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/make_fit_atf.py
> b/arch/arm/mach-rockchip/make_fit_atf.py
> index 6b3d9201c9..b88a5e1f16 100755
> --- a/arch/arm/mach-rockchip/make_fit_atf.py
> +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> @@ -53,7 +53,7 @@ DT_END="""
> };
> """
>
> -def append_atf_node(file, atf_index, phy_addr):
> +def append_atf_node(file, atf_index, phy_addr, elf_entry):
> """
> Append ATF DT node to input FIT dts file.
> """
> @@ -67,7 +67,7 @@ def append_atf_node(file, atf_index, phy_addr):
> print >> file, '\t\t\tcompression = "none";'
> print >> file, '\t\t\tload = <0x%08x>;' % phy_addr
> if atf_index == 1:
> -print >> file, '\t\t\tentry = <0x%08x>;' % phy_addr
> +print >> file, '\t\t\tentry = <0x%08x>;' % elf_entry
> print >> file, '\t\t};'
> print >> file, ''
>
> @@ -141,12 +141,13 @@ def generate_atf_fit_dts(fit_file_name, bl31_file_name,
> uboot_file_name, dtbs_fi
>
> with open(bl31_file_name) as bl31_file:
> bl31 = ELFFile(bl31_file)
> +elf_entry = bl31.header['e_entry']
> for i in range(bl31.num_segments()):
> seg = bl31.get_segment(i)
> if ('PT_LOAD' == seg.__getitem__(ELF_SEG_P_TYPE)):
> paddr = seg.__getitem__(ELF_SEG_P_PADDR)
> p= seg.__getitem__(ELF_SEG_P_PADDR)
> -append_atf_node(fit_file, i+1, paddr)
> +append_atf_node(fit_file, i+1, paddr, elf_entry)
> atf_cnt = i+1
> append_fdt_node(fit_file, dtbs_file_name)
> print >> fit_file, '%s' % DT_IMAGES_NODE_END
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] rockchip: evb-rk3399: correct README for board bring up
On 06/03/2018 10:50 PM, Heinrich Schuchardt wrote: > %s/rkflashtool/rkdeveloptool/ > > We are using rkdeveloptool not rkflashtool. > > Signed-off-by: Heinrich Schuchardt Looks good to me, thanks. Reviewed-by: Kever Yang Thanks, - Kever > --- > board/rockchip/evb_rk3399/README | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/board/rockchip/evb_rk3399/README > b/board/rockchip/evb_rk3399/README > index ada8ca7f3c1..83214670462 100644 > --- a/board/rockchip/evb_rk3399/README > +++ b/board/rockchip/evb_rk3399/README > @@ -65,7 +65,7 @@ Compile the U-Boot > Compile the rkdeveloptool > === >Follow instructions in latest README > - > cd ../rkflashtool > + > cd ../rkdeveloptool >> autoreconf -i >> ./configure >> make ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 1/2] rockchip: make_fit_atf: use elf entry point
Hi Yousaf,
You patch looks good, but I don't know why the script always work
for me,
and I don't met the abort, where do you get the BL31?
Thanks,
- Kever
On 06/08/2018 04:47 PM, Mian Yousaf Kaukab wrote:
> make_fit_atf.py uses physical address of first segment as the
> entry point to bl31. It is incorrect and causes following abort
> when bl31_entry() is called:
>
> U-Boot SPL board initTrying to boot from MMC1
> "Synchronous Abort" handler, esr 0x0200
> elr: lr : ff8c7e8c
> x 0: ff8e x 1:
> x 2: x 3: ff8e0180
> x 4: x 5:
> x 6: 0030 x 7: ff8e0188
> x 8: 01e0 x 9:
> x10: 0007fcdc x11: 002881b8
> x12: 01a2 x13: 0198
> x14: 0007fdcc x15: 002881b8
> x16: 003c0724 x17: 003c0718
> x18: 0007fe80 x19: ff8e
> x20: 0020 x21: ff8e
> x22: x23: 0007fe30
> x24: ff8d1c3c x25: ff8d5000
> x26: deadbeef x27: 04a0
> x28: 009c x29: 0007fd90
>
> Fix it by using the entry point from the elf header.
>
> Signed-off-by: Mian Yousaf Kaukab
> ---
> arch/arm/mach-rockchip/make_fit_atf.py | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/make_fit_atf.py
> b/arch/arm/mach-rockchip/make_fit_atf.py
> index 6b3d9201c9..b88a5e1f16 100755
> --- a/arch/arm/mach-rockchip/make_fit_atf.py
> +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> @@ -53,7 +53,7 @@ DT_END="""
> };
> """
>
> -def append_atf_node(file, atf_index, phy_addr):
> +def append_atf_node(file, atf_index, phy_addr, elf_entry):
> """
> Append ATF DT node to input FIT dts file.
> """
> @@ -67,7 +67,7 @@ def append_atf_node(file, atf_index, phy_addr):
> print >> file, '\t\t\tcompression = "none";'
> print >> file, '\t\t\tload = <0x%08x>;' % phy_addr
> if atf_index == 1:
> -print >> file, '\t\t\tentry = <0x%08x>;' % phy_addr
> +print >> file, '\t\t\tentry = <0x%08x>;' % elf_entry
> print >> file, '\t\t};'
> print >> file, ''
>
> @@ -141,12 +141,13 @@ def generate_atf_fit_dts(fit_file_name, bl31_file_name,
> uboot_file_name, dtbs_fi
>
> with open(bl31_file_name) as bl31_file:
> bl31 = ELFFile(bl31_file)
> +elf_entry = bl31.header['e_entry']
> for i in range(bl31.num_segments()):
> seg = bl31.get_segment(i)
> if ('PT_LOAD' == seg.__getitem__(ELF_SEG_P_TYPE)):
> paddr = seg.__getitem__(ELF_SEG_P_PADDR)
> p= seg.__getitem__(ELF_SEG_P_PADDR)
> -append_atf_node(fit_file, i+1, paddr)
> +append_atf_node(fit_file, i+1, paddr, elf_entry)
> atf_cnt = i+1
> append_fdt_node(fit_file, dtbs_file_name)
> print >> fit_file, '%s' % DT_IMAGES_NODE_END
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND][PATCH 5/9] clk: Add Actions Semi OWL clock support
Hi Simon,
On Tue, Jun 12, 2018 at 07:29:15PM -0600, Simon Glass wrote:
> Hi Mani,
>
> On 12 June 2018 at 00:14, Manivannan Sadhasivam
> wrote:
> > Hi Simon,
> >
> > On Mon, Jun 11, 2018 at 01:38:42PM -0600, Simon Glass wrote:
> >> Hi,
> >>
> >> On 11 June 2018 at 09:48, Manivannan Sadhasivam
> >> wrote:
> >> > This commit adds Actions Semi OWL family base clock and S900 SoC specific
> >> > clock support. For S900 peripheral clock support, only UART clock has
> >> > been
> >> > added for now.
> >> >
> >> > Signed-off-by: Manivannan Sadhasivam
> >> > ---
> >> > arch/arm/include/asm/arch-owl/clk_owl.h | 61 +
> >> > arch/arm/include/asm/arch-owl/regs_s900.h | 64 +
> >> > arch/arm/mach-owl/Kconfig | 2 +-
> >> > drivers/clk/Kconfig | 1 +
> >> > drivers/clk/Makefile | 1 +
> >> > drivers/clk/owl/Kconfig | 12 +++
> >> > drivers/clk/owl/Makefile | 4 +
> >> > drivers/clk/owl/clk_owl.c | 60 +
> >> > drivers/clk/owl/clk_s900.c| 104 ++
> >> > 9 files changed, 308 insertions(+), 1 deletion(-)
> >> > create mode 100644 arch/arm/include/asm/arch-owl/clk_owl.h
> >> > create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
> >> > create mode 100644 drivers/clk/owl/Kconfig
> >> > create mode 100644 drivers/clk/owl/Makefile
> >> > create mode 100644 drivers/clk/owl/clk_owl.c
> >> > create mode 100644 drivers/clk/owl/clk_s900.c
> >>
> >> This doesn't look quite right to me. It looks like you should put all
> >> the code in clk_s900.c and delete clk_owl.c.
> >>
> >
> > The intention is to separate generic OWL family and SoC specific part. I
> > know that there isn't much in the OWL part now but since this is just a
> > basic clk support and I will extend this in upcoming days with further
> > peripherals, this makes sense to me.
> >
> > Also, there are plans to support other OWL family SoCs like S500 and
> > S700. So, in those cases this partition will avoid much code duplication.
> > Moreover, the pattern followed here matches the Linux kernel common
> > clock framework by some means.
>
> I still don't understand this. From the look of it, clk_owl.c has
> almost nothing in it and all the logic is in the driver.
>
Agree!
> It looks like you definitely don't want to have common driver that
> will support multiple compatible strings? Is that right?
>
> But then you have this line in the 'generic' code:
>
> + { .compatible = "actions,s900-cmu" },
>
> Of course it is hard to see where you are going with a start like
> this, but I imagine that the next driver you do would have a similar
> structure to the current one.
>
> So my question is, why not just have the U_BOOT_DRIVER() and other
> 'common' stuff in each driver? I cannot see what you are gaining. You
> are losing discoverability since it will be hard for people to find
> the driver for their actual chip (the compatible string is in one
> file but all the code is in another).
>
Makes sense...
Since I don't have common code to share with other family SoC's for now,
I agree with you on removing clk_owl.c and moving everything to
clk_s900.c. In future we may decide on partitioning the code if there is
enough code duplication.
Will send a v2 incorporating your suggestion.
Thanks for the review!
Regards,
Mani
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 02/13] efi: Init the 'rows' and 'cols' variables
Hi,
On 11 June 2018 at 23:41, Heinrich Schuchardt wrote:
> On 06/12/2018 07:26 AM, Simon Glass wrote:
>> The current code causes a compiler error on gcc 4.8.4 as used by sandbox
>> on Ubuntu 14.04, which is fairly recent. Init these variables to fix the
>> problem.
>>
>> Signed-off-by: Simon Glass
>
> Is this needed after Alex's
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=80483b2ab62ca7cd200db445b6920ee96d17df88
> ?
I missed that one.
I actually think his is the better fix, since we really shouldn't be
setting return values in case of error.
Regards,
Simon
>
> Best regards
>
> Heinrich
>
>> ---
>>
>> Changes in v5: None
>> Changes in v4:
>> - Move the fix to query_console_serial()
>>
>> Changes in v3:
>> - Add new patch to init the 'rows' and 'cols' variables
>>
>> Changes in v2: None
>>
>> lib/efi_loader/efi_console.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>> index ce66c935ec..bd953a1485 100644
>> --- a/lib/efi_loader/efi_console.c
>> +++ b/lib/efi_loader/efi_console.c
>> @@ -204,8 +204,11 @@ static int query_console_serial(int *rows, int *cols)
>> return -1;
>>
>> /* Read {depth,rows,cols} */
>> - if (term_read_reply(n, 3, 't'))
>> + if (term_read_reply(n, 3, 't')) {
>> + *rows = -1;
>> + *cols = -1;
>> return -1;
>> + }
>>
>> *cols = n[2];
>> *rows = n[1];
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] x86: cherryhill: Fix DTC warning
Fix warning when compiling cherryhill.dts with latest DTC:
"Warning (avoid_unnecessary_addr_size): /pci/pch@1f,0: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property"
Signed-off-by: Bin Meng
---
arch/x86/dts/cherryhill.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/dts/cherryhill.dts b/arch/x86/dts/cherryhill.dts
index c3a6aad..3e29683 100644
--- a/arch/x86/dts/cherryhill.dts
+++ b/arch/x86/dts/cherryhill.dts
@@ -75,8 +75,6 @@
pch@1f,0 {
reg = <0xf800 0 0 0 0>;
compatible = "intel,pch9";
- #address-cells = <1>;
- #size-cells = <1>;
irq-router {
compatible = "intel,irq-router";
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 10/13] efi: sandbox: Add a simple 'bootefi test' command
This jumps to test code which can call directly into the EFI support. It
does not need a separate image so it is easy to write tests with it.
This test can be executed without causing problems to the run-time
environemnt (e.g. U-Boot does not need to reboot afterwards).
For now the test just outputs a message. To try it:
./sandbox/u-boot -c "bootefi test"
U-Boot 2017.09-00204-g696c9855fe (Sep 17 2017 - 16:43:53 -0600)
DRAM: 128 MiB
MMC:
Using default environment
In:serial
Out: serial
Err: serial
SCSI: Net: No ethernet found.
IDE: Bus 0: not available
Found 0 disks
WARNING: booting without device tree
Hello, world!
Test passed
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5: None
Changes in v4:
- Rebase to master
- Update SPDX tags
Changes in v3:
- Rebase to master
Changes in v2:
- Rebase to master
cmd/bootefi.c | 26 --
include/efi_loader.h | 3 +++
lib/efi_loader/Kconfig| 10 ++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_test.c | 16
5 files changed, 50 insertions(+), 6 deletions(-)
create mode 100644 lib/efi_loader/efi_test.c
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index a9ebde0c75..ac80074bc4 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -347,7 +347,6 @@ exit:
return ret;
}
-#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
/**
* bootefi_test_prepare() - prepare to run an EFI test
*
@@ -399,7 +398,6 @@ static void bootefi_test_finish(struct efi_loaded_image
*image,
free(image->load_options);
list_del(>link);
}
-#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
static int do_bootefi_bootmgr_exec(void)
{
@@ -431,8 +429,10 @@ static int do_bootefi_bootmgr_exec(void)
/* Interpreter command to boot an arbitrary EFI image from memory */
static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
- unsigned long addr;
+ struct efi_loaded_image image;
+ struct efi_object obj;
char *saddr;
+ unsigned long addr;
efi_status_t r;
void *fdt_addr;
@@ -477,11 +477,25 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
memcpy((char *)addr, __efi_helloworld_begin, size);
} else
#endif
+ if (IS_ENABLED(CONFIG_BOOTEFI_TEST) && !strcmp(argv[1], "test")) {
+ int ret;
+
+ if (bootefi_test_prepare(, , "\\test",
+(ulong)_test))
+ return CMD_RET_FAILURE;
+
+ ret = efi_test(, );
+ bootefi_test_finish(, );
+ if (ret) {
+ printf("Test failed: err=%d\n", ret);
+ return CMD_RET_FAILURE;
+ }
+ printf("Test passed\n");
+
+ return 0;
+ }
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
- struct efi_loaded_image image;
- struct efi_object obj;
-
if (bootefi_test_prepare(, , "\\selftest",
(uintptr_t)_selftest))
return CMD_RET_FAILURE;
diff --git a/include/efi_loader.h b/include/efi_loader.h
index c66252a7dd..0615cfac85 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -442,6 +442,9 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
efi_guid_t *vendor,
void *efi_bootmgr_load(struct efi_device_path **device_path,
struct efi_device_path **file_path);
+/* Perform EFI tests */
+int efi_test(efi_handle_t image_handle, struct efi_system_table *systab);
+
#else /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */
/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index d471e6f4a4..110dcb23c9 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -25,3 +25,13 @@ config EFI_LOADER_BOUNCE_BUFFER
Some hardware does not support DMA to full 64bit addresses. For this
hardware we can create a bounce buffer so that payloads don't have to
worry about platform details.
+
+config BOOTEFI_TEST
+ bool "Provide a test for the EFI loader"
+ depends on EFI_LOADER && SANDBOX
+ default y
+ help
+ Provides a test of the EFI loader functionality accessed via the
+ command line ('bootefi test'). This runs within U-Boot so does not
+ need a separate EFI application to work. It aims to include coverage
+ of all EFI code which can be accessed within sandbox.
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index c6046e36d2..2da28f9c90 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_DM_VIDEO) += efi_gop.o
obj-$(CONFIG_PARTITIONS) += efi_disk.o
obj-$(CONFIG_NET) += efi_net.o
obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
[U-Boot] [PATCH v6 04/13] sandbox: smbios: Update to support sandbox
At present this code casts addresses to pointers so cannot be used with
sandbox. Update it to use mapmem instead.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Drop incorrect map_sysmem() in write_smbios_table()
Changes in v2: None
lib/smbios.c | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/lib/smbios.c b/lib/smbios.c
index df3d26b071..fc3dabcbc1 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -72,9 +73,10 @@ static int smbios_string_table_len(char *start)
static int smbios_write_type0(ulong *current, int handle)
{
- struct smbios_type0 *t = (struct smbios_type0 *)*current;
+ struct smbios_type0 *t;
int len = sizeof(struct smbios_type0);
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type0));
fill_smbios_header(t, SMBIOS_BIOS_INFORMATION, len, handle);
t->vendor = smbios_add_string(t->eos, "U-Boot");
@@ -101,16 +103,18 @@ static int smbios_write_type0(ulong *current, int handle)
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+ unmap_sysmem(t);
return len;
}
static int smbios_write_type1(ulong *current, int handle)
{
- struct smbios_type1 *t = (struct smbios_type1 *)*current;
+ struct smbios_type1 *t;
int len = sizeof(struct smbios_type1);
char *serial_str = env_get("serial#");
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type1));
fill_smbios_header(t, SMBIOS_SYSTEM_INFORMATION, len, handle);
t->manufacturer = smbios_add_string(t->eos, CONFIG_SMBIOS_MANUFACTURER);
@@ -122,15 +126,17 @@ static int smbios_write_type1(ulong *current, int handle)
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+ unmap_sysmem(t);
return len;
}
static int smbios_write_type2(ulong *current, int handle)
{
- struct smbios_type2 *t = (struct smbios_type2 *)*current;
+ struct smbios_type2 *t;
int len = sizeof(struct smbios_type2);
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type2));
fill_smbios_header(t, SMBIOS_BOARD_INFORMATION, len, handle);
t->manufacturer = smbios_add_string(t->eos, CONFIG_SMBIOS_MANUFACTURER);
@@ -140,15 +146,17 @@ static int smbios_write_type2(ulong *current, int handle)
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+ unmap_sysmem(t);
return len;
}
static int smbios_write_type3(ulong *current, int handle)
{
- struct smbios_type3 *t = (struct smbios_type3 *)*current;
+ struct smbios_type3 *t;
int len = sizeof(struct smbios_type3);
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type3));
fill_smbios_header(t, SMBIOS_SYSTEM_ENCLOSURE, len, handle);
t->manufacturer = smbios_add_string(t->eos, CONFIG_SMBIOS_MANUFACTURER);
@@ -160,6 +168,7 @@ static int smbios_write_type3(ulong *current, int handle)
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+ unmap_sysmem(t);
return len;
}
@@ -198,9 +207,10 @@ static void smbios_write_type4_dm(struct smbios_type4 *t)
static int smbios_write_type4(ulong *current, int handle)
{
- struct smbios_type4 *t = (struct smbios_type4 *)*current;
+ struct smbios_type4 *t;
int len = sizeof(struct smbios_type4);
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type4));
fill_smbios_header(t, SMBIOS_PROCESSOR_INFORMATION, len, handle);
t->processor_type = SMBIOS_PROCESSOR_TYPE_CENTRAL;
@@ -214,32 +224,37 @@ static int smbios_write_type4(ulong *current, int handle)
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+ unmap_sysmem(t);
return len;
}
static int smbios_write_type32(ulong *current, int handle)
{
- struct smbios_type32 *t = (struct smbios_type32 *)*current;
+ struct smbios_type32 *t;
int len = sizeof(struct smbios_type32);
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type32));
fill_smbios_header(t, SMBIOS_SYSTEM_BOOT_INFORMATION, len, handle);
*current += len;
+ unmap_sysmem(t);
return len;
}
static int smbios_write_type127(ulong *current, int handle)
{
- struct smbios_type127 *t = (struct smbios_type127 *)*current;
+ struct smbios_type127 *t;
int len = sizeof(struct smbios_type127);
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type127));
fill_smbios_header(t, SMBIOS_END_OF_TABLE, len, handle);
*current += len;
+ unmap_sysmem(t);
return len;
}
Re: [U-Boot] [PATCH v6 13/13] Revert "buildman: Extract environment as part of each build"
Hi, On 12 June 2018 at 20:37, Simon Glass wrote: > This reverts commit 0ddc510ea37aa578b8cb197840a5125409978bec. > > Signed-off-by: Simon Glass > --- > Sorry, please ignore this patch. I am trying to track down a buildman issue and put this commit on top just before sending :-( Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 07/13] efi: Add a comment about duplicated ELF constants
These constants are defined in arch-specific code but redefined here. Add a TODO to clean this up. Signed-off-by: Simon Glass Reviewed-by: Heinrich Schuchardt --- Changes in v6: None Changes in v5: - Drop period after "elf" in comment Changes in v4: None Changes in v3: None Changes in v2: None lib/efi_loader/efi_runtime.c | 4 1 file changed, 4 insertions(+) diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c index acda21c91d..388dfb9840 100644 --- a/lib/efi_loader/efi_runtime.c +++ b/lib/efi_loader/efi_runtime.c @@ -28,6 +28,10 @@ static efi_status_t __efi_runtime EFIAPI efi_unimplemented(void); static efi_status_t __efi_runtime EFIAPI efi_device_error(void); static efi_status_t __efi_runtime EFIAPI efi_invalid_parameter(void); +/* + * TODO(s...@chromium.org): These defines and structs should come from the elf + * header for each arch (or a generic header) rather than being repeated here. + */ #if defined(CONFIG_ARM64) #define R_RELATIVE 1027 #define R_MASK 0xULL -- 2.18.0.rc1.244.gcf134e6275-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 06/13] efi: sandbox: Add relocation constants
Add these so that we can build the EFI loader for sandbox. The values are
for x86_64 so potentially bogus. But we don't support relocation within
sandbox anyway.
Signed-off-by: Simon Glass
---
Changes in v6:
- Warn about building sandbox EFI support on something other than __x86_64__
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
lib/efi_loader/efi_runtime.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 65f2bcf140..acda21c91d 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -58,6 +58,18 @@ struct dyn_sym {
#define R_ABSOLUTE R_RISCV_64
#define SYM_INDEX 32
#endif
+
+/* For sandbox we only support 64-bit x86 at present */
+#elif defined(CONFIG_SANDBOX)
+/*
+ * TODO(s...@chromium.org): Consider providing a way to enable sandbox features
+ * based on the host architecture
+ */
+# ifndef __x86_64__
+# warning "sandbox EFI support is only tested on 64-bit x86"
+# endif
+#define R_RELATIVE 8
+#define R_MASK 0xULL
#else
#error Need to add relocation awareness
#endif
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 12/13] efi: Rename bootefi_test_finish() to bootefi_run_finish()
This function can be used from do_bootefi_exec() so that we use mostly the
same code for a normal EFI application and an EFI test.
Rename the function and use it in both places.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5:
- Rebase to master
Changes in v4:
- Rebase to master
Changes in v3:
- Add new patch to rename bootefi_test_finish() to bootefi_run_finish()
Changes in v2: None
cmd/bootefi.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index b9eb04531b..7a98c9a6bb 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -273,6 +273,20 @@ static efi_status_t bootefi_run_prepare(struct
efi_loaded_image *image,
return 0;
}
+/**
+ * bootefi_run_finish() - finish up after running an EFI test
+ *
+ * @image: Pointer to a struct which holds the loaded image info
+ * @obj: Pointer to a struct which holds the loaded image object
+ */
+static void bootefi_run_finish(struct efi_loaded_image *image,
+ struct efi_object *obj)
+{
+ efi_restore_gd();
+ free(image->load_options);
+ list_del(>link);
+}
+
/*
* Load an EFI payload into a newly allocated piece of memory, register all
* EFI objects it would want to access and jump to it.
@@ -355,8 +369,7 @@ static efi_status_t do_bootefi_exec(void *efi,
ret = efi_do_enter(obj.handle, , entry);
exit:
- /* image has returned, loaded-image obj goes *poof*: */
- list_del();
+ bootefi_run_finish(, );
return ret;
}
@@ -391,20 +404,6 @@ static efi_status_t bootefi_test_prepare(struct
efi_loaded_image *image,
bootefi_device_path, bootefi_image_path);
}
-/**
- * bootefi_test_finish() - finish up after running an EFI test
- *
- * @image: Pointer to a struct which holds the loaded image info
- * @obj: Pointer to a struct which holds the loaded image object
- */
-static void bootefi_test_finish(struct efi_loaded_image *image,
- struct efi_object *obj)
-{
- efi_restore_gd();
- free(image->load_options);
- list_del(>link);
-}
-
static int do_bootefi_bootmgr_exec(void)
{
struct efi_device_path *device_path, *file_path;
@@ -491,7 +490,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return CMD_RET_FAILURE;
ret = efi_test(, );
- bootefi_test_finish(, );
+ bootefi_run_finish(, );
if (ret) {
printf("Test failed: err=%d\n", ret);
return CMD_RET_FAILURE;
@@ -509,7 +508,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
/* Execute the test */
r = efi_selftest(obj.handle, );
- bootefi_test_finish(, );
+ bootefi_run_finish(, );
return r != EFI_SUCCESS;
} else
#endif
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 11/13] efi: Create a function to set up for running EFI code
Add a new bootefi_run_prepare() function which holds common code used to
set up U-Boot to run EFI code. Make use of this from the existing
bootefi_test_prepare() function, as well as do_bootefi_exec().
Also shorten a few variable names.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
- Introduce load_options_path to specifyc U-Boot env var for load_options_path
Changes in v4:
- Rebase to master
Changes in v3:
- Add patch to create a function to set up for running EFI code
Changes in v2: None
cmd/bootefi.c | 79 ---
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index ac80074bc4..b9eb04531b 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -253,6 +253,26 @@ static efi_status_t efi_install_fdt(void *fdt)
return ret;
}
+static efi_status_t bootefi_run_prepare(struct efi_loaded_image *image,
+ struct efi_object *obj,
+ const char *load_options_path,
+ struct efi_device_path *device_path,
+ struct efi_device_path *image_path)
+{
+ efi_setup_loaded_image(image, obj, device_path, image_path);
+
+ /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+ efi_save_gd();
+
+ /* Transfer environment variable as load options */
+ set_load_options(image, load_options_path);
+
+ return 0;
+}
+
/*
* Load an EFI payload into a newly allocated piece of memory, register all
* EFI objects it would want to access and jump to it.
@@ -261,8 +281,8 @@ static efi_status_t do_bootefi_exec(void *efi,
struct efi_device_path *device_path,
struct efi_device_path *image_path)
{
- struct efi_loaded_image loaded_image_info = {};
- struct efi_object loaded_image_info_obj = {};
+ struct efi_loaded_image image;
+ struct efi_object obj;
struct efi_device_path *memdp = NULL;
efi_status_t ret;
@@ -283,19 +303,13 @@ static efi_status_t do_bootefi_exec(void *efi,
assert(device_path && image_path);
}
- efi_setup_loaded_image(_image_info, _image_info_obj,
- device_path, image_path);
+ ret = bootefi_run_prepare(, , "bootargs", device_path,
+ image_path);
+ if (ret)
+ return ret;
- /*
-* gd lives in a fixed register which may get clobbered while we execute
-* the payload. So save it here and restore it on every callback entry
-*/
- efi_save_gd();
-
- /* Transfer environment variable bootargs as load options */
- set_load_options(_image_info, "bootargs");
/* Load the EFI payload */
- entry = efi_load_pe(efi, _image_info);
+ entry = efi_load_pe(efi, );
if (!entry) {
ret = EFI_LOAD_ERROR;
goto exit;
@@ -303,10 +317,10 @@ static efi_status_t do_bootefi_exec(void *efi,
if (memdp) {
struct efi_device_path_memory *mdp = (void *)memdp;
- mdp->memory_type = loaded_image_info.image_code_type;
- mdp->start_address = (uintptr_t)loaded_image_info.image_base;
+ mdp->memory_type = image.image_code_type;
+ mdp->start_address = (uintptr_t)image.image_base;
mdp->end_address = mdp->start_address +
- loaded_image_info.image_size;
+ image.image_size;
}
/* we don't support much: */
@@ -316,8 +330,8 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Call our payload! */
debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry);
- if (setjmp(_image_info.exit_jmp)) {
- ret = loaded_image_info.exit_status;
+ if (setjmp(_jmp)) {
+ ret = image.exit_status;
goto exit;
}
@@ -329,7 +343,7 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Move into EL2 and keep running there */
armv8_switch_to_el2((ulong)entry,
- (ulong)_image_info_obj.handle,
+ (ulong),
(ulong), 0, (ulong)efi_run_in_el2,
ES_TO_AARCH64);
@@ -338,11 +352,11 @@ static efi_status_t do_bootefi_exec(void *efi,
}
#endif
- ret = efi_do_enter(loaded_image_info_obj.handle, , entry);
+ ret = efi_do_enter(obj.handle, , entry);
exit:
/* image has returned, loaded-image obj goes *poof*: */
-
[U-Boot] [PATCH v6 05/13] efi: sandbox: Add distroboot support
With sandbox these values depend on the host system. Let's assume that it is x86_64 for now. Signed-off-by: Simon Glass --- Changes in v6: - Warn about building sandbox EFI support on something other than __x86_64__ Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None include/config_distro_bootcmd.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index d672e8ebe6..1bd79ae3b8 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -251,6 +251,8 @@ #elif defined(CONFIG_ARM) #define BOOTENV_EFI_PXE_ARCH "0xa" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000" + +/* For sandbox we only support 64-bit x86 at present */ #elif defined(CONFIG_X86) /* Always assume we're running 64bit */ #define BOOTENV_EFI_PXE_ARCH "0x7" @@ -261,6 +263,17 @@ #elif defined(CONFIG_CPU_RISCV_64) #define BOOTENV_EFI_PXE_ARCH "0x1b" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000" +#elif defined(CONFIG_SANDBOX) +/* + * TODO(s...@chromium.org): Consider providing a way to enable sandbox features + * based on the host architecture + */ +# ifndef __x86_64__ +# warning "sandbox EFI support is only tested on 64-bit x86" +# endif +/* To support other *host* architectures this should be changed */ +#define BOOTENV_EFI_PXE_ARCH "0x7" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000" #else #error Please specify an EFI client identifier #endif -- 2.18.0.rc1.244.gcf134e6275-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 13/13] Revert "buildman: Extract environment as part of each build"
This reverts commit 0ddc510ea37aa578b8cb197840a5125409978bec.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
tools/buildman/builderthread.py | 10 --
tools/buildman/func_test.py | 5 -
2 files changed, 15 deletions(-)
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index c84ba6acf1..0efe80d945 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -351,16 +351,6 @@ class BuilderThread(threading.Thread):
lines.append(size_result.stdout.splitlines()[1] + ' ' +
rodata_size)
-# Extract the environment from U-Boot and dump it out
-cmd = ['%sobjcopy' % self.toolchain.cross, '-O', 'binary',
- '-j', '.rodata.default_environment',
- 'env/built-in.o', 'uboot.env']
-command.RunPipe([cmd], capture=True,
-capture_stderr=True, cwd=result.out_dir,
-raise_on_error=False, env=env)
-ubootenv = os.path.join(result.out_dir, 'uboot.env')
-self.CopyFiles(result.out_dir, build_dir, '', ['uboot.env'])
-
# Write out the image sizes file. This is similar to the output
# of binutil's 'size' utility, but it omits the header line and
# adds an additional hex value at the end of each line for the
diff --git a/tools/buildman/func_test.py b/tools/buildman/func_test.py
index 363db9d8ce..9206fb299d 100644
--- a/tools/buildman/func_test.py
+++ b/tools/buildman/func_test.py
@@ -327,9 +327,6 @@ class TestFunctional(unittest.TestCase):
def _HandleCommandObjdump(self, args):
return command.CommandResult(return_code=0)
-def _HandleCommandObjcopy(self, args):
-return command.CommandResult(return_code=0)
-
def _HandleCommandSize(self, args):
return command.CommandResult(return_code=0)
@@ -362,8 +359,6 @@ class TestFunctional(unittest.TestCase):
return self._HandleCommandNm(args)
elif cmd.endswith('objdump'):
return self._HandleCommandObjdump(args)
-elif cmd.endswith('objcopy'):
-return self._HandleCommandObjcopy(args)
elif cmd.endswith( 'size'):
return self._HandleCommandSize(args)
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 08/13] efi: sandbox: Enable EFI loader builder for sandbox
This allows this feature to build within sandbox. This is for testing purposes only since it is not possible for sandbox to load native code. Signed-off-by: Simon Glass --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: - Init the 'rows' and 'cols' vars to avoid a compiler error (gcc 4.8.4) Changes in v2: None lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index df58e633d1..d471e6f4a4 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM || X86 || RISCV) && OF_LIBFDT + depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT # We do not support bootefi booting ARMv7 in non-secure mode depends on !ARMV7_NONSEC # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB -- 2.18.0.rc1.244.gcf134e6275-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 09/13] efi: Split out test init/uninit into functions
We plan to run more than one EFI test. In order to avoid duplicating code,
create functions which handle preparing for running the test and cleaning
up afterwards.
Also shorten the awfully long variable names here.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
Changes in v4: None
Changes in v3:
- Add new patch to split out test init/uninit into functions
Changes in v2: None
cmd/bootefi.c | 87 +--
1 file changed, 63 insertions(+), 24 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 707d159bac..a9ebde0c75 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -347,6 +347,60 @@ exit:
return ret;
}
+#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
+/**
+ * bootefi_test_prepare() - prepare to run an EFI test
+ *
+ * This sets things up so we can call EFI functions. This involves preparing
+ * the 'gd' pointer and setting up the load ed image data structures.
+ *
+ * @image: Pointer to a struct which will hold the loaded image info
+ * @obj: Pointer to a struct which will hold the loaded image object
+ * @path: File path to the test being run (often just the test name with a
+ *backslash before it
+ * @test_func: Address of the test function that is being run
+ * @return 0 if OK, -ve on error
+ */
+static efi_status_t bootefi_test_prepare(struct efi_loaded_image *image,
+struct efi_object *obj,
+const char *path, ulong test_func)
+{
+ memset(image, '\0', sizeof(*image));
+ memset(obj, '\0', sizeof(*obj));
+ /* Construct a dummy device path */
+ bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
+ (uintptr_t)test_func,
+ (uintptr_t)test_func);
+ bootefi_image_path = efi_dp_from_file(NULL, 0, path);
+ efi_setup_loaded_image(image, obj, bootefi_device_path,
+ bootefi_image_path);
+ /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+ efi_save_gd();
+
+ /* Transfer environment variable efi_selftest as load options */
+ set_load_options(image, "efi_selftest");
+
+ return 0;
+}
+
+/**
+ * bootefi_test_finish() - finish up after running an EFI test
+ *
+ * @image: Pointer to a struct which holds the loaded image info
+ * @obj: Pointer to a struct which holds the loaded image object
+ */
+static void bootefi_test_finish(struct efi_loaded_image *image,
+ struct efi_object *obj)
+{
+ efi_restore_gd();
+ free(image->load_options);
+ list_del(>link);
+}
+#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
+
static int do_bootefi_bootmgr_exec(void)
{
struct efi_device_path *device_path, *file_path;
@@ -425,31 +479,16 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
#endif
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
- struct efi_loaded_image loaded_image_info = {};
- struct efi_object loaded_image_info_obj = {};
-
- /* Construct a dummy device path. */
- bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
- (uintptr_t)_selftest,
- (uintptr_t)_selftest);
- bootefi_image_path = efi_dp_from_file(NULL, 0, "\\selftest");
-
- efi_setup_loaded_image(_image_info,
- _image_info_obj,
- bootefi_device_path, bootefi_image_path);
- /*
-* gd lives in a fixed register which may get clobbered while we
-* execute the payload. So save it here and restore it on every
-* callback entry
-*/
- efi_save_gd();
- /* Transfer environment variable efi_selftest as load options */
- set_load_options(_image_info, "efi_selftest");
+ struct efi_loaded_image image;
+ struct efi_object obj;
+
+ if (bootefi_test_prepare(, , "\\selftest",
+(uintptr_t)_selftest))
+ return CMD_RET_FAILURE;
+
/* Execute the test */
- r = efi_selftest(loaded_image_info_obj.handle, );
- efi_restore_gd();
- free(loaded_image_info.load_options);
- list_del(_image_info_obj.link);
+ r = efi_selftest(obj.handle, );
+ bootefi_test_finish(, );
return r != EFI_SUCCESS;
} else
#endif
--
[U-Boot] [PATCH v6 02/13] efi: Init the 'rows' and 'cols' variables
The current code causes a compiler error on gcc 4.8.4 as used by sandbox
on Ubuntu 14.04, which is fairly recent. Init these variables to fix the
problem.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5: None
Changes in v4:
- Move the fix to query_console_serial()
Changes in v3:
- Add new patch to init the 'rows' and 'cols' variables
Changes in v2: None
lib/efi_loader/efi_console.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index ce66c935ec..bd953a1485 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -204,8 +204,11 @@ static int query_console_serial(int *rows, int *cols)
return -1;
/* Read {depth,rows,cols} */
- if (term_read_reply(n, 3, 't'))
+ if (term_read_reply(n, 3, 't')) {
+ *rows = -1;
+ *cols = -1;
return -1;
+ }
*cols = n[2];
*rows = n[1];
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox
With sandbox the U-Boot code is not mapped into the sandbox memory range
so does not need to be excluded when allocating EFI memory. Update the EFI
memory init code to take account of that.
Also use mapmem instead of a cast to convert a memory address to a
pointer.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Update to use mapmem instead of a cast
lib/efi_loader/efi_memory.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index ec66af98ea..210e49ee8b 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int pool_type, efi_uintn_t
size, void **buffer)
);
if (r == EFI_SUCCESS) {
- struct efi_pool_allocation *alloc = (void *)(uintptr_t)t;
+ struct efi_pool_allocation *alloc = map_sysmem(t, size);
alloc->num_pages = num_pages;
*buffer = alloc->data;
}
@@ -504,18 +505,22 @@ int efi_memory_init(void)
efi_add_known_memory();
- /* Add U-Boot */
- uboot_start = (gd->start_addr_sp - uboot_stack_size) & ~EFI_PAGE_MASK;
- uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
- efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA, false);
-
- /* Add Runtime Services */
- runtime_start = (ulong)&__efi_runtime_start & ~EFI_PAGE_MASK;
- runtime_end = (ulong)&__efi_runtime_stop;
- runtime_end = (runtime_end + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
- runtime_pages = (runtime_end - runtime_start) >> EFI_PAGE_SHIFT;
- efi_add_memory_map(runtime_start, runtime_pages,
- EFI_RUNTIME_SERVICES_CODE, false);
+ if (!IS_ENABLED(CONFIG_SANDBOX)) {
+ /* Add U-Boot */
+ uboot_start = (gd->start_addr_sp - uboot_stack_size) &
+ ~EFI_PAGE_MASK;
+ uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
+ efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA,
+ false);
+
+ /* Add Runtime Services */
+ runtime_start = (ulong)&__efi_runtime_start & ~EFI_PAGE_MASK;
+ runtime_end = (ulong)&__efi_runtime_stop;
+ runtime_end = (runtime_end + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
+ runtime_pages = (runtime_end - runtime_start) >> EFI_PAGE_SHIFT;
+ efi_add_memory_map(runtime_start, runtime_pages,
+ EFI_RUNTIME_SERVICES_CODE, false);
+ }
#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
/* Request a 32bit 64MB bounce buffer region */
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 00/13] efi: Enable basic sandbox support for EFI loader
A limitation of the EFI loader at present is that it does not build with sandbox. This makes it hard to write tests, since sandbox is used for most testing in U-Boot. This series enables the EFI loader feature. It allows sandbox to build and run a trivial function which calls the EFI API to output a message. This series is at u-boot-dm/efi-working Changes in v6: - Warn about building sandbox EFI support on something other than __x86_64__ Changes in v5: - Add new patch to disallow CMD_BOOTEFI_SELFTEST on sandbox - Drop call to efi_init_obj_list() which is now done in do_bootefi() - Drop period after "elf" in comment - Introduce load_options_path to specifyc U-Boot env var for load_options_path - Rebase to master Changes in v4: - Move the fix to query_console_serial() - Rebase to master - Update SPDX tags Changes in v3: - Add new patch to init the 'rows' and 'cols' variables - Add new patch to rename bootefi_test_finish() to bootefi_run_finish() - Add new patch to split out test init/uninit into functions - Add patch to create a function to set up for running EFI code - Drop incorrect map_sysmem() in write_smbios_table() - Init the 'rows' and 'cols' vars to avoid a compiler error (gcc 4.8.4) - Rebase to master Changes in v2: - Rebase to master - Update to use mapmem instead of a cast Simon Glass (13): efi: Don't allow CMD_BOOTEFI_SELFTEST on sandbox efi: Init the 'rows' and 'cols' variables efi: sandbox: Adjust memory usage for sandbox sandbox: smbios: Update to support sandbox efi: sandbox: Add distroboot support efi: sandbox: Add relocation constants efi: Add a comment about duplicated ELF constants efi: sandbox: Enable EFI loader builder for sandbox efi: Split out test init/uninit into functions efi: sandbox: Add a simple 'bootefi test' command efi: Create a function to set up for running EFI code efi: Rename bootefi_test_finish() to bootefi_run_finish() Revert "buildman: Extract environment as part of each build" cmd/bootefi.c | 153 ++-- include/config_distro_bootcmd.h | 13 +++ include/efi_loader.h| 3 + lib/efi_loader/Kconfig | 12 ++- lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_console.c| 5 +- lib/efi_loader/efi_memory.c | 31 --- lib/efi_loader/efi_runtime.c| 16 lib/efi_loader/efi_test.c | 16 lib/efi_selftest/Kconfig| 2 +- lib/smbios.c| 32 +-- tools/buildman/builderthread.py | 10 --- tools/buildman/func_test.py | 5 -- 13 files changed, 213 insertions(+), 86 deletions(-) create mode 100644 lib/efi_loader/efi_test.c -- 2.18.0.rc1.244.gcf134e6275-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v6 01/13] efi: Don't allow CMD_BOOTEFI_SELFTEST on sandbox
This does not work at present and gives the following error: output: 'ld.bfd: read in flex scanner failed scripts/Makefile.lib:390: recipe for target 'lib/efi_selftest/efi_selftest_miniapp_return_efi.so' failed It may be possible to figure this out with suitable linker magic but it does not seem to be easy. Also, we will be able to run the tests on sandbox without using the miniapp. So for now at least, disable this option. Signed-off-by: Simon Glass --- Changes in v6: None Changes in v5: - Add new patch to disallow CMD_BOOTEFI_SELFTEST on sandbox Changes in v4: None Changes in v3: None Changes in v2: None lib/efi_selftest/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_selftest/Kconfig b/lib/efi_selftest/Kconfig index 59f9f36801..b52696778d 100644 --- a/lib/efi_selftest/Kconfig +++ b/lib/efi_selftest/Kconfig @@ -1,6 +1,6 @@ config CMD_BOOTEFI_SELFTEST bool "Allow booting an EFI efi_selftest" - depends on CMD_BOOTEFI + depends on CMD_BOOTEFI && !SANDBOX imply FAT imply FAT_WRITE help -- 2.18.0.rc1.244.gcf134e6275-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/5] include: reset: Change to use CONFIG_IS_ENABLED(DM_RESET)
On Wed, Jun 13, 2018 at 5:02 AM, Joe Hershberger wrote:
> On Mon, Jun 4, 2018 at 2:19 AM, Ley Foon Tan wrote:
>> Change to use CONFIG_IS_ENABLED(DM_RESET), so this can work in SPL
>> build (CONFIG_SPL_DM_RESET) and U-boot build (CONFIG_DM_RESET).
>>
>> Signed-off-by: Ley Foon Tan
>> ---
>> include/reset.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/reset.h b/include/reset.h
>> index 201bafc..a7bbc1c 100644
>> --- a/include/reset.h
>> +++ b/include/reset.h
>> @@ -77,7 +77,7 @@ struct reset_ctl_bulk {
>> unsigned int count;
>> };
>>
>> -#ifdef CONFIG_DM_RESET
>> +#if CONFIG_IS_ENABLED(DM_RESET)
>
> This seems like it would be more reasonable to squash into the first
> patch of this series.
We need to rename SPL_RESET_SUPPORT to SPL_DM_RESET in the first patch.
Otherwise it will have redefinition of reset-class API compilation
errors in SPL build if we move this patch to first patch.
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-x86
Hi Tom, The following changes since commit 7868909ed53ed41a945f7ed95ebb88aa252142ce: Merge git://git.denx.de/u-boot-fsl-qoriq (2018-06-12 13:25:24 -0400) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to bee053e248e93d82e5c352708f8c892f4a488c54: x86: cougarcanyon2: Add missing chipset interrupt information (2018-06-13 09:50:57 +0800) Andy Shevchenko (1): x86: acpi: Adopt new version of iASL compiler Bin Meng (18): x86: baytrail: Correct the comment of IACORE_VIDS bit ranges usb: xhci-pci: Fix compiler warning x86: ivybridge: Imply USB_XHCI_HCD x86: cougarcanyon2: Update dts for SPI lock down x86: cougarcanyon2: Remove CONFIG_HAVE_INTEL_ME x86: ivybridge: Enable 206ax cpu driver for FSP build x86: ivybridge: Drop CONFIG_USBDEBUG x86: chromebook_link: Remove dm-pre-reloc property in the cpu nodes x86: cougarcanyon2: Enable CPU driver and SMP support x86: irq: Remove chipset specific irq router drivers x86: irq: Change LINK_V2N and LINK_N2V to inline functions x86: Conditionally build the pinctrl_ich6 driver x86: efi: app: Fix broken EFI application x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes x86: efi: payload: Minor clean up on error message output x86: irq: Parse number of PIRQ links from device tree x86: irq: Support discrete PIRQ routing registers via device tree x86: cougarcanyon2: Add missing chipset interrupt information Christian Gmeiner (3): x86: tsc: add support for reading CPU freq from cpuid dm: pci: Make ranges dt property optional dm: pci: Use a 1:1 mapping for bus <-> phy addresses arch/x86/Kconfig | 6 ++ arch/x86/cpu/Makefile | 3 ++- arch/x86/cpu/baytrail/Kconfig | 1 + arch/x86/cpu/baytrail/cpu.c| 2 +- arch/x86/cpu/intel_common/mrc.c| 5 - arch/x86/cpu/irq.c | 127 +++- arch/x86/cpu/ivybridge/Kconfig | 2 ++ arch/x86/cpu/ivybridge/Makefile| 2 +- arch/x86/cpu/ivybridge/model_206ax.c | 15 -- arch/x86/cpu/quark/Makefile| 2 +- arch/x86/cpu/quark/irq.c | 48 -- arch/x86/cpu/quark/quark.c | 26 +++ arch/x86/cpu/queensbay/Makefile| 2 +- arch/x86/cpu/queensbay/irq.c | 64 arch/x86/cpu/queensbay/tnc.c | 39 +++ arch/x86/dts/chromebook_link.dts | 5 - arch/x86/dts/cougarcanyon2.dts | 81 +++ arch/x86/dts/crownbay.dts | 2 +- arch/x86/dts/galileo.dts | 2 +- arch/x86/include/asm/irq.h | 21 +-- arch/x86/lib/Makefile | 6 +++--- configs/cougarcanyon2_defconfig| 6 ++ configs/efi-x86_defconfig | 8 ++- doc/README.x86 | 4 +++- doc/device-tree-bindings/misc/intel,irq-router.txt | 6 ++ drivers/pci/pci-uclass.c | 33 + drivers/timer/tsc_timer.c | 29 +- drivers/usb/host/xhci-pci.c| 5 ++--- lib/efi/Makefile | 6 -- lib/efi/efi_stub.c | 8 --- scripts/Makefile.lib | 1 + scripts/config_whitelist.txt | 1 - 32 files changed, 357 insertions(+), 211 deletions(-) delete mode 100644 arch/x86/cpu/quark/irq.c delete mode 100644 arch/x86/cpu/queensbay/irq.c Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: add Socionext AVE ethernet driver support
2018-06-13 5:45 GMT+09:00 Joe Hershberger : > On Thu, May 24, 2018 at 5:24 AM, Kunihiko Hayashi > wrote: >> Add driver for Socionext AVE ethernet controller that includes MAC and >> MDIO bus supporting RGMII/RMII modes. >> The driver behaves the ethernet driver model (DM_ETH) with devicetree. >> This patch requires the internal phy definition [1]. >> [1] http://patchwork.ozlabs.org/patch/915965/ This comment should be ripped off when this is applied. It should have been under '---' line. >> Signed-off-by: Kunihiko Hayashi >> Signed-off-by: Masahiro Yamada > > Looks great! > > Acked-by: Joe Hershberger Could you apply this with the prerequisite patch please? >> --- >> drivers/net/Kconfig | 10 + >> drivers/net/Makefile | 1 + >> drivers/net/sni_ave.c | 995 >> ++ >> 3 files changed, 1006 insertions(+) > > Any plan to enable this driver in a defconfig so that it is build tested? No worry. I maintain uniphier_*_defconfig We can enable the driver as needed after this driver lands. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] x86: irq: Support discrete PIRQ routing registers via device tree
On Wed, Jun 13, 2018 at 9:29 AM, Simon Glass wrote: > On 12 June 2018 at 02:26, Bin Meng wrote: >> Currently both pirq_reg_to_linkno() and pirq_linkno_to_reg() assume >> consecutive PIRQ routing control registers. But this is not always >> the case on some platforms. Introduce a new device tree property >> intel,pirq-regmap to describe how the PIRQ routing register offset >> is mapped to the link number and adjust the irq router driver to >> utilize the mapping. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - new patch to "support discrete PIRQ routing registers via device tree" >> >> arch/x86/cpu/irq.c | 102 >> +++-- >> arch/x86/include/asm/irq.h | 32 ++- >> doc/device-tree-bindings/misc/intel,irq-router.txt | 6 ++ >> 3 files changed, 107 insertions(+), 33 deletions(-) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] x86: cougarcanyon2: Add missing chipset interrupt information
On Wed, Jun 13, 2018 at 9:29 AM, Simon Glass wrote: > On 12 June 2018 at 02:26, Bin Meng wrote: >> Add Panther Point chipset interrupt pin/PIRQ information, and >> enable the generation of PIRQ routing table and MP table. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - add the PIRQ register mapping via "intel,pirq-regmap" property >> >> arch/x86/dts/cougarcanyon2.dts | 46 >> + >> configs/cougarcanyon2_defconfig | 2 ++ >> 2 files changed, 48 insertions(+) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] x86: irq: Parse number of PIRQ links from device tree
On Wed, Jun 13, 2018 at 9:29 AM, Simon Glass wrote: > Hi Bin, > > On 12 June 2018 at 02:26, Bin Meng wrote: >> The "intel,pirq-link" property in Intel IRQ router's dt bindings >> has two cells, where the second one represents the number of PIRQ >> links on the platform. However current driver does not parse this >> information from device tree. This adds the codes to do the parse >> and save it for future use. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - drop patches that were applied to u-boot-x86 >> - drop v1 patches using Kconfig option CONFIG_DISCRETE_PIRQ_ROUT >> - new patch to "parse number of PIRQ links from device tree" >> >> arch/x86/cpu/irq.c | 14 ++ >> arch/x86/include/asm/irq.h | 2 ++ >> 2 files changed, 12 insertions(+), 4 deletions(-) > > Reviewed-by: Simon Glass > > At some point this driver should be converted to livetree. applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: Add option to prefer bootp/dhcp serverip
2018-06-13 3:59 GMT+08:00 Joe Hershberger :
> On Wed, Jun 6, 2018 at 8:54 PM, Rick Chen wrote:
>>> From: Alexander Graf [mailto:ag...@suse.de]
>>> Sent: Wednesday, June 06, 2018 8:32 PM
>>> To: u-boot@lists.denx.de
>>> Cc: Rick Jian-Zhi Chen(陳建志); Joe Hershberger; Simon Glass
>>> Subject: [PATCH 1/2] net: Add option to prefer bootp/dhcp serverip
>>>
>>> Currently we can choose between 2 different types of behavior for the
>>> serverip
>>> variable:
>>>
>>> 1) Always overwrite it with the DHCP server IP address (default)
>>> 2) Ignore what the DHCP server says (CONFIG_BOOTP_SERVERIP)
>>>
>>> This patch adds a 3rd option:
>>>
>>> 3) Use serverip from DHCP if no serverip is given
>>> (CONFIG_BOOTP_PREFER_SERVERIP)
>>>
>>> With this new option, we can have the default case that a boot file gets
>>> loaded
>>> from the DHCP provided TFTP server work while allowing users to specify
>>> their
>>> own serverip variable to explicitly use a different tftp server.
>>>
>>> Signed-off-by: Alexander Graf
>>> ---
>>> README | 5 +
>>> cmd/Kconfig | 9 +
>>> net/bootp.c | 7 ++-
>>> 3 files changed, 20 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/README b/README
>>> index fb331f910d..d8a99281ca 100644
>>> --- a/README
>>> +++ b/README
>>> @@ -1511,10 +1511,15 @@ The following options need to be configured:
>>> CONFIG_BOOTP_TIMEOFFSET
>>> CONFIG_BOOTP_VENDOREX
>>> CONFIG_BOOTP_MAY_FAIL
>>> + CONFIG_BOOTP_PREFER_SERVERIP
>>>
>>> CONFIG_BOOTP_SERVERIP - TFTP server will be the serverip
>>> environment variable, not the BOOTP server.
>>>
>>> + CONFIG_BOOTP_PREFER_SERVERIP - TFTP server will be the
>>> + serverip environment variable if previously unset, otherwise
>>> + the DHCP provided serverip is used.
>>> +
>>> CONFIG_BOOTP_MAY_FAIL - If the DHCP server is not found
>>> after the configured retry count, the call will fail
>>> instead of starting over. This can be used to fail over diff
>>> --git
>>> a/cmd/Kconfig b/cmd/Kconfig index e283cb9a8a..e77a4131b3 100644
>>> --- a/cmd/Kconfig
>>> +++ b/cmd/Kconfig
>>> @@ -1121,6 +1121,15 @@ config BOOTP_HOSTNAME
>>> help
>>> The name may or may not be qualified with the local domain name.
>>>
>>> +config BOOTP_PREFER_SERVERIP
>>> + bool "Leave serverip variable in place if existing"
>>> + default n
>>> + depends on CMD_BOOTP
>>> + help
>>> + By default a BOOTP/DHCP reply will overwrite the tftp target ip
>>> + address. With this option enabled, it will leave it alone if
>>> + already specified, but populate it if no serverip is specified.
>>> +
>>> config BOOTP_SUBNETMASK
>>> bool "Request & store 'netmask' from BOOTP/DHCP server"
>>> default y
>>> diff --git a/net/bootp.c b/net/bootp.c
>>> index 9d7cb5d30c..91de4cd426 100644
>>> --- a/net/bootp.c
>>> +++ b/net/bootp.c
>>> @@ -147,9 +147,14 @@ static void store_net_params(struct bootp_hdr *bp)
>>> { #if !defined(CONFIG_BOOTP_SERVERIP)
>>> struct in_addr tmp_ip;
>>> + bool overwrite_serverip = true;
>>> +
>>> +#if defined(CONFIG_BOOTP_PREFER_SERVERIP)
>>> + overwrite_serverip = false;
>>> +#endif
>>>
>>> net_copy_ip(_ip, >bp_siaddr);
>>> - if (tmp_ip.s_addr != 0)
>>> + if (tmp_ip.s_addr != 0 && (overwrite_serverip ||
>>> +!net_server_ip.s_addr))
>>> net_copy_ip(_server_ip, >bp_siaddr);
>>> memcpy(net_server_ethaddr,
>>> ((struct ethernet_hdr *)net_rx_packet)->et_src, 6);
>>> --
>>> 2.12.3
>>
>> Hi Alex
>>
>> I have apply those two patchs and verify
>> U-Boot-1-2-net-Add-option-to-prefer-bootp-dhcp-serverip.patch
>> U-Boot-2-2-ax25-Switch-to-CONFIG_BOOTP_PREFER_SERVERIP.patch
>>
>> But it still fail in dhcp command as below
>>
>> case 1
>> serverip is null
>>
>> RISC-V # set serverip
>> RISC-V # env print
>> baudrate=38400
>> bootcmd=fatload mmc 0:1 0x2000 ae350_64.dtb;fatload mmc 0:1 0x0
>> bbl-ae350.bin;go 0x0
>> bootdelay=3
>> bootfile=pxelinux.0
>> ethact=mac@e010
>> fdtcontroladdr=3fedf290
>> fileaddr=60
>> filesize=1bb7d34
>> stderr=serial@f030
>> stdin=serial@f030
>> stdout=serial@f030
>>
>> Environment size: 304/8188 bytes
>> RISC-V # dhcp 0x60 10.0.4.97:boomimage-310y-ag101p.bin
>
> You are explicitly setting the server IP in the DHCP command line, so
> why would you expect the DHCP server IP to be used?
>
>> BOOTP broadcast 1
>> BOOTP broadcast 2
>> BOOTP broadcast 3
>> BOOTP broadcast 4
>> DHCP client bound to address 10.0.4.191 (4603 ms)
>> Using mac@e010 device
>> TFTP from server 255.255.255.255; our IP address is 10.0.4.191;
>
> This broadcast address is clearly not right. It should have been what
> you had in the dhcp command. That should be assigned in net/tftp.c:
> 757...
>
>>> tftp_remote_ip = string_to_ip(net_boot_file_name);
>
> So
Re: [U-Boot] [PATCH v4 4/4] riscv: Remove unused _relocate arguments
Hi Ivan,
On Wed, Jun 13, 2018 at 1:52 AM, Ivan Gorinov wrote:
> EFI image handle and system table are not used in _relocate().
>
> Signed-off-by: Ivan Gorinov
> ---
> arch/riscv/lib/reloc_riscv_efi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/riscv/lib/reloc_riscv_efi.c
> b/arch/riscv/lib/reloc_riscv_efi.c
> index 8b4b2b1..51b7520 100644
> --- a/arch/riscv/lib/reloc_riscv_efi.c
> +++ b/arch/riscv/lib/reloc_riscv_efi.c
> @@ -50,8 +50,7 @@
> #define ELF_R_TYPE ELF32_R_TYPE
> #endif
>
> -efi_status_t _relocate(long ldbase, Elf_Dyn *dyn, efi_handle_t image,
> - struct efi_system_table *systab)
> +efi_status_t _relocate(long ldbase, Elf_Dyn *dyn, efi_handle_t image)
This still has the image argument.
> {
> long relsz = 0, relent = 0;
> Elf_Rela *rel = 0;
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] arm: Remove unused _relocate arguments
Hi Ivan,
On Wed, Jun 13, 2018 at 1:52 AM, Ivan Gorinov wrote:
> EFI image handle and system table are not used in _relocate().
>
> Signed-off-by: Ivan Gorinov
> ---
> arch/arm/lib/crt0_aarch64_efi.S | 2 --
> arch/arm/lib/crt0_arm_efi.S | 2 --
> arch/arm/lib/reloc_aarch64_efi.c | 3 +--
> arch/arm/lib/reloc_arm_efi.c | 3 +--
> 4 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S
> index 5b6c384..0db4360 100644
> --- a/arch/arm/lib/crt0_aarch64_efi.S
> +++ b/arch/arm/lib/crt0_aarch64_efi.S
> @@ -122,8 +122,6 @@ _start:
> mov x29, sp
>
> stp x0, x1, [sp, #16]
> - mov x2, x0
> - mov x3, x1
> adr x0, ImageBase
> adrpx1, _DYNAMIC
> add x1, x1, #:lo12:_DYNAMIC
> diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S
> index 0f296f3..23db49f 100644
> --- a/arch/arm/lib/crt0_arm_efi.S
> +++ b/arch/arm/lib/crt0_arm_efi.S
> @@ -119,8 +119,6 @@ section_table:
> _start:
> stmfd sp!, {r0-r2, lr}
>
> - mov r2, r0
> - mov r3, r1
> adr r1, .L_DYNAMIC
> ldr r0, [r1]
> add r1, r0, r1
> diff --git a/arch/arm/lib/reloc_aarch64_efi.c
> b/arch/arm/lib/reloc_aarch64_efi.c
> index 38c13d3..c648fe4 100644
> --- a/arch/arm/lib/reloc_aarch64_efi.c
> +++ b/arch/arm/lib/reloc_aarch64_efi.c
> @@ -38,8 +38,7 @@
>
> #include
>
> -efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn, efi_handle_t image,
> - struct efi_system_table *systab)
> +efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn, efi_handle_t image)
This still has the image argument.
> {
> long relsz = 0, relent = 0;
> Elf64_Rela *rel = 0;
> diff --git a/arch/arm/lib/reloc_arm_efi.c b/arch/arm/lib/reloc_arm_efi.c
> index 6232e3f..336a98a 100644
> --- a/arch/arm/lib/reloc_arm_efi.c
> +++ b/arch/arm/lib/reloc_arm_efi.c
> @@ -14,8 +14,7 @@
> #include
> #include
>
> -efi_status_t _relocate(long ldbase, Elf32_Dyn *dyn, efi_handle_t image,
> - struct efi_system_table *systab)
> +efi_status_t _relocate(long ldbase, Elf32_Dyn *dyn)
> {
> long relsz = 0, relent = 0;
> Elf32_Rel *rel = 0;
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4] x86: use EFI calling convention for efi_main on x86_64
Hi Ivan,
On Wed, Jun 13, 2018 at 1:52 AM, Ivan Gorinov wrote:
> UEFI specifies the calling convention used in Microsoft compilers;
> first arguments of a function are passed in (%rcx, %rdx, %r8, %r9).
>
> All other compilers use System V ABI by default, passing first integer
> arguments of a function in (%rdi, %rsi, %rdx, %rcx, %r8, %r9).
>
> These ABI also specify different sets of registers that must be preserved
> across function calls (callee-saved).
>
> GCC allows using the Microsoft calling convention by adding the ms_abi
> attribute to a function declaration.
>
> Current EFI implementation in U-Boot specifies EFIAPI for efi_main()
> in the test apps but uses default calling convention in lib/efi.
> The arguments of efi_main() are also passed as unused arguments to the
> _relocate() function.
>
> Save efi_main() arguments in the startup code on x86_64;
> use EFI calling convention for _relocate() on x86_64;
> remove unused _relocate() arguments;
Thanks for working on this. But as I mentioned previously, the removal
of _relocate() arguments should be in a separate patch. This patch
should only deal with the calling convention changes.
So we should have 4 patches:
[1/4]: efi: calling convention changes for x86_64
[2/4]: x86: remove unused _relocate() arguments
[3/4]: arm: remove unused _relocate() arguments
[4/4]: riscv: remove unused _relocate() arguments
> consistently use EFI calling convention for efi_main() everywhere.
>
> Signed-off-by: Ivan Gorinov
> ---
> arch/x86/lib/crt0_x86_64_efi.S | 21 ++---
> arch/x86/lib/reloc_x86_64_efi.c | 3 +--
> lib/efi/efi_app.c | 3 ++-
> lib/efi/efi_stub.c | 3 ++-
> 4 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/lib/crt0_x86_64_efi.S b/arch/x86/lib/crt0_x86_64_efi.S
> index 989799f..096f347 100644
> --- a/arch/x86/lib/crt0_x86_64_efi.S
> +++ b/arch/x86/lib/crt0_x86_64_efi.S
> @@ -3,7 +3,7 @@
> * crt0-efi-x86_64.S - x86_64 EFI startup code.
> * Copyright (C) 1999 Hewlett-Packard Co.
> * Contributed by David Mosberger .
> - * Copyright (C) 2005 Intel Co.
> + * Copyright (C) 2005 Intel Corporation
> * Contributed by Fenghua Yu .
> *
> * All rights reserved.
> @@ -14,26 +14,25 @@
> .globl _start
> _start:
> subq $8, %rsp
> +
> pushq %rcx
> pushq %rdx
>
> -0:
> - lea image_base(%rip), %rdi
> - lea _DYNAMIC(%rip), %rsi
> + lea image_base(%rip), %rcx
> + lea _DYNAMIC(%rip), %rdx
>
> - popq %rcx
> - popq %rdx
> - pushq %rcx
> - pushq %rdx
> call _relocate
>
> - popq %rdi
> - popq %rsi
> + popq %rdx
> + popq %rcx
> +
> + testq %rax, %rax
> + jnz _exit
not "jnz .exit"?
>
> call efi_main
> +.exit:
> addq $8, %rsp
>
> -.exit:
> ret
>
> /*
> diff --git a/arch/x86/lib/reloc_x86_64_efi.c b/arch/x86/lib/reloc_x86_64_efi.c
> index 34c5b2e..59d6f8d 100644
> --- a/arch/x86/lib/reloc_x86_64_efi.c
> +++ b/arch/x86/lib/reloc_x86_64_efi.c
> @@ -14,8 +14,7 @@
> #include
> #include
>
> -efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn, efi_handle_t image,
> - struct efi_system_table *systab)
> +efi_status_t EFIAPI _relocate(long ldbase, Elf64_Dyn *dyn)
> {
> long relsz = 0, relent = 0;
> Elf64_Rel *rel = 0;
> diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
> index c828093..3eb8eeb 100644
> --- a/lib/efi/efi_app.c
> +++ b/lib/efi/efi_app.c
> @@ -96,7 +96,8 @@ static void free_memory(struct efi_priv *priv)
> * U-Boot. If it returns, EFI will continue. Another way to get back to EFI
> * is via reset_cpu().
> */
> -efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table)
> +efi_status_t EFIAPI efi_main(efi_handle_t image,
> +struct efi_system_table *sys_table)
> {
> struct efi_priv local_priv, *priv = _priv;
> efi_status_t ret;
> diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
> index 3138739..399d16b 100644
> --- a/lib/efi/efi_stub.c
> +++ b/lib/efi/efi_stub.c
> @@ -268,7 +268,8 @@ static void add_entry_addr(struct efi_priv *priv, enum
> efi_entry_t type,
> * This function is called by our EFI start-up code. It handles running
> * U-Boot. If it returns, EFI will continue.
> */
> -efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table)
> +efi_status_t EFIAPI efi_main(efi_handle_t image,
> +struct efi_system_table *sys_table)
> {
> struct efi_priv local_priv, *priv = _priv;
> struct efi_boot_services *boot = sys_table->boottime;
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND][PATCH 5/9] clk: Add Actions Semi OWL clock support
Hi Mani,
On 12 June 2018 at 00:14, Manivannan Sadhasivam
wrote:
> Hi Simon,
>
> On Mon, Jun 11, 2018 at 01:38:42PM -0600, Simon Glass wrote:
>> Hi,
>>
>> On 11 June 2018 at 09:48, Manivannan Sadhasivam
>> wrote:
>> > This commit adds Actions Semi OWL family base clock and S900 SoC specific
>> > clock support. For S900 peripheral clock support, only UART clock has been
>> > added for now.
>> >
>> > Signed-off-by: Manivannan Sadhasivam
>> > ---
>> > arch/arm/include/asm/arch-owl/clk_owl.h | 61 +
>> > arch/arm/include/asm/arch-owl/regs_s900.h | 64 +
>> > arch/arm/mach-owl/Kconfig | 2 +-
>> > drivers/clk/Kconfig | 1 +
>> > drivers/clk/Makefile | 1 +
>> > drivers/clk/owl/Kconfig | 12 +++
>> > drivers/clk/owl/Makefile | 4 +
>> > drivers/clk/owl/clk_owl.c | 60 +
>> > drivers/clk/owl/clk_s900.c| 104 ++
>> > 9 files changed, 308 insertions(+), 1 deletion(-)
>> > create mode 100644 arch/arm/include/asm/arch-owl/clk_owl.h
>> > create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
>> > create mode 100644 drivers/clk/owl/Kconfig
>> > create mode 100644 drivers/clk/owl/Makefile
>> > create mode 100644 drivers/clk/owl/clk_owl.c
>> > create mode 100644 drivers/clk/owl/clk_s900.c
>>
>> This doesn't look quite right to me. It looks like you should put all
>> the code in clk_s900.c and delete clk_owl.c.
>>
>
> The intention is to separate generic OWL family and SoC specific part. I
> know that there isn't much in the OWL part now but since this is just a
> basic clk support and I will extend this in upcoming days with further
> peripherals, this makes sense to me.
>
> Also, there are plans to support other OWL family SoCs like S500 and
> S700. So, in those cases this partition will avoid much code duplication.
> Moreover, the pattern followed here matches the Linux kernel common
> clock framework by some means.
I still don't understand this. From the look of it, clk_owl.c has
almost nothing in it and all the logic is in the driver.
It looks like you definitely don't want to have common driver that
will support multiple compatible strings? Is that right?
But then you have this line in the 'generic' code:
+ { .compatible = "actions,s900-cmu" },
Of course it is hard to see where you are going with a start like
this, but I imagine that the next driver you do would have a similar
structure to the current one.
So my question is, why not just have the U_BOOT_DRIVER() and other
'common' stuff in each driver? I cannot see what you are gaining. You
are losing discoverability since it will be hard for people to find
the driver for their actual chip (the compatible string is in one
file but all the code is in another).
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/13] efi: Don't allow CMD_BOOTEFI_SELFTEST on sandbox
Hi Heinrich, On 11 June 2018 at 23:38, Heinrich Schuchardt wrote: > On 06/12/2018 07:26 AM, Simon Glass wrote: >> This does not work at present and gives the following error: >> >> output: 'ld.bfd: read in flex scanner failed >> scripts/Makefile.lib:390: recipe for target >> 'lib/efi_selftest/efi_selftest_miniapp_return_efi.so' failed >> >> It may be possible to figure this out with suitable linker magic but it >> does not seem to be easy. Also, we will be able to run the tests on >> sandbox without using the miniapp. >> >> So for now at least, disable this option. >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in v5: >> - Add new patch to disallow CMD_BOOTEFI_SELFTEST on sandbox >> >> Changes in v4: None >> Changes in v3: None >> Changes in v2: None >> >> lib/efi_selftest/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/efi_selftest/Kconfig b/lib/efi_selftest/Kconfig >> index 59f9f36801..b52696778d 100644 >> --- a/lib/efi_selftest/Kconfig >> +++ b/lib/efi_selftest/Kconfig >> @@ -1,6 +1,6 @@ >> config CMD_BOOTEFI_SELFTEST >> bool "Allow booting an EFI efi_selftest" >> - depends on CMD_BOOTEFI >> + depends on CMD_BOOTEFI && !SANDBOX > > It is sufficient to change the following line in > lib/efi_selftest/Makefile to exclude building of > efi_selftest_startimage_exit.o and > efi_selftest_startimage_return.o: > > -ifeq ($(CONFIG_X86_64),) > +ifeq ($(CONFIG_X86_64)$(SANDBOX),) > > This way we can run all other tests. It can build them but they don't work for me. I would like to leave this as future work as there have been plenty of changes to this long-running series already. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/3] cmd: usb gadget: Add a command to bind a USB gadget driver to a UDC port
Hi Jean-Jacques, On 12 June 2018 at 03:31, Jean-Jacques Hiblot wrote: > Hi, > > > On 08/06/2018 23:59, Simon Glass wrote: >> >> Hi, >> >> On 7 June 2018 at 01:39, Lukasz Majewski wrote: >>> >>> Hi Jean-Jacques, >>> Most of the time the UDC is bound to a driver when a dedicated command is executed, like 'dfu'. But the ethernet gadget driver must be bound by calling usb_ether_init() in the code otherwise the USB ethernet adapter is not visible to the ethernet core. In DM context, the platform code should not be used to bind UDC to a particular driver, so adding a new command to bind a USB device port to a driver. usage example: usbdev bind 0 usb_ether usbdev unbind 0 >>> >>> I would prefer a comment from Simon (so adding him to CC) - as it looks >>> to me that we shall try to use DM to avoid adding separate commands for >>> binding. >> >> We could perhaps introduce 'bind' and 'unbind' commands with similar >> arguments? > > What kind of parameters should be used to identify the device to bind ? > I see 2 possible options: > - node paths: bind /opc/omap_dwc3@4838/usb@483d usb_ether > - device class + index: bind usb_dev 0 usb_ether. > > The last one looks a lot like what I proposed, only more generic, but > requires creating a table to match a string with a UCLASS id. > The first is more precise but IMO less user friendly. We can look up a uclass by name, so your second open should work OK. It matches the current U-Boot approach pretty well two since most commands work this way. However, I have sometimes thought (with driver model) of supporting the first option as a fallback. You could in fact have a function that supports both: 1. Option 1 - it does a global search for a device with that DT node 2. Option 2 - it does a uclass_get_device_by_seq() call I agree that option 2 is likely to be much preferred in normal use. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
Hi Bin, Alex, On 12 June 2018 at 09:36, Bin Meng wrote: > From: Alexander Graf > > Currently efi.h determines a few bits of its environment according to > config options. This falls apart with the efi stub support which may > result in efi.h getting pulled into the stub as well as real U-Boot > code. In that case, one may be 32bit while the other one is 64bit. > > This patch changes the conditionals to use compiler provided defines > instead. That way we always adhere to the build environment we're in > and the definitions adjust automatically. > > Signed-off-by: Alexander Graf > Reviewed-by: Bin Meng > Tested-by: Bin Meng > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > include/efi.h| 17 - > lib/efi/Makefile | 4 ++-- > 2 files changed, 6 insertions(+), 15 deletions(-) > > diff --git a/include/efi.h b/include/efi.h > index 98bddba..5e1e8ac 100644 > --- a/include/efi.h > +++ b/include/efi.h > @@ -19,12 +19,12 @@ > #include > #include > > -#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && > defined(__x86_64__)) > -/* EFI uses the Microsoft ABI which is not the default for GCC */ > +/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */ > +#ifdef __x86_64__ > #define EFIAPI __attribute__((ms_abi)) > #else > #define EFIAPI asmlinkage > -#endif > +#endif /* __x86_64__ */ I made the same comment in another patch. This is becoming too ad-hoc where making EFI builds work is distributed and hidden in such a way that no one will be able to know whether a change causes problems or not. I feel that build config should be deterministic given the CONFIG options provided by the board. Any checks of compiler predefines should be done in one place (efi.h?) and bugs in that stuff should there all be in one place too, and easier to debug and fix. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] x86: irq: Support discrete PIRQ routing registers via device tree
On 12 June 2018 at 02:26, Bin Meng wrote: > Currently both pirq_reg_to_linkno() and pirq_linkno_to_reg() assume > consecutive PIRQ routing control registers. But this is not always > the case on some platforms. Introduce a new device tree property > intel,pirq-regmap to describe how the PIRQ routing register offset > is mapped to the link number and adjust the irq router driver to > utilize the mapping. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - new patch to "support discrete PIRQ routing registers via device tree" > > arch/x86/cpu/irq.c | 102 > +++-- > arch/x86/include/asm/irq.h | 32 ++- > doc/device-tree-bindings/misc/intel,irq-router.txt | 6 ++ > 3 files changed, 107 insertions(+), 33 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] x86: cougarcanyon2: Add missing chipset interrupt information
On 12 June 2018 at 02:26, Bin Meng wrote: > Add Panther Point chipset interrupt pin/PIRQ information, and > enable the generation of PIRQ routing table and MP table. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - add the PIRQ register mapping via "intel,pirq-regmap" property > > arch/x86/dts/cougarcanyon2.dts | 46 > + > configs/cougarcanyon2_defconfig | 2 ++ > 2 files changed, 48 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] x86: irq: Parse number of PIRQ links from device tree
Hi Bin, On 12 June 2018 at 02:26, Bin Meng wrote: > The "intel,pirq-link" property in Intel IRQ router's dt bindings > has two cells, where the second one represents the number of PIRQ > links on the platform. However current driver does not parse this > information from device tree. This adds the codes to do the parse > and save it for future use. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - drop patches that were applied to u-boot-x86 > - drop v1 patches using Kconfig option CONFIG_DISCRETE_PIRQ_ROUT > - new patch to "parse number of PIRQ links from device tree" > > arch/x86/cpu/irq.c | 14 ++ > arch/x86/include/asm/irq.h | 2 ++ > 2 files changed, 12 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass At some point this driver should be converted to livetree. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] soc: qualcomm: Add Shared Memory Manager driver
Hi Ramon, On 12 June 2018 at 02:50, Ramon Fried wrote: > On June 11, 2018 10:38:45 PM GMT+03:00, Simon Glass wrote: >>Hi Ramon, >> >>On 11 June 2018 at 13:14, Ramon Fried wrote: >>> >>> >>> On Mon, Jun 11, 2018 at 5:53 PM, Simon Glass >>wrote: Hi Ramon, On 9 June 2018 at 03:06, Ramon Fried wrote: > The Shared Memory Manager driver implements an interface for >>allocating > and accessing items in the memory area shared among all of the > processors in a Qualcomm platform. > > Adapted from the Linux driver (4.17) > > Changes from the original Linux driver: > * Removed HW spinlock mechanism, which is irrelevant > in U-boot particualar use case, which is just reading from the >>smem. > * adaptaion from Linux driver model to U-boot's. > > Cc: Bjorn Andersson > Signed-off-by: Ramon Fried > --- > > MAINTAINERS | 1 + > arch/arm/Kconfig | 1 + > drivers/Kconfig | 2 + > drivers/soc/Kconfig | 5 + > drivers/soc/Makefile | 1 + > drivers/soc/qualcomm/Kconfig | 11 + > drivers/soc/qualcomm/Makefile | 3 + > drivers/soc/qualcomm/smem.c | 934 >>++ > 8 files changed, 958 insertions(+) > create mode 100644 drivers/soc/Kconfig > create mode 100644 drivers/soc/qualcomm/Kconfig > create mode 100644 drivers/soc/qualcomm/Makefile > create mode 100644 drivers/soc/qualcomm/smem.c Sorry, but NAK on this. This patch supports direct calls into a driver which is not allowed. This should be done through the driver's uclass API, not through direct calls. >>> Hi Simon, >>> I see your point. >>> As you probably see, I was looking at the DM framework for the >>convenience >>> it >>> gives with binding device-tree nodes and drivers. >>> If it's not an option I'll rewrite it as as arch-code under >>mach-snapdragon. >>> Thanks, >>> Ramon. >> >>You are correct that you should be using driver model. It's that you >>need to do it fully, with a proper API. There are lots of examples. >> > Doesn't it make sense to add some facility for drivers that don't export > common functionalities. Like Linux platform drivers? Well this is how things used to work in U-Boot before driver model. Now we are trying to move things to driver model. It does not look like you have many calls, so it should be easy enough to move it to a uclass. You can also add a command to access the device. People can see the tree of devices with 'dm tree', etc. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 28/41] net: fec_mxc: Add the init_clk_fec function
Hi, On 12 June 2018 at 12:27, Joe Hershberger wrote: > > Hi Peng, > > On Mon, May 28, 2018 at 7:25 AM, Peng Fan wrote: > > From: Ye Li > > > > When the power domain driver is enabled, we need to enable clocks after > > power > > domain on. So the clock settings can't set in board_init, needs to set them > > when the device is probed. Add this weak function in driver, that SoC codes > > can implement the clock settings. > > Can you not use clock infrastructure in DM to handle this. We don't > really want these direct calls out of drivers like this. Simon? > Yes that is definitely bad. Probably the easiest option is to add a clock driver. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
On June 12, 2018 1:24:09 PM PDT, Nishanth Menon wrote:
>As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
>needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
>be done unconditionally for Cortex-A15 processors. Provide a config
>option for platforms to enable this option based on impact analysis
>for products.
>
>NOTE: This patch in itself is NOT the final solution, this requires:
>a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
> provide direct access to ACR register.
>b) Operating Systems such as Linux to provide adequate workaround in
>the
> right locations.
This is the case as of 4.18 so you could probably reference CONFIG_CPU_SPECTRE
and CONFIG_HARDEN_BRANCH_PREDICTOR in a v2.
>c) This workaround applies to only the boot processor. It is important
> to apply workaround as necessary (context-save-restore) around low
> power context loss OR additional processors as necessary in either
> firmware support OR elsewhere in OS.
About that, I don't know enough of uboot but are there existing PSCI or other
seemingly standard secondary core support in uboot that would make us go
through the same initialization as the boot CPU? If not, is everything going to
be largely implementation specific and scattered between uboot and the
hypervisors or kernel?
FWIW, this is what prompted me to submit this:
https://patchwork.kernel.org/patch/10453643/
>
>[1] https://developer.arm.com/support/security-update
>[2]
>http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
>
>Cc: Marc Zyngier
>Cc: Russell King
>Cc: Tony Lindgren
>Cc: Robin Murphy
>Cc: Florian Fainelli
>Cc: Catalin Marinas
>Cc: Will Deacon
>Cc: Christoffer Dall
>Cc: Andre Przywara
>Cc: Ard Biesheuvel
>Cc: Tom Rini
>Cc: Michael Nazzareno Trimarchi
>
>Signed-off-by: Nishanth Menon
>---
> arch/arm/Kconfig | 4
> arch/arm/cpu/armv7/start.S | 8
> 2 files changed, 12 insertions(+)
>
>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>index 9e32d5b43cb0..98f58fd27696 100644
>--- a/arch/arm/Kconfig
>+++ b/arch/arm/Kconfig
>@@ -109,6 +109,7 @@ config SYS_ARM_MPU
> # CONFIG_ARM_ERRATA_798870
> # CONFIG_ARM_ERRATA_801819
> # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
>+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>
> config ARM_ERRATA_430973
> bool
>@@ -182,6 +183,9 @@ config ARM_ERRATA_855873
> config ARM_CORTEX_A8_CVE_2017_5715
> bool
>
>+config ARM_CORTEX_A15_CVE_2017_5715
>+ bool
>+
> config CPU_ARM720T
> bool
> select SYS_CACHE_SHIFT_5
>diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>index 3beaf5a93d81..81edec01bf32 100644
>--- a/arch/arm/cpu/armv7/start.S
>+++ b/arch/arm/cpu/armv7/start.S
>@@ -241,6 +241,14 @@ skip_errata_798870:
> skip_errata_801819:
> #endif
>
>+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
>+ orr r0, r0, #1 << 0 @ Enable invalidates of BTB
>+ push{r1-r5} @ Save the cpu info registers
>+ bl v7_arch_cp15_set_acr
>+ pop {r1-r5} @ Restore the cpu info - fall through
>+#endif
>+
> #ifdef CONFIG_ARM_ERRATA_454179
> mrc p15, 0, r0, c1, c0, 1 @ Read ACR
>
--
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
On 06/12/2018 10:24 PM, Nishanth Menon wrote: > Hi, > > This is a follow on from https://marc.info/?l=u-boot=151691688828176=2 > (RFC) > > NOTE: > * As per ARM recommendations[2], and discussions in list[1] ARM > Cortex-A9/12/17 do not need additional steps in u-boot to enable the > OS level workarounds. > * This itself is'nt a complete solution and is based on recommendation > This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen > on > linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag). > * I think it is necessary on older SoCs without firmware support > (such as older OMAPs and AM*) to have kernel support mirroring what we do in > u-boot to support additional cores AND/OR low power states where contexts > are > lost (assuming ACR states are'nt saved). just my 2 cents. > > Few of the tests (with linux next-20180612): > AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15) > OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15) > OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8) > AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8) > > Nishanth Menon (4): > ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for > CVE-2017-5715 > ARM: Introduce ability to enable invalidate of BTB with ICIALLU on > Cortex-A15 for CVE-2017-5715 > ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of > BTB) to facilitate CVE_2017-5715 WA in OS > ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for > CVE-2017-5715 > > arch/arm/Kconfig| 9 + > arch/arm/cpu/armv7/start.S | 15 +-- > arch/arm/mach-omap2/Kconfig | 3 +++ > 3 files changed, 25 insertions(+), 2 deletions(-) > > [1] https://marc.info/?t=15163990652=1=2 > [2] https://developer.arm.com/support/security-update > [3] https://marc.info/?t=15154379047=1=2 and the latest in: > https://marc.info/?l=linux-arm-kernel=151689379521082=2 > [4] > > https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 > https://www.op-tee.org/security-advisories/ > https://www.linaro.org/blog/meltdown-spectre/ > Except for that minor insignificant nit about BIT() macro, entire series Acked-by: Marek Vasut -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
On 06/12/2018 10:24 PM, Nishanth Menon wrote: > Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr > function to setup the bits, we are able to override the settings. > > Without this enabled, Linux kernel reports: > CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, > system vulnerable > > With this enabled, Linux kernel reports: > CPU0: Spectre v2: using ICIALLU workaround > > NOTE: This by itself does not enable the workaround for CPU1 (on > OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches. > > Signed-off-by: Nishanth Menon > --- > arch/arm/mach-omap2/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 3bb1ecb58de0..77820cc8d1e4 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -53,6 +53,7 @@ config OMAP54XX > bool "OMAP54XX SoC" > select ARM_ERRATA_798870 > select SYS_THUMB_BUILD > + select ARM_CORTEX_A15_CVE_2017_5715 > imply NAND_OMAP_ELM > imply NAND_OMAP_GPMC > imply SPL_DISPLAY_PRINT > Can this be enabled for all CA15 systems somehow ? I am sure there are more that are vulnerable. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
On 06/12/2018 10:24 PM, Nishanth Menon wrote: > As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB) > needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to > be done unconditionally for Cortex-A15 processors. Provide a config > option for platforms to enable this option based on impact analysis > for products. > > NOTE: This patch in itself is NOT the final solution, this requires: > a) Implementation of v7_arch_cp15_set_acr on SoCs which may not >provide direct access to ACR register. > b) Operating Systems such as Linux to provide adequate workaround in the >right locations. > c) This workaround applies to only the boot processor. It is important >to apply workaround as necessary (context-save-restore) around low >power context loss OR additional processors as necessary in either >firmware support OR elsewhere in OS. > > [1] https://developer.arm.com/support/security-update > [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html > > Cc: Marc Zyngier > Cc: Russell King > Cc: Tony Lindgren > Cc: Robin Murphy > Cc: Florian Fainelli > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Christoffer Dall > Cc: Andre Przywara > Cc: Ard Biesheuvel > Cc: Tom Rini > Cc: Michael Nazzareno Trimarchi > > Signed-off-by: Nishanth Menon > --- > arch/arm/Kconfig | 4 > arch/arm/cpu/armv7/start.S | 8 > 2 files changed, 12 insertions(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 9e32d5b43cb0..98f58fd27696 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -109,6 +109,7 @@ config SYS_ARM_MPU > # CONFIG_ARM_ERRATA_798870 > # CONFIG_ARM_ERRATA_801819 > # CONFIG_ARM_CORTEX_A8_CVE_2017_5715 > +# CONFIG_ARM_CORTEX_A15_CVE_2017_5715 > > config ARM_ERRATA_430973 > bool > @@ -182,6 +183,9 @@ config ARM_ERRATA_855873 > config ARM_CORTEX_A8_CVE_2017_5715 > bool > > +config ARM_CORTEX_A15_CVE_2017_5715 > + bool > + > config CPU_ARM720T > bool > select SYS_CACHE_SHIFT_5 > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S > index 3beaf5a93d81..81edec01bf32 100644 > --- a/arch/arm/cpu/armv7/start.S > +++ b/arch/arm/cpu/armv7/start.S > @@ -241,6 +241,14 @@ skip_errata_798870: > skip_errata_801819: > #endif > > +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715 > + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register > + orr r0, r0, #1 << 0 @ Enable invalidates of BTB Can we use BIT() macro in the assembler code too ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot
Hi Heinrich,
On Wed, Jun 13, 2018 at 12:04 AM, Heinrich Schuchardt
wrote:
> On 06/12/2018 05:36 PM, Bin Meng wrote:
>> Since commit f3b5056c4e72 ("efi_loader: split README.efi into two
>> separate documents"), the original README.efi was renamed to
>> README.u-boot_on_efi, but x86 doc still refers to the old one.
>>
>> This updates the x86 doc to reference both README.u-boot_on_efi and
>> README.uefi.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> Changes in v2:
>> - update the x86 doc to reference also README.uefi
>>
>> doc/README.x86 | 14 +++---
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/doc/README.x86 b/doc/README.x86
>> index 78664c3..9f657df 100644
>> --- a/doc/README.x86
>> +++ b/doc/README.x86
>> @@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu.
>> EFI Support
>> ---
>> U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
>> -This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI
>> -application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where
>> U-Booot
>> -provides an EFI environment to the kernel (i.e. replaces UEFI completely but
>> -provides the same EFI run-time services) is not currently supported on x86.
>> +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
>> +UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
>> +The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to
>> +the kernel (i.e. replaces UEFI completely but provides the same EFI run-time
>> +services) is not currently supported on x86.
>
> Do you mean
> "is not currently supported on x86 in conjunction with EFI_STUB"
> or do you mean
> "still has bugs on x86"?
>
> On qemu-x86_defconfig I can start EFI applications like the
> helloworld.efi and ipxe. It is only the Linux kernel that has a problem
> with memory setup. That is of cause a bug that needs further attention.
>
I did not touch this when I updated the doc. I believe the doc means
CONFIG_EFI_LOADER is not currently supported. As you mentioned, there
are still some issues to work out. Maybe after you address all the
remaining issues, we can update the doc for its support :)
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fsl-qoriq master
On Tue, Jun 12, 2018 at 05:24:20PM +, York Sun wrote: > Tom, > > I have fixed the issues you caught earlier, and pass compiling > https://travis-ci.org/yorksun/u-boot/builds/390939575 > > The following changes since commit 71002b508a1bc0986023764f155f0db26f548db2: > > cmd: add missing line breaks for pr_err() (2018-06-07 20:06:29 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-fsl-qoriq.git > > for you to fetch changes up to 2d91b533312888e596563a299588e81906383464: > > LS1012AFRWY: Add Secure Boot support (2018-06-11 12:34:45 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/13] x86: Change __kernel_size_t conditionals to use compiler provided defines
Hi Bin,
On 12 June 2018 at 09:36, Bin Meng wrote:
> Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86
> 64-bit payload does not work anymore. The call to GetMemoryMap()
> in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since
> the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly
> interpreted as int, but it should actually be long in a 64-bit EFI
> environment.
>
> This changes the x86 __kernel_size_t conditionals to use compiler
> provided defines instead. That way we always adhere to the build
> environment we're in and the definitions adjust automatically.
>
> Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t")
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - new patch to "change __kernel_size_t conditionals to use compiler
> provided defines"
>
> arch/x86/include/asm/posix_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/posix_types.h
> b/arch/x86/include/asm/posix_types.h
> index 717f6cb..a19f1a0 100644
> --- a/arch/x86/include/asm/posix_types.h
> +++ b/arch/x86/include/asm/posix_types.h
> @@ -16,7 +16,7 @@ typedef int __kernel_pid_t;
> typedef unsigned short __kernel_ipc_pid_t;
> typedef unsigned short __kernel_uid_t;
> typedef unsigned short __kernel_gid_t;
> -#if CONFIG_IS_ENABLED(X86_64)
> +#if defined __x86_64__
Ick.
I worry that this is hiding an EFI peculiarity in generic code.
We have a lot of occurrences of '-#if CONFIG_IS_ENABLED(X86_64)' and
it is not obvious why this one is wrong and the others are correct. A
change to posix_types will presumably affect other things too.
I'm not sure of the best way to solve this,
Is it possible /sensible to introduce a new CONFIG which selects int
or long for these types? I am not even sure what it could be called,
but then it could normally be set according to the X86_64 setting (in
U-Boot or SPL) but changed by EFI.
Or is this not a config setting, but a modulation of a config setting?
If so, then perhaps we can have:
#if CONFIG_IS_ENABLED(X86_64)
# if
#define USE_LONG_FOR_64BIT
#else
#define USE_INT_FOR_64BIT
#else
#define USE_LONG_FOR_64BIT
#endif
But in any case I think we need something explicit for the particular
'64-bit int' needed by this particular build of EFI.
I suppose another possibility is that efi_stub.c should not use
efi_uintn_t and we should just revert that patch? At present the
64-bit stub is quite clearly differentiated from the rest of U-Boot.
Are we just going to end up with a spiderweb of problems here?
> typedef unsigned long __kernel_size_t;
> typedef long __kernel_ssize_t;
> #else
> --
> 2.7.4
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 05/13] efi: sandbox: Add distroboot support
Hi Alex, On 12 June 2018 at 08:06, Alexander Graf wrote: > > > On 12.06.18 15:48, Simon Glass wrote: >> Hi Alex, >> >> On 12 June 2018 at 02:13, Alexander Graf wrote: >>> >>> >>> On 12.06.18 07:26, Simon Glass wrote: With sandbox these values depend on the host system. Let's assume that it is x86_64 for now. Signed-off-by: Simon Glass --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None include/config_distro_bootcmd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index d672e8ebe6..8d11f52da0 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -251,7 +251,7 @@ #elif defined(CONFIG_ARM) #define BOOTENV_EFI_PXE_ARCH "0xa" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000" -#elif defined(CONFIG_X86) +#elif defined(CONFIG_X86) || defined(CONFIG_SANDBOX) >>> >>> I was serious when I said I wanted to have a defined(__x86_64__) guard. >>> Otherwise we'll expose incorrect information. And I doubt that anyone >>> will catch it when porting sandbox to non-x86, because it doesn't error out. >> >> OK I can do a warning but I cannot use the current guard, otherwise it >> prevents sandbox even building on ARM hosts! > > Just change defined(CONFIG_X86) into defined(__x86_64__) || > defined(__i386__) then? Maybe the same for the other archs? I mean print a warning if sandbox is not being build on x86. What you are suggesting is some sort of ad-hoc architecture detection in the EFI header file. If we have a problem here, it should be solved centrally. I'll add a comment. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
On 21:40-20180612, Russell King - ARM Linux wrote: [...] > > I started respinning the series, while there is definitely a use of > > implementing in u-boot, > > I am starting to wonder if we should also be doing this in kernel. > > How does the kernel set the bit when the kernel is running in non-secure > mode, when the ACTLR is read-only in that mode? For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve it: https://patchwork.kernel.org/patch/10461273/ This'd be similar in implementation to ARM erratum 801819 workaround that needs two pieces (u-boot + kernel). I am not really worried about OMAP5/DRA7 since they should'nt loose context in Low power modes. Other SoCs need to be aware of the constraints. /me wishes PSCI was a standard during ARMv7, but it was'nt... So legacy v7 SoCs have implementations that are kind of different (even smc calling conventions vary). -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 10/13] efi: sandbox: Add a simple 'bootefi test' command
Hi Alex, On 12 June 2018 at 08:11, Alexander Graf wrote: > > > On 12.06.18 15:48, Simon Glass wrote: >> Hi Alex, >> >> On 12 June 2018 at 02:28, Alexander Graf wrote: >>> >>> >>> On 12.06.18 07:26, Simon Glass wrote: This jumps to test code which can call directly into the EFI support. It does not need a separate image so it is easy to write tests with it. This test can be executed without causing problems to the run-time environemnt (e.g. U-Boot does not need to reboot afterwards). For now the test just outputs a message. To try it: ./sandbox/u-boot -c "bootefi test" U-Boot 2017.09-00204-g696c9855fe (Sep 17 2017 - 16:43:53 -0600) DRAM: 128 MiB MMC: Using default environment In:serial Out: serial Err: serial SCSI: Net: No ethernet found. IDE: Bus 0: not available Found 0 disks WARNING: booting without device tree Hello, world! Test passed Signed-off-by: Simon Glass >>> >>> From Heinrich's comments it sounded like it wouldn't be hard to make the >>> selftest work. That sounds more appealing to me to be honest :). >> >> Yes and in fact my hope was to run the tests automatically as part of >> 'make tests' >> >> But rather than expanding the scope of this series, can we get this in >> first? Having EFI support in sandbox is a substantial step forward. > > I agree that it would be amazing to have it in, I just want to make sure > we're walking into the right direction. And what I want to have is an > easy way to execute EFI binaries from user space :). That's a different thing entirely from the purpose of my series. My series is designed to allow EFI applications to be *linked* with sandbox and run just like normal C code, with a full unified stack trace, etc. I think this is a very useful feature separate from running EFI binaries in user space. > > Also I don't think that sandbox support is all that far off. Heinrich's > patch should have resolved compilation, no? I don't know what it entails but Heinrich says there is a memory alignment problem to resolve. I was able to repeat his FAT failure but adding his patch and a few other tweaks. I'm happy to look at this once we have basic sandbox support available, but if Heinrich wants to take a look, he is welcome to. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 04/13] sandbox: smbios: Update to support sandbox
Hi Alex, On 12 June 2018 at 08:05, Alexander Graf wrote: > > > On 12.06.18 15:48, Simon Glass wrote: >> Hi Alex, >> >> On 12 June 2018 at 02:12, Alexander Graf wrote: >>> >>> >>> On 12.06.18 07:26, Simon Glass wrote: At present this code casts addresses to pointers so cannot be used with sandbox. Update it to use mapmem instead. Signed-off-by: Simon Glass --- Changes in v5: None Changes in v4: None Changes in v3: - Drop incorrect map_sysmem() in write_smbios_table() Changes in v2: None lib/smbios.c | 32 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/lib/smbios.c b/lib/smbios.c index df3d26b071..fc3dabcbc1 100644 --- a/lib/smbios.c +++ b/lib/smbios.c @@ -6,6 +6,7 @@ */ #include +#include #include #include #include @@ -72,9 +73,10 @@ static int smbios_string_table_len(char *start) static int smbios_write_type0(ulong *current, int handle) >>> >>> Please change the function argument to indicate that we're no longer >>> dealing with pointers, but instead with "u-boot physical addresses". >>> >>> Same for the other functions obviously :). >> >> That actually hasn't changed. We are currently passing a U-Boot >> address around and it is a ulong, as it normally is in U-Boot. What >> has changed is that sandbox does not have a direct mapping between >> U-Boot address and memory address, so we have to do the mapping. >> >> While it is try that the ulong can be converted to a pointer with a >> cast normally, this is not possible with sandbox, so things that need >> to convert the ulong to a pointer need to do a conversion. > > Oh, I missed the * in *current. So it already does get passed as a > number which then is cast back into a pointer. > > That however means that the smbios tables are now u-boot address space > relative. So anything that tries to read them from within EFI context > will explode. Aren't these tables for the Linux kernel? If so, then this doesn't matter. But if EFI reads them, we are in trouble. We cannot always put a 64-bit address into a 32-bit word. I suppose we could support it on 32-bit sandbox, but not a lot of people use that. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/13] efi: sandbox: Adjust memory usage for sandbox
Hi Alex,
On 12 June 2018 at 08:02, Alexander Graf wrote:
>
>
> On 12.06.18 15:48, Simon Glass wrote:
>> Hi Alex,
>>
>> On 12 June 2018 at 02:05, Alexander Graf wrote:
>>>
>>>
>>> On 12.06.18 07:26, Simon Glass wrote:
With sandbox the U-Boot code is not mapped into the sandbox memory range
so does not need to be excluded when allocating EFI memory. Update the EFI
memory init code to take account of that.
Also use mapmem instead of a cast to convert a memory address to a
pointer.
Signed-off-by: Simon Glass
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Update to use mapmem instead of a cast
lib/efi_loader/efi_memory.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index ec66af98ea..210e49ee8b 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int pool_type,
efi_uintn_t size, void **buffer)
);
if (r == EFI_SUCCESS) {
- struct efi_pool_allocation *alloc = (void *)(uintptr_t)t;
+ struct efi_pool_allocation *alloc = map_sysmem(t, size);
>>>
>>> We want to eventually be able to run efi binaries inside sandbox, so we
>>> need to expose a 1:1 memory map inside the efi interfaces.
>>>
>>> That means the memory argument of efi_allocate_pages() already needs to
>>> be set to the virtual address in real VA space. The easiest way to get
>>> there is if you just put virtual addresses in the efi memory map.
>>
>> Can you please explain that a bit more, or give a code example? I'm
>> not quite sure what you mean.
>
> In efi_add_known_memory() we populate the EFI memory table with
> addresses that EFI allocations can return. Because we don't control the
> payloads that call these functions, we can only return pointers. That
> means efi_add_known_memory() should add map_sysmem()'ed values into its
> own table.
>
> Basically while we expose "virtual 0 offset" addresses to the command
> line, anything internal still works on pointers. And everything EFI
> internal needs to be considered a pointer, because we don't control the
> code that deals with them.
>
> So in a nutshell, I mean something like this (untested, probably
> whitespace broken and line wrapped):
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index ec66af98ea..80211d8c95 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -491,6 +491,9 @@ __weak void efi_add_known_memory(void)
> u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
> u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
>
> + /* Sandbox needs virtual addresses here */
> + start = (uintptr_t)map_sysmem(start, pages * EFI_PAGE_SIZE);
> +
> efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
>false);
> }
>
The map_sysmem() call is already when allocated addresses are returned
- see elsewhere in the file. So adding it here as well will cause a
double translation. Still, I tried this out and it just fails to init.
Does any EFI app have access to the internal tables containing the
memory addresses? If not, then perhaps it is OK to use U-Boot
addresses here?
In any case Heinrich has mentioned an alignment problem that needs to
be resolved.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
On Tue, Jun 12, 2018 at 02:13:38PM -0500, Nishanth Menon wrote: > On Tue, May 22, 2018 at 9:05 AM, Fabio Estevam wrote: > > On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon wrote: > >> Hi Folks, > >> > >> This is a follow through on the discussion we have had in [1]. > >> This itself is'nt a complete solution and is based on recommendation > >> This from Arm[2] for variant 2 CVE-2017-5715 > >> > >> The Linux kernel discussions are spread out in [3], ATF and OPTEE > >> status are available in [4]. > >> > >> This is just an RFC series (build tested at this point) to check if > >> the direction is fine and should follow the final solution once kernel > >> patches get to upstream, IMHO. > >> > >> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM > >> Cortex-A9/12/17 do not need additional steps in u-boot to enable the > >> OS level workarounds. > >> > >> Nishanth Menon (2): > >> ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for > >> CVE-2017-5715 > >> ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for > >> CVE-2017-5715 > > > > I started respinning the series, while there is definitely a use of > implementing in u-boot, > I am starting to wonder if we should also be doing this in kernel. How does the kernel set the bit when the kernel is running in non-secure mode, when the ACTLR is read-only in that mode? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Raspberry Pi 3(+) / 64bit bug with saveenv
Yes, this patch works. Thanks a lot. Greets Pascal 2018-06-12 22:36 GMT+02:00 Alexander Graf : > > > On 12.06.18 20:21, Pascal Vizeli wrote: >> Hi, >> >> I see a strange problem with `saveenv` on Raspberry Pi 3 platform. >> Other Raspberry Pi (0/w/2) device work well with `saveenv`. >> >> After I call the `saveenv` command, the device going into `fsm 1, hsts >> 0001` loop. I try it with env file on ext/fat and on mmc. >> >> Here is the bug report: >> https://github.com/home-assistant/hassos/issues/28 >> >> Anyone see a problem like this before? > > Yes. This should be fixed by commit > 79fd08f7456c7d12b04ef39e51d84d9981599c3a. > > In other words, latest git (or 2018.07-rc1) should already contain the fix. > > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 0/3] Why netboot:
Hi Duncan, I tried a test of applying this series and the first patch doesn't apply cleanly and checkpatch complains about Missing or malformed SPDX-License-Identifier. Can you rebase on top of the current upstream master and resend? On Sun, May 20, 2018 at 6:41 PM, wrote: > From: Duncan Hare Is there a reason you are not using (what appears to be) your company email address in your git configuration? > > Central management, including logs and change control, > coupled with with enhanced security and unauthorized > change detection and remediation by exposing a > small attack surface. > > Why TCP with Selective Acknowledgement: > > Currently file transfer are done using tftp or NFS both > over udp. This requires a request to be sent from client > (u-boot) to the boot server. > > For a 4 Mbyte kernel, with a 1k block size this requires > 4,000 request for a block. > > Using a large block size, one greater than the Ethernet > maximum frame size limitation, would require fragmentation, > which u-boot supports. However missing fragment recovery > requires timeout detection and re-transmission requests > for missing fragments. > > UDP is ideally suited to fast single packet exchanges, > inquiry/response, for example dns, becuse of the lack of > connection overhead. > > UDP as a file transport mechanism is slow, even in low > latency networks, because file transfer with udp requires > poll/response mechanism to provide transfer integrity. > > In networks with large latency, for example: the internet, > UDP is even slower. What is a 30 second transfer on a local > boot server and LAN increase to over 3 minutes, because of > all the requests/response traffic. > > This was anticipated in the evolution of the IP protocols > and TCP was developed and then enhanced for high latency high > bandwidth networks. > > The current standard is TCP with selective acknowledgment. > > In our testing we have reduce kernel transmission time to > around 0.4 seconds for a 4Mbyte kernel, with a 100 Mbps > downlink. > > Why http and wget: > > HTTP is the most efficient file retrieval protocol in common > use. The client send a single request, after TCP connection, > to receive a file of any length. > > WGET is the application which implements http file transfer > outside browsers as a file transfer protocol. Versions of > wget exists on many operating systems. > > Changes in v11: > Add TCP with Selective Acknowledgement (SACK) > Adding wget > > Duncan Hare (3): > Adding TCP and wget into u-boot > Adding TCP > Add wget, for fast file transfer. > > cmd/Kconfig| 7 + > cmd/net.c | 13 + > include/net.h | 15 +- > include/net/tcp.h | 227 + > include/net/wget.h | 19 ++ > net/Kconfig| 6 + > net/Makefile | 2 + > net/net.c | 79 +- > net/ping.c | 9 +- > net/tcp.c | 700 > + > net/wget.c | 418 > 11 files changed, 1475 insertions(+), 20 deletions(-) > create mode 100644 include/net/tcp.h > create mode 100644 include/net/wget.h > create mode 100644 net/tcp.c > create mode 100644 net/wget.c > > -- > 2.11.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: Always align tx packets
On Wed, Mar 28, 2018 at 7:38 AM, Mario Six wrote: > Make sure that TX packets are always cache-aligned. > > Signed-off-by: Mario Six Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/5] include: reset: Change to use CONFIG_IS_ENABLED(DM_RESET)
On Mon, Jun 4, 2018 at 2:19 AM, Ley Foon Tan wrote:
> Change to use CONFIG_IS_ENABLED(DM_RESET), so this can work in SPL
> build (CONFIG_SPL_DM_RESET) and U-boot build (CONFIG_DM_RESET).
>
> Signed-off-by: Ley Foon Tan
> ---
> include/reset.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/reset.h b/include/reset.h
> index 201bafc..a7bbc1c 100644
> --- a/include/reset.h
> +++ b/include/reset.h
> @@ -77,7 +77,7 @@ struct reset_ctl_bulk {
> unsigned int count;
> };
>
> -#ifdef CONFIG_DM_RESET
> +#if CONFIG_IS_ENABLED(DM_RESET)
This seems like it would be more reasonable to squash into the first
patch of this series.
> /**
> * reset_get_by_index - Get/request a reset signal by integer index.
> *
> --
> 2.2.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/5] drivers: Add reset ctrl to drivers
On Mon, Jun 11, 2018 at 3:24 AM, Ley Foon Tan wrote: > On Sat, Jun 9, 2018 at 5:59 AM, Simon Glass wrote: >> Hi Ley Foon, >> >> On 3 June 2018 at 23:19, Ley Foon Tan wrote: >>> Add reset ctrl to dwmmc socfpga, designware Ethernet and ns16550 serial >>> drivers. >>> >>> A reset property is an optional feature, so only print out a warning and >>> do not fail if a reset property is not present. >>> >>> If a reset property is discovered, then use it to deassert, thus bringing >>> the >>> IP out of reset. >>> >>> v5 change: >>> - Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET >>> - Change to use CONFIG_IS_ENABLED(DM_RESET) in reset.h >>> - Added Simon's Reviewed-by in dwmmc, 16550 serial and designware emac >>> patches. >> >> I think it is better to also include the earlier change logs, Also you >> should have a change log on each patch as well as the cover letter. > Okay, I can resend this. Also, when you resend it, don't forget to include feedback you've already gotten. v5 has dropped my ack from v3 of net: designware: Add reset ctrl to driver. Also, if you want individual maintainers to take in part of a series like this, it's not very natural. While these are all related changes, they have no interdependencies. At very least, it seems like the network driver change could either stand alone (and not be in the series) or I should not be taking it by itself. You don't have to resend just to add responses you've gotten, but if you do resend for another reason, you need to add the feedback you've gotten on earlier version (as long as they still apply). -Joe >> >> The patman tool does this for you, so I suggest you take a look at that. >> >>> >>> History: >>> v1: https://patchwork.ozlabs.org/cover/905519/ >>> v2: https://patchwork.ozlabs.org/cover/908667/ >>> v3: https://patchwork.ozlabs.org/cover/910018/ >>> v4: https://patchwork.ozlabs.org/cover/923883/ >>> >>> Ley Foon Tan (5): >>> reset: Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET >>> include: reset: Change to use CONFIG_IS_ENABLED(DM_RESET) >>> mmc: dwmmc: socfpga: Add reset ctrl to driver >>> serial: ns16550: Add reset ctrl to driver >>> net: designware: Add reset ctrl to driver >>> >>> arch/arm/mach-stm32mp/Kconfig | 2 +- >>> common/spl/Kconfig| 2 +- >>> drivers/Makefile | 2 +- >>> drivers/mmc/socfpga_dw_mmc.c | 17 + >>> drivers/net/designware.c | 8 >>> drivers/serial/ns16550.c | 8 >>> include/reset.h | 2 +- >>> 7 files changed, 37 insertions(+), 4 deletions(-) >>> >>> -- >>> 2.2.2 >>> > Regards > Ley Foon > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] net: designware: Add reset ctrl to driver
On Wed, May 23, 2018 at 9:22 PM, Ley Foon Tan wrote: > On Wed, May 16, 2018 at 5:08 AM, Joe Hershberger > wrote: >> On Mon, May 7, 2018 at 10:19 PM, Ley Foon Tan wrote: >>> Add code to reset all reset signals as in Ethernet DT node. A reset >>> property is an optional feature, >>> so only print out a warning and do not fail if a reset property is not >>> present. >>> >>> If a reset property is discovered, then use it to deassert, thus bringing >>> the >>> IP out of reset. >>> >>> Signed-off-by: Ley Foon Tan >> >> Acked-by: Joe Hershberger > > Hi Joe > > Will you merge this patch to mainline? OK... it was assigned to Tom in patchwork, but I moved it to me. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: add Socionext AVE ethernet driver support
On Thu, May 24, 2018 at 5:24 AM, Kunihiko Hayashi wrote: > Add driver for Socionext AVE ethernet controller that includes MAC and > MDIO bus supporting RGMII/RMII modes. > The driver behaves the ethernet driver model (DM_ETH) with devicetree. > > This patch requires the internal phy definition [1]. > [1] http://patchwork.ozlabs.org/patch/915965/ > > Signed-off-by: Kunihiko Hayashi > Signed-off-by: Masahiro Yamada Looks great! Acked-by: Joe Hershberger > --- > drivers/net/Kconfig | 10 + > drivers/net/Makefile | 1 + > drivers/net/sni_ave.c | 995 > ++ > 3 files changed, 1006 insertions(+) Any plan to enable this driver in a defconfig so that it is build tested? Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y
> From: Heinrich Schuchardt > Date: Tue, 12 Jun 2018 20:00:28 +0200 > > On 06/12/2018 07:27 PM, Mark Kettenis wrote: > > This series makes it possible to run EFI applications in non-secure > > mode. It allows me to run OpenBSD on the imx7d-pico-pi board while > > using the PSCI implementation provided by U-Boot. > > > > Mark Kettenis (3): > > ARM: HYP/non-sec: save and restore stack > > efi_loader: ARM: run EFI payloads non-secure > > Revert "efi_loader: no support for ARMV7_NONSEC=y" > > > > arch/arm/cpu/armv7/nonsec_virt.S | 6 -- > > cmd/bootefi.c| 32 > > doc/README.uefi | 2 -- > > lib/efi_loader/Kconfig | 2 -- > > 4 files changed, 36 insertions(+), 6 deletions(-) > > > > This is the output I got with your patches when trying to boot my BananaPi: > > => bootefi hello > Scanning disk m...@01c0f000.blk... > Found 3 disks > WARNING: booting without device tree > ## Starting EFI application at 4200 ... > WARNING: using memory device/image path, this may confuse some payloads! > > U-Boot SPL 2018.07-rc1-D001-00104-g5b859da7ca8 (Jun 12 2018 - 19:52:34 > +0200) > DRAM: > > Where able to run bootefi hello on your board? I can run helloworld.efi on my board with this diff. > Which board are you on? Technexion PICO-PI-IMX7; it's a board with an i.MX7D SoC. I have a Banana Pi as well, so I'll give that one a go tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Raspberry Pi 3(+) / 64bit bug with saveenv
On 12.06.18 20:21, Pascal Vizeli wrote: > Hi, > > I see a strange problem with `saveenv` on Raspberry Pi 3 platform. > Other Raspberry Pi (0/w/2) device work well with `saveenv`. > > After I call the `saveenv` command, the device going into `fsm 1, hsts > 0001` loop. I try it with env file on ext/fat and on mmc. > > Here is the bug report: > https://github.com/home-assistant/hassos/issues/28 > > Anyone see a problem like this before? Yes. This should be fixed by commit 79fd08f7456c7d12b04ef39e51d84d9981599c3a. In other words, latest git (or 2018.07-rc1) should already contain the fix. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: HYP/non-sec: save and restore stack
On 12.06.18 22:17, Mark Kettenis wrote: >> From: Alexander Graf >> Date: Tue, 12 Jun 2018 20:46:02 +0200 >> >> On 12.06.18 19:27, Mark Kettenis wrote: >>> The current code that switches into HYP mode doesn't bother to set >>> up a stack for HYP mode. This doesn't work for EFI applications >>> as they expect a usable stack. Fix this by saving the stack >>> pointer before switching and use it to set SP_hyp from monitor. >>> This restores the stack pointer when we drop into HYP mode. >>> >>> Signed-off-by: Mark Kettenis >> >> Can we be sure that the stack in MON is usable from HYP? > > I think so. It is the stack that U-Boot sets up for itself in normal > memory. As far as I can tell arm64 re-uses this stack when dropping > down into EL2 as well. Well, the question is whether it's secure or non-secure memory. Usually the DRAM controller can be configured to have a window of RAM only available to secure and I'd certainly hope that at least the U-Boot parts that are preserved in EL3 live in such a secured area :) Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 15/18] net: fastboot: Merge AOSP UDP fastboot
On Tue, May 29, 2018 at 10:30 AM, Alex Kiernan wrote: > Merge UDP fastboot support from AOSP: > > > https://android.googlesource.com/platform/external/u-boot/+/android-o-mr1-iot-preview-8 > > Signed-off-by: Alex Kiernan > Signed-off-by: Alex Deymo > Signed-off-by: Jocelyn Bohr > Reviewed-by: Simon Glass Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715
As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the right
locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html
Cc: Marc Zyngier
Cc: Russell King
Cc: Tony Lindgren
Cc: Robin Murphy
Cc: Florian Fainelli
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Christoffer Dall
Cc: Andre Przywara
Cc: Ard Biesheuvel
Cc: Tom Rini
Cc: Michael Nazzareno Trimarchi
Signed-off-by: Nishanth Menon
---
arch/arm/Kconfig | 5 +
arch/arm/cpu/armv7/start.S | 7 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422bc5d53..9e32d5b43cb0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -108,6 +108,8 @@ config SYS_ARM_MPU
# CONFIG_ARM_ERRATA_621766
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
+# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+
config ARM_ERRATA_430973
bool
@@ -177,6 +179,9 @@ config ARM_ERRATA_852423
config ARM_ERRATA_855873
bool
+config ARM_CORTEX_A8_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index c996525f861e..3beaf5a93d81 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -252,12 +252,15 @@ skip_errata_801819:
pop {r1-r5} @ Restore the cpu info - fall through
#endif
-#ifdef CONFIG_ARM_ERRATA_430973
+#if defined(CONFIG_ARM_ERRATA_430973) || defined
(CONFIG_ARM_CORTEX_A8_CVE_2017_5715)
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+#ifdef CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+ orr r0, r0, #(0x1 << 6) @ Set IBE bit always to enable OS WA
+#else
cmp r2, #0x21 @ Only on < r2p1
orrlt r0, r0, #(0x1 << 6) @ Set IBE bit
-
+#endif
push{r1-r5} @ Save the cpu info registers
bl v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
be done unconditionally for Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the
right locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
Cc: Marc Zyngier
Cc: Russell King
Cc: Tony Lindgren
Cc: Robin Murphy
Cc: Florian Fainelli
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Christoffer Dall
Cc: Andre Przywara
Cc: Ard Biesheuvel
Cc: Tom Rini
Cc: Michael Nazzareno Trimarchi
Signed-off-by: Nishanth Menon
---
arch/arm/Kconfig | 4
arch/arm/cpu/armv7/start.S | 8
2 files changed, 12 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9e32d5b43cb0..98f58fd27696 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -109,6 +109,7 @@ config SYS_ARM_MPU
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
config ARM_ERRATA_430973
bool
@@ -182,6 +183,9 @@ config ARM_ERRATA_855873
config ARM_CORTEX_A8_CVE_2017_5715
bool
+config ARM_CORTEX_A15_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 3beaf5a93d81..81edec01bf32 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -241,6 +241,14 @@ skip_errata_798870:
skip_errata_801819:
#endif
+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
+ orr r0, r0, #1 << 0 @ Enable invalidates of BTB
+ push{r1-r5} @ Save the cpu info registers
+ bl v7_arch_cp15_set_acr
+ pop {r1-r5} @ Restore the cpu info - fall through
+#endif
+
#ifdef CONFIG_ARM_ERRATA_454179
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
Hi, This is a follow on from https://marc.info/?l=u-boot=151691688828176=2 (RFC) NOTE: * As per ARM recommendations[2], and discussions in list[1] ARM Cortex-A9/12/17 do not need additional steps in u-boot to enable the OS level workarounds. * This itself is'nt a complete solution and is based on recommendation This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag). * I think it is necessary on older SoCs without firmware support (such as older OMAPs and AM*) to have kernel support mirroring what we do in u-boot to support additional cores AND/OR low power states where contexts are lost (assuming ACR states are'nt saved). just my 2 cents. Few of the tests (with linux next-20180612): AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15) OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15) OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8) AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8) Nishanth Menon (4): ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715 ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715 ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for CVE-2017-5715 arch/arm/Kconfig| 9 + arch/arm/cpu/armv7/start.S | 15 +-- arch/arm/mach-omap2/Kconfig | 3 +++ 3 files changed, 25 insertions(+), 2 deletions(-) [1] https://marc.info/?t=15163990652=1=2 [2] https://developer.arm.com/support/security-update [3] https://marc.info/?t=15154379047=1=2 and the latest in: https://marc.info/?l=linux-arm-kernel=151689379521082=2 [4] https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 https://www.op-tee.org/security-advisories/ https://www.linaro.org/blog/meltdown-spectre/ -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr function to setup the bits, we are able to override the settings. Without this enabled, Linux kernel reports: CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable With this enabled, Linux kernel reports: CPU0: Spectre v2: using ICIALLU workaround NOTE: This by itself does not enable the workaround for CPU1 (on OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches. Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3bb1ecb58de0..77820cc8d1e4 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -53,6 +53,7 @@ config OMAP54XX bool "OMAP54XX SoC" select ARM_ERRATA_798870 select SYS_THUMB_BUILD + select ARM_CORTEX_A15_CVE_2017_5715 imply NAND_OMAP_ELM imply NAND_OMAP_GPMC imply SPL_DISPLAY_PRINT -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for CVE-2017-5715
Enable CVE-2017-5715 option to set the IBE bit. This enables kernel workarounds necessary for the said CVE. With this enabled, Linux reports: CPU0: Spectre v2: using BPIALL workaround This workaround may need to be re-applied in OS environment around low power transition resume states where context of ACR would be lost (off-mode etc). Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 77820cc8d1e4..f4babc8d2600 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -10,6 +10,7 @@ config OMAP34XX select ARM_ERRATA_454179 select ARM_ERRATA_621766 select ARM_ERRATA_725233 + select ARM_CORTEX_A8_CVE_2017_5715 select USE_TINY_PRINTF imply NAND_OMAP_GPMC imply SPL_EXT_SUPPORT @@ -116,6 +117,7 @@ config AM43XX config AM33XX bool "AM33XX SoC" select SPECIFY_CONSOLE_INDEX + select ARM_CORTEX_A8_CVE_2017_5715 imply NAND_OMAP_ELM imply NAND_OMAP_GPMC imply SPL_NAND_AM33XX_BCH -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: HYP/non-sec: save and restore stack
> From: Alexander Graf
> Date: Tue, 12 Jun 2018 20:46:02 +0200
>
> On 12.06.18 19:27, Mark Kettenis wrote:
> > The current code that switches into HYP mode doesn't bother to set
> > up a stack for HYP mode. This doesn't work for EFI applications
> > as they expect a usable stack. Fix this by saving the stack
> > pointer before switching and use it to set SP_hyp from monitor.
> > This restores the stack pointer when we drop into HYP mode.
> >
> > Signed-off-by: Mark Kettenis
>
> Can we be sure that the stack in MON is usable from HYP?
I think so. It is the stack that U-Boot sets up for itself in normal
memory. As far as I can tell arm64 re-uses this stack when dropping
down into EL2 as well.
> > ---
> > arch/arm/cpu/armv7/nonsec_virt.S | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S
> > b/arch/arm/cpu/armv7/nonsec_virt.S
> > index 56bdba1d38..246d817340 100644
> > --- a/arch/arm/cpu/armv7/nonsec_virt.S
> > +++ b/arch/arm/cpu/armv7/nonsec_virt.S
> > @@ -52,9 +52,9 @@ _secure_monitor:
> > bl psci_stack_setup
> >
> > @ Configure the PSCI backend
> > - push{r0, r1, r2, ip}
> > + push{r0, r1, r2, r3, ip}
> > bl psci_arch_init
> > - pop {r0, r1, r2, ip}
> > + pop {r0, r1, r2, r3, ip}
> > #endif
> >
> > #ifdef CONFIG_ARM_ERRATA_773022
> > @@ -80,6 +80,7 @@ _secure_monitor:
> > #ifdef CONFIG_ARMV7_VIRT
> > orreq r5, r5, #0x100 @ allow HVC instruction
> > moveq r6, #HYP_MODE @ Enter the kernel as HYP
> > + msreq sp_hyp, r3 @ restore saved stack
> > #endif
> >
> > mcr p15, 0, r5, c1, c1, 0 @ write SCR (with NS bit set)
> > @@ -106,6 +107,7 @@ ENTRY(_do_nonsec_entry)
> > mov r0, r1
> > mov r1, r2
> > mov r2, r3
> > + mov r3, sp
> > smc #0
> > ENDPROC(_do_nonsec_entry)
> >
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
