Re: [U-Boot] [PATCH 1/2] sunxi: Add conditional magic sram poke for A33

[Ian Campbell]

On Fri, 2016-03-25 at 01:10 +0100, Karsten Merker wrote: 
> > -   if ((version & 0x) == 0x1650)
> > +   /*
> > +    * Ideally this would be a switch case, bit we do not know exactly
> 
> s/bit/but/

Other than that, both patches:
Acked-by: Ian Campbell 

Ian.
___
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]

On Fri, 25 Mar 2016 07:37:25 +0100, Albert ARIBAUD
 wrote:
> Hello Tom,

> That way,
> 
> 0) U-Boot gets the stable and controlled AEABI support you want;
> 
> 1) GCC keeps its somewhat stable but uncontrolled internal "generated
>code / libgcc" interface;
> 
> 2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
>i.e. whatever ibgcc-related but non-AEABI-related changes occur in
>a GCC release, we won't break them changes in non-AEABI ;
> 
> 3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI
>breakages happen in a given GCC toolchain will not break U-Boot.
> 
> 4) This design works with any ARM toolchain -- which is kind of evident
>since it separates generic ARM EABI support from specific toolchain
>support.

Addition: this does not mean we should get rid of the private libgcc
support: it can be useful in case of an issue with the non-aeabi part
of libgcc.

Amicalement,
-- 
Albert.
___
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 Sergey,

On Thu, 24 Mar 2016 18:37:52 -0700 (PDT), Sergey Kubushyn
 wrote:
> On Thu, 24 Mar 2016, Tom Rini wrote:

> U-Boot is a standalone program not supposed to coexist with any external
> applications i.e. it is totally self-sufficient, not living in some kind of
> system environment so it makes perfect sense for it not to use _ANY_
> external parts in the final binary.

Granted U-Boot is standalone as a binary system component, but this
binary, as the produce of GCC, is dependent on libgcc for more than
simply AEABI support, hence my proposal.

Amicalement,
-- 
Albert.
___
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 Tom,

On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini  wrote:
> On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> > Hello Tom,
> > 
> > On Wed, 23 Mar 2016 17:36:17 -0400, 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
> > 
> > (ok, that explains what you mean by AEABI functions -- those are
> > actually not functions defined by the AEABI, but functions that the GCC
> > folks prefixed with __aeabi.)
> 
> No.  For reference,
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> and chapter 4 is all about the support library.  We are entirely in our
> right to do either of (a) use the compiler-provided library (b) provide
> our own implementation of what we need.  The kernel opts for (b) and I
> would like us to follow that as well, consistently, rather than ad-hoc.

Kk, so you did not mean "whatever happens to be aeabi in libgcc, you
meant AEABI itself.

But then what you seek is is not a custom libgcc; it is controlled
AEABI support library.

I'm fine with that, since, contrary to libgcc, it has an external,
stable, definition.

But that is *unrelated* to libgcc, which is not described nor intended
as "AEABI support" -- libgcc exists in all architectures, even non-ARM,
and provides AEABI in the ARM case by accident -- or, more to the point,
by sub-optimal design IMO.

The right design for solving the problems raised by Marek is therefore
to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library"
and link U-Boot *first* against this AEABI support library, *then*
against GCC's libgcc.

Essentially, this 'hijacks' whatever is AEABI from libgcc while not
interfering with what is not AEABI (i.e. what is purely GCC/libgcc
internals).

That way,

0) U-Boot gets the stable and controlled AEABI support you want;

1) GCC keeps its somewhat stable but uncontrolled internal "generated
   code / libgcc" interface;

2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
   i.e. whatever ibgcc-related but non-AEABI-related changes occur in
   a GCC release, we won't break them changes in non-AEABI ;

3) GCC+libgcc won't interfere with AEABI any more, i.

[U-Boot] [PATCH V3] fsl: esdhc: support driver model

[Peng Fan]

Support Driver Model for fsl esdhc driver.

1. Introduce a new structure struct fsl_esdhc_priv
2. Refactor fsl_esdhc_initialize which is originally used by board code.
   - Introduce fsl_esdhc_init to be common usage for DM and non-DM
   - Introduce fsl_esdhc_cfg_to_priv to build the bridge for non-DM part.
   - The original API for board code is still there, but we use
 'fsl_esdhc_cfg_to_priv' and 'fsl_esdhc_init' to serve it.
3. All the functions are changed to use 'struct fsl_esdhc_priv', except
   fsl_esdhc_initialize.
4. Since clk driver is not implemented, use mxc_get_clock to geth
   the clk and fill 'priv->sdhc_clk'.

Has been tested on i.MX6UL 14X14 EVK board:
"
=>dm tree

 simple_bus  [ + ]|   `-- aips-bus@0210
  mmc[ + ]|   |-- usdhc@0219
  mmc[ + ]|   |-- usdhc@02194000

=> mmc list
FSL_SDHC: 0 (SD)
FSL_SDHC: 1 (SD)
"

Signed-off-by: Peng Fan 
Cc: York Sun 
Cc: Yangbo Lu 
Cc: Hector Palacios 
Cc: Eric Nelson 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---

V3:
 Fix build error reported by York for PPC.

V2:
 restructure the V1 patch.
 Introduce fsl_esdhc_priv structure.
 Introduce code to handle cd-gpios and non-removable.

 drivers/mmc/fsl_esdhc.c | 253 
 1 file changed, 213 insertions(+), 40 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index ea5f4bf..3acf9e8 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -72,6 +74,30 @@ struct fsl_esdhc {
uintscr;/* eSDHC control register */
 };
 
+/**
+ * struct fsl_esdhc_priv
+ *
+ * @esdhc_regs: registers of the sdhc controller
+ * @sdhc_clk: Current clk of the sdhc controller
+ * @bus_width: bus width, 1bit, 4bit or 8bit
+ * @cfg: mmc config
+ * @mmc: mmc
+ * Following is used when Driver Model is enabled for MMC
+ * @dev: pointer for the device
+ * @non_removable: 0: removable; 1: non-removable
+ * @cd_gpio: gpio for card detection
+ */
+struct fsl_esdhc_priv {
+   struct fsl_esdhc *esdhc_regs;
+   unsigned int sdhc_clk;
+   unsigned int bus_width;
+   struct mmc_config cfg;
+   struct mmc *mmc;
+   struct udevice *dev;
+   int non_removable;
+   struct gpio_desc cd_gpio;
+};
+
 /* Return the XFERTYP flags for a given command and data packet */
 static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
 {
@@ -118,8 +144,8 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct 
mmc_data *data)
 static void
 esdhc_pio_read_write(struct mmc *mmc, struct mmc_data *data)
 {
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
uint blocks;
char *buffer;
uint databuf;
@@ -180,8 +206,8 @@ esdhc_pio_read_write(struct mmc *mmc, struct mmc_data *data)
 static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data)
 {
int timeout;
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
 #ifdef CONFIG_FSL_LAYERSCAPE
dma_addr_t addr;
 #endif
@@ -312,8 +338,8 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct 
mmc_data *data)
int err = 0;
uintxfertyp;
uintirqstat;
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   volatile struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
 
 #ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111
if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
@@ -482,9 +508,9 @@ out:
 static void set_sysctl(struct mmc *mmc, uint clock)
 {
int div, pre_div;
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   volatile struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
-   int sdhc_clk = cfg->sdhc_clk;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
+   int sdhc_clk = priv->sdhc_clk;
uint clk;
 
if (clock < mmc->cfg->f_min)
@@ -527,8 +553,8 @@ static void set_sysctl(struct mmc *mmc, uint clock)
 #ifdef CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
 static void esdhc_clock_control(struct mmc *mmc, bool enable)
 {
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
u32 value;
u32 time_out;
 
@@ -556,8 +582,8 @@ static void esdhc_clock_control(struct mmc *mmc, bool 
enable)
 
 static void esdhc_set_ios(struct mmc *mmc)
 

Re: [U-Boot] [PATCH] driver: net: ldpaa_eth: return number of buffer seeded

[Prabhakar Kushwaha]

> -Original Message-
> From: york sun
> Sent: Thursday, March 24, 2016 11:08 PM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Cc: joe.hershber...@gmail.com
> Subject: Re: [PATCH] driver: net: ldpaa_eth: return number of buffer seeded
> 
> On 03/18/2016 03:45 AM, Prabhakar Kushwaha wrote:
> > if buffer < 7, return number of buffer seeded to QBMAN.
> >
> > Signed-off-by: Prabhakar Kushwaha 
> > Reported-by: Jose Rivera 
> > ---
> >  drivers/net/ldpaa_eth/ldpaa_eth.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
> > b/drivers/net/ldpaa_eth/ldpaa_eth.c
> > index 8a00bc3..274bcea 100644
> > --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> > +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> > @@ -665,7 +665,7 @@ err_alloc:
> > if (i)
> > goto release_bufs;
> >
> > -   return 0;
> > +   return i;
> >  }
> >
> 
> Prabhakar,
> 
> I don't understand what you are trying to do. If i != 0, it goes to
> "release_bufs" and return from there. So the "return i" here only returns 0.
> 

Thanks York for pointing out.

"return i", is not even required. "return 0" is correct. 
This patch should be rejected. I will update the patchwork

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

[U-Boot] [PATCH V2 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 
---
v2: Enhance the Kconfig description to contain complete details re: how to
run rpi_2_defconfig on a Raspberry Pi 3.
---
 arch/arm/mach-bcm283x/Kconfig | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index dc6770437ec6..1f3031d8123f 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -14,12 +14,38 @@ 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 also supports BCM2837-based variants such as the RPi 3
+ Model B, when run in 32-bit mode, provided you have configured the
+ VideoCore firmware to select the PL011 UART for the console by:
+ a) config.txt should contain dtoverlay=pi3-miniuart-bt.
+ b) You should run the following to tell the VC FW to process DT when
+ booting, and copy u-boot.bin.img (rather than u-boot.bin) to the SD
+ card as the kernel image:
+
+  path/to/kernel/scripts/mkknlimg --dtok u-boot.bin u-boot.bin.img
+
+ This works as of firmware.git commit 046effa13ebc "firmware:
+ arm_loader: emmc clock depends on core clock See:
+ https://github.com/raspberrypi/firmware/issues/572";.
+
+ 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

[U-Boot] [PATCH V2 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 046effa13ebc "firmware: arm_loader: emmc clock depends on
core clock See: https://github.com/raspberrypi/firmware/issues/572";.

Signed-off-by: Stephen Warren 
---
v2:
- Fix Kconfig syntax error.
- Update required VC FW commit ID to cover MMC fix too.
---
 arch/arm/mach-bcm283x/Kconfig   | 22 ++
 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, 84 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 1f3031d8123f..a4d291d29742 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
 
@@ -50,11 +54,28 @@ config TARGET_RPI_2
select BCM2836
select CPU_V7
 
+config TARGET_RPI_3_32B
+   bool "Raspberry Pi 3 32-bit build"
+   help
+ 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"
@@ -65,5 +86,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..20b5cf48f558 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2012-2013,2015 Stephen Warren
+ * (C) Copyright 2012-2016 Stephen Warren
  *
  * SPDX-License-Iden

[U-Boot] [PATCH V2 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 
---
v2: No change.
---
 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 V2 1/5] ARM: bcm2835: move CONFIG_BCM283* to Kconfig

[Stephen Warren]

Signed-off-by: Stephen Warren 
---
v2: No change.

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 V2 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 can 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 requires two
things:
a) config.txt should contain dtoverlay=pi3-miniuart-bt
b) You should run the following to tell the VC FW to process DT when
booting, and copy u-boot.bin.img (rather than u-boot.bin) to the SD card
as the kernel image:

   path/to/kernel/scripts/mkknlimg --dtok u-boot.bin u-boot.bin.img

This works as of firmware.git commit 046effa13ebc "firmware: arm_loader:
emmc clock depends on core clock See:
https://github.com/raspberrypi/firmware/issues/572";.

Signed-off-by: Stephen Warren 
---
v2: Enhance the commit description to contain complete details re: how to
run rpi_2_defconfig on a Raspberry Pi 3.
---
 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

Re: [U-Boot] [PATCH v2 0/5] Enable caches for the RPi2

[Stephen Warren]

On 03/16/2016 08:41 AM, Alexander Graf wrote:

This patch set converts the Raspberry Pi 2 system to properly make use of
the caches available in it.

Because we're running in HYP mode, we first need to teach U-Boot how to
make use of HYP registers and the LPAE page layout which is mandated by
hardware when running in HYP mode.

Then while we're at it, also mark the frame buffer cached to speed up
screen updates.

With this patch set, my Raspberry Pi 3 running in AArch32 mode is a *lot*
faster than without.

Please verify that the code works on a RPi2 as well and doesn't break the
original Pi. In theory it should work, but I only have a 3 to test on
available here.


I did find one quirk with this series (as tested in my rpi_dev branch on 
github): HDMI console scrolling is now extremely fast for 32-bit builds. 
However, it's noticeably slower on the 64-bit RPi 3 build. I wonder if 
the DCACHE_* constants aren't optimal for AArch64? Perhaps this can all 
be explained instead by RPi 3 needing a slower core clock to support a 
fixed mini UART frequency; that probably slows down the ARM access to DRAM.

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

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

[Stephen Warren]

On 03/24/2016 03:31 AM, 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 
Acked-by: Stephen Warren 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Stephen Warren]

On 03/23/2016 10:54 PM, Stephen Warren wrote:

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.

...

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.


The MMC bug has been fixed, so I'll revise this patch description since 
I have to resend anyway.



diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig



+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.


I missed the "help" line there. I fail for adding "comments" and not 
test building:-(

___
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, Tom Rini wrote:


On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 17:36:17 -0400, 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


(ok, that explains what you mean by AEABI functions -- those are
actually not functions defined by the AEABI, but functions that the GCC
folks prefixed with __aeabi.)


No.  For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library.  We are entirely in our
right to do either of (a) use the compiler-provided library (b) provide
our own implementation of what we need.  The kernel opts for (b) and I
would like us to follow that as well, consistently, rather than ad-hoc.


Second that. By having _EVERYTHING_ coming from U-Boot we are taking care of
_ANY_ possible mismatch between what we are building and pre-built toolchain
libraries. Soft float in ARM U-Boot and VFP hard float in most i.MX6/7
toolchains is just one of such prominent examples.

U-Boot is a standalone program not supposed to coexist with any external
applications i.e. it is totally self-sufficient, not living in some kind of
system environment so it makes perfect sense for it not to use _ANY_
external parts in the final binary.

---
**
*  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

[Tom Rini]

On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> Hello Tom,
> 
> On Wed, 23 Mar 2016 17:36:17 -0400, 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
> 
> (ok, that explains what you mean by AEABI functions -- those are
> actually not functions defined by the AEABI, but functions that the GCC
> folks prefixed with __aeabi.)

No.  For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library.  We are entirely in our
right to do either of (a) use the compiler-provided library (b) provide
our own implementation of what we need.  The kernel opts for (b) and I
would like us to follow that as well, consistently, rather than ad-hoc.

-- 
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 Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 08:08 PM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Sergey Kubushyn wrote:


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.


OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc.
I'm
analyzing it right now, will come up with more later today.


OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private
libgcc,
my bad -- thought it would

[U-Boot] [PATCH 1/2] sunxi: Add conditional magic sram poke for A33

[Hans de Goede]

I noticed that for certain SoC versions boot0 does a magic poke when
build for A33. I'm not aware of this actually being necessary anywhere,
but better safe then sorry.

Signed-off-by: Hans de Goede 
---
 arch/arm/cpu/armv7/sunxi/board.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 7653148..73c8727 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -120,18 +120,30 @@ void s_init(void)
 */
 #if defined CONFIG_MACH_SUN6I
setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
-#elif defined CONFIG_MACH_SUN8I_A23
-   uint version;
+#elif defined CONFIG_MACH_SUN8I
+   __maybe_unused uint version;
 
/* Unlock sram version info reg, read it, relock */
setbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
-   version = readl(SUNXI_SRAMC_BASE + 0x24);
+   version = readl(SUNXI_SRAMC_BASE + 0x24) >> 16;
clrbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
 
-   if ((version & 0x) == 0x1650)
+   /*
+* Ideally this would be a switch case, bit we do not know exactly
+* which versions there are and which version needs which settings,
+* so reproduce the per SoC code from the BSP.
+*/
+#if defined CONFIG_MACH_SUN8I_A23
+   if (version == 0x1650)
setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
else /* 0x1661 ? */
setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
+#elif defined CONFIG_MACH_SUN8I_A33
+   if (version != 0x1667)
+   setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
+#endif
+   /* A83T BSP never modifies SUNXI_SRAMC_BASE + 0x44 */
+   /* No H3 BSP, boot0 seems to not modify SUNXI_SRAMC_BASE + 0x44 */
 #endif
 
 #if defined CONFIG_MACH_SUN6I || \
-- 
2.7.3

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

[U-Boot] [PATCH 2/2] sunxi: Print soc-id from sram controller for sun8i boards

[Hans de Goede]

As the need for various magic sram pokes has shown this maybe useful
info to have. e.g. this shows one of my a23 tablets having an id of
1661 rather then the usual 1650 for the a23.

Signed-off-by: Hans de Goede 
---
 arch/arm/cpu/armv7/sunxi/cpu_info.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c 
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index b9bc70c..c0eabdf 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -38,6 +38,20 @@ int sunxi_get_ss_bonding_id(void)
 }
 #endif
 
+#ifdef CONFIG_MACH_SUN8I
+uint sunxi_get_sram_id(void)
+{
+   uint id;
+
+   /* Unlock sram info reg, read it, relock */
+   setbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
+   id = readl(SUNXI_SRAMC_BASE + 0x24) >> 16;
+   clrbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
+
+   return id;
+}
+#endif
+
 #ifdef CONFIG_DISPLAY_CPUINFO
 int print_cpuinfo(void)
 {
@@ -66,15 +80,15 @@ int print_cpuinfo(void)
 #elif defined CONFIG_MACH_SUN7I
puts("CPU:   Allwinner A20 (SUN7I)\n");
 #elif defined CONFIG_MACH_SUN8I_A23
-   puts("CPU:   Allwinner A23 (SUN8I)\n");
+   printf("CPU:   Allwinner A23 (SUN8I %04x)\n", sunxi_get_sram_id());
 #elif defined CONFIG_MACH_SUN8I_A33
-   puts("CPU:   Allwinner A33 (SUN8I)\n");
+   printf("CPU:   Allwinner A33 (SUN8I %04x)\n", sunxi_get_sram_id());
+#elif defined CONFIG_MACH_SUN8I_A83T
+   printf("CPU:   Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
 #elif defined CONFIG_MACH_SUN8I_H3
-   puts("CPU:   Allwinner H3 (SUN8I)\n");
+   printf("CPU:   Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
 #elif defined CONFIG_MACH_SUN9I
puts("CPU:   Allwinner A80 (SUN9I)\n");
-#elif defined CONFIG_MACH_SUN8I_A83T
-   puts("CPU:   Allwinner A83T (SUN8I)\n");
 #else
 #warning Please update cpu_info.c with correct CPU information
puts("CPU:   SUNXI Family\n");
-- 
2.7.3

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

[U-Boot] Need help debugging problem with u-boot cache_v7.c when build with gcc6

[Hans de Goede]

Hi All,

For details see:

https://bugzilla.redhat.com/show_bug.cgi?id=1318788

We could really use a hand from someone who knows the
cache code flushing code well and can check if the
generated assembly works as intended.

The preferred method of communication for this is
through bugzilla.

Thanks & Regards,

Hans
___
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 08:08 PM, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Marek Vasut wrote:
> 
>> On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:
>>> On Thu, 24 Mar 2016, Sergey Kubushyn wrote:
>>>
 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

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 07:43 PM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Sergey Kubushyn wrote:


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.


OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
analyzing it right now, will come up with more later today.


OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private libgcc,
my bad -- thought it would be automatic. Having that defined makes build
fail complaining about assembly syntax in d

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

[Marek Vasut]

On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Sergey Kubushyn wrote:
> 
>> 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 

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

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Sergey Kubushyn wrote:


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 ove

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.


OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
analyzing it right now, will come up with more later today.

---
**
*  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] Variable content dump to memory

[James Chargin]

On 03/24/2016 03:30 AM, Nicolae Rosia wrote:

Hello,

I'm trying to write the contents of a variable to a file using ext4write
but it requires a memory address as input.
Is there an easy way to get the contents of a variable to a particular mem
address?


You weren't completely specific about your needs, but assuming you are 
wanting to write a U-Boot environment variable to memory, try something like


=> # set up a test value
=> setenv var 12345678
=> printenv var
var=12345678
=>
=> # do the actual write
=> mw.l 8002 $var 1
=>
=> # observe memory was set
=> md.l 8001fff0 c
8001fff0: 67ffedc4 dbc98df5 8e71cdd4 628fcacd...g..qb
8002: 12345678 a2fe8db5 df34c767 636dbd37xV4.g.4.7.mc
80020010: 375dfdcb fde86ca2 3f273cdf 1fe951f9..]7.l...<'?.Q..

Also, "help mw".

This was done on something similar to beaglebone x15. You will need to 
use memory addresses that are valid for your target system.


Jim



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



--
Jim Chargin
AJA Video Systems   j...@aja.com
(530) 271-3334  http://www.aja.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] driver: net: ldpaa_eth: return number of buffer seeded

[york sun]

On 03/18/2016 03:45 AM, Prabhakar Kushwaha wrote:
> if buffer < 7, return number of buffer seeded to QBMAN.
> 
> Signed-off-by: Prabhakar Kushwaha 
> Reported-by: Jose Rivera 
> ---
>  drivers/net/ldpaa_eth/ldpaa_eth.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index 8a00bc3..274bcea 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -665,7 +665,7 @@ err_alloc:
>   if (i)
>   goto release_bufs;
>  
> - return 0;
> + return i;
>  }
>  

Prabhakar,

I don't understand what you are trying to do. If i != 0, it goes to
"release_bufs" and return from there. So the "return i" here only returns 0.

York
___
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"

[Tom Rini]

On Tue, Mar 22, 2016 at 05:50:41PM -0700, 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).
> 
> Does anyone know how to contact:
>   Dileep Katta 
> (this email bounces) ?

Sam, can you comment / ack this?  Dileep isn't with Linaro anymore and I
assume isn't overly interested in this area anymore.  Thanks!

> 
>  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, &hs_ep_out);
> - is_high_speed = true;
> - } else {
> + else
>   ret = usb_ep_enable(f_fb->out_ep, &fs_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(&cmd, ":");
>   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;
>   }
> -- 
> 1.8.5
> 

-- 
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] usb: gadget: Move CONFIG_USB_GADGET to Kconfig

[Sam Protsenko]

On Tue, Mar 22, 2016 at 11:37 PM, Stephen Warren  wrote:
> 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?

Yes, you are right. I was assuming that each defconfig file must
define CONFIG_TARGET_ in order to tie itself to corresponding
include/configs/*.h header. It turns out it's not true and I obviously
need to check ".config" file for CONFIG_TARGET_* definition after
doing "make ..._defconfig". This is because some defconfig files
doesn't have CONFIG_TARGET_ definition, but it's enabled as
dependency, or as default value, or whatever. Also I think it's good
idea to check modified defconfig files for consistency with "make
savedefconfig" rule.

I'm going to revise this patch and will submit new version soon.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Variable content dump to memory

[Nicolae Rosia]

Hello,

I'm trying to write the contents of a variable to a file using ext4write
but it requires a memory address as input.
Is there an easy way to get the contents of a variable to a particular mem
address?

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

[U-Boot] cli_simple_run_command results in an unknown reference to "do_bootd" or "parse_string_outer"

[Hugo Heutinck]

Hello, I was attempting to create a custom u-boot command. But I am not
able to get the
"run_command" or "cli_simple_run_command" to work.

I`m building u-boot: am335x_boneblack_defconfig

Attempting to use the "run_command" function results in:

| common/built-in.o: In function `run_command':
|
/home/x/Projects/Yocto/BeagleBoneBlack/build/tmp/work/beaglebone-poky-linux-gnueabi/u-boot/v2015.07+gitAUTOINC+33711bdd4a-r0/git/common/cli.c:43:
undefined reference to `parse_string_outer'

Attempting to use the cli_simple_run_command, see below.

/home/x/Projects/Yocto/BeagleBoneBlack/build/tmp/work/beaglebone-poky-linux-gnueabi/u-boot/v2015.07+gitAUTOINC+33711bdd4a-r0/git/common/command.c:537:
undefined reference to `do_bootd'
scripts/Makefile.spl:214: recipe for target 'spl/u-boot-spl' failed
make[2]: *** [spl/u-boot-spl] Error 1
Makefile:1263: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
Makefile:457: recipe for target '__build_one_by_one' failed
make: *** [__build_one_by_one] Error 2

The small test code is added as cmd_mytestcmd.c in the common/ directory
and in the common/Makefile  "obj-y += cmd_mytestcmd.o" is added at the end
of the file.


#include 
#include 
#include 

#define MAX_CMD_LEN (255)

static int do_mytest(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
int ret = 0;
char cmd[MAX_CMD_LEN] = "load mmc 0:1 ${loadaddr} my.env";
ret = cli_simple_run_command(cmd, 0);
if (ret == 0) {
printf("OK\n");
} else {
printf("NOK\n");
}


return ret;
}

U_BOOT_CMD(
mytestcmd,  1,  0,  do_mytest,
"my test command",
"");


What am I missing here ?
- Is it possible to use the run_command like this ?
- Do I need to configure any special CONFIG to enable this functionality ?
- ???
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] arm: socfpga: migration of CONFIG_SPI_FLASH_BAR

[Denis Bakhvalov]

CONFIG_SPI_FLASH_BAR was deleted from socfpga_common.h
and placed in socfpga_*_defconfig where it makes sense.

Signed-off-by: Denis Bakhvalov 
Reported-by: Denis Bakhvalov 
Cc: Marek Vasut 
Acked-by: Marek Vasut 
---
Changes for v2:
   - Diff was generated from u-boot-socfpga

 configs/socfpga_arria5_defconfig   | 1 +
 configs/socfpga_cyclone5_defconfig | 1 +
 configs/socfpga_de0_nano_soc_defconfig | 1 +
 configs/socfpga_mcvevk_defconfig   | 1 +
 configs/socfpga_sockit_defconfig   | 1 +
 configs/socfpga_socrates_defconfig | 1 +
 configs/socfpga_sr1500_defconfig   | 1 +
 include/configs/socfpga_common.h   | 2 --
 8 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig
index 7b60d95..505a68d 100644
--- a/configs/socfpga_arria5_defconfig
+++ b/configs/socfpga_arria5_defconfig
@@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/socfpga_cyclone5_defconfig 
b/configs/socfpga_cyclone5_defconfig
index 6a487f4..df19a95 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/socfpga_de0_nano_soc_defconfig 
b/configs/socfpga_de0_nano_soc_defconfig
index cfcae5d..bb37825 100644
--- a/configs/socfpga_de0_nano_soc_defconfig
+++ b/configs/socfpga_de0_nano_soc_defconfig
@@ -19,5 +19,6 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
 CONFIG_CADENCE_QSPI=y
 CONFIG_DESIGNWARE_SPI=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/socfpga_mcvevk_defconfig b/configs/socfpga_mcvevk_defconfig
index b6f6a65..8a76aa1 100644
--- a/configs/socfpga_mcvevk_defconfig
+++ b/configs/socfpga_mcvevk_defconfig
@@ -19,5 +19,6 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
 CONFIG_CADENCE_QSPI=y
 CONFIG_DESIGNWARE_SPI=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/socfpga_sockit_defconfig b/configs/socfpga_sockit_defconfig
index f45c3ed..36bb1e1 100644
--- a/configs/socfpga_sockit_defconfig
+++ b/configs/socfpga_sockit_defconfig
@@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/socfpga_socrates_defconfig 
b/configs/socfpga_socrates_defconfig
index e25d09b..937f14f 100644
--- a/configs/socfpga_socrates_defconfig
+++ b/configs/socfpga_socrates_defconfig
@@ -23,5 +23,6 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
 CONFIG_CADENCE_QSPI=y
 CONFIG_DESIGNWARE_SPI=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/socfpga_sr1500_defconfig b/configs/socfpga_sr1500_defconfig
index d499a14..83eada3 100644
--- a/configs/socfpga_sr1500_defconfig
+++ b/configs/socfpga_sr1500_defconfig
@@ -17,6 +17,7 @@ CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 56d32e6..2ad0287 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -93,7 +93,6 @@
 #define CONFIG_CMD_SPI
 #define CONFIG_CMD_SF
 #define CONFIG_SF_DEFAULT_SPEED3000
-#define CONFIG_SPI_FLASH_BAR
 /*
  * The base address is configurable in QSys, each board must specify the
  * base address based on it's particular FPGA configuration. Please note
@@ -219,7 +218,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #endif
 #define CONFIG_CQSPI_DECODER   0
 #define CONFIG_CMD_SF
-#define CONFIG_SPI_FLASH_BAR
 
 /*
  * Designware SPI support
-- 
1.9.1

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

[U-Boot] [PATCH] doc: clarify openssl-based key and certificate generation process

[Andreas Dannenberg]

Add some basic clarification that the dev.key file generated by OpenSSL
contains both the public and private key, and further highlight that
the certificate generated here contains the public key only.

Signed-off-by: Andreas Dannenberg 
---
 doc/uImage.FIT/signature.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index b2f89fc..e487401 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -62,14 +62,14 @@ placed alongside rsa.c, and its functions added to the 
table in image-sig.c
 also.
 
 
-Creating an RSA key and certificate

-To create a new public key, size 2048 bits:
+Creating an RSA key pair and certificate
+
+To create a new public/private key pair, size 2048 bits:
 
 $ openssl genpkey -algorithm RSA -out keys/dev.key \
 -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
 
-To create a certificate for this:
+To create a certificate for this containing the public key:
 
 $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
 
-- 
2.6.4

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

[U-Boot] [PATCH] doc: fix file extension for flattened image tree blob

[Andreas Dannenberg]

Different sections in the document suggest flattened image tree blob
files have a file name extension of .itb. Fix the list of file extensions
to reflect that.

Signed-off-by: Andreas Dannenberg 
---
 doc/uImage.FIT/source_file_format.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/uImage.FIT/source_file_format.txt 
b/doc/uImage.FIT/source_file_format.txt
index 029f481..5d8cda4 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -55,7 +55,7 @@ FIT is formally a flattened device tree (in the libfdt 
meaning), which
 conforms to bindings defined in this document.
 
 .its   - image tree source
-.fit   - flattened image tree blob
+.itb   - flattened image tree blob
 
 c) Image building procedure
 
-- 
2.6.4

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

Re: [U-Boot] Possible mistake in the csu_cslx_ind enum (ns_access.h)

[york sun]

On 03/24/2016 01:17 AM, Vincent wrote:
> Hi,
> I started to port my kernel to the secure world on a LS1021a board, so
> I started to read the reference manual on the CSU component. In Table
> 9.8, we can see that
> 
> - Debug EPU is CSL47[24:16]
> - DDDI is CSL48[24:16]
> - Debug GDI is CSL48[8:0]
> 
> but in ns_access.h the order doesn't seem to fit. If I understand correctly:
> 
> - CSU_CSLX_EPU and CSU_CSLX_COP_DCSR should be exchanged
> - CSU_CSLX_DDI and CSU_CSLX_GDI should be exchanged
> - CSU_CSLX_USB3_PHY should be = 116, not 117
> 
> 
> I don't have any Errata yet, and I might be wrong, so I'd rather have
> a confirmation.
> 
> By the way, there are a lot of 'Reserved' entry that have a name (like
> CSU_CSLX_GIC for example), am I lacking some information ?
> 

Vincent,

I can't explain. It doesn't match the document I have.

Alison/Mingkai,

Can you comment?

York


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

Re: [U-Boot] [PATCH v2] arm: socfpga: migration of CONFIG_SPI_FLASH_BAR

[Marek Vasut]

On 03/24/2016 09:45 AM, Denis Bakhvalov wrote:
> CONFIG_SPI_FLASH_BAR was deleted from socfpga_common.h
> and placed in socfpga_*_defconfig where it makes sense.

When I read the commit message and I pretend to have no experience with
socfpga, the following question comes to mind:

And why exactly does it make sense in configs/socfpga_* and not in
include/configs/socfpga_common.h ?

The commit message should answer this. (sorry for torturing you here,
hope you don't mind)

> Signed-off-by: Denis Bakhvalov 
> Reported-by: Denis Bakhvalov 
> Cc: Marek Vasut 
> Acked-by: Marek Vasut 
> ---
> Changes for v2:
>- Diff was generated from u-boot-socfpga

Thanks. Can you fix the commit message and do a V3 so I can apply it?
Also, thanks for using the git send-email :)

>  configs/socfpga_arria5_defconfig   | 1 +
>  configs/socfpga_cyclone5_defconfig | 1 +
>  configs/socfpga_de0_nano_soc_defconfig | 1 +
>  configs/socfpga_mcvevk_defconfig   | 1 +
>  configs/socfpga_sockit_defconfig   | 1 +
>  configs/socfpga_socrates_defconfig | 1 +
>  configs/socfpga_sr1500_defconfig   | 1 +
>  include/configs/socfpga_common.h   | 2 --
>  8 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/configs/socfpga_arria5_defconfig 
> b/configs/socfpga_arria5_defconfig
> index 7b60d95..505a68d 100644
> --- a/configs/socfpga_arria5_defconfig
> +++ b/configs/socfpga_arria5_defconfig
> @@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> +CONFIG_SPI_FLASH_BAR=y
>  CONFIG_DM_ETH=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_SYS_NS16550=y
> diff --git a/configs/socfpga_cyclone5_defconfig 
> b/configs/socfpga_cyclone5_defconfig
> index 6a487f4..df19a95 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> +CONFIG_SPI_FLASH_BAR=y
>  CONFIG_DM_ETH=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_SYS_NS16550=y
> diff --git a/configs/socfpga_de0_nano_soc_defconfig 
> b/configs/socfpga_de0_nano_soc_defconfig
> index cfcae5d..bb37825 100644
> --- a/configs/socfpga_de0_nano_soc_defconfig
> +++ b/configs/socfpga_de0_nano_soc_defconfig
> @@ -19,5 +19,6 @@ CONFIG_ETH_DESIGNWARE=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_CADENCE_QSPI=y
>  CONFIG_DESIGNWARE_SPI=y
> +CONFIG_SPI_FLASH_BAR=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> diff --git a/configs/socfpga_mcvevk_defconfig 
> b/configs/socfpga_mcvevk_defconfig
> index b6f6a65..8a76aa1 100644
> --- a/configs/socfpga_mcvevk_defconfig
> +++ b/configs/socfpga_mcvevk_defconfig
> @@ -19,5 +19,6 @@ CONFIG_ETH_DESIGNWARE=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_CADENCE_QSPI=y
>  CONFIG_DESIGNWARE_SPI=y
> +CONFIG_SPI_FLASH_BAR=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> diff --git a/configs/socfpga_sockit_defconfig 
> b/configs/socfpga_sockit_defconfig
> index f45c3ed..36bb1e1 100644
> --- a/configs/socfpga_sockit_defconfig
> +++ b/configs/socfpga_sockit_defconfig
> @@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> +CONFIG_SPI_FLASH_BAR=y
>  CONFIG_DM_ETH=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_SYS_NS16550=y
> diff --git a/configs/socfpga_socrates_defconfig 
> b/configs/socfpga_socrates_defconfig
> index e25d09b..937f14f 100644
> --- a/configs/socfpga_socrates_defconfig
> +++ b/configs/socfpga_socrates_defconfig
> @@ -23,5 +23,6 @@ CONFIG_ETH_DESIGNWARE=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_CADENCE_QSPI=y
>  CONFIG_DESIGNWARE_SPI=y
> +CONFIG_SPI_FLASH_BAR=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> diff --git a/configs/socfpga_sr1500_defconfig 
> b/configs/socfpga_sr1500_defconfig
> index d499a14..83eada3 100644
> --- a/configs/socfpga_sr1500_defconfig
> +++ b/configs/socfpga_sr1500_defconfig
> @@ -17,6 +17,7 @@ CONFIG_DM_MMC=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> +CONFIG_SPI_FLASH_BAR=y
>  CONFIG_DM_ETH=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_SYS_NS16550=y
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index 56d32e6..2ad0287 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -93,7 +93,6 @@
>  #define CONFIG_CMD_SPI
>  #define CONFIG_CMD_SF
>  #define CONFIG_SF_DEFAULT_SPEED  3000
> -#define CONFIG_SPI_FLASH_BAR
>  /*
>   * The base address is configurable in QSys, each board must specify the
>   * base address based on it's particular FPGA configuration. Please note
> @@ -219,7 +218,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  #endif
>  #define CONFIG_CQSPI_DECODER 0
>  #define CONFIG_CMD_SF
> -#define CONFIG_SPI_FLASH_BAR
>  
>  /*
>   * Designware SPI support
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing l

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

[Sam Protsenko]

On Thu, Mar 24, 2016 at 7:31 AM, Lokesh Vutla  wrote:
>
>
> 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 :).

Agree, it's better course of actions.

> This is because DMA is failing. Can you please try this patch[1].
>
> [1] http://patchwork.ozlabs.org/patch/601463/
>

Mentioned patch fixes fastboot. Now it works as expected. The only new
thing I noticed (which appeared after applying that patch) is next
message (showed after running "fastboot 0" command):

UNKNOWN IRQ type 1683973225

It's harmless though, fastboot works as expected. So I presume we
should merge that DMA patch, as it's obviously useful and fixes real
bug.

Thanks for helping me out :)

> 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] [PATCH 06/10] pinctrl: uniphier: use devm_get_addr() to get base address

[Masahiro Yamada]

Currently, fdtdec_get_addr_size() does not support the address
translation, so it cannot handle device trees with non-straight
"ranges" properties.  (This would be a problem with DTS for UniPhier
ARMv8 SoCs.)

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
index ffdccab..ac3a06c 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
@@ -8,13 +8,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include "pinctrl-uniphier.h"
 
-DECLARE_GLOBAL_DATA_PTR;
-
 static int uniphier_pinctrl_get_groups_count(struct udevice *dev)
 {
struct uniphier_pinctrl_priv *priv = dev_get_priv(dev);
@@ -128,14 +127,12 @@ int uniphier_pinctrl_probe(struct udevice *dev,
 {
struct uniphier_pinctrl_priv *priv = dev_get_priv(dev);
fdt_addr_t addr;
-   fdt_size_t size;
 
-   addr = fdtdec_get_addr_size(gd->fdt_blob, dev->of_offset, "reg",
-   &size);
+   addr = dev_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
 
-   priv->base = map_sysmem(addr, size);
+   priv->base = map_sysmem(addr, SZ_4K);
if (!priv->base)
return -ENOMEM;
 
-- 
1.9.1

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

[U-Boot] [PATCH 00/10] ARM: uniphier: driver updates for ARMv8 SoCs support

[Masahiro Yamada]

Masahiro Yamada (10):
  serial: uniphier: use devm_get_addr() to get base address
  clk: uniphier: use devm_get_addr() to get base address
  i2c: uniphier: use devm_get_addr() to get base address
  gpio: uniphier: use devm_get_addr() to get base address
  mmc: uniphier: use devm_get_addr() to get base address
  pinctrl: uniphier: use devm_get_addr() to get base address
  pinctrl: uniphier: introduce quirks flags
  pinctrl: uniphier: support per-pin input enable quirk for new SoCs
  pinctrl: uniphier: support UniPhier PH1-LD20 pinctrl driver
  pinctrl: uniphier: support UniPhier PH1-LD11 pinctrl driver

 drivers/clk/uniphier/clk-uniphier-core.c |   9 +-
 drivers/gpio/gpio-uniphier.c |   8 +-
 drivers/i2c/i2c-uniphier-f.c |  12 +--
 drivers/i2c/i2c-uniphier.c   |  11 +--
 drivers/mmc/uniphier-sd.c|   9 +-
 drivers/pinctrl/uniphier/Kconfig |   6 ++
 drivers/pinctrl/uniphier/Makefile|   1 +
 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c |  64 ++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 114 +++
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c  |   3 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c |   3 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c |   4 +-
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c |   4 +-
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs2.c |   3 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c |   3 -
 drivers/pinctrl/uniphier/pinctrl-uniphier.h  |  10 +-
 drivers/serial/serial_uniphier.c |   8 +-
 17 files changed, 208 insertions(+), 64 deletions(-)
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c

-- 
1.9.1

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

[U-Boot] [PATCH 07/10] pinctrl: uniphier: introduce quirks flags

[Masahiro Yamada]

The core part of the UniPhier pinctrl driver needs to support a new
quirk for upcoming UniPhier ARMv8 SoCs.  This often happens because
pinctrl drivers include really SoC-specific stuff.

This commit intends to tidy up SoC-specific parameters of the existing
drivers before adding new ones.  Having flags would be better than
adding new members every time a new SoC-specific quirk comes up.

At this time, there is one flag, UNIPHIER_PINCTRL_DBGMUX_SEPARATE.
This quirk was added for PH1-Pro4 and PH1-Pro5 as requirement from
our customer.  For those SoCs, one pinmux setting is controlled by
the combination of two separate registers; LSB bits at register offset
(8 * N) and MSB bits at (8 * N + 4).  Because it is impossible to
update two separate registers atomically, the LOAD_PINCTRL register
should be set in order to make the pinmux settings really effective.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 27 
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c  |  3 ---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c |  3 ---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c |  4 +---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c |  4 +---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs2.c |  3 ---
 drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c |  3 ---
 drivers/pinctrl/uniphier/pinctrl-uniphier.h  |  8 +++
 8 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
index ac3a06c..7a6c95c 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
@@ -68,14 +68,33 @@ static void uniphier_pinmux_set_one(struct udevice *dev, 
unsigned pin,
unsigned muxval)
 {
struct uniphier_pinctrl_priv *priv = dev_get_priv(dev);
-   unsigned mux_bits = priv->socdata->mux_bits;
-   unsigned reg_stride = priv->socdata->reg_stride;
-   unsigned reg, reg_end, shift, mask;
+   unsigned mux_bits, reg_stride, reg, reg_end, shift, mask;
+   bool load_pinctrl;
u32 tmp;
 
/* some pins need input-enabling */
uniphier_pinconf_input_enable(dev, pin);
 
+   if (priv->socdata->quirks & UNIPHIER_PINCTRL_DBGMUX_SEPARATE) {
+   /*
+*  Mode   offsetbit
+*  Normal 4 * n shift+3:shift
+*  Debug  4 * n shift+7:shift+4
+*/
+   mux_bits = 4;
+   reg_stride = 8;
+   load_pinctrl = true;
+   } else {
+   /*
+*  Mode   offset   bit
+*  Normal 8 * nshift+3:shift
+*  Debug  8 * n + 4shift+3:shift
+*/
+   mux_bits = 8;
+   reg_stride = 4;
+   load_pinctrl = false;
+   }
+
reg = UNIPHIER_PINCTRL_PINMUX_BASE + pin * mux_bits / 32 * reg_stride;
reg_end = reg + reg_stride;
shift = pin * mux_bits % 32;
@@ -94,7 +113,7 @@ static void uniphier_pinmux_set_one(struct udevice *dev, 
unsigned pin,
muxval >>= mux_bits;
}
 
-   if (priv->socdata->load_pinctrl)
+   if (load_pinctrl)
writel(1, priv->base + UNIPHIER_PINCTRL_LOAD_PINMUX);
 }
 
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c
index b3d47f0..8f7574e 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c
@@ -107,9 +107,6 @@ static struct uniphier_pinctrl_socdata 
ph1_ld4_pinctrl_socdata = {
.groups_count = ARRAY_SIZE(ph1_ld4_groups),
.functions = ph1_ld4_functions,
.functions_count = ARRAY_SIZE(ph1_ld4_functions),
-   .mux_bits = 8,
-   .reg_stride = 4,
-   .load_pinctrl = false,
 };
 
 static int ph1_ld4_pinctrl_probe(struct udevice *dev)
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c
index 8703a21..2a5d5f3 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c
@@ -107,9 +107,6 @@ static struct uniphier_pinctrl_socdata 
ph1_ld6b_pinctrl_socdata = {
.groups_count = ARRAY_SIZE(ph1_ld6b_groups),
.functions = ph1_ld6b_functions,
.functions_count = ARRAY_SIZE(ph1_ld6b_functions),
-   .mux_bits = 8,
-   .reg_stride = 4,
-   .load_pinctrl = false,
 };
 
 static int ph1_ld6b_pinctrl_probe(struct udevice *dev)
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c
index b3eaf13..e07fafb 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c
@@ -103,9 +103,7 @@ static struct uniphier_pinctrl_socd

[U-Boot] [PATCH 09/10] pinctrl: uniphier: support UniPhier PH1-LD20 pinctrl driver

[Masahiro Yamada]

Add pin configuration and pinmux support for UniPhier PH1-LD20 SoC.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/uniphier/Kconfig |   6 ++
 drivers/pinctrl/uniphier/Makefile|   1 +
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 113 +++
 3 files changed, 120 insertions(+)
 create mode 100644 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index d22d485..626df8e 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -39,4 +39,10 @@ config PINCTRL_UNIPHIER_LD6B
default y
select PINCTRL_UNIPHIER
 
+config PINCTRL_UNIPHIER_LD20
+   bool "UniPhier PH1-LD20 SoC pinctrl driver"
+   depends on ARCH_UNIPHIER_LD20
+   default y
+   select PINCTRL_UNIPHIER
+
 endif
diff --git a/drivers/pinctrl/uniphier/Makefile 
b/drivers/pinctrl/uniphier/Makefile
index c6cc13d..bea4dd8 100644
--- a/drivers/pinctrl/uniphier/Makefile
+++ b/drivers/pinctrl/uniphier/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_PINCTRL_UNIPHIER_SLD8)   += 
pinctrl-uniphier-sld8.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PRO5)+= pinctrl-uniphier-pro5.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_PXS2)+= pinctrl-uniphier-pxs2.o
 obj-$(CONFIG_PINCTRL_UNIPHIER_LD6B)+= pinctrl-uniphier-ld6b.o
+obj-$(CONFIG_PINCTRL_UNIPHIER_LD20)+= pinctrl-uniphier-ld20.o
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
new file mode 100644
index 000..9209109
--- /dev/null
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
@@ -0,0 +1,113 @@
+/*
+ * Copyright (C) 2016 Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+#include "pinctrl-uniphier.h"
+
+static const unsigned emmc_pins[] = {18, 19, 20, 21, 22, 23, 24, 25};
+static const unsigned emmc_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0};
+static const unsigned emmc_dat8_pins[] = {26, 27, 28, 29};
+static const unsigned emmc_dat8_muxvals[] = {0, 0, 0, 0};
+static const unsigned i2c0_pins[] = {63, 64};
+static const unsigned i2c0_muxvals[] = {0, 0};
+static const unsigned i2c1_pins[] = {65, 66};
+static const unsigned i2c1_muxvals[] = {0, 0};
+static const unsigned i2c3_pins[] = {67, 68};
+static const unsigned i2c3_muxvals[] = {1, 1};
+static const unsigned i2c4_pins[] = {61, 62};
+static const unsigned i2c4_muxvals[] = {1, 1};
+static const unsigned nand_pins[] = {3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
+15, 16};
+static const unsigned nand_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0};
+static const unsigned nand_cs1_pins[] = {};
+static const unsigned nand_cs1_muxvals[] = {};
+static const unsigned sd_pins[] = {10, 11, 12, 13, 14, 15, 16, 17};
+static const unsigned sd_muxvals[] = {8, 8, 8, 8, 8, 8, 8, 8};  /* No SDVOLC */
+static const unsigned uart0_pins[] = {54, 55};
+static const unsigned uart0_muxvals[] = {0, 0};
+static const unsigned uart1_pins[] = {58, 59};
+static const unsigned uart1_muxvals[] = {1, 1};
+static const unsigned uart2_pins[] = {90, 91};
+static const unsigned uart2_muxvals[] = {1, 1};
+static const unsigned uart3_pins[] = {94, 95};
+static const unsigned uart3_muxvals[] = {1, 1};
+static const unsigned usb0_pins[] = {46, 47};
+static const unsigned usb0_muxvals[] = {0, 0};
+static const unsigned usb1_pins[] = {48, 49};
+static const unsigned usb1_muxvals[] = {0, 0};
+static const unsigned usb2_pins[] = {50, 51};
+static const unsigned usb2_muxvals[] = {0, 0};
+static const unsigned usb3_pins[] = {52, 53};
+static const unsigned usb3_muxvals[] = {0, 0};
+
+static const struct uniphier_pinctrl_group uniphier_ld20_groups[] = {
+   UNIPHIER_PINCTRL_GROUP(emmc),
+   UNIPHIER_PINCTRL_GROUP(emmc_dat8),
+   UNIPHIER_PINCTRL_GROUP(i2c0),
+   UNIPHIER_PINCTRL_GROUP(i2c1),
+   UNIPHIER_PINCTRL_GROUP(i2c3),
+   UNIPHIER_PINCTRL_GROUP(i2c4),
+   UNIPHIER_PINCTRL_GROUP(nand),
+   UNIPHIER_PINCTRL_GROUP(nand_cs1),
+   UNIPHIER_PINCTRL_GROUP(sd),
+   UNIPHIER_PINCTRL_GROUP(uart0),
+   UNIPHIER_PINCTRL_GROUP(uart1),
+   UNIPHIER_PINCTRL_GROUP(uart2),
+   UNIPHIER_PINCTRL_GROUP(uart3),
+   UNIPHIER_PINCTRL_GROUP(usb0),
+   UNIPHIER_PINCTRL_GROUP(usb1),
+   UNIPHIER_PINCTRL_GROUP(usb2),
+   UNIPHIER_PINCTRL_GROUP(usb3),
+};
+
+static const char * const uniphier_ld20_functions[] = {
+   "emmc",
+   "i2c0",
+   "i2c1",
+   "i2c3",
+   "i2c4",
+   "nand",
+   "sd",
+   "uart0",
+   "uart1",
+   "uart2",
+   "uart3",
+   "usb0",
+   "usb1",
+   "usb2",
+   "usb3",
+};
+
+static struct uniphier_pinctrl_socdata uniphier_ld20_pinctrl_socdata = {
+   .groups = uniphier_ld20_groups,
+   .groups_count = ARRAY_SIZE(uniphier_ld20_groups),
+   .functions = uniphier_ld20_functions,
+   .functions_coun

[U-Boot] [PATCH 02/10] clk: uniphier: use devm_get_addr() to get base address

[Masahiro Yamada]

Currently, fdtdec_get_addr_size() does not support the address
translation, so it cannot handle device trees with non-straight
"ranges" properties.  (This would be a problem with DTS for UniPhier
ARMv8 SoCs.)

Signed-off-by: Masahiro Yamada 
---

 drivers/clk/uniphier/clk-uniphier-core.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/uniphier/clk-uniphier-core.c 
b/drivers/clk/uniphier/clk-uniphier-core.c
index e79e0ff..25c163b 100644
--- a/drivers/clk/uniphier/clk-uniphier-core.c
+++ b/drivers/clk/uniphier/clk-uniphier-core.c
@@ -8,13 +8,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include "clk-uniphier.h"
 
-DECLARE_GLOBAL_DATA_PTR;
-
 static int uniphier_clk_enable(struct udevice *dev, int index)
 {
struct uniphier_clk_priv *priv = dev_get_priv(dev);
@@ -133,14 +132,12 @@ int uniphier_clk_probe(struct udevice *dev)
 {
struct uniphier_clk_priv *priv = dev_get_priv(dev);
fdt_addr_t addr;
-   fdt_size_t size;
 
-   addr = fdtdec_get_addr_size(gd->fdt_blob, dev->of_offset, "reg",
-   &size);
+   addr = dev_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
 
-   priv->base = map_sysmem(addr, size);
+   priv->base = map_sysmem(addr, SZ_4K);
if (!priv->base)
return -ENOMEM;
 
-- 
1.9.1

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

[U-Boot] [PATCH 08/10] pinctrl: uniphier: support per-pin input enable quirk for new SoCs

[Masahiro Yamada]

Upcoming new pinctrl drivers of PH1-LD11/LD20 support input signal
gating for each pin.  (While, existing ones only support it per pin
group.)  This commit prepares the core part for that.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 28 +++-
 drivers/pinctrl/uniphier/pinctrl-uniphier.h  |  2 ++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
index 7a6c95c..5e7ff02 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
@@ -44,7 +44,23 @@ static const char *uniphier_pinmux_get_function_name(struct 
udevice *dev,
return priv->socdata->functions[selector];
 }
 
-static void uniphier_pinconf_input_enable(struct udevice *dev, unsigned pin)
+static void uniphier_pinconf_input_enable_perpin(struct udevice *dev,
+unsigned pin)
+{
+   struct uniphier_pinctrl_priv *priv = dev_get_priv(dev);
+   unsigned reg;
+   u32 mask, tmp;
+
+   reg = UNIPHIER_PINCTRL_IECTRL + pin / 32 * 4;
+   mask = BIT(pin % 32);
+
+   tmp = readl(priv->base + reg);
+   tmp |= mask;
+   writel(tmp, priv->base + reg);
+}
+
+static void uniphier_pinconf_input_enable_legacy(struct udevice *dev,
+unsigned pin)
 {
struct uniphier_pinctrl_priv *priv = dev_get_priv(dev);
int pins_count = priv->socdata->pins_count;
@@ -64,6 +80,16 @@ static void uniphier_pinconf_input_enable(struct udevice 
*dev, unsigned pin)
}
 }
 
+static void uniphier_pinconf_input_enable(struct udevice *dev, unsigned pin)
+{
+   struct uniphier_pinctrl_priv *priv = dev_get_priv(dev);
+
+   if (priv->socdata->quirks & UNIPHIER_PINCTRL_PERPIN_IECTRL)
+   uniphier_pinconf_input_enable_perpin(dev, pin);
+   else
+   uniphier_pinconf_input_enable_legacy(dev, pin);
+}
+
 static void uniphier_pinmux_set_one(struct udevice *dev, unsigned pin,
unsigned muxval)
 {
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier.h 
b/drivers/pinctrl/uniphier/pinctrl-uniphier.h
index e622d93..0134d06 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier.h
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier.h
@@ -7,6 +7,7 @@
 #ifndef __PINCTRL_UNIPHIER_H__
 #define __PINCTRL_UNIPHIER_H__
 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,7 @@ struct uniphier_pinctrl_socdata {
const char * const *functions;
int functions_count;
unsigned quirks;
+#define UNIPHIER_PINCTRL_PERPIN_IECTRL BIT(1)
 #define UNIPHIER_PINCTRL_DBGMUX_SEPARATE   BIT(0)
 };
 
-- 
1.9.1

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

[U-Boot] [PATCH 04/10] gpio: uniphier: use devm_get_addr() to get base address

[Masahiro Yamada]

Currently, fdtdec_get_addr_size() does not support the address
translation, so it cannot handle device trees with non-straight
"ranges" properties.  (This would be a problem with DTS for UniPhier
ARMv8 SoCs.)

Signed-off-by: Masahiro Yamada 
---

 drivers/gpio/gpio-uniphier.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
index 80bb16e..bde51ea 100644
--- a/drivers/gpio/gpio-uniphier.c
+++ b/drivers/gpio/gpio-uniphier.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -91,17 +92,14 @@ static int uniphier_gpio_probe(struct udevice *dev)
 {
struct uniphier_gpio_priv *priv = dev_get_priv(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-   DECLARE_GLOBAL_DATA_PTR;
fdt_addr_t addr;
-   fdt_size_t size;
unsigned int tmp;
 
-   addr = fdtdec_get_addr_size(gd->fdt_blob, dev->of_offset, "reg",
-   &size);
+   addr = dev_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
 
-   priv->base = map_sysmem(addr, size);
+   priv->base = map_sysmem(addr, SZ_8);
if (!priv->base)
return -ENOMEM;
 
-- 
1.9.1

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

[U-Boot] [PATCH 05/10] mmc: uniphier: use devm_get_addr() to get base address

[Masahiro Yamada]

Currently, fdtdec_get_addr_size() does not support the address
translation, so it cannot handle device trees with non-straight
"ranges" properties.  (This would be a problem with DTS for UniPhier
ARMv8 SoCs.)

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/uniphier-sd.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index 3bc4d94..81a80cd 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -650,15 +651,17 @@ int uniphier_sd_probe(struct udevice *dev)
struct uniphier_sd_priv *priv = dev_get_priv(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
fdt_addr_t base;
-   fdt_size_t size;
struct udevice *clk_dev;
int clk_id;
int ret;
 
priv->dev = dev;
 
-   base = fdtdec_get_addr_size(gd->fdt_blob, dev->of_offset, "reg", &size);
-   priv->regbase = map_sysmem(base, size);
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   priv->regbase = map_sysmem(base, SZ_2K);
if (!priv->regbase)
return -ENOMEM;
 
-- 
1.9.1

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

[U-Boot] [PATCH 10/10] pinctrl: uniphier: support UniPhier PH1-LD11 pinctrl driver

[Masahiro Yamada]

The pinmux of PH1-LD11 is almost a subset of that of PH1-LD20
(as far as used in boot-loader), so this commit makes the driver
shared between the two SoCs.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/uniphier/Kconfig | 4 ++--
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 9 +
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/uniphier/Kconfig b/drivers/pinctrl/uniphier/Kconfig
index 626df8e..1856ff0 100644
--- a/drivers/pinctrl/uniphier/Kconfig
+++ b/drivers/pinctrl/uniphier/Kconfig
@@ -40,8 +40,8 @@ config PINCTRL_UNIPHIER_LD6B
select PINCTRL_UNIPHIER
 
 config PINCTRL_UNIPHIER_LD20
-   bool "UniPhier PH1-LD20 SoC pinctrl driver"
-   depends on ARCH_UNIPHIER_LD20
+   bool "UniPhier PH1-LD11/PH1-LD20 SoC pinctrl driver"
+   depends on ARCH_UNIPHIER_LD11 || ARCH_UNIPHIER_LD20
default y
select PINCTRL_UNIPHIER
 
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
index 9209109..febc73c 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
@@ -55,7 +55,7 @@ static const struct uniphier_pinctrl_group 
uniphier_ld20_groups[] = {
UNIPHIER_PINCTRL_GROUP(i2c4),
UNIPHIER_PINCTRL_GROUP(nand),
UNIPHIER_PINCTRL_GROUP(nand_cs1),
-   UNIPHIER_PINCTRL_GROUP(sd),
+   UNIPHIER_PINCTRL_GROUP(sd), /* SD does not exist for LD11 */
UNIPHIER_PINCTRL_GROUP(uart0),
UNIPHIER_PINCTRL_GROUP(uart1),
UNIPHIER_PINCTRL_GROUP(uart2),
@@ -63,7 +63,7 @@ static const struct uniphier_pinctrl_group 
uniphier_ld20_groups[] = {
UNIPHIER_PINCTRL_GROUP(usb0),
UNIPHIER_PINCTRL_GROUP(usb1),
UNIPHIER_PINCTRL_GROUP(usb2),
-   UNIPHIER_PINCTRL_GROUP(usb3),
+   UNIPHIER_PINCTRL_GROUP(usb3),   /* USB3 does not exist for LD11 */
 };
 
 static const char * const uniphier_ld20_functions[] = {
@@ -73,7 +73,7 @@ static const char * const uniphier_ld20_functions[] = {
"i2c3",
"i2c4",
"nand",
-   "sd",
+   "sd",   /* SD does not exist for LD11 */
"uart0",
"uart1",
"uart2",
@@ -81,7 +81,7 @@ static const char * const uniphier_ld20_functions[] = {
"usb0",
"usb1",
"usb2",
-   "usb3",
+   "usb3", /* USB3 does not exist for LD11 */
 };
 
 static struct uniphier_pinctrl_socdata uniphier_ld20_pinctrl_socdata = {
@@ -98,6 +98,7 @@ static int uniphier_ld20_pinctrl_probe(struct udevice *dev)
 }
 
 static const struct udevice_id uniphier_ld20_pinctrl_match[] = {
+   { .compatible = "socionext,ph1-ld11-pinctrl" },
{ .compatible = "socionext,ph1-ld20-pinctrl" },
{ /* sentinel */ }
 };
-- 
1.9.1

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

[U-Boot] [PATCH 03/10] i2c: uniphier: use devm_get_addr() to get base address

[Masahiro Yamada]

Currently, fdtdec_get_addr_size() does not support the address
translation, so it cannot handle device trees with non-straight
"ranges" properties.  (This would be a problem with DTS for UniPhier
ARMv8 SoCs.)

Signed-off-by: Masahiro Yamada 
---

 drivers/i2c/i2c-uniphier-f.c | 12 +---
 drivers/i2c/i2c-uniphier.c   | 11 +--
 2 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/i2c-uniphier-f.c b/drivers/i2c/i2c-uniphier-f.c
index b3349af..aebdcfc 100644
--- a/drivers/i2c/i2c-uniphier-f.c
+++ b/drivers/i2c/i2c-uniphier-f.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -14,8 +15,6 @@
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 struct uniphier_fi2c_regs {
u32 cr; /* control register */
 #define I2C_CR_MST (1 << 3)/* master mode */
@@ -112,15 +111,14 @@ static int check_device_busy(struct uniphier_fi2c_regs 
__iomem *regs)
 static int uniphier_fi2c_probe(struct udevice *dev)
 {
fdt_addr_t addr;
-   fdt_size_t size;
struct uniphier_fi2c_dev *priv = dev_get_priv(dev);
int ret;
 
-   addr = fdtdec_get_addr_size(gd->fdt_blob, dev->of_offset, "reg",
-   &size);
-
-   priv->regs = map_sysmem(addr, size);
+   addr = dev_get_addr(dev);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
 
+   priv->regs = map_sysmem(addr, SZ_128);
if (!priv->regs)
return -ENOMEM;
 
diff --git a/drivers/i2c/i2c-uniphier.c b/drivers/i2c/i2c-uniphier.c
index 85b9eff..f8221da 100644
--- a/drivers/i2c/i2c-uniphier.c
+++ b/drivers/i2c/i2c-uniphier.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -14,8 +15,6 @@
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 struct uniphier_i2c_regs {
u32 dtrm;   /* data transmission */
 #define I2C_DTRM_STA   (1 << 10)
@@ -48,13 +47,13 @@ struct uniphier_i2c_dev {
 static int uniphier_i2c_probe(struct udevice *dev)
 {
fdt_addr_t addr;
-   fdt_size_t size;
struct uniphier_i2c_dev *priv = dev_get_priv(dev);
 
-   addr = fdtdec_get_addr_size(gd->fdt_blob, dev->of_offset, "reg", &size);
-
-   priv->regs = map_sysmem(addr, size);
+   addr = dev_get_addr(dev);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
 
+   priv->regs = map_sysmem(addr, SZ_64);
if (!priv->regs)
return -ENOMEM;
 
-- 
1.9.1

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

[U-Boot] [PATCH 01/10] serial: uniphier: use devm_get_addr() to get base address

[Masahiro Yamada]

Currently, fdtdec_get_addr_size() does not support the address
translation, so it cannot handle device trees with non-straight
"ranges" properties.  (This would be a problem with DTS for UniPhier
ARMv8 SoCs.)

Signed-off-by: Masahiro Yamada 
---

 drivers/serial/serial_uniphier.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/serial_uniphier.c b/drivers/serial/serial_uniphier.c
index edb9203..525f0a4 100644
--- a/drivers/serial/serial_uniphier.c
+++ b/drivers/serial/serial_uniphier.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -91,12 +92,13 @@ static int uniphier_serial_probe(struct udevice *dev)
struct uniphier_serial_private_data *priv = dev_get_priv(dev);
struct uniphier_serial __iomem *port;
fdt_addr_t base;
-   fdt_size_t size;
u32 tmp;
 
-   base = fdtdec_get_addr_size(gd->fdt_blob, dev->of_offset, "reg", &size);
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
 
-   port = map_sysmem(base, size);
+   port = map_sysmem(base, SZ_64);
if (!port)
return -ENOMEM;
 
-- 
1.9.1

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

[U-Boot] [PATCH] ARM: uniphier: add sramupdate command

[Masahiro Yamada]

This command would be useful to update U-Boot images in SRAM.

Signed-off-by: Masahiro Yamada 
---

 include/configs/uniphier.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index da80c00..059b034 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -229,6 +229,10 @@
"netdev=eth0\0" \
"verify=n\0"\
"nor_base=0x4200\0" \
+   "sramupdate=setexpr tmp_addr $nor_base + 0x5 &&"\
+   "tftpboot $tmp_addr u-boot-spl.bin &&"  \
+   "setexpr tmp_addr $nor_base + 0x6 &&"   \
+   "tftpboot $tmp_addr u-boot.bin\0"   \
"emmcupdate=mmcsetn &&" \
"mmc partconf $mmc_first_dev 0 1 1 &&"  \
"mmc erase 0 800 &&"\
-- 
1.9.1

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

[U-Boot] [PATCH] ARM: uniphier: make u-boot-with-spl.bin really available

[Masahiro Yamada]

Commit d085ecd61b99 ("ARM: uniphier: switch to raw U-Boot image")
claimed that u-boot-with-spl.bin would be useful in its commit log,
but it was not available because the commit missed to define
CONFIG_SPL_MAX_SIZE.  Without it, CONFIG_SPL_PAD_TO is not defined
either (see include/config_fallbacks.h).  So, the SPL image is not
padded correctly.

Signed-off-by: Masahiro Yamada 
---

 include/configs/uniphier.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 5f3d6b8..da80c00 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -279,5 +279,6 @@
 
 #define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_MAX_FOOTPRINT   0x1
+#define CONFIG_SPL_MAX_SIZE0x1
 
 #endif /* __CONFIG_UNIPHIER_COMMON_H__ */
-- 
1.9.1

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

[U-Boot] [PATCH] mtd: nand: denali: max_banks calculation changed in revision 5.1

[Masahiro Yamada]

From: Graham Moore 

Read Denali hardware revision number and use it to
calculate max_banks,  The encoding of max_banks changed
in Denali revision 5.1.

[ Linux commit : 271707b1d817f5104e02b2bd1bab43f0c8759418 ]

Signed-off-by: Graham Moore 
[Brian: parentheses around macro arg]
Signed-off-by: Brian Norris 
[Masahiro: import from Linux and adjust ioread32() to readl() ]
Signed-off-by: Masahiro Yamada 

---

 drivers/mtd/nand/denali.c | 11 ++-
 drivers/mtd/nand/denali.h |  2 ++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 018d14f..5894fcc 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -431,7 +431,16 @@ static void find_valid_banks(struct denali_nand_info 
*denali)
 static void detect_max_banks(struct denali_nand_info *denali)
 {
uint32_t features = readl(denali->flash_reg + FEATURES);
-   denali->max_banks = 2 << (features & FEATURES__N_BANKS);
+   /*
+* Read the revision register, so we can calculate the max_banks
+* properly: the encoding changed from rev 5.0 to 5.1
+*/
+   u32 revision = MAKE_COMPARABLE_REVISION(
+   readl(denali->flash_reg + REVISION));
+   if (revision < REVISION_5_1)
+   denali->max_banks = 2 << (features & FEATURES__N_BANKS);
+   else
+   denali->max_banks = 1 << (features & FEATURES__N_BANKS);
 }
 
 static void detect_partition_feature(struct denali_nand_info *denali)
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index 93b5725..db1457a 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -166,6 +166,8 @@
 
 #define REVISION   0x370
 #define REVISION__VALUE0x
+#define MAKE_COMPARABLE_REVISION(x)swab16((x) & REVISION__VALUE)
+#define REVISION_5_1   0x0501
 
 #define ONFI_DEVICE_FEATURES   0x380
 #define ONFI_DEVICE_FEATURES__VALUE0x003f
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 0/4] net: phy: Force master mode for RTL8211C on some boards

[Chen-Yu Tsai]

Hi,

On Thu, Mar 24, 2016 at 2:46 PM, Michael Haas  wrote:
>
> This patch is required to get reliable 1000BASE-T operation on some
> boards using the RTL8211C(L) PHY.
>
> Following discussions on v2 of this patch, I have removed the incorrect
> check for the RTL8211C(L). Affected boards now have to define
> CONFIG_RTL8211X_PHY_FORCE_MASTER to benefit from the fix.
>
> Note that this patch requires Karsten Merkers '[PATCH] net: phy: Realtek
> RTL8211B/C PHY ID fix' as well as Hans de Goede's recent u-boot-sunxi
> pull request, specifically 1eae8f66ff749409eb96e2f3f3387c56232d0b8a and
> fc8991c61c393ce6a9d3dfc97cb56dbbd9e8cbba.
>
> Michael
>
>
> Changes in v3:
>  - Remove incorrect detection of RTL8211CL and use #ifdef instead
>(thanks to Karsten Merker)
>  - Introduced constants for register bits
>
> Changes in v2:
>  - Removed accidental inclusion of Karsten's patch in my first submission of 
> this series.
>  - Fix a typo in the code: 6 -> &
>
> Michael Haas (4):
>   net: phy: Optionally force master mode for RTL PHY


>   net: phy: Force master mode for A20-Olimex-SOM-EVB
>   net: phy: Force master mode A20-OLinuXino-Lime2

These 2 should probably read:

sunxi: A20-Olx: Force master mode for RTL8211CL

ChenYu

>   net: phy: Add RTL8211X_PHY_FORCE_MASTER to Kconfig
>
>  configs/A20-OLinuXino-Lime2_defconfig |  1 +
>  configs/A20-Olimex-SOM-EVB_defconfig  |  1 +
>  drivers/net/Kconfig   | 17 +
>  drivers/net/phy/realtek.c | 13 -
>  4 files changed, 31 insertions(+), 1 deletion(-)
>
> --
> 2.7.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/4] net: phy: Force master mode for RTL8211C on some boards

[Hans de Goede]

Hi Michael,

On 24-03-16 07:46, Michael Haas wrote:


This patch is required to get reliable 1000BASE-T operation on some
boards using the RTL8211C(L) PHY.

Following discussions on v2 of this patch, I have removed the incorrect
check for the RTL8211C(L). Affected boards now have to define
CONFIG_RTL8211X_PHY_FORCE_MASTER to benefit from the fix.

Note that this patch requires Karsten Merkers '[PATCH] net: phy: Realtek
RTL8211B/C PHY ID fix' as well as Hans de Goede's recent u-boot-sunxi
pull request, specifically 1eae8f66ff749409eb96e2f3f3387c56232d0b8a and
fc8991c61c393ce6a9d3dfc97cb56dbbd9e8cbba.


Thanks for this patch series. I believe you should
squash patch 4 into patch 1, as that is where it belongs
IMHO.

Also note that patch 2/3 will not do anything unless patch 4
is also applied setting CONFIG_FOO in a defconfig does not do
anything unless CONFIG_FOO is defined in Kconfig.

Regards,

Hans





Michael


Changes in v3:
  - Remove incorrect detection of RTL8211CL and use #ifdef instead
(thanks to Karsten Merker)
  - Introduced constants for register bits

Changes in v2:
  - Removed accidental inclusion of Karsten's patch in my first submission of 
this series.
  - Fix a typo in the code: 6 -> &

Michael Haas (4):
   net: phy: Optionally force master mode for RTL PHY
   net: phy: Force master mode for A20-Olimex-SOM-EVB
   net: phy: Force master mode A20-OLinuXino-Lime2
   net: phy: Add RTL8211X_PHY_FORCE_MASTER to Kconfig

  configs/A20-OLinuXino-Lime2_defconfig |  1 +
  configs/A20-Olimex-SOM-EVB_defconfig  |  1 +
  drivers/net/Kconfig   | 17 +
  drivers/net/phy/realtek.c | 13 -
  4 files changed, 31 insertions(+), 1 deletion(-)


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

[U-Boot] [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

Acked-by: Lukasz Majewski 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/Kconfig |  4 
 arch/arm/include/asm/types.h | 17 +++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e5f57ef..550ecde 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,10 @@ config SYS_ARCH
 config ARM64
bool
 
+config DMA_ADDR_T_64BIT
+   bool
+   default y if ARM64
+
 config HAS_VBAR
 bool
 
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

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

[Lukasz Majewski]

Hi Lokesh,

> 
> 
> On Thursday 24 March 2016 02:11 PM, Lukasz Majewski wrote:
> > Hi Lokesh,
> > 
> >> 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.
> > 
> > I've already stumbled upon this issue...
> > 
> >>
> >> 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
> > 
> > Generally this approach is correct, but please pay attention to the
> > CONFIG_PHYS_64BIT.
> > 
> > The actual size of dma_addr_t (64 or 32 bits) is decided by
> > defining or undefining CONFIG_PHYS_64BIT at
> > arch/arm/include/asm/config.h. This is based on the status of
> > CONFIG_ARM64.
> > 
> > To avoid regression we need to take into account status of
> > CONFIG_ARM64 to be sure that CONFIG_DMA_ADDR_T_64BIT is set on
> > ARM64 systems.
> 
> Good point. So we need to select DMA_ADDR_T_64BIT by default for all
> ARM64 systems. I guess the below diff should be sufficient along with
> the $subject patch?
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e5f57ef..550ecde 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -7,6 +7,10 @@ config SYS_ARCH
>  config ARM64
>   bool
> 
> +config DMA_ADDR_T_64BIT
> + bool
> + default y if ARM64
> +
>  config HAS_VBAR
>  bool
> 
> 
> Thanks and regards,
> Lokesh
> 

Acked-by: Lukasz Majewski 

> > 
> >> +typedef unsigned long long dma_addr_t;
> >> +#else
> >> +typedef u32 dma_addr_t;
> >> +#endif
> >> +
> >>  #endif /* __KERNEL__ */
> >>  
> >>  typedef unsigned long resource_size_t;
> > 
> > 
> > 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Stefan Roese]

Hi Tom,

please pull the following patches from the marvell git
repository. I plan to send some other patches still under
review a bit later - perhaps in a week or. As I'm off in
Easter vacation starting tomorrow.

Thanks,
Stefan

The following changes since commit d085ecd61b9956cda0d37b89b5c538f54440fe58:

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

are available in the git repository at:

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

for you to fetch changes up to 7497a6a1f13eb86d68a936edecfd682bbad5752d:

  tools: kwboot: Add xmodem timeout option (2016-03-24 10:08:49 +0100)


Andreas Färber (1):
  arm: mvebu: db-88f6820: Drop obsolete binary.0 placeholder

Dirk Eibach (1):
  arm: mvebu: Fix ddr3_init() cpu config

Kevin Smith (2):
  tools: kwboot: Clean up usage text
  tools: kwboot: Add xmodem timeout option

Peter Korsgaard (1):
  ARM: sheevaplug: correct nand partition layout

Stefan Roese (5):
  gpio: Add DM GPIO driver for Marvell MVEBU
  fpga: altera: Add StratixV support
  arm: mvebu: Add some SPI CS attributes
  arm: mvebu: spi.h: Add registers for direct write access
  arm: mvebu: theadorable: Add StratixV FPGA programming support

 arch/arm/dts/armada-xp-theadorable.dts |  21 
 arch/arm/include/asm/arch-mvebu/spi.h  |   3 +
 arch/arm/mach-mvebu/include/mach/cpu.h |   3 +
 board/Marvell/db-88f6820-gp/binary.0   |  16 ---
 board/theadorable/Makefile |   1 +
 board/theadorable/fpga.c   | 179 +
 board/theadorable/theadorable.c|  13 +++
 board/theadorable/theadorable.h|  12 +++
 configs/theadorable_debug_defconfig|   3 +-
 configs/theadorable_defconfig  |   2 +-
 drivers/ddr/marvell/a38x/ddr3_init.c   |   2 -
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/altera.c  |   3 +
 drivers/fpga/stratixv.c| 103 +++
 drivers/gpio/Kconfig   |   7 ++
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/mvebu_gpio.c  | 119 ++
 include/altera.h   |  20 
 include/configs/sheevaplug.h   |   6 +-
 include/configs/theadorable.h  |   5 +
 tools/kwboot.c |  13 ++-
 21 files changed, 507 insertions(+), 26 deletions(-)
 delete mode 100644 board/Marvell/db-88f6820-gp/binary.0
 create mode 100644 board/theadorable/fpga.c
 create mode 100644 board/theadorable/theadorable.h
 create mode 100644 drivers/fpga/stratixv.c
 create mode 100644 drivers/gpio/mvebu_gpio.c

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

Re: [U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Phil Sutter]

On Thu, Mar 24, 2016 at 10:13:35AM +0100, Stefan Roese wrote:
> On 04.01.2016 12:25, Marek Vasut wrote:
> > On Monday, January 04, 2016 at 04:02:26 AM, Phil Sutter wrote:
> >> Hi,
> >>
> >> On Mon, Jan 04, 2016 at 12:47:37AM +0100, Marek Vasut wrote:
> >>> On Monday, January 04, 2016 at 12:38:07 AM, Phil Sutter wrote:
>  The bit which really was missing is the USB mode setting I smuggled in
>  along with my patch - setting the devices to host mode is sufficient
>  for Linux to successfully enumerate the HCD.
> >>>
> >>> OK, so the controller is OTG capable and upon reset, it's in Gadget mode?
> >>
> >> Yes, seems it's capable. Upon reset, register 0x501a0 contains value 0.
> >> Trying to print register 0x511a0 freezes U-Boot for me.
> >
> > 0x501a0 and 0x511a0 are two different registers. Freeze usually indicates
> > disabled clock to the IP block or somesuch.
> >
>  Checking the logs of the vendor's U-Boot fork, it appears that devices
>  1 and 2 are configured to host mode, while the third is set to device
>  mode. I changed my code to copy that, but am not sure it's necessary
>  at all: The DS414 exports only a single port of the SoC's EHCI, and
>  Linux
> 
>  detects that:
>  | orion-ehci f105.usb: EHCI Host Controller
>  | orion-ehci f105.usb: new USB bus registered, assigned bus number
>  | 3 orion-ehci f105.usb: irq 27, io mem 0xf105
>  | orion-ehci f105.usb: USB 2.0 started, EHCI 1.00
>  | hub 3-0:1.0: USB hub found
>  | hub 3-0:1.0: 1 port detected
> 
>  OTOH I'm not sure how far this configuration is device specific in the
>  first place. What puzzles me is that I couldn't find a reference to
>  this USB mode register at 0x501A8 in Marvell's MV78230 specs, still it
>  seems to be crucial. Does anyone of you have this register referenced
>  in some Marvell datasheet somewhere?
> >>>
> >>> It's the USBMODE register, see for example [1] . It's part of EHCI cores
> >>> which are OTG capable.
> >>>
> >>> [1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-hcd.c#L179
> >>
> >> Interesting. I would have expected this to show up in MV78230 specs, but
> >> maybe I missed the part where it clarifies these offsets to be standard
> >> conformant.
> >
> > It seems to be standard comformant, but I didn't see the datasheet.
> >
>  Maybe there's also a more generic way to do this, 'usb start' (which
>  solves the problem without any changes to the SoC init code) seems to
>  not address this register.
> >>>
> >>> Probably add a fixup into ehci-orion.c in Linux or something along those
> >>> lines. It should configure the code according to the "dr_mode" DT prop.
> >>
> >> Hmm. Searching through the relevant DT files didn't yield a result for
> >> "dr_mode". Seems like this property is missing, maybe that's why Linux
> >> fails here?
> >
> > More likely it's not implemented for the MVEBU yet.
> >
> >> Is this something generally user-configurable? (Note that I
> >> don't have the slightest idea of how device mode USB works in Linux).
> >
> > Yes, you can run the core in either Host/Gadget/OTG mode. For that to work,
> > you need to configure the core mode.
> 
> I've not followed the discussion and just now going through my list
> of open patches.
> 
> Phil, what is the current status of this patch? Is it still needed?

I reported the issue to linux-usb list back in January, but never got
any usable reply. So no progress upstream.

Also, it seems that even with this patch the front USB port is not
usable in Linux, no devices are detected.

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

[U-Boot] [PATCH v5 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

v4 -> v5:

  - Align fb start down, not up
---
 drivers/video/bcm2835.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index bff1fcb..cd605e6 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 = gd->fb_base & ~(MMU_SECTION_SIZE - 1);
+   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] tools/kwboot.c: Support UART fallback mode

[Stefan Roese]

Hi Kevin,

On 01.09.2015 14:52, Stefan Roese wrote:

Hi Kevin,

(Added Luka to Cc, as the Marvell / MVEBU custodian)

On 31.08.2015 22:30, Kevin Smith wrote:

On some processors such as Armada 38x, if the hardware-
configured boot mode fails, the CPU falls back to booting over
UART.  When this happens the chip prints a failure message, waits
for the magic sequence and, when it is received, prints a
"(boot)" message, then sends a NAK to start the transfer.

This breaks the current kwboot behavior because the xmodem
transfer only tries to read one character after the magic
sequence, looking for the NAK.  Instead it gets the "(boot)"
text, and retries the magic sequence.  The CPU thinks the
repeated sequence is part of the packet, stops NAKing, and one
side or another eventually times out.

This patch adds support for a fallback mode which continues to
scan for a NAK in the characters received after the sequence,
printing out any non-NAK characters.  This allows kwboot to skip
the "(boot)" message, find the NAK, and start the transfer
successfully.

Signed-off-by: Kevin Smith 


I've not seen this "(boot)" yet. But the patch looks good. So:

Reviewed-by: Stefan Roese 


Is this patch still needed (or helpful)? If yes, please rebase
on top of latest u-boot-marvell/master and send a new version
so that I can pick it up.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Stefan Roese]

On 04.01.2016 12:25, Marek Vasut wrote:

On Monday, January 04, 2016 at 04:02:26 AM, Phil Sutter wrote:

Hi,

On Mon, Jan 04, 2016 at 12:47:37AM +0100, Marek Vasut wrote:

On Monday, January 04, 2016 at 12:38:07 AM, Phil Sutter wrote:

The bit which really was missing is the USB mode setting I smuggled in
along with my patch - setting the devices to host mode is sufficient
for Linux to successfully enumerate the HCD.


OK, so the controller is OTG capable and upon reset, it's in Gadget mode?


Yes, seems it's capable. Upon reset, register 0x501a0 contains value 0.
Trying to print register 0x511a0 freezes U-Boot for me.


0x501a0 and 0x511a0 are two different registers. Freeze usually indicates
disabled clock to the IP block or somesuch.


Checking the logs of the vendor's U-Boot fork, it appears that devices
1 and 2 are configured to host mode, while the third is set to device
mode. I changed my code to copy that, but am not sure it's necessary
at all: The DS414 exports only a single port of the SoC's EHCI, and
Linux

detects that:
| orion-ehci f105.usb: EHCI Host Controller
| orion-ehci f105.usb: new USB bus registered, assigned bus number
| 3 orion-ehci f105.usb: irq 27, io mem 0xf105
| orion-ehci f105.usb: USB 2.0 started, EHCI 1.00
| hub 3-0:1.0: USB hub found
| hub 3-0:1.0: 1 port detected

OTOH I'm not sure how far this configuration is device specific in the
first place. What puzzles me is that I couldn't find a reference to
this USB mode register at 0x501A8 in Marvell's MV78230 specs, still it
seems to be crucial. Does anyone of you have this register referenced
in some Marvell datasheet somewhere?


It's the USBMODE register, see for example [1] . It's part of EHCI cores
which are OTG capable.

[1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-hcd.c#L179


Interesting. I would have expected this to show up in MV78230 specs, but
maybe I missed the part where it clarifies these offsets to be standard
conformant.


It seems to be standard comformant, but I didn't see the datasheet.


Maybe there's also a more generic way to do this, 'usb start' (which
solves the problem without any changes to the SoC init code) seems to
not address this register.


Probably add a fixup into ehci-orion.c in Linux or something along those
lines. It should configure the code according to the "dr_mode" DT prop.


Hmm. Searching through the relevant DT files didn't yield a result for
"dr_mode". Seems like this property is missing, maybe that's why Linux
fails here?


More likely it's not implemented for the MVEBU yet.


Is this something generally user-configurable? (Note that I
don't have the slightest idea of how device mode USB works in Linux).


Yes, you can run the core in either Host/Gadget/OTG mode. For that to work,
you need to configure the core mode.


I've not followed the discussion and just now going through my list
of open patches.

Phil, what is the current status of this patch? Is it still needed?

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 2/2] tools: kwboot: Add xmodem timeout option

[Stefan Roese]

On 16.02.2016 22:28, Kevin Smith wrote:

Add command-line specification of xmodem timeout.  If the binary
header needs to take a while to do something (e.g. DDR ECC
scrubbing), the xmodem transfer can time out.  Add a configurable
xmodem block timeout to allow transfers with slow binary headers
to succeed.

Signed-off-by: Kevin Smith 
Cc: Stefan Roese 


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

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

[Lokesh Vutla]

On Thursday 24 March 2016 02:11 PM, Lukasz Majewski wrote:
> Hi Lokesh,
> 
>> 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.
> 
> I've already stumbled upon this issue...
> 
>>
>> 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
> 
> Generally this approach is correct, but please pay attention to the
> CONFIG_PHYS_64BIT.
> 
> The actual size of dma_addr_t (64 or 32 bits) is decided by defining or
> undefining CONFIG_PHYS_64BIT at arch/arm/include/asm/config.h. This is
> based on the status of CONFIG_ARM64.
> 
> To avoid regression we need to take into account status of CONFIG_ARM64
> to be sure that CONFIG_DMA_ADDR_T_64BIT is set on ARM64 systems.

Good point. So we need to select DMA_ADDR_T_64BIT by default for all
ARM64 systems. I guess the below diff should be sufficient along with
the $subject patch?

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e5f57ef..550ecde 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,10 @@ config SYS_ARCH
 config ARM64
bool

+config DMA_ADDR_T_64BIT
+   bool
+   default y if ARM64
+
 config HAS_VBAR
 bool


Thanks and regards,
Lokesh

> 
>> +typedef unsigned long long dma_addr_t;
>> +#else
>> +typedef u32 dma_addr_t;
>> +#endif
>> +
>>  #endif /* __KERNEL__ */
>>  
>>  typedef unsigned long resource_size_t;
> 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] tools: kwboot: Clean up usage text

[Stefan Roese]

On 16.02.2016 22:28, Kevin Smith wrote:

Usage text was getting unwieldy and somewhat incorrect.  The
usage summary implied that some options were mutually exclusive
(e.g. -q or -s).  Clean up the summary to just include the
important ones, and include a generic "[OPTIONS]" instead.

Signed-off-by: Kevin Smith 
Cc: Stefan Roese 


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] arm: mvebu: db-88f6820: Drop obsolete binary.0 placeholder

[Stefan Roese]

On 15.02.2016 19:13, Andreas Färber wrote:

It has been superseded in kwbimage.cfg in favor of an SPL in commit
9e30b31d20f0b793465d07f056b3d9885f578c0d (arm: mvebu: db-88f6820: Add
SPL support with DDR init code). Found via code review.

Cc: Stefan Roese 
Signed-off-by: Andreas Färber 


Applied to u-boot-marvell/master.

Thanks,
Stefan

___
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

[Alexander Graf]

> Am 24.03.2016 um 03:05 schrieb 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).

Yes, my bad. I'll send another version.

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

Re: [U-Boot] [PATCH 3/3 v2] arm: mvebu: theadorable: Add StratixV FPGA programming support

[Stefan Roese]

On 12.02.2016 14:24, Stefan Roese wrote:

This patch adds support for Altera StratixV bitstream programming. 2 FPGAs
are connected to the SPI busses. This patch uses board specific write
code to program the bitstream via SPI direct write mode.

Signed-off-by: Stefan Roese 
Cc: Luka Perkov 
---
v2:
- Add missing mbus mapping for the SPI devices (direct access mode)


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 1/3] arm: mvebu: Add some SPI CS attributes

[Stefan Roese]

On 12.02.2016 13:52, Stefan Roese wrote:

These attribute defines may be used to map an area of memory for direct
access to the specific SPI devices. See SPI Direct Access Mode for
further information.

Signed-off-by: Stefan Roese 
Cc: Luka Perkov 


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 2/3] arm: mvebu: spi.h: Add registers for direct write access

[Stefan Roese]

On 12.02.2016 13:52, Stefan Roese wrote:

The direct write config register is needed for SPI direct write mode
configuration.

Signed-off-by: Stefan Roese 
Cc: Luka Perkov 


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] fpga: altera: Add StratixV support

[Stefan Roese]

On 12.02.2016 13:48, Stefan Roese wrote:

This patch adds support for programming of the StratixV FPGAs. Programming
is done in this case (board theadorable) via SPI. The board may provide
board specific code for bitstream programming.

This StratixV support will be used by the theadorable board.

Signed-off-by: Stefan Roese 
Cc: Tom Rini 


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] gpio: Add DM GPIO driver for Marvell MVEBU

[Stefan Roese]

On 12.02.2016 13:46, Stefan Roese wrote:

This patch adds a DM GPIO driver for the Marvell MVEBU SoCs. There are
other non-DM drivers that might be used on these platforms. But this
patch creates a new DM driver. Which will be used by all Armada XP/38x
boards. Other MVEBU SoC (Kirkwood / Orion) may follow once they
support DM as well.

Signed-off-by: Stefan Roese 
Cc: Dirk Eibach 
Cc: Phil Sutter 
Cc: Kevin Smith 
Cc: Luka Perkov 
Cc: Tom Rini 


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

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

[Lukasz Majewski]

Hi Lokesh,

> 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.

I've already stumbled upon this issue...

> 
> 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

Generally this approach is correct, but please pay attention to the
CONFIG_PHYS_64BIT.

The actual size of dma_addr_t (64 or 32 bits) is decided by defining or
undefining CONFIG_PHYS_64BIT at arch/arm/include/asm/config.h. This is
based on the status of CONFIG_ARM64.

To avoid regression we need to take into account status of CONFIG_ARM64
to be sure that CONFIG_DMA_ADDR_T_64BIT is set on ARM64 systems.

> +typedef unsigned long long dma_addr_t;
> +#else
> +typedef u32 dma_addr_t;
> +#endif
> +
>  #endif /* __KERNEL__ */
>  
>  typedef unsigned long resource_size_t;



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] kirkwood_nand: claim MPP pins on the fly

[Stefan Roese]

On 02.02.2016 00:35, Chris Packham wrote:

Claim the MPP pins for the NAND flash controller only when it's actually
being used. This allows the pins to be shared with the SPI interface
which already supports an equivalent on-access MPP reconfiguration.

Reviewed-by: Mark Tomlinson 
Signed-off-by: Chris Packham 
---
I haven't wrapped this with a configuration option because I think it
should be safe to enable by default. It will either re-apply the same
MPP configuration that has already been done in the board init or put
the MPP pins into the correct mode to access NAND.

I've only got access to one kirkwood based board with NAND flash so I'd
appreciate some feedback from someone with access to a few different
boards.

 From the datasheets I have access to it looks like there is only one
possible MPP configuration for NF_IO[0-7] so that is what I've
implemented. I'm not aware of anything using this driver that needs a
different MPP config.

Changes in v2:
- make nand_config static const


Scott, are you okay with this patch in v2? If yes, will you pull it?
Or should I include it in a marvell pull request?

Thanks,
Stefan

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

Re: [U-Boot] [PATCH v0 4/5] arm: mvebu: Fix ddr3_init() cpu config

[Stefan Roese]

On 28.10.2015 16:44, dirk.eib...@gdsys.cc wrote:

From: Dirk Eibach 

Armada 38x has a maximum of two cores. Probably copy/paste
bug from Armada XP.

Signed-off-by: Dirk Eibach 


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] arm: mvebu: enable generic distro boot config

[Stefan Roese]

Hi Dennis,

On 27.01.2016 07:45, Stefan Roese wrote:

Hi Dennis,

On 15.01.2016 02:20, Dennis Gilmore wrote:

Switch all of the mvebu boards to support disto generic booting
This will enable Fedora, Debian and other distros to support
mvebu systems easier. Tested on SolidRun ClearFog


Sorry for the late review. I have a few issues with this patch.
It generates build errors on some mvebu boards:

ds414 db-88f6820-gp db-mv784mp-gp

Mostly because of redefined macros:

This one (db-mv784mp-gp):

include/configs/mv-common.h:187:0: warning: "CONFIG_PREBOOT" redefined
  #define CONFIG_PREBOOT  "sata init"
  ^
In file included from include/configs/db-mv784mp-gp.h:100:0,
  from include/config.h:5,
  from include/common.h:18,
  from examples/standalone/hello_world.c:8:
include/configs/mv-common.h:61:0: note: this is the location of the previous 
definition
  #define CONFIG_PREBOOT


Or this one (db-88f6820-gp):

include/configs/mv-common.h:236:0: warning: "CONFIG_EXTRA_ENV_SETTINGS" 
redefined
  #define CONFIG_EXTRA_ENV_SETTINGS
  ^
In file included from include/config.h:5:0,
  from include/common.h:18,
  from drivers/ddr/marvell/a38x/xor.c:7:
include/configs/db-88f6820-gp.h:108:0: note: this is the location of the 
previous definition
  #define CONFIG_EXTRA_ENV_SETTINGS \


Or this one (ds414):

include/configs/ds414.h:156:0: warning: "CONFIG_BOOTCOMMAND" redefined
#define CONFIG_BOOTCOMMAND "sf read ${loadaddr} 0xd 0x70; bootm"
^
In file included from include/configs/mv-common.h:204:0,
from include/configs/ds414.h:104,
from include/config.h:5,
from include/common.h:18,
from include/ubi_uboot.h:17,
from fs/ubifs/ubifs.h:37,
from fs/ubifs/recovery.c:45:


Perhaps it makes sense to not move all mvebu boards to the
generic distro booting. But only the Marvell eval boards and
the community boards, like the clearfog (and not the ds414
for example).

What do you think?


Did you find the time to look into this?

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 4/4] ARM: sheevaplug: correct nand partition layout

[Stefan Roese]

On 17.01.2016 18:23, Peter Korsgaard wrote:

Commit 1e3d640316 (ARM: sheevaplug: redefine MTDPARTS) changed the partition
layout (without any description why), but didn't change the offset/size to
load the kernel from or the root=/dev/mtdblockX in the bootargs.

The 3MB forseen for a kernel is furthermore too little. A 4.4 build of
mvebu_v5_defconfig is 3.6MB:

-rw-r--r-- 1 peko peko 3.6M Jan 16 20:24 uImage.kirkwood-sheevaplug

When device tree support for sheevaplug was added to the kernel in commit
ee514b381e (ARM: Kirkwood: Add dts files for Sheevaplug and eSATA
Sheevaplug) a default flash partition layout (used if mtdparts= isn't passed
on the command line / CONFIG_MTD_CMDLINE_PARTS isn't enabled) with 1MB for
u-boot / environment, 4MB for the kernel and the rest for the rootfs, so use
that layout here and adjust the kernel loading to match.

Signed-off-by: Peter Korsgaard 


Applied to u-boot-marvell/master.

Thanks,
Stefan

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

[U-Boot] Possible mistake in the csu_cslx_ind enum (ns_access.h)

[Vincent]

Hi,
I started to port my kernel to the secure world on a LS1021a board, so
I started to read the reference manual on the CSU component. In Table
9.8, we can see that

- Debug EPU is CSL47[24:16]
- DDDI is CSL48[24:16]
- Debug GDI is CSL48[8:0]

but in ns_access.h the order doesn't seem to fit. If I understand correctly:

- CSU_CSLX_EPU and CSU_CSLX_COP_DCSR should be exchanged
- CSU_CSLX_DDI and CSU_CSLX_GDI should be exchanged
- CSU_CSLX_USB3_PHY should be = 116, not 117


I don't have any Errata yet, and I might be wrong, so I'd rather have
a confirmation.

By the way, there are a lot of 'Reserved' entry that have a name (like
CSU_CSLX_GIC for example), am I lacking some information ?

Best regards,
Vincent
___
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

[Valentin Longchamp]

York,

Thanks a lot for your answer and precisions.

On 23/03/16 16:56, york sun wrote:
> 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.

OK, the precision about the 4G address space was the part I was missing. From
then on it's clear that you can expect the reset vector at different addresses
since not all the 32 pins are connected to the NOR chip indeed.

> 
>> - 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.

OK, good to know for our actual mapping (that most likely will be similar).

> 
> 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.
> 

Yup, a lot of similarities here, that helps a lot !

Thanks again for your support

Valentin

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailma

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

[Albert ARIBAUD]

Hello Tom,

On Wed, 23 Mar 2016 17:36:17 -0400, 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

(ok, that explains what you mean by AEABI functions -- those are
actually not functions defined by the AEABI, but functions that the GCC
folks prefixed with __aeabi.)

I do understand that clang does not provide these functions. What I
want to understand is how come code compiled by clang would need them
unless we introduced that dependency ourselves. clang does produce
correct and self-sufficient code when using 64-bit division, right?

> > > > 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
> > t