Re: [U-Boot] [PATCH 0/3] ARM: DRA7: Fix fastboot command

[Lokesh Vutla]

On Thursday 24 March 2016 12:13 AM, Semen Protsenko wrote:
> 
> Hi All,
> 
> This series reverts recently added patches that break fastboot command.
> I propose to keep it this way until issue is found and fixed.

Let's get this fixed instead of  reverting any of the patches :). This
is because DMA is failing. Can you please try this patch[1].

[1] http://patchwork.ozlabs.org/patch/601463/

Thanks and regards,
Lokesh

> 
> When I'm trying to run fastboot command, next error occurs:
> 
> => fas 0
> data abort
> pc : []  lr : [<0020>]
> reloc pc : [<8081f25e>]lr : []
> ...
> Resetting CPU ...
> 
> My board information:
> 
> CPU  : DRA752 ES1.0
> Board: DRA74x EVM REV E.0
> I2C:   ready
> DRAM:  1.5 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH] ARM: asm: types: Introduce DMA_ADDR_T_64BIT

[Lokesh Vutla]

dma_addr_t holds any valid DMA address. If the DMA API only uses 32-bit
addresses, dma_addr_t need only be 32 bits wide.  Bus addresses, e.g., PCI BARs,
may be wider than 32 bits, but drivers do memory-mapped I/O to ioremapped
kernel virtual addresses, so they don't care about the size of the actual
bus addresses.
Also 32 bit ARM systems with LPAE enabled can use 64bit address space, but
DMA still use 32bit address like in case of DRA7 and Keystone platforms.

This is inspired from the Linux kernel types implementation[1]

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/types.h#n142

Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/types.h | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
index 388058e..d108915 100644
--- a/arch/arm/include/asm/types.h
+++ b/arch/arm/include/asm/types.h
@@ -46,16 +46,29 @@ typedef unsigned long long u64;
 #endif /* CONFIG_ARM64 */
 
 #ifdef CONFIG_PHYS_64BIT
-typedef unsigned long long dma_addr_t;
 typedef unsigned long long phys_addr_t;
 typedef unsigned long long phys_size_t;
 #else
 /* DMA addresses are 32-bits wide */
-typedef u32 dma_addr_t;
 typedef unsigned long phys_addr_t;
 typedef unsigned long phys_size_t;
 #endif
 
+/*
+ * A dma_addr_t can hold any valid DMA address, i.e., any address returned
+ * by the DMA API.
+ *
+ * If the DMA API only uses 32-bit addresses, dma_addr_t need only be 32
+ * bits wide.  Bus addresses, e.g., PCI BARs, may be wider than 32 bits,
+ * but drivers do memory-mapped I/O to ioremapped kernel virtual addresses,
+ * so they don't care about the size of the actual bus addresses.
+ */
+#ifdef CONFIG_DMA_ADDR_T_64BIT
+typedef unsigned long long dma_addr_t;
+#else
+typedef u32 dma_addr_t;
+#endif
+
 #endif /* __KERNEL__ */
 
 typedef unsigned long resource_size_t;
-- 
2.1.4

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

[U-Boot] [PATCH 1/5] ARM: bcm2835: move CONFIG_BCM283* to Kconfig

[Stephen Warren]

Signed-off-by: Stephen Warren 
---
This series depends on:

* My series beginning with "ARM: bcm283x: don't always define
  CONFIG_BCM2835"
* My patch "serial: add BCM283x mini UART driver".
* Alexander Graf's arm64 page table/cache series starting with
  "arm64: Add 32bit arm compatible dcache definitions".
---
 arch/arm/mach-bcm283x/Kconfig | 12 +++-
 include/configs/rpi.h |  1 -
 include/configs/rpi_2.h   |  1 -
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index 1a7baf69e590..dc6770437ec6 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -1,3 +1,11 @@
+config BCM2835
+   bool "Broadcom BCM2835 SoC support"
+   depends on ARCH_BCM283X
+
+config BCM2836
+   bool "Broadcom BCM2836 SoC support"
+   depends on ARCH_BCM283X
+
 menu "Broadcom BCM283X family"
depends on ARCH_BCM283X
 
@@ -7,12 +15,14 @@ choice
 
 config TARGET_RPI
bool "Raspberry Pi"
+   select BCM2835
select CPU_ARM1176
 
 config TARGET_RPI_2
bool "Raspberry Pi 2"
-   select CPU_V7
select ARMV7_LPAE
+   select BCM2836
+   select CPU_V7
 
 endchoice
 
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index a788ce42e44c..86422e390da2 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -7,7 +7,6 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_BCM2835
 #define CONFIG_SYS_CACHELINE_SIZE  32
 
 #include "rpi-common.h"
diff --git a/include/configs/rpi_2.h b/include/configs/rpi_2.h
index 13dc8de14315..0917e8650864 100644
--- a/include/configs/rpi_2.h
+++ b/include/configs/rpi_2.h
@@ -8,7 +8,6 @@
 #define __CONFIG_H
 
 #define CONFIG_SKIP_LOWLEVEL_INIT
-#define CONFIG_BCM2836
 #define CONFIG_SYS_CACHELINE_SIZE  64
 
 #include "rpi-common.h"
-- 
2.7.3

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

[U-Boot] [PATCH 5/5] rpi: BCM2837 and Raspberry Pi 3 32-bit support

[Stephen Warren]

The Raspberry Pi 3 contains a BCM2837 SoC. The BCM2837 is a BCM2836 with
the CPU complex swapped out for a quad-core ARMv8. This can operate in 32-
or 64-bit mode. 32-bit mode is the current default selected by the
VideoCore firmware on the Raspberry Pi 3. This patch adds a 32-bit port of
U-Boot for the Raspberry Pi 3.

>From U-Boot's perspective, the only delta between the RPi 2 and RPi 3 is a
change in usage of the SoC UARTs. On all previous Pis, the PL011 was the
only UART in use. The Raspberry Pi 3 adds a Bluetooth module which uses a
UART to connect to the SoC. By default, the PL011 is used for this purpose
since it has larger FIFOs than the other ("mini" UART). However, this can
be configured via the VideoCore firmware's config.txt file. This patch
hard-codes use of the mini UART in the RPi 3 port. If your system uses the
PL011 UART for the console even on the RPi 3, please use the RPi 2 U-Boot
port instead. A future change might determine which UART to use at
run-time, thus allowing the RPi 2 and RPi 3 (32-bit) ports to be squashed
together.

The mini UART has some limitations. One externally visible issue in the
BCM2837 integration is that the UART divides the SoC's "core clock" to
generate the baud rate. The core clock is typically variable, and under
control of the VideoCore firmware for thermal management reasons. If the
VC FW does modify the core clock rate, UART communication will be
corrupted since the baud rate will vary from the expected value. This was
not an issue for the PL011 UART, since it is fed by a fixed 3MHz clock. To
work around this, the VideoCore firmware can be told not to modify the SoC
core clock. However, the only way this can happen and be thermally safe is
to limit the core clock to a low/minimum frequency. This leaves
performance on the table for use-cases that don't care about a UART
console. Consequently, use of the mini UART console must be explicitly
requested by entering the following line into config.txt

enable_uart=1

A recent version of the VC firmware is required to ensure that the mini
UART is fully and correctly initialized by the VC FW. At least
firmware.git commit 7f536a27cc74 "kernel: lirc_rpi: Lower IR reception
error to debug See: https://github.com/raspberrypi/linux/pull/1361; is
required. However, note that there is a bug in that version that prevents
MMC from operating correctly on any Pi. As of 20160323 that is not fixed.

Signed-off-by: Stephen Warren <swar...@wwwdotorg.org>
---
 arch/arm/mach-bcm283x/Kconfig   | 21 +
 board/raspberrypi/rpi/rpi.c | 16 +++-
 board/raspberrypi/rpi_3_32b/MAINTAINERS |  6 ++
 board/raspberrypi/rpi_3_32b/Makefile|  7 +++
 configs/rpi_3_32b_defconfig | 11 +++
 include/configs/rpi-common.h|  9 -
 include/configs/rpi_3_32b.h | 15 +++
 7 files changed, 83 insertions(+), 2 deletions(-)
 create mode 100644 board/raspberrypi/rpi_3_32b/MAINTAINERS
 create mode 100644 board/raspberrypi/rpi_3_32b/Makefile
 create mode 100644 configs/rpi_3_32b_defconfig
 create mode 100644 include/configs/rpi_3_32b.h

diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index 0790dd02d6f0..ea33d77ae1f7 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -6,6 +6,10 @@ config BCM2836
bool "Broadcom BCM2836 SoC support"
depends on ARCH_BCM283X
 
+config BCM2837
+   bool "Broadcom BCM2837 SoC support"
+   depends on ARCH_BCM283X
+
 menu "Broadcom BCM283X family"
depends on ARCH_BCM283X
 
@@ -41,11 +45,27 @@ config TARGET_RPI_2
select BCM2836
select CPU_V7
 
+config TARGET_RPI_3_32B
+   bool "Raspberry Pi 3 32-bit build"
+ Support for all BCM2837-based Raspberry Pi variants, such as
+ the RPi 3 model B, in AArch32 (32-bit) mode.
+
+ This option assumes the VideoCore firmware is configured to use the
+ mini UART (rather than PL011) for the serial console. This is the
+ default on the RPi 3. To enable the UART console, the following non-
+ default option must be present in config.txt: enable_uart=1.
+
+ This option creates a build targetting the ARMv7/AArch32 ISA.
+   select ARMV7_LPAE
+   select BCM2837
+   select CPU_V7
+
 endchoice
 
 config SYS_BOARD
default "rpi" if TARGET_RPI
default "rpi_2" if TARGET_RPI_2
+   default "rpi_3_32b" if TARGET_RPI_3_32B
 
 config SYS_VENDOR
default "raspberrypi"
@@ -56,5 +76,6 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "rpi" if TARGET_RPI
default "rpi_2" if TARGET_RPI_2
+   default "rpi_3_32b" if TARGET_RPI_3_32B
 
 endmenu
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index d31a79c661d9..20b5cf48f55

[U-Boot] [PATCH 3/5] rpi: add Raspberry Pi 3 board ID

[Stephen Warren]

This allows U-Boot to known the name of the board.

The existing rpi_2_defconfig should be able to operate correctly on the
Raspberry Pi 3 in 32-bit mode /if/ you have configured the firmware to use
the PL011 UART as the console UART (the default is the mini UART). This
should be possible by loading the pi3-miniuart-bt DT overlay. As of
20160323 (or firmware.git commit 7f536a27cc74 "kernel: lirc_rpi: Lower IR
reception error to debug See: https://github.com/raspberrypi/linux/pull/1361;
this doesn't seem to work; I assume this is due to a firmware bug.

Signed-off-by: Stephen Warren <swar...@wwwdotorg.org>
---
 board/raspberrypi/rpi/rpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 54ea4a814b54..d31a79c661d9 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -109,6 +109,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
"bcm2836-rpi-2-b.dtb",
true,
},
+   [0x8] = {
+   "3 Model B",
+   "bcm2837-rpi-3-b.dtb",
+   true,
+   },
[0x9] = {
"Zero",
"bcm2835-rpi-zero.dtb",
-- 
2.7.3

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

[U-Boot] [PATCH 2/5] rpi: use constant "unknown board" DT filename

[Stephen Warren]

To simplify support for new SoCs, just use a constant filename
for the unknown case. In practice this case shouldn't be hit anyway, so
the filename isn't relevant, and certainly doesn't need to differentiate
between SoCs. If a user has an as-yet-unknown board, they can override
this value in the environment anyway.

Signed-off-by: Stephen Warren 
---
 board/raspberrypi/rpi/rpi.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 1fd7591f3325..54ea4a814b54 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -99,11 +99,7 @@ struct rpi_model {
 
 static const struct rpi_model rpi_model_unknown = {
"Unknown model",
-#ifdef CONFIG_BCM2836
-   "bcm2836-rpi-other.dtb",
-#else
-   "bcm2835-rpi-other.dtb",
-#endif
+   "bcm283x-rpi-other.dtb",
false,
 };
 
-- 
2.7.3

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

[U-Boot] [PATCH 4/5] ARM: bcm2835: expand Kconfig target descriptions

[Stephen Warren]

This adds an explanation of which Raspberry Pi models each target option
supports.

Signed-off-by: Stephen Warren 
---
 arch/arm/mach-bcm283x/Kconfig | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index dc6770437ec6..0790dd02d6f0 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -14,12 +14,29 @@ choice
optional
 
 config TARGET_RPI
-   bool "Raspberry Pi"
+   bool "Raspberry Pi (all BCM2835 variants)"
+   help
+ Support for all ARM1176-/BCM2835-based Raspberry Pi variants, such as
+ the A, A+, B, B+, Compute Module, and Zero. This option cannot
+ support BCM2836/BCM2837-based Raspberry Pis such as the RPi 2 and
+ RPi 3 due to different peripheral address maps.
+
+ This option creates a build targetting the ARM1176 ISA.
select BCM2835
select CPU_ARM1176
 
 config TARGET_RPI_2
bool "Raspberry Pi 2"
+   help
+ Support for all BCM2836-based Raspberry Pi variants, such as
+ the RPi 2 model B.
+
+ This option should also support BCM2837-based variants such as the
+ RPi 3 model B, when run in 32-bit mode, provided you have configured
+ the VideoCore firmware (via config.txt) to select the PL011 UART for
+ the console (the default is the mini UART on the RPi 3).
+
+ This option creates a build targetting the ARMv7/AArch32 ISA.
select ARMV7_LPAE
select BCM2836
select CPU_V7
-- 
2.7.3

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

Re: [U-Boot] [PATCH 2/2] ARM: keystone2: Add missing privilege ID settings

[Lokesh Vutla]

On Wednesday 23 March 2016 08:44 PM, Nishanth Menon wrote:
> Add missing Privilege ID settings for KS2 SoCs.
> 
> Based on:
> K2H/K: Table 6-7. Privilege ID Settings from SPRS866E (Nov 2013)
>   http://www.ti.com/lit/ds/symlink/66ak2h14.pdf (page 99)
> K2L: Table 7-7. Privilege ID Settings from SPRS930 (April 2015)
>   http://www.ti.com/lit/ds/symlink/66ak2l06.pdf (page 71)
> K2E: Table 7-7. Privilege ID Settings from SPRS865D (Mar 2015)
>   http://www.ti.com/lit/ds/symlink/66ak2e05.pdf (page 75)
> K2G: Table 3-16. PrivIDs from SPRUHY8 (Jan 2016)
>   http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf (page 238)
> 
> Overall mapping:
> ---+---+---+---+-
> PrivID | KS2H/K| K2L   | K2E   | K2G
> ---+---+---+---+-
> 0  | C66x 0| C66x 0| C66x 0| C66x 0
> 1  | C66x 1| C66x 1| Reserved  | ARM
> 2  | C66x 2| C66x 2| Reserved  | ICSS0
> 3  | C66x 3| C66x 3| Reserved  | ICSS1
> 4  | C66x 4| Reserved  | Reserved  | NETCP
> 5  | C66x 5| Reserved  | Reserved  | CPIE
> 6  | C66x 6| Reserved  | Reserved  | USB
> 7  | C66x 7| Reserved  | Reserved  | Reserved
> 8  | ARM   | ARM   | ARM   | MLB
> 9  | NetCP | NetCP | NetCP | PMMC
> 10 | QM_PDSP   | QM_PDSP   | QM_PDSP   | DSS
> 11 | PCIe_0| PCIe_0| PCIe_0| MMC
> 12 | DEBUG/DAP | DEBUG/DAP | DEBUG/DAP | DEBUG/DAP
> 13 | Reserved  | Reserved  | PCIe_1| Reserved
> 14 | HyperLink | PCIe_1| HyperLink | Reserved
> 15 | Reserved  | Reserved  | TSIP  | Reserved
> ---+---+---+---+-
> 
> NOTE: Few of these might have default configurations, however,
> since most are software configurable, it is better to explicitly
> configure the system to have a known default state.
> 
> Without programming these, we end up seeing lack of coherency on certain
> peripherals resulting in inexplicable failures (such as USB peripheral's
> DMA data not appearing on ARM etc and weird workarounds being done by
> drivers including cache flushes which tend to have system wide
> performance impact).
> 
> By marking these segments as shared, we also ensure SoC wide coherency
> is enabled.

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh


> 
> Reported-by: Bin Liu 
> Signed-off-by: Nishanth Menon 
> ---
>  arch/arm/mach-keystone/include/mach/hardware.h | 23 ++
>  arch/arm/mach-keystone/init.c  | 32 
> +-
>  2 files changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
> b/arch/arm/mach-keystone/include/mach/hardware.h
> index dd9268fbf209..38d019056a29 100644
> --- a/arch/arm/mach-keystone/include/mach/hardware.h
> +++ b/arch/arm/mach-keystone/include/mach/hardware.h
> @@ -216,22 +216,45 @@ typedef volatile unsigned int   *dv_reg_p;
>  #define KS2_MSMC_CTRL_BASE   0x0bc0
>  #define KS2_MSMC_DATA_BASE   0x0c00
>  
> +/* KS2 Generic Privilege ID Settings for MSMC2 */
> +#define KS2_MSMC_SEGMENT_C6X_0   0
> +#define KS2_MSMC_SEGMENT_C6X_1   1
> +#define KS2_MSMC_SEGMENT_C6X_2   2
> +#define KS2_MSMC_SEGMENT_C6X_3   3
> +#define KS2_MSMC_SEGMENT_C6X_4   4
> +#define KS2_MSMC_SEGMENT_C6X_5   5
> +#define KS2_MSMC_SEGMENT_C6X_6   6
> +#define KS2_MSMC_SEGMENT_C6X_7   7
> +
> +#define KS2_MSMC_SEGMENT_DEBUG   12
> +
>  /* KS2 HK/L/E MSMC PRIVIDs  for MSMC2 */
>  #define K2HKLE_MSMC_SEGMENT_ARM  8
>  #define K2HKLE_MSMC_SEGMENT_NETCP9
>  #define K2HKLE_MSMC_SEGMENT_QM_PDSP  10
>  #define K2HKLE_MSMC_SEGMENT_PCIE011
>  
> +/* K2HK specific Privilege ID Settings */
> +#define K2HKE_MSMC_SEGMENT_HYPERLINK 14
> +
>  /* K2L specific Privilege ID Settings */
>  #define K2L_MSMC_SEGMENT_PCIE1   14
>  
>  /* K2E specific Privilege ID Settings */
>  #define K2E_MSMC_SEGMENT_PCIE1   13
> +#define K2E_MSMC_SEGMENT_TSIP15
>  
>  /* K2G specific Privilege ID Settings */
>  #define K2G_MSMC_SEGMENT_ARM 1
> +#define K2G_MSMC_SEGMENT_ICSS0   2
> +#define K2G_MSMC_SEGMENT_ICSS1   3
>  #define K2G_MSMC_SEGMENT_NSS 4
>  #define K2G_MSMC_SEGMENT_PCIE5
> +#define K2G_MSMC_SEGMENT_USB 6
> +#define K2G_MSMC_SEGMENT_MLB 8
> +#define K2G_MSMC_SEGMENT_PMMC9
> +#define K2G_MSMC_SEGMENT_DSS 10
> +#define K2G_MSMC_SEGMENT_MMC 11
>  
>  /* MSMC segment size shift bits */
>  #define KS2_MSMC_SEG_SIZE_SHIFT  12
> diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
> index 2368315ff68c..3b6d5efce1a1 100644
> --- a/arch/arm/mach-keystone/init.c
> +++ b/arch/arm/mach-keystone/init.c
> @@ 

Re: [U-Boot] [PATCH 1/2] ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery

[Lokesh Vutla]

On Wednesday 23 March 2016 08:44 PM, Nishanth Menon wrote:
> MSMC segment Privilege ID is not consistent accross the keystone2 SoCs.
> As the first step to ensure complete SoC wide coherency setup, lets
> refactor the macros to remove the #if-deffery around the code which
> obfuscates which IDs are actually enabled for which SoC.
> 
> As a result of this change the PCIe configuration is moved after the
> msmc configuration is complete, but that should ideally have no
> functional impact.

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> 
> Signed-off-by: Nishanth Menon 
> ---
>  arch/arm/mach-keystone/include/mach/hardware-k2e.h |  3 --
>  arch/arm/mach-keystone/include/mach/hardware-k2l.h |  3 --
>  arch/arm/mach-keystone/include/mach/hardware.h | 27 +-
>  arch/arm/mach-keystone/init.c  | 43 
> ++
>  4 files changed, 53 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2e.h 
> b/arch/arm/mach-keystone/include/mach/hardware-k2e.h
> index df499957e54d..e6bc77caaf09 100644
> --- a/arch/arm/mach-keystone/include/mach/hardware-k2e.h
> +++ b/arch/arm/mach-keystone/include/mach/hardware-k2e.h
> @@ -34,9 +34,6 @@
>  #define KS2_LPSC_PCIE_1  27
>  #define KS2_LPSC_XGE 50
>  
> -/* MSMC */
> -#define KS2_MSMC_SEGMENT_PCIE1   13
> -
>  /* Chip Interrupt Controller */
>  #define KS2_CIC2_DDR3_ECC_IRQ_NUM-1  /* not defined in K2E */
>  #define KS2_CIC2_DDR3_ECC_CHAN_NUM   -1  /* not defined in K2E */
> diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2l.h 
> b/arch/arm/mach-keystone/include/mach/hardware-k2l.h
> index a59e0713593f..92c17d7dd5ba 100644
> --- a/arch/arm/mach-keystone/include/mach/hardware-k2l.h
> +++ b/arch/arm/mach-keystone/include/mach/hardware-k2l.h
> @@ -53,9 +53,6 @@
>  #define KS2_LPSC_FFTC_B  49
>  #define KS2_LPSC_IQN_AIL 50
>  
> -/* MSMC */
> -#define KS2_MSMC_SEGMENT_PCIE1   14
> -
>  /* Chip Interrupt Controller */
>  #define KS2_CIC2_DDR3_ECC_IRQ_NUM0x0D3
>  #define KS2_CIC2_DDR3_ECC_CHAN_NUM   0x01D
> diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
> b/arch/arm/mach-keystone/include/mach/hardware.h
> index 8ca19bbcdbe9..dd9268fbf209 100644
> --- a/arch/arm/mach-keystone/include/mach/hardware.h
> +++ b/arch/arm/mach-keystone/include/mach/hardware.h
> @@ -215,16 +215,23 @@ typedef volatile unsigned int   *dv_reg_p;
>  /* MSMC control */
>  #define KS2_MSMC_CTRL_BASE   0x0bc0
>  #define KS2_MSMC_DATA_BASE   0x0c00
> -#ifndef CONFIG_SOC_K2G
> -#define KS2_MSMC_SEGMENT_TETRIS  8
> -#define KS2_MSMC_SEGMENT_NETCP   9
> -#define KS2_MSMC_SEGMENT_QM_PDSP 10
> -#define KS2_MSMC_SEGMENT_PCIE0   11
> -#else
> -#define KS2_MSMC_SEGMENT_TETRIS  1
> -#define KS2_MSMC_SEGMENT_NETCP   4
> -#define KS2_MSMC_SEGMENT_PCIE0   5
> -#endif
> +
> +/* KS2 HK/L/E MSMC PRIVIDs  for MSMC2 */
> +#define K2HKLE_MSMC_SEGMENT_ARM  8
> +#define K2HKLE_MSMC_SEGMENT_NETCP9
> +#define K2HKLE_MSMC_SEGMENT_QM_PDSP  10
> +#define K2HKLE_MSMC_SEGMENT_PCIE011
> +
> +/* K2L specific Privilege ID Settings */
> +#define K2L_MSMC_SEGMENT_PCIE1   14
> +
> +/* K2E specific Privilege ID Settings */
> +#define K2E_MSMC_SEGMENT_PCIE1   13
> +
> +/* K2G specific Privilege ID Settings */
> +#define K2G_MSMC_SEGMENT_ARM 1
> +#define K2G_MSMC_SEGMENT_NSS 4
> +#define K2G_MSMC_SEGMENT_PCIE5
>  
>  /* MSMC segment size shift bits */
>  #define KS2_MSMC_SEG_SIZE_SHIFT  12
> diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
> index aadd10bff270..2368315ff68c 100644
> --- a/arch/arm/mach-keystone/init.c
> +++ b/arch/arm/mach-keystone/init.c
> @@ -96,22 +96,51 @@ static void config_pcie_mode(int pcie_port,  enum 
> pci_mode mode)
>   __raw_writel(val, KS2_DEVCFG);
>  }
>  
> +static void msmc_k2hkle_common_setup(void)
> +{
> + msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
> + msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
> +#ifdef KS2_MSMC_SEGMENT_QM_PDSP
> + msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
> +#endif
> + msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_PCIE0);
> +}
> +
> +static inline void msmc_k2l_setup(void)
> +{
> + msmc_share_all_segments(K2L_MSMC_SEGMENT_PCIE1);
> +}
> +
> +static inline void msmc_k2e_setup(void)
> +{
> + msmc_share_all_segments(K2E_MSMC_SEGMENT_PCIE1);
> +}
> +
> +static inline void msmc_k2g_setup(void)
> +{
> + msmc_share_all_segments(K2G_MSMC_SEGMENT_ARM);
> + msmc_share_all_segments(K2G_MSMC_SEGMENT_NSS);
> + msmc_share_all_segments(K2G_MSMC_SEGMENT_PCIE);
> +}
> +
>  int arch_cpu_init(void)
>  {
>   chip_configuration_unlock();
>   icache_enable();
>  
> - 

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:08 AM, Tom Rini wrote:

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini 
wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut 
wrote:

This patch decouples U-Boot binary from the toolchain on
systems where
private libgcc is available. Instead of pulling in functions
provided
by the libgcc from the toolchain, U-Boot will use it's own set
of libgcc
functions. These functions are usually imported from Linux
kernel, which
also uses it's own libgcc functions instead of the ones
provided by the
toolchain.

This patch solves a rather common problem. The toolchain can
usually
generate code for many variants of target architecture and
often even
different endianness. The libgcc on the other hand is usually
compiled
for one particular configuration and the functions provided by
it may
or may not be suited for use in U-Boot. This can manifest in
two ways,
either the U-Boot fails to compile altogether and linker will
complain
or, in the much worse case, the resulting U-Boot will build,
but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix
for some
cases where a target cannot properly link with the libgcc
provided by
the (specific release of the) GCC toolchain in use. Using
private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this
respect.


This isn't true, exactly.  If using clang for example everyone
needs to
enable this code.  We're also using -fno-builtin -ffreestanding
which
should limit the amount of interference from the toolchain.  And
we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing
all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division
since we
switched to 64-bit all around ARM. It comes from clock
calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor
do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?


I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
Linux
arm libgcc does have arch/arm/lib/div64.S file that provides
__do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit
ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have
div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.


In that case, we should just import div64.S from Linux on arm32 and be
done with it ? Since we now have all the necessary macros thanks to the
first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?


Sure I'll test it, no problems. Just bake the patch :)


Done, give it a go please.


Will do first thing tomorrow morning when I'm back at my work desk. Will
post the results when done.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 5/5] bcm2835 video: Map fb as cached

[Stephen Warren]

On 03/23/2016 06:27 PM, Alexander Graf wrote:

The bcm2835 frame buffer is in RAM, so we can easily map it as cached and gain
all the glorious performance boost that brings with it.


Tested-by: Stephen Warren 


diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c



@@ -44,6 +44,7 @@ void lcd_ctrl_init(void *lcdbase)



+   /* Enable dcache for the frame buffer */
+   fb_start = ALIGN(gd->fb_base, 1 << MMU_SECTION_SHIFT);
+   fb_end = gd->fb_base + msg_setup->allocate_buffer.body.resp.fb_size;
+   fb_end = ALIGN(fb_end, 1 << MMU_SECTION_SHIFT);
+   mmu_set_region_dcache_behaviour(fb_start, fb_end - fb_start,
+   DCACHE_WRITEBACK);


Shouldn't the start be rounded down and the end be rounded up to cover 
the entire FB RAM? Normally it might be problematic to push the 
boundaries outside the relevant data block since it would affect 
adjacent memory that might not then be aware of the cache setup. 
However, since the entire FB is in the VC portion of RAM and U-Boot is 
touching nothing else there, it should be fine in this case. (And even 
if it wasn't, the two ALIGNs would still want to move in opposite 
directions; start up and end down).

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

[U-Boot] [PATCH] efi_loader: Fix some entry/exit points

[Alexander Graf]

When switching between EFI context and U-Boot context we need to swap
the register that "gd" resides in.

Some functions slipped through here, with efi_allocate_pool / efi_free_pool
not doing the switch correctly and efi_return_handle switching too often.

Fix them all up to make sure we always have consistent register state.

Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_boottime.c | 13 ++---
 lib/efi_loader/efi_image_loader.c |  5 +
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 87400de..9daca50 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -137,12 +137,20 @@ efi_status_t EFIAPI efi_get_memory_map_ext(unsigned long 
*memory_map_size,
 static efi_status_t EFIAPI efi_allocate_pool(int pool_type, unsigned long size,
 void **buffer)
 {
-   return efi_allocate_pages(0, pool_type, (size + 0xfff) >> 12, 
(void*)buffer);
+   efi_status_t r;
+
+   EFI_ENTRY("%d, %ld, %p", pool_type, size, buffer);
+   r = efi_allocate_pages(0, pool_type, (size + 0xfff) >> 12, 
(void*)buffer);
+   return EFI_EXIT(r);
 }
 
 static efi_status_t EFIAPI efi_free_pool(void *buffer)
 {
-   return efi_free_pages((ulong)buffer, 0);
+   efi_status_t r;
+
+   EFI_ENTRY("%p", buffer);
+   r = efi_free_pages((ulong)buffer, 0);
+   return EFI_EXIT(r);
 }
 
 /*
@@ -706,7 +714,6 @@ static efi_status_t EFIAPI efi_handle_protocol(void *handle,
   efi_guid_t *protocol,
   void **protocol_interface)
 {
-   EFI_ENTRY("%p, %p, %p", handle, protocol, protocol_interface);
return efi_open_protocol(handle, protocol, protocol_interface,
 NULL, NULL, 0);
 }
diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index d558f5a..574b204 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -22,11 +22,8 @@ efi_status_t EFIAPI efi_return_handle(void *handle, 
efi_guid_t *protocol,
void **protocol_interface, void *agent_handle,
void *controller_handle, uint32_t attributes)
 {
-   EFI_ENTRY("%p, %p, %p, %p, %p, 0x%x", handle, protocol,
- protocol_interface, agent_handle, controller_handle,
- attributes);
*protocol_interface = handle;
-   return EFI_EXIT(EFI_SUCCESS);
+   return EFI_SUCCESS;
 }
 
 static void efi_loader_relocate(const IMAGE_BASE_RELOCATION *rel,
-- 
1.8.5.6

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

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Marek Vasut]

On 03/24/2016 01:13 AM, Tom Rini wrote:
> On Thu, Mar 24, 2016 at 12:49:54AM +0100, Marek Vasut wrote:
>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>
 On 03/24/2016 12:08 AM, Tom Rini wrote:
> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>> On Wed, 23 Mar 2016, Tom Rini wrote:
>>
>>> On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
 Hello Tom,

 On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini 
 wrote:
> On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
>> Hello Marek,
>>
>> On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut 
>> wrote:
>>> This patch decouples U-Boot binary from the toolchain on
>>> systems where
>>> private libgcc is available. Instead of pulling in functions
>>> provided
>>> by the libgcc from the toolchain, U-Boot will use it's own set
>>> of libgcc
>>> functions. These functions are usually imported from Linux
>>> kernel, which
>>> also uses it's own libgcc functions instead of the ones
>>> provided by the
>>> toolchain.
>>>
>>> This patch solves a rather common problem. The toolchain can
>>> usually
>>> generate code for many variants of target architecture and
>>> often even
>>> different endianness. The libgcc on the other hand is usually
>>> compiled
>>> for one particular configuration and the functions provided by
>>> it may
>>> or may not be suited for use in U-Boot. This can manifest in
>>> two ways,
>>> either the U-Boot fails to compile altogether and linker will
>>> complain
>>> or, in the much worse case, the resulting U-Boot will build,
>>> but will
>>> misbehave in very subtle and hard to debug ways.
>>
>> I don't think using private libgcc by default is a good idea.
>>
>> U-Boot's private libgcc is not a feature of U-Boot, but a fix
>> for some
>> cases where a target cannot properly link with the libgcc
>> provided by
>> the (specific release of the) GCC toolchain in use. Using
>> private libgcc
>> to other cases than these does not fix or improve anything; those
>> other cases were working and did not require any fix in this
>> respect.
>
> This isn't true, exactly.  If using clang for example everyone
> needs to
> enable this code.  We're also using -fno-builtin -ffreestanding
> which
> should limit the amount of interference from the toolchain.  And
> we get
> that.

 You mean clang does not produce self-sustained binaries?
>>>
>>> clang does not provide "libgcc", so there's no -lgcc providing all of
>>> the functions that are (today) in:
>>> _ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
>>> _umodsi3.S div0.S  _uldivmod.S
>>> which aside from __modsi3 and __umodsi3 are all __aeabi_xxx
>>
>> There is also _udivmoddi4 pulled from libgcc for 64-bit division
>> since we
>> switched to 64-bit all around ARM. It comes from clock calculations for
>> video, e.g. from drivers/video/ipu_common.c for i.MX6.
>
> Well, this is an example of why we both don't want libgcc ever nor do we
> want to overly expand what we do offer.  In this case isn't it an
> example of something that should be using lldiv/do_div/etc?

 I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
 also doesn't implement the function. Which toolchain do you use and
 which target did you compile?
>>>
>>> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
>>> Linux
>>> arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
>>> function that is used by do_div() from include/asm/div64.h for 32-bit ARM
>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
>>> (that is totally different from what Linux provides) but no div64.S in
>>> arch/arm/lib.
>>
>> In that case, we should just import div64.S from Linux on arm32 and be
>> done with it ? Since we now have all the necessary macros thanks to the
>> first four patches in this series, that should be trivial.
>>
>> What do you think? I can bake a patch real quick, so you can test it ?
> 
> Follow-up _series_ to re-sync our 64bit math stuff with the kernel.
> 
Something tells me this is gonna be one patch , not a series.

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

[U-Boot] [PATCH v4 5/5] bcm2835 video: Map fb as cached

[Alexander Graf]

The bcm2835 frame buffer is in RAM, so we can easily map it as cached and gain
all the glorious performance boost that brings with it.

Signed-off-by: Alexander Graf 

---

v2 -> v3:

  - Fix align parameters
  - Fix whitespace

v3 -> v4:

  - Align start of fb as well to align with segments
  - Align fb size on segment size, not page size
---
 drivers/video/bcm2835.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index bff1fcb..a376537 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -44,6 +44,7 @@ void lcd_ctrl_init(void *lcdbase)
ALLOC_CACHE_ALIGN_BUFFER(struct msg_setup, msg_setup, 1);
int ret;
u32 w, h;
+   u32 fb_start, fb_end;
 
debug("bcm2835: Query resolution...\n");
 
@@ -106,6 +107,14 @@ void lcd_ctrl_init(void *lcdbase)
 
gd->fb_base = bus_to_phys(
msg_setup->allocate_buffer.body.resp.fb_address);
+
+   /* Enable dcache for the frame buffer */
+   fb_start = ALIGN(gd->fb_base, 1 << MMU_SECTION_SHIFT);
+   fb_end = gd->fb_base + msg_setup->allocate_buffer.body.resp.fb_size;
+   fb_end = ALIGN(fb_end, 1 << MMU_SECTION_SHIFT);
+   mmu_set_region_dcache_behaviour(fb_start, fb_end - fb_start,
+   DCACHE_WRITEBACK);
+   lcd_set_flush_dcache(1);
 }
 
 void lcd_enable(void)
-- 
1.8.5.6

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

Re: [U-Boot] [PATCH] arm: mxs: Update MX28EVK config

[Fabio Estevam]

On Wed, Mar 23, 2016 at 8:57 PM, Marek Vasut  wrote:
> Enable FIT image support, EXT4 support and generic FS support.
>
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 

Reviewed-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Tom Rini]

On Thu, Mar 24, 2016 at 12:49:54AM +0100, Marek Vasut wrote:
> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
> > On Thu, 24 Mar 2016, Marek Vasut wrote:
> > 
> >> On 03/24/2016 12:08 AM, Tom Rini wrote:
> >>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>  On Wed, 23 Mar 2016, Tom Rini wrote:
> 
> > On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
> >> Hello Tom,
> >>
> >> On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini 
> >> wrote:
> >>> On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
>  Hello Marek,
> 
>  On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut 
>  wrote:
> > This patch decouples U-Boot binary from the toolchain on
> > systems where
> > private libgcc is available. Instead of pulling in functions
> > provided
> > by the libgcc from the toolchain, U-Boot will use it's own set
> > of libgcc
> > functions. These functions are usually imported from Linux
> > kernel, which
> > also uses it's own libgcc functions instead of the ones
> > provided by the
> > toolchain.
> >
> > This patch solves a rather common problem. The toolchain can
> > usually
> > generate code for many variants of target architecture and
> > often even
> > different endianness. The libgcc on the other hand is usually
> > compiled
> > for one particular configuration and the functions provided by
> > it may
> > or may not be suited for use in U-Boot. This can manifest in
> > two ways,
> > either the U-Boot fails to compile altogether and linker will
> > complain
> > or, in the much worse case, the resulting U-Boot will build,
> > but will
> > misbehave in very subtle and hard to debug ways.
> 
>  I don't think using private libgcc by default is a good idea.
> 
>  U-Boot's private libgcc is not a feature of U-Boot, but a fix
>  for some
>  cases where a target cannot properly link with the libgcc
>  provided by
>  the (specific release of the) GCC toolchain in use. Using
>  private libgcc
>  to other cases than these does not fix or improve anything; those
>  other cases were working and did not require any fix in this
>  respect.
> >>>
> >>> This isn't true, exactly.  If using clang for example everyone
> >>> needs to
> >>> enable this code.  We're also using -fno-builtin -ffreestanding
> >>> which
> >>> should limit the amount of interference from the toolchain.  And
> >>> we get
> >>> that.
> >>
> >> You mean clang does not produce self-sustained binaries?
> >
> > clang does not provide "libgcc", so there's no -lgcc providing all of
> > the functions that are (today) in:
> > _ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
> > _umodsi3.S div0.S  _uldivmod.S
> > which aside from __modsi3 and __umodsi3 are all __aeabi_xxx
> 
>  There is also _udivmoddi4 pulled from libgcc for 64-bit division
>  since we
>  switched to 64-bit all around ARM. It comes from clock calculations for
>  video, e.g. from drivers/video/ipu_common.c for i.MX6.
> >>>
> >>> Well, this is an example of why we both don't want libgcc ever nor do we
> >>> want to overly expand what we do offer.  In this case isn't it an
> >>> example of something that should be using lldiv/do_div/etc?
> >>
> >> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
> >> also doesn't implement the function. Which toolchain do you use and
> >> which target did you compile?
> > 
> > I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
> > Linux
> > arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
> > function that is used by do_div() from include/asm/div64.h for 32-bit ARM
> > platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
> > (that is totally different from what Linux provides) but no div64.S in
> > arch/arm/lib.
> 
> In that case, we should just import div64.S from Linux on arm32 and be
> done with it ? Since we now have all the necessary macros thanks to the
> first four patches in this series, that should be trivial.
> 
> What do you think? I can bake a patch real quick, so you can test it ?

Follow-up _series_ to re-sync our 64bit math stuff with the kernel.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Marek Vasut]

On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Marek Vasut wrote:
> 
>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>
 On 03/24/2016 12:08 AM, Tom Rini wrote:
> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>> On Wed, 23 Mar 2016, Tom Rini wrote:
>>
>>> On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
 Hello Tom,

 On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini 
 wrote:
> On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
>> Hello Marek,
>>
>> On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut 
>> wrote:
>>> This patch decouples U-Boot binary from the toolchain on
>>> systems where
>>> private libgcc is available. Instead of pulling in functions
>>> provided
>>> by the libgcc from the toolchain, U-Boot will use it's own set
>>> of libgcc
>>> functions. These functions are usually imported from Linux
>>> kernel, which
>>> also uses it's own libgcc functions instead of the ones
>>> provided by the
>>> toolchain.
>>>
>>> This patch solves a rather common problem. The toolchain can
>>> usually
>>> generate code for many variants of target architecture and
>>> often even
>>> different endianness. The libgcc on the other hand is usually
>>> compiled
>>> for one particular configuration and the functions provided by
>>> it may
>>> or may not be suited for use in U-Boot. This can manifest in
>>> two ways,
>>> either the U-Boot fails to compile altogether and linker will
>>> complain
>>> or, in the much worse case, the resulting U-Boot will build,
>>> but will
>>> misbehave in very subtle and hard to debug ways.
>>
>> I don't think using private libgcc by default is a good idea.
>>
>> U-Boot's private libgcc is not a feature of U-Boot, but a fix
>> for some
>> cases where a target cannot properly link with the libgcc
>> provided by
>> the (specific release of the) GCC toolchain in use. Using
>> private libgcc
>> to other cases than these does not fix or improve anything; those
>> other cases were working and did not require any fix in this
>> respect.
>
> This isn't true, exactly.  If using clang for example everyone
> needs to
> enable this code.  We're also using -fno-builtin -ffreestanding
> which
> should limit the amount of interference from the toolchain.  And
> we get
> that.

 You mean clang does not produce self-sustained binaries?
>>>
>>> clang does not provide "libgcc", so there's no -lgcc providing
>>> all of
>>> the functions that are (today) in:
>>> _ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
>>> _umodsi3.S div0.S  _uldivmod.S
>>> which aside from __modsi3 and __umodsi3 are all __aeabi_xxx
>>
>> There is also _udivmoddi4 pulled from libgcc for 64-bit division
>> since we
>> switched to 64-bit all around ARM. It comes from clock
>> calculations for
>> video, e.g. from drivers/video/ipu_common.c for i.MX6.
>
> Well, this is an example of why we both don't want libgcc ever nor
> do we
> want to overly expand what we do offer.  In this case isn't it an
> example of something that should be using lldiv/do_div/etc?

 I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
 also doesn't implement the function. Which toolchain do you use and
 which target did you compile?
>>>
>>> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
>>> Linux
>>> arm libgcc does have arch/arm/lib/div64.S file that provides
>>> __do_div64()
>>> function that is used by do_div() from include/asm/div64.h for 32-bit
>>> ARM
>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have
>>> div64.h
>>> (that is totally different from what Linux provides) but no div64.S in
>>> arch/arm/lib.
>>
>> In that case, we should just import div64.S from Linux on arm32 and be
>> done with it ? Since we now have all the necessary macros thanks to the
>> first four patches in this series, that should be trivial.
>>
>> What do you think? I can bake a patch real quick, so you can test it ?
> 
> Sure I'll test it, no problems. Just bake the patch :)

Done, give it a go please.

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

[U-Boot] [PATCH] arm: lib: Import __do_div64 from Linux

[Marek Vasut]

Import __do_div64 from Linux 4.4.6 , commit 
0d1912303e54ed1b2a371be0bba51c384dd57326
on arm32. This function is for some toolchains, which generate _udivmoddi4()
for 64 bit division.

Since we do not support stack unwinding, instead of importing the whole
asm/unwind.h and all the baggage, this patch defines empty UNWIND() macro.

Signed-off-by: Marek Vasut 
Cc: k...@koi8.net
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/Makefile |   2 +-
 arch/arm/lib/div64.S  | 214 ++
 2 files changed, 215 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/lib/div64.S

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index dce6ff9..29c2f2b 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -6,7 +6,7 @@
 #
 
 lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o \
-   lib1funcs.o uldivmod.o div0.o
+   lib1funcs.o uldivmod.o div0.o div64.o
 
 ifdef CONFIG_CPU_V7M
 obj-y  += vectors_m.o crt0.o
diff --git a/arch/arm/lib/div64.S b/arch/arm/lib/div64.S
new file mode 100644
index 000..f238bc6
--- /dev/null
+++ b/arch/arm/lib/div64.S
@@ -0,0 +1,214 @@
+/*
+ *  linux/arch/arm/lib/div64.S
+ *
+ *  Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ *  Author:Nicolas Pitre
+ *  Created:   Oct 5, 2003
+ *  Copyright: Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#ifdef __UBOOT__
+#define UNWIND(x...)
+#endif
+
+#ifdef __ARMEB__
+#define xh r0
+#define xl r1
+#define yh r2
+#define yl r3
+#else
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+#endif
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ *   This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * xh-xl   = dividend (clobbered)
+ * r4  = divisor (preserved)
+ *
+ * Output values:
+ * yh-yl   = result
+ * xh  = remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+UNWIND(.fnstart)
+
+   @ Test for easy paths first.
+   subsip, r4, #1
+   bls 9f  @ divisor is 0 or 1
+   tst ip, r4
+   beq 8f  @ divisor is power of 2
+
+   @ See if we need to handle upper 32-bit result.
+   cmp xh, r4
+   mov yh, #0
+   blo 3f
+
+   @ Align divisor with upper part of dividend.
+   @ The aligned divisor is stored in yl preserving the original.
+   @ The bit position is stored in ip.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+   clz yl, r4
+   clz ip, xh
+   sub yl, yl, ip
+   mov ip, #1
+   mov ip, ip, lsl yl
+   mov yl, r4, lsl yl
+
+#else
+
+   mov yl, r4
+   mov ip, #1
+1: cmp yl, #0x8000
+   cmpcc   yl, xh
+   movcc   yl, yl, lsl #1
+   movcc   ip, ip, lsl #1
+   bcc 1b
+
+#endif
+
+   @ The division loop for needed upper bit positions.
+   @ Break out early if dividend reaches 0.
+2: cmp xh, yl
+   orrcs   yh, yh, ip
+   subcss  xh, xh, yl
+   movnes  ip, ip, lsr #1
+   mov yl, yl, lsr #1
+   bne 2b
+
+   @ See if we need to handle lower 32-bit result.
+3: cmp xh, #0
+   mov yl, #0
+   cmpeq   xl, r4
+   movlo   xh, xl
+   retlo   lr
+
+   @ The division loop for lower bit positions.
+   @ Here we shift remainer bits leftwards rather than moving the
+   @ divisor for comparisons, considering the carry-out bit as well.
+   mov ip, #0x8000
+4: movsxl, xl, lsl #1
+   adcsxh, xh, xh
+   beq 6f
+   cmpcc   xh, r4
+5: orrcs   yl, yl, ip
+   subcs   xh, xh, r4
+   movsip, ip, lsr #1
+   bne 4b
+   ret lr
+
+   @ The top part of remainder became zero.  If carry is set
+   @ (the 33th bit) this is a false positive so resume the loop.
+   @ Otherwise, if lower part is also null then we are done.
+6: bcs 5b
+   cmp xl, #0
+   reteq   lr
+
+   @ We still have remainer bits in the low part.  Bring them up.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+   clz xh, xl  @ we know xh is zero here so...
+   add xh, xh, #1
+   mov xl, xl, lsl xh
+   mov ip, ip, lsr xh
+
+#else
+
+7: movsxl, xl, lsl #1
+   mov ip, ip, lsr #1
+   bcc 7b
+
+#endif
+
+   @ Current remainder is now 1.  It is worthless to compare with
+   @ 

[U-Boot] [PATCH] arm: mxs: Update MX28EVK config

[Marek Vasut]

Enable FIT image support, EXT4 support and generic FS support.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 configs/mx28evk_defconfig | 1 +
 include/configs/mx28evk.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index d0e413d..bb900ff 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_TARGET_MX28EVK=y
 CONFIG_SPL=y
+CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="ENV_IS_IN_MMC"
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index a52c8c9..4d86c13 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -23,7 +23,10 @@
 #define CONFIG_CMD_CACHE
 #define CONFIG_CMD_DATE
 #define CONFIG_CMD_DHCP
+#define CONFIG_CMD_EXT4
+#define CONFIG_CMD_EXT4_WRITE
 #define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
 #define CONFIG_CMD_MII
 #define CONFIG_CMD_MMC
 #define CONFIG_CMD_PING
-- 
2.7.0

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

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:08 AM, Tom Rini wrote:

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini 
wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut 
wrote:

This patch decouples U-Boot binary from the toolchain on
systems where
private libgcc is available. Instead of pulling in functions
provided
by the libgcc from the toolchain, U-Boot will use it's own set
of libgcc
functions. These functions are usually imported from Linux
kernel, which
also uses it's own libgcc functions instead of the ones
provided by the
toolchain.

This patch solves a rather common problem. The toolchain can
usually
generate code for many variants of target architecture and
often even
different endianness. The libgcc on the other hand is usually
compiled
for one particular configuration and the functions provided by
it may
or may not be suited for use in U-Boot. This can manifest in
two ways,
either the U-Boot fails to compile altogether and linker will
complain
or, in the much worse case, the resulting U-Boot will build,
but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix
for some
cases where a target cannot properly link with the libgcc
provided by
the (specific release of the) GCC toolchain in use. Using
private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this
respect.


This isn't true, exactly.  If using clang for example everyone
needs to
enable this code.  We're also using -fno-builtin -ffreestanding
which
should limit the amount of interference from the toolchain.  And
we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division
since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?


I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.


In that case, we should just import div64.S from Linux on arm32 and be
done with it ? Since we now have all the necessary macros thanks to the
first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?


Sure I'll test it, no problems. Just bake the patch :)

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Marek Vasut]

On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Marek Vasut wrote:
> 
>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
 On Wed, 23 Mar 2016, Tom Rini wrote:

> On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
>> Hello Tom,
>>
>> On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini 
>> wrote:
>>> On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
 Hello Marek,

 On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut 
 wrote:
> This patch decouples U-Boot binary from the toolchain on
> systems where
> private libgcc is available. Instead of pulling in functions
> provided
> by the libgcc from the toolchain, U-Boot will use it's own set
> of libgcc
> functions. These functions are usually imported from Linux
> kernel, which
> also uses it's own libgcc functions instead of the ones
> provided by the
> toolchain.
>
> This patch solves a rather common problem. The toolchain can
> usually
> generate code for many variants of target architecture and
> often even
> different endianness. The libgcc on the other hand is usually
> compiled
> for one particular configuration and the functions provided by
> it may
> or may not be suited for use in U-Boot. This can manifest in
> two ways,
> either the U-Boot fails to compile altogether and linker will
> complain
> or, in the much worse case, the resulting U-Boot will build,
> but will
> misbehave in very subtle and hard to debug ways.

 I don't think using private libgcc by default is a good idea.

 U-Boot's private libgcc is not a feature of U-Boot, but a fix
 for some
 cases where a target cannot properly link with the libgcc
 provided by
 the (specific release of the) GCC toolchain in use. Using
 private libgcc
 to other cases than these does not fix or improve anything; those
 other cases were working and did not require any fix in this
 respect.
>>>
>>> This isn't true, exactly.  If using clang for example everyone
>>> needs to
>>> enable this code.  We're also using -fno-builtin -ffreestanding
>>> which
>>> should limit the amount of interference from the toolchain.  And
>>> we get
>>> that.
>>
>> You mean clang does not produce self-sustained binaries?
>
> clang does not provide "libgcc", so there's no -lgcc providing all of
> the functions that are (today) in:
> _ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
> _umodsi3.S div0.S  _uldivmod.S
> which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

 There is also _udivmoddi4 pulled from libgcc for 64-bit division
 since we
 switched to 64-bit all around ARM. It comes from clock calculations for
 video, e.g. from drivers/video/ipu_common.c for i.MX6.
>>>
>>> Well, this is an example of why we both don't want libgcc ever nor do we
>>> want to overly expand what we do offer.  In this case isn't it an
>>> example of something that should be using lldiv/do_div/etc?
>>
>> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
>> also doesn't implement the function. Which toolchain do you use and
>> which target did you compile?
> 
> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
> Linux
> arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
> function that is used by do_div() from include/asm/div64.h for 32-bit ARM
> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
> (that is totally different from what Linux provides) but no div64.S in
> arch/arm/lib.

In that case, we should just import div64.S from Linux on arm32 and be
done with it ? Since we now have all the necessary macros thanks to the
first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?

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

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:08 AM, Tom Rini wrote:

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect.


This isn't true, exactly.  If using clang for example everyone needs to
enable this code.  We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain.  And we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?


I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.

The target is a custom board based on Freescale/NXP mx6qsabresd (I'm not
ready to submit it to the main tree yet) so sabresd should produce the same
result. Just have IPU enabled.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect.


This isn't true, exactly.  If using clang for example everyone needs to
enable this code.  We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain.  And we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


It is. However do_div does not help for some reason -- here is an excerpt
from drivers/video/ipu_common.c (one of several places where do_div() is
used) that pulls _udivmoddi4 from toolchain anyways:

=== Cut ===
static void ipu_pixel_clk_recalc(struct clk *clk)
{
u32 div;
u64 final_rate = (unsigned long long)clk->parent->rate * 16;

div = __raw_readl(DI_BS_CLKGEN0(clk->id));
debug("read BS_CLKGEN0 div:%d, final_rate:%lld, prate:%ld\n",
  div, final_rate, clk->parent->rate);

clk->rate = 0;
if (div != 0) {
do_div(final_rate, div);
clk->rate = final_rate;
}
}
=== Cut ===

Without the above hack this results in link failure:

=== Cut ===
arm-linux-gnueabi-ld.bfd: error: 
/opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
 uses VFP register arguments, u-boot does not
arm-linux-gnueabi-ld.bfd: failed to merge target specific data of file 
/opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
Makefile:1191: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1
=== Cut ===

U-Boot built with "-mfloat-abi=hard -mfpu=vfpv3-d16" pulls whatever it
requires from toolchain libgcc and works fine, no problems.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Marek Vasut]

On 03/24/2016 12:08 AM, Tom Rini wrote:
> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>> On Wed, 23 Mar 2016, Tom Rini wrote:
>>
>>> On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
 Hello Tom,

 On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:
> On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
>> Hello Marek,
>>
>> On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:
>>> This patch decouples U-Boot binary from the toolchain on systems where
>>> private libgcc is available. Instead of pulling in functions provided
>>> by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
>>> functions. These functions are usually imported from Linux kernel, which
>>> also uses it's own libgcc functions instead of the ones provided by the
>>> toolchain.
>>>
>>> This patch solves a rather common problem. The toolchain can usually
>>> generate code for many variants of target architecture and often even
>>> different endianness. The libgcc on the other hand is usually compiled
>>> for one particular configuration and the functions provided by it may
>>> or may not be suited for use in U-Boot. This can manifest in two ways,
>>> either the U-Boot fails to compile altogether and linker will complain
>>> or, in the much worse case, the resulting U-Boot will build, but will
>>> misbehave in very subtle and hard to debug ways.
>>
>> I don't think using private libgcc by default is a good idea.
>>
>> U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
>> cases where a target cannot properly link with the libgcc provided by
>> the (specific release of the) GCC toolchain in use. Using private libgcc
>> to other cases than these does not fix or improve anything; those
>> other cases were working and did not require any fix in this respect.
>
> This isn't true, exactly.  If using clang for example everyone needs to
> enable this code.  We're also using -fno-builtin -ffreestanding which
> should limit the amount of interference from the toolchain.  And we get
> that.

 You mean clang does not produce self-sustained binaries?
>>>
>>> clang does not provide "libgcc", so there's no -lgcc providing all of
>>> the functions that are (today) in:
>>> _ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
>>> _umodsi3.S div0.S  _uldivmod.S
>>> which aside from __modsi3 and __umodsi3 are all __aeabi_xxx
>>
>> There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
>> switched to 64-bit all around ARM. It comes from clock calculations for
>> video, e.g. from drivers/video/ipu_common.c for i.MX6.
> 
> Well, this is an example of why we both don't want libgcc ever nor do we
> want to overly expand what we do offer.  In this case isn't it an
> example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?

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

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Tom Rini]

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
> On Wed, 23 Mar 2016, Tom Rini wrote:
> 
> >On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
> >>Hello Tom,
> >>
> >>On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:
> >>>On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
> Hello Marek,
> 
> On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:
> >This patch decouples U-Boot binary from the toolchain on systems where
> >private libgcc is available. Instead of pulling in functions provided
> >by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
> >functions. These functions are usually imported from Linux kernel, which
> >also uses it's own libgcc functions instead of the ones provided by the
> >toolchain.
> >
> >This patch solves a rather common problem. The toolchain can usually
> >generate code for many variants of target architecture and often even
> >different endianness. The libgcc on the other hand is usually compiled
> >for one particular configuration and the functions provided by it may
> >or may not be suited for use in U-Boot. This can manifest in two ways,
> >either the U-Boot fails to compile altogether and linker will complain
> >or, in the much worse case, the resulting U-Boot will build, but will
> >misbehave in very subtle and hard to debug ways.
> 
> I don't think using private libgcc by default is a good idea.
> 
> U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
> cases where a target cannot properly link with the libgcc provided by
> the (specific release of the) GCC toolchain in use. Using private libgcc
> to other cases than these does not fix or improve anything; those
> other cases were working and did not require any fix in this respect.
> >>>
> >>>This isn't true, exactly.  If using clang for example everyone needs to
> >>>enable this code.  We're also using -fno-builtin -ffreestanding which
> >>>should limit the amount of interference from the toolchain.  And we get
> >>>that.
> >>
> >>You mean clang does not produce self-sustained binaries?
> >
> >clang does not provide "libgcc", so there's no -lgcc providing all of
> >the functions that are (today) in:
> >_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
> >_umodsi3.S div0.S  _uldivmod.S
> >which aside from __modsi3 and __umodsi3 are all __aeabi_xxx
> 
> There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
> switched to 64-bit all around ARM. It comes from clock calculations for
> video, e.g. from drivers/video/ipu_common.c for i.MX6.

Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect.


This isn't true, exactly.  If using clang for example everyone needs to
enable this code.  We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain.  And we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

The problem is most of i.MX6 toolchains (including my own) are built with
"-mfloat-abi=hard -mfpu=vfpv3-d16" or something similar so it fails to link
with the rest of U-Boot that is unconditionally built with "-msoft-float"
for unknown reason.

We should either add 64-bit functions to private libgcc so it is built and
linked properly with whatever ABI are nailed down in arch/arm/config.mk or
somehow allow to specify specific ABI flags in board configuration or
wherever else.

I do use a hack like this

=== Cut ===
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 9af6c37..a96868c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -16,8 +16,14 @@ endif
 LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
 -fno-common -ffixed-r9
-PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
-  $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
+
+ifeq ($(CONFIG_SYS_HARDFP_VFP_BUILD),y)
+PLATFORM_RELFLAGS += $(call cc-option,-mfloat-abi=hard,$(call 
cc-option,-mfpu=vfpv3-d16,))
+else
+PLATFORM_RELFLAGS += $(call cc-option, -msoft-float)
+endif
+
+PLATFORM_RELFLAGS += $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
=== Cut ===

but this is not very nice so it won't go in the main tree for sure.

A smarter, more elegant way should be invented so the entire U-Boot could be
built with ABI flags matched those used for toolchain build.

Or _ALL_ libgcc functions should be made U-Boot private so no toolchain
parts are used at all.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] fastboot: sparse: fix block addressing for don't care chunk type

[Steve Rae]

On Wed, Mar 9, 2016 at 12:46 PM, Maxime Ripard
 wrote:
> On Tue, Feb 09, 2016 at 11:19:10AM -0800, Steve Rae wrote:
>> When 7bfc3b1 (sparse: Refactor chunk parsing function) was implemented,
>> it dropped 9981945 (aboot: fix block addressing for don't care chunk type).
>>
>> This re-implements the required fix for the "don't care chunk type"...
>>
>> Signed-off-by: Steve Rae 
>
> Acked-by: Maxime Ripard 
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

can this be applied? Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] fastboot: sparse: remove unnecessary logging

[Steve Rae]

On Wed, Mar 9, 2016 at 12:47 PM, Maxime Ripard
 wrote:
> On Tue, Feb 09, 2016 at 11:19:11AM -0800, Steve Rae wrote:
>> remove logging of the 'skipped' blocks
>>
>> Signed-off-by: Steve Rae 
>
> Acked-by: Maxime Ripard 
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

can this be applied? Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-sunxi master

[Hans de Goede]

Hi Tom,

Here is the first sunxi pull-req for v2016.05, it
contains:

-A sync of the sunxi dts files with the kernel
-Addition of support for 10 new boards
-Various fixes

The following changes since commit 0764f24ae6bc937e358990c357f7452b4d5351e3:

  net: Move CONFIG_RTL8169 to Kconfig (2016-03-22 12:19:53 -0400)

are available in the git repository at:

  http://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to e449e840c5adf728ddd308501af3115656aa9a60:

  sunxi: A83T: fix 32bit overflow warning (2016-03-23 22:04:13 +0100)


Alex Kaplan (1):
  sunxi: Enable composite video out on the CHIP

Boris Brezillon (1):
  sunxi: Fix DCDC2 output in CHIP_defconfig

Chen-Yu Tsai (3):
  sunxi: Add defconfig for Cubietruck Plus
  sunxi: Add defconfig for Sinlinx SinA31s
  sunxi: Support SID e-fuses on A83T and H3

Hans de Goede (22):
  sunxi: A23: Fix some revisions needing a different magic sram poke
  include/dt-bindings: Sync some files with the kernel
  sunxi: Sync dts files with the upstream kernel
  sunxi: Fix clock_twi_onoff for sun6i
  sunxi: Fix clock_twi_onoff for sun8i-a83
  sunxi: Fix clock_twi_onoff for sun9i
  sunxi: Add defconfig and dts for colorfly e708 q1 tablet
  sunxi: Add defconfig and dts for Difrence DIT4350 tablet
  sunxi: Add defconfig and dts for the Polaroid MID2809PXE4 tablet
  sunxi: Add defconfig and dts for Dserve DSRV9703C tablet
  sunxi: Add defconfig and dts for Orange Pi 2 SBC
  sunxi: Enable realtek phy support
  sunxi: Add support for USB vbus pin for USB3
  sunxi: Specify USB vbus pins for orangepi boards
  sunxi: Add a bunch of missing compatible strings to sunxi_gpio.c
  spl: Print from which mmc slot spl is trying to boot
  sunxi: Enable support for the eMMC found on the orangepi plus
  sunxi: Fix 2nd usb controller on sun4i/sun7i no longer working
  sunxi: Fix gmac not working due to cpu_eth_init no longer being called
  sunxi: Turn satapwr on from board_init
  sunxi: Specify SATAPWR pin for Orangepi Plus
  sunxi: Select CONFIG_OF_BOARD_SETUP from arch/arm/Kconfig

Lawrence Yu (1):
  sunxi: Configure only LVDS pins instead of all LCD pins when LVDS 
interface selected

Marcus Cooper (1):
  sun7i: Add defconfig for the Itead Ibox

Peter Korsgaard (1):
  sunxi: Add defconfig for yones toptech bs1078-v2 tablet

Stefan Roese (1):
  sunxi: Add defconfig for icnova-a20-swac

vishnupatekar (2):
  sunxi: sinovoip-bpi-m3: drop LDO settings from defconfig
  sunxi: A83T: fix 32bit overflow warning

 arch/arm/Kconfig   |   1 +
 arch/arm/cpu/armv7/sunxi/board.c   |  50 +-
 arch/arm/cpu/armv7/sunxi/clock.c   |  35 +
 arch/arm/cpu/armv7/sunxi/clock_sun6i.c |  26 -
 arch/arm/cpu/armv7/sunxi/clock_sun9i.c |   4 +-
 arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c |   2 +-
 arch/arm/cpu/armv7/sunxi/usb_phy.c |   1 +
 arch/arm/dts/Makefile  |  13 +-
 arch/arm/dts/axp22x.dtsi   | 145 
 arch/arm/dts/sun4i-a10-a1000.dts   |   4 +
 arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts |  22 +
 arch/arm/dts/sun4i-a10-cubieboard.dts  |   4 +
 arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts| 281 +++
 arch/arm/dts/sun4i-a10-gemei-g9.dts|  63 +-
 arch/arm/dts/sun4i-a10-inet1.dts   |  48 ++
 arch/arm/dts/sun4i-a10-inet97fv2.dts   | 127 +++-
 arch/arm/dts/sun4i-a10-inet9f-rev03.dts| 181 +
 arch/arm/dts/sun4i-a10-itead-iteaduino-plus.dts|  86 +--
 arch/arm/dts/sun4i-a10-jesurun-q5.dts  |  15 +
 arch/arm/dts/sun4i-a10-marsboard.dts   |  23 +
 arch/arm/dts/sun4i-a10-mk802.dts   |  37 +
 arch/arm/dts/sun4i-a10-olinuxino-lime.dts  |  12 +
 arch/arm/dts/sun4i-a10-pcduino.dts |  58 +-
 arch/arm/dts/sun4i-a10-pcduino2.dts|  78 ++
 arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts|  69 ++
 arch/arm/dts/sun4i-a10.dtsi| 153 +++-
 arch/arm/dts/sun5i-a10s-auxtek-t004.dts|  14 +
 arch/arm/dts/sun5i-a10s-olinuxino-micro.dts|   2 +-
 arch/arm/dts/sun5i-a13-difrnce-dit4350.dts | 226 ++
 arch/arm/dts/sun5i-a13-empire-electronix-d709.dts  |  19 +-
 arch/arm/dts/sun5i-a13-inet-98v-rev2.dts   |  26 +-
 arch/arm/dts/sun5i-a13-utoo-p66.dts|  30 +
 arch/arm/dts/sun5i-q8-common.dtsi  |  10 +
 arch/arm/dts/sun5i-r8-chip.dts |  47 +-
 arch/arm/dts/sun5i.dtsi|  31 +
 arch/arm/dts/sun6i-a31-colombus.dts|  24 +
 arch/arm/dts/sun6i-a31-hummingbird.dts | 132 ++--
 arch/arm/dts/sun6i-a31.dtsi|  65 +-
 

Re: [U-Boot] pull request: u-boot-uniphier/master

[Tom Rini]

On Thu, Mar 24, 2016 at 01:56:11AM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> 
> Here is a series of UniPhier SoCs updates for v2016.5-rc1.
> It includes ARM64 compiler warning fixes, cleanups, new SoC/board DTS,
> and misc changes.
> 
> 
> 
> The following changes since commit 0764f24ae6bc937e358990c357f7452b4d5351e3:
> 
>   net: Move CONFIG_RTL8169 to Kconfig (2016-03-22 12:19:53 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-uniphier.git master
> 
> for you to fetch changes up to d085ecd61b9956cda0d37b89b5c538f54440fe58:
> 
>   ARM: uniphier: switch to raw U-Boot image (2016-03-24 01:45:41 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Tom Rini]

On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
> Hello Tom,
> 
> On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:
> > On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
> > > Hello Marek,
> > > 
> > > On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:
> > > > This patch decouples U-Boot binary from the toolchain on systems where
> > > > private libgcc is available. Instead of pulling in functions provided
> > > > by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
> > > > functions. These functions are usually imported from Linux kernel, which
> > > > also uses it's own libgcc functions instead of the ones provided by the
> > > > toolchain.
> > > > 
> > > > This patch solves a rather common problem. The toolchain can usually
> > > > generate code for many variants of target architecture and often even
> > > > different endianness. The libgcc on the other hand is usually compiled
> > > > for one particular configuration and the functions provided by it may
> > > > or may not be suited for use in U-Boot. This can manifest in two ways,
> > > > either the U-Boot fails to compile altogether and linker will complain
> > > > or, in the much worse case, the resulting U-Boot will build, but will
> > > > misbehave in very subtle and hard to debug ways.
> > > 
> > > I don't think using private libgcc by default is a good idea.
> > > 
> > > U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
> > > cases where a target cannot properly link with the libgcc provided by
> > > the (specific release of the) GCC toolchain in use. Using private libgcc
> > > to other cases than these does not fix or improve anything; those
> > > other cases were working and did not require any fix in this respect. 
> > 
> > This isn't true, exactly.  If using clang for example everyone needs to
> > enable this code.  We're also using -fno-builtin -ffreestanding which
> > should limit the amount of interference from the toolchain.  And we get
> > that.
> 
> You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

> > > Also, libgcc is not a standalone project that can be frozen, forked or
> > > improved freely; it is an internal component of the GCC toolchain. No
> > > standard defines what libgcc is or should be, and we have no control
> > > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > > project may decide to change that contract at any time, and produce a
> > > new toolchain and a new libgcc. Using our private libgcc by default
> > > will cause all targets to break for no good reason. We've already been
> > > bitten by internal GCC changes on which we were dependent; adding more
> > > such dependency is not the way to go IMO.
> > > 
> > > If we truly fear that GCC is *generally* unable to properly build our
> > > targets due to its libgcc, then we should not only "snapshot and fix"
> > > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > > sure we keep a consistent copy of it. I don't think that would be a
> > > viable move.
> > > 
> > > And if we don't believe that GCC is generally unable to properly build
> > > U-Boot, then we should always use it as provided unless it is provably
> > > buggy, in which case if a private libgcc is a fix, then by all means we
> > > should use it.
> > > 
> > > And whenever we find that a GCC toolchain is provably buggy, we should
> > > raise a bug, either to the toolchain provider if the issue is only with
> > > a given binary release (e.g. mismatched or badly supported endianness),
> > > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > > of non-supported opcodes for a given arch/cpu).
> > 
> > Ah, but this shows part of the problem.  We don't need "libgcc" as in
> > "the thing which provides gcc'isms".  We need "libgcc" as in "the thing
> > which provides AEABI functions".
> 
> Not sure I'm getting what you mean. For one thing, I don't see that
> AEABI specifies any functions. Also, I don't see where it is established
> that U-Boot "needs AEABI functions". Finally, I don't see that libgcc
> is a standalone project aiming at providing AEABI functions.

Well, lets unpack things in the order that it matters.  If we kludge the
toplevel Makefile to not set CONFIG_USE_PRIVATE_LIBGCC nor link in
libgcc on ARM, and build work_92105 with an arm-none-eabi GCC we start
failing on:
arch/arm/cpu/arm926ejs/built-in.o: In function `print_cpuinfo':
/home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:64:
undefined reference to `__aeabi_uidiv'
/home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:65:
undefined reference to `__aeabi_uidiv'

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Albert ARIBAUD]

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:
> On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
> > Hello Marek,
> > 
> > On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:
> > > This patch decouples U-Boot binary from the toolchain on systems where
> > > private libgcc is available. Instead of pulling in functions provided
> > > by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
> > > functions. These functions are usually imported from Linux kernel, which
> > > also uses it's own libgcc functions instead of the ones provided by the
> > > toolchain.
> > > 
> > > This patch solves a rather common problem. The toolchain can usually
> > > generate code for many variants of target architecture and often even
> > > different endianness. The libgcc on the other hand is usually compiled
> > > for one particular configuration and the functions provided by it may
> > > or may not be suited for use in U-Boot. This can manifest in two ways,
> > > either the U-Boot fails to compile altogether and linker will complain
> > > or, in the much worse case, the resulting U-Boot will build, but will
> > > misbehave in very subtle and hard to debug ways.
> > 
> > I don't think using private libgcc by default is a good idea.
> > 
> > U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
> > cases where a target cannot properly link with the libgcc provided by
> > the (specific release of the) GCC toolchain in use. Using private libgcc
> > to other cases than these does not fix or improve anything; those
> > other cases were working and did not require any fix in this respect. 
> 
> This isn't true, exactly.  If using clang for example everyone needs to
> enable this code.  We're also using -fno-builtin -ffreestanding which
> should limit the amount of interference from the toolchain.  And we get
> that.

You mean clang does not produce self-sustained binaries?

> > Also, libgcc is not a standalone project that can be frozen, forked or
> > improved freely; it is an internal component of the GCC toolchain. No
> > standard defines what libgcc is or should be, and we have no control
> > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > project may decide to change that contract at any time, and produce a
> > new toolchain and a new libgcc. Using our private libgcc by default
> > will cause all targets to break for no good reason. We've already been
> > bitten by internal GCC changes on which we were dependent; adding more
> > such dependency is not the way to go IMO.
> > 
> > If we truly fear that GCC is *generally* unable to properly build our
> > targets due to its libgcc, then we should not only "snapshot and fix"
> > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > sure we keep a consistent copy of it. I don't think that would be a
> > viable move.
> > 
> > And if we don't believe that GCC is generally unable to properly build
> > U-Boot, then we should always use it as provided unless it is provably
> > buggy, in which case if a private libgcc is a fix, then by all means we
> > should use it.
> > 
> > And whenever we find that a GCC toolchain is provably buggy, we should
> > raise a bug, either to the toolchain provider if the issue is only with
> > a given binary release (e.g. mismatched or badly supported endianness),
> > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > of non-supported opcodes for a given arch/cpu).
> 
> Ah, but this shows part of the problem.  We don't need "libgcc" as in
> "the thing which provides gcc'isms".  We need "libgcc" as in "the thing
> which provides AEABI functions".

Not sure I'm getting what you mean. For one thing, I don't see that
AEABI specifies any functions. Also, I don't see where it is established
that U-Boot "needs AEABI functions". Finally, I don't see that libgcc
is a standalone project aiming at providing AEABI functions.

> Today we get these from libgcc but we
> run into cases where this doesn't work quite right (toolchain fun) or
> simply aren't available (again, clang).  So I am in favour of re-syncing
> with this part of the kernel and mirroring the decision to always
> include these functions, again, like the kernel does.

If we are using libgcc for providing AEABI services then we are using it
wrong. Its role is to support GCC-generated code.

Could you give me an example of this "need for [an] AEABI function"?

> -- 
> Tom

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH v1 0/1] Use LS2080A as the only SoC name

[York Sun]

Not long ago, a change was made in U-Boot to switch the primary SoC from
LS2085A to LS2080A. SoC name and board names were changed. It turns out
the same board support both SoCs with a socket. It is possible to swtich
SoC. In this case, using one unified image is more appropriate. If future
SoC can be hosted on the same boards, they should be added.

At this moment, the board name remains LS2080ARDB and LS2080AQDS. They
don't match the labels on the boards. Should this become a concern, we
can rename the boards.

Tested on LS2085ARDB with both personalities.


York Sun (1):
  armv8: LS2080A: Consolidate LS2080A and LS2085A

 arch/arm/cpu/armv8/fsl-layerscape/Makefile |4 ---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|9 ---
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |6 -
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |2 +-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   14 +-
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|4 +--
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |9 ++-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |2 +-
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |2 +-
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |2 ++
 board/freescale/ls2080a/ddr.c  |   27 +++-
 board/freescale/ls2080a/ls2080a.c  |2 +-
 board/freescale/ls2080aqds/MAINTAINERS |2 --
 board/freescale/ls2080aqds/ddr.c   |   27 +++-
 board/freescale/ls2080aqds/ls2080aqds.c|2 +-
 board/freescale/ls2080ardb/MAINTAINERS |2 --
 board/freescale/ls2080ardb/ddr.c   |   27 +++-
 board/freescale/ls2080ardb/ls2080ardb.c|2 +-
 configs/ls2085aqds_defconfig   |   19 --
 configs/ls2085aqds_nand_defconfig  |   14 --
 configs/ls2085ardb_defconfig   |   19 --
 configs/ls2085ardb_nand_defconfig  |   14 --
 drivers/net/ldpaa_eth/Makefile |1 -
 include/configs/ls2080a_common.h   |7 +
 include/configs/ls2080a_emu.h  |7 -
 include/configs/ls2080a_simu.h |7 -
 include/linux/usb/xhci-fsl.h   |2 +-
 27 files changed, 83 insertions(+), 152 deletions(-)
 delete mode 100644 configs/ls2085aqds_defconfig
 delete mode 100644 configs/ls2085aqds_nand_defconfig
 delete mode 100644 configs/ls2085ardb_defconfig
 delete mode 100644 configs/ls2085ardb_nand_defconfig

-- 
1.7.9.5

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

[U-Boot] [RFC PATCH v1] armv8: LS2080A: Consolidate LS2080A and LS2085A

[York Sun]

LS2080A is the primary SoC, and LS2085A is a personality with AIOP
and DPAA DDR. The RDB and QDS boards support both personality. By
detecting the SVR at runtime, a single image per board can support
both SoCs. It gives users flexibility to swtich SoC without the need
to reprogram the board.

Signed-off-by: York Sun 
CC: Prabhakar Kushwaha 

---

 arch/arm/cpu/armv8/fsl-layerscape/Makefile |4 ---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|9 ---
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |6 -
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |2 +-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   14 +-
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|4 +--
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |9 ++-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |2 +-
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |2 +-
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |2 ++
 board/freescale/ls2080a/ddr.c  |   27 +++-
 board/freescale/ls2080a/ls2080a.c  |2 +-
 board/freescale/ls2080aqds/MAINTAINERS |2 --
 board/freescale/ls2080aqds/ddr.c   |   27 +++-
 board/freescale/ls2080aqds/ls2080aqds.c|2 +-
 board/freescale/ls2080ardb/MAINTAINERS |2 --
 board/freescale/ls2080ardb/ddr.c   |   27 +++-
 board/freescale/ls2080ardb/ls2080ardb.c|2 +-
 configs/ls2085aqds_defconfig   |   19 --
 configs/ls2085aqds_nand_defconfig  |   14 --
 configs/ls2085ardb_defconfig   |   19 --
 configs/ls2085ardb_nand_defconfig  |   14 --
 drivers/net/ldpaa_eth/Makefile |1 -
 include/configs/ls2080a_common.h   |7 +
 include/configs/ls2080a_emu.h  |7 -
 include/configs/ls2080a_simu.h |7 -
 include/linux/usb/xhci-fsl.h   |2 +-
 27 files changed, 83 insertions(+), 152 deletions(-)
 delete mode 100644 configs/ls2085aqds_defconfig
 delete mode 100644 configs/ls2085aqds_nand_defconfig
 delete mode 100644 configs/ls2085ardb_defconfig
 delete mode 100644 configs/ls2085ardb_nand_defconfig

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index cce7405..5f86ef9 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -25,10 +25,6 @@ ifneq ($(CONFIG_LS2080A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o
 endif
 
-ifneq ($(CONFIG_LS2085A),)
-obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o
-endif
-
 ifneq ($(CONFIG_LS1043A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls1043a_serdes.o
 endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 4b9e209..d939900 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -538,12 +538,12 @@ int print_cpuinfo(void)
struct sys_info sysinfo;
char buf[32];
unsigned int i, core;
-   u32 type, rcw;
+   u32 type, rcw, svr = gur_in32(>svr);
 
puts("SoC: ");
 
cpu_name(buf);
-   printf(" %s (0x%x)\n", buf, gur_in32(>svr));
+   printf(" %s (0x%x)\n", buf, svr);
memset((u8 *)buf, 0x00, ARRAY_SIZE(buf));
get_sys_info();
puts("Clock Configuration:");
@@ -564,7 +564,10 @@ int print_cpuinfo(void)
printf("  FMAN: %-4s MHz", strmhz(buf, sysinfo.freq_fman[0]));
 #endif
 #ifdef CONFIG_SYS_FSL_HAS_DP_DDR
-   printf(" DP-DDR:   %-4s MT/s", strmhz(buf, sysinfo.freq_ddrbus2));
+   if (soc_has_dp_ddr()) {
+   printf(" DP-DDR:   %-4s MT/s",
+  strmhz(buf, sysinfo.freq_ddrbus2));
+   }
 #endif
puts("\n");
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
index 81cf470..d580a43 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
@@ -97,9 +97,13 @@ void get_sys_info(struct sys_info *sys_info)
FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_SHIFT) &
FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_MASK;
 #ifdef CONFIG_SYS_FSL_HAS_DP_DDR
-   sys_info->freq_ddrbus2 *= (gur_in32(>rcwsr[0]) >>
+   if (soc_has_dp_ddr()) {
+   sys_info->freq_ddrbus2 *= (gur_in32(>rcwsr[0]) >>
FSL_CHASSIS3_RCWSR0_MEM2_PLL_RAT_SHIFT) &
FSL_CHASSIS3_RCWSR0_MEM2_PLL_RAT_MASK;
+   } else {
+   sys_info->freq_ddrbus2 = 0;
+   }
 #endif
 
for (i = 0; i < CONFIG_SYS_FSL_NUM_CC_PLLS; i++) {
diff --git 

Re: [U-Boot] sunxi: A83T: fix 32bit overflow warning

[Hans de Goede]

Hi,

On 23-03-16 18:54, vishnupatekar wrote:

In mctl_channel_init, (0x50<<26) which overflows 32bit.
It was supposed to be 0x50<<16,corrected now.

Reported-by: Hans de Goede 
Signed-off-by: Vishnu Patekar 


Thanks, applied.

Regards,

Hans



---
  arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c 
b/arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c
index 7c46acd..55df1b9 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c
@@ -280,7 +280,7 @@ static int mctl_channel_init(struct dram_para *para)

writel(0x94be6fa3, MCTL_PROTECT);
udelay(100);
-   clrsetbits_le32(MX_UPD2, 0xfff << 16, 0x50 << 26);
+   clrsetbits_le32(MX_UPD2, 0xfff << 16, 0x50 << 16);
writel(0x0, MCTL_PROTECT);
udelay(100);



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

Re: [U-Boot] [PATCH v1] Revert "fastboot: OUT transaction length must be aligned to wMaxPacketSize"

[Steve Rae]

On Wed, Mar 23, 2016 at 12:40 PM, Sam Protsenko
 wrote:
> On Wed, Mar 23, 2016 at 7:40 PM, Steve Rae  wrote:
>> Lukasz & Sam:
>>
>> On Wed, Mar 23, 2016 at 8:54 AM, Sam Protsenko
>>  wrote:
>>>
>>> On Wed, Mar 23, 2016 at 11:49 AM, Lukasz Majewski
>>>  wrote:
>>> > Hi Marek,
>>> >
>>> >> On 03/23/2016 01:50 AM, Steve Rae wrote:
>>> >> > This reverts commit 9e4b510d40310bf46e09f4edd0a0b6356213df47.
>>> >> >
>>> >> > Signed-off-by: Steve Rae 
>>> >> > ---
>>> >> > As discussed on the mailing list, this change breaks the download
>>> >> > portion of fastboot by causing the server (the device running
>>> >> > U-Boot) to wait forever for bytes which are never sent by the
>>> >> > client (the host connected via USB).
>>> >>
>>> >> It'd be real cool if you could reference the ML discussion next time.
>>> >>
>>> >> > Does anyone know how to contact:
>>> >> >   Dileep Katta 
>>> >> > (this email bounces) ?
>>> >>
>>> >> No clue, sorry.
>>> >
>>> > Probably he is no longer employed by Linaro.
>>> >
>>> >>
>>> >> Applied for now as it fixes real bug.
>>> >
>>> > I've a gut feeling that there are different versions of "fastboot"
>>> > protocol.
>>> >
>>
>> Yes - I suspect that also, which is why I test with two (2) fastboot clients:
>> (1) from 2013 (and I don't know its origin), and
>> (2) from the Adroid SDK (r24.4.1) for Linux - from
>> developer.android.com; which requires
>> the "Android SDK Platform-tools (rev 23.1)" to be installed...
>> [ this is the current version - checked yesterday! ]
>>
>>> > What Steve is describing is that HOST is waiting for ZLP ACK.
>>
>> Lukasz:
>> Is there any debugging I can enable to verify this?
>>
>>> >
>>> > Anyway, I'm not able to test fastboot gadget since our (I mean
>>> > Samsung's) boards aren't supporting fastboot - we use UMS, DFU, LTHOR.
>>> >
>>> > Hence, I can only rely on somebody's testing and review the code without
>>> > the ability to know about implementation "quirks".
>>> >
>>> >>
>>> >> >  drivers/usb/gadget/f_fastboot.c | 27 +--
>>> >> >  1 file changed, 5 insertions(+), 22 deletions(-)
>>> >> >
>>> >> > diff --git a/drivers/usb/gadget/f_fastboot.c
>>> >> > b/drivers/usb/gadget/f_fastboot.c index a54b4ee..887cf4f 100644
>>> >> > --- a/drivers/usb/gadget/f_fastboot.c
>>> >> > +++ b/drivers/usb/gadget/f_fastboot.c
>>> >> > @@ -57,7 +57,6 @@ static struct f_fastboot *fastboot_func;
>>> >> >  static unsigned int fastboot_flash_session_id;
>>> >> >  static unsigned int download_size;
>>> >> >  static unsigned int download_bytes;
>>> >> > -static bool is_high_speed;
>>> >> >
>>> >> >  static struct usb_endpoint_descriptor fs_ep_in = {
>>> >> > .bLength= USB_DT_ENDPOINT_SIZE,
>>> >> > @@ -241,13 +240,10 @@ static int fastboot_set_alt(struct
>>> >> > usb_function *f, __func__, f->name, interface, alt);
>>> >> >
>>> >> > /* make sure we don't enable the ep twice */
>>> >> > -   if (gadget->speed == USB_SPEED_HIGH) {
>>> >> > +   if (gadget->speed == USB_SPEED_HIGH)
>>> >> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
>>> >> > -   is_high_speed = true;
>>> >> > -   } else {
>>> >> > +   else
>>> >> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
>>> >> > -   is_high_speed = false;
>>> >> > -   }
>>> >> > if (ret) {
>>> >> > puts("failed to enable out ep\n");
>>> >> > return ret;
>>> >> > @@ -419,20 +415,13 @@ static void cb_getvar(struct usb_ep *ep,
>>> >> > struct usb_request *req) fastboot_tx_write_str(response);
>>> >> >  }
>>> >> >
>>> >> > -static unsigned int rx_bytes_expected(unsigned int maxpacket)
>>> >> > +static unsigned int rx_bytes_expected(void)
>>> >> >  {
>>> >> > int rx_remain = download_size - download_bytes;
>>> >> > -   int rem = 0;
>>> >> > if (rx_remain < 0)
>>> >> > return 0;
>>> >> > if (rx_remain > EP_BUFFER_SIZE)
>>> >> > return EP_BUFFER_SIZE;
>>> >> > -   if (rx_remain < maxpacket) {
>>> >> > -   rx_remain = maxpacket;
>>> >> > -   } else if (rx_remain % maxpacket != 0) {
>>> >> > -   rem = rx_remain % maxpacket;
>>> >> > -   rx_remain = rx_remain + (maxpacket - rem);
>>> >> > -   }
>>> >> > return rx_remain;
>>> >> >  }
>>> >> >
>>> >> > @@ -444,7 +433,6 @@ static void rx_handler_dl_image(struct usb_ep
>>> >> > *ep, struct usb_request *req) const unsigned char *buffer =
>>> >> > req->buf; unsigned int buffer_size = req->actual;
>>> >> > unsigned int pre_dot_num, now_dot_num;
>>> >> > -   unsigned int max;
>>> >> >
>>> >> > if (req->status != 0) {
>>> >> > printf("Bad status: %d\n", req->status);
>>> >> > @@ -482,9 +470,7 @@ static void rx_handler_dl_image(struct usb_ep
>>> >> > *ep, struct usb_request *req)
>>> >> > printf("\ndownloading of %d bytes finished\n",
>>> >> > download_bytes); } 

Re: [U-Boot] [PATCH v1] Revert "fastboot: OUT transaction length must be aligned to wMaxPacketSize"

[Sam Protsenko]

On Wed, Mar 23, 2016 at 7:40 PM, Steve Rae  wrote:
> Lukasz & Sam:
>
> On Wed, Mar 23, 2016 at 8:54 AM, Sam Protsenko
>  wrote:
>>
>> On Wed, Mar 23, 2016 at 11:49 AM, Lukasz Majewski
>>  wrote:
>> > Hi Marek,
>> >
>> >> On 03/23/2016 01:50 AM, Steve Rae wrote:
>> >> > This reverts commit 9e4b510d40310bf46e09f4edd0a0b6356213df47.
>> >> >
>> >> > Signed-off-by: Steve Rae 
>> >> > ---
>> >> > As discussed on the mailing list, this change breaks the download
>> >> > portion of fastboot by causing the server (the device running
>> >> > U-Boot) to wait forever for bytes which are never sent by the
>> >> > client (the host connected via USB).
>> >>
>> >> It'd be real cool if you could reference the ML discussion next time.
>> >>
>> >> > Does anyone know how to contact:
>> >> >   Dileep Katta 
>> >> > (this email bounces) ?
>> >>
>> >> No clue, sorry.
>> >
>> > Probably he is no longer employed by Linaro.
>> >
>> >>
>> >> Applied for now as it fixes real bug.
>> >
>> > I've a gut feeling that there are different versions of "fastboot"
>> > protocol.
>> >
>
> Yes - I suspect that also, which is why I test with two (2) fastboot clients:
> (1) from 2013 (and I don't know its origin), and
> (2) from the Adroid SDK (r24.4.1) for Linux - from
> developer.android.com; which requires
> the "Android SDK Platform-tools (rev 23.1)" to be installed...
> [ this is the current version - checked yesterday! ]
>
>> > What Steve is describing is that HOST is waiting for ZLP ACK.
>
> Lukasz:
> Is there any debugging I can enable to verify this?
>
>> >
>> > Anyway, I'm not able to test fastboot gadget since our (I mean
>> > Samsung's) boards aren't supporting fastboot - we use UMS, DFU, LTHOR.
>> >
>> > Hence, I can only rely on somebody's testing and review the code without
>> > the ability to know about implementation "quirks".
>> >
>> >>
>> >> >  drivers/usb/gadget/f_fastboot.c | 27 +--
>> >> >  1 file changed, 5 insertions(+), 22 deletions(-)
>> >> >
>> >> > diff --git a/drivers/usb/gadget/f_fastboot.c
>> >> > b/drivers/usb/gadget/f_fastboot.c index a54b4ee..887cf4f 100644
>> >> > --- a/drivers/usb/gadget/f_fastboot.c
>> >> > +++ b/drivers/usb/gadget/f_fastboot.c
>> >> > @@ -57,7 +57,6 @@ static struct f_fastboot *fastboot_func;
>> >> >  static unsigned int fastboot_flash_session_id;
>> >> >  static unsigned int download_size;
>> >> >  static unsigned int download_bytes;
>> >> > -static bool is_high_speed;
>> >> >
>> >> >  static struct usb_endpoint_descriptor fs_ep_in = {
>> >> > .bLength= USB_DT_ENDPOINT_SIZE,
>> >> > @@ -241,13 +240,10 @@ static int fastboot_set_alt(struct
>> >> > usb_function *f, __func__, f->name, interface, alt);
>> >> >
>> >> > /* make sure we don't enable the ep twice */
>> >> > -   if (gadget->speed == USB_SPEED_HIGH) {
>> >> > +   if (gadget->speed == USB_SPEED_HIGH)
>> >> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
>> >> > -   is_high_speed = true;
>> >> > -   } else {
>> >> > +   else
>> >> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
>> >> > -   is_high_speed = false;
>> >> > -   }
>> >> > if (ret) {
>> >> > puts("failed to enable out ep\n");
>> >> > return ret;
>> >> > @@ -419,20 +415,13 @@ static void cb_getvar(struct usb_ep *ep,
>> >> > struct usb_request *req) fastboot_tx_write_str(response);
>> >> >  }
>> >> >
>> >> > -static unsigned int rx_bytes_expected(unsigned int maxpacket)
>> >> > +static unsigned int rx_bytes_expected(void)
>> >> >  {
>> >> > int rx_remain = download_size - download_bytes;
>> >> > -   int rem = 0;
>> >> > if (rx_remain < 0)
>> >> > return 0;
>> >> > if (rx_remain > EP_BUFFER_SIZE)
>> >> > return EP_BUFFER_SIZE;
>> >> > -   if (rx_remain < maxpacket) {
>> >> > -   rx_remain = maxpacket;
>> >> > -   } else if (rx_remain % maxpacket != 0) {
>> >> > -   rem = rx_remain % maxpacket;
>> >> > -   rx_remain = rx_remain + (maxpacket - rem);
>> >> > -   }
>> >> > return rx_remain;
>> >> >  }
>> >> >
>> >> > @@ -444,7 +433,6 @@ static void rx_handler_dl_image(struct usb_ep
>> >> > *ep, struct usb_request *req) const unsigned char *buffer =
>> >> > req->buf; unsigned int buffer_size = req->actual;
>> >> > unsigned int pre_dot_num, now_dot_num;
>> >> > -   unsigned int max;
>> >> >
>> >> > if (req->status != 0) {
>> >> > printf("Bad status: %d\n", req->status);
>> >> > @@ -482,9 +470,7 @@ static void rx_handler_dl_image(struct usb_ep
>> >> > *ep, struct usb_request *req)
>> >> > printf("\ndownloading of %d bytes finished\n",
>> >> > download_bytes); } else {
>> >> > -   max = is_high_speed ? hs_ep_out.wMaxPacketSize :
>> >> > -   fs_ep_out.wMaxPacketSize;
>> >> > -   req->length = rx_bytes_expected(max);
>> >> > + 

[U-Boot] [PATCH 2/3] Revert "ARM: DRA7: EMIF: Add 4GB DDR settings"

[Semen Protsenko]

From: Sam Protsenko 

This reverts commit c4a2736ca165167aa38228a60354c6a8950d42f8.
---
 board/ti/dra7xx/evm.c | 83 ++-
 1 file changed, 3 insertions(+), 80 deletions(-)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 4e45abf..eb19a6d 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -34,8 +34,6 @@
 #define board_is_dra74x_evm()  board_ti_is("5777xCPU")
 #define board_is_dra74x_revh_or_later() board_is_dra74x_evm() &&   \
(strncmp("H", board_ti_get_rev(), 1) <= 0)
-#define board_ti_get_emif_size()   board_ti_get_emif1_size() + \
-   board_ti_get_emif2_size()
 
 #ifdef CONFIG_DRIVER_TI_CPSW
 #include 
@@ -127,78 +125,18 @@ static const struct emif_regs 
emif_1_regs_ddr3_666_mhz_1cs_dra_es1 = {
.emif_rd_wr_exec_thresh = 0x0305
 };
 
-const struct emif_regs emif1_ddr3_532_mhz_1cs_2G = {
-   .sdram_config_init  = 0x61851ab2,
-   .sdram_config   = 0x61851ab2,
-   .sdram_config2  = 0x0800,
-   .ref_ctrl   = 0x40F1,
-   .ref_ctrl_final = 0x1035,
-   .sdram_tim1 = 0xCCCF36B3,
-   .sdram_tim2 = 0x30BF7FDA,
-   .sdram_tim3 = 0x427F8BA8,
-   .read_idle_ctrl = 0x0005,
-   .zq_config  = 0x0007190B,
-   .temp_alert_config  = 0x,
-   .emif_ddr_phy_ctlr_1_init   = 0x0024400B,
-   .emif_ddr_phy_ctlr_1= 0x0E24400B,
-   .emif_ddr_ext_phy_ctrl_1= 0x10040100,
-   .emif_ddr_ext_phy_ctrl_2= 0x00910091,
-   .emif_ddr_ext_phy_ctrl_3= 0x00950095,
-   .emif_ddr_ext_phy_ctrl_4= 0x009B009B,
-   .emif_ddr_ext_phy_ctrl_5= 0x009E009E,
-   .emif_rd_wr_lvl_rmp_win = 0x,
-   .emif_rd_wr_lvl_rmp_ctl = 0x8000,
-   .emif_rd_wr_lvl_ctl = 0x,
-   .emif_rd_wr_exec_thresh = 0x0305
-};
-
-const struct emif_regs emif2_ddr3_532_mhz_1cs_2G = {
-   .sdram_config_init  = 0x61851B32,
-   .sdram_config   = 0x61851B32,
-   .sdram_config2  = 0x0800,
-   .ref_ctrl   = 0x40F1,
-   .ref_ctrl_final = 0x1035,
-   .sdram_tim1 = 0xCCCF36B3,
-   .sdram_tim2 = 0x308F7FDA,
-   .sdram_tim3 = 0x427F88A8,
-   .read_idle_ctrl = 0x0005,
-   .zq_config  = 0x0007190B,
-   .temp_alert_config  = 0x,
-   .emif_ddr_phy_ctlr_1_init   = 0x0024400B,
-   .emif_ddr_phy_ctlr_1= 0x0E24400B,
-   .emif_ddr_ext_phy_ctrl_1= 0x10040100,
-   .emif_ddr_ext_phy_ctrl_2= 0x00910091,
-   .emif_ddr_ext_phy_ctrl_3= 0x00950095,
-   .emif_ddr_ext_phy_ctrl_4= 0x009B009B,
-   .emif_ddr_ext_phy_ctrl_5= 0x009E009E,
-   .emif_rd_wr_lvl_rmp_win = 0x,
-   .emif_rd_wr_lvl_rmp_ctl = 0x8000,
-   .emif_rd_wr_lvl_ctl = 0x,
-   .emif_rd_wr_exec_thresh = 0x0305
-};
-
 void emif_get_reg_dump(u32 emif_nr, const struct emif_regs **regs)
 {
-   u64 ram_size;
-
-   ram_size = board_ti_get_emif_size();
-
switch (omap_revision()) {
case DRA752_ES1_0:
case DRA752_ES1_1:
case DRA752_ES2_0:
switch (emif_nr) {
case 1:
-   if (ram_size > CONFIG_MAX_MEM_MAPPED)
-   *regs = _ddr3_532_mhz_1cs_2G;
-   else
-   *regs = _ddr3_532_mhz_1cs;
+   *regs = _ddr3_532_mhz_1cs;
break;
case 2:
-   if (ram_size > CONFIG_MAX_MEM_MAPPED)
-   *regs = _ddr3_532_mhz_1cs_2G;
-   else
-   *regs = _ddr3_532_mhz_1cs;
+   *regs = _ddr3_532_mhz_1cs;
break;
}
break;
@@ -226,28 +164,13 @@ static const struct dmm_lisa_map_regs lisa_map_2G_x_2 = {
.is_ma_present  = 0x1
 };
 
-const struct dmm_lisa_map_regs lisa_map_dra7_2GB = {
-   .dmm_lisa_map_0 = 0x0,
-   .dmm_lisa_map_1 = 0x0,
-   .dmm_lisa_map_2 = 0x80740300,
-   .dmm_lisa_map_3 = 0xFF020100,
-   .is_ma_present  = 0x1
-};
-
 void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
 {
-   u64 ram_size;
-
-   ram_size = board_ti_get_emif_size();
-
switch (omap_revision()) {
case DRA752_ES1_0:
case 

[U-Boot] [PATCH 3/3] Revert "ARM: DRA7-evm: Update memory info in banks"

[Semen Protsenko]

From: Sam Protsenko 

This reverts commit d468b1781abe3975fdbc1695ef1fcfb48b01732b.
---
 board/ti/dra7xx/evm.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index eb19a6d..4f60837 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -191,20 +191,6 @@ int board_init(void)
return 0;
 }
 
-void dram_init_banksize(void)
-{
-   u64 ram_size;
-
-   ram_size = board_ti_get_emif_size();
-
-   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
-   gd->bd->bi_dram[0].size = get_effective_memsize();
-   if (ram_size > CONFIG_MAX_MEM_MAPPED) {
-   gd->bd->bi_dram[1].start = 0x2;
-   gd->bd->bi_dram[1].size = ram_size - CONFIG_MAX_MEM_MAPPED;
-   }
-}
-
 int board_late_init(void)
 {
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
-- 
2.7.0

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

[U-Boot] [PATCH 1/3] Revert "ARM: DRA7: configs: Prepare for detecting memory > 2GB"

[Semen Protsenko]

From: Sam Protsenko 

This reverts commit 212425b2721bb67273963b7fc517455425948d90.
---
 include/configs/dra7xx_evm.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index c0795ab..6e3a482 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -19,11 +19,6 @@
 #define CONFIG_IODELAY_RECALIBRATION
 #endif
 
-#define CONFIG_VERY_BIG_RAM
-#define CONFIG_PHYS_64BIT
-#define CONFIG_NR_DRAM_BANKS   2
-#define CONFIG_MAX_MEM_MAPPED  0x8000
-
 #ifndef CONFIG_QSPI_BOOT
 /* MMC ENV related defines */
 #define CONFIG_ENV_IS_IN_MMC
-- 
2.7.0

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

[U-Boot] [PATCH 0/3] ARM: DRA7: Fix fastboot command

[Semen Protsenko]

Hi All,

This series reverts recently added patches that break fastboot command.
I propose to keep it this way until issue is found and fixed.

When I'm trying to run fastboot command, next error occurs:

=> fas 0
data abort
pc : []  lr : [<0020>]
reloc pc : [<8081f25e>]lr : []
...
Resetting CPU ...

My board information:

CPU  : DRA752 ES1.0
Board: DRA74x EVM REV E.0
I2C:   ready
DRAM:  1.5 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
SCSI:  SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sunxi: A83T: fix 32bit overflow warning

[Vishnu Patekar]

In mctl_channel_init, (0x50<<26) which overflows 32bit.
It was supposed to be 0x50<<16,corrected now.

Reported-by: Hans de Goede 
Signed-off-by: Vishnu Patekar 
---
 arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c 
b/arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c
index 7c46acd..55df1b9 100644
--- a/arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c
+++ b/arch/arm/cpu/armv7/sunxi/dram_sun8i_a83t.c
@@ -280,7 +280,7 @@ static int mctl_channel_init(struct dram_para *para)
 
writel(0x94be6fa3, MCTL_PROTECT);
udelay(100);
-   clrsetbits_le32(MX_UPD2, 0xfff << 16, 0x50 << 26);
+   clrsetbits_le32(MX_UPD2, 0xfff << 16, 0x50 << 16);
writel(0x0, MCTL_PROTECT);
udelay(100);
 
-- 
1.9.1

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

Re: [U-Boot] [RFC V2 PATCH 3/3] mmc: add support for block device cache

[Eric Nelson]

Hi Stephen,

On 03/23/2016 10:27 AM, Stephen Warren wrote:
> On 03/20/2016 07:45 PM, Eric Nelson wrote:
> 
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> 
>> @@ -6,7 +6,6 @@
>>*
>>* SPDX-License-Identifier:GPL-2.0+
>>*/
>> -
>>   #include 
> 
> Unrelated change?
> 

Yes. Sorry about that.

> I don't see any cache invalidation call when the SD device is
> re-initialized.
> 
> I think I mentioned these two points last time.

You did and I missed it.

Regards,


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

Re: [U-Boot] [RFC V2 PATCH 2/3] block: add Kconfig options for [CMD_]BLOCK_CACHE

[Eric Nelson]

On 03/23/2016 10:24 AM, Stephen Warren wrote:
> On 03/20/2016 07:45 PM, Eric Nelson wrote:
>> Allow the selection of CONFIG_BLOCK_CACHE, CONFIG_CMD_BLOCK_CACHE
>> using menuconfig.
> 
> I think this should be part of patch 1.

Works for me, especially as it adds some documentation in
the form of help text.

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

Re: [U-Boot] [RFC V2 PATCH 1/3] drivers: block: add block device cache

[Eric Nelson]

Hi Stephen,

Thanks again for the detailed review.

On 03/23/2016 10:22 AM, Stephen Warren wrote:
> On 03/20/2016 07:45 PM, Eric Nelson wrote:
>> Add a block device cache to speed up repeated reads of block devices by
>> various filesystems.
>>
>> This small amount of cache can dramatically speed up filesystem
>> operations by skipping repeated reads of common areas of a block
>> device (typically directory structures).
>>
>> This has shown to have some benefit on FAT filesystem operations of
>> loading a kernel and RAM disk, but more dramatic benefits on ext4
>> filesystems when the kernel and/or RAM disk are spread across
>> multiple extent header structures as described in commit fc0fc50.
>>
>> The cache is implemented through a minimal list (block_cache) maintained
>> in most-recently-used order and count of the current number of entries
>> (cache_count). It uses a maximum block count setting to prevent copies
>> of large block reads and an upper bound on the number of cached areas.
>>
>> The maximum number of entries in the cache defaults to 4 and the maximum
>> number of blocks per cache entry has a default of 1, which matches the
>> current implementation of at least FAT and ext4 that only read a single
>> block at a time.
> 
> If the maximum size of the cache is fixed and small (which judging by
> the description it is), why not use an array rather than a linked list.
> That would be far simpler to manage.
> 

You seem to agree with Marek, and I must be dain-bramaged because I
just don't see it.

>> The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows
>> changing these values and can be used to tune for a particular filesystem
>> layout.
> 
> Even with this dynamic adjustment, using an array still feels simpler,
> although I have't looked at the code yet.
> 
>> diff --git a/drivers/block/cache_block.c b/drivers/block/cache_block.c
> 
>> +/*
>> + * search for a set of blocks in the cache
>> + *
>> + * remove and return the node if found so it can be
>> + * added back at the start of the list and maintain MRU order)
>> + */
> 
> Splitting the remove/add feels a bit dangerous, since forgetting to
> re-do the add (or e.g. some error causing that to be skipped) could
> cause cache_count to become inconsistent.
> 
> The function name "find" is a bit misleading. cache_find_and_remove()
> would make its semantics more obvious. Or, simply put the list_del()
> somewhere else; it doesn't feel like part of a "find" operation to me.
> Or, put the entire move-to-front operation inside this function so it
> isn't split up - if so, cache_find_and_move_to_head().
>

You're right. I'll look at that for a V3 (hopefully non-RFC)
patch set.

>> +static struct block_cache_node *cache_find
>> +(int iftype, int devnum,
> 
> Nit: the ( and first n arguments shouldn't be wrapped.
> 
>> +int cache_block_read(int iftype, int devnum,
>> + lbaint_t start, lbaint_t blkcnt,
>> + unsigned long blksz, void *buffer)
> 
>> +memcpy(buffer, src, blksz*blkcnt);
> 
> Nit: Space around operators. checkpatch should catch this.
> 

Thanks.

>> +if (trace)
>> +printf("hit: start " LBAF ", count " LBAFU "\n",
>> +   start, blkcnt);
> 
> I guess I'll find that trace can be adjusted at run-time somewhere later
> in this patch, but it's more typical to use debug() without the if
> statement for this. It would be awesome if debug() could be adjusted at
> run-time...
> 

I wanted to keep this as a run-time thing because it's useful in
tuning things and I'm not yet certain if/when users might need
to update the sizes.

I could wrap these with some #ifdef stuff but I'm not certain
which is the right thing to do.

>> +void cache_block_fill(int iftype, int devnum,
> ...
>> +if (node->cache == 0) {
>> +node->cache = malloc(bytes);
>> +if (!node->cache) {
> 
> Nit: may as well be consistent with those NULL checks.
> 

Yep.

>> +void cache_block_invalidate(int iftype, int devnum)
> ...
>> +void cache_block_invalidate_all(void)
> 
> There's no invalidate_blocks(); I imagine that writing-to/erasing (some
> blocks of) a device must call cache_block_invalidate() which will wipe
> out even data that wasn't written.
> 

Right. I figured that this wasn't worth extra code.

The 99.99% use case for U-Boot is read-only, so optimizing this
just seems like bloat.

>> +static void dump_block_cache(void)
> ...
>> +list_for_each_safe(entry, n, _cache) {
> 
> Nit: This doesn't need to be _safe since the list is not being modified.
> 

Good catch.

>> +static int do_blkcache(cmd_tbl_t *cmdtp, int flag,
>> +   int argc, char * const argv[])
>> +{
>> +if ((argc == 1) || !strcmp("show", argv[1])) {
>> +printf("block cache:\n"
>> +   "%u\thits\n"
>> +   "%u\tmisses\n"
>> +   "%u\tentries in cache\n"
>> +   "trace %s\n"
>> +   "max blocks/entry %lu\n"
>> +   "max 

Re: [U-Boot] [PATCH v1] Revert "fastboot: OUT transaction length must be aligned to wMaxPacketSize"

[Steve Rae]

Lukasz & Sam:

On Wed, Mar 23, 2016 at 8:54 AM, Sam Protsenko
 wrote:
>
> On Wed, Mar 23, 2016 at 11:49 AM, Lukasz Majewski
>  wrote:
> > Hi Marek,
> >
> >> On 03/23/2016 01:50 AM, Steve Rae wrote:
> >> > This reverts commit 9e4b510d40310bf46e09f4edd0a0b6356213df47.
> >> >
> >> > Signed-off-by: Steve Rae 
> >> > ---
> >> > As discussed on the mailing list, this change breaks the download
> >> > portion of fastboot by causing the server (the device running
> >> > U-Boot) to wait forever for bytes which are never sent by the
> >> > client (the host connected via USB).
> >>
> >> It'd be real cool if you could reference the ML discussion next time.
> >>
> >> > Does anyone know how to contact:
> >> >   Dileep Katta 
> >> > (this email bounces) ?
> >>
> >> No clue, sorry.
> >
> > Probably he is no longer employed by Linaro.
> >
> >>
> >> Applied for now as it fixes real bug.
> >
> > I've a gut feeling that there are different versions of "fastboot"
> > protocol.
> >

Yes - I suspect that also, which is why I test with two (2) fastboot clients:
(1) from 2013 (and I don't know its origin), and
(2) from the Adroid SDK (r24.4.1) for Linux - from
developer.android.com; which requires
the "Android SDK Platform-tools (rev 23.1)" to be installed...
[ this is the current version - checked yesterday! ]

> > What Steve is describing is that HOST is waiting for ZLP ACK.

Lukasz:
Is there any debugging I can enable to verify this?

> >
> > Anyway, I'm not able to test fastboot gadget since our (I mean
> > Samsung's) boards aren't supporting fastboot - we use UMS, DFU, LTHOR.
> >
> > Hence, I can only rely on somebody's testing and review the code without
> > the ability to know about implementation "quirks".
> >
> >>
> >> >  drivers/usb/gadget/f_fastboot.c | 27 +--
> >> >  1 file changed, 5 insertions(+), 22 deletions(-)
> >> >
> >> > diff --git a/drivers/usb/gadget/f_fastboot.c
> >> > b/drivers/usb/gadget/f_fastboot.c index a54b4ee..887cf4f 100644
> >> > --- a/drivers/usb/gadget/f_fastboot.c
> >> > +++ b/drivers/usb/gadget/f_fastboot.c
> >> > @@ -57,7 +57,6 @@ static struct f_fastboot *fastboot_func;
> >> >  static unsigned int fastboot_flash_session_id;
> >> >  static unsigned int download_size;
> >> >  static unsigned int download_bytes;
> >> > -static bool is_high_speed;
> >> >
> >> >  static struct usb_endpoint_descriptor fs_ep_in = {
> >> > .bLength= USB_DT_ENDPOINT_SIZE,
> >> > @@ -241,13 +240,10 @@ static int fastboot_set_alt(struct
> >> > usb_function *f, __func__, f->name, interface, alt);
> >> >
> >> > /* make sure we don't enable the ep twice */
> >> > -   if (gadget->speed == USB_SPEED_HIGH) {
> >> > +   if (gadget->speed == USB_SPEED_HIGH)
> >> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
> >> > -   is_high_speed = true;
> >> > -   } else {
> >> > +   else
> >> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
> >> > -   is_high_speed = false;
> >> > -   }
> >> > if (ret) {
> >> > puts("failed to enable out ep\n");
> >> > return ret;
> >> > @@ -419,20 +415,13 @@ static void cb_getvar(struct usb_ep *ep,
> >> > struct usb_request *req) fastboot_tx_write_str(response);
> >> >  }
> >> >
> >> > -static unsigned int rx_bytes_expected(unsigned int maxpacket)
> >> > +static unsigned int rx_bytes_expected(void)
> >> >  {
> >> > int rx_remain = download_size - download_bytes;
> >> > -   int rem = 0;
> >> > if (rx_remain < 0)
> >> > return 0;
> >> > if (rx_remain > EP_BUFFER_SIZE)
> >> > return EP_BUFFER_SIZE;
> >> > -   if (rx_remain < maxpacket) {
> >> > -   rx_remain = maxpacket;
> >> > -   } else if (rx_remain % maxpacket != 0) {
> >> > -   rem = rx_remain % maxpacket;
> >> > -   rx_remain = rx_remain + (maxpacket - rem);
> >> > -   }
> >> > return rx_remain;
> >> >  }
> >> >
> >> > @@ -444,7 +433,6 @@ static void rx_handler_dl_image(struct usb_ep
> >> > *ep, struct usb_request *req) const unsigned char *buffer =
> >> > req->buf; unsigned int buffer_size = req->actual;
> >> > unsigned int pre_dot_num, now_dot_num;
> >> > -   unsigned int max;
> >> >
> >> > if (req->status != 0) {
> >> > printf("Bad status: %d\n", req->status);
> >> > @@ -482,9 +470,7 @@ static void rx_handler_dl_image(struct usb_ep
> >> > *ep, struct usb_request *req)
> >> > printf("\ndownloading of %d bytes finished\n",
> >> > download_bytes); } else {
> >> > -   max = is_high_speed ? hs_ep_out.wMaxPacketSize :
> >> > -   fs_ep_out.wMaxPacketSize;
> >> > -   req->length = rx_bytes_expected(max);
> >> > +   req->length = rx_bytes_expected();
> >> > if (req->length < ep->maxpacket)
> >> > req->length = ep->maxpacket;
> >> > }
> >> > @@ -497,7 +483,6 @@ static void 

Re: [U-Boot] [RFC V2 PATCH 3/3] mmc: add support for block device cache

[Stephen Warren]

On 03/20/2016 07:45 PM, Eric Nelson wrote:


diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c



@@ -6,7 +6,6 @@
   *
   * SPDX-License-Identifier:   GPL-2.0+
   */
-
  #include 


Unrelated change?

I don't see any cache invalidation call when the SD device is 
re-initialized.


I think I mentioned these two points last time.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC V2 PATCH 2/3] block: add Kconfig options for [CMD_]BLOCK_CACHE

[Stephen Warren]

On 03/20/2016 07:45 PM, Eric Nelson wrote:

Allow the selection of CONFIG_BLOCK_CACHE, CONFIG_CMD_BLOCK_CACHE
using menuconfig.


I think this should be part of patch 1.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC V2 PATCH 1/3] drivers: block: add block device cache

[Stephen Warren]

On 03/20/2016 07:45 PM, Eric Nelson wrote:

Add a block device cache to speed up repeated reads of block devices by
various filesystems.

This small amount of cache can dramatically speed up filesystem
operations by skipping repeated reads of common areas of a block
device (typically directory structures).

This has shown to have some benefit on FAT filesystem operations of
loading a kernel and RAM disk, but more dramatic benefits on ext4
filesystems when the kernel and/or RAM disk are spread across
multiple extent header structures as described in commit fc0fc50.

The cache is implemented through a minimal list (block_cache) maintained
in most-recently-used order and count of the current number of entries
(cache_count). It uses a maximum block count setting to prevent copies
of large block reads and an upper bound on the number of cached areas.

The maximum number of entries in the cache defaults to 4 and the maximum
number of blocks per cache entry has a default of 1, which matches the
current implementation of at least FAT and ext4 that only read a single
block at a time.


If the maximum size of the cache is fixed and small (which judging by 
the description it is), why not use an array rather than a linked list. 
That would be far simpler to manage.



The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows
changing these values and can be used to tune for a particular filesystem
layout.


Even with this dynamic adjustment, using an array still feels simpler, 
although I have't looked at the code yet.



diff --git a/drivers/block/cache_block.c b/drivers/block/cache_block.c



+/*
+ * search for a set of blocks in the cache
+ *
+ * remove and return the node if found so it can be
+ * added back at the start of the list and maintain MRU order)
+ */


Splitting the remove/add feels a bit dangerous, since forgetting to 
re-do the add (or e.g. some error causing that to be skipped) could 
cause cache_count to become inconsistent.


The function name "find" is a bit misleading. cache_find_and_remove() 
would make its semantics more obvious. Or, simply put the list_del() 
somewhere else; it doesn't feel like part of a "find" operation to me. 
Or, put the entire move-to-front operation inside this function so it 
isn't split up - if so, cache_find_and_move_to_head().



+static struct block_cache_node *cache_find
+   (int iftype, int devnum,


Nit: the ( and first n arguments shouldn't be wrapped.


+int cache_block_read(int iftype, int devnum,
+lbaint_t start, lbaint_t blkcnt,
+unsigned long blksz, void *buffer)



+   memcpy(buffer, src, blksz*blkcnt);


Nit: Space around operators. checkpatch should catch this.


+   if (trace)
+   printf("hit: start " LBAF ", count " LBAFU "\n",
+  start, blkcnt);


I guess I'll find that trace can be adjusted at run-time somewhere later 
in this patch, but it's more typical to use debug() without the if 
statement for this. It would be awesome if debug() could be adjusted at 
run-time...



+void cache_block_fill(int iftype, int devnum,

...

+   if (node->cache == 0) {
+   node->cache = malloc(bytes);
+   if (!node->cache) {


Nit: may as well be consistent with those NULL checks.


+void cache_block_invalidate(int iftype, int devnum)

...

+void cache_block_invalidate_all(void)


There's no invalidate_blocks(); I imagine that writing-to/erasing (some 
blocks of) a device must call cache_block_invalidate() which will wipe 
out even data that wasn't written.



+static void dump_block_cache(void)

...

+   list_for_each_safe(entry, n, _cache) {


Nit: This doesn't need to be _safe since the list is not being modified.


+static int do_blkcache(cmd_tbl_t *cmdtp, int flag,
+  int argc, char * const argv[])
+{
+   if ((argc == 1) || !strcmp("show", argv[1])) {
+   printf("block cache:\n"
+  "%u\thits\n"
+  "%u\tmisses\n"
+  "%u\tentries in cache\n"
+  "trace %s\n"
+  "max blocks/entry %lu\n"
+  "max entries %lu\n",
+  block_cache_hits, block_cache_misses, cache_count,
+  trace ? "on" : "off",
+  max_blocks_per_entry, max_cache_entries);


Nit: Let's print the value and "label" in a consistent order. I would 
suggest everything being formatted as:


"description: %u"

so that it's indented, has a delimiter between description and value, 
and so that irrespective of the length of the converted value, the 
indentation of the other parts of the string don't change (\t doesn't 
guarantee this after a certain number length).


I would rather have expected "show" to dump the entries too, but I 
suppose it's fine that they're separate.



+   } else if ((argc == 2) && ('c' == argv[1][0])) {


Nit: 

[U-Boot] pull request: u-boot-uniphier/master

[Masahiro Yamada]

Hi Tom,


Here is a series of UniPhier SoCs updates for v2016.5-rc1.
It includes ARM64 compiler warning fixes, cleanups, new SoC/board DTS,
and misc changes.



The following changes since commit 0764f24ae6bc937e358990c357f7452b4d5351e3:

  net: Move CONFIG_RTL8169 to Kconfig (2016-03-22 12:19:53 -0400)

are available in the git repository at:

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

for you to fetch changes up to d085ecd61b9956cda0d37b89b5c538f54440fe58:

  ARM: uniphier: switch to raw U-Boot image (2016-03-24 01:45:41 +0900)


Masahiro Yamada (18):
  mtd: denali: fix warning when compiled for 64bit system
  spl_mmc: allow to load raw image
  ARM: dts: uniphier: add device tree for Micro Support Card
  ARM: uniphier: remove commented out define
  ARM: uniphier: fix bogus comment
  ARM: uniphier: drop PH1- prefix from CONFIG options and file names
  ARM: uniphier: refactor SBC init code
  ARM: uniphier: drop ifdef in ddrphy-regs.h
  ARM: uniphier: add work-around to support Micro Support Card v3.6.10
  ARM: uniphier: enable DDR PHY parameter dump commands by default
  ARM: dts: uniphier: add PH1-LD20 SoC/board device tree sources
  ARM: dts: uniphier: add PH1-LD11 SoC/board device tree sources
  ARM: uniphier: add sg_set_iectrl() function
  ARM: uniphier: add System Control register macros for ARMv8 SoCs
  ARM: uniphier: support Debug UART
  ARM: uniphier: fix README instruction for updating U-Boot via TFTP
  ARM: uniphier: add NOR boot support
  ARM: uniphier: switch to raw U-Boot image

 arch/arm/dts/Makefile   |   2 +
 arch/arm/dts/uniphier-ph1-ld11-ref.dts  |  69 +++
 arch/arm/dts/uniphier-ph1-ld11.dtsi | 205
+
 arch/arm/dts/uniphier-ph1-ld20-ref.dts  |  69 +++
 arch/arm/dts/uniphier-ph1-ld20.dtsi | 241
+
 arch/arm/dts/uniphier-ph1-ld4-ref.dts   |   5 +
 arch/arm/dts/uniphier-ph1-ld6b-ref.dts  |   5 +
 arch/arm/dts/uniphier-ph1-pro4-ref.dts  |   5 +
 arch/arm/dts/uniphier-ph1-sld3-ref.dts  |   5 +
 arch/arm/dts/uniphier-ph1-sld8-ref.dts  |   5 +
 arch/arm/dts/uniphier-pinctrl.dtsi  |   5 +
 arch/arm/dts/uniphier-support-card.dtsi |  33 
 arch/arm/mach-uniphier/Kconfig  |  23 +--
 arch/arm/mach-uniphier/Makefile |   1 +
 arch/arm/mach-uniphier/arm32/debug_ll.S |  42 ++---
 arch/arm/mach-uniphier/bcu/Makefile |   6 +-
 arch/arm/mach-uniphier/bcu/{bcu-ph1-ld4.c => bcu-ld4.c} |   0
 arch/arm/mach-uniphier/bcu/{bcu-ph1-sld3.c => bcu-sld3.c}   |   0
 arch/arm/mach-uniphier/board_early_init_f.c |  28 +--
 arch/arm/mach-uniphier/boards.c |  28 +--
 arch/arm/mach-uniphier/boot-mode/Makefile   |  14 +-
 .../boot-mode/{boot-mode-ph1-ld4.c => boot-mode-ld4.c}  |   2 +-
 .../boot-mode/{boot-mode-ph1-pro5.c => boot-mode-pro5.c}|   0
 .../boot-mode/{boot-mode-proxstream2.c => boot-mode-pxs2.c} |   0
 .../boot-mode/{boot-mode-ph1-sld3.c => boot-mode-sld3.c}|   2 +-
 arch/arm/mach-uniphier/boot-mode/boot-mode.c|  26 ++-
 arch/arm/mach-uniphier/boot-mode/cmd_pinmon.c   |  26 ++-
 arch/arm/mach-uniphier/clk/Makefile |  14 +-
 arch/arm/mach-uniphier/clk/{clk-ph1-ld4.c => clk-ld4.c} |   0
 arch/arm/mach-uniphier/clk/{clk-ph1-pro4.c => clk-pro4.c}   |   0
 arch/arm/mach-uniphier/clk/{clk-ph1-pro5.c => clk-pro5.c}   |   0
 .../arm/mach-uniphier/clk/{clk-proxstream2.c => clk-pxs2.c} |   0
 arch/arm/mach-uniphier/debug-uart/Makefile  |  17 ++
 arch/arm/mach-uniphier/debug-uart/debug-uart-ld20.c |  35 
 arch/arm/mach-uniphier/debug-uart/debug-uart-ld4.c  |  21 +++
 arch/arm/mach-uniphier/debug-uart/debug-uart-ld6b.c |  31 
 arch/arm/mach-uniphier/debug-uart/debug-uart-pro4.c |  31 
 arch/arm/mach-uniphier/debug-uart/debug-uart-pro5.c |  34 
 arch/arm/mach-uniphier/debug-uart/debug-uart-pxs2.c |  32 
 arch/arm/mach-uniphier/debug-uart/debug-uart-sld3.c |  31 
 arch/arm/mach-uniphier/debug-uart/debug-uart-sld8.c |  21 +++
 arch/arm/mach-uniphier/debug-uart/debug-uart.c  |  85 +
 arch/arm/mach-uniphier/debug-uart/debug-uart.h  |  20 ++
 arch/arm/mach-uniphier/dram/Makefile|  16 +-
 arch/arm/mach-uniphier/dram/cmd_ddrphy.c| 168
++---
 .../mach-uniphier/dram/{ddrphy-ph1-ld4.c => ddrphy-ld4.c}   |   0
 arch/arm/mach-uniphier/dram/ddrphy-regs.h

Re: [U-Boot] [PATCH 0/3] ARM: uniphier: more patches for bulk updates for v2016.05-rc1

[Masahiro Yamada]

2016-03-23 1:40 GMT+09:00 Masahiro Yamada :
>
>
>
> Masahiro Yamada (3):
>   ARM: uniphier: fix README instruction for updating U-Boot via TFTP
>   ARM: uniphier: add NOR boot support
>   ARM: uniphier: switch to raw U-Boot image


Series, Applied to u-boot-uniphier/master.


-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/13] ARM: uniphier: bulk changes for v2016.05-rc1

[Masahiro Yamada]

2016-03-18 16:41 GMT+09:00 Masahiro Yamada :
>
>
>
> Masahiro Yamada (13):
>   ARM: dts: uniphier: add device tree for Micro Support Card
>   ARM: uniphier: remove commented out define
>   ARM: uniphier: fix bogus comment
>   ARM: uniphier: drop PH1- prefix from CONFIG options and file names
>   ARM: uniphier: refactor SBC init code
>   ARM: uniphier: drop ifdef in ddrphy-regs.h
>   ARM: uniphier: add work-around to support Micro Support Card v3.6.10
>   ARM: uniphier: enable DDR PHY parameter dump commands by default
>   ARM: dts: uniphier: add PH1-LD20 SoC/board device tree sources
>   ARM: dts: uniphier: add PH1-LD11 SoC/board device tree sources
>   ARM: uniphier: add sg_set_iectrl() function
>   ARM: uniphier: add System Control register macros for ARMv8 SoCs
>   ARM: uniphier: support Debug UART


Series, Applied to u-boot-uniphier/master.



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: denali: fix warning when compiled for 64bit system

[Masahiro Yamada]

2016-02-29 20:57 GMT+09:00 Masahiro Yamada :
> The 64-bit compiler (ex. aarch64) emits "warning: cast from pointer
> to integer of different size".
>
> Make it work with 64bit DMA address while I am here.
>
> Signed-off-by: Masahiro Yamada 

Applied to u-boot-uniphier/master.



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] spl_mmc: allow to load raw image

[Masahiro Yamada]

2016-03-16 12:10 GMT+09:00 Masahiro Yamada :
> The function spl_parse_image_header() falls back to a raw image
> if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE
> is undefined.  While, mmc_load_image_raw_sector() only accepts a
> U-Boot legacy image or an FIT image, preventing us from loading a
> raw image.
>
> Signed-off-by: Masahiro Yamada 


Applied to u-boot-uniphier/master.


-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [T1040] Boot location and NOR flash memory mapping

[york sun]

Valentin,

Your understand is correct. Please see my answers below to your questions.

On 03/23/2016 12:46 AM, Valentin Longchamp wrote:
> Hello,
> 
> We are currently designing a board based on the T1040 CPU from Freescale/NXP. 
> I
> am preparing its u-boot support and bring-up tools (JTAG) as well as
> contributing to the hardware design. We base our work (both HW and SW) on the
> 1040RDB dev board as our reference design. We want to use a parallel
> ("classical", not SPI) NOR Flash to boot from and to store our RCW/PBL and 
> u-boot.
> 
> I have a question regarding the Boot location address when booting from the 
> NOR
> flash. From the documentation, it is clear that the RCW and PBL instructions 
> are
> read from the NOR (when cfg_rcw_src and RCW[PBI_SRC] are defined accordingly)
> through CS0 at from the address 0x_ (RM 27.5.1, PBL Starting 
> addresses).
> I have not found a clear indication about this in the doc, but I guess that 
> the
> PBL manages to minimally configure the IFC NOR controller to make sure the
> addresses it accesses trigger the CS0 and drives the address lines to access
> address 0 and counting up. My understanding is that we must thus make sure 
> that
> the NOR Flash's CS is connected to the CS0.
> 
> For the actual boot location (i.e. when the cores start to execute code, after
> the RCW/PBL sequence), as stated in section 4.3.3 in the RM (Boot Space
> Translation), the cores execute the code that is located in the 4K page 
> located
> at address 0x0__F000, starting with the reset vector at address
> 0x0__FFFC, which are located in the default boot location (0x0_FF80_ 
> to
> 0x0__). My conclusion is that somehow, the IFC NOR controller is again
> configured so that the accesses to this memory range will trigger the CS0 NOR
> access (in the T1040RDB RCW/PBL, I have seen no indication that another boot
> window than the default one is use, since the boot space translation 
> capability
> is unused). But since the NOR boot section (24.6.1) does not give any 
> details, I
> have no idea how this works.
> 
> Now u-boot, for its T1040RDB support, uses a memory mapping for the NOR Flash
> that is not aligned with the above boot location mapping. The 128 MB of the 
> NOR
> flash are mapped from 0xE800_ to 0xEFFF_. My guess about this "change"
> it that it is to avoid the memory conflict with CCSR that is located at
> 0x0_FE00_ by default when the NOR is bigger than 16 MB. I think this 
> mapping
> is only relevant later in the u-boot boot sequence, when the TLBs and LAWs are
> configured but not at boot time.
> 
> I have two questions about this NOR boot mechanism:
> - how are the NOR accesses really happening (or how is the IFC NOR configured)
> at boot time to read the RCW/PBL and the boot code at boot location ? I ask 
> this
> in order to make sure that our HW design will allow us to boot from the NOR
> Flash (i.e. how we connect the NOR address bus to the IFC)

When IFC NOR flash is used for RCW_SRC (configured by hardware pins), the IFC
defaults some registers to enable accessing to CS0. You can read the notes for
CSPR0, CSOR0, AMASK0, etc. Basically they are set to default values based on the
RCW_SRC and 4G space is mapped to CS0. So you can see any reading accessing is
mapped to CS0. Because we don't have NOR flash with 4GB, and we don't have 32
address pins on NOR flash chip, you can expect to get RCW image from the
beginning of NOR flash at multiple addresses, including zero. You can also
expect to get reset vector at multiple addresses, including 0xfffc. So in
short, these default settings guarantee the RCW and reset vectors are
accessible, regardless the size of NOR flash chip.

> - what about CONFIG_SYS_TEXT_BASE ? I see that it defined according the later
> "u-boot" memory mapping. Why this one and not the "boot time" one ?

Since we have 128MB NOR flash chip, and other devices on IFC, the default memory
map is not enough. We need to remap them to avoid conflicts and make room. It is
done by calling init_early_memctl_regs(). CONFIG_SYS_TEXT_BASE needs to match
the actual address.

You worked on 85xx before (kmp204x). It is the same idea. Even T1040 had a "T"
in the name, it is still in mpc85xx family.

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

Re: [U-Boot] [PATCH] smsc95xx: fix operation on 64-bit systems

[Joe Hershberger]

On Tue, Mar 22, 2016 at 11:28 PM, Stephen Warren  wrote:
> smsc95xx_read_reg() should calculate sizeof(*data) not sizeof(data) since
> data is a pointer, and the value pointed at is being transferred over USB,
> not the value of the pointer. This fixes operation of the driver in 64-bit
> builds, such as the Raspberry Pi 3.
>
> Reported-by: Eric Anholt 
> Signed-off-by: Stephen Warren 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1] Revert "fastboot: OUT transaction length must be aligned to wMaxPacketSize"

[Sam Protsenko]

On Wed, Mar 23, 2016 at 11:49 AM, Lukasz Majewski
 wrote:
> Hi Marek,
>
>> On 03/23/2016 01:50 AM, Steve Rae wrote:
>> > This reverts commit 9e4b510d40310bf46e09f4edd0a0b6356213df47.
>> >
>> > Signed-off-by: Steve Rae 
>> > ---
>> > As discussed on the mailing list, this change breaks the download
>> > portion of fastboot by causing the server (the device running
>> > U-Boot) to wait forever for bytes which are never sent by the
>> > client (the host connected via USB).
>>
>> It'd be real cool if you could reference the ML discussion next time.
>>
>> > Does anyone know how to contact:
>> >   Dileep Katta 
>> > (this email bounces) ?
>>
>> No clue, sorry.
>
> Probably he is no longer employed by Linaro.
>
>>
>> Applied for now as it fixes real bug.
>
> I've a gut feeling that there are different versions of "fastboot"
> protocol.
>
> What Steve is describing is that HOST is waiting for ZLP ACK.
>
> Anyway, I'm not able to test fastboot gadget since our (I mean
> Samsung's) boards aren't supporting fastboot - we use UMS, DFU, LTHOR.
>
> Hence, I can only rely on somebody's testing and review the code without
> the ability to know about implementation "quirks".
>
>>
>> >  drivers/usb/gadget/f_fastboot.c | 27 +--
>> >  1 file changed, 5 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/drivers/usb/gadget/f_fastboot.c
>> > b/drivers/usb/gadget/f_fastboot.c index a54b4ee..887cf4f 100644
>> > --- a/drivers/usb/gadget/f_fastboot.c
>> > +++ b/drivers/usb/gadget/f_fastboot.c
>> > @@ -57,7 +57,6 @@ static struct f_fastboot *fastboot_func;
>> >  static unsigned int fastboot_flash_session_id;
>> >  static unsigned int download_size;
>> >  static unsigned int download_bytes;
>> > -static bool is_high_speed;
>> >
>> >  static struct usb_endpoint_descriptor fs_ep_in = {
>> > .bLength= USB_DT_ENDPOINT_SIZE,
>> > @@ -241,13 +240,10 @@ static int fastboot_set_alt(struct
>> > usb_function *f, __func__, f->name, interface, alt);
>> >
>> > /* make sure we don't enable the ep twice */
>> > -   if (gadget->speed == USB_SPEED_HIGH) {
>> > +   if (gadget->speed == USB_SPEED_HIGH)
>> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
>> > -   is_high_speed = true;
>> > -   } else {
>> > +   else
>> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
>> > -   is_high_speed = false;
>> > -   }
>> > if (ret) {
>> > puts("failed to enable out ep\n");
>> > return ret;
>> > @@ -419,20 +415,13 @@ static void cb_getvar(struct usb_ep *ep,
>> > struct usb_request *req) fastboot_tx_write_str(response);
>> >  }
>> >
>> > -static unsigned int rx_bytes_expected(unsigned int maxpacket)
>> > +static unsigned int rx_bytes_expected(void)
>> >  {
>> > int rx_remain = download_size - download_bytes;
>> > -   int rem = 0;
>> > if (rx_remain < 0)
>> > return 0;
>> > if (rx_remain > EP_BUFFER_SIZE)
>> > return EP_BUFFER_SIZE;
>> > -   if (rx_remain < maxpacket) {
>> > -   rx_remain = maxpacket;
>> > -   } else if (rx_remain % maxpacket != 0) {
>> > -   rem = rx_remain % maxpacket;
>> > -   rx_remain = rx_remain + (maxpacket - rem);
>> > -   }
>> > return rx_remain;
>> >  }
>> >
>> > @@ -444,7 +433,6 @@ static void rx_handler_dl_image(struct usb_ep
>> > *ep, struct usb_request *req) const unsigned char *buffer =
>> > req->buf; unsigned int buffer_size = req->actual;
>> > unsigned int pre_dot_num, now_dot_num;
>> > -   unsigned int max;
>> >
>> > if (req->status != 0) {
>> > printf("Bad status: %d\n", req->status);
>> > @@ -482,9 +470,7 @@ static void rx_handler_dl_image(struct usb_ep
>> > *ep, struct usb_request *req)
>> > printf("\ndownloading of %d bytes finished\n",
>> > download_bytes); } else {
>> > -   max = is_high_speed ? hs_ep_out.wMaxPacketSize :
>> > -   fs_ep_out.wMaxPacketSize;
>> > -   req->length = rx_bytes_expected(max);
>> > +   req->length = rx_bytes_expected();
>> > if (req->length < ep->maxpacket)
>> > req->length = ep->maxpacket;
>> > }
>> > @@ -497,7 +483,6 @@ static void cb_download(struct usb_ep *ep,
>> > struct usb_request *req) {
>> > char *cmd = req->buf;
>> > char response[FASTBOOT_RESPONSE_LEN];
>> > -   unsigned int max;
>> >
>> > strsep(, ":");
>> > download_size = simple_strtoul(cmd, NULL, 16);
>> > @@ -513,9 +498,7 @@ static void cb_download(struct usb_ep *ep,
>> > struct usb_request *req) } else {
>> > sprintf(response, "DATA%08x", download_size);
>> > req->complete = rx_handler_dl_image;
>> > -   max = is_high_speed ? hs_ep_out.wMaxPacketSize :
>> > -   fs_ep_out.wMaxPacketSize;
>> > -   req->length = rx_bytes_expected(max);
>> > +   req->length = rx_bytes_expected();
>> > if 

[U-Boot] [PATCH] README: Specify the full path for README.displaying-bmps

[Fabio Estevam]

From: Fabio Estevam 

It is clearer to specify the full path to access the 
doc/README.displaying-bmps file.

Signed-off-by: Fabio Estevam 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 523941f..1fb8f88 100644
--- a/README
+++ b/README
@@ -1908,7 +1908,7 @@ CBFS (Coreboot Filesystem) support
 
If this option is set, then U-Boot will prevent the environment
variable "splashimage" from being set to a problematic address
-   (see README.displaying-bmps).
+   (see doc/README.displaying-bmps).
This option is useful for targets where, due to alignment
restrictions, an improperly aligned BMP image will cause a data
abort. If you think you will not have problems with unaligned
-- 
1.9.1

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

[U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Stefan Roese]

Hi Chin,

On 23.03.2016 16:00, Chin Liang See wrote:

On Mon, 2016-03-21 at 23:45 +0800, Chin Liang See wrote:

On Mon, 2016-03-21 at 22:05 +0800, Chin Liang See wrote:

On Fri, 2016-03-04 at 20:03 +0100, Marek Vasut wrote:

On 03/04/2016 05:06 PM, Dinh Nguyen wrote:

On 03/02/2016 05:24 PM, Marek Vasut wrote:


[..]


Well, that's our usual USB/QSPI cache issue that's tormenting
your soul.
CCing Chin ;-)

Does the issue by any chance magically disappear if you apply
this patch:

diff --git a/arch/arm/include/asm/system.h
b/arch/arm/include/asm/system.h
index 026e7ef..06802c6 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -274,7 +274,7 @@ static inline void set_dacr(unsigned int
val)

  /* options available for data cache on each page */
  enum dcache_option {
-   DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK |
TTB_SECT,
+   DCACHE_OFF = TTB_SECT_S_MASK | TTB_SECT_DOMAIN(0) |
TTB_SECT_XN_MASK | TTB_SECT,
 DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
 DCACHE_WRITEBACK = DCACHE_WRITETHROUGH |
TTB_SECT_B_MASK,
 DCACHE_WRITEALLOC = DCACHE_WRITEBACK |
TTB_SECT_TEX(1),



Yes, this patch fixes USB with dcache left on.


Except that it doesn't fix anything, it just makes the system
slower
by
setting the S bit :-/ So this is not a fix :-(


Sorry for away for a while as busy with some critical issues.

Finally relooking back on this. I notice that with SanDisk Cruzer
Blade
pendrive, U-Boot 2013.01.01 can detect it while latest cannot. The
dcache disablement at latest U-Boot doesn't help.

With that, I compared a bunch of registers from clocks, sysmgr,
SCTLR,
ATCLR and USB1 too. I noticed they are similar except the
usb1.globgrp.gusbcfg.ulpiextvbusdrv. The latest U-Boot is
indicating
external supply (address 0xffb4000c return value 0x00101710) while
working 2013.01.01 indicating internal charge pump (return value
0x1710)

Wonder you guys are seeing the same too? Will dig more about this.
FYI,
I tried to add lot of delay within dwc2.c but doesn't help at all.



While modifying the USB power control of the code, I noticed the
patch
made by Dinh is not there. Just realize the git clone through http
from
main git doesn't work. I was able to clone but getting older version.

With getting the latest code, all my pendrive now can works with
dcache
off. Its easier now as I can get consistent behaviour compared
previously. With that, dcache investigation for tomorrow then

Thanks
Chin Liang



Spent more time on the dcache + USB issue today. Narrow down to below
patch which can make all my USB pendrives work with dcache enabled. But
still need to understand further as not in depth familiar with dwc2.
Probably this might ring a bell to you guys?


diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index b2f4bc6..b11d8d7 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -776,6 +776,7 @@ static int transfer_chunk(struct dwc2_hc_regs
*hc_regs, void *aligned_buffer,
(num_packets << DWC2_HCTSIZ_PKTCNT_OFFSET) |
(*pid << DWC2_HCTSIZ_PID_OFFSET),
_regs->hctsiz);
+   udelay(2);

 if (!in && xfer_len) {
 memcpy(aligned_buffer, buffer, xfer_len);


I can't really comment on the USB problem, as I've only seen this
d-cache / S-bit problem with SPI NOR flash. This is because I've never
really used USB on this platform intensively. But I'm nearly 100%
sure, that all changes that add some delays (or debug printfs)
resulting in a "working solution", either in the USB case or the SPI
NOR case, are just papering over the real problem.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH v2 00/11] armv8: ls2080aqds: Enable QSPI boot support

[york sun]

On 03/23/2016 01:12 AM, Yao Yuan wrote:
> On 03/23/2016 03:09 AM, York Sun wrote:
>> On 03/06/2016 11:56 PM, Yuan Yao wrote:
>>> From: Yuan Yao 
>>>
>>> This series add support for QSPI boot on LS2080AQDS.
>>>
>>> Yuan Yao (11):
>>>   armv8: ls2080aqds: Select QSPI CLK div via SCFG
>>>   configs: ls2080a_common: Remove duplicate NOR configs
>>>   configs: ls2080aqds: disable IFC NOR & QIXIS when QSPI enable
>>>   configs: ls2080aqds: Enable QSPI flash support
>>>   dm: dts: ls2080aqds: Add QSPI dts node
>>>   armv8: ls2080aqds: Config QSPI pin mux via FPGA in NAND boot
>>>   configs: ls2080a: Increase load image len in NAND boot
>>>   ls2080aqds_nand_defconfig: Enable QSPI & its dependence
>>>   armv8: ls2080aqds: Enable QSPI boot support
>>> Changed in v2:
>>>  merged the patch:
>>>  0009-armv8-ls2080aqds-Enable-QSPI-boot-support.patch
>>>  0010-ls2080aqds-Enable-support-for-boot-from-QSPI.patch
>>>  0012-LS2080QDS-QSPI-boot-fix-issues.patch
>>>  in this patch.
>>>   board/ls2080qds: add the procedure to deply QSPI image.
>>> New add in v2.
>>>   freescale: cmd: qixis: tidy up the duplicated code
>>>
>>>  arch/arm/dts/fsl-ls2080a-qds.dts   | 14 +++
>>>  arch/arm/dts/fsl-ls2080a.dtsi  | 10 +
>>>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |  4 ++
>>>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  3 ++
>>>  board/freescale/common/qixis.c | 12 ++
>>>  board/freescale/ls2080aqds/README  | 35 ++
>>>  board/freescale/ls2080aqds/ls2080aqds.c| 16 
>>>  common/board_f.c   |  6 +--
>>>  configs/ls2080aqds_nand_defconfig  |  9 +
>>>  configs/ls2080aqds_qspi_defconfig  | 10 +
>>>  include/configs/ls2080a_common.h   | 11 ++
>>>  include/configs/ls2080a_simu.h |  7 
>>>  include/configs/ls2080aqds.h   | 43 
>>> +-
>>>  13 files changed, 159 insertions(+), 21 deletions(-)  create mode
>>> 100644 configs/ls2080aqds_qspi_defconfig
>>>
>>
>> Yuan,
>>
>> This set was sent before Jagan's comment on your v1 patch. Please let me
>> know if you need to update your patches.
>>
> 
> Yes, I will update this patch set.
> But from some review and comments there is a lot of the changes for this 
> patch set.
> So I need some time to confirm and test it.
> I will resend this patch set as soon as possible.
> 

That's OK. Take you time. You may have to wait until Jagan's patch set is 
settled

York

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

[U-Boot] [PATCH 1/2] ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery

[Nishanth Menon]

MSMC segment Privilege ID is not consistent accross the keystone2 SoCs.
As the first step to ensure complete SoC wide coherency setup, lets
refactor the macros to remove the #if-deffery around the code which
obfuscates which IDs are actually enabled for which SoC.

As a result of this change the PCIe configuration is moved after the
msmc configuration is complete, but that should ideally have no
functional impact.

Signed-off-by: Nishanth Menon 
---
 arch/arm/mach-keystone/include/mach/hardware-k2e.h |  3 --
 arch/arm/mach-keystone/include/mach/hardware-k2l.h |  3 --
 arch/arm/mach-keystone/include/mach/hardware.h | 27 +-
 arch/arm/mach-keystone/init.c  | 43 ++
 4 files changed, 53 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2e.h 
b/arch/arm/mach-keystone/include/mach/hardware-k2e.h
index df499957e54d..e6bc77caaf09 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2e.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2e.h
@@ -34,9 +34,6 @@
 #define KS2_LPSC_PCIE_127
 #define KS2_LPSC_XGE   50
 
-/* MSMC */
-#define KS2_MSMC_SEGMENT_PCIE1 13
-
 /* Chip Interrupt Controller */
 #define KS2_CIC2_DDR3_ECC_IRQ_NUM  -1  /* not defined in K2E */
 #define KS2_CIC2_DDR3_ECC_CHAN_NUM -1  /* not defined in K2E */
diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2l.h 
b/arch/arm/mach-keystone/include/mach/hardware-k2l.h
index a59e0713593f..92c17d7dd5ba 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2l.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2l.h
@@ -53,9 +53,6 @@
 #define KS2_LPSC_FFTC_B49
 #define KS2_LPSC_IQN_AIL   50
 
-/* MSMC */
-#define KS2_MSMC_SEGMENT_PCIE1 14
-
 /* Chip Interrupt Controller */
 #define KS2_CIC2_DDR3_ECC_IRQ_NUM  0x0D3
 #define KS2_CIC2_DDR3_ECC_CHAN_NUM 0x01D
diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
b/arch/arm/mach-keystone/include/mach/hardware.h
index 8ca19bbcdbe9..dd9268fbf209 100644
--- a/arch/arm/mach-keystone/include/mach/hardware.h
+++ b/arch/arm/mach-keystone/include/mach/hardware.h
@@ -215,16 +215,23 @@ typedef volatile unsigned int   *dv_reg_p;
 /* MSMC control */
 #define KS2_MSMC_CTRL_BASE 0x0bc0
 #define KS2_MSMC_DATA_BASE 0x0c00
-#ifndef CONFIG_SOC_K2G
-#define KS2_MSMC_SEGMENT_TETRIS8
-#define KS2_MSMC_SEGMENT_NETCP 9
-#define KS2_MSMC_SEGMENT_QM_PDSP   10
-#define KS2_MSMC_SEGMENT_PCIE0 11
-#else
-#define KS2_MSMC_SEGMENT_TETRIS1
-#define KS2_MSMC_SEGMENT_NETCP 4
-#define KS2_MSMC_SEGMENT_PCIE0 5
-#endif
+
+/* KS2 HK/L/E MSMC PRIVIDs  for MSMC2 */
+#define K2HKLE_MSMC_SEGMENT_ARM8
+#define K2HKLE_MSMC_SEGMENT_NETCP  9
+#define K2HKLE_MSMC_SEGMENT_QM_PDSP10
+#define K2HKLE_MSMC_SEGMENT_PCIE0  11
+
+/* K2L specific Privilege ID Settings */
+#define K2L_MSMC_SEGMENT_PCIE1 14
+
+/* K2E specific Privilege ID Settings */
+#define K2E_MSMC_SEGMENT_PCIE1 13
+
+/* K2G specific Privilege ID Settings */
+#define K2G_MSMC_SEGMENT_ARM   1
+#define K2G_MSMC_SEGMENT_NSS   4
+#define K2G_MSMC_SEGMENT_PCIE  5
 
 /* MSMC segment size shift bits */
 #define KS2_MSMC_SEG_SIZE_SHIFT12
diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index aadd10bff270..2368315ff68c 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -96,22 +96,51 @@ static void config_pcie_mode(int pcie_port,  enum pci_mode 
mode)
__raw_writel(val, KS2_DEVCFG);
 }
 
+static void msmc_k2hkle_common_setup(void)
+{
+   msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
+   msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
+#ifdef KS2_MSMC_SEGMENT_QM_PDSP
+   msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
+#endif
+   msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_PCIE0);
+}
+
+static inline void msmc_k2l_setup(void)
+{
+   msmc_share_all_segments(K2L_MSMC_SEGMENT_PCIE1);
+}
+
+static inline void msmc_k2e_setup(void)
+{
+   msmc_share_all_segments(K2E_MSMC_SEGMENT_PCIE1);
+}
+
+static inline void msmc_k2g_setup(void)
+{
+   msmc_share_all_segments(K2G_MSMC_SEGMENT_ARM);
+   msmc_share_all_segments(K2G_MSMC_SEGMENT_NSS);
+   msmc_share_all_segments(K2G_MSMC_SEGMENT_PCIE);
+}
+
 int arch_cpu_init(void)
 {
chip_configuration_unlock();
icache_enable();
 
-   msmc_share_all_segments(KS2_MSMC_SEGMENT_TETRIS);
-   msmc_share_all_segments(KS2_MSMC_SEGMENT_NETCP);
-#ifdef KS2_MSMC_SEGMENT_QM_PDSP
-   msmc_share_all_segments(KS2_MSMC_SEGMENT_QM_PDSP);
-#endif
-   msmc_share_all_segments(KS2_MSMC_SEGMENT_PCIE0);
+   if (cpu_is_k2g()) {
+   msmc_k2g_setup();
+   } else {
+   msmc_k2hkle_common_setup();
+   

[U-Boot] [PATCH 2/2] ARM: keystone2: Add missing privilege ID settings

[Nishanth Menon]

Add missing Privilege ID settings for KS2 SoCs.

Based on:
K2H/K: Table 6-7. Privilege ID Settings from SPRS866E (Nov 2013)
  http://www.ti.com/lit/ds/symlink/66ak2h14.pdf (page 99)
K2L: Table 7-7. Privilege ID Settings from SPRS930 (April 2015)
  http://www.ti.com/lit/ds/symlink/66ak2l06.pdf (page 71)
K2E: Table 7-7. Privilege ID Settings from SPRS865D (Mar 2015)
  http://www.ti.com/lit/ds/symlink/66ak2e05.pdf (page 75)
K2G: Table 3-16. PrivIDs from SPRUHY8 (Jan 2016)
  http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf (page 238)

Overall mapping:
---+---+---+---+-
PrivID | KS2H/K| K2L   | K2E   | K2G
---+---+---+---+-
0  | C66x 0| C66x 0| C66x 0| C66x 0
1  | C66x 1| C66x 1| Reserved  | ARM
2  | C66x 2| C66x 2| Reserved  | ICSS0
3  | C66x 3| C66x 3| Reserved  | ICSS1
4  | C66x 4| Reserved  | Reserved  | NETCP
5  | C66x 5| Reserved  | Reserved  | CPIE
6  | C66x 6| Reserved  | Reserved  | USB
7  | C66x 7| Reserved  | Reserved  | Reserved
8  | ARM   | ARM   | ARM   | MLB
9  | NetCP | NetCP | NetCP | PMMC
10 | QM_PDSP   | QM_PDSP   | QM_PDSP   | DSS
11 | PCIe_0| PCIe_0| PCIe_0| MMC
12 | DEBUG/DAP | DEBUG/DAP | DEBUG/DAP | DEBUG/DAP
13 | Reserved  | Reserved  | PCIe_1| Reserved
14 | HyperLink | PCIe_1| HyperLink | Reserved
15 | Reserved  | Reserved  | TSIP  | Reserved
---+---+---+---+-

NOTE: Few of these might have default configurations, however,
since most are software configurable, it is better to explicitly
configure the system to have a known default state.

Without programming these, we end up seeing lack of coherency on certain
peripherals resulting in inexplicable failures (such as USB peripheral's
DMA data not appearing on ARM etc and weird workarounds being done by
drivers including cache flushes which tend to have system wide
performance impact).

By marking these segments as shared, we also ensure SoC wide coherency
is enabled.

Reported-by: Bin Liu 
Signed-off-by: Nishanth Menon 
---
 arch/arm/mach-keystone/include/mach/hardware.h | 23 ++
 arch/arm/mach-keystone/init.c  | 32 +-
 2 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
b/arch/arm/mach-keystone/include/mach/hardware.h
index dd9268fbf209..38d019056a29 100644
--- a/arch/arm/mach-keystone/include/mach/hardware.h
+++ b/arch/arm/mach-keystone/include/mach/hardware.h
@@ -216,22 +216,45 @@ typedef volatile unsigned int   *dv_reg_p;
 #define KS2_MSMC_CTRL_BASE 0x0bc0
 #define KS2_MSMC_DATA_BASE 0x0c00
 
+/* KS2 Generic Privilege ID Settings for MSMC2 */
+#define KS2_MSMC_SEGMENT_C6X_0 0
+#define KS2_MSMC_SEGMENT_C6X_1 1
+#define KS2_MSMC_SEGMENT_C6X_2 2
+#define KS2_MSMC_SEGMENT_C6X_3 3
+#define KS2_MSMC_SEGMENT_C6X_4 4
+#define KS2_MSMC_SEGMENT_C6X_5 5
+#define KS2_MSMC_SEGMENT_C6X_6 6
+#define KS2_MSMC_SEGMENT_C6X_7 7
+
+#define KS2_MSMC_SEGMENT_DEBUG 12
+
 /* KS2 HK/L/E MSMC PRIVIDs  for MSMC2 */
 #define K2HKLE_MSMC_SEGMENT_ARM8
 #define K2HKLE_MSMC_SEGMENT_NETCP  9
 #define K2HKLE_MSMC_SEGMENT_QM_PDSP10
 #define K2HKLE_MSMC_SEGMENT_PCIE0  11
 
+/* K2HK specific Privilege ID Settings */
+#define K2HKE_MSMC_SEGMENT_HYPERLINK   14
+
 /* K2L specific Privilege ID Settings */
 #define K2L_MSMC_SEGMENT_PCIE1 14
 
 /* K2E specific Privilege ID Settings */
 #define K2E_MSMC_SEGMENT_PCIE1 13
+#define K2E_MSMC_SEGMENT_TSIP  15
 
 /* K2G specific Privilege ID Settings */
 #define K2G_MSMC_SEGMENT_ARM   1
+#define K2G_MSMC_SEGMENT_ICSS0 2
+#define K2G_MSMC_SEGMENT_ICSS1 3
 #define K2G_MSMC_SEGMENT_NSS   4
 #define K2G_MSMC_SEGMENT_PCIE  5
+#define K2G_MSMC_SEGMENT_USB   6
+#define K2G_MSMC_SEGMENT_MLB   8
+#define K2G_MSMC_SEGMENT_PMMC  9
+#define K2G_MSMC_SEGMENT_DSS   10
+#define K2G_MSMC_SEGMENT_MMC   11
 
 /* MSMC segment size shift bits */
 #define KS2_MSMC_SEG_SIZE_SHIFT12
diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index 2368315ff68c..3b6d5efce1a1 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -98,29 +98,57 @@ static void config_pcie_mode(int pcie_port,  enum pci_mode 
mode)
 
 static void msmc_k2hkle_common_setup(void)
 {
+   msmc_share_all_segments(KS2_MSMC_SEGMENT_C6X_0);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
 #ifdef KS2_MSMC_SEGMENT_QM_PDSP
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
 #endif

[U-Boot] [PATCH 0/2] ARM: keystone2: Fix missing privilege ID

[Nishanth Menon]

Looks like Keystone2 platform may have quite a few missing
configurations for various SoC variants. We need mark each of these
id as shared in corresponding registers as well, without doing this,
drivers fail inexplicably since the drivers seem to expect SoC wide
coherency capability - which needs to be configured explicitly.

Bootlog:
  k2g: http://pastebin.ubuntu.com/15480089/
  k2hk: http://pastebin.ubuntu.com/15480090/

also tested on an slightly older bootloader on K2E/K2L as well:
k2g: http://pastebin.ubuntu.com/15475588/
k2hk: http://pastebin.ubuntu.com/15475589/
k2l: http://pastebin.ubuntu.com/15478358/
k2e: http://pastebin.ubuntu.com/15478332/

This series is based on:
  master   0764f24ae6bc net: Move CONFIG_RTL8169 to Kconfig

NOTE: K2G still requires additional patches for fixing NAND to prevent
data abort being registered early in the boot by u-boot wrong access
to GPMC. (testing was performed using out-of-tree solution for this)

Nishanth Menon (2):
  ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery
  ARM: keystone2: Add missing privilege ID settings

 arch/arm/mach-keystone/include/mach/hardware-k2e.h |  3 -
 arch/arm/mach-keystone/include/mach/hardware-k2l.h |  3 -
 arch/arm/mach-keystone/include/mach/hardware.h | 50 ---
 arch/arm/mach-keystone/init.c  | 73 +++---
 4 files changed, 106 insertions(+), 23 deletions(-)

-- 
2.8.0.rc3

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[Chin Liang See]

On Mon, 2016-03-21 at 23:45 +0800, Chin Liang See wrote:
> On Mon, 2016-03-21 at 22:05 +0800, Chin Liang See wrote:
> > On Fri, 2016-03-04 at 20:03 +0100, Marek Vasut wrote:
> > > On 03/04/2016 05:06 PM, Dinh Nguyen wrote:
> > > > On 03/02/2016 05:24 PM, Marek Vasut wrote:

[..]

> > > > > Well, that's our usual USB/QSPI cache issue that's tormenting
> > > > > your soul.
> > > > > CCing Chin ;-)
> > > > > 
> > > > > Does the issue by any chance magically disappear if you apply
> > > > > this patch:
> > > > > 
> > > > > diff --git a/arch/arm/include/asm/system.h
> > > > > b/arch/arm/include/asm/system.h
> > > > > index 026e7ef..06802c6 100644
> > > > > --- a/arch/arm/include/asm/system.h
> > > > > +++ b/arch/arm/include/asm/system.h
> > > > > @@ -274,7 +274,7 @@ static inline void set_dacr(unsigned int
> > > > > val)
> > > > > 
> > > > >  /* options available for data cache on each page */
> > > > >  enum dcache_option {
> > > > > -   DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK |
> > > > > TTB_SECT,
> > > > > +   DCACHE_OFF = TTB_SECT_S_MASK | TTB_SECT_DOMAIN(0) |
> > > > > TTB_SECT_XN_MASK | TTB_SECT,
> > > > > DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
> > > > > DCACHE_WRITEBACK = DCACHE_WRITETHROUGH |
> > > > > TTB_SECT_B_MASK,
> > > > > DCACHE_WRITEALLOC = DCACHE_WRITEBACK |
> > > > > TTB_SECT_TEX(1),
> > > > > 
> > > > 
> > > > Yes, this patch fixes USB with dcache left on.
> > > 
> > > Except that it doesn't fix anything, it just makes the system
> > > slower
> > > by
> > > setting the S bit :-/ So this is not a fix :-(
> > 
> > Sorry for away for a while as busy with some critical issues. 
> > 
> > Finally relooking back on this. I notice that with SanDisk Cruzer
> > Blade
> > pendrive, U-Boot 2013.01.01 can detect it while latest cannot. The
> > dcache disablement at latest U-Boot doesn't help.
> > 
> > With that, I compared a bunch of registers from clocks, sysmgr,
> > SCTLR,
> > ATCLR and USB1 too. I noticed they are similar except the
> > usb1.globgrp.gusbcfg.ulpiextvbusdrv. The latest U-Boot is
> > indicating
> > external supply (address 0xffb4000c return value 0x00101710) while
> > working 2013.01.01 indicating internal charge pump (return value
> > 0x1710)
> > 
> > Wonder you guys are seeing the same too? Will dig more about this.
> > FYI,
> > I tried to add lot of delay within dwc2.c but doesn't help at all.
> > 
> 
> While modifying the USB power control of the code, I noticed the
> patch
> made by Dinh is not there. Just realize the git clone through http
> from
> main git doesn't work. I was able to clone but getting older version.
> 
> With getting the latest code, all my pendrive now can works with
> dcache
> off. Its easier now as I can get consistent behaviour compared
> previously. With that, dcache investigation for tomorrow then
> 
> Thanks
> Chin Liang
> 

Spent more time on the dcache + USB issue today. Narrow down to below
patch which can make all my USB pendrives work with dcache enabled. But
still need to understand further as not in depth familiar with dwc2.
Probably this might ring a bell to you guys?


diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index b2f4bc6..b11d8d7 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -776,6 +776,7 @@ static int transfer_chunk(struct dwc2_hc_regs
*hc_regs, void *aligned_buffer,
   (num_packets << DWC2_HCTSIZ_PKTCNT_OFFSET) |
   (*pid << DWC2_HCTSIZ_PID_OFFSET),
   _regs->hctsiz);
+   udelay(2);

if (!in && xfer_len) {
memcpy(aligned_buffer, buffer, xfer_len);


Thanks
Chin Liang

> 
> > Thanks
> > Chin Liang
> > 
> > 
> > 
> > > 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: kirkwood_spi: Add support for multiple chip-selects on MVEBU

[Stefan Roese]

Hi Jagan,

please excuse the long delay here. Some comments below.

On 12.02.2016 21:27, Jagan Teki wrote:

On 12 February 2016 at 18:15, Stefan Roese  wrote:

Currently only chip-select 0 is supported by the kirkwood SPI driver.
The Armada XP / 38x SoCs also use this driver and support multiple chip
selects. This patch adds support for multiple CS on MVEBU.

The register definitions are restructured a bit with this patch. Grouping
them to the corresponding registers.

Signed-off-by: Stefan Roese 
Cc: Luka Perkov 
Cc: Jagan Teki 
---
  arch/arm/include/asm/arch-mvebu/spi.h | 17 -
  drivers/spi/kirkwood_spi.c|  6 ++
  2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-mvebu/spi.h 
b/arch/arm/include/asm/arch-mvebu/spi.h
index e512dce..4b66499 100644
--- a/arch/arm/include/asm/arch-mvebu/spi.h
+++ b/arch/arm/include/asm/arch-mvebu/spi.h
@@ -32,13 +32,15 @@ struct kwspi_registers {
  #define SCK_MPP10  (1 << 1)
  #define MISO_MPP11 (1 << 2)

+/* Control Register */
+#define KWSPI_CSN_ACT  (1 << 0) /* Activates serial memory interface */
+#define KWSPI_SMEMRDY  (1 << 1) /* SerMem Data xfer ready */
+#define KWSPI_CS_SHIFT 2   /* chip select shift */
+#define KWSPI_CS_MASK  0x7 /* chip select mask */
+
+/* Configuration Register */
  #define KWSPI_CLKPRESCL_MASK   0x1f
  #define KWSPI_CLKPRESCL_MIN0x12
-#define KWSPI_CSN_ACT  1 /* Activates serial memory interface */
-#define KWSPI_SMEMRDY  (1 << 1) /* SerMem Data xfer ready */
-#define KWSPI_IRQUNMASK1 /* unmask SPI interrupt */
-#define KWSPI_IRQMASK  0 /* mask SPI interrupt */
-#define KWSPI_SMEMRDIRQ1 /* SerMem data xfer ready irq */
  #define KWSPI_XFERLEN_1BYTE0
  #define KWSPI_XFERLEN_2BYTE(1 << 5)
  #define KWSPI_XFERLEN_MASK (1 << 5)
@@ -47,6 +49,11 @@ struct kwspi_registers {
  #define KWSPI_ADRLEN_3BYTE (2 << 8)
  #define KWSPI_ADRLEN_4BYTE (3 << 8)
  #define KWSPI_ADRLEN_MASK  (3 << 8)
+
+#define KWSPI_IRQUNMASK1 /* unmask SPI interrupt */
+#define KWSPI_IRQMASK  0 /* mask SPI interrupt */
+#define KWSPI_SMEMRDIRQ1 /* SerMem data xfer ready irq */
+
  #define KWSPI_TIMEOUT  1

  #endif /* __KW_SPI_H__ */
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index 7890796..fa30be4 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -280,6 +280,12 @@ static int mvebu_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
 struct udevice *bus = dev->parent;
 struct mvebu_spi_platdata *plat = dev_get_platdata(bus);

+#ifdef CONFIG_ARCH_MVEBU
+   clrsetbits_le32(>spireg->ctrl,
+   KWSPI_CS_MASK << KWSPI_CS_SHIFT,
+   spi_chip_select(dev) << KWSPI_CS_SHIFT);
+#endif


This looks clearing a desired cs from 'sf probe' why is this need
here?


Its not clearing a CS but configuring the CS number in the CTRL
register. This configured CS number will get enabled or disabled
exactly the same way as when its zero (without this patch) in
the existing spi_cs_activate/deactivate functions


I think we can do the desired cs activate or deactivate through
existing spi_cs_activate/deactivate functions itself.


This is exactly what this patch does. The CS number is
configured with the clrsetbits_le32() call above. And activated /
deactivated in the existing functions.

Or do you mean something else?

Thanks,
Stefan

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

[U-Boot] POST WORD for socfpga platform

[Abhishek Madhyastha]

Hi,

I'm working on enabling the POST feature for the socfpga cyclone v platform
but I'm unable to define a proper address for the post word.

>From what I've read, I believe this word needs to point to a location on
the on chip RAM, especially for ARM based architectures.
Ref: http://lists.denx.de/pipermail/u-boot/2011-September/100138.html

While referring to other architectures/implementations, I see that a
particular space on the on chip RAM is reserved for the POST word.

On the socfpga platform, in ./include/configs/socfpga_common.h

CONFIG_SYS_INIT_RAM_ADDR points to 0x

CONFIG_SYS_INIT_RAM_SIZE points to (0x1 - 0x100)   where 0x100
is space reserved at back of scratch RAM for debug info.

CONFIG_SYS_INIT_SP_ADDR points to (CONFIG_SYS_INIT_RAM_ADDR +
CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)


So, the stack pointer resides at this address. I tried modifying this by
changing


CONFIG_SYS_INIT_RAM_SIZE to (0x1 - 0x104)and defining

CONFIG_SYS_POST_WORD_ADDR as   (CONFIG_SYS_INIT_RAM_ADDR +
CONFIG_SYS_INIT_RAM_SIZE + 0x100)

so that the space at the end would be reserved for the post word.


However, doing this makes uboot to get stuck at board_init_f which means it
doesn't go past the relocate_code.

Could someone explain how I can implement this feature?


Thanks,
Abhishek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5 03/14] fsl: ls-ch3: Add new header for Secure Boot

[Saksham Jain]

For Secure Boot, a header is used to identify key table, signature and
image address. For Ls-Ch3, there is a new header structure being used.

Currently Key extension (IE) feature is not supported. Single Key
feature is not supported. Keys must be in table format. Hence, SRK (Key
table) is by default currently always present. Max Key number has
increase from 4 to 8. 8th Key is irrevocable. A New Barker Code is being
used.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message
Changes for v5:
- Cleaned up commit message

 arch/arm/include/asm/arch-fsl-layerscape/config.h |  3 +-
 arch/arm/include/asm/fsl_secure_boot.h|  4 ++
 board/freescale/common/fsl_validate.c | 35 +++--
 include/fsl_secboot_err.h |  3 ++
 include/fsl_validate.h| 60 ---
 5 files changed, 91 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 34851a9..0445dbd 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -79,7 +79,8 @@
 /* Security Monitor */
 #define CONFIG_SYS_FSL_SEC_MON_LE
 
-
+/* Secure Boot */
+#define CONFIG_ESBC_HDR_LS
 
 /* Cache Coherent Interconnect */
 #define CCI_MN_BASE0x0400
diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index a32a1d7..4eb3b15 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -35,9 +35,13 @@
  * The feature is only applicable in case of NOR boot and is
  * not applicable in case of RAMBOOT (NAND, SD, SPI).
  */
+#ifndef CONFIG_ESBC_HDR_LS
+/* Current Key EXT feature not available in LS ESBC Header */
 #define CONFIG_FSL_ISBC_KEY_EXT
 #endif
 
+#endif
+
 #ifdef CONFIG_LS1043A
 /* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit */
 #define CONFIG_ESBC_ADDR_64BIT
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 8fd6dd6..c12b9c9 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -35,7 +35,13 @@ static const u8 hash_identifier[] = { 0x30, 0x31, 0x30, 
0x0d, 0x06, 0x09, 0x60,
};
 
 static u8 hash_val[SHA256_BYTES];
+
+#ifdef CONFIG_ESBC_HDR_LS
+/* New Barker Code for LS ESBC Header */
+static const u8 barker_code[ESBC_BARKER_LEN] = { 0x12, 0x19, 0x20, 0x01 };
+#else
 static const u8 barker_code[ESBC_BARKER_LEN] = { 0x68, 0x39, 0x27, 0x81 };
+#endif
 
 void branch_to_self(void) __attribute__ ((noreturn));
 
@@ -157,10 +163,15 @@ static int get_ie_info_addr(u32 *ie_addr)
 /* This function checks srk_table_flag in header and set/reset srk_flag.*/
 static u32 check_srk(struct fsl_secboot_img_priv *img)
 {
+#ifdef CONFIG_ESBC_HDR_LS
+   /* In LS, No SRK Flag as SRK is always present*/
+   return 1;
+#else
if (img->hdr.len_kr.srk_table_flag & SRK_FLAG)
return 1;
 
return 0;
+#endif
 }
 
 /* This function returns ospr's key_revoc values.*/
@@ -223,6 +234,7 @@ static u32 read_validate_srk_tbl(struct 
fsl_secboot_img_priv *img)
 }
 #endif
 
+#ifndef CONFIG_ESBC_HDR_LS
 static u32 read_validate_single_key(struct fsl_secboot_img_priv *img)
 {
struct fsl_secboot_img_hdr *hdr = >hdr;
@@ -238,6 +250,7 @@ static u32 read_validate_single_key(struct 
fsl_secboot_img_priv *img)
 
return 0;
 }
+#endif /* CONFIG_ESBC_HDR_LS */
 
 #if defined(CONFIG_FSL_ISBC_KEY_EXT)
 static u32 read_validate_ie_tbl(struct fsl_secboot_img_priv *img)
@@ -388,6 +401,7 @@ void fsl_secboot_handle_error(int error)
case ERROR_ESBC_CLIENT_HEADER_SIG_KEY_MOD:
case ERROR_ESBC_CLIENT_HEADER_SG_ESBC_EP:
case ERROR_ESBC_CLIENT_HEADER_SG_ENTIRES_BAD:
+   case ERROR_KEY_TABLE_NOT_FOUND:
 #ifdef CONFIG_KEY_REVOCATION
case ERROR_ESBC_CLIENT_HEADER_KEY_REVOKED:
case ERROR_ESBC_CLIENT_HEADER_INVALID_SRK_NUM_ENTRY:
@@ -536,11 +550,18 @@ static int calc_esbchdr_esbc_hash(struct 
fsl_secboot_img_priv *img)
if (!key_hash && check_ie(img))
key_hash = 1;
 #endif
-   if (!key_hash)
+#ifndef CONFIG_ESBC_HDR_LS
+/* No single key support in LS ESBC header */
+   if (!key_hash) {
ret = algo->hash_update(algo, ctx,
img->img_key, img->hdr.key_len, 0);
+   key_hash = 1;
+   }
+#endif
if (ret)
return ret;
+   if (!key_hash)
+   return ERROR_KEY_TABLE_NOT_FOUND;
 
/* Update hash for actual Image */
ret = algo->hash_update(algo, ctx,
@@ -626,8 +647,6 @@ static int read_validate_esbc_client_header(struct 
fsl_secboot_img_priv *img)
u8 

[U-Boot] [PATCH v5 09/14] armv8: fsl-lsch3: Disable SMMU during Secure Boot

[Saksham Jain]

During secure boot, SMMU is enabled on POR by SP bootrom. SMMU needs
to be put in Bypass mode in uboot to enable CAAM transcations to pass
through.

During Nonsecure Boot, SP BootROM doesn't enable SMMU and at reset
SMMU is in bypass mode.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- No changes
Changes for v5:
- Cleaned up commit message

 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 18 +-
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 15 +++
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 213ce3a..a39d08d 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -151,7 +151,14 @@ static void erratum_a009203(void)
 #endif
 #endif
 }
-
+void bypass_smmu(void)
+{
+   u32 val;
+   val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_SCR0, val);
+   val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_NSCR0, val);
+}
 void fsl_lsch3_early_init_f(void)
 {
erratum_a008751();
@@ -160,6 +167,15 @@ void fsl_lsch3_early_init_f(void)
erratum_a009203();
erratum_a008514();
erratum_a008336();
+#ifdef CONFIG_CHAIN_OF_TRUST
+   /* In case of Secure Boot, the IBR configures the SMMU
+   * to allow only Secure transactions.
+   * SMMU must be reset in bypass mode.
+   * Set the ClientPD bit and Clear the USFCFG Bit
+   */
+   if (fsl_check_boot_mode_secure() == 1)
+   bypass_smmu();
+#endif
 }
 
 #ifdef CONFIG_SCSI_AHCI_PLAT
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 1fc51e0..06d4856 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -83,6 +83,21 @@
 /* Security Monitor */
 #define CONFIG_SYS_SEC_MON_ADDR(CONFIG_SYS_IMMR + 0x00e9)
 
+/* MMU 500 */
+#define SMMU_SCR0  (SMMU_BASE + 0x0)
+#define SMMU_SCR1  (SMMU_BASE + 0x4)
+#define SMMU_SCR2  (SMMU_BASE + 0x8)
+#define SMMU_SACR  (SMMU_BASE + 0x10)
+#define SMMU_IDR0  (SMMU_BASE + 0x20)
+#define SMMU_IDR1  (SMMU_BASE + 0x24)
+
+#define SMMU_NSCR0 (SMMU_BASE + 0x400)
+#define SMMU_NSCR2 (SMMU_BASE + 0x408)
+#define SMMU_NSACR (SMMU_BASE + 0x410)
+
+#define SCR0_CLIENTPD_MASK 0x0001
+#define SCR0_USFCFG_MASK   0x0400
+
 
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
-- 
1.8.1.4

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

[U-Boot] [PATCH v5 08/14] ls2080: Add config for endianess of CCSR GUR

[Saksham Jain]

The GUR (DCFG) registers in CCSR space are in Little Endian format for
ls2080. Defined a config CONFIG_SYS_FSL_CCSR_GUR_LE in
arch/arm/include/asm/arch-fsl-layerscape/config.h

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- No changes
Changes for v5:
- Cleaned up commit message

 arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 0445dbd..057912f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -82,6 +82,9 @@
 /* Secure Boot */
 #define CONFIG_ESBC_HDR_LS
 
+/* DCFG - GUR */
+#define CONFIG_SYS_FSL_CCSR_GUR_LE
+
 /* Cache Coherent Interconnect */
 #define CCI_MN_BASE0x0400
 #define CCI_MN_RNF_NODEID_LIST 0x180
-- 
1.8.1.4

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

[U-Boot] [PATCH v5 11/14] crypto/fsl: Make CAAM transactions cacheable

[Saksham Jain]

This commit solves CAAM coherency issue on ls2080. When Caches are
enabled and CAAM's DMA's AXI transcations are not made cacheable, Core
reads/write data from/to Caches and CAAM does from Main Memory. This
forces data flushes to synchronize various data structures. But even if
any data in proximity of these structures is read by core, these
structures again are fetched in caches.

To avoid this problem, either all the data that CAAM accesses can be
made cache line aligned or CAAM transcations can be made cacheable.

So, this commit makes CAAM transcations as Write Back with Write and
Read Allocate.

Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message
Changes for v5:
- Cleaned up commit message

 drivers/crypto/fsl/jr.c | 13 +
 drivers/crypto/fsl/jr.h |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index b766470..894fa03 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -543,7 +543,20 @@ int sec_init(void)
uint32_t liodn_s;
 #endif
 
+   /*
+* Modifying CAAM Read/Write Attributes
+* For LS2080A and LS2085A
+* For AXI Write - Cacheable, Write Back, Write allocate
+* For AXI Read - Cacheable, Read allocate
+* Only For LS2080a and LS2085a, to solve CAAM coherency issues
+*/
+#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+   mcr = (mcr & ~MCFGR_AWCACHE_MASK) | (0xb << MCFGR_AWCACHE_SHIFT);
+   mcr = (mcr & ~MCFGR_ARCACHE_MASK) | (0x6 << MCFGR_ARCACHE_SHIFT);
+#else
mcr = (mcr & ~MCFGR_AWCACHE_MASK) | (0x2 << MCFGR_AWCACHE_SHIFT);
+#endif
+
 #ifdef CONFIG_PHYS_64BIT
mcr |= (1 << MCFGR_PS_SHIFT);
 #endif
diff --git a/drivers/crypto/fsl/jr.h b/drivers/crypto/fsl/jr.h
index 545d964..1642dbb 100644
--- a/drivers/crypto/fsl/jr.h
+++ b/drivers/crypto/fsl/jr.h
@@ -23,6 +23,9 @@
 #define MCFGR_PS_SHIFT  16
 #define MCFGR_AWCACHE_SHIFT8
 #define MCFGR_AWCACHE_MASK (0xf << MCFGR_AWCACHE_SHIFT)
+#define MCFGR_ARCACHE_SHIFT12
+#define MCFGR_ARCACHE_MASK (0xf << MCFGR_ARCACHE_SHIFT)
+
 #define JR_INTMASK   0x0001
 #define JRCR_RESET  0x01
 #define JRINT_ERR_HALT_INPROGRESS   0x4
-- 
1.8.1.4

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

[U-Boot] [PATCH 2/6 v2] net: mvpp2.c: Add Marvell mvpp2 network driver for Armada 375

[Stefan Roese]

This patch adds support for the mvpp2 ethernet controller which is integrated
in the Marvell Armada 375 SoC. This port is based on the Linux driver (v4.4),
which has been stripped of the in U-Boot unused portions.

Tested on the Marvell Armada 375 eval board db-88f6720.

Signed-off-by: Stefan Roese 
Cc: Luka Perkov 
Cc: Joe Hershberger 
---
v2:
- Removed check for PHYLIB
- Used U-Boot defines instead of Linux ones where possible
- Added PROT_PPP_SES and PROT_IPV6 to include/net.h
- Introduced probe function for the MISC parent driver, which
  now handles all the "do-once" things
  
 drivers/net/Kconfig  |8 +
 drivers/net/Makefile |1 +
 drivers/net/mvpp2.c  | 4199 ++
 include/net.h|2 +
 4 files changed, 4210 insertions(+)
 create mode 100644 drivers/net/mvpp2.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2a229b8..d9dda16 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -94,6 +94,14 @@ config ETH_DESIGNWARE
  100Mbit and 1 Gbit operation. You must enable CONFIG_PHYLIB to
  provide the PHY (physical media interface).
 
+config MVPP2
+   bool "Marvell Armada 375 network interface support"
+   depends on ARMADA_375
+   select PHYLIB
+   help
+ This driver supports the network interface units in the
+ Marvell ARMADA 375 SoC.
+
 config PCH_GBE
bool "Intel Platform Controller Hub EG20T GMAC driver"
depends on DM_ETH && DM_PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 33a81ee..fbedd04 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
 obj-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o
 obj-$(CONFIG_MVGBE) += mvgbe.o
 obj-$(CONFIG_MVNETA) += mvneta.o
+obj-$(CONFIG_MVPP2) += mvpp2.o
 obj-$(CONFIG_NATSEMI) += natsemi.o
 obj-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
 obj-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
new file mode 100644
index 000..897e51b
--- /dev/null
+++ b/drivers/net/mvpp2.c
@@ -0,0 +1,4199 @@
+/*
+ * Driver for Marvell PPv2 network controller for Armada 375 SoC.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Marcin Wojtas 
+ *
+ * U-Boot version:
+ * Copyright (C) 2016 Stefan Roese 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Some linux -> U-Boot compatibility stuff */
+#define netdev_err(dev, fmt, args...)  \
+   printf(fmt, ##args)
+#define netdev_warn(dev, fmt, args...) \
+   printf(fmt, ##args)
+#define netdev_info(dev, fmt, args...) \
+   printf(fmt, ##args)
+#define netdev_dbg(dev, fmt, args...)  \
+   printf(fmt, ##args)
+
+#define ETH_ALEN   6   /* Octets in one ethernet addr  */
+
+#define __verify_pcpu_ptr(ptr) \
+do {   \
+   const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;\
+   (void)__vpp_verify; \
+} while (0)
+
+#define VERIFY_PERCPU_PTR(__p) \
+({ \
+   __verify_pcpu_ptr(__p); \
+   (typeof(*(__p)) __kernel __force *)(__p);   \
+})
+
+#define per_cpu_ptr(ptr, cpu)  ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
+#define smp_processor_id() 0
+#define num_present_cpus() 1
+#define for_each_present_cpu(cpu)  \
+   for ((cpu) = 0; (cpu) < 1; (cpu)++)
+
+#define NET_SKB_PADmax(32, MVPP2_CPU_D_CACHE_LINE_SIZE)
+
+#define CONFIG_NR_CPUS 1
+#define ETH_HLEN   ETHER_HDR_SIZE  /* Total octets in header */
+
+/* 2(HW hdr) 14(MAC hdr) 4(CRC) 32(extra for cache prefetch) */
+#define WRAP   (2 + ETH_HLEN + 4 + 32)
+#define MTU1500
+#define RX_BUFFER_SIZE (ALIGN(MTU + WRAP, ARCH_DMA_MINALIGN))
+
+#define MVPP2_SMI_TIMEOUT  1
+
+/* RX Fifo Registers */
+#define MVPP2_RX_DATA_FIFO_SIZE_REG(port)  (0x00 + 4 * (port))
+#define MVPP2_RX_ATTR_FIFO_SIZE_REG(port)  (0x20 + 4 * (port))
+#define MVPP2_RX_MIN_PKT_SIZE_REG  0x60
+#define MVPP2_RX_FIFO_INIT_REG 0x64
+
+/* RX DMA Top Registers */
+#define MVPP2_RX_CTRL_REG(port)(0x140 + 4 * (port))

[U-Boot] [PATCH 2/6 v3] net: mvpp2.c: Add Marvell mvpp2 network driver for Armada 375

[Stefan Roese]

This patch adds support for the mvpp2 ethernet controller which is integrated
in the Marvell Armada 375 SoC. This port is based on the Linux driver (v4.4),
which has been stripped of the in U-Boot unused portions.

Tested on the Marvell Armada 375 eval board db-88f6720.

Signed-off-by: Stefan Roese 
Cc: Luka Perkov 
Cc: Joe Hershberger 
---
v3:
- Use priv_auto_alloc for the priv struct of the parent MISC
  driver instead of allocating manually

v2:
- Removed check for PHYLIB
- Used U-Boot defines instead of Linux ones where possible
- Added PROT_PPP_SES and PROT_IPV6 to include/net.h
- Introduced probe function for the MISC parent driver, which
  now handles all the "do-once" things
  
 drivers/net/Kconfig  |8 +
 drivers/net/Makefile |1 +
 drivers/net/mvpp2.c  | 4190 ++
 include/net.h|2 +
 4 files changed, 4201 insertions(+)
 create mode 100644 drivers/net/mvpp2.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2a229b8..d9dda16 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -94,6 +94,14 @@ config ETH_DESIGNWARE
  100Mbit and 1 Gbit operation. You must enable CONFIG_PHYLIB to
  provide the PHY (physical media interface).
 
+config MVPP2
+   bool "Marvell Armada 375 network interface support"
+   depends on ARMADA_375
+   select PHYLIB
+   help
+ This driver supports the network interface units in the
+ Marvell ARMADA 375 SoC.
+
 config PCH_GBE
bool "Intel Platform Controller Hub EG20T GMAC driver"
depends on DM_ETH && DM_PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 33a81ee..fbedd04 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
 obj-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o
 obj-$(CONFIG_MVGBE) += mvgbe.o
 obj-$(CONFIG_MVNETA) += mvneta.o
+obj-$(CONFIG_MVPP2) += mvpp2.o
 obj-$(CONFIG_NATSEMI) += natsemi.o
 obj-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
 obj-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
new file mode 100644
index 000..900a04c
--- /dev/null
+++ b/drivers/net/mvpp2.c
@@ -0,0 +1,4190 @@
+/*
+ * Driver for Marvell PPv2 network controller for Armada 375 SoC.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Marcin Wojtas 
+ *
+ * U-Boot version:
+ * Copyright (C) 2016 Stefan Roese 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Some linux -> U-Boot compatibility stuff */
+#define netdev_err(dev, fmt, args...)  \
+   printf(fmt, ##args)
+#define netdev_warn(dev, fmt, args...) \
+   printf(fmt, ##args)
+#define netdev_info(dev, fmt, args...) \
+   printf(fmt, ##args)
+#define netdev_dbg(dev, fmt, args...)  \
+   printf(fmt, ##args)
+
+#define ETH_ALEN   6   /* Octets in one ethernet addr  */
+
+#define __verify_pcpu_ptr(ptr) \
+do {   \
+   const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;\
+   (void)__vpp_verify; \
+} while (0)
+
+#define VERIFY_PERCPU_PTR(__p) \
+({ \
+   __verify_pcpu_ptr(__p); \
+   (typeof(*(__p)) __kernel __force *)(__p);   \
+})
+
+#define per_cpu_ptr(ptr, cpu)  ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
+#define smp_processor_id() 0
+#define num_present_cpus() 1
+#define for_each_present_cpu(cpu)  \
+   for ((cpu) = 0; (cpu) < 1; (cpu)++)
+
+#define NET_SKB_PADmax(32, MVPP2_CPU_D_CACHE_LINE_SIZE)
+
+#define CONFIG_NR_CPUS 1
+#define ETH_HLEN   ETHER_HDR_SIZE  /* Total octets in header */
+
+/* 2(HW hdr) 14(MAC hdr) 4(CRC) 32(extra for cache prefetch) */
+#define WRAP   (2 + ETH_HLEN + 4 + 32)
+#define MTU1500
+#define RX_BUFFER_SIZE (ALIGN(MTU + WRAP, ARCH_DMA_MINALIGN))
+
+#define MVPP2_SMI_TIMEOUT  1
+
+/* RX Fifo Registers */
+#define MVPP2_RX_DATA_FIFO_SIZE_REG(port)  (0x00 + 4 * (port))
+#define MVPP2_RX_ATTR_FIFO_SIZE_REG(port)  (0x20 + 4 * (port))
+#define MVPP2_RX_MIN_PKT_SIZE_REG  0x60
+#define MVPP2_RX_FIFO_INIT_REG 0x64
+

[U-Boot] [PATCH v5 13/14] SECURE BOOT: Halt execution when secure boot fail

[Saksham Jain]

In case of fatal failure during secure boot execution (e.g. header not
found), it is needed that the execution stops. Earlier, we assert reset
request in case in case of failure. But if the RESET_REQ is not tied off
to HRESET, this allows the execution to continue.

This can either be taken care in bootscript (Execute esbc_halt command
in case of image verification process) or it can be taken care in Uboot
Code. In this commit, doing the latter via esbc_halt().

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Chnages for v4:
- Cleaned up commit message
Changes for v5:
- Cleaned up commit message

 board/freescale/common/cmd_esbc_validate.c | 2 +-
 board/freescale/common/fsl_validate.c  | 5 +
 include/fsl_validate.h | 3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/board/freescale/common/cmd_esbc_validate.c 
b/board/freescale/common/cmd_esbc_validate.c
index dfa3e21..375bc24 100644
--- a/board/freescale/common/cmd_esbc_validate.c
+++ b/board/freescale/common/cmd_esbc_validate.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 
-static int do_esbc_halt(cmd_tbl_t *cmdtp, int flag, int argc,
+int do_esbc_halt(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
if (fsl_check_boot_mode_secure() == 0) {
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index c12b9c9..95059c7 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -325,6 +325,8 @@ static void fsl_secboot_header_verification_failure(void)
 
printf("Generating reset request\n");
do_reset(NULL, 0, 0, NULL);
+   /* If reset doesn't coocur, halt execution */
+   do_esbc_halt(NULL, 0, 0, NULL);
 }
 
 /*
@@ -355,6 +357,9 @@ static void fsl_secboot_image_verification_failure(void)
 
printf("Generating reset request\n");
do_reset(NULL, 0, 0, NULL);
+   /* If reset doesn't coocur, halt execution */
+   do_esbc_halt(NULL, 0, 0, NULL);
+
} else {
change_sec_mon_state(HPSR_SSM_ST_TRUST,
 HPSR_SSM_ST_NON_SECURE);
diff --git a/include/fsl_validate.h b/include/fsl_validate.h
index f812c1a..ff6f6b7 100644
--- a/include/fsl_validate.h
+++ b/include/fsl_validate.h
@@ -242,6 +242,9 @@ struct fsl_secboot_img_priv {
uint32_t img_size;  /* ESBC Image Size */
 };
 
+int do_esbc_halt(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[]);
+
 int fsl_secboot_validate(uintptr_t haddr, char *arg_hash_str,
uintptr_t img_loc);
 int fsl_secboot_blob_encap(cmd_tbl_t *cmdtp, int flag, int argc,
-- 
1.8.1.4

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

[U-Boot] [PATCH v5 04/14] ls2080: Add Secure Boot support

[Saksham Jain]

Sec_init has been called in the starting to initialize SEC Block (CAAM)
which will be used for Secure Boot validation later for both ls2080a
qds and rdb. 64-bit address in ESBC Header has been enabled as this SoC
is based on armv8. Secure Boot defconfigs created for boards (NOR Boot).

Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message
Changes for v5:
- Cleaned up commit message
- Added new configs in defconfigs as per new intermediate patches

 arch/arm/include/asm/fsl_secure_boot.h   |  9 +++--
 board/freescale/ls2080aqds/MAINTAINERS   |  6 ++
 board/freescale/ls2080aqds/ls2080aqds.c  |  5 -
 board/freescale/ls2080ardb/MAINTAINERS   |  6 ++
 board/freescale/ls2080ardb/ls2080ardb.c  |  5 -
 configs/ls2080aqds_SECURE_BOOT_defconfig | 20 
 configs/ls2080ardb_SECURE_BOOT_defconfig | 20 
 configs/ls2085aqds_SECURE_BOOT_defconfig | 20 
 configs/ls2085ardb_SECURE_BOOT_defconfig | 20 
 include/configs/ls2080aqds.h |  2 ++
 include/configs/ls2080ardb.h |  2 ++
 11 files changed, 111 insertions(+), 4 deletions(-)
 create mode 100644 configs/ls2080aqds_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2080ardb_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2085aqds_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2085ardb_SECURE_BOOT_defconfig

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 4eb3b15..b745194 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -18,7 +18,9 @@
 #ifdef CONFIG_CHAIN_OF_TRUST
 #define CONFIG_CMD_ESBC_VALIDATE
 #define CONFIG_CMD_BLOB
+#define CONFIG_CMD_HASH
 #define CONFIG_FSL_SEC_MON
+#define CONFIG_SHA_HW_ACCEL
 #define CONFIG_SHA_PROG_HW_ACCEL
 #define CONFIG_RSA_FREESCALE_EXP
 
@@ -42,8 +44,11 @@
 
 #endif
 
-#ifdef CONFIG_LS1043A
-/* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit */
+#if defined(CONFIG_LS1043A) || defined(CONFIG_LS2080A) ||\
+   defined(CONFIG_LS2085A)
+/* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit
+ * Similiarly for LS2080 and LS2085
+ */
 #define CONFIG_ESBC_ADDR_64BIT
 #endif
 
diff --git a/board/freescale/ls2080aqds/MAINTAINERS 
b/board/freescale/ls2080aqds/MAINTAINERS
index 6f99ad0..558cef1 100644
--- a/board/freescale/ls2080aqds/MAINTAINERS
+++ b/board/freescale/ls2080aqds/MAINTAINERS
@@ -8,3 +8,9 @@ F:  configs/ls2080aqds_defconfig
 F: configs/ls2080aqds_nand_defconfig
 F: configs/ls2085aqds_defconfig
 F: configs/ls2085aqds_nand_defconfig
+
+LS2080A_SECURE_BOOT BOARD
+M: Saksham Jain 
+S: Maintained
+F: configs/ls2080aqds_SECURE_BOOT_defconfig
+F: configs/ls2085aqds_SECURE_BOOT_defconfig
diff --git a/board/freescale/ls2080aqds/ls2080aqds.c 
b/board/freescale/ls2080aqds/ls2080aqds.c
index aa256a2..ab101a4 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../common/qixis.h"
 #include "ls2080aqds_qixis.h"
@@ -248,7 +249,9 @@ int arch_misc_init(void)
 #ifdef CONFIG_FSL_DEBUG_SERVER
debug_server_init();
 #endif
-
+#ifdef CONFIG_FSL_CAAM
+   sec_init();
+#endif
return 0;
 }
 #endif
diff --git a/board/freescale/ls2080ardb/MAINTAINERS 
b/board/freescale/ls2080ardb/MAINTAINERS
index c9f3459..0817711d 100644
--- a/board/freescale/ls2080ardb/MAINTAINERS
+++ b/board/freescale/ls2080ardb/MAINTAINERS
@@ -8,3 +8,9 @@ F:  configs/ls2080ardb_defconfig
 F: configs/ls2080ardb_nand_defconfig
 F: configs/ls2085ardb_defconfig
 F: configs/ls2085ardb_nand_defconfig
+
+LS2080A_SECURE_BOOT BOARD
+M: Saksham Jain 
+S: Maintained
+F: configs/ls2080ardb_SECURE_BOOT_defconfig
+F: configs/ls2085ardb_SECURE_BOOT_defconfig
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index c63b639..0c78a41 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../common/qixis.h"
 #include "ls2080ardb_qixis.h"
@@ -214,7 +215,9 @@ int arch_misc_init(void)
 #ifdef CONFIG_FSL_DEBUG_SERVER
debug_server_init();
 #endif
-
+#ifdef CONFIG_FSL_CAAM
+   sec_init();
+#endif
return 0;
 }
 #endif
diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig 
b/configs/ls2080aqds_SECURE_BOOT_defconfig
new file mode 100644
index 000..408d1ee
--- /dev/null
+++ b/configs/ls2080aqds_SECURE_BOOT_defconfig
@@ -0,0 +1,20 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS2080AQDS=y
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y

[U-Boot] [PATCH v5 07/14] ls2080: Change env variable "fdt_high"

[Saksham Jain]

"fdt_high" env variable has been changed to 0xa000 for ls2080
during Secure Boot. This env_varible is used to specify the upper limit
to be used for copying flat device tree. This address must be visible
to kernel.

The "fdt_high" value has been set during Secure Boot to same value as
it's default value during non-secure boot.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- No changes
Changes for v5:
- Cleaned up commit message

 arch/arm/include/asm/fsl_secure_boot.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 4d04eea..d576f2e 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -52,10 +52,17 @@
 #define CONFIG_ESBC_ADDR_64BIT
 #endif
 
+#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+#define CONFIG_EXTRA_ENV \
+   "setenv fdt_high 0xa000;"   \
+   "setenv initrd_high 0xcfff;"\
+   "setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
+#else
 #define CONFIG_EXTRA_ENV \
"setenv fdt_high 0xcfff;"   \
"setenv initrd_high 0xcfff;"\
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
+#endif
 
 /* Copying Bootscript and Header to DDR from NOR for LS2 and for rest, from
  * Non-XIP Memory (Nand/SD)*/
-- 
1.8.1.4

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

[U-Boot] [PATCH v5 10/14] crypto/fsl: Correct 64-bit Write when MMU disabled

[Saksham Jain]

When MMU is disabled, 64bit Write must be at a memory aligned at 64-bit
Boundary. So, this commit splits the 64-bit write into two 32-bit writes
as the memory location is not guaranteed to be 64-bit aligned. The
alignment exception only occurs when MMU is disabled.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- No changes
Changes for v5:
- Cleaned up commit message

 drivers/crypto/fsl/desc_constr.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/fsl/desc_constr.h b/drivers/crypto/fsl/desc_constr.h
index 2559ccd..db6ddee 100644
--- a/drivers/crypto/fsl/desc_constr.h
+++ b/drivers/crypto/fsl/desc_constr.h
@@ -85,10 +85,9 @@ static inline void append_ptr(u32 *desc, dma_addr_t ptr)
 #ifdef CONFIG_PHYS_64BIT
/* The Position of low and high part of 64 bit address
 * will depend on the endianness of CAAM Block */
-   union ptr_addr_t ptr_addr;
-   ptr_addr.m_halfs.high = (u32)(ptr >> 32);
-   ptr_addr.m_halfs.low = (u32)ptr;
-   *offset = ptr_addr.m_whole;
+   union ptr_addr_t *ptr_addr = (union ptr_addr_t *)offset;
+   ptr_addr->m_halfs.high = (u32)(ptr >> 32);
+   ptr_addr->m_halfs.low = (u32)ptr;
 #else
*offset = ptr;
 #endif
-- 
1.8.1.4

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

[U-Boot] [PATCH v5 01/14] armv8: ls2080: Add SFP Configs for LS2080

[Saksham Jain]

In LS2080, SFP is Little Endian and Verion is 3.4 . The base address is
0x01e80200. SFP will be used in Secure Boot to read fuses.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message
Changes for v5:
- Cleaned up commit message

 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 4 
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 3 +++
 include/fsl_sfp.h  | 3 ++-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 0ef7c9d..380d5ac 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -67,6 +67,10 @@
 /* SMMU Defintions */
 #define SMMU_BASE  0x0500 /* GR0 Base */
 
+/* SFP */
+#define CONFIG_SYS_FSL_SFP_VER_3_4
+#define CONFIG_SYS_FSL_SFP_LE
+
 /* Cache Coherent Interconnect */
 #define CCI_MN_BASE0x0400
 #define CCI_MN_RNF_NODEID_LIST 0x180
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 91f3ce8..f1b021f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -73,6 +73,9 @@
 #define AHCI_BASE_ADDR1(CONFIG_SYS_IMMR + 
0x0220)
 #define AHCI_BASE_ADDR2(CONFIG_SYS_IMMR + 
0x0221)
 
+/* SFP */
+#define CONFIG_SYS_SFP_ADDR(CONFIG_SYS_IMMR + 0x00e80200)
+
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
 #define CONFIG_SYS_PCIE2_ADDR  (CONFIG_SYS_IMMR + 0x250)
diff --git a/include/fsl_sfp.h b/include/fsl_sfp.h
index 353a123..2976a2c 100644
--- a/include/fsl_sfp.h
+++ b/include/fsl_sfp.h
@@ -32,7 +32,8 @@
 /* Number of SRKH registers */
 #define NUM_SRKH_REGS  8
 
-#ifdef CONFIG_SYS_FSL_SFP_VER_3_2
+#ifdefined(CONFIG_SYS_FSL_SFP_VER_3_2) ||  \
+   defined(CONFIG_SYS_FSL_SFP_VER_3_4)
 struct ccsr_sfp_regs {
u32 ospr;   /* 0x200 */
u32 ospr1;  /* 0x204 */
-- 
1.8.1.4

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

[U-Boot] [PATCH v5 02/14] ls2080: Add configs for SEC, SecMon, SRK and DCFG

[Saksham Jain]

For ls2080, Added configs for various IPs used during secure boot.
Added address and endianness for SEC and Security Monitor. SRK are
Fuses in SFP (Fuses for public key's hash). These are stored in Little
Endian format.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
-Cleaned up commit message
Changes for v5:
-Cleaned up commit message

 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 10 ++
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 380d5ac..34851a9 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -70,6 +70,16 @@
 /* SFP */
 #define CONFIG_SYS_FSL_SFP_VER_3_4
 #define CONFIG_SYS_FSL_SFP_LE
+#define CONFIG_SYS_FSL_SRK_LE
+
+/* SEC */
+#define CONFIG_SYS_FSL_SEC_LE
+#define CONFIG_SYS_FSL_SEC_COMPAT  5
+
+/* Security Monitor */
+#define CONFIG_SYS_FSL_SEC_MON_LE
+
+
 
 /* Cache Coherent Interconnect */
 #define CCI_MN_BASE0x0400
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index f1b021f..1fc51e0 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -76,6 +76,14 @@
 /* SFP */
 #define CONFIG_SYS_SFP_ADDR(CONFIG_SYS_IMMR + 0x00e80200)
 
+/* SEC */
+#define CONFIG_SYS_FSL_SEC_ADDR(CONFIG_SYS_IMMR + 0x0700)
+#define CONFIG_SYS_FSL_JR0_ADDR(CONFIG_SYS_IMMR + 0x0701)
+
+/* Security Monitor */
+#define CONFIG_SYS_SEC_MON_ADDR(CONFIG_SYS_IMMR + 0x00e9)
+
+
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
 #define CONFIG_SYS_PCIE2_ADDR  (CONFIG_SYS_IMMR + 0x250)
@@ -204,6 +212,8 @@ struct ccsr_gur {
 #defineFSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_SHIFT  16
 #defineFSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_MASK   0xFF00
 #defineFSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_SHIFT  24
+#define RCW_SB_EN_REG_INDEX9
+#define RCW_SB_EN_MASK 0x0400
 
u8  res_180[0x200-0x180];
u32 scratchrw[32];  /* Scratch Read/Write */
-- 
1.8.1.4

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

Re: [U-Boot] [PATCH] usb: gadget: Move CONFIG_USB_GADGET to Kconfig

[Stephen Warren]

On 03/22/2016 01:59 PM, Semen Protsenko wrote:

From: Sam Protsenko 

The description was borrowed from kernel. "tristate" type was changed
to "bool" (I believe we don't support modules for u-boot yet, right?).
CONFIG_USB_GADGET requires CONFIG_USB to be defined too, so add it along
as well.

Some platforms weren't ported though:

 include/configs/e2220-1170.h
 include/configs/sunxi-common.h
 include/configs/xilinx_zynqmp.h

CONFIG_USB_GADGET remains in those files as there is no corresponding
defconfig files for those and I don't want to break anything.


That's not true; configs/e2220-1170_defconfig has existed for months. 
Did you base this change on the latest u-boot/master?

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

[U-Boot] [PATCH v5 00/14] Add Support for Secure Boot on LS2080

[Saksham Jain]

Secure Boot ESBC has been enabled on FSL LS208x platforms.

Changes for v2:
- changed function fsl_secboot_validate to return address of image
- corrected Bootscript header for ls1043 and ls1021
Changes for v3:
- minor changes to remove compilation warnings
Changes for v4:
- removed IE Key extenstion support. Methodology not fixed yet.
- minor changes in commit messages (clean up)
Changes for v5:
- Cleaned up commit messages
- Changed defconfigs to add configs like CONFIG_RSA
(These were added by intermediate patches since
these patches were floated for review)

Saksham Jain (14):
  armv8: ls2080: Add SFP Configs for LS2080
  ls2080: Add configs for SEC, SecMon, SRK and DCFG
  fsl: ls-ch3: Add new header for Secure Boot
  ls2080: Add Secure Boot support
  ls2080: Add bootscript header addr for secure boot
  fsl: ls-ch3: Copy Bootscript and header from NOR to DDR
  ls2080: Change env variable "fdt_high"
  ls2080: Add config for endianess of CCSR GUR
  armv8: fsl-lsch3: Disable SMMU during Secure Boot
  crypto/fsl: Correct 64-bit Write when MMU disabled
  crypto/fsl: Make CAAM transactions cacheable
  SECURE_BOOT: Use default bootargs
  SECURE BOOT: Halt execution when secure boot fail
  SECURE BOOT: Change fsl_secboot_validate func to ret image addr

 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 18 +-
 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 18 ++
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  | 28 +
 arch/arm/include/asm/fsl_secure_boot.h | 50 ++--
 board/freescale/common/cmd_esbc_validate.c | 14 -
 board/freescale/common/fsl_validate.c  | 66 +++--
 board/freescale/ls2080aqds/MAINTAINERS |  6 ++
 board/freescale/ls2080aqds/ls2080aqds.c|  5 +-
 board/freescale/ls2080ardb/MAINTAINERS |  6 ++
 board/freescale/ls2080ardb/ls2080ardb.c|  5 +-
 configs/ls2080aqds_SECURE_BOOT_defconfig   | 20 +++
 configs/ls2080ardb_SECURE_BOOT_defconfig   | 20 +++
 configs/ls2085aqds_SECURE_BOOT_defconfig   | 20 +++
 configs/ls2085ardb_SECURE_BOOT_defconfig   | 20 +++
 drivers/crypto/fsl/desc_constr.h   |  7 +--
 drivers/crypto/fsl/jr.c| 13 +
 drivers/crypto/fsl/jr.h|  3 +
 include/config_fsl_chain_trust.h   | 25 +---
 include/configs/ls2080aqds.h   |  2 +
 include/configs/ls2080ardb.h   |  2 +
 include/fsl_secboot_err.h  |  3 +
 include/fsl_sfp.h  |  3 +-
 include/fsl_validate.h | 67 ++
 23 files changed, 373 insertions(+), 48 deletions(-)
 create mode 100644 configs/ls2080aqds_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2080ardb_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2085aqds_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2085ardb_SECURE_BOOT_defconfig

-- 
1.8.1.4

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

Re: [U-Boot] [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support

[Zhiqiang Hou]

Hi Chenhui,

Do you have any update about how to fixup the related device node according to 
the PSCI and spin-table?

> -Original Message-
> From: york sun
> Sent: 2016年3月18日 5:09
> To: Zhiqiang Hou ; Bhupesh Sharma
> ; Scott Wood ; Zhiqiang Hou
> ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; mingkai...@freescale.com; Stuart Yoder
> ; le...@freescale.com; prabha...@freescale.com;
> bhupesh.sha...@freescale.com; Rod Dorris ; Chenhui
> Zhao 
> Subject: Re: [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support
> 
> On 01/24/2016 07:22 PM, Zhiqiang Hou wrote:
> >
> > Chenhui is working on it.
> >
> 
> Guys,
> 
> Where are we on this set?
> 
> York
> 

Thanks,
Zhiqiang

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

[U-Boot] [PATCH v5 12/14] SECURE_BOOT: Use default bootargs

[Saksham Jain]

For secure boot, currently we were using fixed bootargs for all SoCs.
This is not needed and we can use the bootargs which are used in
non-secure boot. Incase bootargs are not defined for non-secure boot
of any platform, we use default bootargs.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message
Changes for v5:
- Cleaned up commit message

 include/config_fsl_chain_trust.h | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/include/config_fsl_chain_trust.h b/include/config_fsl_chain_trust.h
index aa222bb..566fd80 100644
--- a/include/config_fsl_chain_trust.h
+++ b/include/config_fsl_chain_trust.h
@@ -44,11 +44,18 @@
  *  "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
  */
 
+#ifdef CONFIG_BOOTARGS
+#define CONFIG_SET_BOOTARGS"setenv bootargs \'" CONFIG_BOOTARGS" \';"
+#else
+#define CONFIG_SET_BOOTARGS"setenv bootargs \'root=/dev/ram "  \
+   "rw console=ttyS0,115200 ramdisk_size=60\';"
+#endif
+
+
 #ifdef CONFIG_BOOTSCRIPT_KEY_HASH
 #define CONFIG_SECBOOT \
"setenv bs_hdraddr " __stringify(CONFIG_BOOTSCRIPT_HDR_ADDR)";" \
-   "setenv bootargs \'root=/dev/ram rw console=ttyS0,115200 "  \
-   "ramdisk_size=60\';"\
+   CONFIG_SET_BOOTARGS \
CONFIG_EXTRA_ENV\
"esbc_validate $bs_hdraddr " \
  __stringify(CONFIG_BOOTSCRIPT_KEY_HASH)";" \
@@ -57,8 +64,7 @@
 #else
 #define CONFIG_SECBOOT \
"setenv bs_hdraddr " __stringify(CONFIG_BOOTSCRIPT_HDR_ADDR)";" \
-   "setenv bootargs \'root=/dev/ram rw console=ttyS0,115200 "  \
-   "ramdisk_size=60\';"\
+   CONFIG_SET_BOOTARGS \
CONFIG_EXTRA_ENV\
"esbc_validate $bs_hdraddr;" \
"source $img_addr;" \
-- 
1.8.1.4

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

[U-Boot] [PATCH v5 14/14] SECURE BOOT: Change fsl_secboot_validate func to ret image addr

[Saksham Jain]

Currently, fsl_secboot_validate function used to set env variable
"img_addr" to contain address of image being validated.

The function has been changed to output image addr via argument
img_addr_ptr. The command esbc_validate sets the env variable
"img_addr".

This change helps when fsl_secboot_validate function is called from
within UBOOT (because now instead of calling function
"getenv("img_addr")" we can directly get the image address).

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message
Changes for v5:
- Cleaned up commit message
 board/freescale/common/cmd_esbc_validate.c | 12 +++-
 board/freescale/common/fsl_validate.c  | 26 +++---
 include/fsl_validate.h |  4 ++--
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/board/freescale/common/cmd_esbc_validate.c 
b/board/freescale/common/cmd_esbc_validate.c
index 375bc24..cefe3cc 100644
--- a/board/freescale/common/cmd_esbc_validate.c
+++ b/board/freescale/common/cmd_esbc_validate.c
@@ -29,6 +29,8 @@ static int do_esbc_validate(cmd_tbl_t *cmdtp, int flag, int 
argc,
char *hash_str = NULL;
uintptr_t haddr;
int ret;
+   uintptr_t img_addr = 0;
+   char buf[20];
 
if (argc < 2)
return cmd_usage(cmdtp);
@@ -43,7 +45,15 @@ static int do_esbc_validate(cmd_tbl_t *cmdtp, int flag, int 
argc,
 * part of header. So, the function is called
 * by passing this argument as 0.
 */
-   ret = fsl_secboot_validate(haddr, hash_str, 0);
+   ret = fsl_secboot_validate(haddr, hash_str, _addr);
+
+   /* Need to set "img_addr" even if validation failure.
+* Required when SB_EN in RCW set and non-fatal error
+* to continue U-Boot
+*/
+   sprintf(buf, "%lx", img_addr);
+   setenv("img_addr", buf);
+
if (ret)
return 1;
 
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 95059c7..64e4e30 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -570,7 +570,7 @@ static int calc_esbchdr_esbc_hash(struct 
fsl_secboot_img_priv *img)
 
/* Update hash for actual Image */
ret = algo->hash_update(algo, ctx,
-   (u8 *)img->img_addr, img->img_size, 1);
+   (u8 *)(*(img->img_addr_ptr)), img->img_size, 1);
if (ret)
return ret;
 
@@ -646,7 +646,6 @@ static void construct_img_encoded_hash_second(struct 
fsl_secboot_img_priv *img)
  */
 static int read_validate_esbc_client_header(struct fsl_secboot_img_priv *img)
 {
-   char buf[20];
struct fsl_secboot_img_hdr *hdr = >hdr;
void *esbc = (u8 *)(uintptr_t)img->ehdrloc;
u8 *k, *s;
@@ -661,17 +660,14 @@ static int read_validate_esbc_client_header(struct 
fsl_secboot_img_priv *img)
/* If Image Address is not passed as argument to function,
 * then Address and Size must be read from the Header.
 */
-   if (img->img_addr == 0) {
+   if (*(img->img_addr_ptr) == 0) {
#ifdef CONFIG_ESBC_ADDR_64BIT
-   img->img_addr = hdr->pimg64;
+   *(img->img_addr_ptr) = hdr->pimg64;
#else
-   img->img_addr = hdr->pimg;
+   *(img->img_addr_ptr) = hdr->pimg;
#endif
}
 
-   sprintf(buf, "%lx", img->img_addr);
-   setenv("img_addr", buf);
-
if (!hdr->img_size)
return ERROR_ESBC_CLIENT_HEADER_IMG_SIZE;
 
@@ -814,9 +810,17 @@ static int calculate_cmp_img_sig(struct 
fsl_secboot_img_priv *img)
 
return 0;
 }
-
+/* haddr - Address of the header of image to be validated.
+ * arg_hash_str - Option hash string. If provided, this
+ * overides the key hash in the SFP fuses.
+ * img_addr_ptr - Optional pointer to address of image to be validated.
+ * If non zero addr, this overides the addr of image in header,
+ * otherwise updated to image addr in header.
+ * Acts as both input and output of function.
+ * This pointer shouldn't be NULL.
+ */
 int fsl_secboot_validate(uintptr_t haddr, char *arg_hash_str,
-   uintptr_t img_addr)
+   uintptr_t *img_addr_ptr)
 {
struct ccsr_sfp_regs *sfp_regs = (void *)(CONFIG_SYS_SFP_ADDR);
ulong hash[SHA256_BYTES/sizeof(ulong)];
@@ -869,7 +873,7 @@ int fsl_secboot_validate(uintptr_t haddr, char 
*arg_hash_str,
/* Update the information in Private Struct */
hdr = >hdr;
img->ehdrloc = haddr;
-   img->img_addr = img_addr;
+   img->img_addr_ptr = img_addr_ptr;
esbc = (u8 *)img->ehdrloc;
 
memcpy(hdr, esbc, sizeof(struct fsl_secboot_img_hdr));
diff --git a/include/fsl_validate.h b/include/fsl_validate.h
index ff6f6b7..a71e1ce 

[U-Boot] [PATCH v5 06/14] fsl: ls-ch3: Copy Bootscript and header from NOR to DDR

[Saksham Jain]

During Secure Boot, a bootscript is validated using its header. This
patch copies both these images to DDR from NOR and then validates and
executed them from DDR. (If NOR is the boot source for LS2080).

This copy step is done to make this step common across booting sources.
Because in case of non-xip memories (e.g. NAND, SD) it is neccessary to
copy both these images to DDR.

For other ARM Platforms (ls1043 and ls1020), header is not copied from
NOR to DDR (otherwise customers will need to modify the existing
headers).

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- for platform such as ls1043 and ls1021, boot header in NOR.
Not copied to NOR. For them, fixed CONFIG_BOOTSCRIPT_HDR_ADDR
to CONFIG_BS_HDR_ADDR_FLASH.
Changes for v3:
- No change
Changes for v4:
-Cleaned up commit message
Changes for v5:
- Cleaned up commit message


 arch/arm/include/asm/fsl_secure_boot.h | 28 +---
 include/config_fsl_chain_trust.h   | 11 +++
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 5575934..4d04eea 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -57,11 +57,33 @@
"setenv initrd_high 0xcfff;"\
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
 
-/* The address needs to be modified according to NOR memory map */
+/* Copying Bootscript and Header to DDR from NOR for LS2 and for rest, from
+ * Non-XIP Memory (Nand/SD)*/
+#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_LS2080A) ||\
+   defined(CONFIG_LS2085A)
+#define CONFIG_BOOTSCRIPT_COPY_RAM
+#endif
+/* The address needs to be modified according to NOR and DDR memory map */
 #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
-#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x58392
+#define CONFIG_BS_HDR_ADDR_FLASH   0x58392
+#define CONFIG_BS_ADDR_FLASH   0x58390
+#define CONFIG_BS_HDR_ADDR_RAM 0xa392
+#define CONFIG_BS_ADDR_RAM 0xa390
+#else
+#define CONFIG_BS_HDR_ADDR_FLASH   0x600a
+#define CONFIG_BS_ADDR_FLASH   0x6006
+#define CONFIG_BS_HDR_ADDR_RAM 0xa006
+#define CONFIG_BS_ADDR_RAM 0xa006
+#endif
+
+#ifdef CONFIG_BOOTSCRIPT_COPY_RAM
+#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_RAM
+#define CONFIG_BS_HDR_SIZE 0x2000
+#define CONFIG_BOOTSCRIPT_ADDR CONFIG_BS_ADDR_RAM
+#define CONFIG_BS_SIZE 0x1000
 #else
-#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x600a
+#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_FLASH
+/* BS_HDR_SIZE, BOOTSCRIPT_ADDR and BS_SIZE are not required */
 #endif
 
 #include 
diff --git a/include/config_fsl_chain_trust.h b/include/config_fsl_chain_trust.h
index 45dda56..aa222bb 100644
--- a/include/config_fsl_chain_trust.h
+++ b/include/config_fsl_chain_trust.h
@@ -65,8 +65,6 @@
"esbc_halt\0"
 #endif
 
-/* For secure boot flow, default environment used will be used */
-#if defined(CONFIG_SYS_RAMBOOT)
 #ifdef CONFIG_BOOTSCRIPT_COPY_RAM
 #define CONFIG_BS_COPY_ENV \
"setenv bs_hdr_ram " __stringify(CONFIG_BS_HDR_ADDR_RAM)";" \
@@ -76,14 +74,19 @@
"setenv bs_flash " __stringify(CONFIG_BS_ADDR_FLASH)";" \
"setenv bs_size " __stringify(CONFIG_BS_SIZE)";"
 
+/* For secure boot flow, default environment used will be used */
+#if defined(CONFIG_SYS_RAMBOOT)
 #if defined(CONFIG_RAMBOOT_NAND)
 #define CONFIG_BS_COPY_CMD \
"nand read $bs_hdr_ram $bs_hdr_flash $bs_hdr_size ;" \
"nand read $bs_ram $bs_flash $bs_size ;"
 #endif /* CONFIG_RAMBOOT_NAND */
-#endif /* CONFIG_BOOTSCRIPT_COPY_RAM */
-
+#else
+#define CONFIG_BS_COPY_CMD \
+   "cp.b $bs_hdr_flash $bs_hdr_ram  $bs_hdr_size ;" \
+   "cp.b $bs_flash $bs_ram  $bs_size ;"
 #endif
+#endif /* CONFIG_BOOTSCRIPT_COPY_RAM */
 
 #ifndef CONFIG_BS_COPY_ENV
 #define CONFIG_BS_COPY_ENV
-- 
1.8.1.4

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

[U-Boot] [PATCH v5 05/14] Add bootscript header addr for ls2080a secure boot

[Saksham Jain]

During secure boot, Linux image along with other images are validated
using bootscript. This bootscript also needs to be validated before it
is executed. This requires a header for bootscript.

When secure boot is enabled, default bootcmd is changed to first
validate bootscript using the header and then execute the script.

For ls2080, NOR memory map is different from earlier arm SoCs. So a new
address on NOR is used for this bootscript header (0x58392). The
Bootscript address is mentioned in this header along with addresses of
other images.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
-Cleaned up commit message
Changes for v5:
-Cleaned up commit message

 arch/arm/include/asm/fsl_secure_boot.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index b745194..5575934 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -58,7 +58,11 @@
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
 
 /* The address needs to be modified according to NOR memory map */
+#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x58392
+#else
 #define CONFIG_BOOTSCRIPT_HDR_ADDR 0x600a
+#endif
 
 #include 
 #endif /* #ifdef CONFIG_CHAIN_OF_TRUST */
-- 
1.8.1.4

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

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Tom Rini]

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
> Hello Marek,
> 
> On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:
> > This patch decouples U-Boot binary from the toolchain on systems where
> > private libgcc is available. Instead of pulling in functions provided
> > by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
> > functions. These functions are usually imported from Linux kernel, which
> > also uses it's own libgcc functions instead of the ones provided by the
> > toolchain.
> > 
> > This patch solves a rather common problem. The toolchain can usually
> > generate code for many variants of target architecture and often even
> > different endianness. The libgcc on the other hand is usually compiled
> > for one particular configuration and the functions provided by it may
> > or may not be suited for use in U-Boot. This can manifest in two ways,
> > either the U-Boot fails to compile altogether and linker will complain
> > or, in the much worse case, the resulting U-Boot will build, but will
> > misbehave in very subtle and hard to debug ways.
> 
> I don't think using private libgcc by default is a good idea.
> 
> U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
> cases where a target cannot properly link with the libgcc provided by
> the (specific release of the) GCC toolchain in use. Using private libgcc
> to other cases than these does not fix or improve anything; those
> other cases were working and did not require any fix in this respect. 

This isn't true, exactly.  If using clang for example everyone needs to
enable this code.  We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain.  And we get
that.

> Also, libgcc is not a standalone project that can be frozen, forked or
> improved freely; it is an internal component of the GCC toolchain. No
> standard defines what libgcc is or should be, and we have no control
> over the 'contract' between GCC-emitted code and libgcc. The GCC
> project may decide to change that contract at any time, and produce a
> new toolchain and a new libgcc. Using our private libgcc by default
> will cause all targets to break for no good reason. We've already been
> bitten by internal GCC changes on which we were dependent; adding more
> such dependency is not the way to go IMO.
> 
> If we truly fear that GCC is *generally* unable to properly build our
> targets due to its libgcc, then we should not only "snapshot and fix"
> libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> sure we keep a consistent copy of it. I don't think that would be a
> viable move.
> 
> And if we don't believe that GCC is generally unable to properly build
> U-Boot, then we should always use it as provided unless it is provably
> buggy, in which case if a private libgcc is a fix, then by all means we
> should use it.
> 
> And whenever we find that a GCC toolchain is provably buggy, we should
> raise a bug, either to the toolchain provider if the issue is only with
> a given binary release (e.g. mismatched or badly supported endianness),
> or to the GCC project if the bug is inherent to GCC (e.g. generation
> of non-supported opcodes for a given arch/cpu).

Ah, but this shows part of the problem.  We don't need "libgcc" as in
"the thing which provides gcc'isms".  We need "libgcc" as in "the thing
which provides AEABI functions".  Today we get these from libgcc but we
run into cases where this doesn't work quite right (toolchain fun) or
simply aren't available (again, clang).  So I am in favour of re-syncing
with this part of the kernel and mirroring the decision to always
include these functions, again, like the kernel does.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sunxi: Select CONFIG_OF_BOARD_SETUP from arch/arm/Kconfig

[Ian Campbell]

On Wed, 2016-03-23 at 11:13 +0100, Hans de Goede wrote:
> Always select OF_BOARD_SETUP on sunxi, rather then having it in
> almost
> all our defconfigs. This also fixes it missing from some recently
> added defconfigs.
> 
> This commit also modifies our ft_board_setup() to not cause warnings
> when CONFIG_VIDEO_DT_SIMPLEFB is not set, since we will now always
> build it.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Only select CONFIG_OF_BOARD_SETUP when CONFIG_VIDEO is set, rather then 
> always
> Changes in v3:
> -Back to always enabling CONFIG_OF_BOARD_SETUP on sunxi + fix the compile
>  warning in ft_board_setup when CONFIG_VIDEO_DT_SIMPLEFB is not set

I agree this approach is better:
Acked-by: Ian Campbell 

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

Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts for Orange Pi 2 SBC

[Ian Campbell]

On Wed, 2016-03-23 at 11:13 +0100, Hans de Goede wrote:
> The Orange Pi 2 is a SBC based on the Allwinner H3 SoC with a uSD
> slot,
> 4 USB ports connected via a USB-2 hub, a 10/100M ethernet port using
> the
> SoC's integrated PHY, Wifi via a RTL8189ETV sdio wifi chip, USB OTG,
> HDMI,
> a TRRS headphone jack for stereo out and composite out, a microphone,
> an IR receiver, a CSI connector, 2 LEDs, a 3 pin UART header
> and a 40-pin GPIO header.
> 
> The added dts file is identical to the one submitted to the upstream
> kernel.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Albert ARIBAUD]

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:
> This patch decouples U-Boot binary from the toolchain on systems where
> private libgcc is available. Instead of pulling in functions provided
> by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
> functions. These functions are usually imported from Linux kernel, which
> also uses it's own libgcc functions instead of the ones provided by the
> toolchain.
> 
> This patch solves a rather common problem. The toolchain can usually
> generate code for many variants of target architecture and often even
> different endianness. The libgcc on the other hand is usually compiled
> for one particular configuration and the functions provided by it may
> or may not be suited for use in U-Boot. This can manifest in two ways,
> either the U-Boot fails to compile altogether and linker will complain
> or, in the much worse case, the resulting U-Boot will build, but will
> misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect. 

Also, libgcc is not a standalone project that can be frozen, forked or
improved freely; it is an internal component of the GCC toolchain. No
standard defines what libgcc is or should be, and we have no control
over the 'contract' between GCC-emitted code and libgcc. The GCC
project may decide to change that contract at any time, and produce a
new toolchain and a new libgcc. Using our private libgcc by default
will cause all targets to break for no good reason. We've already been
bitten by internal GCC changes on which we were dependent; adding more
such dependency is not the way to go IMO.

If we truly fear that GCC is *generally* unable to properly build our
targets due to its libgcc, then we should not only "snapshot and fix"
libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
sure we keep a consistent copy of it. I don't think that would be a
viable move.

And if we don't believe that GCC is generally unable to properly build
U-Boot, then we should always use it as provided unless it is provably
buggy, in which case if a private libgcc is a fix, then by all means we
should use it.

And whenever we find that a GCC toolchain is provably buggy, we should
raise a bug, either to the toolchain provider if the issue is only with
a given binary release (e.g. mismatched or badly supported endianness),
or to the GCC project if the bug is inherent to GCC (e.g. generation
of non-supported opcodes for a given arch/cpu).

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH][v4] armv8/ls2080ardb: Enable VID support

[Rai Harninder]

This patch enable VID support for ls2080ardb platform.
It uses the common VID driver

Signed-off-by: Rai Harninder 
---
Changes in v4:
- Fix implicit declaration warning for adjust_vdd()
by including approriate header file

Changes in v3:
- Call adjust_vdd() so that the voltage gets adjusted
during u-boot boot up itself

Changes in v2
- Use CONFIG_FSL_LSCH3 instead of CONFIG_LAYERSCAPE
  since the latter is defined for other platforms
  as well
- Modify patch description


 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 
 board/freescale/common/vid.c   |   15 ++-
 board/freescale/ls2080ardb/ls2080ardb.c|9 +
 include/configs/ls2080ardb.h   |   16 
 4 files changed, 43 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 081519a..94258d2 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -154,6 +154,10 @@ struct ccsr_gur {
u8  res_008[0x20-0x8];
u32 gpporcr1;   /* General-purpose POR configuration */
u32 gpporcr2;   /* General-purpose POR configuration 2 */
+#define FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT 25
+#define FSL_CHASSIS3_DCFG_FUSESR_VID_MASK  0x1F
+#define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT  20
+#define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK   0x1F
u32 dcfg_fusesr;/* Fuse status register */
u32 gpporcr3;
u32 gpporcr4;
diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index a6a132a..2f29795 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -10,6 +10,8 @@
 #include 
 #ifdef CONFIG_LS1043A
 #include 
+#elif defined(CONFIG_FSL_LSCH3)
+#include 
 #else
 #include 
 #endif
@@ -285,7 +287,7 @@ static int set_voltage(int i2caddress, int vdd)
 int adjust_vdd(ulong vdd_override)
 {
int re_enable = disable_interrupts();
-#ifdef CONFIG_LS1043A
+#if defined(CONFIG_LS1043A) || defined(CONFIG_FSL_LSCH3)
struct ccsr_gur *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
 #else
ccsr_gur_t __iomem *gur =
@@ -362,7 +364,11 @@ int adjust_vdd(ulong vdd_override)
}
 
/* get the voltage ID from fuse status register */
+#ifdef CONFIG_FSL_LSCH3
+   fusesr = in_le32(>dcfg_fusesr);
+#else
fusesr = in_be32(>dcfg_fusesr);
+#endif
/*
 * VID is used according to the table below
 *---
@@ -387,6 +393,13 @@ int adjust_vdd(ulong vdd_override)
vid = (fusesr >> FSL_CHASSIS2_DCFG_FUSESR_VID_SHIFT) &
FSL_CHASSIS2_DCFG_FUSESR_VID_MASK;
}
+#elif defined(CONFIG_FSL_LSCH3)
+   vid = (fusesr >> FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT) &
+   FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK;
+   if ((vid == 0) || (vid == FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK)) {
+   vid = (fusesr >> FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT) &
+   FSL_CHASSIS3_DCFG_FUSESR_VID_MASK;
+   }
 #else
vid = (fusesr >> FSL_CORENET_DCFG_FUSESR_ALTVID_SHIFT) &
FSL_CORENET_DCFG_FUSESR_ALTVID_MASK;
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index 12638df..9d3c680 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -21,6 +21,7 @@
 
 #include "../common/qixis.h"
 #include "ls2080ardb_qixis.h"
+#include "../common/vid.h"
 
 #define PIN_MUX_SEL_SDHC   0x00
 #define PIN_MUX_SEL_DSPI   0x0a
@@ -122,6 +123,11 @@ int select_i2c_ch_pca9547(u8 ch)
return 0;
 }
 
+int i2c_multiplexer_select_vid_channel(u8 channel)
+{
+   return select_i2c_ch_pca9547(channel);
+}
+
 int config_board_mux(int ctrl_type)
 {
u8 reg5;
@@ -188,6 +194,9 @@ int misc_init_r(void)
if (hwconfig("sdhc"))
config_board_mux(MUX_TYPE_SDHC);
 
+   if (adjust_vdd(0))
+   printf("Warning: Adjusting core voltage failed.\n");
+
return 0;
 }
 
diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 59a3f66..2a1e841 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -14,6 +14,22 @@
 
 #define CONFIG_DISPLAY_BOARDINFO
 
+#define I2C_MUX_CH_VOL_MONITOR 0xa
+#define I2C_VOL_MONITOR_ADDR   0x38
+#define CONFIG_VOL_MONITOR_IR36021_READ
+#define CONFIG_VOL_MONITOR_IR36021_SET
+
+#define CONFIG_VID_FLS_ENV "ls2080ardb_vdd_mv"
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_VID
+#endif
+/* step the IR regulator in 5mV increments */
+#define IR_VDD_STEP_DOWN   5
+#define IR_VDD_STEP_UP 5
+/* The lowest and highest voltage allowed for LS2080ARDB */
+#define VDD_MV_MIN 

[U-Boot] [PATCH 1/2] armv8: fsl-layerscape: change LS1043A SVR register

[Gong Qianyu]

From: Mingkai Hu 

Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
 arch/arm/include/asm/arch-fsl-layerscape/soc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
index ea78e15..512a8e0 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -41,7 +41,7 @@ struct cpu_type {
{ .name = #n, .soc_ver = SVR_##v, .num_cores = (nc)}
 
 #define SVR_WO_E   0xFE
-#define SVR_LS1043 0x879204
+#define SVR_LS1043 0x879200
 #define SVR_LS2045 0x870120
 #define SVR_LS2080 0x870110
 #define SVR_LS2085 0x870100
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH] armv8/ls1043aqds: dts: set SPI mode for DSPI

[Gong Qianyu]

It's necessary to set the clock phase and polarity for DSPI
flash or it could not work properly.

Signed-off-by: Gong Qianyu 
---
 arch/arm/dts/fsl-ls1043a-qds.dtsi | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/fsl-ls1043a-qds.dtsi 
b/arch/arm/dts/fsl-ls1043a-qds.dtsi
index 66efe67..2e9f1f9 100644
--- a/arch/arm/dts/fsl-ls1043a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1043a-qds.dtsi
@@ -28,8 +28,10 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "spi-flash";
-   reg = <0>;
spi-max-frequency = <100>; /* input clock */
+   spi-cpol;
+   spi-cpha;
+   reg = <0>;
};
 
dflash1: sst25wf040b {
@@ -37,6 +39,8 @@
#size-cells = <1>;
compatible = "spi-flash";
spi-max-frequency = <350>;
+   spi-cpol;
+   spi-cpha;
reg = <1>;
};
 
@@ -45,6 +49,8 @@
#size-cells = <1>;
compatible = "spi-flash";
spi-max-frequency = <350>;
+   spi-cpol;
+   spi-cpha;
reg = <2>;
};
 };
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH 2/2] armv8: fsl-layerscape: add LS1023A SVR

[Gong Qianyu]

From: Mingkai Hu 

Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 1 +
 arch/arm/include/asm/arch-fsl-layerscape/soc.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h 
b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
index 794b764..a9dadfa 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
@@ -12,6 +12,7 @@ static struct cpu_type cpu_type_list[] = {
CPU_TYPE_ENTRY(LS2085, LS2085, 8),
CPU_TYPE_ENTRY(LS2045, LS2045, 4),
CPU_TYPE_ENTRY(LS1043, LS1043, 4),
+   CPU_TYPE_ENTRY(LS1023, LS1023, 2),
CPU_TYPE_ENTRY(LS2040, LS2040, 4),
 };
 
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
index 512a8e0..56989e1 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -42,6 +42,7 @@ struct cpu_type {
 
 #define SVR_WO_E   0xFE
 #define SVR_LS1043 0x879200
+#define SVR_LS1023 0x879208
 #define SVR_LS2045 0x870120
 #define SVR_LS2080 0x870110
 #define SVR_LS2085 0x870100
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCHv3 2/2] Add support the Avionic Design Meerkat COM and Kein Baseboard

[Julian Scheel]

On 04.03.2016 08:32, Julian Scheel wrote:

Add support for platforms based on the Meerkat COM module. Includes support
for the minimal reference platform called Kein Baseboard, which in fact is
sufficient to run most existing Meerkat carriers.

Signed-off-by: Julian Scheel 
---
Changes in v3:
  - Remove bad as3722 gpio manipulations on pcie init (this time for real)

Changes in v2:
  - Rename config options to TARGET_KEIN_BASEBOARD
  - Remove unnecessary CONFIG options from kein-baseboard.h
  - Add clocks to meerkat dtsi, as it was removed from tegra124-dtsi lately
---


Are there any objections left on this series?

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

[U-Boot] [PATCH v3] sunxi: Select CONFIG_OF_BOARD_SETUP from arch/arm/Kconfig

[Hans de Goede]

Always select OF_BOARD_SETUP on sunxi, rather then having it in almost
all our defconfigs. This also fixes it missing from some recently
added defconfigs.

This commit also modifies our ft_board_setup() to not cause warnings
when CONFIG_VIDEO_DT_SIMPLEFB is not set, since we will now always
build it.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Only select CONFIG_OF_BOARD_SETUP when CONFIG_VIDEO is set, rather then always
Changes in v3:
-Back to always enabling CONFIG_OF_BOARD_SETUP on sunxi + fix the compile
 warning in ft_board_setup when CONFIG_VIDEO_DT_SIMPLEFB is not set
---
 arch/arm/Kconfig   | 1 +
 board/sunxi/board.c| 9 ++---
 configs/A10-OLinuXino-Lime_defconfig   | 1 -
 configs/A10s-OLinuXino-M_defconfig | 1 -
 configs/A13-OLinuXinoM_defconfig   | 1 -
 configs/A13-OLinuXino_defconfig| 1 -
 configs/A20-OLinuXino-Lime2_defconfig  | 1 -
 configs/A20-OLinuXino-Lime_defconfig   | 1 -
 configs/A20-OLinuXino_MICRO_defconfig  | 1 -
 configs/A20-Olimex-SOM-EVB_defconfig   | 1 -
 configs/Ainol_AW1_defconfig| 1 -
 configs/Ampe_A76_defconfig | 1 -
 configs/Auxtek-T003_defconfig  | 1 -
 configs/Auxtek-T004_defconfig  | 1 -
 configs/Bananapi_defconfig | 1 -
 configs/Bananapro_defconfig| 1 -
 configs/CHIP_defconfig | 1 -
 configs/CSQ_CS908_defconfig| 1 -
 configs/Chuwi_V7_CW0825_defconfig  | 1 -
 configs/Colombus_defconfig | 1 -
 configs/Cubieboard2_defconfig  | 1 -
 configs/Cubieboard_defconfig   | 1 -
 configs/Cubietruck_defconfig   | 1 -
 configs/Empire_electronix_d709_defconfig   | 1 -
 configs/Hummingbird_A31_defconfig  | 1 -
 configs/Hyundai_A7HD_defconfig | 1 -
 configs/Lamobo_R1_defconfig| 1 -
 configs/Linksprite_pcDuino3_Nano_defconfig | 1 -
 configs/Linksprite_pcDuino3_defconfig  | 1 -
 configs/Linksprite_pcDuino_defconfig   | 1 -
 configs/MK808C_defconfig   | 1 -
 configs/MSI_Primo73_defconfig  | 1 -
 configs/MSI_Primo81_defconfig  | 1 -
 configs/Marsboard_A10_defconfig| 1 -
 configs/Mele_A1000G_quad_defconfig | 1 -
 configs/Mele_A1000_defconfig   | 1 -
 configs/Mele_I7_defconfig  | 1 -
 configs/Mele_M3_defconfig  | 1 -
 configs/Mele_M5_defconfig  | 1 -
 configs/Mele_M9_defconfig  | 1 -
 configs/Mini-X_defconfig   | 1 -
 configs/Orangepi_defconfig | 1 -
 configs/Orangepi_mini_defconfig| 1 -
 configs/Sinlinx_SinA31s_defconfig  | 1 -
 configs/Sinlinx_SinA33_defconfig   | 1 -
 configs/Sinovoip_BPI_M2_defconfig  | 1 -
 configs/UTOO_P66_defconfig | 1 -
 configs/Wexler_TAB7200_defconfig   | 1 -
 configs/Wits_Pro_A20_DKT_defconfig | 1 -
 configs/Wobo_i5_defconfig  | 1 -
 configs/Yones_Toptech_BD1078_defconfig | 1 -
 configs/ba10_tv_box_defconfig  | 1 -
 configs/dserve_dsrv9703c_defconfig | 1 -
 configs/ga10h_v1_1_defconfig   | 1 -
 configs/gt90h_v4_defconfig | 1 -
 configs/i12-tvbox_defconfig| 1 -
 configs/iNet_3F_defconfig  | 1 -
 configs/iNet_3W_defconfig  | 1 -
 configs/iNet_86VS_defconfig| 1 -
 configs/inet1_defconfig| 1 -
 configs/inet97fv2_defconfig| 1 -
 configs/inet98v_rev2_defconfig | 1 -
 configs/inet9f_rev03_defconfig | 1 -
 configs/jesurun_q5_defconfig   | 1 -
 configs/mixtile_loftq_defconfig| 1 -
 configs/mk802_a10s_defconfig   | 1 -
 configs/mk802_defconfig| 1 -
 configs/mk802ii_defconfig  | 1 -
 configs/pov_protab2_ips9_defconfig | 1 -
 configs/q8_a13_tablet_defconfig| 1 -
 configs/q8_a23_tablet_800x480_defconfig| 1 -
 configs/q8_a33_tablet_1024x600_defconfig   | 1 -
 configs/q8_a33_tablet_800x480_defconfig| 1 -
 configs/r7-tv-dongle_defconfig | 1 -
 configs/sunxi_Gemei_G9_defconfig   | 1 -
 75 files changed, 7 insertions(+), 76 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e5f57ef..ab986d3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -531,6 +531,7 @@ config ARCH_SUNXI
select DM_KEYBOARD
select DM_SERIAL
select DM_USB
+   select OF_BOARD_SETUP
select OF_CONTROL
select OF_SEPARATE
select SPL_STACK_R if !MACH_SUN9I
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 2e2a1f5..2d5335f 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -607,11 +607,14 @@ int misc_init_r(void)
 }
 #endif
 
-#ifdef 

[U-Boot] [PATCH] sunxi: Add defconfig and dts for Orange Pi 2 SBC

[Hans de Goede]

The Orange Pi 2 is a SBC based on the Allwinner H3 SoC with a uSD slot,
4 USB ports connected via a USB-2 hub, a 10/100M ethernet port using the
SoC's integrated PHY, Wifi via a RTL8189ETV sdio wifi chip, USB OTG, HDMI,
a TRRS headphone jack for stereo out and composite out, a microphone,
an IR receiver, a CSI connector, 2 LEDs, a 3 pin UART header
and a 40-pin GPIO header.

The added dts file is identical to the one submitted to the upstream
kernel.

Signed-off-by: Hans de Goede 
---
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/sun8i-h3-orangepi-2.dts | 186 +++
 board/sunxi/MAINTAINERS  |   1 +
 configs/orangepi_2_defconfig |  18 
 4 files changed, 206 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-h3-orangepi-2.dts
 create mode 100644 configs/orangepi_2_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6112f52..ae75c76 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -201,6 +201,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-a83t-sinovoip-bpi-m3.dtb
 dtb-$(CONFIG_MACH_SUN8I_H3) += \
+   sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-pc.dtb \
sun8i-h3-orangepi-plus.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
diff --git a/arch/arm/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/dts/sun8i-h3-orangepi-2.dts
new file mode 100644
index 000..f93f5d1
--- /dev/null
+++ b/arch/arm/dts/sun8i-h3-orangepi-2.dts
@@ -0,0 +1,186 @@
+/*
+ * Copyright (C) 2016 Hans de Goede 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Xunlong Orange Pi 2";
+   compatible = "xunlong,orangepi-2", "allwinner,sun8i-h3";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_opc>, <_r_opc>;
+
+   status_led {
+   label = "orangepi:red:status";
+   gpios = < 0 15 GPIO_ACTIVE_HIGH>;
+   };
+
+   pwr_led {
+   label = "orangepi:green:pwr";
+   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
+   r_gpio_keys {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <_r_opc>;
+
+   sw2 {
+   label = "sw2";
+   linux,code = ;
+   gpios = <_pio 0 4 GPIO_ACTIVE_LOW>;
+   };
+
+   sw4 {
+   label = "sw4";
+   linux,code = ;
+   gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   

Re: [U-Boot] [PATCH v2] sunxi: Select CONFIG_OF_BOARD_SETUP from CONFIG_VIDEO

[Hans de Goede]

Hi,

On 23-03-16 10:26, Ian Campbell wrote:

On Tue, 2016-03-22 at 23:08 +0100, Hans de Goede wrote:

Select OF_BOARD_SETUP when CONFIG_VIDEO is set, rather then having it
in
almost all our defconfigs. This also fixes it missing from some
recently
added defconfigs.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Only select CONFIG_OF_BOARD_SETUP when CONFIG_VIDEO is set, rather
then always


What were the warning you got with the first version? Is that something
we should consider addressing instead? The link between OF_BOARD_SETUP
and VIDEO is not entirely clear to me.


Out ft_board_Setup looks like this:

#ifdef CONFIG_OF_BOARD_SETUP
int ft_board_setup(void *blob, bd_t *bd)
{
#ifdef CONFIG_VIDEO_DT_SIMPLEFB
return sunxi_simplefb_setup(blob);
#endif
}
#endif /* CONFIG_OF_BOARD_SETUP */

So without CONFIG_VIDEO we get a warning about a non void
function not having a return, we could change ft_board_setup() to:

#ifdef CONFIG_OF_BOARD_SETUP
int ft_board_setup(void *blob, bd_t *bd)
{
int __maybe_unused r;

#ifdef CONFIG_VIDEO_DT_SIMPLEFB
r = sunxi_simplefb_setup(blob);
if (r)
return r;
#endif
return 0;
}
#endif /* CONFIG_OF_BOARD_SETUP */

Note the using of "int __maybe_unused r" outside of the
#ifdef CONFIG_VIDEO_DT_SIMPLEFB is deliberate, it is to
avoid having to move things around if / when we add
another ft setup function to call from ft_board_setup().

I believe that you're right and doing something like the
above + always selecting CONFIG_OF_BOARD_SETUP would be
better, I'll send a v3 soon.

Regards,

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

Re: [U-Boot] [PATCH v1] Revert "fastboot: OUT transaction length must be aligned to wMaxPacketSize"

[Lukasz Majewski]

Hi Marek,

> On 03/23/2016 01:50 AM, Steve Rae wrote:
> > This reverts commit 9e4b510d40310bf46e09f4edd0a0b6356213df47.
> > 
> > Signed-off-by: Steve Rae 
> > ---
> > As discussed on the mailing list, this change breaks the download
> > portion of fastboot by causing the server (the device running
> > U-Boot) to wait forever for bytes which are never sent by the
> > client (the host connected via USB).
> 
> It'd be real cool if you could reference the ML discussion next time.
> 
> > Does anyone know how to contact:
> >   Dileep Katta 
> > (this email bounces) ?
> 
> No clue, sorry.

Probably he is no longer employed by Linaro.

> 
> Applied for now as it fixes real bug.

I've a gut feeling that there are different versions of "fastboot"
protocol.

What Steve is describing is that HOST is waiting for ZLP ACK.

Anyway, I'm not able to test fastboot gadget since our (I mean
Samsung's) boards aren't supporting fastboot - we use UMS, DFU, LTHOR.

Hence, I can only rely on somebody's testing and review the code without
the ability to know about implementation "quirks".

> 
> >  drivers/usb/gadget/f_fastboot.c | 27 +--
> >  1 file changed, 5 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/usb/gadget/f_fastboot.c
> > b/drivers/usb/gadget/f_fastboot.c index a54b4ee..887cf4f 100644
> > --- a/drivers/usb/gadget/f_fastboot.c
> > +++ b/drivers/usb/gadget/f_fastboot.c
> > @@ -57,7 +57,6 @@ static struct f_fastboot *fastboot_func;
> >  static unsigned int fastboot_flash_session_id;
> >  static unsigned int download_size;
> >  static unsigned int download_bytes;
> > -static bool is_high_speed;
> >  
> >  static struct usb_endpoint_descriptor fs_ep_in = {
> > .bLength= USB_DT_ENDPOINT_SIZE,
> > @@ -241,13 +240,10 @@ static int fastboot_set_alt(struct
> > usb_function *f, __func__, f->name, interface, alt);
> >  
> > /* make sure we don't enable the ep twice */
> > -   if (gadget->speed == USB_SPEED_HIGH) {
> > +   if (gadget->speed == USB_SPEED_HIGH)
> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
> > -   is_high_speed = true;
> > -   } else {
> > +   else
> > ret = usb_ep_enable(f_fb->out_ep, _ep_out);
> > -   is_high_speed = false;
> > -   }
> > if (ret) {
> > puts("failed to enable out ep\n");
> > return ret;
> > @@ -419,20 +415,13 @@ static void cb_getvar(struct usb_ep *ep,
> > struct usb_request *req) fastboot_tx_write_str(response);
> >  }
> >  
> > -static unsigned int rx_bytes_expected(unsigned int maxpacket)
> > +static unsigned int rx_bytes_expected(void)
> >  {
> > int rx_remain = download_size - download_bytes;
> > -   int rem = 0;
> > if (rx_remain < 0)
> > return 0;
> > if (rx_remain > EP_BUFFER_SIZE)
> > return EP_BUFFER_SIZE;
> > -   if (rx_remain < maxpacket) {
> > -   rx_remain = maxpacket;
> > -   } else if (rx_remain % maxpacket != 0) {
> > -   rem = rx_remain % maxpacket;
> > -   rx_remain = rx_remain + (maxpacket - rem);
> > -   }
> > return rx_remain;
> >  }
> >  
> > @@ -444,7 +433,6 @@ static void rx_handler_dl_image(struct usb_ep
> > *ep, struct usb_request *req) const unsigned char *buffer =
> > req->buf; unsigned int buffer_size = req->actual;
> > unsigned int pre_dot_num, now_dot_num;
> > -   unsigned int max;
> >  
> > if (req->status != 0) {
> > printf("Bad status: %d\n", req->status);
> > @@ -482,9 +470,7 @@ static void rx_handler_dl_image(struct usb_ep
> > *ep, struct usb_request *req) 
> > printf("\ndownloading of %d bytes finished\n",
> > download_bytes); } else {
> > -   max = is_high_speed ? hs_ep_out.wMaxPacketSize :
> > -   fs_ep_out.wMaxPacketSize;
> > -   req->length = rx_bytes_expected(max);
> > +   req->length = rx_bytes_expected();
> > if (req->length < ep->maxpacket)
> > req->length = ep->maxpacket;
> > }
> > @@ -497,7 +483,6 @@ static void cb_download(struct usb_ep *ep,
> > struct usb_request *req) {
> > char *cmd = req->buf;
> > char response[FASTBOOT_RESPONSE_LEN];
> > -   unsigned int max;
> >  
> > strsep(, ":");
> > download_size = simple_strtoul(cmd, NULL, 16);
> > @@ -513,9 +498,7 @@ static void cb_download(struct usb_ep *ep,
> > struct usb_request *req) } else {
> > sprintf(response, "DATA%08x", download_size);
> > req->complete = rx_handler_dl_image;
> > -   max = is_high_speed ? hs_ep_out.wMaxPacketSize :
> > -   fs_ep_out.wMaxPacketSize;
> > -   req->length = rx_bytes_expected(max);
> > +   req->length = rx_bytes_expected();
> > if (req->length < ep->maxpacket)
> > req->length = ep->maxpacket;
> > }
> > 
> 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group

Re: [U-Boot] [PATCH v2] sunxi: Select CONFIG_OF_BOARD_SETUP from CONFIG_VIDEO

[Ian Campbell]

On Tue, 2016-03-22 at 23:08 +0100, Hans de Goede wrote:
> Select OF_BOARD_SETUP when CONFIG_VIDEO is set, rather then having it
> in
> almost all our defconfigs. This also fixes it missing from some
> recently
> added defconfigs.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Only select CONFIG_OF_BOARD_SETUP when CONFIG_VIDEO is set, rather
> then always

What were the warning you got with the first version? Is that something
we should consider addressing instead? The link between OF_BOARD_SETUP
and VIDEO is not entirely clear to me.

Ian.

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

Re: [U-Boot] [PATCH v5 3/4] drivers:usb:common:fsl-dt-fixup: Add device-tree fixup support for xhci controller

[Marek Vasut]

On 03/23/2016 09:41 AM, Marek Vasut wrote:
> On 03/23/2016 09:30 AM, Sriram Dash wrote:
>>
>>
>>> -Original Message-
>>> From: Marek Vasut [mailto:ma...@denx.de]
>>> Sent: Tuesday, March 22, 2016 12:54 PM
>>> To: Sriram Dash ; u-boot@lists.denx.de
>>> Cc: york sun ; Ramneek Mehresh
>>> ; Rajesh Bhagat 
>>> Subject: Re: [PATCH v5 3/4] drivers:usb:common:fsl-dt-fixup: Add 
>>> device-tree fixup
>>> support for xhci controller
>>>
>>> On 03/22/2016 08:10 AM, Sriram Dash wrote:
 Enables usb device-tree fixup code to incorporate xhci controller

 Signed-off-by: Ramneek Mehresh 
 Signed-off-by: Sriram Dash 
 ---
 Changes in v5:
   - Make the array static const
 Changes in v4:
   - Use a terminating entry in the array for getting node type for
 controller Changes in v3:
   - Modify the Makefile to remove comparison
   - Put the supported controllers in array and checking from array
 Changes in v2:
   - Remove the #defines from the patch and adding controller support

  drivers/usb/common/Makefile   |  1 +
  drivers/usb/common/fsl-dt-fixup.c | 33 +
  include/fdt_support.h |  4 ++--
  3 files changed, 20 insertions(+), 18 deletions(-)

 diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
 index a38ee4a..2f3d43d 100644
 --- a/drivers/usb/common/Makefile
 +++ b/drivers/usb/common/Makefile
 @@ -4,3 +4,4 @@
  #

  obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o
 +obj-$(CONFIG_USB_XHCI_FSL) += fsl-dt-fixup.o
 diff --git a/drivers/usb/common/fsl-dt-fixup.c
 b/drivers/usb/common/fsl-dt-fixup.c
 index eb13f12..13f9fb8 100644
 --- a/drivers/usb/common/fsl-dt-fixup.c
 +++ b/drivers/usb/common/fsl-dt-fixup.c
 @@ -19,27 +19,28 @@
  #define CONFIG_USB_MAX_CONTROLLER_COUNT 1  #endif

 +static const char compat_usb_fsl[] = {
 +  "fsl-usb2-mph" "\0"
 +  "fsl-usb2-dr" "\0"
 +  "snps,dwc3" "\0"
 +};
>>>
>>> This is supposed to be static constant array of strings. Can you tell me, 
>>> based on
>>> your knowledge of the C language, what is wrong with this construct ?
>>>
>>
>> IMO, above construct is correct. Originally, we proposed array of strings 
>> but later we changed to 
>> character array with terminating NULL entry for each element to incorporate 
>> your below review 
>> comment given in v3. 
>> "My opinion is to use a terminating NULL entry and iterate over the array 
>> until you reach it."
> 
> Do this:
> 
> static const char *compat_usb_fsl[] = {
>   "fsl-usb2-mph",
>   "fsl-usb2-dr",
>   "snps,dwc3",
>   NULL
> };
> 
> and then do
> 
> i = 0;
> while (compat_usb_fsl[i]) {
>   ... do some stuff ...
>   i++;
> }

Or even use for(i = 0; compat_usb_fsl[i]; i++) { do something }

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