Re: [U-Boot] [PATCH v2 2/2] video: dw_hdmi: fix HSYNC and VSYNC polarity settings

[Jernej Škrabec]

Hi,

Dne ponedeljek, 14. maj 2018 ob 22:49:53 CEST je Vasily Khoruzhick napisal(a):
> Currently dw_hdmi configures HSYNC polarity using VSYNC setting from
> EDID and vice versa. Fix it, since it breaks displays where HSYNC
> and VSYNC polarity differs
> 
> Signed-off-by: Vasily Khoruzhick 

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

> ---
>  drivers/video/dw_hdmi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/dw_hdmi.c b/drivers/video/dw_hdmi.c
> index dbad0e2b24..229bd63c97 100644
> --- a/drivers/video/dw_hdmi.c
> +++ b/drivers/video/dw_hdmi.c
> @@ -401,11 +401,11 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>   /* set up hdmi_fc_invidconf */
>   inv_val = HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE;
> 
> - inv_val |= (edid->flags & DISPLAY_FLAGS_HSYNC_HIGH ?
> + inv_val |= (edid->flags & DISPLAY_FLAGS_VSYNC_HIGH ?
>  HDMI_FC_INVIDCONF_VSYNC_IN_POLARITY_ACTIVE_HIGH :
>  HDMI_FC_INVIDCONF_VSYNC_IN_POLARITY_ACTIVE_LOW);
> 
> - inv_val |= (edid->flags & DISPLAY_FLAGS_VSYNC_HIGH ?
> + inv_val |= (edid->flags & DISPLAY_FLAGS_HSYNC_HIGH ?
>  HDMI_FC_INVIDCONF_HSYNC_IN_POLARITY_ACTIVE_HIGH :
>  HDMI_FC_INVIDCONF_HSYNC_IN_POLARITY_ACTIVE_LOW);
> 
> --
> 2.17.0




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] sunxi: video: HDMI: use correct bits for HSYNC and VSYNC polarity.

[Jernej Škrabec]

Hi!

Dne ponedeljek, 14. maj 2018 ob 22:49:52 CEST je Vasily Khoruzhick napisal(a):
> HSYNC is bit 8, and VSYNC is bit 9.
> 
> Signed-off-by: Vasily Khoruzhick 

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

> ---
>  drivers/video/sunxi/sunxi_dw_hdmi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
> b/drivers/video/sunxi/sunxi_dw_hdmi.c index c78e33b947..9dbea649a0 100644
> --- a/drivers/video/sunxi/sunxi_dw_hdmi.c
> +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
> @@ -303,10 +303,10 @@ static int sunxi_dw_hdmi_enable(struct udevice *dev,
> int panel_bpp,
> 
>   sunxi_dw_hdmi_lcdc_init(priv->mux, edid, panel_bpp);
> 
> - if (edid->flags & DISPLAY_FLAGS_HSYNC_LOW)
> + if (edid->flags & DISPLAY_FLAGS_VSYNC_LOW)
>   setbits_le32(>pol, 0x200);
> 
> - if (edid->flags & DISPLAY_FLAGS_VSYNC_LOW)
> + if (edid->flags & DISPLAY_FLAGS_HSYNC_LOW)
>   setbits_le32(>pol, 0x100);
> 
>   setbits_le32(>ctrl, 0xf << 12);
> --
> 2.17.0




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] arm: Raspberry Pi Compile warnings

[Duncan Hare]

Hi Simon

Is this is problem?

arch/arm/dts/bcm2835-rpi-a-plus.dtb: Warning (phys_property): Missing
property '#phy-cells' in node /phy or bad phandle (referred
from /soc/usb@7e98:phys[0])

repeated about 6 - 8 times

make[2]:'arch/arm/dts/bcm2837-rpi-3-b.dtb' is up to date.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: mvebu: a38x: Add missing SPDX license identfier

[Chris Packham]

mv_ddr_build_message.c is generated in Marvell's standalone mv_ddr code.
When imported into u-boot we need to add the appropriate SPDX tag and
re-format it slightly.

Signed-off-by: Chris Packham 
---

 drivers/ddr/marvell/a38x/mv_ddr_build_message.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_build_message.c 
b/drivers/ddr/marvell/a38x/mv_ddr_build_message.c
index 8e60448318f2..2b49b77f7306 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_build_message.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_build_message.c
@@ -1 +1,3 @@
-const char mv_ddr_build_message[] = "";   const char 
mv_ddr_version_string[] = "mv_ddr: mv_ddr-armada-17.10.4";
+// SPDX-License-Identifier: GPL-2.0
+const char mv_ddr_build_message[] = "";
+const char mv_ddr_version_string[] = "mv_ddr: mv_ddr-armada-17.10.4";
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-marvell/master

[Chris Packham]

Hi Tom, Stefan,

On Tue, May 15, 2018 at 3:16 AM Stefan Roese  wrote:

> Hi Tom,

> (Cc'ing Chris)

> On 14.05.2018 17:11, Tom Rini wrote:
> > On Mon, May 14, 2018 at 01:58:59PM +0200, Stefan Roese wrote:
> >
> >> Hi Tom,
> >>
> >> please pull the following MVEBU related patches from Marek and
> >> Chris.
> >>
> >> Thanks,
> >> Stefan
> >>
> >> The following changes since commit
62d77cea31216cad526e5f45c88e8377efc6fcae:
> >>
> >>mmc: Improve tinification (2018-05-13 07:57:32 -0400)
> >>
> >> are available in the Git repository at:
> >>
> >>git://www.denx.de/git/u-boot-marvell.git
> >>
> >> for you to fetch changes up to
ca734a875dec089c3978663a0ce303d776365b20:
> >>
> >>phy: marvell: a3700: Fix compatible string for ehci (2018-05-14
10:01:56 +0200)
> >>
> >
> > Applied to u-boot/master.
> >
> > But please note that drivers/ddr/marvell/a38x/mv_ddr_build_message.c is
> > both missing an SPDX tag and oddly formatted.  I assume there's a good
> > reason those two variables exist in the way they do and that we can't
> > just fold that into some other files, so please look into what the
> > correct SPDX tag and copyright line should be for that content, thanks!

> Thanks Tom, I didn't spot this.

> Chris, I assume that we need this file (this way) for compatibility
> (potential later re-sync) with the Marvell code? Is this correct?
> Or could this be done in a different way? Please check and add the
> SPDX tag and copyright line as requested by Tom.

Yeah it is an oddity. In Marvell's version of the code that file is
actually generated[1] based on the tags/commit id. Which when ported to
u-boot loses some of it's meaning (saying "mv_ddr-armada-17.10.4" is still
helpful to identify which upstream tag we're in sync with). I looked at
folding it into the code but that just increases the delta with the
original upstream code. I'll send a patch to add a SPDX license line to the
top of the file and re-format it.

--
[1] -
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/blob/mv_ddr-armada-17.02/Makefile#L174
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PULL] Please pull u-boot-rockchip/master

[Tom Rini]

On Mon, May 14, 2018 at 05:32:25PM +0200, Dr. Philipp Tomsich wrote:

> Tom,
> 
> I have two fixes for regressions (that unfortunately ended up in the last 
> release) in my tree,
> ready for a merge onto master.
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit ca70cbabdcd19bf157ae4fa984559b126071ccff:
> 
>   Merge git://git.denx.de/u-boot-marvell (2018-05-14 08:52:48 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to ed1030e1523541801ae1e36bc34ee6872d474184:
> 
>   rockchip: clk: rk3288: handle clk_enable requests for GMAC (2018-05-14 
> 17:30:40 +0200)
> 

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

[U-Boot] [PATCH] arm: zynq: Add initial support for Avnet MiniZed

[Ibai Erkiaga]

Initial support for Avnet MiniZed board. Tested UART1 (serial console),
QSPI(Flash), SDHCI1 (eMMC), USB.

Signed-off-by: Ibai Erkiaga 
---
Changes for v3:
-dts formating refactor
-CONFIG_DISPLAY_CPUINFO removed from config
-CONFIG_OF_EMBED removed from config

Changes for v2:
-board model changed to use Avent prefix
-usb phy driver changed usb-no-xceiv
-removed gpio and intc binding
-fixed-partitions usage
---
 arch/arm/dts/Makefile  |1 +
 arch/arm/dts/zynq-minized.dts  |  106 
 configs/zynq_minized_defconfig |   66 +
 3 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/dts/zynq-minized.dts
 create mode 100644 configs/zynq_minized_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7bec3d6..f7b33f9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-cc108.dtb \
zynq-cse-qspi-single.dtb \
zynq-microzed.dtb \
+   zynq-minized.dtb \
zynq-picozed.dtb \
zynq-syzygy-hub.dtb \
zynq-topic-miami.dtb \
diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts
new file mode 100644
index 000..525921e
--- /dev/null
+++ b/arch/arm/dts/zynq-minized.dts
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * dts file for Avnet MiniZed board
+ *
+ * (C) Copyright 2017 - 2018, Xilinx, Inc.
+ *
+ * Ibai Erkiaga 
+ */
+
+/dts-v1/;
+#include "zynq-7000.dtsi"
+
+/ {
+   model = "Avnet Zynq MiniZed Development Board";
+   compatible = "avnet,minized", "xlnx,zynq-7000";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   spi0 = 
+   mmc0 = 
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x2000>;
+   };
+
+   chosen {
+   bootargs = "";
+   stdout-path = "serial0:115200n8";
+   };
+
+   usb_phy0: phy0 {
+   compatible = "usb-nop-xceiv";
+   #phy-cells = <0>;
+   };
+};
+
+ {
+   status = "okay";
+   is-dual = <0>;
+   num-cs = <1>;
+   flash@0 {
+   compatible = "micron,m25p128";
+   reg = <0x0>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <5000>;
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   partition@0 {
+   label = "boot";
+   reg = <0x0 0xff>;
+   };
+
+   partition@27 {
+   label = "kernel";
+   reg = <0x27 0xd8>;
+   };
+
+   partition@ff {
+   label = "bootenv";
+   reg = <0xff 0x1>;
+   };
+
+   partition@100 {
+   label = "spare";
+   reg = <0x100 0x0>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   dr_mode = "host";
+   usb-phy = <_phy0>;
+   usb-reset = < 7 0>; /* USB_RST_N-MIO7 */
+};
+
+ {
+   status = "okay";
+   non-removable;
+   bus-width = <4>;
+   max-frequency = <1200>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mmccard: mmccard@0 {
+   compatible = "mmc-card";
+   reg = <0>;
+   broken-hpi;
+   };
+};
diff --git a/configs/zynq_minized_defconfig b/configs/zynq_minized_defconfig
new file mode 100644
index 000..8cf3215
--- /dev/null
+++ b/configs/zynq_minized_defconfig
@@ -0,0 +1,66 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ZYNQ=y
+CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_SPL=y
+CONFIG_SPL_STACK_R_ADDR=0x20
+CONFIG_DEFAULT_DEVICE_TREE="zynq-minized"
+CONFIG_DEBUG_UART=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_BOOTCOMMAND="run $modeboot || run distro_bootcmd"
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_OS_BOOT=y
+CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_THOR_DOWNLOAD=y
+CONFIG_CMD_DFU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_FPGA_LOADBP=y
+CONFIG_CMD_FPGA_LOADFS=y
+CONFIG_CMD_FPGA_LOADMK=y
+CONFIG_CMD_FPGA_LOADP=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y

[U-Boot] [PATCH] arm: zynq: Add initial support for Avnet MiniZed

[Ibai Erkiaga]

Initial support for Avnet MiniZed board. Tested UART1 (serial console),
QSPI(Flash), SDHCI1 (eMMC), USB.

Signed-off-by: Ibai Erkiaga 
---
 arch/arm/dts/Makefile  |1 +
 arch/arm/dts/zynq-minized.dts  |  106 
 configs/zynq_minized_defconfig |   66 +
 3 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/dts/zynq-minized.dts
 create mode 100644 configs/zynq_minized_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7bec3d6..f7b33f9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-cc108.dtb \
zynq-cse-qspi-single.dtb \
zynq-microzed.dtb \
+   zynq-minized.dtb \
zynq-picozed.dtb \
zynq-syzygy-hub.dtb \
zynq-topic-miami.dtb \
diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts
new file mode 100644
index 000..525921e
--- /dev/null
+++ b/arch/arm/dts/zynq-minized.dts
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * dts file for Avnet MiniZed board
+ *
+ * (C) Copyright 2017 - 2018, Xilinx, Inc.
+ *
+ * Ibai Erkiaga 
+ */
+
+/dts-v1/;
+#include "zynq-7000.dtsi"
+
+/ {
+   model = "Avnet Zynq MiniZed Development Board";
+   compatible = "avnet,minized", "xlnx,zynq-7000";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   spi0 = 
+   mmc0 = 
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x2000>;
+   };
+
+   chosen {
+   bootargs = "";
+   stdout-path = "serial0:115200n8";
+   };
+
+   usb_phy0: phy0 {
+   compatible = "usb-nop-xceiv";
+   #phy-cells = <0>;
+   };
+};
+
+ {
+   status = "okay";
+   is-dual = <0>;
+   num-cs = <1>;
+   flash@0 {
+   compatible = "micron,m25p128";
+   reg = <0x0>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <5000>;
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   partition@0 {
+   label = "boot";
+   reg = <0x0 0xff>;
+   };
+
+   partition@27 {
+   label = "kernel";
+   reg = <0x27 0xd8>;
+   };
+
+   partition@ff {
+   label = "bootenv";
+   reg = <0xff 0x1>;
+   };
+
+   partition@100 {
+   label = "spare";
+   reg = <0x100 0x0>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   dr_mode = "host";
+   usb-phy = <_phy0>;
+   usb-reset = < 7 0>; /* USB_RST_N-MIO7 */
+};
+
+ {
+   status = "okay";
+   non-removable;
+   bus-width = <4>;
+   max-frequency = <1200>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mmccard: mmccard@0 {
+   compatible = "mmc-card";
+   reg = <0>;
+   broken-hpi;
+   };
+};
diff --git a/configs/zynq_minized_defconfig b/configs/zynq_minized_defconfig
new file mode 100644
index 000..8cf3215
--- /dev/null
+++ b/configs/zynq_minized_defconfig
@@ -0,0 +1,66 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ZYNQ=y
+CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_SPL=y
+CONFIG_SPL_STACK_R_ADDR=0x20
+CONFIG_DEFAULT_DEVICE_TREE="zynq-minized"
+CONFIG_DEBUG_UART=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_BOOTCOMMAND="run $modeboot || run distro_bootcmd"
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_OS_BOOT=y
+CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_THOR_DOWNLOAD=y
+CONFIG_CMD_DFU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_FPGA_LOADBP=y
+CONFIG_CMD_FPGA_LOADFS=y
+CONFIG_CMD_FPGA_LOADMK=y
+CONFIG_CMD_FPGA_LOADP=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_FPGA_XILINX=y
+CONFIG_FPGA_ZYNQPL=y
+CONFIG_DM_GPIO=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ZYNQ=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHY_MARVELL=y

Re: [U-Boot] [PATCH 2/2] ARM: Add a new arch + board for QEMU's 'virt' machine

[Tuomas Tynkkynen]

Hi,

On Wed, 9 May 2018 12:56:46 +0200
Paulo Neves  wrote:

> Hello I have successfully built u-boot and launched qemu with the
> flags proposed by the patch. My problems start when I try to boot the
> kernel
> 
> What is the linux kernel defconfig that should be used to boot this
> machine?

multi_v7_defconfig does work at least.

> I tried the versatile one but they are different in some key
> places like the sd card. The end result is that I can only see
> Starting Kernel, and nothing else. What bootargs do you pass to the
> kernel to have the serial output in qemu?

The serial port in Linux is ttyAMA0. But I think it works without any
console= specified as well, because the QEMU-generated dtb specifies
/chosen/stdout-path already pointing to that serial port.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] block: Have BLOCK_CACHE default to y in some cases

[Tom Rini]

When dealing with filesystems that come from block devices we can get a
noticeable performance gain in some use cases from having the block
cache enabled.  Do so by default for btrfs/ext4/FAT.

Signed-off-by: Tom Rini 
---
In general this grows U-Boot itself by ~2KiB and does grow SPL by ~540
bytes when we have it present.  This is only seemingly true when we have
CONFIG_SPL_BLK and in turn block devices and filesystems.  I'm not
opposed to introducing CONFIG_SPL_BLOCK_CACHE down the line if needed,
but I don't think we need it to start with.
---
 drivers/block/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 15fd1bcb2b7e..a7f4bbfb7bb9 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -29,7 +29,8 @@ config SPL_BLK
 
 config BLOCK_CACHE
bool "Use block device cache"
-   default n
+   depends on BLK
+   default y if FS_BTRFS || FS_EXT4 || FS_FAT
help
  This option enables a disk-block cache for all block devices.
  This is most useful when accessing filesystems under U-Boot since
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Makefile: adopt --std=gnu11 for HOSTCFLAGS on Linux

[Tom Rini]

On Mon, May 14, 2018 at 10:58:49PM +0200, Mark Kettenis wrote:
> > Date: Mon, 14 May 2018 10:57:12 -0400
> > From: Tom Rini 
> > 
> > On Mon, May 14, 2018 at 04:53:49PM +0200, Mark Kettenis wrote:
> > > > From: Philipp Tomsich 
> > > > Date: Mon, 14 May 2018 15:22:06 +0200
> > > > 
> > > > Following the conversion of the SPDX license tags, a number of files
> > > > compiled with -pedantic now generate warnings similar to the following
> > > > for using C99-style '//' comments in ISO C90 code:
> > > > 
> > > >   tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed 
> > > > in ISO C90
> > > >// SPDX-License-Identifier: GPL-2.0+
> > > >^
> > > > 
> > > > The SPDX comment-style change means that these files have adopted C99,
> > > > so need to change the language-standard to --std=gnu99 or --std=gnu11
> > > > to let the compiler know this.
> > > > 
> > > > As we now require GCC 6 or newer for the cross-compiler, the project has
> > > > implicitly moved the project to GNU11: let older GCC versions on various
> > > > Linux distros know to treat our host tools as GNU11 as well.
> > > 
> > > Note that the requirement is on the cross-compiler, not the host
> > > compiler.  On our "primary" architectures OpenBSD 6.3 ships with Clang
> > > 5.0.1 and the current development version uses Clang 6.0.0, which
> > > default to --std=gnu11.  I do hope those will continue to be supported
> > > as the host compiler...
> > 
> > Does Clang 5.0.1 support gnu11 ?  Note that at this point we're not even
> > talking about moving to GNU11 features being used anywhere, just
> > enforcing consistency between modern (post gcc-5) and old (gcc-4.x)
> > compilers all in order to not have // style comments be a warning (which
> > in turn is a C99/gnu99 thing).  Thanks!
> 
> Yes.  Both Clang 5.0.1 and Clang 6.0.0 support gnu11 and even default to it.
> 
> If tere is no intention to use C11 features (and frankly I don't think
> C11 offers any significant benefits over C99), it'd make more sense to
> add --std=gnu99 instead of --std=gnu11 wouldn't it?  That would
> actually catch accidental use of C11 features.

Mostly because as I read more about the differences, I'm not sure
there's a good reason to artificially limit ourselves.  As a matter of
style, https://www.denx.de/wiki/U-Boot/CodingStyle is mostly correct and
just needs to be clarified when we deviate from "Linux kernel style".

And outside of comment style, being able to do:
for (int i = 0; i ... )
and declaring variables when used (within reason) are the only things
were are hard NO during the gnu89 days and we sometimes do now and could
maybe do more of now.   We need to tell older compilers we're doing
something newer, but I don't think we need to limit ourselves.

But I'm quite open to further discussion on this point.  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] arm: socfpga: fix CONFIG_SPL_MAX_SIZE (less than SRAM)

[Marek Vasut]

On 05/14/2018 11:02 PM, Simon Goldschmidt wrote:
> The boot ROMs of the socfpga platform limit the size of the
> SPL to copy to less than the available SRAM.
> (See "Intel SoC FPGA Embedded Development Suite User Guide")
> 
> According to this document, Cyclone V and Arria V allow 60KB
> maximum while Arria 10 allows 200KB. In both cases, this is
> less than CONFIG_SYS_INIT_RAM_SIZE.

Do they really copy less ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: correctly reserve SRAM for boot counter

[Marek Vasut]

On 05/14/2018 10:58 PM, Goldschmidt Simon wrote:
> Bootcounter for is1 and sr1500 boards somewhat relied on struct global data 
> alignment gap
> at the end of internal SRAM. Let's fix this by explicitly reserving some 
> bytes.
> 
> Signed-off-by: Simon Goldschmidt 

This should be reserved somewhere in the common memory reservation code.
That's what that code is there for IMO. Add a __weak function to reserve
more space if needed.

> ---
>  include/configs/socfpga_common.h | 6 +-
>  include/configs/socfpga_is1.h| 3 ++-
>  include/configs/socfpga_sr1500.h | 3 ++-
>  3 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index 4de2aa7929..1934aea86d 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -35,8 +35,12 @@
>  #define CONFIG_SYS_INIT_RAM_ADDR 0xFFE0
>  #define CONFIG_SYS_INIT_RAM_SIZE 0x4 /* 256KB */
>  #endif
> +/* Reserve bytes at the end of SRAM? */
> +#ifndef SOCFPGA_INIT_RAM_END_RESERVE
> +#define SOCFPGA_INIT_RAM_END_RESERVE 0
> +#endif
>  #define CONFIG_SYS_INIT_SP_OFFSET\
> - (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
> + (CONFIG_SYS_INIT_RAM_SIZE - SOCFPGA_INIT_RAM_END_RESERVE)
>  #define CONFIG_SYS_INIT_SP_ADDR  \
>   (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
>  
> diff --git a/include/configs/socfpga_is1.h b/include/configs/socfpga_is1.h
> index c233c208a5..b243fd29cd 100644
> --- a/include/configs/socfpga_is1.h
> +++ b/include/configs/socfpga_is1.h
> @@ -27,8 +27,9 @@
>  #include 
>  
>  /*
> - * Bootcounter
> + * Bootcounter (preserve the last 2 lwords for the boot-counter)
>   */
> +#define CONFIG_SYS_INIT_RAM_END_RESERVE  8
>  #define CONFIG_SYS_BOOTCOUNT_BE
>  
>  #endif   /* __CONFIG_SOCFPGA_IS1_H__ */
> diff --git a/include/configs/socfpga_sr1500.h 
> b/include/configs/socfpga_sr1500.h
> index c835d23235..ff71712566 100644
> --- a/include/configs/socfpga_sr1500.h
> +++ b/include/configs/socfpga_sr1500.h
> @@ -26,8 +26,9 @@
>  #define CONFIG_SPI_N25Q256A_RESET
>  
>  /*
> - * Bootcounter
> + * Bootcounter (preserve the last 2 lwords for the boot-counter)
>   */
> +#define SOCFPGA_INIT_RAM_END_RESERVE 8
>  #define CONFIG_SYS_BOOTCOUNT_BE
>  
>  /* Environment setting for SPI flash */
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] soc: zynqmp: Update required API version to 1.0

[Marek Vasut]

On 05/14/2018 03:39 PM, Michal Simek wrote:
> From: Rajan Vaja 
> 
> Existing EEMI version is to as 1.0 (available from xilinx v2018.1
> version). Update required API version to match with EEMI API version.

Not sure I understand this sentence.

> New PMUFW version is required for operations with programmable logic.

Seems the meta-xilinx 2018.1 comes with PMUFW 2017.3
https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-bsp/recipes-bsp/pmu-firmware

Is this out of date ?

> Signed-off-by: Rajan Vaja 
> Signed-off-by: Michal Simek 
> ---
> 
>  arch/arm/cpu/armv8/zynqmp/cpu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
> index 792a3e1b655f..e122be59c747 100644
> --- a/arch/arm/cpu/armv8/zynqmp/cpu.c
> +++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
> @@ -173,8 +173,8 @@ int __maybe_unused invoke_smc(u32 pm_api_id, u32 arg0, 
> u32 arg1, u32 arg2,
>  
>  #define ZYNQMP_SIP_SVC_GET_API_VERSION   0xC201
>  
> -#define ZYNQMP_PM_VERSION_MAJOR  0
> -#define ZYNQMP_PM_VERSION_MINOR  3
> +#define ZYNQMP_PM_VERSION_MAJOR  1
> +#define ZYNQMP_PM_VERSION_MINOR  0
>  #define ZYNQMP_PM_VERSION_MAJOR_SHIFT16
>  #define ZYNQMP_PM_VERSION_MINOR_MASK 0x
>  
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: socfpga: Put stack at the end of SRAM

[Marek Vasut]

On 05/14/2018 09:43 PM, Simon Goldschmidt wrote:
> 
> 
> On 14.05.2018 17:51, Stefan Roese wrote:
>> On 14.05.2018 11:06, Marek Vasut wrote:
>>> On 05/14/2018 11:01 AM, Simon Goldschmidt wrote:


 On 14.05.2018 10:17, Marek Vasut wrote:
> On 05/14/2018 10:03 AM, Simon Goldschmidt wrote:
>> On 12.05.2018 22:27, Marek Vasut wrote:
>>> The global data are in the .data section, so there's no point in
>>> reserving any space for it above stack. Put stack at the end of
>>> SRAM.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Chin Liang See 
>>> Cc: Dinh Nguyen 
>>> ---
>>>     include/configs/socfpga_common.h | 4 +---
>>>     1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/include/configs/socfpga_common.h
>>> b/include/configs/socfpga_common.h
>>> index 4de2aa7929..cb67d539b1 100644
>>> --- a/include/configs/socfpga_common.h
>>> +++ b/include/configs/socfpga_common.h
>>> @@ -35,10 +35,8 @@
>>>     #define CONFIG_SYS_INIT_RAM_ADDR    0xFFE0
>>>     #define CONFIG_SYS_INIT_RAM_SIZE    0x4 /* 256KB */
>>>     #endif
>>> -#define CONFIG_SYS_INIT_SP_OFFSET    \
>>> -    (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
>>>     #define CONFIG_SYS_INIT_SP_ADDR    \
>>> -    (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
>>> +    (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)
>>
>> I think this interferes with the bootcount being stored at the end of
>> SRAM. See the defconfigs of 'is1' and 'sr1500' boards - or my local
>> defconfig here :-)
>>
>> I'd really like to keep some room here for bootcounter and some
>> related
>> things I store here.
>
> So if I understand it correctly, before this patch, the boards
> overwrote
> the global data ?

 Ehrm, reading up on the init code path in the S and C files, it seems
 like that, yes. I just used the two boards as an example. Are they
 actively maintained? get_maintainer.pl shows the boards are maintained
 by denx, so maybe you could clarify this?
>>>
>>> +CC Stefan.
>>
>> Thanks. At the time I added the bootcounter support on this platform,
>> it used to work. I might have missed something though. Right now,
>> I don't have access to such a platform, so its hard for me to test
>> something. If you have some patches to fix any potential overlapping
>> memory usages, I'll gladly review them.
> 
> I just checked out ae996c80 and from what I can tell, the RAM layout was
> the same at that time: include/generated/generated-asm-offsets.h contains:
> - #define GENERATED_GBL_DATA_SIZE 208
> - #define GD_SIZE 200
> 
> That leaves us with an 8 byte alignment gap at the end of the SRAM and
> that's where the boot counter is located. So the global data is not
> overwritten, but this is more or less by chance, any change to the
> struct definition might change this.
> 
> Looking at just another example: the x600 board defines its SRAM_SIZE 8
> bytes smaller than what it really is. That seems like a good idea for
> socfpga, too. I'll see if I can provide a patch.

This looks like a hack and a bogus one. Lying about RAM size is never a
good idea.

> Slightly off-topic: I have a constellation where the boot-counter is not
> reset although the power has been pulled. This device has big capacitors
> and the SRAM content seems to survive although the processor is reset.
> To me it seems as if looking at the boot reason might be safer than
> checking for a magic word... Any ideas?

What boot reason options do you get ?

[...]

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] image.h Allow booting Aarch64 from arm

[Ramon Fried]

Snapdragon bootloader needs to jump from 32bit to 64bit
Allow booting in these cases when CONFIG_AARCH32_SUPPORT_ARM64 is
defined.

Signed-off-by: Ramon Fried 
---
 include/image.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/image.h b/include/image.h
index df701e3470..598c66177d 100644
--- a/include/image.h
+++ b/include/image.h
@@ -817,7 +817,13 @@ static inline int image_check_type(const image_header_t 
*hdr, uint8_t type)
 static inline int image_check_arch(const image_header_t *hdr, uint8_t arch)
 {
return (image_get_arch(hdr) == arch) ||
+#ifndef CONFIG_AARCH32_SUPPORT_ARM64
(image_get_arch(hdr) == IH_ARCH_ARM && arch == IH_ARCH_ARM64);
+#else
+   (image_get_arch(hdr) == IH_ARCH_ARM && arch == IH_ARCH_ARM64) ||
+   (image_get_arch(hdr) == IH_ARCH_ARM64 && arch == IH_ARCH_ARM);
+#endif
+
 }
 static inline int image_check_os(const image_header_t *hdr, uint8_t os)
 {
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] image: fit: Allow booting Aarch64 from arm

[Ramon Fried]

Snapdragon bootloader needs to jump from 32bit to 64bit
Allow booting in these cases when CONFIG_AARCH32_SUPPORT_ARM64 is defined.

Signed-off-by: Ramon Fried 
---
 common/image-fit.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 5b93dceae1..62dbfbdd3d 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1253,17 +1253,24 @@ int fit_image_check_arch(const void *fit, int noffset, 
uint8_t arch)
 {
uint8_t image_arch;
int aarch32_support = 0;
+   int aarch64_support = 0;
 
 #ifdef CONFIG_ARM64_SUPPORT_AARCH32
aarch32_support = 1;
 #endif
 
+#ifdef CONFIG_AARCH32_SUPPORT_ARM64
+   aarch64_support = 1;
+#endif
+
if (fit_image_get_arch(fit, noffset, _arch))
return 0;
return (arch == image_arch) ||
(arch == IH_ARCH_I386 && image_arch == IH_ARCH_X86_64) ||
(arch == IH_ARCH_ARM64 && image_arch == IH_ARCH_ARM &&
-aarch32_support);
+aarch32_support) ||
+   (arch == IH_ARCH_ARM && image_arch == IH_ARCH_ARM64 &&
+aarch64_support);
 }
 
 /**
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] mach-snapdragon: Introduce pinctrl driver

[Ramon Fried]

On Mon, May 14, 2018 at 10:51 PM, Simon Glass  wrote:
> Hi Ramon,
>
> On 14 May 2018 at 01:10, Ramon Fried  wrote:
>> On Mon, May 14, 2018 at 1:00 AM, Simon Glass  wrote:
>>> Hi Ramon,
>>>
>>> On 12 May 2018 at 20:15, Ramon Fried  wrote:
 This patch adds pinmux and pinctrl driver for TLMM
 subsystem in snapdragon chipsets.
 Currently, supporting only 8016, but implementation is
 generic and 8096 can be added easily.

 Driver is using the generic dt-bindings and doesn't
 introduce any new bindings (yet).

 Signed-off-by: Ramon Fried 
 ---
  arch/arm/mach-snapdragon/Makefile|   2 +
  arch/arm/mach-snapdragon/pinctrl-apq8016.c   | 162 
 +++
  arch/arm/mach-snapdragon/pinctrl-snapdragon.c| 118 +
  arch/arm/mach-snapdragon/pinctrl-snapdragon.h|  21 +++
  configs/dragonboard410c_defconfig|   5 +
  include/dt-bindings/pinctrl/pinctrl-snapdragon.h |  22 +++
  6 files changed, 330 insertions(+)
  create mode 100644 arch/arm/mach-snapdragon/pinctrl-apq8016.c
  create mode 100644 arch/arm/mach-snapdragon/pinctrl-snapdragon.c
  create mode 100644 arch/arm/mach-snapdragon/pinctrl-snapdragon.h
  create mode 100644 include/dt-bindings/pinctrl/pinctrl-snapdragon.h

 diff --git a/arch/arm/mach-snapdragon/Makefile 
 b/arch/arm/mach-snapdragon/Makefile
 index 1c23dc52cf..1d35fea912 100644
 --- a/arch/arm/mach-snapdragon/Makefile
 +++ b/arch/arm/mach-snapdragon/Makefile
 @@ -6,4 +6,6 @@ obj-$(CONFIG_TARGET_DRAGONBOARD820C) += clock-apq8096.o
  obj-$(CONFIG_TARGET_DRAGONBOARD820C) += sysmap-apq8096.o
  obj-$(CONFIG_TARGET_DRAGONBOARD410C) += clock-apq8016.o
  obj-$(CONFIG_TARGET_DRAGONBOARD410C) += sysmap-apq8016.o
 +obj-$(CONFIG_TARGET_DRAGONBOARD410C) += pinctrl-apq8016.o
 +obj-$(CONFIG_TARGET_DRAGONBOARD410C) += pinctrl-snapdragon.o
  obj-y += clock-snapdragon.o
 diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c 
 b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
 new file mode 100644
 index 00..8e57e2338c
 --- /dev/null
 +++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
 @@ -0,0 +1,162 @@
 +// SPDX-License-Identifier: GPL-2.0+
 +/*
 + * Qualcomm APQ8016 pinctrl
 + *
 + * (C) Copyright 2018 Ramon Fried 
 + *
 + */
 +
 +#include "pinctrl-snapdragon.h"
 +#include 
 +
 +const char * const msm_pinctrl_pins[] = {
 +   "GPIO_0",
 +   "GPIO_1",
 +   "GPIO_2",
 +   "GPIO_3",
 +   "GPIO_4",
 +   "GPIO_5",
 +   "GPIO_6",
 +   "GPIO_7",
>>>
>>> This seems inefficient. Could you not sprintf() the name for most of
>>> these values?
>> The origin of this table is from the Linux kernel driver.
>> I'm not sure I understand how sprintf will more efficient, do you want
>> to fill up this table on runtime ?
>
> I think this table is only used in one function, so you could create
> the string there perhaps?
>
Actually, it works the other way around, the generic-pinctrl needs a
function to translate string to index.
Basically, it reads strings from the FDT and then go over all indexes
until it matches that string. this is inefficient IMHO as I think it
will be easier just
to be able to provide an index instead of a string in the FDT.

> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 13/13] net: fastboot: Merge AOSP UDP fastboot

[Alex Kiernan]

On Mon, May 14, 2018 at 8:53 PM Simon Glass  wrote:

> Hi Alex,

> On 14 May 2018 at 03:09, 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 
> > ---
> >
> > Changes in v3:
> > - use FASTBOOT as our guard in Kconfig not a list of USB || UDP
> > - correct mis-translation from AOSP introduced when cleaning up for
> >   checkpatch - we should write when buffer is not NULL, rather than
> >   erasing, and erase when buffer is NULL
> > - use CMD_RET_USAGE from do_fastboot
> > - remove do_fastboot_udp from cmd/net.c and rewrite using net_loop()
> > - rename timed_send_info to fastboot_send_info, rename
fastboot_send_info to
> >   fastboot_udp_send_info
> > - replace FASTBOOT_HEADER_SIZE with sizeof(struct fastboot_header)
> > - move start time into timed_send_info() rather than passing it in
> > - make calls to fastboot_udp_send_info a runtime dependency, not a
compile
> >   time one
> > - set ${filesize} to size of downloaded image
> > - add progress meter from USB path during download
> > - add support for 'oem format' command from the USB path
> > - rename 'fastbootcmd' to 'fastboot_bootcmd' to make clear that this is
the
> >   fastboot boot command
> > - make getvar implementation table driven
> > - add fastboot_buf_addr, fastboot_buf_size to override buffer address
and
> >   size
> > - return correct filesystem type in getvar partition-type on MMC
> > - process "fastboot." prefixed env variables in getvar first so you
> >   can override the normal values (this also lets you set a fs type for
> >   NAND devices)
> > - squash subsequent patches which change this code into this one:
> >   - If the fastboot flash/erase commands are disabled, remove that
support
> > so we still build correctly.
> >   - Add NAND support to fastboot UDP flash/erase commands
> >   - If we don't have a partition name passed, report it as not found.
> >   - Change the behaviour of the fastboot net code such that
> > "reboot-bootloader" is no longer written to
CONFIG_FASTBOOT_BUF_ADDR for
> > use as a marker on reboot (the AOSP code in
common/android-bootloader.c
> > uses this marker - this code could be reinstated there if that gets
> > merged).
> >   - Merge USB and UDP boot code. The USB implementation stays the same,
but
> > UDP no longer passes an fdt. We introduce a new environment variable
> > 'fastboot_bootcmd' which if set overrides the hardcoded boot
command,
> > setting this then allows the UDP implementation to remain the same.
If
> > after running 'fastboot_bootcmd' the board has not booted, control
is
> > returned to U-Boot and the fastboot process ends.
> >   - Separate the fastboot protocol handling from the fastboot UDP code
in
> > preparation for reusing it in the USB code.
> >
> > Changes in v2:
> > - ensure fastboot syntax is backward compatible - 'fastboot 0' means
> >   'fastboot usb 0'
> >
> >  cmd/fastboot.c|  91 -
> >  drivers/fastboot/Kconfig  |  15 ++
> >  drivers/fastboot/Makefile |   2 +
> >  drivers/fastboot/fb_command.c | 258 +++
> >  drivers/fastboot/fb_common.c  |  48 +++
> >  drivers/fastboot/fb_getvar.c  | 222 ++
> >  drivers/fastboot/fb_mmc.c |  67 -
> >  drivers/fastboot/fb_nand.c|  12 +-
> >  include/fastboot.h|  47 +++
> >  include/fb_mmc.h  |   8 +-
> >  include/fb_nand.h |  10 +-
> >  include/net.h |   2 +-
> >  include/net/fastboot.h|  21 +++
> >  net/Makefile  |   1 +
> >  net/fastboot.c| 310
++
> >  net/net.c |   7 +
> >  16 files changed, 1105 insertions(+), 16 deletions(-)
> >  create mode 100644 drivers/fastboot/fb_command.c
> >  create mode 100644 drivers/fastboot/fb_getvar.c
> >  create mode 100644 include/net/fastboot.h
> >  create mode 100644 net/fastboot.c

> Reviewed-by: Simon Glass 

> Please can you add function comments to the rest of the fastboot.h
> stuff, see if you can remove the global variables in that file, and
> also add function comments to non-trivial static functions?


Will do... I don't think I can easily make the remaining globals go away,
but I can certainly put them behind accessor functions.

--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,3/3] mmc: support writing sparse images

[Alex Kiernan]

On Mon, May 14, 2018 at 9:50 PM Tom Rini  wrote:

> On Mon, May 14, 2018 at 05:14:42PM +0100, Alex Kiernan wrote:
> > On Mon, May 14, 2018 at 3:47 PM Tom Rini  wrote:
> >
> > > On Mon, May 14, 2018 at 06:42:41PM +0530, Jassi Brar wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, May 8, 2018 at 10:45 PM, Tom Rini 
wrote:
> > > > > On Fri, Apr 06, 2018 at 12:05:24PM +0530, jassisinghb...@gmail.com
> > wrote:
> > > > >
> > > > >> From: Jassi Brar 
> > > > >>
> > > > >> Provide an alternate path for sparse-images to be
> > > > >> written to MMC. For example, via tftp on platforms
> > > > >> that don't support fastboot protocol. Or when an
> > > > >> image is to written at some offset, rather than the
> > > > >> start of a partition.
> > > > >>
> > > > >> Signed-off-by: Jassi Brar 
> > > > >
> > > > > Applied to u-boot/master, thanks!
> > > >
> > > > I see you modified the patch to protect the feature with
> > > > CONFIG_FASTBOOT_FLASH, which kills the purpose -- this feature is
for
> > > > platforms that don't support fastboot.
> > > >
> > > > Do you want me to send the patch to revert the protection?
> >
> > > Sorry, I guess maybe things weren't clear enough all around, and we
> > > should (functionally) revert patches 2 and 3 and try something
> > > different.  It is OK to say "lets make writing sparse images more
widely
> > > available".  It's not OK to make every platform with MMC write grow a
> > > decent bit in binary size.  Making a quick pass at re-enabling things
on
> > > a platform without fastboot support already grew things by nearly
2KiB.
> > > The other part which is I believe got me down this path was that
without
> > > a change to common/Makefile to always (outside of SPL) include
> > > common/image-sparse.o things don't link.
> >
> > > In sum, a new patch to add an option to allow people to opt-in for
> > > swrite would be good.  And please make sure to do something like:
> > > diff --git a/common/Makefile b/common/Makefile
> > > index d0681c7dd96a..92b2aa1ca8f0 100644
> > > --- a/common/Makefile
> > > +++ b/common/Makefile
> > > @@ -120,6 +120,7 @@ ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
> > >   obj-y += fb_nand.o
> > >   endif
> > >   endif
> > > +obj-$(CONFIG_MMC_WRITE) += image-sparse.o
> > >   endif
> >
> > Isn't this just move image-sparse to lib and add a separate guard for it
> > (LIB_IMAGE_SPARSE?) which can be selected by both FASTBOOT and a new
> > command symbol (CMD_MMC_SWRITE)?
> >
> > This is all overlapping with the UDP fastboot code I've been posting, so
> > I'd kinda like it to fit nicely with that, rather than have to refactor
it
> > to fit something different!

> That sounds like a good idea to me, thanks!


I'll work it into that patch series... having just had a quick look at it,
it's going to be easiest part way through it after I've done most of the
Kconfig reworking.

-- 
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Makefile: adopt --std=gnu11 for HOSTCFLAGS on Linux

[Mark Kettenis]

> From: "Dr. Philipp Tomsich" 
> Date: Mon, 14 May 2018 17:02:43 +0200
> 
> > On 14 May 2018, at 16:53, Mark Kettenis  wrote:
> > 
> >> From: Philipp Tomsich 
> >> Date: Mon, 14 May 2018 15:22:06 +0200
> >> 
> >> Following the conversion of the SPDX license tags, a number of files
> >> compiled with -pedantic now generate warnings similar to the following
> >> for using C99-style '//' comments in ISO C90 code:
> >> 
> >>  tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in 
> >> ISO C90
> >>   // SPDX-License-Identifier: GPL-2.0+
> >>   ^
> >> 
> >> The SPDX comment-style change means that these files have adopted C99,
> >> so need to change the language-standard to --std=gnu99 or --std=gnu11
> >> to let the compiler know this.
> >> 
> >> As we now require GCC 6 or newer for the cross-compiler, the project has
> >> implicitly moved the project to GNU11: let older GCC versions on various
> >> Linux distros know to treat our host tools as GNU11 as well.
> > 
> > Note that the requirement is on the cross-compiler, not the host
> > compiler.  On our "primary" architectures OpenBSD 6.3 ships with Clang
> > 5.0.1 and the current development version uses Clang 6.0.0, which
> > default to --std=gnu11.  I do hope those will continue to be supported
> > as the host compiler…
> 
> Many of the files in question (e.g. lib/sha{1,256}.c) are shared between
> the target and the host tools.

Sure.  But these files are all supposed to be fairly high-level code
written in standard C.  Ane decent C99 compiler shoul be able to
compile that code.  The specific GCC 6 requirement for the cross
compiler was (mostly) introduced to be able to meet size constraints
nad I don't think it makes sense to enforce it for the host compiler.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: socfpga: fix CONFIG_SPL_MAX_SIZE (less than SRAM)

[Simon Goldschmidt]

The boot ROMs of the socfpga platform limit the size of the
SPL to copy to less than the available SRAM.
(See "Intel SoC FPGA Embedded Development Suite User Guide")

According to this document, Cyclone V and Arria V allow 60KB
maximum while Arria 10 allows 200KB. In both cases, this is
less than CONFIG_SYS_INIT_RAM_SIZE.

Signed-off-by: Simon Goldschmidt 
---
 include/configs/socfpga_common.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/configs/socfpga_common.h 
b/include/configs/socfpga_common.h

index 4de2aa7929..bf7014064a 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -31,9 +31,12 @@
 #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 #define CONFIG_SYS_INIT_RAM_ADDR   0x
 #define CONFIG_SYS_INIT_RAM_SIZE   0x1
+#define CONFIG_SPL_MAX_SIZE0xF000 /* 60KB */
+
 #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
 #define CONFIG_SYS_INIT_RAM_ADDR   0xFFE0
 #define CONFIG_SYS_INIT_RAM_SIZE   0x4 /* 256KB */
+#define CONFIG_SPL_MAX_SIZE0x32000 /* 200KB */
 #endif
 #define CONFIG_SYS_INIT_SP_OFFSET  \
(CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
@@ -254,7 +257,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
  * 0x_FF00 .. End of SRAM
  */
 #define CONFIG_SPL_TEXT_BASE   CONFIG_SYS_INIT_RAM_ADDR
-#define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE

 /* SPL SDMMC boot support */
 #ifdef CONFIG_SPL_MMC_SUPPORT
--
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Makefile: adopt --std=gnu11 for HOSTCFLAGS on Linux

[Mark Kettenis]

> Date: Mon, 14 May 2018 10:57:12 -0400
> From: Tom Rini 
> 
> On Mon, May 14, 2018 at 04:53:49PM +0200, Mark Kettenis wrote:
> > > From: Philipp Tomsich 
> > > Date: Mon, 14 May 2018 15:22:06 +0200
> > > 
> > > Following the conversion of the SPDX license tags, a number of files
> > > compiled with -pedantic now generate warnings similar to the following
> > > for using C99-style '//' comments in ISO C90 code:
> > > 
> > >   tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed 
> > > in ISO C90
> > >// SPDX-License-Identifier: GPL-2.0+
> > >^
> > > 
> > > The SPDX comment-style change means that these files have adopted C99,
> > > so need to change the language-standard to --std=gnu99 or --std=gnu11
> > > to let the compiler know this.
> > > 
> > > As we now require GCC 6 or newer for the cross-compiler, the project has
> > > implicitly moved the project to GNU11: let older GCC versions on various
> > > Linux distros know to treat our host tools as GNU11 as well.
> > 
> > Note that the requirement is on the cross-compiler, not the host
> > compiler.  On our "primary" architectures OpenBSD 6.3 ships with Clang
> > 5.0.1 and the current development version uses Clang 6.0.0, which
> > default to --std=gnu11.  I do hope those will continue to be supported
> > as the host compiler...
> 
> Does Clang 5.0.1 support gnu11 ?  Note that at this point we're not even
> talking about moving to GNU11 features being used anywhere, just
> enforcing consistency between modern (post gcc-5) and old (gcc-4.x)
> compilers all in order to not have // style comments be a warning (which
> in turn is a C99/gnu99 thing).  Thanks!

Yes.  Both Clang 5.0.1 and Clang 6.0.0 support gnu11 and even default to it.

If tere is no intention to use C11 features (and frankly I don't think
C11 offers any significant benefits over C99), it'd make more sense to
add --std=gnu99 instead of --std=gnu11 wouldn't it?  That would
actually catch accidental use of C11 features.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: socfpga: correctly reserve SRAM for boot counter

[Goldschmidt Simon]

Bootcounter for is1 and sr1500 boards somewhat relied on struct global data 
alignment gap
at the end of internal SRAM. Let's fix this by explicitly reserving some bytes.

Signed-off-by: Simon Goldschmidt 
---
 include/configs/socfpga_common.h | 6 +-
 include/configs/socfpga_is1.h| 3 ++-
 include/configs/socfpga_sr1500.h | 3 ++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 4de2aa7929..1934aea86d 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -35,8 +35,12 @@
 #define CONFIG_SYS_INIT_RAM_ADDR   0xFFE0
 #define CONFIG_SYS_INIT_RAM_SIZE   0x4 /* 256KB */
 #endif
+/* Reserve bytes at the end of SRAM? */
+#ifndef SOCFPGA_INIT_RAM_END_RESERVE
+#define SOCFPGA_INIT_RAM_END_RESERVE   0
+#endif
 #define CONFIG_SYS_INIT_SP_OFFSET  \
-   (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
+   (CONFIG_SYS_INIT_RAM_SIZE - SOCFPGA_INIT_RAM_END_RESERVE)
 #define CONFIG_SYS_INIT_SP_ADDR\
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
 
diff --git a/include/configs/socfpga_is1.h b/include/configs/socfpga_is1.h
index c233c208a5..b243fd29cd 100644
--- a/include/configs/socfpga_is1.h
+++ b/include/configs/socfpga_is1.h
@@ -27,8 +27,9 @@
 #include 
 
 /*
- * Bootcounter
+ * Bootcounter (preserve the last 2 lwords for the boot-counter)
  */
+#define CONFIG_SYS_INIT_RAM_END_RESERVE8
 #define CONFIG_SYS_BOOTCOUNT_BE
 
 #endif /* __CONFIG_SOCFPGA_IS1_H__ */
diff --git a/include/configs/socfpga_sr1500.h b/include/configs/socfpga_sr1500.h
index c835d23235..ff71712566 100644
--- a/include/configs/socfpga_sr1500.h
+++ b/include/configs/socfpga_sr1500.h
@@ -26,8 +26,9 @@
 #define CONFIG_SPI_N25Q256A_RESET
 
 /*
- * Bootcounter
+ * Bootcounter (preserve the last 2 lwords for the boot-counter)
  */
+#define SOCFPGA_INIT_RAM_END_RESERVE   8
 #define CONFIG_SYS_BOOTCOUNT_BE
 
 /* Environment setting for SPI flash */
-- 
2.17.0.windows.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] PCI: Document pciauto_region_allocate()

[Tuomas Tynkkynen]

Add a doc comment for pciauto_region_allocate().

Signed-off-by: Tuomas Tynkkynen 
---
This patch depends on [PATCH 2/2] PCI: autoconfig: Don't allocate 64-bit
addresses to 32-bit only resources.
---
 include/pci.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/pci.h b/include/pci.h
index 127d3c6a6f..8e27cbfaf1 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -680,6 +680,19 @@ extern int pci_write_config_dword(pci_dev_t dev, int 
where, u32 val);
 void pciauto_region_init(struct pci_region *res);
 void pciauto_region_align(struct pci_region *res, pci_size_t size);
 void pciauto_config_init(struct pci_controller *hose);
+
+/**
+ * pciauto_region_allocate() - Allocate resources from a PCI resource region
+ *
+ * Allocates @size bytes from the PCI resource @res. If @supports_64bit is
+ * false, the result will be guaranteed to fit in 32 bits.
+ *
+ * @res:   PCI region to allocate from
+ * @size:  Amount of bytes to allocate
+ * @bar:   Returns the PCI bus address of the allocated resource
+ * @supports_64bit:Whether to allow allocations above the 32-bit boundary
+ * @return 0 if successful, -1 on failure
+ */
 int pciauto_region_allocate(struct pci_region *res, pci_size_t size,
pci_addr_t *bar, bool supports_64bit);
 
-- 
2.16.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,3/3] mmc: support writing sparse images

[Tom Rini]

On Mon, May 14, 2018 at 05:14:42PM +0100, Alex Kiernan wrote:
> On Mon, May 14, 2018 at 3:47 PM Tom Rini  wrote:
> 
> > On Mon, May 14, 2018 at 06:42:41PM +0530, Jassi Brar wrote:
> > > Hi Tom,
> > >
> > > On Tue, May 8, 2018 at 10:45 PM, Tom Rini  wrote:
> > > > On Fri, Apr 06, 2018 at 12:05:24PM +0530, jassisinghb...@gmail.com
> wrote:
> > > >
> > > >> From: Jassi Brar 
> > > >>
> > > >> Provide an alternate path for sparse-images to be
> > > >> written to MMC. For example, via tftp on platforms
> > > >> that don't support fastboot protocol. Or when an
> > > >> image is to written at some offset, rather than the
> > > >> start of a partition.
> > > >>
> > > >> Signed-off-by: Jassi Brar 
> > > >
> > > > Applied to u-boot/master, thanks!
> > >
> > > I see you modified the patch to protect the feature with
> > > CONFIG_FASTBOOT_FLASH, which kills the purpose -- this feature is for
> > > platforms that don't support fastboot.
> > >
> > > Do you want me to send the patch to revert the protection?
> 
> > Sorry, I guess maybe things weren't clear enough all around, and we
> > should (functionally) revert patches 2 and 3 and try something
> > different.  It is OK to say "lets make writing sparse images more widely
> > available".  It's not OK to make every platform with MMC write grow a
> > decent bit in binary size.  Making a quick pass at re-enabling things on
> > a platform without fastboot support already grew things by nearly 2KiB.
> > The other part which is I believe got me down this path was that without
> > a change to common/Makefile to always (outside of SPL) include
> > common/image-sparse.o things don't link.
> 
> > In sum, a new patch to add an option to allow people to opt-in for
> > swrite would be good.  And please make sure to do something like:
> > diff --git a/common/Makefile b/common/Makefile
> > index d0681c7dd96a..92b2aa1ca8f0 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -120,6 +120,7 @@ ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
> >   obj-y += fb_nand.o
> >   endif
> >   endif
> > +obj-$(CONFIG_MMC_WRITE) += image-sparse.o
> >   endif
> 
> Isn't this just move image-sparse to lib and add a separate guard for it
> (LIB_IMAGE_SPARSE?) which can be selected by both FASTBOOT and a new
> command symbol (CMD_MMC_SWRITE)?
> 
> This is all overlapping with the UDP fastboot code I've been posting, so
> I'd kinda like it to fit nicely with that, rather than have to refactor it
> to fit something different!

That sounds like a good idea to me, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] video: dw_hdmi: fix HSYNC and VSYNC polarity settings

[Vasily Khoruzhick]

Currently dw_hdmi configures HSYNC polarity using VSYNC setting from
EDID and vice versa. Fix it, since it breaks displays where HSYNC
and VSYNC polarity differs

Signed-off-by: Vasily Khoruzhick 
---
 drivers/video/dw_hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/dw_hdmi.c b/drivers/video/dw_hdmi.c
index dbad0e2b24..229bd63c97 100644
--- a/drivers/video/dw_hdmi.c
+++ b/drivers/video/dw_hdmi.c
@@ -401,11 +401,11 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
/* set up hdmi_fc_invidconf */
inv_val = HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE;
 
-   inv_val |= (edid->flags & DISPLAY_FLAGS_HSYNC_HIGH ?
+   inv_val |= (edid->flags & DISPLAY_FLAGS_VSYNC_HIGH ?
   HDMI_FC_INVIDCONF_VSYNC_IN_POLARITY_ACTIVE_HIGH :
   HDMI_FC_INVIDCONF_VSYNC_IN_POLARITY_ACTIVE_LOW);
 
-   inv_val |= (edid->flags & DISPLAY_FLAGS_VSYNC_HIGH ?
+   inv_val |= (edid->flags & DISPLAY_FLAGS_HSYNC_HIGH ?
   HDMI_FC_INVIDCONF_HSYNC_IN_POLARITY_ACTIVE_HIGH :
   HDMI_FC_INVIDCONF_HSYNC_IN_POLARITY_ACTIVE_LOW);
 
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] tools: adopt --std=gnu99 where C99 comments are needed

[Tom Rini]

On Mon, May 14, 2018 at 02:07:27PM +0200, Dr. Philipp Tomsich wrote:

> While it’s not directly related to this patch, we should clearly state that
> the U-Boot code base (with the possible exception of the tools/ directory,
> which I have started touching here) has _implicitly_ moved to GNU11 
> (yes, even newer than C99), when be upgraded beyond GCC 5.
> 
> For reference, see the "Default standard is now GNU11” section at 
>   https://gcc.gnu.org/gcc-5/porting_to.html
> 
> Do we want to
> (a)   document this somewhere (which file in doc/ would be appropriate?)
> (b)   explicitly set the “--std=“ flag to make sure that people (and their 
> compilers)
>   are aware of this?

For the record, I don't see anything here as a problem.  I did half
suggest, and did reviewed-by just spelling out GNU11.  So long as that
isn't a problem for clang-5, I don't think this is a problem.  The "$X
is a warning" are things we've had to long since clean up.  This is also
not me suggesting that we make use of any particular new language
features.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/2] sunxi: video: HDMI: use correct bits for HSYNC and VSYNC polarity.

[Vasily Khoruzhick]

HSYNC is bit 8, and VSYNC is bit 9.

Signed-off-by: Vasily Khoruzhick 
---
 drivers/video/sunxi/sunxi_dw_hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c 
b/drivers/video/sunxi/sunxi_dw_hdmi.c
index c78e33b947..9dbea649a0 100644
--- a/drivers/video/sunxi/sunxi_dw_hdmi.c
+++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
@@ -303,10 +303,10 @@ static int sunxi_dw_hdmi_enable(struct udevice *dev, int 
panel_bpp,
 
sunxi_dw_hdmi_lcdc_init(priv->mux, edid, panel_bpp);
 
-   if (edid->flags & DISPLAY_FLAGS_HSYNC_LOW)
+   if (edid->flags & DISPLAY_FLAGS_VSYNC_LOW)
setbits_le32(>pol, 0x200);
 
-   if (edid->flags & DISPLAY_FLAGS_VSYNC_LOW)
+   if (edid->flags & DISPLAY_FLAGS_HSYNC_LOW)
setbits_le32(>pol, 0x100);
 
setbits_le32(>ctrl, 0xf << 12);
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 0/2] video: dw_hdmi: fix HSYNC and VSYNC polarity settings

[Vasily Khoruzhick]

Previous attempt to fix HSYNC and VSYNC polarity settings for dw_hdmi on sunxi
wasn't completely correct - there's another bug in dw_hdmi driver.
This series fixes hsync/vsync settings in sunxi glue driver and
applies proper fix to dw_hdmi

v2: don't revert earlier fix, just use correct bits for hsync and vsync

Vasily Khoruzhick (2):
  sunxi: video: HDMI: use correct bits for HSYNC and VSYNC polarity.
  video: dw_hdmi: fix HSYNC and VSYNC polarity settings

 drivers/video/dw_hdmi.c | 4 ++--
 drivers/video/sunxi/sunxi_dw_hdmi.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] GPL clarification needed

[Burt Janz]

Long time u-boot user... (since the ppc days).

Need a clarification from WD re. GPL2: do Makefiles and header files in 
include/config fall within the u-boot GPL?


NO, I do not want to link with any u-boot libraries.  I'm writing code 
that uses the jump table to add my "extensions", but would like to have 
a platform-specific file in include/configs to call those functions.  To 
do that, I need to add my own platform file and make a change to a 
Makefile to cause it to be included in the build.


My intention is to follow WD's GPL restrictions to the letter. But, 
since I'm not adding any code that links with any of the rest of the 
u-boot source, and since I'm using the jump table to add my code as 
external tools (as required to stay within WD's requirements), I'd like 
to have my own include/config/myboard.h to contain my environment (to 
prevent production and manufacturing from "fat fingering" changes after 
we flash u-boot into the boards).


So I need just some clarification here: can I make changes to some 
Makefiles and add my own code to include/configs /without/ going astray 
of the u-boot GPL?


Thanks!

--
Burt Janz
603-943-0330 (cell)
603-880-0482 (home office)
bhj...@ccsneinc.com or burt.j...@gmail.com
http://bhjanz.ccsneinc.com

"There is no such thing as bad weather - just inappropriate clothing."

(PGP public key block available on request)

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/13] fastboot: Extract common definitions from USB fastboot

[Alex Kiernan]

On Mon, May 14, 2018 at 8:53 PM Simon Glass  wrote:

> Hi,

> On 14 May 2018 at 03:09, Alex Kiernan  wrote:
> > Move strcmp_l1() to include/common.h so we can can call it from
elsewhere.
> > Move FASTBOOT_VERSION to include/fastboot.h so when we merge the UDP
code
> > we only have one definition.
> >
> > Signed-off-by: Alex Kiernan 
> > ---
> >
> > Changes in v3:
> > - new
> >
> > Changes in v2: None
> >
> >  drivers/usb/gadget/f_fastboot.c | 10 --
> >  include/common.h| 13 +
> >  include/fastboot.h  |  2 ++
> >  3 files changed, 15 insertions(+), 10 deletions(-)

> Can you please add this to string.h instead? We are trying to reduce /
> remove common.h


When I was looking through the size changes, I realised that by the time I
was done I'd removed this completely, so I'll just drop it altogether.

-- 
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: socfpga: Put stack at the end of SRAM

[Simon Goldschmidt]

On 14.05.2018 21:43, Simon Goldschmidt wrote:



On 14.05.2018 17:51, Stefan Roese wrote:

On 14.05.2018 11:06, Marek Vasut wrote:

On 05/14/2018 11:01 AM, Simon Goldschmidt wrote:



On 14.05.2018 10:17, Marek Vasut wrote:

On 05/14/2018 10:03 AM, Simon Goldschmidt wrote:

On 12.05.2018 22:27, Marek Vasut wrote:

The global data are in the .data section, so there's no point in
reserving any space for it above stack. Put stack at the end of
SRAM.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
---
    include/configs/socfpga_common.h | 4 +---
    1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/configs/socfpga_common.h
b/include/configs/socfpga_common.h
index 4de2aa7929..cb67d539b1 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -35,10 +35,8 @@
    #define CONFIG_SYS_INIT_RAM_ADDR    0xFFE0
    #define CONFIG_SYS_INIT_RAM_SIZE    0x4 /* 256KB */
    #endif
-#define CONFIG_SYS_INIT_SP_OFFSET    \
-    (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
    #define CONFIG_SYS_INIT_SP_ADDR    \
-    (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
+    (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)


Anyway, after reading up on this in the code and the resulting binaries, 
I do think this patch is correct, so:


Reviewed-by: Simon Goldschmidt 

Sorry for the confusion, but this really helped to clarify my 
understanding of the initial memory allocation ;-)


Thanks,
Simon



I think this interferes with the bootcount being stored at the end of
SRAM. See the defconfigs of 'is1' and 'sr1500' boards - or my local
defconfig here :-)

I'd really like to keep some room here for bootcounter and some 
related

things I store here.


So if I understand it correctly, before this patch, the boards 
overwrote

the global data ?


Ehrm, reading up on the init code path in the S and C files, it seems
like that, yes. I just used the two boards as an example. Are they
actively maintained? get_maintainer.pl shows the boards are maintained
by denx, so maybe you could clarify this?


+CC Stefan.


Thanks. At the time I added the bootcounter support on this platform,
it used to work. I might have missed something though. Right now,
I don't have access to such a platform, so its hard for me to test
something. If you have some patches to fix any potential overlapping
memory usages, I'll gladly review them.


I just checked out ae996c80 and from what I can tell, the RAM layout was 
the same at that time: include/generated/generated-asm-offsets.h contains:

- #define GENERATED_GBL_DATA_SIZE 208
- #define GD_SIZE 200

That leaves us with an 8 byte alignment gap at the end of the SRAM and 
that's where the boot counter is located. So the global data is not 
overwritten, but this is more or less by chance, any change to the 
struct definition might change this.


Looking at just another example: the x600 board defines its SRAM_SIZE 8 
bytes smaller than what it really is. That seems like a good idea for 
socfpga, too. I'll see if I can provide a patch.


Slightly off-topic: I have a constellation where the boot-counter is not 
reset although the power has been pulled. This device has big capacitors 
and the SRAM content seems to survive although the processor is reset. 
To me it seems as if looking at the boot reason might be safer than 
checking for a magic word... Any ideas?


Thanks,
Simon




Chances are high that these bytes just fit into the 16-byte alignment
allocated by GENERATED_GBL_DATA_SIZE (and on my board it *is* like 
that).




Anyway, if you need some extra space, look at
board_init_f_alloc_reserve() .



OK, but that function does not seem to be overridable? How can I 
reserve

my own memory here?


Add a __weak there I guess ?


And reading this function, I guess your commit message is a bit
misleading. It seems that the purpose of CONFIG_SYS_INIT_SP_OFFSET like
it was was to reserve memory for the initial gd (before relocation),
which is now done in board_init_f_alloc_reserve().


The code is confusing as hell, I give you that.


Thanks,
Stefan


___
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 10/13] fastboot: Extract common definitions from USB fastboot

[Simon Glass]

Hi,

On 14 May 2018 at 03:09, Alex Kiernan  wrote:
> Move strcmp_l1() to include/common.h so we can can call it from elsewhere.
> Move FASTBOOT_VERSION to include/fastboot.h so when we merge the UDP code
> we only have one definition.
>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v3:
> - new
>
> Changes in v2: None
>
>  drivers/usb/gadget/f_fastboot.c | 10 --
>  include/common.h| 13 +
>  include/fastboot.h  |  2 ++
>  3 files changed, 15 insertions(+), 10 deletions(-)

Can you please add this to string.h instead? We are trying to reduce /
remove common.h

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] PCI: Add newlines to debug prints in pci_auto_common.c

[Simon Glass]

On 14 May 2018 at 10:38, Tuomas Tynkkynen  wrote:
> All of the debug output from this file is squished to one line. Fix
> it.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  drivers/pci/pci_auto_common.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 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 v3 12/13] fs: Add fs_get_type_name to return current filesystem name

[Simon Glass]

On 14 May 2018 at 03:09, Alex Kiernan  wrote:
> Add fs_get_type_name so we can get the current filesystem type.
>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v3:
> - new
>
> Changes in v2: None
>
>  fs/fs.c  | 5 +
>  include/fs.h | 5 +
>  2 files changed, 10 insertions(+)
>

Reviewed-by: Simon Glass 

Note this comment style does not match docbook, but I suppose it is
OK, since the rest of fs.h doesn't either.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 13/13] net: fastboot: Merge AOSP UDP fastboot

[Simon Glass]

Hi Alex,

On 14 May 2018 at 03:09, 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 
> ---
>
> Changes in v3:
> - use FASTBOOT as our guard in Kconfig not a list of USB || UDP
> - correct mis-translation from AOSP introduced when cleaning up for
>   checkpatch - we should write when buffer is not NULL, rather than
>   erasing, and erase when buffer is NULL
> - use CMD_RET_USAGE from do_fastboot
> - remove do_fastboot_udp from cmd/net.c and rewrite using net_loop()
> - rename timed_send_info to fastboot_send_info, rename fastboot_send_info to
>   fastboot_udp_send_info
> - replace FASTBOOT_HEADER_SIZE with sizeof(struct fastboot_header)
> - move start time into timed_send_info() rather than passing it in
> - make calls to fastboot_udp_send_info a runtime dependency, not a compile
>   time one
> - set ${filesize} to size of downloaded image
> - add progress meter from USB path during download
> - add support for 'oem format' command from the USB path
> - rename 'fastbootcmd' to 'fastboot_bootcmd' to make clear that this is the
>   fastboot boot command
> - make getvar implementation table driven
> - add fastboot_buf_addr, fastboot_buf_size to override buffer address and
>   size
> - return correct filesystem type in getvar partition-type on MMC
> - process "fastboot." prefixed env variables in getvar first so you
>   can override the normal values (this also lets you set a fs type for
>   NAND devices)
> - squash subsequent patches which change this code into this one:
>   - If the fastboot flash/erase commands are disabled, remove that support
> so we still build correctly.
>   - Add NAND support to fastboot UDP flash/erase commands
>   - If we don't have a partition name passed, report it as not found.
>   - Change the behaviour of the fastboot net code such that
> "reboot-bootloader" is no longer written to CONFIG_FASTBOOT_BUF_ADDR for
> use as a marker on reboot (the AOSP code in common/android-bootloader.c
> uses this marker - this code could be reinstated there if that gets
> merged).
>   - Merge USB and UDP boot code. The USB implementation stays the same, but
> UDP no longer passes an fdt. We introduce a new environment variable
> 'fastboot_bootcmd' which if set overrides the hardcoded boot command,
> setting this then allows the UDP implementation to remain the same. If
> after running 'fastboot_bootcmd' the board has not booted, control is
> returned to U-Boot and the fastboot process ends.
>   - Separate the fastboot protocol handling from the fastboot UDP code in
> preparation for reusing it in the USB code.
>
> Changes in v2:
> - ensure fastboot syntax is backward compatible - 'fastboot 0' means
>   'fastboot usb 0'
>
>  cmd/fastboot.c|  91 -
>  drivers/fastboot/Kconfig  |  15 ++
>  drivers/fastboot/Makefile |   2 +
>  drivers/fastboot/fb_command.c | 258 +++
>  drivers/fastboot/fb_common.c  |  48 +++
>  drivers/fastboot/fb_getvar.c  | 222 ++
>  drivers/fastboot/fb_mmc.c |  67 -
>  drivers/fastboot/fb_nand.c|  12 +-
>  include/fastboot.h|  47 +++
>  include/fb_mmc.h  |   8 +-
>  include/fb_nand.h |  10 +-
>  include/net.h |   2 +-
>  include/net/fastboot.h|  21 +++
>  net/Makefile  |   1 +
>  net/fastboot.c| 310 
> ++
>  net/net.c |   7 +
>  16 files changed, 1105 insertions(+), 16 deletions(-)
>  create mode 100644 drivers/fastboot/fb_command.c
>  create mode 100644 drivers/fastboot/fb_getvar.c
>  create mode 100644 include/net/fastboot.h
>  create mode 100644 net/fastboot.c

Reviewed-by: Simon Glass 

Please can you add function comments to the rest of the fastboot.h
stuff, see if you can remove the global variables in that file, and
also add function comments to non-trivial static functions?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] PCI: autoconfig: Don't allocate 64-bit addresses to 32-bit only resources

[Simon Glass]

Hi Tuomas,

On 14 May 2018 at 10:38, Tuomas Tynkkynen  wrote:
> Currently, if we happen to allocate an address requiring 64 bits to a
> device only supporting 32-bit BARs, the address eventually gets silently
> truncated to 32 bits. Avoid this by adding a new flag to
> pciauto_region_allocate() to bail out in such situations.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  drivers/pci/pci_auto.c| 6 --
>  drivers/pci/pci_auto_common.c | 7 ++-
>  drivers/pci/pci_auto_old.c| 5 +++--
>  include/pci.h | 2 +-
>  4 files changed, 14 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass 

Please can you add a function comment to pciauto_region_allocate()?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 11/13] ti: fastboot: Move weak overrides to board files

[Simon Glass]

On 14 May 2018 at 03:09, Alex Kiernan  wrote:
> Overriding fastboot_set_reboot_flag() in arch/arm/mach-omap2/boot-common.c
> leaves it applying all boards that derive from this, not just the ones which
> have support for Android bootloader flow. Move the weak function override to
> the relevant board files.
>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v3:
> - new
>
> Changes in v2: None
>
>  arch/arm/mach-omap2/boot-common.c | 10 --
>  board/ti/am57xx/board.c   | 10 ++
>  board/ti/dra7xx/evm.c | 10 ++
>  3 files changed, 20 insertions(+), 10 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 v3 08/13] fastboot: Fix parameter types in _fb_nand_write

[Simon Glass]

On 14 May 2018 at 03:09, Alex Kiernan  wrote:
> Compiling on a 64 bit target the arguments to _fb_nand_write are
> incompatible:
>
>   drivers/fastboot/fb_nand.c: In function ‘_fb_nand_write’:
>   drivers/fastboot/fb_nand.c:101:42: warning: passing argument 3 of 
> ‘nand_write_skip_bad’ from incompatible pointer type 
> [-Wincompatible-pointer-types]
> return nand_write_skip_bad(mtd, offset, , written,
>   ^
>   In file included from drivers/fastboot/fb_nand.c:16:0:
>   include/nand.h:107:5: note: expected ‘size_t * {aka long unsigned int *}’ 
> but argument is of type ‘unsigned int *’
>int nand_write_skip_bad(struct mtd_info *mtd, loff_t offset, size_t 
> *length,
>^~~
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v3:
> - new
>
> Changes in v2: None
>
>  drivers/fastboot/fb_nand.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] doc: qemu-arm: Drop highmem=off references

[Simon Glass]

On 14 May 2018 at 09:47, Tuomas Tynkkynen  wrote:
> Now that U-Boot works fine with highmem enabled, there is no need to
> tell users to disable highmem.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  doc/README.qemu-arm | 7 +++
>  1 file changed, 3 insertions(+), 4 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 v3 09/13] fastboot: Rename fb_set_reboot_flag to fastboot_set_reboot_flag

[Simon Glass]

On 14 May 2018 at 03:09, Alex Kiernan  wrote:
> Rename fb_set_reboot_flag to fastboot_set_reboot_flag so it matches
> all other fastboot code in the global name space. Fix the guards around
> them so that they're dependent on FASTBOOT, not just USB_FUNCTION_FASTBOOT.
>
> Move the weak implementation of fastboot_set_reboot_flag to fb_common.c
> so we can call it from non-USB fastboot code.
>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v3:
> - new
>
> Changes in v2: None
>
>  arch/arm/mach-omap2/boot-common.c | 4 ++--
>  arch/arm/mach-rockchip/rk3128-board.c | 4 ++--
>  arch/arm/mach-rockchip/rk322x-board.c | 4 ++--
>  board/amazon/kc1/kc1.c| 2 +-
>  board/lg/sniper/sniper.c  | 2 +-
>  drivers/fastboot/fb_common.c  | 5 +
>  drivers/usb/gadget/f_fastboot.c   | 7 +--
>  include/fastboot.h| 2 +-
>  8 files changed, 15 insertions(+), 15 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 4/6] scripts/dtc: Update to upstream version v1.4.6-9-gaadd0b65c987

[Simon Glass]

Hi,

On 13 May 2018 at 16:45, Eugeniu Rosca  wrote:
> Hi Simon,
>
> On Mon, May 14, 2018 at 08:00:40AM +1000, Simon Glass wrote:
>> Hi,
>>
>> On 13 May 2018 at 03:13, Eugeniu Rosca  wrote:
>> > From: Rob Herring 
>> >
>> > This adds the following commits from upstream:
>> >
>> > aadd0b65c987 checks: centralize printing of property names in failure 
>> > messages
>> > 88960e398907 checks: centralize printing of node path in check_msg
>> > f1879e1a50eb Add limited read-only support for older (V2 and V3) device 
>> > tree to libfdt.
>> > 37dea76e9700 srcpos: drop special handling of tab
>> > 65893da4aee0 libfdt: overlay: Add missing license
>> > 962a45ca034d Avoid installing pylibfdt when dependencies are missing
>> > cd6ea1b2bea6 Makefile: Split INSTALL out into 
>> > INSTALL_{PROGRAM,LIB,DATA,SCRIPT}
>> > 51b3a16338df Makefile.tests: Add LIBDL make(1) variable for portability 
>> > sake
>> > 333d533a8f4d Attempt to auto-detect stat(1) being used if not given proper 
>> > invocation
>> > e54388015af1 dtc: Bump version to v1.4.6
>> > a1fe86f380cb fdtoverlay: Switch from using alloca to malloc
>> > c8d5472de3ff tests: Improve compatibility with other platforms
>> > c81d389a10cc checks: add chosen node checks
>> > e671852042a7 checks: add aliases node checks
>> > d0c44ebe3f42 checks: check for #{size,address}-cells without child nodes
>> > 18a3d84bb802 checks: add string list check for *-names properties
>> > 8fe94fd6f19f checks: add string list check
>> > 6c5730819604 checks: add a string check for 'label' property
>> > a384191eba09 checks: fix sound-dai phandle with arg property check
>> > b260c4f610c0 Fix ambiguous grammar for devicetree rule
>> > fe667e382bac tests: Add some basic tests for the pci_bridge checks
>> > 7975f6422260 Fix widespread incorrect use of strneq(), replace with new 
>> > strprefixeq()
>> > fca296445eab Add strstarts() helper function
>> > cc392f089007 tests: Check non-matching cases for 
>> > fdt_node_check_compatible()
>> > bba26a5291c8 livetree: avoid assertion of orphan phandles with overlays
>> > c8f8194d76cc implement strnlen for systems that need it
>> > c8b38f65fdec libfdt: Remove leading underscores from identifiers
>> > 3b62fdaebfe5 Remove leading underscores from identifiers
>> > 2d45d1c5c65e Replace FDT_VERSION() with stringify()
>> > 2e6fe5a107b5 Fix some errors in comments
>> > b0ae9e4b0ceb tests: Correct warning in sw_tree1.c
>> >
>> > Commit c8b38f65fdec upstream ("libfdt: Remove leading underscores from
>> > identifiers") changed the multiple inclusion define protection, so the
>> > kernel's libfdt_env.h needs the corresponding update.
>> >
>> > Signed-off-by: Rob Herring 
>> > [ Linux commit: 9130ba884640328bb78aaa4840e5ddf06ccafb1c ]
>> > [erosca: - Fixup conflicts in include/linux/libfdt_env.h caused by 
>> > v2018.03-rc4
>> >commit b08c8c487083 ("libfdt: move headers to 
>> >and ")
>> >  - Fix build errors in lib/libfdt/fdt_ro.c, tools/libfdt/fdt_rw.c 
>> > by:
>> >- s/_fdt_mem_rsv/fdt_mem_rsv_/
>> >- s/_fdt_offset_ptr/fdt_offset_ptr_/
>> >- s/_fdt_check_node_offset/fdt_check_node_offset_/
>> >- s/_fdt_check_prop_offset/fdt_check_prop_offset_/
>> >- s/_fdt_find_add_string/fdt_find_add_string_/]
>> > Signed-off-by: Eugeniu Rosca 
>> > ---
>> >
>> > v1-v2:
>> > * Newly pushed
>> >
>> >  include/linux/libfdt_env.h   |   6 +-
>> >  lib/libfdt/fdt_ro.c  |  18 +-
>> >  scripts/dtc/checks.c | 439 ++-
>> >  scripts/dtc/dtc-parser.y |  17 +-
>> >  scripts/dtc/dtc.c|   7 +-
>> >  scripts/dtc/dtc.h|  11 +-
>> >  scripts/dtc/flattree.c   |   2 +-
>> >  scripts/dtc/libfdt/fdt.c |  13 +-
>> >  scripts/dtc/libfdt/fdt.h |   6 +-
>> >  scripts/dtc/libfdt/fdt_overlay.c |  51 
>> >  scripts/dtc/libfdt/fdt_ro.c  | 132 ++--
>> >  scripts/dtc/libfdt/fdt_rw.c  |  90 +++---
>> >  scripts/dtc/libfdt/fdt_sw.c  |  24 +-
>> >  scripts/dtc/libfdt/fdt_wip.c |  10 +-
>> >  scripts/dtc/libfdt/libfdt.h  |  37 +--
>> >  scripts/dtc/libfdt/libfdt_env.h  |  33 +-
>> >  scripts/dtc/libfdt/libfdt_internal.h |  32 +-
>> >  scripts/dtc/livetree.c   |  10 +-
>> >  scripts/dtc/srcpos.c |   5 -
>> >  scripts/dtc/srcpos.h |   6 +-
>> >  scripts/dtc/util.h   |   9 +-
>> >  scripts/dtc/version_gen.h|   2 +-
>> >  tools/libfdt/fdt_rw.c|   2 +-
>> >  23 files changed, 632 insertions(+), 330 deletions(-)
>>
>> Can you please check that this does not adversely impact code size?
>
> Sure. Here are the sizes before and after this patch (sandbox):
>
> 1. ELF size comparison shows 96 bytes increase
> $ du -b u-boot.before 

Re: [U-Boot] [PATCH v3 07/13] fastboot: Remove FIXME for CONFIG_FASTBOOT_...NAME

[Simon Glass]

On 14 May 2018 at 03:09, Alex Kiernan  wrote:
> CONFIG_FASTBOOT_GPT_NAME and CONFIG_FASTBOOT_MBR_NAME are always defined
> by Kconfig if you're compiling this code, so remove these redundant
> defaults.
>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v3:
> - new
>
> Changes in v2: None
>
>  drivers/fastboot/fb_mmc.c | 13 -
>  1 file changed, 13 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] net: [PATCH v10 3/3] Adding wget

[Simon Glass]

Hi Duncan,

On 14 May 2018 at 09:26, Duncan Hare  wrote:
> From: Simon Glass 
>
>
> To: Duncan Hare 
> Cc: "joe.hershber...@ni.com" ; U-Boot Mailing List
> 
> Sent: Sunday, May 13, 2018 3:00 PM
> Subject: Re: net: [U-Boot] [PATCH v10 3/3] Adding wget
>
>
>Please setup a test that can run in an environment without the
>Internet. That is critical for unit tests.
>
>Hand tests for Internet usage and the environmental effects are great,
>but that can't be what we include in the auto tests for repeat-ability
>reasons. Simon is asking for a separate type of test.

 Is the test environment another patch in the series or an addition to
 the
 wget patch?
>
>>I suggest a separate patch.
>>
>>Regards,
>>>Simon
>
> Separate patch, patch 4 of the series or a completely new patch?

Patch 4 in the series.

>
> Conceptual approach:
>
> apt-get install nginx (in debian)
>
> I'll provide a config file pointing to test kernel a a specified file
> location.
>
> Test kernel will be numbered lines of printable characters. Printable, not
> binary, easy to expand in a spreadsheet.
>
> Can the u-boot print command print sections of memory? That is
>
> print $loadaddr $length?
>
> That will work for small test kernels, or
>
> I tested by using tftp to download a kernel, then used a modified wget to
> download a seconf time and verify the
> downloads were identical.
>
> compare $loadaddr1 $loadaddr2 $length
>
> Is that a preferred approach?

You don't need to download a kernel. Just download a small file (say
10KB) that you generate in your test. You might find test_vboot.py and
test_net.py helpful. Something like:

- start an http server on localhost (in Python)
- put a single file in the server that can be read (generate 10KB of
known data?)
- run U-Boot with the commands to wget from that server
- check that U-Boot gets the expected file

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set

[Simon Glass]

On 14 May 2018 at 09:47, Tuomas Tynkkynen  wrote:
> Currently, qemu_arm_defconfig and qemu_arm64_defconfig only work with
> the 'highmem=off' parameter passed to QEMU's virt machine. The reason is
> that when 'highmem' is not disabled, QEMU appends 64-bit a memory
> resource to the PCI controller's regions property in DT in addition to
> the 32-bit PCI memory window in low memory. And the current DT parsing
> code picks the last (thus the 64-bit one) memory resource, whose address
> eventually gets silently truncated to 32 bits because
> CONFIG_SYS_PCI_64BIT is not set, which obviously causes PCI to break.
>
> Avoid this problem by ignoring memory regions whose addresses are above
> the 32-bit boundary when CONFIG_SYS_PCI_64BIT is not set.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  drivers/pci/pci-uclass.c | 7 +++
>  1 file changed, 7 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 2/3] ARM: qemu-arm: Bump RAM size in AArch64 MMU table

[Simon Glass]

On 14 May 2018 at 09:47, Tuomas Tynkkynen  wrote:
> Now that PCI devices work with highmem-enabled QEMU emulation, bump up
> the RAM size in the MMU tables to gain access to the full 255 GB of RAM
> potential instead of the puny 3 GB.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
>  board/emulation/qemu-arm/qemu-arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] spl: Add full fitImage support

[Simon Glass]

Hi Marek,

On 13 May 2018 at 16:22, Marek Vasut  wrote:
> On 05/14/2018 12:02 AM, Simon Glass wrote:
>> On 13 May 2018 at 08:23, Marek Vasut  wrote:
>>> Add support for loading U-Boot and optionally FDT from a fitImage
>>> in SPL by using the full fitImage support from U-Boot. While we do
>>> have limited SPL loading support in SPL with a small footprint, it
>>> is missing a lot of important features, like checking signatures.
>>> This support has all the fitImage features, while the footprint is
>>> obviously larger.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Pantelis Antoniou 
>>> Cc: Simon Glass 
>>> ---
>>> V2: - Drop blank line below spl_load_fit_image()
>>> - Explicitly enable image verification if available
>>> ---
>>>  Kconfig  | 11 +
>>>  common/spl/spl.c | 74 
>>> 
>>>  2 files changed, 85 insertions(+)
>>>
>>
>> Reviewed-by: Simon Glass 
>>
>> Can you add this to the FIT tests?
>
> Yeah, do you have some pointers for me ?

The current test is in test/py/tests/test_fit.py so you can start with
that, or create a new one based on it.

At present we have sandbox_spl which includes SPL support. If you run
a test with that (i.e. CONFIG_SPL set) it will run SPL, which in turn
will load U-Boot. The logic for that is in u_boot_console_sandbox.py
and the function which actually loads U-Boot is
spl_board_load_image().

So I think you could create a FIT with U-Boot and a DTB in it, then
modify spl_board_load_image() to use that instead. Then your test
could simply check the console output. For example test_ofplatdata.py
shows how to find a string in the output, although at present that
test does nothing, since there is no way to tell SPL to output the
platdata.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] mach-snapdragon: Introduce pinctrl driver

[Simon Glass]

Hi Ramon,

On 14 May 2018 at 01:10, Ramon Fried  wrote:
> On Mon, May 14, 2018 at 1:00 AM, Simon Glass  wrote:
>> Hi Ramon,
>>
>> On 12 May 2018 at 20:15, Ramon Fried  wrote:
>>> This patch adds pinmux and pinctrl driver for TLMM
>>> subsystem in snapdragon chipsets.
>>> Currently, supporting only 8016, but implementation is
>>> generic and 8096 can be added easily.
>>>
>>> Driver is using the generic dt-bindings and doesn't
>>> introduce any new bindings (yet).
>>>
>>> Signed-off-by: Ramon Fried 
>>> ---
>>>  arch/arm/mach-snapdragon/Makefile|   2 +
>>>  arch/arm/mach-snapdragon/pinctrl-apq8016.c   | 162 
>>> +++
>>>  arch/arm/mach-snapdragon/pinctrl-snapdragon.c| 118 +
>>>  arch/arm/mach-snapdragon/pinctrl-snapdragon.h|  21 +++
>>>  configs/dragonboard410c_defconfig|   5 +
>>>  include/dt-bindings/pinctrl/pinctrl-snapdragon.h |  22 +++
>>>  6 files changed, 330 insertions(+)
>>>  create mode 100644 arch/arm/mach-snapdragon/pinctrl-apq8016.c
>>>  create mode 100644 arch/arm/mach-snapdragon/pinctrl-snapdragon.c
>>>  create mode 100644 arch/arm/mach-snapdragon/pinctrl-snapdragon.h
>>>  create mode 100644 include/dt-bindings/pinctrl/pinctrl-snapdragon.h
>>>
>>> diff --git a/arch/arm/mach-snapdragon/Makefile 
>>> b/arch/arm/mach-snapdragon/Makefile
>>> index 1c23dc52cf..1d35fea912 100644
>>> --- a/arch/arm/mach-snapdragon/Makefile
>>> +++ b/arch/arm/mach-snapdragon/Makefile
>>> @@ -6,4 +6,6 @@ obj-$(CONFIG_TARGET_DRAGONBOARD820C) += clock-apq8096.o
>>>  obj-$(CONFIG_TARGET_DRAGONBOARD820C) += sysmap-apq8096.o
>>>  obj-$(CONFIG_TARGET_DRAGONBOARD410C) += clock-apq8016.o
>>>  obj-$(CONFIG_TARGET_DRAGONBOARD410C) += sysmap-apq8016.o
>>> +obj-$(CONFIG_TARGET_DRAGONBOARD410C) += pinctrl-apq8016.o
>>> +obj-$(CONFIG_TARGET_DRAGONBOARD410C) += pinctrl-snapdragon.o
>>>  obj-y += clock-snapdragon.o
>>> diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c 
>>> b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
>>> new file mode 100644
>>> index 00..8e57e2338c
>>> --- /dev/null
>>> +++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
>>> @@ -0,0 +1,162 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Qualcomm APQ8016 pinctrl
>>> + *
>>> + * (C) Copyright 2018 Ramon Fried 
>>> + *
>>> + */
>>> +
>>> +#include "pinctrl-snapdragon.h"
>>> +#include 
>>> +
>>> +const char * const msm_pinctrl_pins[] = {
>>> +   "GPIO_0",
>>> +   "GPIO_1",
>>> +   "GPIO_2",
>>> +   "GPIO_3",
>>> +   "GPIO_4",
>>> +   "GPIO_5",
>>> +   "GPIO_6",
>>> +   "GPIO_7",
>>
>> This seems inefficient. Could you not sprintf() the name for most of
>> these values?
> The origin of this table is from the Linux kernel driver.
> I'm not sure I understand how sprintf will more efficient, do you want
> to fill up this table on runtime ?

I think this table is only used in one function, so you could create
the string there perhaps?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] arm: zynq: Add initial support for Avnet MiniZed

[Ibai Erkiaga Elorza]

Hi Michal,

> -Original Message-
> From: Michal Simek [mailto:michal.si...@xilinx.com]
> Sent: 10 May 2018 09:21
> To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de
> Cc: michal.si...@xilinx.com
> Subject: Re: [PATCH v2] arm: zynq: Add initial support for Avnet MiniZed
> 
> On 9.5.2018 17:56, Ibai Erkiaga wrote:
> > Initial support for Avnet MiniZed board. Tested UART1 (serial
> > console), QSPI(Flash), SDHCI1 (eMMC), USB.
> >
> > Signed-off-by: Ibai Erkiaga 
> > ---
> > Changes for v2:
> > -board model changed to use Avent prefix
> > -usb phy driver changed usb-no-xceiv
> > -removed gpio and intc binding
> > -fixed-partitions usage
> > ---
> > U-Boot 2018.05-00023-gdf332c1-dirty (May 09 2018 - 14:50:51 +0100)
> >
> > Model: Avnet Zynq MiniZed Development Board
> > Board: Xilinx Zynq
> > Silicon: v3.1
> > DRAM:  ECC disabled 512 MiB
> > MMC:   sdhci@e0101000: 0
> > Loading Environment from SPI Flash... SF: Detected n25q128 with page
> > size 256 Bytes, erase size 64 KiB, total 16 MiB OK
> > In:serial@e0001000
> > Out:   serial@e0001000
> > Err:   serial@e0001000
> > Net:   No ethernet found.
> > Hit any key to stop autoboot:  0
> > Zynq> fatls mmc 0
> >  16783864   image.ub
> >   183   wpa_supplicant.conf
> >   1391116   smallboot.bin
> >
> > 3 file(s), 0 dir(s)
> >
> > Zynq> sf probe 0 0 0
> > SF: Detected n25q128 with page size 256 Bytes, erase size 64 KiB,
> > total 16 MiB
> > Zynq> usb start
> > starting USB...
> > USB0:   USB EHCI 1.00
> > scanning bus 0 for devices... 2 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> > Zynq> fatls usb 0
> >12   test.txt
> >
> > 1 file(s), 0 dir(s)
> >
> > Zynq>
> > ---
> >  arch/arm/dts/Makefile  |1 +
> >  arch/arm/dts/zynq-minized.dts  |  104
> 
> >  configs/zynq_minized_defconfig |   68 ++
> >  3 files changed, 173 insertions(+), 0 deletions(-)  create mode
> > 100644 arch/arm/dts/zynq-minized.dts  create mode 100644
> > configs/zynq_minized_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> > 6fe93a8..5c5f8a8 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -129,6 +129,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
> > zynq-cc108.dtb \
> > zynq-cse-qspi-single.dtb \
> > zynq-microzed.dtb \
> > +   zynq-minized.dtb \
> > zynq-picozed.dtb \
> > zynq-syzygy-hub.dtb \
> > zynq-topic-miami.dtb \
> > diff --git a/arch/arm/dts/zynq-minized.dts
> > b/arch/arm/dts/zynq-minized.dts new file mode 100644 index
> > 000..68fe09a
> > --- /dev/null
> > +++ b/arch/arm/dts/zynq-minized.dts
> > @@ -0,0 +1,104 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * dts file for Avnet MiniZed board
> > + *
> > + * (C) Copyright 2017 - 2018, Xilinx, Inc.
> > + *
> > + * Ibai Erkiaga   */
> > +
> > +/dts-v1/;
> > +#include "zynq-7000.dtsi"
> > +
> > +/ {
> > +   model = "Avnet Zynq MiniZed Development Board";
> > +   compatible = "avnet,minized", "xlnx,zynq-7000";
> > +
> > +   aliases {
> > +   serial0 = 
> > +   serial1 = 
> > +   spi0 = 
> > +   mmc0 = 
> > +   };
> > +
> > +   memory@0 {
> > +   device_type = "memory";
> > +   reg = <0x0 0x2000>;
> > +   };
> > +
> > +   chosen {
> > +   bootargs = "";
> > +   stdout-path = "serial0:115200n8";
> > +   };
> > +
> > +   usb_phy0: phy0 {
> > +   compatible = "usb-nop-xceiv";
> > +   #phy-cells = <0>;
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +   is-dual = <0>;
> > +   num-cs = <1>;
> > +   flash@0 {
> > +   compatible = "micron,m25p128";
> > +   reg = <0x0>;
> > +   spi-tx-bus-width = <4>;
> > +   spi-rx-bus-width = <4>;
> > +   spi-max-frequency = <5000>;
> > +   partitions {
> > +   compatible = "fixed-partitions";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   partition@0 {
> > +   label = "boot";
> > +   reg = <0x0 0xff>;
> > +   };
> > +
> > +   partition@027 {
> 
> remove this leading zero.
> 
> > +   label = "kernel";
> > +   reg = <0x27 0xd8>;
> > +   };
> > +
> > +   partition@ff {
> > +   label = "bootenv";
> > +   reg = <0xff 0x1>;
> > +   };
> > +
> > +   partition@100 {
> > +   label = "spare";
> > +   reg = <0x100 0x0>;
> > +   };
> > +   };
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   

Re: [U-Boot] [PATCH] ARM: socfpga: Put stack at the end of SRAM

[Simon Goldschmidt]

On 14.05.2018 17:51, Stefan Roese wrote:

On 14.05.2018 11:06, Marek Vasut wrote:

On 05/14/2018 11:01 AM, Simon Goldschmidt wrote:



On 14.05.2018 10:17, Marek Vasut wrote:

On 05/14/2018 10:03 AM, Simon Goldschmidt wrote:

On 12.05.2018 22:27, Marek Vasut wrote:

The global data are in the .data section, so there's no point in
reserving any space for it above stack. Put stack at the end of
SRAM.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
---
    include/configs/socfpga_common.h | 4 +---
    1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/configs/socfpga_common.h
b/include/configs/socfpga_common.h
index 4de2aa7929..cb67d539b1 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -35,10 +35,8 @@
    #define CONFIG_SYS_INIT_RAM_ADDR    0xFFE0
    #define CONFIG_SYS_INIT_RAM_SIZE    0x4 /* 256KB */
    #endif
-#define CONFIG_SYS_INIT_SP_OFFSET    \
-    (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
    #define CONFIG_SYS_INIT_SP_ADDR    \
-    (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
+    (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)


I think this interferes with the bootcount being stored at the end of
SRAM. See the defconfigs of 'is1' and 'sr1500' boards - or my local
defconfig here :-)

I'd really like to keep some room here for bootcounter and some 
related

things I store here.


So if I understand it correctly, before this patch, the boards 
overwrote

the global data ?


Ehrm, reading up on the init code path in the S and C files, it seems
like that, yes. I just used the two boards as an example. Are they
actively maintained? get_maintainer.pl shows the boards are maintained
by denx, so maybe you could clarify this?


+CC Stefan.


Thanks. At the time I added the bootcounter support on this platform,
it used to work. I might have missed something though. Right now,
I don't have access to such a platform, so its hard for me to test
something. If you have some patches to fix any potential overlapping
memory usages, I'll gladly review them.


I just checked out ae996c80 and from what I can tell, the RAM layout was 
the same at that time: include/generated/generated-asm-offsets.h contains:

- #define GENERATED_GBL_DATA_SIZE 208
- #define GD_SIZE 200

That leaves us with an 8 byte alignment gap at the end of the SRAM and 
that's where the boot counter is located. So the global data is not 
overwritten, but this is more or less by chance, any change to the 
struct definition might change this.


Looking at just another example: the x600 board defines its SRAM_SIZE 8 
bytes smaller than what it really is. That seems like a good idea for 
socfpga, too. I'll see if I can provide a patch.


Slightly off-topic: I have a constellation where the boot-counter is not 
reset although the power has been pulled. This device has big capacitors 
and the SRAM content seems to survive although the processor is reset. 
To me it seems as if looking at the boot reason might be safer than 
checking for a magic word... Any ideas?


Thanks,
Simon




Chances are high that these bytes just fit into the 16-byte alignment
allocated by GENERATED_GBL_DATA_SIZE (and on my board it *is* like 
that).




Anyway, if you need some extra space, look at
board_init_f_alloc_reserve() .



OK, but that function does not seem to be overridable? How can I reserve
my own memory here?


Add a __weak there I guess ?


And reading this function, I guess your commit message is a bit
misleading. It seems that the purpose of CONFIG_SYS_INIT_SP_OFFSET like
it was was to reserve memory for the initial gd (before relocation),
which is now done in board_init_f_alloc_reserve().


The code is confusing as hell, I give you that.


Thanks,
Stefan


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 03/25] tpm: disociate TPMv1.x specific and generic code

[Tom Rini]

On Mon, May 14, 2018 at 08:01:57PM +0200, Miquel Raynal wrote:
> Hi Simon,
> 
> On Wed, 2 May 2018 20:31:48 -0600, Simon Glass  wrote:
> 
> > Hi Miquel,
> > 
> > On 2 May 2018 at 02:59, Miquel Raynal  wrote:
> > > There are no changes in this commit unless:
> > > 1/ a new organization of the code as follow.
> > > 2/ some *very* basic checkpatch.pl corrections that polluated my reports
> > >like s/uint_t/u/, blank spaces and non-aligned parameters on
> > >parenthesis.
> > >
> > > * cmd/ directory:  
> > > > move existing code from cmd/tpm.c in cmd/tpm-common.c
> > > > move specific code in cmd/tpm-v1.c
> > > > create a specific header file with generic definitions for  
> > >   commands only called cmd/tpm-user-utils.h
> > >
> > > * lib/ directory:  
> > > > move existing code from lib/tpm.c in lib/tpm-common.c
> > > > move specific code in lib/tpm-v1.c
> > > > create a specific header file with generic definitions for  
> > >   the library itself called lib/tpm-utils.h
> > >
> > > * include/ directory:  
> > > > move existing code from include/tpm.h in include/tpm-common.h
> > > > move specific code in include/tpm-v1.h  
> > >
> > > Code designated as 'common' is compiled if TPM are used. Code designated
> > > as 'specific' is compiled only if the right specification has been
> > > selected.
> > >
> > > All files include tpm-common.h.
> > > Files in cmd/ include tpm-user-utils.h.
> > > Files in lib/ include tpm-utils.h.
> > > Depending on the specification, files may include either (not both)
> > > tpm-v1.h or tpm-v2.h.
> > >
> > > Signed-off-by: Miquel Raynal 
> > > ---
> > >  cmd/Makefile   |   3 +-
> > >  cmd/tpm-common.c   | 289 
> > > +++
> > >  cmd/tpm-user-utils.h   |  25 +++
> > >  cmd/{tpm.c => tpm-v1.c}| 305 
> > > ++---
> > >  cmd/tpm_test.c |   2 +-
> > >  drivers/tpm/tpm-uclass.c   |   4 +-
> > >  drivers/tpm/tpm_atmel_twi.c|   2 +-
> > >  drivers/tpm/tpm_tis_infineon.c |   2 +-
> > >  drivers/tpm/tpm_tis_lpc.c  |   2 +-
> > >  drivers/tpm/tpm_tis_sandbox.c  |   2 +-
> > >  drivers/tpm/tpm_tis_st33zp24_i2c.c |   2 +-
> > >  drivers/tpm/tpm_tis_st33zp24_spi.c |   2 +-
> > >  include/tpm-common.h   | 214 ++
> > >  include/{tpm.h => tpm-v1.h}| 274 
> > > ++---
> > >  lib/Makefile   |   3 +-
> > >  lib/tpm-common.c   | 189 +++
> > >  lib/tpm-utils.h|  96 
> > >  lib/{tpm.c => tpm-v1.c}| 248 +-
> > >  18 files changed, 886 insertions(+), 778 deletions(-)
> > >  create mode 100644 cmd/tpm-common.c
> > >  create mode 100644 cmd/tpm-user-utils.h
> > >  rename cmd/{tpm.c => tpm-v1.c} (76%)
> > >  create mode 100644 include/tpm-common.h
> > >  rename include/{tpm.h => tpm-v1.h} (62%)
> > >  create mode 100644 lib/tpm-common.c
> > >  create mode 100644 lib/tpm-utils.h
> > >  rename lib/{tpm.c => tpm-v1.c} (81%)
> > >  
> > 
> > This is a bit hard to review as there is so much going on.
> > 
> > Can you do the patman/chcekpatch clean-up in a separate patch before
> > this one? Then hopefully most of this becomes just a rename?
> 
> I understand your point and made all the checkpatch.pl changes in
> different commits previously to this one.
> 
> Unfortunately, as I split one file ( being include/cmd/lib):
> - /tpm.x
> in two files:
> - /tpm-common.x
> - /tpm-v1.x
> 
> There will never be just a rename :/
> 
> > 
> > Also do you have to do it all at once in one patch? It seem slike you
> > could move lib/ around separately from cmd/ for example.
> > 
> > At present all I can give is a rubber stamp.
> 
> I think it would add more changes doing so because of the includes
> being renamed. Plus, I don't think the understanding would be enhanced
> as the point of this commit is to clearly separate shared code and
> specific code for TPMv1 only chips. From my point of view doing so in
> several commits does not clarify the goal, nor it would simplify the
> review :(
> 
> Otherwise, in the next version there will be nothing more than just code
> moves in this commit.
> 
> Hope this new split of the changes will be enough?

You're really sure you've only got just file renames, content moving and
related header additions here?  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 1/6] kconfig: re-sync with Linux 4.17-rc4

[Petr Vorel]

Hi Eugeniu, Masahiro,

> > So, it seems like all the trailing white-space from above files
> > disappeared on your branch, after applying the patches from the
> > email client (who did this?...).

> > I didn't expect that trailing white-space to be of any value for the
> > test results, but it turns out it is! With the whitespace removed, I can
> > also reproduce the failures of "make testconfig".

> Right.
> Whitespaces are precious in the expected_stdout files.
> Do not rip them off.



> > I am not familiar with pytest, but, based on what we see here, it looks
> > like every single character stored in *xpected_stdout files (including
> > whitespace at the end of lines) matters for the test to pass.

> > I wonder if Kconfig could avoid printing whitespace in command line
> > user dialogs. Then maybe those space characters could be removed from
> > the "*xpected_stdout" files.

BTW this topic is more for linux-kbuild, than u-boot.


> 'make config' display a space at the end of line
> when prompting user input.

> This makes the input readable, like follows:

> *
> * Linux/x86 4.17.0-rc4 Kernel Configuration
> *
> 64-bit kernel (64BIT) [Y/n/?] y
> *
> * General setup
> *
> Cross-compiler tool prefix (CROSS_COMPILE) []
> Compile also drivers which will not load (COMPILE_TEST) [N/y/?] y



> I think you are suggesting to remove a space, like follows:

> *
> * Linux/x86 4.17.0-rc4 Kernel Configuration
> *
> 64-bit kernel (64BIT) [Y/n/?]y
> *
> * General setup
> *
> Cross-compiler tool prefix (CROSS_COMPILE) []
> Compile also drivers which will not load (COMPILE_TEST) [N/y/?]y




> I believe we should not do this
> just for unit-testing.
Yes, that wouldn't make sense.
I just have to be careful when applying patches :)

> > Masahiro?

> > Thanks again!

> > Best regards,
> > Eugeniu.


Kind regards,
Petr
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 03/25] tpm: disociate TPMv1.x specific and generic code

[Miquel Raynal]

Hi Simon,

On Wed, 2 May 2018 20:31:48 -0600, Simon Glass  wrote:

> Hi Miquel,
> 
> On 2 May 2018 at 02:59, Miquel Raynal  wrote:
> > There are no changes in this commit unless:
> > 1/ a new organization of the code as follow.
> > 2/ some *very* basic checkpatch.pl corrections that polluated my reports
> >like s/uint_t/u/, blank spaces and non-aligned parameters on
> >parenthesis.
> >
> > * cmd/ directory:  
> > > move existing code from cmd/tpm.c in cmd/tpm-common.c
> > > move specific code in cmd/tpm-v1.c
> > > create a specific header file with generic definitions for  
> >   commands only called cmd/tpm-user-utils.h
> >
> > * lib/ directory:  
> > > move existing code from lib/tpm.c in lib/tpm-common.c
> > > move specific code in lib/tpm-v1.c
> > > create a specific header file with generic definitions for  
> >   the library itself called lib/tpm-utils.h
> >
> > * include/ directory:  
> > > move existing code from include/tpm.h in include/tpm-common.h
> > > move specific code in include/tpm-v1.h  
> >
> > Code designated as 'common' is compiled if TPM are used. Code designated
> > as 'specific' is compiled only if the right specification has been
> > selected.
> >
> > All files include tpm-common.h.
> > Files in cmd/ include tpm-user-utils.h.
> > Files in lib/ include tpm-utils.h.
> > Depending on the specification, files may include either (not both)
> > tpm-v1.h or tpm-v2.h.
> >
> > Signed-off-by: Miquel Raynal 
> > ---
> >  cmd/Makefile   |   3 +-
> >  cmd/tpm-common.c   | 289 
> > +++
> >  cmd/tpm-user-utils.h   |  25 +++
> >  cmd/{tpm.c => tpm-v1.c}| 305 
> > ++---
> >  cmd/tpm_test.c |   2 +-
> >  drivers/tpm/tpm-uclass.c   |   4 +-
> >  drivers/tpm/tpm_atmel_twi.c|   2 +-
> >  drivers/tpm/tpm_tis_infineon.c |   2 +-
> >  drivers/tpm/tpm_tis_lpc.c  |   2 +-
> >  drivers/tpm/tpm_tis_sandbox.c  |   2 +-
> >  drivers/tpm/tpm_tis_st33zp24_i2c.c |   2 +-
> >  drivers/tpm/tpm_tis_st33zp24_spi.c |   2 +-
> >  include/tpm-common.h   | 214 ++
> >  include/{tpm.h => tpm-v1.h}| 274 ++---
> >  lib/Makefile   |   3 +-
> >  lib/tpm-common.c   | 189 +++
> >  lib/tpm-utils.h|  96 
> >  lib/{tpm.c => tpm-v1.c}| 248 +-
> >  18 files changed, 886 insertions(+), 778 deletions(-)
> >  create mode 100644 cmd/tpm-common.c
> >  create mode 100644 cmd/tpm-user-utils.h
> >  rename cmd/{tpm.c => tpm-v1.c} (76%)
> >  create mode 100644 include/tpm-common.h
> >  rename include/{tpm.h => tpm-v1.h} (62%)
> >  create mode 100644 lib/tpm-common.c
> >  create mode 100644 lib/tpm-utils.h
> >  rename lib/{tpm.c => tpm-v1.c} (81%)
> >  
> 
> This is a bit hard to review as there is so much going on.
> 
> Can you do the patman/chcekpatch clean-up in a separate patch before
> this one? Then hopefully most of this becomes just a rename?

I understand your point and made all the checkpatch.pl changes in
different commits previously to this one.

Unfortunately, as I split one file ( being include/cmd/lib):
- /tpm.x
in two files:
- /tpm-common.x
- /tpm-v1.x

There will never be just a rename :/

> 
> Also do you have to do it all at once in one patch? It seem slike you
> could move lib/ around separately from cmd/ for example.
> 
> At present all I can give is a rubber stamp.

I think it would add more changes doing so because of the includes
being renamed. Plus, I don't think the understanding would be enhanced
as the point of this commit is to clearly separate shared code and
specific code for TPMv1 only chips. From my point of view doing so in
several commits does not clarify the goal, nor it would simplify the
review :(

Otherwise, in the next version there will be nothing more than just code
moves in this commit.

Hope this new split of the changes will be enough?

> 
> Regards,
> Simon

Thanks,
Miquèl

-- 
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] u-boot on raspberry pi cm3

[Jan Leonhardt]

Hello List,

i am new here and in embedded development (more a Javascript/Java developer)

currently i have to port android to an raspberry pi cm3 and like to use
u-boot.

what works already:
* boot into u-boot
* boot into android
* boot into u-boot into android

so far so good. now i have to store a variable into the environment of
u-boot. here i got stuck. any try to write somewhere from u-boot leads
in a endless loop of the following message:
fsm 1, hsts 0001

it doesn't matter if i use saveenv, fatwrite or ext4write

some google result on that says the sd-card is bat and should be
changed. but on cm3 there is no sd-card. its a flash storage directly on
the compute module itself. and i tried more than on module. all with the
same result. and i can write in usb-storage mode from any other device
and from inside the booted android to this storage. so i think there
might be a fundamental problem with writing to the flash from u-boot.

does anybody have some hints/points to look into?

i tried current master (v2018.05) and next branches. same result.


here some serial output:

U-Boot 2018.05-00181-g62d77cea31-dirty (May 14 2018 - 13:41:23 +0200)

DRAM:  944 MiB
RPI Compute Module 3 (0xa020a0)
MMC:   mmc@7e202000: 0, sdhci@7e30: 1
Loading Environment from FAT... WARNING at
drivers/mmc/bcm2835_sdhost.c:435/bcm2835_send_command()!
WARNING at drivers/mmc/bcm2835_sdhost.c:435/bcm2835_send_command()!
*** Warning - bad CRC, using default environment

Failed (-5)
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   scanning bus 0 for devices...
Error: smsc95xx_eth address not set.
2 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
WARNING at drivers/mmc/bcm2835_sdhost.c:435/bcm2835_send_command()!
WARNING at drivers/mmc/bcm2835_sdhost.c:435/bcm2835_send_command()!
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr.uimg
4489 bytes read in 3 ms (1.4 MiB/s)
## Executing script at 0200
Loading uImage...
6143256 bytes read in 785 ms (7.5 MiB/s)
Loading uRamdisk...
1562965 bytes read in 202 ms (7.4 MiB/s)

-- 
Mit freundlichen Grüßen / With kind regards

Jan Leonhardt

IT-Dienstleistungen
IT-Konsultant
Administration
Softwareentwicklung



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] PCI: autoconfig: Don't allocate 64-bit addresses to 32-bit only resources

[Tuomas Tynkkynen]

Currently, if we happen to allocate an address requiring 64 bits to a
device only supporting 32-bit BARs, the address eventually gets silently
truncated to 32 bits. Avoid this by adding a new flag to
pciauto_region_allocate() to bail out in such situations.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/pci/pci_auto.c| 6 --
 drivers/pci/pci_auto_common.c | 7 ++-
 drivers/pci/pci_auto_old.c| 5 +++--
 include/pci.h | 2 +-
 4 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index d1feb503a0..d7237f6eee 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -98,7 +98,8 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
bars_num,
}
 
if (!enum_only && pciauto_region_allocate(bar_res, bar_size,
- _value) == 0) {
+ _value,
+ found_mem64) == 0) {
/* Write it out and update our limit */
dm_pci_write_config32(dev, bar, (u32)bar_value);
 
@@ -140,7 +141,8 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
bars_num,
debug("PCI Autoconfig: ROM, size=%#x, ",
  (unsigned int)bar_size);
if (pciauto_region_allocate(mem, bar_size,
-   _value) == 0) {
+   _value,
+   false) == 0) {
dm_pci_write_config32(dev, rom_addr,
  bar_value);
}
diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
index d90dbcf91a..183787333e 100644
--- a/drivers/pci/pci_auto_common.c
+++ b/drivers/pci/pci_auto_common.c
@@ -32,7 +32,7 @@ void pciauto_region_align(struct pci_region *res, pci_size_t 
size)
 }
 
 int pciauto_region_allocate(struct pci_region *res, pci_size_t size,
-   pci_addr_t *bar)
+   pci_addr_t *bar, bool supports_64bit)
 {
pci_addr_t addr;
 
@@ -48,6 +48,11 @@ int pciauto_region_allocate(struct pci_region *res, 
pci_size_t size,
goto error;
}
 
+   if (upper_32_bits(addr) && !supports_64bit) {
+   debug("Cannot assign 64-bit address to 32-bit-only resource\n");
+   goto error;
+   }
+
res->bus_lower = addr + size;
 
debug("address=0x%llx bus_lower=0x%llx\n", (unsigned long long)addr,
diff --git a/drivers/pci/pci_auto_old.c b/drivers/pci/pci_auto_old.c
index bc119fba87..e705a3072e 100644
--- a/drivers/pci/pci_auto_old.c
+++ b/drivers/pci/pci_auto_old.c
@@ -108,7 +108,8 @@ void pciauto_setup_device(struct pci_controller *hose,
}
 
 #ifndef CONFIG_PCI_ENUM_ONLY
-   if (pciauto_region_allocate(bar_res, bar_size, _value) == 
0) {
+   if (pciauto_region_allocate(bar_res, bar_size,
+   _value, found_mem64) == 0) {
/* Write it out and update our limit */
pci_hose_write_config_dword(hose, dev, bar, 
(u32)bar_value);
 
@@ -150,7 +151,7 @@ void pciauto_setup_device(struct pci_controller *hose,
debug("PCI Autoconfig: ROM, size=%#x, ",
  (unsigned int)bar_size);
if (pciauto_region_allocate(mem, bar_size,
-   _value) == 0) {
+   _value, false) == 0) {
pci_hose_write_config_dword(hose, dev, rom_addr,
bar_value);
}
diff --git a/include/pci.h b/include/pci.h
index cda6907688..127d3c6a6f 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -681,7 +681,7 @@ void pciauto_region_init(struct pci_region *res);
 void pciauto_region_align(struct pci_region *res, pci_size_t size);
 void pciauto_config_init(struct pci_controller *hose);
 int pciauto_region_allocate(struct pci_region *res, pci_size_t size,
-   pci_addr_t *bar);
+   pci_addr_t *bar, bool supports_64bit);
 
 #if !defined(CONFIG_DM_PCI) || defined(CONFIG_DM_PCI_COMPAT)
 extern int pci_hose_read_config_byte_via_dword(struct pci_controller *hose,
-- 
2.16.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] PCI: Add newlines to debug prints in pci_auto_common.c

[Tuomas Tynkkynen]

All of the debug output from this file is squished to one line. Fix
it.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/pci/pci_auto_common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
index 1d202ae2ef..d90dbcf91a 100644
--- a/drivers/pci/pci_auto_common.c
+++ b/drivers/pci/pci_auto_common.c
@@ -37,7 +37,7 @@ int pciauto_region_allocate(struct pci_region *res, 
pci_size_t size,
pci_addr_t addr;
 
if (!res) {
-   debug("No resource");
+   debug("No resource\n");
goto error;
}
 
@@ -50,7 +50,7 @@ int pciauto_region_allocate(struct pci_region *res, 
pci_size_t size,
 
res->bus_lower = addr + size;
 
-   debug("address=0x%llx bus_lower=0x%llx", (unsigned long long)addr,
+   debug("address=0x%llx bus_lower=0x%llx\n", (unsigned long long)addr,
  (unsigned long long)res->bus_lower);
 
*bar = addr;
-- 
2.16.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,3/3] mmc: support writing sparse images

[Alex Kiernan]

On Mon, May 14, 2018 at 3:47 PM Tom Rini  wrote:

> On Mon, May 14, 2018 at 06:42:41PM +0530, Jassi Brar wrote:
> > Hi Tom,
> >
> > On Tue, May 8, 2018 at 10:45 PM, Tom Rini  wrote:
> > > On Fri, Apr 06, 2018 at 12:05:24PM +0530, jassisinghb...@gmail.com
wrote:
> > >
> > >> From: Jassi Brar 
> > >>
> > >> Provide an alternate path for sparse-images to be
> > >> written to MMC. For example, via tftp on platforms
> > >> that don't support fastboot protocol. Or when an
> > >> image is to written at some offset, rather than the
> > >> start of a partition.
> > >>
> > >> Signed-off-by: Jassi Brar 
> > >
> > > Applied to u-boot/master, thanks!
> >
> > I see you modified the patch to protect the feature with
> > CONFIG_FASTBOOT_FLASH, which kills the purpose -- this feature is for
> > platforms that don't support fastboot.
> >
> > Do you want me to send the patch to revert the protection?

> Sorry, I guess maybe things weren't clear enough all around, and we
> should (functionally) revert patches 2 and 3 and try something
> different.  It is OK to say "lets make writing sparse images more widely
> available".  It's not OK to make every platform with MMC write grow a
> decent bit in binary size.  Making a quick pass at re-enabling things on
> a platform without fastboot support already grew things by nearly 2KiB.
> The other part which is I believe got me down this path was that without
> a change to common/Makefile to always (outside of SPL) include
> common/image-sparse.o things don't link.

> In sum, a new patch to add an option to allow people to opt-in for
> swrite would be good.  And please make sure to do something like:
> diff --git a/common/Makefile b/common/Makefile
> index d0681c7dd96a..92b2aa1ca8f0 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -120,6 +120,7 @@ ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
>   obj-y += fb_nand.o
>   endif
>   endif
> +obj-$(CONFIG_MMC_WRITE) += image-sparse.o
>   endif

Isn't this just move image-sparse to lib and add a separate guard for it
(LIB_IMAGE_SPARSE?) which can be selected by both FASTBOOT and a new
command symbol (CMD_MMC_SWRITE)?

This is all overlapping with the UDP fastboot code I've been posting, so
I'd kinda like it to fit nicely with that, rather than have to refactor it
to fit something different!

--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

I had a bit more time to look into this and it looks as if we have two 
problem-spots...

First, there's a type-mismatch between ram_info.size (a size_t) and gd.ram_size 
(phys_size_t).
While we can increase the size of a phys_size_t to 64bit (by defining 
CONFIG_PHYS_64BIT),
the size_t will always be an unsigned int on a 32bit arm architecture.  So 
here’s one possible
pitfall that should be resolved.

Once this is adjusted, we might just increase the width of ram_info.size to 
64bit by enabling
CONFIG_PHYS_64BIT … however, this comes with a caveat: the default cell sizes 
for the
FDT (via fdtdec) also increases.  I.e. if any come in our arch or the drivers 
still goes through
the fdtdec-functions, we’ll end up with a problem.

As my test coverage is limited to 64bit targets, I can’t tell whether defining 
the PHYS_64BIT
configuration would be possible for the RK3288 — if it is, we’d have a rather 
easy way forward
and could reuse the phys_size_t for ram_info.size.

I’d appreciate if you could take a look at whether CONFIG_PHYS_64BIT gets us 
into a lot
of trouble on the RK3288 or whether this will trigger just a few minor 
adjustments…

Thanks,
Philipp.

> On 9 May 2018, at 09:24, Dr. Philipp Tomsich 
>  wrote:
> 
>> 
>> On 9 May 2018, at 07:29, Marty E. Plummer  wrote:
>> 
>> On Tue, May 08, 2018 at 11:08:14PM +0200, Dr. Philipp Tomsich wrote:
>>> 
 On 8 May 2018, at 21:21, Marty E. Plummer  wrote:
 
 On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
> Marty,
> 
>> On 8 May 2018, at 02:52, Marty E. Plummer  wrote:
>> 
>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>>> 
 On 7 May 2018, at 04:34, Marty E. Plummer  
 wrote:
 
 On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> Hi Marty,
> 
> 
> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>> 
>> Without this change, my u-boot build for the asus c201 chromebook 
>> (4GiB)
>> is incorrectly detected as 0 Bytes of ram.
> 
> I know the root cause for this issue, and I have a local patch for it.
> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
> before
> the max size before return with '<<20'. Sorry for forgot to send it 
> out.
> 
>> 
>> Signed-off-by: Marty E. Plummer 
>> ---
>> arch/arm/mach-rockchip/sdram_common.c | 62 
>> ---
>> 1 file changed, 37 insertions(+), 25 deletions(-)
>> 
>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>> b/arch/arm/mach-rockchip/sdram_common.c
>> index 76dbdc8715..a9c9f970a4 100644
>> --- a/arch/arm/mach-rockchip/sdram_common.c
>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>> @@ -10,6 +10,8 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>> +#include 
>> 
>> DECLARE_GLOBAL_DATA_PTR;
>> size_t rockchip_sdram_size(phys_addr_t reg)
>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>  size_t size_mb = 0;
>>  u32 ch;
>> 
>> -u32 sys_reg = readl(reg);
>> -u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>> -   & SYS_REG_NUM_CH_MASK);
>> +if (!size_mb) {
> 
> I don't understand this and follow up changes, we don't really need 
> it,
> isn't it?
> I think don't need the changes before here.
 Yeah, that was just another level of indentation for the if (!size_mb)
 guard, but I've reworked the patch to not do that as it was pointed out
 that since size_mb is initialized to 0 prior.
>> +/*
>> + * we use the 0x~0xfeff space
>> + * since 0xff00~0x is soc register space
>> + * so we reserve it
>> + */
>> +size_mb = min(size_mb, 0xff00/SZ_1M);
> 
> This is what we really need, as Klaus point out, we need to use
> SDRAM_MAX_SIZE
> instead of hard code.
 Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as 
 instructed,
 build and boot tested on my hardware.
>>> 
>>> In that case you just masked the problem but didn???t solve it: 
>>> assuming size_mb
>>> is size_t (I???ll assume this is 64bit, but did not check), then your 
>>> 4GB is 0x1__ )
>>> which overflows to 0x0 when converted to a u32.
>>> 
>>> In other words: we need 

Re: [U-Boot] [PATCH] ARM: socfpga: Put stack at the end of SRAM

[Stefan Roese]

On 14.05.2018 11:06, Marek Vasut wrote:

On 05/14/2018 11:01 AM, Simon Goldschmidt wrote:



On 14.05.2018 10:17, Marek Vasut wrote:

On 05/14/2018 10:03 AM, Simon Goldschmidt wrote:

On 12.05.2018 22:27, Marek Vasut wrote:

The global data are in the .data section, so there's no point in
reserving any space for it above stack. Put stack at the end of
SRAM.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
---
    include/configs/socfpga_common.h | 4 +---
    1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/configs/socfpga_common.h
b/include/configs/socfpga_common.h
index 4de2aa7929..cb67d539b1 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -35,10 +35,8 @@
    #define CONFIG_SYS_INIT_RAM_ADDR    0xFFE0
    #define CONFIG_SYS_INIT_RAM_SIZE    0x4 /* 256KB */
    #endif
-#define CONFIG_SYS_INIT_SP_OFFSET    \
-    (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
    #define CONFIG_SYS_INIT_SP_ADDR    \
-    (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
+    (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)


I think this interferes with the bootcount being stored at the end of
SRAM. See the defconfigs of 'is1' and 'sr1500' boards - or my local
defconfig here :-)

I'd really like to keep some room here for bootcounter and some related
things I store here.


So if I understand it correctly, before this patch, the boards overwrote
the global data ?


Ehrm, reading up on the init code path in the S and C files, it seems
like that, yes. I just used the two boards as an example. Are they
actively maintained? get_maintainer.pl shows the boards are maintained
by denx, so maybe you could clarify this?


+CC Stefan.


Thanks. At the time I added the bootcounter support on this platform,
it used to work. I might have missed something though. Right now,
I don't have access to such a platform, so its hard for me to test
something. If you have some patches to fix any potential overlapping
memory usages, I'll gladly review them.


Chances are high that these bytes just fit into the 16-byte alignment
allocated by GENERATED_GBL_DATA_SIZE (and on my board it *is* like that).



Anyway, if you need some extra space, look at
board_init_f_alloc_reserve() .



OK, but that function does not seem to be overridable? How can I reserve
my own memory here?


Add a __weak there I guess ?


And reading this function, I guess your commit message is a bit
misleading. It seems that the purpose of CONFIG_SYS_INIT_SP_OFFSET like
it was was to reserve memory for the initial gd (before relocation),
which is now done in board_init_f_alloc_reserve().


The code is confusing as hell, I give you that.


Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/3] doc: qemu-arm: Drop highmem=off references

[Tuomas Tynkkynen]

Now that U-Boot works fine with highmem enabled, there is no need to
tell users to disable highmem.

Signed-off-by: Tuomas Tynkkynen 
---
 doc/README.qemu-arm | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/doc/README.qemu-arm b/doc/README.qemu-arm
index 6f6f07d8bb..260165638a 100644
--- a/doc/README.qemu-arm
+++ b/doc/README.qemu-arm
@@ -39,13 +39,12 @@ Running U-Boot
 The minimal QEMU command line to get U-Boot up and running is:
 
 - For ARM:
-qemu-system-arm -machine virt,highmem=off -bios u-boot.bin
+qemu-system-arm -machine virt -bios u-boot.bin
 
 - For AArch64:
-qemu-system-aarch64 -machine virt,highmem=off -cpu cortex-a57 -bios 
u-boot.bin
+qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin
 
-The 'highmem=off' parameter to the 'virt' machine is required for PCI to work
-in U-Boot. Also, for some odd reason qemu-system-aarch64 needs to be explicitly
+Note that for some odd reason qemu-system-aarch64 needs to be explicitly
 told to use a 64-bit CPU or it will boot in 32-bit mode.
 
 Additional peripherals that have been tested to work in both U-Boot and Linux
-- 
2.16.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/3] ARM: qemu-arm: Bump RAM size in AArch64 MMU table

[Tuomas Tynkkynen]

Now that PCI devices work with highmem-enabled QEMU emulation, bump up
the RAM size in the MMU tables to gain access to the full 255 GB of RAM
potential instead of the puny 3 GB.

Signed-off-by: Tuomas Tynkkynen 
---
 board/emulation/qemu-arm/qemu-arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 6ec4200170..085cbbef99 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -28,7 +28,7 @@ static struct mm_region qemu_arm64_mem_map[] = {
/* RAM */
.virt = 0x4000UL,
.phys = 0x4000UL,
-   .size = 0xc000UL,
+   .size = 255UL * SZ_1G,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-- 
2.16.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/3] PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set

[Tuomas Tynkkynen]

Currently, qemu_arm_defconfig and qemu_arm64_defconfig only work with
the 'highmem=off' parameter passed to QEMU's virt machine. The reason is
that when 'highmem' is not disabled, QEMU appends 64-bit a memory
resource to the PCI controller's regions property in DT in addition to
the 32-bit PCI memory window in low memory. And the current DT parsing
code picks the last (thus the 64-bit one) memory resource, whose address
eventually gets silently truncated to 32 bits because
CONFIG_SYS_PCI_64BIT is not set, which obviously causes PCI to break.

Avoid this problem by ignoring memory regions whose addresses are above
the 32-bit boundary when CONFIG_SYS_PCI_64BIT is not set.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/pci/pci-uclass.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 49be1ebdd7..1cd1e409e3 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -860,6 +860,13 @@ static int decode_regions(struct pci_controller *hose, 
ofnode parent_node,
} else {
continue;
}
+
+   if (!IS_ENABLED(CONFIG_SYS_PCI_64BIT) &&
+   type == PCI_REGION_MEM && upper_32_bits(pci_addr)) {
+   debug(" - beyond the 32-bit boundary, ignoring\n");
+   continue;
+   }
+
pos = -1;
for (i = 0; i < hose->region_count; i++) {
if (hose->regions[i].flags == type)
-- 
2.16.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] net: nfs: don't fail when nfs_read_reply returns -NFS_RPC_DROP

[Vasily Khoruzhick]

That can happen if duplicate UDP packet arrived, and that's not uncommon.
Anyway, we ignore packets with rpc_id lower than last we sent for other
requests, so it makes sense to do that for read request as well.

Signed-off-by: Vasily Khoruzhick 
---
 net/nfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index 83ed0a7c37..9a16765ba1 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -822,6 +822,8 @@ static void nfs_handler(uchar *pkt, unsigned dest, struct 
in_addr sip,
 
case STATE_READ_REQ:
rlen = nfs_read_reply(pkt, len);
+   if (rlen == -NFS_RPC_DROP)
+   break;
net_set_timeout_handler(nfs_timeout, nfs_timeout_handler);
if (rlen > 0) {
nfs_offset += rlen;
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PULL] Please pull u-boot-rockchip/master

[Dr. Philipp Tomsich]

Travis report (prior to a final rebase onto your latest master) is at
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/378666041

> On 14 May 2018, at 17:32, Dr. Philipp Tomsich 
>  wrote:
> 
> Tom,
> 
> I have two fixes for regressions (that unfortunately ended up in the last 
> release) in my tree,
> ready for a merge onto master.
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit ca70cbabdcd19bf157ae4fa984559b126071ccff:
> 
>  Merge git://git.denx.de/u-boot-marvell (2018-05-14 08:52:48 -0400)
> 
> are available in the git repository at:
> 
>  git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to ed1030e1523541801ae1e36bc34ee6872d474184:
> 
>  rockchip: clk: rk3288: handle clk_enable requests for GMAC (2018-05-14 
> 17:30:40 +0200)
> 
> 
> Jonathan Gray (2):
>  rockchip: set SYS_NS16550_MEM32 for all SoCs
>  rockchip: clk: rk3288: handle clk_enable requests for GMAC
> 
> drivers/clk/rockchip/clk_rk3288.c | 10 ++
> include/configs/rockchip-common.h |  2 ++
> 2 files changed, 12 insertions(+)
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PULL] Please pull u-boot-rockchip/master

[Dr. Philipp Tomsich]

Tom,

I have two fixes for regressions (that unfortunately ended up in the last 
release) in my tree,
ready for a merge onto master.

Thanks,
Philipp.


The following changes since commit ca70cbabdcd19bf157ae4fa984559b126071ccff:

  Merge git://git.denx.de/u-boot-marvell (2018-05-14 08:52:48 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git master

for you to fetch changes up to ed1030e1523541801ae1e36bc34ee6872d474184:

  rockchip: clk: rk3288: handle clk_enable requests for GMAC (2018-05-14 
17:30:40 +0200)


Jonathan Gray (2):
  rockchip: set SYS_NS16550_MEM32 for all SoCs
  rockchip: clk: rk3288: handle clk_enable requests for GMAC

 drivers/clk/rockchip/clk_rk3288.c | 10 ++
 include/configs/rockchip-common.h |  2 ++
 2 files changed, 12 insertions(+)

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] mmc: sunxi: run calibration on A64

[Vasily Khoruzhick]

Along with using new mode it fixes eMMC instability on Pinebook

Signed-off-by: Vasily Khoruzhick 
---
 arch/arm/include/asm/arch-sunxi/mmc.h |  6 +-
 drivers/mmc/sunxi_mmc.c   | 11 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h 
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 1574b8e8fe..d6664a01f2 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -46,7 +46,9 @@ struct sunxi_mmc {
u32 cbda;   /* 0x94 */
u32 res2[26];
 #ifdef CONFIG_SUNXI_GEN_SUN6I
-   u32 res3[64];
+   u32 res3[17];
+   u32 samp_dl;
+   u32 res4[46];
 #endif
u32 fifo;   /* 0x100 / 0x200 FIFO access address */
 };
@@ -130,5 +132,7 @@ struct sunxi_mmc {
 #define SUNXI_MMC_COMMON_CLK_GATE  (1 << 16)
 #define SUNXI_MMC_COMMON_RESET (1 << 18)
 
+#define SUNXI_MMC_CAL_DL_SW_EN (0x1 << 7)
+
 struct mmc *sunxi_mmc_init(int sdc_no);
 #endif /* _SUNXI_MMC_H */
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 65d88ee921..542b85b592 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -223,6 +223,17 @@ static int mmc_config_clock(struct sunxi_mmc_priv *priv, 
struct mmc *mmc)
rval &= ~SUNXI_MMC_CLK_DIVIDER_MASK;
writel(rval, >reg->clkcr);
 
+#ifdef CONFIG_MACH_SUN50I
+   /* A64 needs to run calibration on eMMC controller and we
+* have to set delay of zero before starting calibration.
+* Allwinner BSP driver sets a delay only in the case of
+* using HS400 which is not supported by mainline U-Boot or
+* Linux at the moment
+*/
+   if (priv->mmc_no == 2)
+   writel(SUNXI_MMC_CAL_DL_SW_EN, >reg->samp_dl);
+#endif
+
/* Re-enable Clock */
rval |= SUNXI_MMC_CLK_ENABLE;
writel(rval, >reg->clkcr);
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/2] sunxi-mmc: use new mode on A64

[Vasily Khoruzhick]

That is necessary for using automatic calibration on A64 eMMC.

Signed-off-by: Vasily khoruzhick 
---
 arch/arm/mach-sunxi/Kconfig | 1 +
 drivers/mmc/sunxi_mmc.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index f0c9d1b058..376380e977 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -256,6 +256,7 @@ config MACH_SUN50I
select SUNXI_DE2
select SUNXI_GEN_SUN6I
select SUNXI_HIGH_SRAM
+   select MMC_SUNXI_HAS_NEW_MODE
select SUPPORT_SPL
select SUNXI_DRAM_DW
select SUNXI_DRAM_DW_32BIT
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index fe6d82c7b4..65d88ee921 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -165,7 +165,7 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
unsigned int hz)
}
 
if (new_mode) {
-#ifdef CONFIG_MMC_SUNXI_HAS_NEW_MODE
+#if defined(CONFIG_MMC_SUNXI_HAS_NEW_MODE) && !defined(CONFIG_MACH_SUN50I)
val = CCM_MMC_CTRL_MODE_SEL_NEW;
setbits_le32(>reg->ntsr, SUNXI_MMC_NTSR_MODE_SEL_NEW);
 #endif
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 0/2] sunxi: fix eMMC stability issues on A64

[Vasily Khoruzhick]

eMMC seems to require new clocking mode and calibration on A64,
otherwise it is pretty unstable on some boards (e.g. Pinebook)
with some eMMCs.

v2: - improve comment about calibration for eMMC on A64
- simplify ifdef-s around configuring delays

Vasily Khoruzhick (2):
  sunxi-mmc: use new mode on A64
  mmc: sunxi: run calibration on A64

 arch/arm/include/asm/arch-sunxi/mmc.h |  6 +-
 arch/arm/mach-sunxi/Kconfig   |  1 +
 drivers/mmc/sunxi_mmc.c   | 13 -
 3 files changed, 18 insertions(+), 2 deletions(-)

-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] net: [PATCH v10 3/3] Adding wget

[Duncan Hare]

From: Simon Glass 


 To: Duncan Hare  
Cc: "joe.hershber...@ni.com" ; U-Boot Mailing List 

 Sent: Sunday, May 13, 2018 3:00 PM
 Subject: Re: net: [U-Boot] [PATCH v10 3/3] Adding wget
   

Please setup a test that can run in an environment without the
Internet. That is critical for unit tests.

Hand tests for Internet usage and the environmental effects are great,
but that can't be what we include in the auto tests for repeat-ability
reasons. Simon is asking for a separate type of test.
>>>
>>> Is the test environment another patch in the series or an addition to the
>>> wget patch?

>I suggest a separate patch.
>>Regards,>>Simon
Separate patch, patch 4 of the series or a completely new patch?
Conceptual approach:

apt-get install nginx (in debian)
I'll provide a config file pointing to test kernel a a specified file location.

Test kernel will be numbered lines of printable characters. Printable, not 
binary, easy to expand in a spreadsheet.

Can the u-boot print command print sections of memory? That is
print $loadaddr $length? 

That will work for small test kernels, or 

I tested by using tftp to download a kernel, then used a modified wget to 
download a seconf time and verify thedownloads were identical.

compare $loadaddr1 $loadaddr2 $length

Is that a preferred approach?
 Duncan Hare

714 931 7952

   
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ext4fs: Add ext4 extent tree cache

[Tom Rini]

On Mon, May 14, 2018 at 05:21:38PM +0200, Marek Vasut wrote:

> On 05/14/2018 05:14 PM, Evan Thompson wrote:
> > On Sun, May 13, 2018 at 12:03 PM, Marek Vasut  wrote:
> >>
> >> btw doesn't CONFIG_BLOCK_CACHE offer similar service, but for everyone
> >> and on block level ? I recall looking for ext4 fs speed up , but then
> >> ultimately used CONFIG_BLOCK_CACHE which did it for me.
> > 
> > I was unaware of the existence of CONFIG_BLOCK_CACHE - yes, that will
> > solve the same problem by caching at the block level instead of the
> > filesystem level. So my patch is redundant, and ext4 users should just
> > be advised to turn on CONFIG_BLOCK_CACHE.
> 
> Maybe this block cache should be default=y (if BLK is enabled?) or we
> should advertise it more somehow. I ran into the exact same issue and
> started looking into the ext4 patches myself only to find the block
> cache later on.

Agreed.  I'm right now testing a patch or two to do that and see what
the size cost is.  Thanks all!

-- 
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] ext4fs: Add ext4 extent tree cache

[Marek Vasut]

On 05/14/2018 05:14 PM, Evan Thompson wrote:
> On Sun, May 13, 2018 at 12:03 PM, Marek Vasut  wrote:
>>
>> btw doesn't CONFIG_BLOCK_CACHE offer similar service, but for everyone
>> and on block level ? I recall looking for ext4 fs speed up , but then
>> ultimately used CONFIG_BLOCK_CACHE which did it for me.
> 
> I was unaware of the existence of CONFIG_BLOCK_CACHE - yes, that will
> solve the same problem by caching at the block level instead of the
> filesystem level. So my patch is redundant, and ext4 users should just
> be advised to turn on CONFIG_BLOCK_CACHE.

Maybe this block cache should be default=y (if BLK is enabled?) or we
should advertise it more somehow. I ran into the exact same issue and
started looking into the ext4 patches myself only to find the block
cache later on.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 2/2] dts: sunxi: add PWM node for sun50i

[Vasily Khoruzhick]

Add PWM definition to sun50i-a64.dtsi

Signed-off-by: Vasily Khoruzhick 
---
 arch/arm/dts/sun50i-a64.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/dts/sun50i-a64.dtsi b/arch/arm/dts/sun50i-a64.dtsi
index 65a344d9ce..a82a3d89af 100644
--- a/arch/arm/dts/sun50i-a64.dtsi
+++ b/arch/arm/dts/sun50i-a64.dtsi
@@ -319,6 +319,15 @@
};
};
 
+   pwm: pwm@01c21400 {
+   compatible = "allwinner,sun50i-a64-pwm",
+"allwinner,sun5i-a13-pwm";
+   reg = <0x01c21400 0x8>;
+   clocks = <>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-marvell/master

[Stefan Roese]

Hi Tom,

(Cc'ing Chris)

On 14.05.2018 17:11, Tom Rini wrote:

On Mon, May 14, 2018 at 01:58:59PM +0200, Stefan Roese wrote:


Hi Tom,

please pull the following MVEBU related patches from Marek and
Chris.

Thanks,
Stefan

The following changes since commit 62d77cea31216cad526e5f45c88e8377efc6fcae:

   mmc: Improve tinification (2018-05-13 07:57:32 -0400)

are available in the Git repository at:

   git://www.denx.de/git/u-boot-marvell.git

for you to fetch changes up to ca734a875dec089c3978663a0ce303d776365b20:

   phy: marvell: a3700: Fix compatible string for ehci (2018-05-14 10:01:56 
+0200)



Applied to u-boot/master.

But please note that drivers/ddr/marvell/a38x/mv_ddr_build_message.c is
both missing an SPDX tag and oddly formatted.  I assume there's a good
reason those two variables exist in the way they do and that we can't
just fold that into some other files, so please look into what the
correct SPDX tag and copyright line should be for that content, thanks!


Thanks Tom, I didn't spot this.

Chris, I assume that we need this file (this way) for compatibility
(potential later re-sync) with the Marvell code? Is this correct?
Or could this be done in a different way? Please check and add the
SPDX tag and copyright line as requested by Tom.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 1/2] pwm: sunxi: add support for PWM found on Allwinner A64

[Vasily Khoruzhick]

This commit adds basic support for PWM found on Allwinner A64.
It can be used for pwm_backlight driver (e.g. for Pinebook)

Signed-off-by: Vasily Khoruzhick 
---
 arch/arm/include/asm/arch-sunxi/gpio.h |   1 +
 arch/arm/include/asm/arch-sunxi/pwm.h  |  12 ++
 drivers/pwm/Kconfig|   7 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/sunxi_pwm.c| 178 +
 5 files changed, 199 insertions(+)
 create mode 100644 drivers/pwm/sunxi_pwm.c

diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 3334fb51f0..e4fe54d8b8 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -172,6 +172,7 @@ enum sunxi_gpio_number {
 #define SUN8I_GPD_SDC1 3
 #define SUNXI_GPD_LCD0 2
 #define SUNXI_GPD_LVDS03
+#define SUNXI_GPD_PWM  2
 
 #define SUN5I_GPE_SDC2 3
 #define SUN8I_GPE_TWI2 3
diff --git a/arch/arm/include/asm/arch-sunxi/pwm.h 
b/arch/arm/include/asm/arch-sunxi/pwm.h
index 47eb433fb6..dca283c7a9 100644
--- a/arch/arm/include/asm/arch-sunxi/pwm.h
+++ b/arch/arm/include/asm/arch-sunxi/pwm.h
@@ -10,8 +10,15 @@
 #define SUNXI_PWM_CH0_PERIOD   (SUNXI_PWM_BASE + 4)
 
 #define SUNXI_PWM_CTRL_PRESCALE0(x)((x) & 0xf)
+#define SUNXI_PWM_CTRL_PRESCALE0_MASK  0xf
 #define SUNXI_PWM_CTRL_ENABLE0 (0x5 << 4)
 #define SUNXI_PWM_CTRL_POLARITY0(x)((x) << 5)
+#define SUNXI_PWM_CTRL_CH0_ACT_STA BIT(5)
+#define SUNXI_PWM_CTRL_CLK_GATEBIT(6)
+
+#define SUNXI_PWM_CH0_PERIOD_MAX   (0x)
+#define SUNXI_PWM_CH0_PERIOD_PRD(x)((x & 0x) << 16)
+#define SUNXI_PWM_CH0_PERIOD_DUTY(x)   ((x) & 0x)
 
 #define SUNXI_PWM_PERIOD_80PCT 0x04af03c0
 
@@ -30,4 +37,9 @@
 #define SUNXI_PWM_MUX  SUN8I_GPH_PWM
 #endif
 
+struct sunxi_pwm {
+   u32 ctrl;
+   u32 ch0_period;
+};
+
 #endif
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e827558052..2984b79766 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -43,3 +43,10 @@ config PWM_TEGRA
  four channels with a programmable period and duty cycle. Only a
  32KHz clock is supported by the driver but the duty cycle is
  configurable.
+
+config PWM_SUNXI
+   bool "Enable support for the Allwinner Sunxi PWM"
+   depends on DM_PWM
+   help
+ This PWM is found on H3, A64 and other Allwinner SoCs. It supports a
+ programmable period and duty cycle. A 16-bit counter is used.
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 16739e7fda..a837c35ed2 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o
 obj-$(CONFIG_PWM_ROCKCHIP) += rk_pwm.o
 obj-$(CONFIG_PWM_SANDBOX)  += sandbox_pwm.o
 obj-$(CONFIG_PWM_TEGRA)+= tegra_pwm.o
+obj-$(CONFIG_PWM_SUNXI)+= sunxi_pwm.o
diff --git a/drivers/pwm/sunxi_pwm.c b/drivers/pwm/sunxi_pwm.c
new file mode 100644
index 00..3c7dffdd90
--- /dev/null
+++ b/drivers/pwm/sunxi_pwm.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2017-2018 Vasily Khoruzhick 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define OSC_24MHZ 2400
+
+struct sunxi_pwm_priv {
+   struct sunxi_pwm *regs;
+   bool invert;
+   u32 prescaler;
+};
+
+static const u32 prescaler_table[] = {
+   120,/*  */
+   180,/* 0001 */
+   240,/* 0010 */
+   360,/* 0011 */
+   480,/* 0100 */
+   0,  /* 0101 */
+   0,  /* 0110 */
+   0,  /* 0111 */
+   12000,  /* 1000 */
+   24000,  /* 1001 */
+   36000,  /* 1010 */
+   48000,  /* 1011 */
+   72000,  /* 1100 */
+   0,  /* 1101 */
+   0,  /* 1110 */
+   1,  /*  */
+};
+
+static int sunxi_pwm_config_pinmux(void)
+{
+#ifdef CONFIG_MACH_SUN50I
+   sunxi_gpio_set_cfgpin(SUNXI_GPD(22), SUNXI_GPD_PWM);
+#endif
+   return 0;
+}
+
+static int sunxi_pwm_set_invert(struct udevice *dev, uint channel,
+   bool polarity)
+{
+   struct sunxi_pwm_priv *priv = dev_get_priv(dev);
+
+   debug("%s: polarity=%u\n", __func__, polarity);
+   priv->invert = polarity;
+
+   return 0;
+}
+
+static int sunxi_pwm_set_config(struct udevice *dev, uint channel,
+   uint period_ns, uint duty_ns)
+{
+   struct sunxi_pwm_priv *priv = dev_get_priv(dev);
+   struct sunxi_pwm *regs = priv->regs;
+   int prescaler;
+   u32 v, period = 0, duty;
+   u64 scaled_freq = 0;
+   const u32 nsecs_per_sec = 10U;
+
+   debug("%s: period_ns=%u, duty_ns=%u\n", __func__, period_ns, duty_ns);
+
+   for 

[U-Boot] [PATCH v4 0/2] sunxi: add PWM driver for A64

[Vasily Khoruzhick]

This series introduces a PWM driver for Allwinner A64.

This driver can be used to control backlight on Pinebook

v4: use the same binding as in Linux

Vasily Khoruzhick (2):
  pwm: sunxi: add support for PWM found on Allwinner A64
  dts: sunxi: add PWM node for sun50i

 arch/arm/dts/sun50i-a64.dtsi   |   9 ++
 arch/arm/include/asm/arch-sunxi/gpio.h |   1 +
 arch/arm/include/asm/arch-sunxi/pwm.h  |  12 ++
 drivers/pwm/Kconfig|   7 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/sunxi_pwm.c| 178 +
 6 files changed, 208 insertions(+)
 create mode 100644 drivers/pwm/sunxi_pwm.c

-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ext4fs: Add ext4 extent tree cache

[Evan Thompson]

On Sun, May 13, 2018 at 12:03 PM, Marek Vasut  wrote:
>
> btw doesn't CONFIG_BLOCK_CACHE offer similar service, but for everyone
> and on block level ? I recall looking for ext4 fs speed up , but then
> ultimately used CONFIG_BLOCK_CACHE which did it for me.

I was unaware of the existence of CONFIG_BLOCK_CACHE - yes, that will
solve the same problem by caching at the block level instead of the
filesystem level. So my patch is redundant, and ext4 users should just
be advised to turn on CONFIG_BLOCK_CACHE.

Thanks,
Evan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-marvell/master

[Tom Rini]

On Mon, May 14, 2018 at 01:58:59PM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following MVEBU related patches from Marek and
> Chris.
> 
> Thanks,
> Stefan
> 
> The following changes since commit 62d77cea31216cad526e5f45c88e8377efc6fcae:
> 
>   mmc: Improve tinification (2018-05-13 07:57:32 -0400)
> 
> are available in the Git repository at:
> 
>   git://www.denx.de/git/u-boot-marvell.git 
> 
> for you to fetch changes up to ca734a875dec089c3978663a0ce303d776365b20:
> 
>   phy: marvell: a3700: Fix compatible string for ehci (2018-05-14 10:01:56 
> +0200)
> 

Applied to u-boot/master.

But please note that drivers/ddr/marvell/a38x/mv_ddr_build_message.c is
both missing an SPDX tag and oddly formatted.  I assume there's a good
reason those two variables exist in the way they do and that we can't
just fold that into some other files, so please look into what the
correct SPDX tag and copyright line should be for that content, 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] Makefile: adopt --std=gnu11 for HOSTCFLAGS on Linux

[Dr. Philipp Tomsich]

> On 14 May 2018, at 16:53, Mark Kettenis  wrote:
> 
>> From: Philipp Tomsich 
>> Date: Mon, 14 May 2018 15:22:06 +0200
>> 
>> Following the conversion of the SPDX license tags, a number of files
>> compiled with -pedantic now generate warnings similar to the following
>> for using C99-style '//' comments in ISO C90 code:
>> 
>>  tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in 
>> ISO C90
>>   // SPDX-License-Identifier: GPL-2.0+
>>   ^
>> 
>> The SPDX comment-style change means that these files have adopted C99,
>> so need to change the language-standard to --std=gnu99 or --std=gnu11
>> to let the compiler know this.
>> 
>> As we now require GCC 6 or newer for the cross-compiler, the project has
>> implicitly moved the project to GNU11: let older GCC versions on various
>> Linux distros know to treat our host tools as GNU11 as well.
> 
> Note that the requirement is on the cross-compiler, not the host
> compiler.  On our "primary" architectures OpenBSD 6.3 ships with Clang
> 5.0.1 and the current development version uses Clang 6.0.0, which
> default to --std=gnu11.  I do hope those will continue to be supported
> as the host compiler…

Many of the files in question (e.g. lib/sha{1,256}.c) are shared between
the target and the host tools.

>> References: commit 83d290c56fab ("SPDX: Convert all of our single license 
>> tags to Linux Kernel style")
>> Signed-off-by: Philipp Tomsich 
>> ---
>> 
>> Changes in v2:
>> - Set '--std=gnu11' during compilation of host tools on Linux.
>> 
>> Makefile | 9 +
>> 1 file changed, 9 insertions(+)
>> 
>> diff --git a/Makefile b/Makefile
>> index f31ee60..d08fb6a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -258,6 +258,15 @@ HOSTCFLAGS   = -Wall -Wstrict-prototypes -O2 
>> -fomit-frame-pointer \
>>  $(if $(CONFIG_TOOLS_DEBUG),-g)
>> HOSTCXXFLAGS = -O2
>> 
>> +# With the move to GCC 6, we have implicitly upgraded our language
>> +# standard to GNU11 (see https://gcc.gnu.org/gcc-5/porting_to.html).
>> +# Some Linux distributions (including RHEL7, SLES13, Debian 8) still
>> +# have older compilers as their default, so we make it explicit for
>> +# these that our host tools are GNU11 (i.e. C11 w/ GNU extensions).
>> +ifeq ($(HOSTOS),linux)
>> +HOSTCFLAGS += --std=gnu11
>> +endif
>> +
>> ifeq ($(HOSTOS),cygwin)
>> HOSTCFLAGS   += -ansi
>> endif
>> -- 
>> 2.1.4
>> 
>> ___
>> 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 v2] Makefile: adopt --std=gnu11 for HOSTCFLAGS on Linux

[Tom Rini]

On Mon, May 14, 2018 at 04:53:49PM +0200, Mark Kettenis wrote:
> > From: Philipp Tomsich 
> > Date: Mon, 14 May 2018 15:22:06 +0200
> > 
> > Following the conversion of the SPDX license tags, a number of files
> > compiled with -pedantic now generate warnings similar to the following
> > for using C99-style '//' comments in ISO C90 code:
> > 
> >   tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in 
> > ISO C90
> >// SPDX-License-Identifier: GPL-2.0+
> >^
> > 
> > The SPDX comment-style change means that these files have adopted C99,
> > so need to change the language-standard to --std=gnu99 or --std=gnu11
> > to let the compiler know this.
> > 
> > As we now require GCC 6 or newer for the cross-compiler, the project has
> > implicitly moved the project to GNU11: let older GCC versions on various
> > Linux distros know to treat our host tools as GNU11 as well.
> 
> Note that the requirement is on the cross-compiler, not the host
> compiler.  On our "primary" architectures OpenBSD 6.3 ships with Clang
> 5.0.1 and the current development version uses Clang 6.0.0, which
> default to --std=gnu11.  I do hope those will continue to be supported
> as the host compiler...

Does Clang 5.0.1 support gnu11 ?  Note that at this point we're not even
talking about moving to GNU11 features being used anywhere, just
enforcing consistency between modern (post gcc-5) and old (gcc-4.x)
compilers all in order to not have // style comments be a warning (which
in turn is a C99/gnu99 thing).  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] Makefile: adopt --std=gnu11 for HOSTCFLAGS on Linux

[Mark Kettenis]

> From: Philipp Tomsich 
> Date: Mon, 14 May 2018 15:22:06 +0200
> 
> Following the conversion of the SPDX license tags, a number of files
> compiled with -pedantic now generate warnings similar to the following
> for using C99-style '//' comments in ISO C90 code:
> 
>   tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in 
> ISO C90
>// SPDX-License-Identifier: GPL-2.0+
>^
> 
> The SPDX comment-style change means that these files have adopted C99,
> so need to change the language-standard to --std=gnu99 or --std=gnu11
> to let the compiler know this.
> 
> As we now require GCC 6 or newer for the cross-compiler, the project has
> implicitly moved the project to GNU11: let older GCC versions on various
> Linux distros know to treat our host tools as GNU11 as well.

Note that the requirement is on the cross-compiler, not the host
compiler.  On our "primary" architectures OpenBSD 6.3 ships with Clang
5.0.1 and the current development version uses Clang 6.0.0, which
default to --std=gnu11.  I do hope those will continue to be supported
as the host compiler...

> References: commit 83d290c56fab ("SPDX: Convert all of our single license 
> tags to Linux Kernel style")
> Signed-off-by: Philipp Tomsich 
> ---
> 
> Changes in v2:
> - Set '--std=gnu11' during compilation of host tools on Linux.
> 
>  Makefile | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index f31ee60..d08fb6a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -258,6 +258,15 @@ HOSTCFLAGS   = -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer \
>   $(if $(CONFIG_TOOLS_DEBUG),-g)
>  HOSTCXXFLAGS = -O2
>  
> +# With the move to GCC 6, we have implicitly upgraded our language
> +# standard to GNU11 (see https://gcc.gnu.org/gcc-5/porting_to.html).
> +# Some Linux distributions (including RHEL7, SLES13, Debian 8) still
> +# have older compilers as their default, so we make it explicit for
> +# these that our host tools are GNU11 (i.e. C11 w/ GNU extensions).
> +ifeq ($(HOSTOS),linux)
> +HOSTCFLAGS += --std=gnu11
> +endif
> +
>  ifeq ($(HOSTOS),cygwin)
>  HOSTCFLAGS   += -ansi
>  endif
> -- 
> 2.1.4
> 
> ___
> 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 v2] Makefile: adopt --std=gnu11 for HOSTCFLAGS on Linux

[Tom Rini]

On Mon, May 14, 2018 at 03:22:06PM +0200, Philipp Tomsich wrote:

> Following the conversion of the SPDX license tags, a number of files
> compiled with -pedantic now generate warnings similar to the following
> for using C99-style '//' comments in ISO C90 code:
> 
>   tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in 
> ISO C90
>// SPDX-License-Identifier: GPL-2.0+
>^
> 
> The SPDX comment-style change means that these files have adopted C99,
> so need to change the language-standard to --std=gnu99 or --std=gnu11
> to let the compiler know this.
> 
> As we now require GCC 6 or newer for the cross-compiler, the project has
> implicitly moved the project to GNU11: let older GCC versions on various
> Linux distros know to treat our host tools as GNU11 as well.
> 
> References: commit 83d290c56fab ("SPDX: Convert all of our single license 
> tags to Linux Kernel style")
> Signed-off-by: Philipp Tomsich 

Reviewed-by: Tom Rini 

-- 
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] [GIT PULL] Xilinx changes for v2018.07

[Tom Rini]

On Mon, May 14, 2018 at 03:31:03PM +0200, Michal Simek wrote:
> On 11.5.2018 21:22, Tom Rini wrote:
> > On Fri, May 11, 2018 at 03:16:56PM +0200, Michal Simek wrote:
> > 
> >> Hi Tom,
> >>
> >> please pull these changes to your tree.
> >> Buildman looks good and travis build is not showing any issue too.
> >> https://travis-ci.org/michalsimek/u-boot/builds/377645974
> >>
> >> As we have discussed I have grab pending mmc patches for fixing timer
> >> issue and adding sd3.0 support because there was no reaction from Jaehoon.
> >>
> >> And will see that will come from coverity in connection to zynqmp bif
> >> support.
> >>
> >> Thanks,
> >> Michal
> >>
> >>
> >> The following changes since commit 
> >> da342f06b30399fbbebbb53aadfc018713c65c24:
> >>
> >>   Merge git://git.denx.de/u-boot-ubi (2018-05-10 07:17:14 -0400)
> >>
> >> are available in the Git repository at:
> >>
> >>   git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.07
> >>
> >> for you to fetch changes up to 4b87f2d500e94f877f38d9c11e4e47e1721f3fbe:
> >>
> >>   arm64: zynqmp: Enable UHS support for ZCU102 Rev1.0 board (2018-05-11
> >> 11:13:54 +0200)
> >>
> > 
> > With a follow-up patch to correct SPDX tag formats, applied to
> > u-boot/master, thanks!
> 
> Did that discussing end up that we are going to follow kernel spdx style?

Barring further vocal disagreement about doing so, yes.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,3/3] mmc: support writing sparse images

[Tom Rini]

On Mon, May 14, 2018 at 06:42:41PM +0530, Jassi Brar wrote:
> Hi Tom,
> 
> On Tue, May 8, 2018 at 10:45 PM, Tom Rini  wrote:
> > On Fri, Apr 06, 2018 at 12:05:24PM +0530, jassisinghb...@gmail.com wrote:
> >
> >> From: Jassi Brar 
> >>
> >> Provide an alternate path for sparse-images to be
> >> written to MMC. For example, via tftp on platforms
> >> that don't support fastboot protocol. Or when an
> >> image is to written at some offset, rather than the
> >> start of a partition.
> >>
> >> Signed-off-by: Jassi Brar 
> >
> > Applied to u-boot/master, thanks!
>
> I see you modified the patch to protect the feature with
> CONFIG_FASTBOOT_FLASH, which kills the purpose -- this feature is for
> platforms that don't support fastboot.
> 
> Do you want me to send the patch to revert the protection?

Sorry, I guess maybe things weren't clear enough all around, and we
should (functionally) revert patches 2 and 3 and try something
different.  It is OK to say "lets make writing sparse images more widely
available".  It's not OK to make every platform with MMC write grow a
decent bit in binary size.  Making a quick pass at re-enabling things on
a platform without fastboot support already grew things by nearly 2KiB.
The other part which is I believe got me down this path was that without
a change to common/Makefile to always (outside of SPL) include
common/image-sparse.o things don't link.

In sum, a new patch to add an option to allow people to opt-in for
swrite would be good.  And please make sure to do something like:
diff --git a/common/Makefile b/common/Makefile
index d0681c7dd96a..92b2aa1ca8f0 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -120,6 +120,7 @@ ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
 obj-y += fb_nand.o
 endif
 endif
+obj-$(CONFIG_MMC_WRITE) += image-sparse.o
 endif
 
 ifdef CONFIG_CMD_EEPROM_LAYOUT

too so it links everywhere.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Revert "sunxi: binman: Add U-Boot binary size check"

[Maxime Ripard]

This reverts commit 819f1e081c527d2d02cdaeec0027384688cf5de0.

This check was introduced in order to cope with the size limitation we had
when we were still using the raw environment in MMC. However, this
introduces padding as well, which can result in an overly huge binary if
one wants to flash the environment to some other location.

Since we now have a FAT-based environment, this check is not so useful
anymore, so we can just drop it.

Cc: Andre Przywara 
Cc: Måns Rullgård 
Signed-off-by: Maxime Ripard 
---
 arch/arm/dts/sunxi-u-boot.dtsi | 12 
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index 72e95afd780e..5adfd9bca2ec 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -1,14 +1,5 @@
 #include 
 
-/*
- * This is the maximum size the U-Boot binary can be, which is basically
- * the start of the environment, minus the start of the U-Boot binary in
- * the MMC. This makes the assumption that the MMC is using 512-bytes
- * blocks, but devices using something other than that remains to be
- * seen.
- */
-#define UBOOT_MMC_MAX_SIZE (CONFIG_ENV_OFFSET - 
(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512))
-
 / {
binman {
filename = "u-boot-sunxi-with-spl.bin";
@@ -17,9 +8,6 @@
filename = "spl/sunxi-spl.bin";
};
u-boot-img {
-#ifdef CONFIG_MMC
-   size = ;
-#endif
pos = ;
};
};
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rockchip: clk: rk3288: handle clk_enable requests for GMAC

[Philipp Tomsich]

> Since b0ba1e7e9d9b9441a18048ec67a3b3100c096975
> (rockchip: clk: rk3288: add clk_enable function and support USB HOST0/HSIC)
> Ethernet no longer probes on RK3288.
> 
> Add no-ops for GMAC clocks observed to be requested which match the
> clk_enable cases in RK3368 and RK3399.
> 
> Signed-off-by: Jonathan Gray 
> Cc: Wadim Egorov 
> Cc: Philipp Tomsich 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
>  drivers/clk/rockchip/clk_rk3288.c | 10 ++
>  1 file changed, 10 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 09/10] ARM: dts: stm32: Add quadspi reset for stm32f746

[Patrice Chotard]

Add missing reset property in quadspi node.

Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 arch/arm/dts/stm32f746.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index 8581df9a2778..4845279ccfca 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -92,6 +92,7 @@
interrupts = <92>;
spi-max-frequency = <10800>;
clocks = < 0 STM32F7_AHB3_CLOCK(QSPI)>;
+   resets = < STM32F7_AHB3_RESET(QSPI)>;
status = "disabled";
};
usart1: serial@40011000 {
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 07/10] spi: stm32_qspi: Use dev_read_xxx API

[Patrice Chotard]

Use dev_read_xxx() instead of old manner fdt_xxx() API

Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 drivers/spi/stm32_qspi.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index 56ea5911239a..62875e2e4c89 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -16,8 +16,7 @@
 #include 
 #include 
 #include 
-
-DECLARE_GLOBAL_DATA_PTR;
+#include 
 
 struct stm32_qspi_regs {
u32 cr; /* 0x00 */
@@ -421,27 +420,23 @@ static int _stm32_qspi_xfer(struct stm32_qspi_priv *priv,
 
 static int stm32_qspi_ofdata_to_platdata(struct udevice *bus)
 {
-   struct fdt_resource res_regs, res_mem;
+   struct resource res_regs, res_mem;
struct stm32_qspi_platdata *plat = bus->platdata;
-   const void *blob = gd->fdt_blob;
-   int node = dev_of_offset(bus);
int ret;
 
-   ret = fdt_get_named_resource(blob, node, "reg", "reg-names",
-"qspi", _regs);
+   ret = dev_read_resource_byname(bus, "qspi", _regs);
if (ret) {
debug("Error: can't get regs base addresses(ret = %d)!\n", ret);
return -ENOMEM;
}
-   ret = fdt_get_named_resource(blob, node, "reg", "reg-names",
-"qspi_mm", _mem);
+   ret = dev_read_resource_byname(bus, "qspi_mm", _mem);
if (ret) {
debug("Error: can't get mmap base address(ret = %d)!\n", ret);
return -ENOMEM;
}
 
-   plat->max_hz = fdtdec_get_int(blob, node, "spi-max-frequency",
-   STM32_QSPI_DEFAULT_SCK_FREQ);
+   plat->max_hz = dev_read_u32_default(bus, "spi-max-frequency",
+   STM32_QSPI_DEFAULT_SCK_FREQ);
 
plat->base = res_regs.start;
plat->memory_map = res_mem.start;
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 06/10] spi: stm32_qspi: Add chip select management

[Patrice Chotard]

From: Christophe Kerello 

Quad-SPI interface is able to manage 2 spi nor devices.
FSEL bit selects the flash memory to be addressed in single flash mode.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 drivers/spi/stm32_qspi.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index 9fe8b297a458..56ea5911239a 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -155,6 +155,8 @@ enum STM32_QSPI_CCR_FMODE {
 /* default SCK frequency, unit: HZ */
 #define STM32_QSPI_DEFAULT_SCK_FREQ 10800
 
+#define STM32_MAX_NORCHIP 2
+
 struct stm32_qspi_platdata {
u32 base;
u32 memory_map;
@@ -212,6 +214,12 @@ static void _stm32_qspi_set_flash_size(struct 
stm32_qspi_priv *priv, u32 size)
fsize << STM32_QSPI_DCR_FSIZE_SHIFT);
 }
 
+static void _stm32_qspi_set_cs(struct stm32_qspi_priv *priv, unsigned int cs)
+{
+   clrsetbits_le32(>regs->cr, STM32_QSPI_CR_FSEL,
+   cs ? STM32_QSPI_CR_FSEL : 0);
+}
+
 static unsigned int _stm32_qspi_gen_ccr(struct stm32_qspi_priv *priv)
 {
unsigned int ccr_reg = 0;
@@ -497,10 +505,17 @@ static int stm32_qspi_claim_bus(struct udevice *dev)
struct stm32_qspi_priv *priv;
struct udevice *bus;
struct spi_flash *flash;
+   struct dm_spi_slave_platdata *slave_plat;
 
bus = dev->parent;
priv = dev_get_priv(bus);
flash = dev_get_uclass_priv(dev);
+   slave_plat = dev_get_parent_platdata(dev);
+
+   if (slave_plat->cs >= STM32_MAX_NORCHIP)
+   return -ENODEV;
+
+   _stm32_qspi_set_cs(priv, slave_plat->cs);
 
_stm32_qspi_set_flash_size(priv, flash->size);
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 08/10] spi: stm32_qspi: Add reset support

[Patrice Chotard]

In some situation, QSPI controller is already configured by an early
boot stage, adding reset support will insure that QSPI controller is
started from a pristine state.

Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 drivers/spi/stm32_qspi.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index 62875e2e4c89..f6cc35336320 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -457,6 +458,7 @@ static int stm32_qspi_probe(struct udevice *bus)
struct stm32_qspi_priv *priv = dev_get_priv(bus);
struct dm_spi_bus *dm_spi_bus;
struct clk clk;
+   struct reset_ctl reset_ctl;
int ret;
 
dm_spi_bus = bus->uclass_priv;
@@ -484,6 +486,19 @@ static int stm32_qspi_probe(struct udevice *bus)
return priv->clock_rate;
}
 
+   ret = reset_get_by_index(bus, 0, _ctl);
+   if (ret) {
+   if (ret != -ENOENT) {
+   dev_err(bus, "failed to get reset\n");
+   clk_disable();
+   return ret;
+   }
+   } else {
+   /* Reset QSPI controller */
+   reset_assert(_ctl);
+   udelay(2);
+   reset_deassert(_ctl);
+   }
 
setbits_le32(>regs->cr, STM32_QSPI_CR_SSHIFT);
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 04/10] spi: stm32_qspi: Align reg-names with kernel 4.12 RC1

[Patrice Chotard]

From: Christophe Kerello 

Align qspi bindings following kernel dt-bindings
Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
from kernel v4.12-rc1.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 drivers/spi/stm32_qspi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index 4bc4455d2ef9..fc1a34ea442c 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -420,13 +420,13 @@ static int stm32_qspi_ofdata_to_platdata(struct udevice 
*bus)
int ret;
 
ret = fdt_get_named_resource(blob, node, "reg", "reg-names",
-"QuadSPI", _regs);
+"qspi", _regs);
if (ret) {
debug("Error: can't get regs base addresses(ret = %d)!\n", ret);
return -ENOMEM;
}
ret = fdt_get_named_resource(blob, node, "reg", "reg-names",
-"QuadSPI-memory", _mem);
+"qspi_mm", _mem);
if (ret) {
debug("Error: can't get mmap base address(ret = %d)!\n", ret);
return -ENOMEM;
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 10/10] ARM: dts: stm32: Update qspi bindings for stm32f746

[Patrice Chotard]

Align qspi bindings following kernel dt-bindings
Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
from kernel v4.17-rc1.

Signed-off-by: Patrice Chotard 
---

Changes in v2:
 _ remove "update mode management" patch, will be reworked and
   submitted separately

 arch/arm/dts/stm32f746.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index 4845279ccfca..afa7832f8936 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -88,7 +88,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0xA0001000 0x1000>, <0x9000 0x1000>;
-   reg-names = "QuadSPI", "QuadSPI-memory";
+   reg-names = "qspi", "qspi_mm";
interrupts = <92>;
spi-max-frequency = <10800>;
clocks = < 0 STM32F7_AHB3_CLOCK(QSPI)>;
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 05/10] spi: stm32_qspi: Add st, stm32f469-qspi compatible string

[Patrice Chotard]

From: Christophe Kerello 

Add "st,stm32f469-qspi" compatible which is used on kernel side.
This will be necessary when DT will be synchronised from kernel.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 drivers/spi/stm32_qspi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index fc1a34ea442c..9fe8b297a458 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -635,6 +635,7 @@ static const struct dm_spi_ops stm32_qspi_ops = {
 
 static const struct udevice_id stm32_qspi_ids[] = {
{ .compatible = "st,stm32-qspi" },
+   { .compatible = "st,stm32f469-qspi" },
{ }
 };
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 01/10] spi: stm32_qspi: Remove CONFIG_CLK flag

[Patrice Chotard]

As all platforms which uses this driver have CONFIG_CLK flag
enable in their defconfig, we can remove it from driver code.

Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 drivers/spi/stm32_qspi.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index 7d1801280773..41a488097c19 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -448,6 +448,8 @@ static int stm32_qspi_probe(struct udevice *bus)
struct stm32_qspi_platdata *plat = dev_get_platdata(bus);
struct stm32_qspi_priv *priv = dev_get_priv(bus);
struct dm_spi_bus *dm_spi_bus;
+   struct clk clk;
+   int ret;
 
dm_spi_bus = bus->uclass_priv;
 
@@ -457,9 +459,6 @@ static int stm32_qspi_probe(struct udevice *bus)
 
priv->max_hz = plat->max_hz;
 
-#ifdef CONFIG_CLK
-   int ret;
-   struct clk clk;
ret = clk_get_by_index(bus, 0, );
if (ret < 0)
return ret;
@@ -477,7 +476,6 @@ static int stm32_qspi_probe(struct udevice *bus)
return priv->clock_rate;
}
 
-#endif
 
setbits_le32(>regs->cr, STM32_QSPI_CR_SSHIFT);
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 03/10] spi: stm32_qspi: Sort include files alphabetically

[Patrice Chotard]

Sort include files by alphabetical order

Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 drivers/spi/stm32_qspi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index a82c180089e0..4bc4455d2ef9 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -8,14 +8,14 @@
  */
 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 02/10] spi: stm32_qspi: Solve issue detected by checkpatch

[Patrice Chotard]

From: Patrick Delaunay 

Fix parameters function alingemnt
Fix variable declaration

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 drivers/spi/stm32_qspi.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index 41a488097c19..a82c180089e0 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -206,6 +206,7 @@ static void _stm32_qspi_wait_for_ftf(struct stm32_qspi_priv 
*priv)
 static void _stm32_qspi_set_flash_size(struct stm32_qspi_priv *priv, u32 size)
 {
u32 fsize = fls(size) - 1;
+
clrsetbits_le32(>regs->dcr,
STM32_QSPI_DCR_FSIZE_MASK << STM32_QSPI_DCR_FSIZE_SHIFT,
fsize << STM32_QSPI_DCR_FSIZE_SHIFT);
@@ -255,13 +256,15 @@ static unsigned int _stm32_qspi_gen_ccr(struct 
stm32_qspi_priv *priv)
 }
 
 static void _stm32_qspi_enable_mmap(struct stm32_qspi_priv *priv,
-   struct spi_flash *flash)
+   struct spi_flash *flash)
 {
+   unsigned int ccr_reg;
+
priv->command = flash->read_cmd | CMD_HAS_ADR | CMD_HAS_DATA
| CMD_HAS_DUMMY;
priv->dummycycles = flash->dummy_byte * 8;
 
-   unsigned int ccr_reg = _stm32_qspi_gen_ccr(priv);
+   ccr_reg = _stm32_qspi_gen_ccr(priv);
ccr_reg |= (STM32_QSPI_CCR_MEM_MAP << STM32_QSPI_CCR_FMODE_SHIFT);
 
_stm32_qspi_wait_for_not_busy(priv);
@@ -291,10 +294,12 @@ static void _stm32_qspi_start_xfer(struct stm32_qspi_priv 
*priv, u32 cr_reg)
 }
 
 static int _stm32_qspi_xfer(struct stm32_qspi_priv *priv,
-   struct spi_flash *flash, unsigned int bitlen,
-   const u8 *dout, u8 *din, unsigned long flags)
+   struct spi_flash *flash, unsigned int bitlen,
+   const u8 *dout, u8 *din, unsigned long flags)
 {
unsigned int words = bitlen / 8;
+   u32 ccr_reg;
+   int i;
 
if (flags & SPI_XFER_MMAP) {
_stm32_qspi_enable_mmap(priv, flash);
@@ -346,7 +351,7 @@ static int _stm32_qspi_xfer(struct stm32_qspi_priv *priv,
}
 
if (flags & SPI_XFER_END) {
-   u32 ccr_reg = _stm32_qspi_gen_ccr(priv);
+   ccr_reg = _stm32_qspi_gen_ccr(priv);
ccr_reg |= STM32_QSPI_CCR_IND_WRITE
<< STM32_QSPI_CCR_FMODE_SHIFT;
 
@@ -365,7 +370,7 @@ static int _stm32_qspi_xfer(struct stm32_qspi_priv *priv,
 
debug("%s: words:%d data:", __func__, words);
 
-   int i = 0;
+   i = 0;
while (words > i) {
writeb(dout[i], >regs->dr);
debug("%02x ", dout[i]);
@@ -379,7 +384,7 @@ static int _stm32_qspi_xfer(struct stm32_qspi_priv *priv,
}
}
} else if (din) {
-   u32 ccr_reg = _stm32_qspi_gen_ccr(priv);
+   ccr_reg = _stm32_qspi_gen_ccr(priv);
ccr_reg |= STM32_QSPI_CCR_IND_READ
<< STM32_QSPI_CCR_FMODE_SHIFT;
 
@@ -394,7 +399,7 @@ static int _stm32_qspi_xfer(struct stm32_qspi_priv *priv,
 
debug("%s: data:", __func__);
 
-   int i = 0;
+   i = 0;
while (words > i) {
din[i] = readb(>regs->dr);
debug("%02x ", din[i]);
@@ -518,7 +523,7 @@ static int stm32_qspi_release_bus(struct udevice *dev)
 }
 
 static int stm32_qspi_xfer(struct udevice *dev, unsigned int bitlen,
-   const void *dout, void *din, unsigned long flags)
+  const void *dout, void *din, unsigned long flags)
 {
struct stm32_qspi_priv *priv;
struct udevice *bus;
@@ -536,12 +541,13 @@ static int stm32_qspi_set_speed(struct udevice *bus, uint 
speed)
 {
struct stm32_qspi_platdata *plat = bus->platdata;
struct stm32_qspi_priv *priv = dev_get_priv(bus);
+   u32 qspi_clk = priv->clock_rate;
+   u32 prescaler = 255;
+   u32 csht;
 
if (speed > plat->max_hz)
speed = plat->max_hz;
 
-   u32 qspi_clk = priv->clock_rate;
-   u32 prescaler = 255;
if (speed > 0) {
prescaler = DIV_ROUND_UP(qspi_clk, speed) - 1;
if (prescaler > 255)
@@ -550,7 +556,7 @@ static int stm32_qspi_set_speed(struct udevice *bus, uint 
speed)
prescaler = 0;
}
 
-   u32 csht = DIV_ROUND_UP((5 * qspi_clk) / (prescaler + 1), 1);
+   csht = DIV_ROUND_UP((5 * qspi_clk) / (prescaler + 1), 1);
csht = (csht - 1) & 

[U-Boot] [PATCH v2 00/10] Update STM32 QSPI driver

[Patrice Chotard]

This series :
  _ removes useless CONFIG_CLK flag
  _ fixes checkpatch warnings
  _ sorts include files in alphabetical order
  _ align DT bindings with kernel in DT and in driver code
  _ add chip select management
  _ uses dev_read_xxx API
  _ add reset support


Changes in v2:
 _ remove "update mode management" patch, will be reworked and
   submitted separately

Christophe Kerello (3):
  spi: stm32_qspi: Align reg-names with kernel 4.12 RC1
  spi: stm32_qspi: Add st,stm32f469-qspi compatible string
  spi: stm32_qspi: Add chip select management

Patrice Chotard (6):
  spi: stm32_qspi: Remove CONFIG_CLK flag
  spi: stm32_qspi: Sort include files alphabetically
  spi: stm32_qspi: Use dev_read_xxx API
  spi: stm32_qspi: Add reset support
  ARM: dts: stm32: Add quadspi reset for stm32f746
  ARM: dts: stm32: Update qspi bindings for stm32f746

Patrick Delaunay (1):
  spi: stm32_qspi: Solve issue detected by checkpatch

 arch/arm/dts/stm32f746.dtsi |  3 +-
 drivers/spi/stm32_qspi.c| 91 ++---
 2 files changed, 62 insertions(+), 32 deletions(-)

-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] soc: zynqmp: Update required API version to 1.0

[Michal Simek]

From: Rajan Vaja 

Existing EEMI version is to as 1.0 (available from xilinx v2018.1
version). Update required API version to match with EEMI API version.

New PMUFW version is required for operations with programmable logic.

Signed-off-by: Rajan Vaja 
Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/zynqmp/cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index 792a3e1b655f..e122be59c747 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -173,8 +173,8 @@ int __maybe_unused invoke_smc(u32 pm_api_id, u32 arg0, u32 
arg1, u32 arg2,
 
 #define ZYNQMP_SIP_SVC_GET_API_VERSION 0xC201
 
-#define ZYNQMP_PM_VERSION_MAJOR0
-#define ZYNQMP_PM_VERSION_MINOR3
+#define ZYNQMP_PM_VERSION_MAJOR1
+#define ZYNQMP_PM_VERSION_MINOR0
 #define ZYNQMP_PM_VERSION_MAJOR_SHIFT  16
 #define ZYNQMP_PM_VERSION_MINOR_MASK   0x
 
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm64: zynqmp: Get rid of emulatio platforms

[Michal Simek]

ZynqMP emulation platforms are no longer tested and supported that's why
remove macros and code around.

Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/zynqmp/clk.c | 4 
 arch/arm/cpu/armv8/zynqmp/cpu.c | 4 
 arch/arm/include/asm/arch-zynqmp/hardware.h | 2 --
 3 files changed, 10 deletions(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/clk.c b/arch/arm/cpu/armv8/zynqmp/clk.c
index 13e1977bfa1a..82fdbf886cdf 100644
--- a/arch/arm/cpu/armv8/zynqmp/clk.c
+++ b/arch/arm/cpu/armv8/zynqmp/clk.c
@@ -16,10 +16,6 @@ unsigned long zynqmp_get_system_timer_freq(void)
u32 ver = zynqmp_get_silicon_version();
 
switch (ver) {
-   case ZYNQMP_CSU_VERSION_VELOCE:
-   return 1;
-   case ZYNQMP_CSU_VERSION_EP108:
-   return 400;
case ZYNQMP_CSU_VERSION_QEMU:
return 5000;
}
diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index 2748d65d14b4..792a3e1b655f 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -135,12 +135,8 @@ unsigned int zynqmp_get_silicon_version(void)
gd->cpu_clk = get_tbclk();
 
switch (gd->cpu_clk) {
-   case 0 ... 100:
-   return ZYNQMP_CSU_VERSION_VELOCE;
case 5000:
return ZYNQMP_CSU_VERSION_QEMU;
-   case 400:
-   return ZYNQMP_CSU_VERSION_EP108;
}
 
return ZYNQMP_CSU_VERSION_SILICON;
diff --git a/arch/arm/include/asm/arch-zynqmp/hardware.h 
b/arch/arm/include/asm/arch-zynqmp/hardware.h
index dfd6097b4beb..3f1f9498e356 100644
--- a/arch/arm/include/asm/arch-zynqmp/hardware.h
+++ b/arch/arm/include/asm/arch-zynqmp/hardware.h
@@ -123,8 +123,6 @@ struct apu_regs {
 /* Board version value */
 #define ZYNQMP_CSU_BASEADDR0xFFCA
 #define ZYNQMP_CSU_VERSION_SILICON 0x0
-#define ZYNQMP_CSU_VERSION_EP108   0x1
-#define ZYNQMP_CSU_VERSION_VELOCE  0x2
 #define ZYNQMP_CSU_VERSION_QEMU0x3
 
 #define ZYNQMP_CSU_VERSION_EMPTY_SHIFT 20
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [GIT PULL] Xilinx changes for v2018.07

[Michal Simek]

On 11.5.2018 21:22, Tom Rini wrote:
> On Fri, May 11, 2018 at 03:16:56PM +0200, Michal Simek wrote:
> 
>> Hi Tom,
>>
>> please pull these changes to your tree.
>> Buildman looks good and travis build is not showing any issue too.
>> https://travis-ci.org/michalsimek/u-boot/builds/377645974
>>
>> As we have discussed I have grab pending mmc patches for fixing timer
>> issue and adding sd3.0 support because there was no reaction from Jaehoon.
>>
>> And will see that will come from coverity in connection to zynqmp bif
>> support.
>>
>> Thanks,
>> Michal
>>
>>
>> The following changes since commit da342f06b30399fbbebbb53aadfc018713c65c24:
>>
>>   Merge git://git.denx.de/u-boot-ubi (2018-05-10 07:17:14 -0400)
>>
>> are available in the Git repository at:
>>
>>   git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.07
>>
>> for you to fetch changes up to 4b87f2d500e94f877f38d9c11e4e47e1721f3fbe:
>>
>>   arm64: zynqmp: Enable UHS support for ZCU102 Rev1.0 board (2018-05-11
>> 11:13:54 +0200)
>>
> 
> With a follow-up patch to correct SPDX tag formats, applied to
> u-boot/master, thanks!

Did that discussing end up that we are going to follow kernel spdx style?

Thanks,
Michal



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot