Re: [U-Boot] [PATCH 2/4] rsa: Verify RSA padding programatically

[Simon Glass]

Hi Andrew,

On 11 November 2016 at 14:22, Andrew Duda  wrote:
> Simon,
>
> So I looked into this more after you asked this, and it looks very
> platform dependent. I tested on two builds: sandbox and a version of
> x86-common. The before/after for sandbox image was
> 5486016-5486800(+784). The before/after for my x86 build was
> 3306100-3305908(-192). So memory saving is anywhere from a few bytes
> to actually more space. But the big motivation is the next two patches
> depend on this change.

OK, well I'm not worried about sandbox, and seeing a saving on a real
x86 board is comforting.

BTW please try not to top-post as it confuses the history.

Regards,
Simon

>
> Thanks,
> Andrew
>
> On Fri, Nov 11, 2016 at 8:17 AM, Simon Glass  wrote:
>> On 8 November 2016 at 11:53, aduda  wrote:
>>> From: Andrew Duda 
>>>
>>> Padding verification was done against static SHA/RSA pair arrays which
>>> take up a lot of static memory, are mostly 0xff, and cannot be reused
>>> for additional SHA/RSA pairings. The padding can be easily computed
>>> according to PKCS#1v2.1 as:
>>>
>>>   EM = 0x00 || 0x01 || PS || 0x00 || T
>>>
>>> where PS is (emLen - tLen - 3) octets of 0xff and T is DER encoding
>>> of the hash.
>>>
>>> Store DER prefix in checksum_algo and create rsa_verify_padding
>>> function to handle verification of a message for any SHA/RSA pairing.
>>>
>>> Signed-off-by: Andrew Duda 
>>> Signed-off-by: aduda 
>>> ---
>>>
>>>  common/image-sig.c|   9 ++--
>>>  include/image.h   |   3 +-
>>>  include/u-boot/rsa-checksum.h |   4 --
>>>  include/u-boot/sha1.h |   3 ++
>>>  include/u-boot/sha256.h   |   3 ++
>>>  lib/rsa/rsa-checksum.c| 121 
>>> --
>>>  lib/rsa/rsa-verify.c  |  38 -
>>>  lib/sha1.c|   5 ++
>>>  lib/sha256.c  |   6 +++
>>>  9 files changed, 61 insertions(+), 131 deletions(-)
>>
>> Reviewed-by: Simon Glass 
>>
>> How much memory does this save?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] rsa: cosmetic: rename pad_len to key_len

[Simon Glass]

On 11 November 2016 at 14:16, Andrew Duda  wrote:
>
> Simon,
>
> padded_len could work. I decided to go with key_len to be more
> RSA-independent since I have been dealing with ECDSA primarily. More
> specifically, ECDSA has no notion of padding or padded_len, but it
> does have a notion of key_len. And in RSA, I believe the padded_len is
> the same as the key_len. So the name key_len name would be applicable
> to both RSA and ECDSA. Granted, only RSA is currently supported in
> u-boot so I wouldn't have much of a problem updating this to
> padded_len.
>
> (sorry for the duplicate Simon)

OK I see.

Reviewed-by: Simon Glass 

>
> Thanks,
> Andrew
>
> On Fri, Nov 11, 2016 at 8:17 AM, Simon Glass  wrote:
> > Hi,
> >
> > On 8 November 2016 at 11:53, aduda  wrote:
> >> From: Andrew Duda 
> >>
> >> checksum_algo's pad_len field isn't actually used to store the length of
> >> the padding but the total length of the RSA key (msg_len + pad_len)
> >
> > Perhaps it should be padded_key_len or padded_len?
> >
> >>
> >> Signed-off-by: Andrew Duda 
> >> Signed-off-by: aduda 
> >> ---
> >>
> >>  include/image.h  | 2 +-
> >>  lib/rsa/rsa-verify.c | 6 +++---
> >>  2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/image.h b/include/image.h
> >> index 2b1296c..bfe10a0 100644
> >> --- a/include/image.h
> >> +++ b/include/image.h
> >> @@ -1070,7 +1070,7 @@ struct image_region {
> >>  struct checksum_algo {
> >> const char *name;
> >> const int checksum_len;
> >> -   const int pad_len;
> >> +   const int key_len;
> >>  #if IMAGE_ENABLE_SIGN
> >> const EVP_MD *(*calculate_sign)(void);
> >>  #endif
> >> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
> >> index 442b769..5418f59 100644
> >> --- a/lib/rsa/rsa-verify.c
> >> +++ b/lib/rsa/rsa-verify.c
> >> @@ -84,7 +84,7 @@ static int rsa_verify_key(struct key_prop *prop, const 
> >> uint8_t *sig,
> >> }
> >>
> >> padding = algo->rsa_padding;
> >> -   pad_len = algo->pad_len - algo->checksum_len;
> >> +   pad_len = algo->key_len - algo->checksum_len;
> >>
> >> /* Check pkcs1.5 padding bytes. */
> >> if (memcmp(buf, padding, pad_len)) {
> >> @@ -160,7 +160,7 @@ int rsa_verify(struct image_sign_info *info,
> >>  {
> >> const void *blob = info->fdt_blob;
> >> /* Reserve memory for maximum checksum-length */
> >> -   uint8_t hash[info->algo->checksum->pad_len];
> >> +   uint8_t hash[info->algo->checksum->key_len];
> >> int ndepth, noffset;
> >> int sig_node, node;
> >> char name[100];
> >> @@ -171,7 +171,7 @@ int rsa_verify(struct image_sign_info *info,
> >>  * rsa-signature-length
> >>  */
> >> if (info->algo->checksum->checksum_len >
> >> -   info->algo->checksum->pad_len) {
> >> +   info->algo->checksum->key_len) {
> >> debug("%s: invlaid checksum-algorithm %s for %s\n",
> >>   __func__, info->algo->checksum->name, 
> >> info->algo->name);
> >> return -EINVAL;
> >> --
> >> 2.10.2
> >>
> >
> > Regards,
> > Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Tom Rini]

On Mon, Nov 14, 2016 at 07:58:03PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Nov 14, 2016 at 10:25:27AM -0500, Tom Rini wrote:
> > On Mon, Nov 14, 2016 at 04:20:49PM +0100, Maxime Ripard wrote:
> > > On Fri, Nov 11, 2016 at 11:20:47AM -0500, Tom Rini wrote:
> > > > On Tue, Nov 08, 2016 at 05:21:14PM +0100, Maxime Ripard wrote:
> > > > 
> > > > > This program generates raw SPL images that can be flashed on the NAND 
> > > > > with
> > > > > the ECC and randomizer properly set up.
> > > > > 
> > > > > Signed-off-by: Maxime Ripard 
> > > > [snip]
> > > > > +++ b/tools/sunxi-spl-image-builder.c
> > > > > @@ -0,0 +1,1113 @@
> > > > > +/*
> > > > > + * Generic binary BCH encoding/decoding library
> > > > 
> > > > OK, but this is also lib/bch.c and re-using lib/ code for tools is a
> > > > normal best practice.  I'd suggest re-factoring this code in sunxi-tools
> > > > sot that it too borrows lib/bch.c from the kernel (and can re-sync
> > > > bugfixes if needed).  Thanks!
> > > 
> > > I finally figured that out.
> > > 
> > > It turns out that the driver was doing a modulo by 0. I guess gcc's
> > > and our libgcc don't have the same behaviour in this case, but in
> > > U-boot's case, the function was simply returning (which is kind of
> > > odd).
> > > 
> > > I'll send a fix for the driver.
> > 
> > So it's something in how lib/bch.c and lib1funcs.S interact?  Please CC
> > me on these when fixing whatever side of this it is in the kernel,
> > thanks!
> 
> Hmm, no, sorry, I meant to reply on the cover letter. The issue isn't
> in lib/bch.c, it was really in our NAND driver. No changes required in
> the kernel, just an extra patch in this serie :)

Ah-ah! OK, thanks for clarifying.

-- 
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 4/7] tools: sunxi: Add spl image builder

[Maxime Ripard]

Hi,

On Mon, Nov 14, 2016 at 10:25:27AM -0500, Tom Rini wrote:
> On Mon, Nov 14, 2016 at 04:20:49PM +0100, Maxime Ripard wrote:
> > On Fri, Nov 11, 2016 at 11:20:47AM -0500, Tom Rini wrote:
> > > On Tue, Nov 08, 2016 at 05:21:14PM +0100, Maxime Ripard wrote:
> > > 
> > > > This program generates raw SPL images that can be flashed on the NAND 
> > > > with
> > > > the ECC and randomizer properly set up.
> > > > 
> > > > Signed-off-by: Maxime Ripard 
> > > [snip]
> > > > +++ b/tools/sunxi-spl-image-builder.c
> > > > @@ -0,0 +1,1113 @@
> > > > +/*
> > > > + * Generic binary BCH encoding/decoding library
> > > 
> > > OK, but this is also lib/bch.c and re-using lib/ code for tools is a
> > > normal best practice.  I'd suggest re-factoring this code in sunxi-tools
> > > sot that it too borrows lib/bch.c from the kernel (and can re-sync
> > > bugfixes if needed).  Thanks!
> > 
> > I finally figured that out.
> > 
> > It turns out that the driver was doing a modulo by 0. I guess gcc's
> > and our libgcc don't have the same behaviour in this case, but in
> > U-boot's case, the function was simply returning (which is kind of
> > odd).
> > 
> > I'll send a fix for the driver.
> 
> So it's something in how lib/bch.c and lib1funcs.S interact?  Please CC
> me on these when fixing whatever side of this it is in the kernel,
> thanks!

Hmm, no, sorry, I meant to reply on the cover letter. The issue isn't
in lib/bch.c, it was really in our NAND driver. No changes required in
the kernel, just an extra patch in this serie :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning

[Siarhei Siamashka]

On Thu,  3 Nov 2016 00:58:12 +
Andre Przywara  wrote:

> Somehow an int returning function without a return statement sneaked
> in. Fix it.
> 
> Signed-off-by: Andre Przywara 
> ---
>  drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
> index 67c7edd..7502314 100644
> --- a/drivers/mtd/spi/sunxi_spi_spl.c
> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
>(1 << AHB_RESET_SPI0_SHIFT));
>  }
>  
> -static int spi0_init(void)
> +static void spi0_init(void)
>  {
>   unsigned int pin_function = SUNXI_GPC_SPI0;
> +
>   if (IS_ENABLED(CONFIG_MACH_SUN50I))
>   pin_function = SUN50I_GPC_SPI0;
>  

Thanks for spotting and fixing this compilation warning.

This was a last minute change. Originally there was also a check for
the pins state and the function returned an error code in the case if
the pins are already configured for NAND. But I removed this code
before sending the patch.

The idea is that probing the SPI flash may be useful in the future even
if booting from some other media. We may store some board-specific
configuration in the on-board SPI flash (for example, the DRAM and
CPU speed grade information). But this functionality definitely belongs
to a separate patch and can be always contributed later. There is also
the SPL size concern and we don't want to unnecessarily increase the
code size.

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

Re: [U-Boot] [PATCH v3 5/5] ARMv8: LS1043A: Enable LS1043A default PSCI support

[york sun]

On 11/06/2016 08:14 PM, macro.wav...@gmail.com wrote:
> From: Hongbo Zhang 
>
> A most basic PSCI implementation with only one psci_version is added for
> LS1043A, this can verify the generic PSCI framework, and more platform 
> specific
> implementation will be added later.
>
> Signed-off-by: Hongbo Zhang 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/Makefile   |  1 +
>  arch/arm/cpu/armv8/fsl-layerscape/ls1043a_psci.S | 20 
>  board/freescale/ls1043ardb/Kconfig   |  9 +
>  configs/ls1043ardb_defconfig |  3 +++
>  4 files changed, 33 insertions(+)
>  create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1043a_psci.S
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
> b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> index 51c1cee..423b4b3 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> @@ -28,6 +28,7 @@ endif
>
>  ifneq ($(CONFIG_LS1043A),)
>  obj-$(CONFIG_SYS_HAS_SERDES) += ls1043a_serdes.o
> +obj-$(CONFIG_ARMV8_PSCI) += ls1043a_psci.o
>  endif
>
>  ifneq ($(CONFIG_ARCH_LS1012A),)
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1043a_psci.S 
> b/arch/arm/cpu/armv8/fsl-layerscape/ls1043a_psci.S
> new file mode 100644
> index 000..86045ac
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1043a_psci.S
> @@ -0,0 +1,20 @@
> +/*
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + * Author: Hongbo Zhang 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + * This file implements LS102X platform PSCI SYSTEM-SUSPEND function
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> + .pushsection ._secure.text, "ax"
> +
> +.globl   psci_version
> +psci_version:
> + ldr w0, =0x0001 /* PSCI v1.0 */
> + ret
> +
> + .popsection
> diff --git a/board/freescale/ls1043ardb/Kconfig 
> b/board/freescale/ls1043ardb/Kconfig
> index 51818ec..0c596f9 100644
> --- a/board/freescale/ls1043ardb/Kconfig
> +++ b/board/freescale/ls1043ardb/Kconfig
> @@ -13,4 +13,13 @@ config SYS_SOC
>  config SYS_CONFIG_NAME
>   default "ls1043ardb"
>
> +config SYS_HAS_ARMV8_SECURE_BASE
> + bool "Enable secure RAM for PSCI image"
> + depends on ARMV8_PSCI
> + default y
> + help
> +   PSCI image can be re-located to secure RAM.
> +   If enabled, please also define the value for ARMV8_SECURE_BASE,
> +   for LS1043ARDB, it is address in OCRAM.
> +
>  endif
> diff --git a/configs/ls1043ardb_defconfig b/configs/ls1043ardb_defconfig
> index 79a4eb2..cb189f3 100644
> --- a/configs/ls1043ardb_defconfig
> +++ b/configs/ls1043ardb_defconfig
> @@ -28,3 +28,6 @@ CONFIG_DM_USB=y
>  CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_STORAGE=y
> +CONFIG_ARMV8_PSCI=y
> +CONFIG_ARMV8_PSCI_CPUS_PER_CLUSTER=4
> +CONFIG_ARMV8_SECURE_BASE=0x1001
>

How do you decide the CONFIG_ARMV8_SECURE_BASE?

Zhiqiang,

Does this patch set interfere with existing PPA support?

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

Re: [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning

[Siarhei Siamashka]

On Mon, 14 Nov 2016 11:56:50 -0500
Tom Rini  wrote:

> On Mon, Nov 14, 2016 at 04:47:26PM +, Andre Przywara wrote:
> > Hi,
> > 
> > On 14/11/16 16:30, Jagan Teki wrote:  
> > > On Thu, Nov 3, 2016 at 6:28 AM, Andre Przywara  
> > > wrote:  
> > >> Somehow an int returning function without a return statement sneaked
> > >> in. Fix it.
> > >>
> > >> Signed-off-by: Andre Przywara 
> > >> ---
> > >>  drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
> > >>  1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c 
> > >> b/drivers/mtd/spi/sunxi_spi_spl.c
> > >> index 67c7edd..7502314 100644
> > >> --- a/drivers/mtd/spi/sunxi_spi_spl.c
> > >> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
> > >> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
> > >>  (1 << AHB_RESET_SPI0_SHIFT));
> > >>  }
> > >>
> > >> -static int spi0_init(void)
> > >> +static void spi0_init(void)
> > >>  {
> > >> unsigned int pin_function = SUNXI_GPC_SPI0;
> > >> +  
> > > 
> > > Space not needed or unrelated, please  remove this.  
> > 
> > This is Linux coding style, which U-Boot adheres to.
> > "WARNING: Missing a blank line after declarations"
> > 
> > I thought I should fix this since this is was in the context of this
> > very simple patch and it improves readability.
> > If this is too much, then please remove the line before committing.  
> 
> Making things checkpatch clean is good, in the future please also
> mention that in commit messages.  Thanks!

How can I get this checkpatch warning?


$ scripts/checkpatch.pl 0001-sunxi-Support-booting-from-SPI-flash.patch 
total: 0 errors, 0 warnings, 0 checks, 361 lines checked

NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX 
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE 
PREFER_ETHER_ADDR_COPY USLEEP_RANGE

0001-sunxi-Support-booting-from-SPI-flash.patch has no obvious style problems 
and is ready for submission.


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

Re: [U-Boot] [PATCH v2 2/3] LS1046AQDS: Add NOR Secure Boot Target

[york sun]

On 10/26/2016 03:47 AM, Sumit Garg wrote:
> Add NOR secure boot target. Also enable sec init.
>
> Signed-off-by: Vinitha Pillai 
> Signed-off-by: Sumit Garg 
> ---
>
> Changes in v2:
> Split patches logically from 2 to 3.
>
>  board/freescale/ls1046aqds/MAINTAINERS   |  4 
>  board/freescale/ls1046aqds/ls1046aqds.c  | 18 ++
>  configs/ls1046aqds_SECURE_BOOT_defconfig | 29 +
>  3 files changed, 51 insertions(+)
>  create mode 100644 configs/ls1046aqds_SECURE_BOOT_defconfig
>
> diff --git a/board/freescale/ls1046aqds/MAINTAINERS 
> b/board/freescale/ls1046aqds/MAINTAINERS
> index b4549ae..6737d55 100644
> --- a/board/freescale/ls1046aqds/MAINTAINERS
> +++ b/board/freescale/ls1046aqds/MAINTAINERS
> @@ -8,3 +8,7 @@ F:configs/ls1046aqds_nand_defconfig
>  F:   configs/ls1046aqds_sdcard_ifc_defconfig
>  F:   configs/ls1046aqds_sdcard_qspi_defconfig
>  F:   configs/ls1046aqds_qspi_defconfig
> +
> +M:   Sumit Garg 
> +S:   Maintained
> +F:   configs/ls1046aqds_SECURE_BOOT_defconfig
> diff --git a/board/freescale/ls1046aqds/ls1046aqds.c 
> b/board/freescale/ls1046aqds/ls1046aqds.c
> index 8c18538..a418590 100644
> --- a/board/freescale/ls1046aqds/ls1046aqds.c
> +++ b/board/freescale/ls1046aqds/ls1046aqds.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "../common/vid.h"
> @@ -242,6 +243,23 @@ int board_init(void)
>   if (adjust_vdd(0))
>   printf("Warning: Adjusting core voltage failed.\n");
>
> +#ifdef CONFIG_SECURE_BOOT
> + /* In case of Secure Boot, the IBR configures the SMMU
> +  * to allow only Secure transactions.
> +  * SMMU must be reset in bypass mode.
> +  * Set the ClientPD bit and Clear the USFCFG Bit
> +  */

Multiple-line comment in wrong format. You just fixed some in your first 
patch.

York

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

Re: [U-Boot] [PATCH] armv8/ls1043a: Add the OCRAM initialization

[york sun]

On 11/07/2016 10:36 AM, york@nxp.com wrote:
> On 10/27/2016 02:47 AM, Calvin Johnson wrote:
>> Hi York,
>>
>>> -Original Message-
>>> From: york sun
>>> Sent: Wednesday, October 26, 2016 10:09 PM
>>> To: Calvin Johnson ; Prabhakar Kushwaha
>>> ; Pratiyush
>>> Srivastava ; u-boot@lists.denx.de;
>>> Mingkai Hu 
>>> Cc: Hou Zhiqiang 
>>> Subject: Re: [PATCH] armv8/ls1043a: Add the OCRAM initialization
>>>
>>> On 10/24/2016 09:30 PM, Calvin Johnson wrote:
>>>
>>> I wonder why we don't see ECC errors before this patch. We have
>>> LS1043A boots on NAND, SD.
>>>
>>
>> OCRAM has a requirement of initializing before first time "read".
>> If user reads OCRAM before **initializing**; ECC error will come.
>> (u-boot is not handling this error for now).
>>
>> I can only guess the reason of not seeing this error as OCRAM
>> never read before any write.
>> Even in case of Stack, data is first written and then read.
>>
>
> Is there a case you want to read from OCRAM before writing anything
> to it? Why don't we need to do so for SPL or
>>> LSCH3?

 This issue will be seen ONLY in secure boot. It was reproduced on
 LS1043A also.

>>>
>>> How about LSCH3? We have LS2080A secure boot.
>>
>> I don't know about LS2080A. Prabhakar or Ruchika(copied) may be able
>> to comment on this.
>>
>
> Please follow up on this thread. We need to understand when and where
> OCRAM needs to be cleared.
>

Can Prabhakar or Ruchika verify this OCRAM init on LSCH3? If it is 
required and effective, we can take this patch.

York

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

Re: [U-Boot] [ANN] U-Boot v2016.11 is released

[Jagan Teki]

On Mon, Nov 14, 2016 at 10:16 PM, Tom Rini  wrote:
> Hey all,
>
> I've released v2016.11 and it's now live on git and FTP and ACD (along
> with PGP sig file).
>
> In many ways it feels good to say that the highlights of the last
> release once again apply.  We've had more DM conversion work, Kconfig
> conversion work and arch / SoC / platform updates.  We've also had some
> important filesystem fixes come in and equally as important, test cases
> added.  We also now support the new and default enabled ext4 64bit flag
> (thanks again Stefan!).
>
> And what I want to highlight here is going forward both relative ease
> of, and expectations on testing.  Last time I talked about test.py and
> how I'm using it more myself now.  This time, I want to talk about
> travis-ci support.  If you use github you can get a more-or-less world
> build and test.py for all of the QEMU targets we support today done in
> about 2 and a half hours, wall clock.  I don't expect people to do this
> for iterative development or "trivial" changes, but if you have a series
> that touches a lot of areas I think it's reasonable to expect that
> you'll test things out this way.  And I'll say now it's not 100%.  About
> once every 10 builds I'll have to go and re-start a sub-job because it
> will fail to fetch one of the PPAs we use for no apparent reason.  But
> to be clear, it's a few minutes worth of setup and then you push a
> change and you get build coverage and test coverage.  This is really
> awesome and I wish I had been paying more attention to this sooner.
>
> As always, I know I'm missing pointing out a few things that I should
> point out and would encourage folks to chime in if there's anything they
> would like to highlight.
>
> Thanks again everyone!

Unfortunately "Amarula Solutions" is not listed in Employers list [1]
for this I sent a domain-map mail to Wolfgang Denk during MW, any edit
for this?

[1] http://www.denx.de/wiki/U-Boot/UbootStat_2016_11

-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v8 0/3] armv8: Support loading 32-bit OS in AArch32 execution state

[Alison Wang]

> On 10 November 2016 at 02:49, Alison Wang  wrote:
> > This series is to support loading a 32-bit OS, the execution state
> will change from AArch64 to AArch32 when jumping to kernel. The
> architecture information will be got through checking FIT image, then
> U-Boot will load 32-bit OS or 64-bit OS automatically.
> >
> > Spin-table method is used for secondary cores to load 32-bit OS.
> > The architecture information will be got through checking FIT image
> and saved in the os_arch element of spin-table, then the secondary
> cores will check os_arch and jump to 32-bit OS or 64-bit OS
> automatically.
> >
> > PSCI method can also be used for secondary cores to load 32-bit OS.
> > As PSCI and secure monitor firmware framework are enabled, loading
> 32-bit OS is supported in such case. The default target exception level
> returned to U-Boot is EL2, so the corresponding work to switch to
> AArch32 EL2 and jump to 32-bit OS are done in U-Boot and secure
> firmware together.
> >
> > ---
> > Changes in v8:
> > - Fix the issue when U-Boot is running in EL2 or EL1.
> 
> Thanks for sticking with this.  Great news: it works for my setup.
> 
> I tested booting an arm64 kernel on FVP Foundation and AEMv8 modes and
> on Juno R0, R1 and R2.  I also tested and Versatile Express TC2 can
> still load it's Aarch32 kernel.
> 
> I didn't test running an Aarch32 kernel or any of the new functionality
> on my ARMv8 platforms.
> 
> But I checked and the patches are bisect-able on my ARMv8 platforms.
> 
> Tested-by: Ryan Harkin 
> 
[Alison Wang] Thanks for your verification.


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

Re: [U-Boot] [PATCH] armv8: QSPI: Add AHB bus 16MB+ size support

[york sun]

On 11/07/2016 10:03 PM, Yao Yuan wrote:
> On 11/08/2016 02:27 AM, York Sun wrote:
>> On 10/25/2016 07:10 PM, Yuan Yao wrote:
>>> From: Yuan Yao 
>>>
>>> The default configuration for QSPI AHB bus can't support 16MB+.
>>> But some flash on NXP layerscape board are more than 16MB.
>>
>> So what do you do?
>>
>> Is this an erratum workaround? If yes, please refer the erratum number.
>
> Hi York,
>
> I think It's not an erratum maybe it's better to call it new feature.
>
> As a default configuration for QSPI AHB, the address size is 3-bytes.
> It has a good compatibility for QSPI boot for different SPI-NOR flash.
>
> But if the address size is only 3-bytes, the QSPI can't access to the data 
> that more than 16M+.
>
> So we can update the default configuration for QSPI AHB in uboot to use 
> 4-bytes address.
> So that QSPI can access to 16M+ size by AHB bus.

Let me try to understand this. With your change, 4-byte addressing is 
supported. Do all flash chips support 4-byte addressing?


>
> Thanks.
>>
>>>
>>> Signed-off-by: Yuan Yao 
>>> ---
>>>  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 37
>> ++
>>>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
>>> .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
>>>  include/configs/ls1012a_common.h   |  1 +
>>>  include/configs/ls1046ardb.h   |  1 +
>>>  5 files changed, 41 insertions(+)
>>>
>>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
>>> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
>>> index d68eeba..18d753e 100644
>>> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
>>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
>>> @@ -370,6 +370,40 @@ void fsl_lsch2_early_init_f(void)  }  #endif
>>>
>>> +#ifdef CONFIG_QSPI_AHB_INIT
>>> +/* Enable 4bytes address support and fast read */ int
>>> +qspi_ahb_init(void) {
>>> +   u32 *qspi_lut, lut_key, *qspi_key;
>>> +
>>> +   qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
>>> +   qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
>>> +
>>> +   lut_key = in_be32(qspi_key);
>>> +
>>> +   if (lut_key == 0x5af05af0) {
>>> +   /* That means the register is BE */
>>> +   out_be32(qspi_key, 0x5af05af0);
>>> +   out_be32(qspi_key + 1, 0x0002);
>>> +   out_be32(qspi_lut, 0x0820040c);
>>> +   out_be32(qspi_lut + 1, 0x1c080c08);
>>> +   out_be32(qspi_lut + 2, 0x2400);
>>> +   out_be32(qspi_key, 0x5af05af0);
>>> +   out_be32(qspi_key + 1, 0x0001);
>>> +   } else {
>>> +   /* That means the register is LE */
>>> +   out_le32(qspi_key, 0x5af05af0);
>>> +   out_le32(qspi_key + 1, 0x0002);
>>> +   out_le32(qspi_lut, 0x0820040c);
>>> +   out_le32(qspi_lut + 1, 0x1c080c08);
>>> +   out_le32(qspi_lut + 2, 0x2400);
>>> +   out_le32(qspi_key, 0x5af05af0);
>>> +   out_le32(qspi_key + 1, 0x0001);
>>> +   }
>>
>> What do these sequences do?
>
> It used to set the AHB bus to use 4-bytes command and the corresponding 
> sequence.
> So that QSPI can access to 16M+ size by AHB bus.
>
>>
>> Put a blank line before return.

You need a blank line here.

>>
>>> +   return 0;
>>> +}
>>> +#endif
>>> +
>>>  #ifdef CONFIG_BOARD_LATE_INIT
>>>  int board_late_init(void)
>>>  {
>>> @@ -379,6 +413,9 @@ int board_late_init(void)  #ifdef
>>> CONFIG_CHAIN_OF_TRUST
>>> fsl_setenv_chain_of_trust();
>>>  #endif
>>> +#ifdef CONFIG_QSPI_AHB_INIT
>>> +   qspi_ahb_init();
>>> +#endif
>>>
>>> return 0;
>>>  }
>>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>>> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>>> index d88543d..a28b1fd 100644
>>> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
>>> @@ -18,6 +18,7 @@
>>>  #define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR +
>> 0x0018)
>>>  #define CONFIG_SYS_GIC400_ADDR (CONFIG_SYS_IMMR +
>> 0x0040)
>>>  #define CONFIG_SYS_IFC_ADDR(CONFIG_SYS_IMMR +
>> 0x0053)
>>> +#define CONFIG_SYS_QSPI_ADDR   (CONFIG_SYS_IMMR +
>> 0x0055)
>>>  #define CONFIG_SYS_FSL_ESDHC_ADDR  (CONFIG_SYS_IMMR +
>> 0x0056)
>>>  #define CONFIG_SYS_FSL_CSU_ADDR
>>  (CONFIG_SYS_IMMR + 0x0051)
>>>  #define CONFIG_SYS_FSL_GUTS_ADDR   (CONFIG_SYS_IMMR +
>> 0x00ee)
>>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>>> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>>> index 7acba27..8aefc76 100644
>>> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>>> @@ -19,6 +19,7 @@
>>>  #define CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR   (CONFIG_SYS_IMMR +
>> 0x0030)
>>>  #define CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR   (CONFIG_SYS_IMMR +
>> 0x0031)
>>>  #define 

[U-Boot] FDT retrived varaibles appear to have different properties fom other u-boot variables - and are corrupted on get, set, get correction

[dh]

 Duncan Hare

714 931 7952

 
- Forwarded Message -
 From: "d...@synoia.com" 
 To: "u-boot@lists.denx.de"  
Cc: Cédric Schieli 
 Sent: Sunday, November 13, 2016 4:08 PM
 Subject: FDT retrived varaibles appear to have different properties fom other 
u-boot variables - and are corrupted on get, set, get sequence
   
Cédric
I move the fdt to 0x100
fdt move ${fdt_addr}  100
fdt addr 100

then
fdt get value bootargs /chosen bootargs
printenv bootargs 
bootargs=8250.nr_uarts=1 dma.dmachans=all the boot args... (note 
the space after "uarts=1)

 setenv abc $bootargs fails...as does printenv $bootargs

They I tried

fdt set bootargs /chosen bootargsfdt get value bootargs /chosen 
bootargsbootargs=8250.nr_uarts=1
The bootargs parameter list is truncated after the first blank.

Something is not right in the world of fdt code.
 Duncan Hare

714 931 7952

  From: Cédric Schieli 
 To: d...@synoia.com 
 Sent: Sunday, November 13, 2016 2:21 AM
 Subject: Re: Fw: [U-Boot] Fw: FDT pointer value, passed by the PI firmware, is 
not set in u-boot
  
Hello Duncan,

2016-11-13 3:04 GMT+01:00 :

> If appending to "/chosen bootargs" (making it longer), does the fdt command
> automatically relocate the fdt, or does the u-boot script have to do that
> itself?
>
> The fdt doc at http://www.denx.de/wiki/view/ DULG/UBootCmdFDT
> Is quite unclear on how the fdt size is managed, especially when the fdt is
> located close to the end of memory.

I'm not an expert here, but looking at cmd/fdt.c I didn't find any kind of 
relocation code. So I guess the safe bet is to move the blob before making any 
(growing) change to the tree:

# load the blob from the firmware provided address (at the end of memory)
fdt addr ${fdt_addr}

# move the blob to the (previously) default location (0x100)
fdt move ${fdt_addr_r}

# make needed changes
setenv bootargs "..."

# boot from the new location
bootz ${kernel_addr_r} - ${fdt_addr_r}


Another solution is to force the firmware to load the blob at a fixed location 
(as before) by updating config.txt:
device_tree_address=0x100

Regards,
Cédric


   

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

Re: [U-Boot] [v2, 2/5] mmc: send STOP command when the READ/WRITE commands fail

[york sun]

On 09/23/2016 12:38 AM, Y.B. Lu wrote:
>> ditto.
>
> [Lu Yangbo-B47093] Ok, I will check the return. Thanks :)
>>

Yangbo,

Do you have an update?

York

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

Re: [U-Boot] [PATCH 1/6][v3] armv8: lsch3: Add generic get_svr() in assembly

[york sun]

On 11/03/2016 04:12 AM, Priyanka Jain wrote:
> Signed-off-by: Priyanka Jain 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|7 ---
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |9 +
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |6 +++---
>  3 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index b7a2e0c..2863e18 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -305,13 +305,6 @@ u32 fsl_qoriq_core_to_type(unsigned int core)
>   return -1;  /* cannot identify the cluster */
>  }
>
> -uint get_svr(void)
> -{
> - struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
> -
> - return gur_in32(>svr);
> -}
> -
>  #ifdef CONFIG_DISPLAY_CPUINFO
>  int print_cpuinfo(void)
>  {
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
> b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> index 5d0b7a4..ee20c27 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> @@ -13,6 +13,9 @@
>  #ifdef CONFIG_MP
>  #include 
>  #endif
> +#ifdef CONFIG_FSL_LSCH3
> +#include 
> +#endif
>
>  ENTRY(lowlevel_init)
>   mov x29, lr /* Save LR */
> @@ -199,6 +202,12 @@ ENTRY(lowlevel_init)
>  ENDPROC(lowlevel_init)
>
>  #ifdef CONFIG_FSL_LSCH3
> + .globl get_svr
> +get_svr:
> + ldr x1, =FSL_LSCH3_SVR
> + ldr w0, [x1]
> + ret
> +

This has an issue with non_lsch3 SoCs. You will see compiling error on 
them, for example ls1012afrdm_qspi.

York

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

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Tom Rini]

On Mon, Nov 14, 2016 at 03:21:41PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 14-11-16 15:12, Maxime Ripard wrote:
> >On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:
> >>> #ifdef CONFIG_SPL_SPI_SUNXI
> >>>@@ -143,7 +157,14 @@
> >>> #define CONFIG_GENERIC_MMC
> >>> #define CONFIG_MMC_SUNXI
> >>> #define CONFIG_MMC_SUNXI_SLOT 0
> >>>-#define CONFIG_ENV_IS_IN_MMC
> >>>+#endif
> >>>+
> >>>+#if defined(CONFIG_ENV_IS_IN_NAND)
> >>>+#define CONFIG_ENV_OFFSET 0xc0
> >>>+#define CONFIG_ENV_SIZE   0x40
> >>>+#elif defined(CONFIG_ENV_IS_IN_MMC)
> >>>+#define CONFIG_ENV_OFFSET (544 << 10) /* (8 + 24 + 512) 
> >>>KiB */
> >>>+#define CONFIG_ENV_SIZE   (128 << 10) /* 128 KiB 
> >>>*/
> >>> #define CONFIG_SYS_MMC_ENV_DEV0   /* first detected MMC 
> >>> controller */
> >>> #endif
> >
> >Oh, and this part is broken. It relies on the fact that all board
> >define ENV_IS_IN_MMC (which they should), while obviously they
> >don't. I'm not exactly sure about what the proper fix would be.
> 
> Yes, this has been a known problem for a while, but never
> became an issue due to lack of NAND support.
> 
> My preferred way for dealing with this be would for the
> environment code in u-boot allowing to build in multiple
> back-ends and use spl_boot_device() which then would need
> to loose its spl prefix. For the CHIP devices I'm sure
> you can come up with a simpler fix since those don't
> have an sdcard-slot. But for other boards this will be
> necessary as we really don't want to have separate
> nand and mmc u-boot.bin files.
> 
> Anyways this is something for whomever will take over
> as sunxi custodian from me. Maybe someone from free-electrons
> can co-maintain with Jagan ?

I would really like to see the co-maintainer model continue here, if
possible, yes.  Thanks!

-- 
Tom


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

Re: [U-Boot] Stepping down as sunxi u-boot custodian (for real this time)

[Yann E. MORIN]

Hans, Ian, All,

On 2016-11-14 12:53 +0100, Hans de Goede spake thusly:
> A while back I wrote:
> 
> "Between my $dayjob, linux-sunxi, other foss projects and last but
> not least spending time with my wife and children I'm way too
> busy lately.
> 
> So I've decided to seriously scale back my involvement in
> linux-sunxi, as such I'm going to step down as u-boot sunxi
> custodian."

So long, and thanks for all the fish! :-)

> So after this mail I'm going to send a mail updating
> the MAINTAINERS status of sunxi to orphan and I will also
> unsubscribe myself from the u-boot list to protect myself
> against getting dragged in again.

Don't forget to update (or get updated) the list of custodians on the
website (which is where I found the info):
http://www.denx.de/wiki/U-Boot/Custodians

Regards,
Yann E. MORIN.

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN |  ___   |
| +33 223 225 172 `.---:  X  AGAINST  |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|   v   conspiracy.  |
'--^---^--^'
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning

[Tom Rini]

On Mon, Nov 14, 2016 at 04:47:26PM +, Andre Przywara wrote:
> Hi,
> 
> On 14/11/16 16:30, Jagan Teki wrote:
> > On Thu, Nov 3, 2016 at 6:28 AM, Andre Przywara  
> > wrote:
> >> Somehow an int returning function without a return statement sneaked
> >> in. Fix it.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c 
> >> b/drivers/mtd/spi/sunxi_spi_spl.c
> >> index 67c7edd..7502314 100644
> >> --- a/drivers/mtd/spi/sunxi_spi_spl.c
> >> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
> >> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
> >>  (1 << AHB_RESET_SPI0_SHIFT));
> >>  }
> >>
> >> -static int spi0_init(void)
> >> +static void spi0_init(void)
> >>  {
> >> unsigned int pin_function = SUNXI_GPC_SPI0;
> >> +
> > 
> > Space not needed or unrelated, please  remove this.
> 
> This is Linux coding style, which U-Boot adheres to.
> "WARNING: Missing a blank line after declarations"
> 
> I thought I should fix this since this is was in the context of this
> very simple patch and it improves readability.
> If this is too much, then please remove the line before committing.

Making things checkpatch clean is good, in the future please also
mention that in commit messages.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning

[Andre Przywara]

Hi,

On 14/11/16 16:30, Jagan Teki wrote:
> On Thu, Nov 3, 2016 at 6:28 AM, Andre Przywara  wrote:
>> Somehow an int returning function without a return statement sneaked
>> in. Fix it.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c 
>> b/drivers/mtd/spi/sunxi_spi_spl.c
>> index 67c7edd..7502314 100644
>> --- a/drivers/mtd/spi/sunxi_spi_spl.c
>> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
>> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
>>  (1 << AHB_RESET_SPI0_SHIFT));
>>  }
>>
>> -static int spi0_init(void)
>> +static void spi0_init(void)
>>  {
>> unsigned int pin_function = SUNXI_GPC_SPI0;
>> +
> 
> Space not needed or unrelated, please  remove this.

This is Linux coding style, which U-Boot adheres to.
"WARNING: Missing a blank line after declarations"

I thought I should fix this since this is was in the context of this
very simple patch and it improves readability.
If this is too much, then please remove the line before committing.

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

[U-Boot] [ANN] U-Boot v2016.11 is released

[Tom Rini]

Hey all,

I've released v2016.11 and it's now live on git and FTP and ACD (along
with PGP sig file).

In many ways it feels good to say that the highlights of the last
release once again apply.  We've had more DM conversion work, Kconfig
conversion work and arch / SoC / platform updates.  We've also had some
important filesystem fixes come in and equally as important, test cases
added.  We also now support the new and default enabled ext4 64bit flag
(thanks again Stefan!).

And what I want to highlight here is going forward both relative ease
of, and expectations on testing.  Last time I talked about test.py and
how I'm using it more myself now.  This time, I want to talk about
travis-ci support.  If you use github you can get a more-or-less world
build and test.py for all of the QEMU targets we support today done in
about 2 and a half hours, wall clock.  I don't expect people to do this
for iterative development or "trivial" changes, but if you have a series
that touches a lot of areas I think it's reasonable to expect that
you'll test things out this way.  And I'll say now it's not 100%.  About
once every 10 builds I'll have to go and re-start a sub-job because it
will fail to fetch one of the PPAs we use for no apparent reason.  But
to be clear, it's a few minutes worth of setup and then you push a
change and you get build coverage and test coverage.  This is really
awesome and I wish I had been paying more attention to this sooner.

As always, I know I'm missing pointing out a few things that I should
point out and would encourage folks to chime in if there's anything they
would like to highlight.

Thanks again everyone!

-- 
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] drivers: SPI: sunxi SPL: fix warning

[Jagan Teki]

On Thu, Nov 3, 2016 at 6:28 AM, Andre Przywara  wrote:
> Somehow an int returning function without a return statement sneaked
> in. Fix it.
>
> Signed-off-by: Andre Przywara 
> ---
>  drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
> index 67c7edd..7502314 100644
> --- a/drivers/mtd/spi/sunxi_spi_spl.c
> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
>  (1 << AHB_RESET_SPI0_SHIFT));
>  }
>
> -static int spi0_init(void)
> +static void spi0_init(void)
>  {
> unsigned int pin_function = SUNXI_GPC_SPI0;
> +

Space not needed or unrelated, please  remove this.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAINTAINERS: mark sunxi status as Orphan

[Tom Rini]

On Mon, Nov 14, 2016 at 12:53:25PM +0100, Hans de Goede wrote:

> Ian has not had any time for sunxi for some time now and I'm
> in the same situation now, so I'm stepping down as sunxi
> custodian and marking the sunxi support as Orphan.
> 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Ian Campbell 
> Signed-off-by: Hans de Goede 
> Acked-by: Ian Campbell 

Sadly, applied to u-boot/master.  Once again, thanks for all the time
you've spent!

-- 
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] dfu: dfu_sf: Fix read offset

[Lukasz Majewski]

Hi Phil,

> The offset was applied to write, but not read, now its applied to
> both.
> 
> Signed-off-by: Phil Edworthy 
> ---
>  drivers/dfu/dfu_sf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
> index 9702eee..b6d5fe2 100644
> --- a/drivers/dfu/dfu_sf.c
> +++ b/drivers/dfu/dfu_sf.c
> @@ -20,7 +20,8 @@ static long dfu_get_medium_size_sf(struct
> dfu_entity *dfu) static int dfu_read_medium_sf(struct dfu_entity
> *dfu, u64 offset, void *buf, long *len)
>  {
> - return spi_flash_read(dfu->data.sf.dev, offset, *len, buf);
> + return spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start +
> offset,
> + *len, buf);
>  }
>  
>  static u64 find_sector(struct dfu_entity *dfu, u64 start, u64 offset)

Acked-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R 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 4/7] tools: sunxi: Add spl image builder

[Tom Rini]

On Mon, Nov 14, 2016 at 04:20:49PM +0100, Maxime Ripard wrote:
> On Fri, Nov 11, 2016 at 11:20:47AM -0500, Tom Rini wrote:
> > On Tue, Nov 08, 2016 at 05:21:14PM +0100, Maxime Ripard wrote:
> > 
> > > This program generates raw SPL images that can be flashed on the NAND with
> > > the ECC and randomizer properly set up.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > [snip]
> > > +++ b/tools/sunxi-spl-image-builder.c
> > > @@ -0,0 +1,1113 @@
> > > +/*
> > > + * Generic binary BCH encoding/decoding library
> > 
> > OK, but this is also lib/bch.c and re-using lib/ code for tools is a
> > normal best practice.  I'd suggest re-factoring this code in sunxi-tools
> > sot that it too borrows lib/bch.c from the kernel (and can re-sync
> > bugfixes if needed).  Thanks!
> 
> I finally figured that out.
> 
> It turns out that the driver was doing a modulo by 0. I guess gcc's
> and our libgcc don't have the same behaviour in this case, but in
> U-boot's case, the function was simply returning (which is kind of
> odd).
> 
> I'll send a fix for the driver.

So it's something in how lib/bch.c and lib1funcs.S interact?  Please CC
me on these when fixing whatever side of this it is in the kernel,
thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] dfu: dfu_sf: Fix read offset

[Fabio Estevam]

On Mon, Nov 14, 2016 at 1:19 PM, Phil Edworthy
 wrote:
> The offset was applied to write, but not read, now its applied to
> both.
>
> Signed-off-by: Phil Edworthy 

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

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Maxime Ripard]

On Fri, Nov 11, 2016 at 11:20:47AM -0500, Tom Rini wrote:
> On Tue, Nov 08, 2016 at 05:21:14PM +0100, Maxime Ripard wrote:
> 
> > This program generates raw SPL images that can be flashed on the NAND with
> > the ECC and randomizer properly set up.
> > 
> > Signed-off-by: Maxime Ripard 
> [snip]
> > +++ b/tools/sunxi-spl-image-builder.c
> > @@ -0,0 +1,1113 @@
> > +/*
> > + * Generic binary BCH encoding/decoding library
> 
> OK, but this is also lib/bch.c and re-using lib/ code for tools is a
> normal best practice.  I'd suggest re-factoring this code in sunxi-tools
> sot that it too borrows lib/bch.c from the kernel (and can re-sync
> bugfixes if needed).  Thanks!

I finally figured that out.

It turns out that the driver was doing a modulo by 0. I guess gcc's
and our libgcc don't have the same behaviour in this case, but in
U-boot's case, the function was simply returning (which is kind of
odd).

I'll send a fix for the driver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[U-Boot] [PATCH] dfu: dfu_sf: Fix read offset

[Phil Edworthy]

The offset was applied to write, but not read, now its applied to
both.

Signed-off-by: Phil Edworthy 
---
 drivers/dfu/dfu_sf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
index 9702eee..b6d5fe2 100644
--- a/drivers/dfu/dfu_sf.c
+++ b/drivers/dfu/dfu_sf.c
@@ -20,7 +20,8 @@ static long dfu_get_medium_size_sf(struct dfu_entity *dfu)
 static int dfu_read_medium_sf(struct dfu_entity *dfu, u64 offset, void *buf,
long *len)
 {
-   return spi_flash_read(dfu->data.sf.dev, offset, *len, buf);
+   return spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start + offset,
+   *len, buf);
 }
 
 static u64 find_sector(struct dfu_entity *dfu, u64 start, u64 offset)
-- 
2.7.4

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

Re: [U-Boot] [PATCH RESEND 6/9] eeprom: Add DS2431 support

[Tom Rini]

On Mon, Nov 14, 2016 at 02:42:59PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Nov 11, 2016 at 11:16:39AM -0800, Moritz Fischer wrote:
> > > +U_BOOT_DRIVER(ds2431) = {
> > > +   .name   = "ds2431",
> > > +   .id = UCLASS_EEPROM,
> > > +   .ops= _ops,
> > 
> > Do you want to add a .flags = DM_UC_FLAG_SEQ_ALIAS here?
> 
> I don't know. I was kind of wondering why U-Boot relies on aliases so
> much, especially when the Linux DT maintainers are saying that aliases
> should be avoided entirely, and we'll won't be able to upstream those
> changes.

Bah.  Do you have a pointer to some discussion about this handy?
Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] socfpga: add support for Terasic DE1-SoC board

[Marek Vasut]

On 11/14/2016 04:07 PM, Anatolij Gustschin wrote:
> Add CycloneV based Terasic DE1-SoC board. The board boots
> from SD/MMC. Ethernet and USB host is supported.
> 
> Signed-off-by: Anatolij Gustschin 
> Cc: Marek Vasut 
> ---
> 

Applied, thanks.

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

[U-Boot] [PATCH v2] socfpga: add support for Terasic DE1-SoC board

[Anatolij Gustschin]

Add CycloneV based Terasic DE1-SoC board. The board boots
from SD/MMC. Ethernet and USB host is supported.

Signed-off-by: Anatolij Gustschin 
Cc: Marek Vasut 
---

v2:
 - drop custom raw partition configuration, use default instead

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/socfpga_cyclone5_de1_soc.dts |  66 +++
 arch/arm/mach-socfpga/Kconfig |   7 +
 board/terasic/de1-soc/MAINTAINERS |   5 +
 board/terasic/de1-soc/Makefile|   9 +
 board/terasic/de1-soc/qts/iocsr_config.h  | 660 ++
 board/terasic/de1-soc/qts/pinmux_config.h | 219 ++
 board/terasic/de1-soc/qts/pll_config.h|  91 
 board/terasic/de1-soc/qts/sdram_config.h  | 344 
 board/terasic/de1-soc/socfpga.c   |  19 +
 configs/socfpga_de1_soc_defconfig |  50 +++
 include/configs/socfpga_de1_soc.h |  57 +++
 12 files changed, 1528 insertions(+)
 create mode 100644 arch/arm/dts/socfpga_cyclone5_de1_soc.dts
 create mode 100644 board/terasic/de1-soc/MAINTAINERS
 create mode 100644 board/terasic/de1-soc/Makefile
 create mode 100644 board/terasic/de1-soc/qts/iocsr_config.h
 create mode 100644 board/terasic/de1-soc/qts/pinmux_config.h
 create mode 100644 board/terasic/de1-soc/qts/pll_config.h
 create mode 100644 board/terasic/de1-soc/qts/sdram_config.h
 create mode 100644 board/terasic/de1-soc/socfpga.c
 create mode 100644 configs/socfpga_de1_soc_defconfig
 create mode 100644 include/configs/socfpga_de1_soc.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 836a8c4..36bda16 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -128,6 +128,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=   
\
socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_de0_nano_soc.dtb   \
+   socfpga_cyclone5_de1_soc.dtb\
socfpga_cyclone5_sockit.dtb \
socfpga_cyclone5_socrates.dtb   \
socfpga_cyclone5_sr1500.dtb \
diff --git a/arch/arm/dts/socfpga_cyclone5_de1_soc.dts 
b/arch/arm/dts/socfpga_cyclone5_de1_soc.dts
new file mode 100644
index 000..a583990
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_de1_soc.dts
@@ -0,0 +1,66 @@
+/*
+ * Copyright Altera Corporation (C) 2015
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "Terasic DE1-SoC";
+   compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   aliases {
+   ethernet0 = 
+   udc0 = 
+   };
+
+   memory {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x4000>; /* 1GB */
+   };
+
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+
+   rxd0-skew-ps = <420>;
+   rxd1-skew-ps = <420>;
+   rxd2-skew-ps = <420>;
+   rxd3-skew-ps = <420>;
+   txen-skew-ps = <0>;
+   txc-skew-ps = <1860>;
+   rxdv-skew-ps = <420>;
+   rxc-skew-ps = <1680>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index d91b8bb..6991af8 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -74,6 +74,10 @@ config TARGET_SOCFPGA_TERASIC_DE0_NANO
bool "Terasic DE0-Nano-Atlas (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
 
+config TARGET_SOCFPGA_TERASIC_DE1_SOC
+   bool "Terasic DE1-SoC (Cyclone V)"
+   select TARGET_SOCFPGA_CYCLONE5
+
 config TARGET_SOCFPGA_TERASIC_SOCKIT
bool "Terasic SoCkit (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
@@ -84,6 +88,7 @@ config SYS_BOARD
default "arria5-socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
default "cyclone5-socdk" if TARGET_SOCFPGA_CYCLONE5_SOCDK
default "de0-nano-soc" if TARGET_SOCFPGA_TERASIC_DE0_NANO
+   default "de1-soc" if TARGET_SOCFPGA_TERASIC_DE1_SOC
default "is1" if TARGET_SOCFPGA_IS1
default "mcvevk" if TARGET_SOCFPGA_DENX_MCVEVK
default "sockit" if TARGET_SOCFPGA_TERASIC_SOCKIT
@@ -98,6 +103,7 @@ config SYS_VENDOR
default "ebv" if TARGET_SOCFPGA_EBV_SOCRATES
default "samtec" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
default "terasic" if TARGET_SOCFPGA_TERASIC_DE0_NANO
+   default "terasic" if TARGET_SOCFPGA_TERASIC_DE1_SOC
default "terasic" if TARGET_SOCFPGA_TERASIC_SOCKIT
 
 config SYS_SOC
@@ -107,6 +113,7 @@ config SYS_CONFIG_NAME
default "socfpga_arria5_socdk" if 

Re: [U-Boot] [PATCH] socfpga: add support for Terasic DE1-SoC board

[Marek Vasut]

On 11/14/2016 03:17 PM, Anatolij Gustschin wrote:
> Hi,
> 
> On Mon, 14 Nov 2016 15:07:31 +0100
> Marek Vasut ma...@denx.de wrote:
> ...
>>> +#undef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
>>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 2  
>>
>> Why is this needed ? Just start U-Boot from partition 1 as all the other
>> SoCFPGAs do , esp. since this is a devkit, please keep it consistent.
> 
> It is not really needed. I used the original Terasic SD-Card,
> its raw partition is 2. OK, will remove it.

Thanks!

>> Looks great otherwise :)
> 
> Thanks for review!

I'll pick V2 for the next release then. Thanks!

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

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Hans de Goede]

Hi,

On 14-11-16 15:12, Maxime Ripard wrote:

On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:

 #ifdef CONFIG_SPL_SPI_SUNXI
@@ -143,7 +157,14 @@
 #define CONFIG_GENERIC_MMC
 #define CONFIG_MMC_SUNXI
 #define CONFIG_MMC_SUNXI_SLOT  0
-#define CONFIG_ENV_IS_IN_MMC
+#endif
+
+#if defined(CONFIG_ENV_IS_IN_NAND)
+#define CONFIG_ENV_OFFSET  0xc0
+#define CONFIG_ENV_SIZE0x40
+#elif defined(CONFIG_ENV_IS_IN_MMC)
+#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) 
KiB */
+#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB 
*/
 #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
controller */
 #endif


Oh, and this part is broken. It relies on the fact that all board
define ENV_IS_IN_MMC (which they should), while obviously they
don't. I'm not exactly sure about what the proper fix would be.


Yes, this has been a known problem for a while, but never
became an issue due to lack of NAND support.

My preferred way for dealing with this be would for the
environment code in u-boot allowing to build in multiple
back-ends and use spl_boot_device() which then would need
to loose its spl prefix. For the CHIP devices I'm sure
you can come up with a simpler fix since those don't
have an sdcard-slot. But for other boards this will be
necessary as we really don't want to have separate
nand and mmc u-boot.bin files.

Anyways this is something for whomever will take over
as sunxi custodian from me. Maybe someone from free-electrons
can co-maintain with Jagan ?

Regards,

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

Re: [U-Boot] [PATCH] socfpga: add support for Terasic DE1-SoC board

[Anatolij Gustschin]

Hi,

On Mon, 14 Nov 2016 15:07:31 +0100
Marek Vasut ma...@denx.de wrote:
...
> > +#undef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
> > +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 2  
> 
> Why is this needed ? Just start U-Boot from partition 1 as all the other
> SoCFPGAs do , esp. since this is a devkit, please keep it consistent.

It is not really needed. I used the original Terasic SD-Card,
its raw partition is 2. OK, will remove it.
 
> Looks great otherwise :)

Thanks for review!

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

Re: [U-Boot] [PATCH] Do not force master mode on unaffected PHY's

[Olliver Schinagl]

Hans,


On 14-11-16 15:13, Hans de Goede wrote:

Hi,

On 14-11-16 15:11, Olliver Schinagl wrote:

Hey Hans,


On 14-11-16 12:26, Hans de Goede wrote:

Hi,

On 08-11-16 17:38, Olliver Schinagl wrote:
The current implementation to force the PHY into master mode is to 
have a
define which affects all realtek PHY's. This is not needed as the 
problem
only exists in the RTL8211C chips. Let us thus turn this into a 
quirk flag

instead.


Series looks good to me:

Reviewed-by: Hans de Goede 
Thanks, but keep your eye on the thread. I'm working on a v3 where 
i'm pulling the eeprom stuff out of the sunxi stuff, and in the 
net-uclass layer!


Erm, this is another series :)

Ah poop. You are right! Sorry :)


Regards,

Hans


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

Re: [U-Boot] [PATCH] Do not force master mode on unaffected PHY's

[Hans de Goede]

Hi,

On 14-11-16 15:11, Olliver Schinagl wrote:

Hey Hans,


On 14-11-16 12:26, Hans de Goede wrote:

Hi,

On 08-11-16 17:38, Olliver Schinagl wrote:

The current implementation to force the PHY into master mode is to have a
define which affects all realtek PHY's. This is not needed as the problem
only exists in the RTL8211C chips. Let us thus turn this into a quirk flag
instead.


Series looks good to me:

Reviewed-by: Hans de Goede 

Thanks, but keep your eye on the thread. I'm working on a v3 where i'm pulling 
the eeprom stuff out of the sunxi stuff, and in the net-uclass layer!


Erm, this is another series :)

Regards,

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

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Maxime Ripard]

On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:
> >  #ifdef CONFIG_SPL_SPI_SUNXI
> > @@ -143,7 +157,14 @@
> >  #define CONFIG_GENERIC_MMC
> >  #define CONFIG_MMC_SUNXI
> >  #define CONFIG_MMC_SUNXI_SLOT  0
> > -#define CONFIG_ENV_IS_IN_MMC
> > +#endif
> > +
> > +#if defined(CONFIG_ENV_IS_IN_NAND)
> > +#define CONFIG_ENV_OFFSET  0xc0
> > +#define CONFIG_ENV_SIZE0x40
> > +#elif defined(CONFIG_ENV_IS_IN_MMC)
> > +#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) 
> > KiB */
> > +#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB 
> > */
> >  #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
> > controller */
> >  #endif

Oh, and this part is broken. It relies on the fact that all board
define ENV_IS_IN_MMC (which they should), while obviously they
don't. I'm not exactly sure about what the proper fix would be.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Hans de Goede]

Hi,

On 14-11-16 15:09, Maxime Ripard wrote:

Hi,

On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:

 #ifdef CONFIG_SPL_SPI_SUNXI
@@ -143,7 +157,14 @@
 #define CONFIG_GENERIC_MMC
 #define CONFIG_MMC_SUNXI
 #define CONFIG_MMC_SUNXI_SLOT  0
-#define CONFIG_ENV_IS_IN_MMC
+#endif
+
+#if defined(CONFIG_ENV_IS_IN_NAND)
+#define CONFIG_ENV_OFFSET  0xc0
+#define CONFIG_ENV_SIZE0x40
+#elif defined(CONFIG_ENV_IS_IN_MMC)
+#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) 
KiB */
+#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB 
*/
 #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
controller */
 #endif



I would greatly prefer putting the env in an UBI partition,
I thought that we had agreed on doing that ?


That was mentionned a few times, but I didn't remember having a final
decision. I'm not really sure that putting the environment in UBI
would be a good idea.

Attaching the UBI volume takes a very significant time. Doing so
before the user can see that something is happening in the system
feels pretty bad.


So maybe we need to print a message before doing so ?

We really need bad-block management for the environment, AFAICT
the current non UBI implementation does not even have a backup ?

Regards,

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

Re: [U-Boot] [PATCH] Do not force master mode on unaffected PHY's

[Olliver Schinagl]

Hey Hans,


On 14-11-16 12:26, Hans de Goede wrote:

Hi,

On 08-11-16 17:38, Olliver Schinagl wrote:
The current implementation to force the PHY into master mode is to 
have a
define which affects all realtek PHY's. This is not needed as the 
problem
only exists in the RTL8211C chips. Let us thus turn this into a quirk 
flag

instead.


Series looks good to me:

Reviewed-by: Hans de Goede 
Thanks, but keep your eye on the thread. I'm working on a v3 where i'm 
pulling the eeprom stuff out of the sunxi stuff, and in the net-uclass 
layer!


Olliver


Regards,

Hans


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

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Hans de Goede]

Hi,

On 14-11-16 14:53, Maxime Ripard wrote:

On Mon, Nov 14, 2016 at 12:29:25PM +0100, Hans de Goede wrote:

Hi,

On 14-11-16 12:18, Hans de Goede wrote:

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

This program generates raw SPL images that can be flashed on the NAND with
the ECC and randomizer properly set up.

Signed-off-by: Maxime Ripard 


Looks good to me:

Reviewed-by: Hans de Goede 


Note this causes a cpu_to_be32 redefine compiler warning
I've fixed this up locally.


I'll have to send a v2 based on Tom's comments. How did you fix this?


I added an undef above the define, if you use the
pre-existing macro you get problems later
because it gets called as cpu_to_be32(*addr++)
and the pre-existing macro references its argument
multiple times.

Regards,

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

[U-Boot] [PATCH] [resend] net: fman: fix 2.5G SGMII settings

[shh.xie]

From: Shaohui Xie 

The settings for 2.5G SGMII are wrong, which the 2.5G case is missed in
set_if_mode(), and the serdes PCS configuration are wrong, this patch uses
the correct settings took from Linux.

Signed-off-by: Shaohui Xie 
---
not sure what was wrong, the patch did not show in patchwork, so resend it.
Sorry for the bothering.

 drivers/net/fm/eth.c   | 32 ++--
 drivers/net/fm/memac.c |  1 +
 include/fsl_memac.h|  1 +
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index eb8e936..543aaa8 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -45,9 +45,11 @@ static void dtsec_configure_serdes(struct fm_eth *priv)
 
 qsgmii_loop:
/* SGMII IF mode + AN enable only for 1G SGMII, not for 2.5G */
-   value = PHY_SGMII_IF_MODE_SGMII;
-   if (!sgmii_2500)
-   value |= PHY_SGMII_IF_MODE_AN;
+   value = PHY_SGMII_IF_MODE_SGMII | PHY_SGMII_IF_MODE_AN;
+   if (sgmii_2500)
+   value = PHY_SGMII_CR_PHY_RESET |
+   PHY_SGMII_IF_SPEED_GIGABIT |
+   PHY_SGMII_IF_MODE_SGMII;
 
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x14, value);
 
@@ -55,15 +57,24 @@ qsgmii_loop:
value = PHY_SGMII_DEV_ABILITY_SGMII;
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x4, value);
 
-   /* Adjust link timer for SGMII  -
-   1.6 ms in units of 8 ns = 2 * 10^5 = 0x30d40 */
-   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x3);
-   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xd40);
+   if (sgmii_2500) {
+   /* Adjust link timer for 2.5G SGMII,
+* 1.6 ms in units of 3.2 ns:
+* 1.6ms / 3.2ns = 5 * 10^5 = 0x7a120.
+*/
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x0007);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xa120);
+   } else {
+   /* Adjust link timer for SGMII,
+* 1.6 ms in units of 8 ns:
+* 1.6ms / 8ns = 2 * 10^5 = 0x30d40.
+*/
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x3);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xd40);
+   }
 
/* Restart AN */
-   value = PHY_SGMII_CR_DEF_VAL;
-   if (!sgmii_2500)
-   value |= PHY_SGMII_CR_RESET_AN;
+   value = PHY_SGMII_CR_DEF_VAL | PHY_SGMII_CR_RESET_AN;
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0, value);
 
if ((priv->enet_if == PHY_INTERFACE_MODE_QSGMII) && (i < 3)) {
@@ -391,6 +402,7 @@ static int fm_eth_startup(struct fm_eth *fm_eth)
 
/* For some reason we need to set SPEED_100 */
if (((fm_eth->enet_if == PHY_INTERFACE_MODE_SGMII) ||
+(fm_eth->enet_if == PHY_INTERFACE_MODE_SGMII_2500) ||
 (fm_eth->enet_if == PHY_INTERFACE_MODE_QSGMII)) &&
  mac->set_if_mode)
mac->set_if_mode(mac, fm_eth->enet_if, SPEED_100);
diff --git a/drivers/net/fm/memac.c b/drivers/net/fm/memac.c
index 81a64bf..1b5779c 100644
--- a/drivers/net/fm/memac.c
+++ b/drivers/net/fm/memac.c
@@ -90,6 +90,7 @@ static void memac_set_interface_mode(struct fsl_enet_mac *mac,
if_mode |= (IF_MODE_GMII | IF_MODE_RM);
break;
case PHY_INTERFACE_MODE_SGMII:
+   case PHY_INTERFACE_MODE_SGMII_2500:
case PHY_INTERFACE_MODE_QSGMII:
if_mode &= ~IF_MODE_MASK;
if_mode |= (IF_MODE_GMII);
diff --git a/include/fsl_memac.h b/include/fsl_memac.h
index bed2a40..431c2a0 100644
--- a/include/fsl_memac.h
+++ b/include/fsl_memac.h
@@ -226,6 +226,7 @@ struct memac {
 #define PHY_SGMII_CR_PHY_RESET  0x8000
 #define PHY_SGMII_CR_RESET_AN   0x0200
 #define PHY_SGMII_CR_DEF_VAL0x1140
+#define PHY_SGMII_IF_SPEED_GIGABIT  0x0008
 #define PHY_SGMII_DEV_ABILITY_SGMII 0x4001
 #define PHY_SGMII_IF_MODE_AN0x0002
 #define PHY_SGMII_IF_MODE_SGMII 0x0001
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH] net: fman: fix 2.5G SGMII settings

[shh.xie]

From: Shaohui Xie 

The settings for 2.5G SGMII are wrong, which the 2.5G case is missed in
set_if_mode(), and the serdes PCS configuration are wrong, this patch uses
the correct settings took from Linux.

Signed-off-by: Shaohui Xie 
---
 drivers/net/fm/eth.c   | 32 ++--
 drivers/net/fm/memac.c |  1 +
 include/fsl_memac.h|  1 +
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index eb8e936..543aaa8 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -45,9 +45,11 @@ static void dtsec_configure_serdes(struct fm_eth *priv)
 
 qsgmii_loop:
/* SGMII IF mode + AN enable only for 1G SGMII, not for 2.5G */
-   value = PHY_SGMII_IF_MODE_SGMII;
-   if (!sgmii_2500)
-   value |= PHY_SGMII_IF_MODE_AN;
+   value = PHY_SGMII_IF_MODE_SGMII | PHY_SGMII_IF_MODE_AN;
+   if (sgmii_2500)
+   value = PHY_SGMII_CR_PHY_RESET |
+   PHY_SGMII_IF_SPEED_GIGABIT |
+   PHY_SGMII_IF_MODE_SGMII;
 
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x14, value);
 
@@ -55,15 +57,24 @@ qsgmii_loop:
value = PHY_SGMII_DEV_ABILITY_SGMII;
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x4, value);
 
-   /* Adjust link timer for SGMII  -
-   1.6 ms in units of 8 ns = 2 * 10^5 = 0x30d40 */
-   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x3);
-   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xd40);
+   if (sgmii_2500) {
+   /* Adjust link timer for 2.5G SGMII,
+* 1.6 ms in units of 3.2 ns:
+* 1.6ms / 3.2ns = 5 * 10^5 = 0x7a120.
+*/
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x0007);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xa120);
+   } else {
+   /* Adjust link timer for SGMII,
+* 1.6 ms in units of 8 ns:
+* 1.6ms / 8ns = 2 * 10^5 = 0x30d40.
+*/
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x3);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xd40);
+   }
 
/* Restart AN */
-   value = PHY_SGMII_CR_DEF_VAL;
-   if (!sgmii_2500)
-   value |= PHY_SGMII_CR_RESET_AN;
+   value = PHY_SGMII_CR_DEF_VAL | PHY_SGMII_CR_RESET_AN;
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0, value);
 
if ((priv->enet_if == PHY_INTERFACE_MODE_QSGMII) && (i < 3)) {
@@ -391,6 +402,7 @@ static int fm_eth_startup(struct fm_eth *fm_eth)
 
/* For some reason we need to set SPEED_100 */
if (((fm_eth->enet_if == PHY_INTERFACE_MODE_SGMII) ||
+(fm_eth->enet_if == PHY_INTERFACE_MODE_SGMII_2500) ||
 (fm_eth->enet_if == PHY_INTERFACE_MODE_QSGMII)) &&
  mac->set_if_mode)
mac->set_if_mode(mac, fm_eth->enet_if, SPEED_100);
diff --git a/drivers/net/fm/memac.c b/drivers/net/fm/memac.c
index 81a64bf..1b5779c 100644
--- a/drivers/net/fm/memac.c
+++ b/drivers/net/fm/memac.c
@@ -90,6 +90,7 @@ static void memac_set_interface_mode(struct fsl_enet_mac *mac,
if_mode |= (IF_MODE_GMII | IF_MODE_RM);
break;
case PHY_INTERFACE_MODE_SGMII:
+   case PHY_INTERFACE_MODE_SGMII_2500:
case PHY_INTERFACE_MODE_QSGMII:
if_mode &= ~IF_MODE_MASK;
if_mode |= (IF_MODE_GMII);
diff --git a/include/fsl_memac.h b/include/fsl_memac.h
index bed2a40..431c2a0 100644
--- a/include/fsl_memac.h
+++ b/include/fsl_memac.h
@@ -226,6 +226,7 @@ struct memac {
 #define PHY_SGMII_CR_PHY_RESET  0x8000
 #define PHY_SGMII_CR_RESET_AN   0x0200
 #define PHY_SGMII_CR_DEF_VAL0x1140
+#define PHY_SGMII_IF_SPEED_GIGABIT  0x0008
 #define PHY_SGMII_DEV_ABILITY_SGMII 0x4001
 #define PHY_SGMII_IF_MODE_AN0x0002
 #define PHY_SGMII_IF_MODE_SGMII 0x0001
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Maxime Ripard]

Hi,

On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:
> >  #ifdef CONFIG_SPL_SPI_SUNXI
> > @@ -143,7 +157,14 @@
> >  #define CONFIG_GENERIC_MMC
> >  #define CONFIG_MMC_SUNXI
> >  #define CONFIG_MMC_SUNXI_SLOT  0
> > -#define CONFIG_ENV_IS_IN_MMC
> > +#endif
> > +
> > +#if defined(CONFIG_ENV_IS_IN_NAND)
> > +#define CONFIG_ENV_OFFSET  0xc0
> > +#define CONFIG_ENV_SIZE0x40
> > +#elif defined(CONFIG_ENV_IS_IN_MMC)
> > +#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) 
> > KiB */
> > +#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB 
> > */
> >  #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
> > controller */
> >  #endif
> > 
> 
> I would greatly prefer putting the env in an UBI partition,
> I thought that we had agreed on doing that ?

That was mentionned a few times, but I didn't remember having a final
decision. I'm not really sure that putting the environment in UBI
would be a good idea.

Attaching the UBI volume takes a very significant time. Doing so
before the user can see that something is happening in the system
feels pretty bad.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[U-Boot] [PATCH] net: phy: micrel: Fix error handling

[Marek Vasut]

Fix the following error, the $ret variable handling must
be part of the loop, while due to the missing parenthesis
it was not.

drivers/net/phy/micrel.c: In function ‘ksz9021_of_config’:
drivers/net/phy/micrel.c:303:2: warning: this ‘for’ clause does not guard... 
[-Wmisleading-indentation]
  for (i = 0; i < ARRAY_SIZE(ofcfg); i++)
  ^~~
drivers/net/phy/micrel.c:305:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the ‘for’
   if (ret)
   ^~
drivers/net/phy/micrel.c: In function ‘ksz9031_of_config’:
drivers/net/phy/micrel.c:411:2: warning: this ‘for’ clause does not guard... 
[-Wmisleading-indentation]
  for (i = 0; i < ARRAY_SIZE(ofcfg); i++)
  ^~~
drivers/net/phy/micrel.c:413:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the ‘for’
   if (ret)
   ^~

Signed-off-by: Marek Vasut 
Cc: Joe Hershberger 
---
 drivers/net/phy/micrel.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 28a1401..7163fa2 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -300,10 +300,11 @@ static int ksz9021_of_config(struct phy_device *phydev)
};
int i, ret = 0;
 
-   for (i = 0; i < ARRAY_SIZE(ofcfg); i++)
+   for (i = 0; i < ARRAY_SIZE(ofcfg); i++) {
ret = ksz90x1_of_config_group(phydev, &(ofcfg[i]));
if (ret)
return ret;
+   }
 
return 0;
 }
@@ -408,10 +409,11 @@ static int ksz9031_of_config(struct phy_device *phydev)
};
int i, ret = 0;
 
-   for (i = 0; i < ARRAY_SIZE(ofcfg); i++)
+   for (i = 0; i < ARRAY_SIZE(ofcfg); i++) {
ret = ksz90x1_of_config_group(phydev, &(ofcfg[i]));
if (ret)
return ret;
+   }
 
return 0;
 }
-- 
2.10.2

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

Re: [U-Boot] [PATCH] socfpga: add support for Terasic DE1-SoC board

[Marek Vasut]

On 11/14/2016 02:53 PM, Anatolij Gustschin wrote:
> Add CycloneV based Terasic DE1-SoC board. The board boots
> from SD/MMC. Ethernet and USB host is supported.
> 
> Signed-off-by: Anatolij Gustschin 
> Cc: Marek Vasut 

[...]

> diff --git a/include/configs/socfpga_de1_soc.h 
> b/include/configs/socfpga_de1_soc.h
> new file mode 100644
> index 000..9514b27
> --- /dev/null
> +++ b/include/configs/socfpga_de1_soc.h
> @@ -0,0 +1,60 @@
> +/*
> + * Copyright (C) 2016 Marek Vasut 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +#ifndef __CONFIG_TERASIC_DE1_SOC_H__
> +#define __CONFIG_TERASIC_DE1_SOC_H__
> +
> +#include 
> +
> +/* U-Boot Commands */
> +#define CONFIG_SYS_NO_FLASH
> +#define CONFIG_DOS_PARTITION
> +#define CONFIG_FAT_WRITE
> +#define CONFIG_HW_WATCHDOG
> +
> +/* Memory configurations */
> +#define PHYS_SDRAM_1_SIZE0x4000  /* 1GiB */
> +
> +/* Booting Linux */
> +#define CONFIG_BOOTFILE  "fitImage"
> +#define CONFIG_BOOTARGS  "console=ttyS0," 
> __stringify(CONFIG_BAUDRATE)
> +#define CONFIG_BOOTCOMMAND   "run mmcload; run mmcboot"
> +#define CONFIG_LOADADDR  0x0100
> +#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
> +
> +/* Ethernet on SoC (EMAC) */
> +#if defined(CONFIG_CMD_NET)
> +#define CONFIG_PHY_MICREL
> +#define CONFIG_PHY_MICREL_KSZ9021
> +#endif
> +
> +#define CONFIG_ENV_IS_IN_MMC
> +
> +/* Extra Environment */
> +#define CONFIG_EXTRA_ENV_SETTINGS \
> + "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
> + "bootm ${loadaddr} - ${fdtaddr}\0" \
> + "bootimage=zImage\0" \
> + "fdtaddr=100\0" \
> + "fdtimage=socfpga.dtb\0" \
> + "bootm ${loadaddr} - ${fdtaddr}\0" \
> + "mmcroot=/dev/mmcblk0p2\0" \
> + "mmcboot=setenv bootargs " CONFIG_BOOTARGS \
> + " root=${mmcroot} rw rootwait;" \
> + "bootz ${loadaddr} - ${fdtaddr}\0" \
> + "mmcload=mmc rescan;" \
> + "load mmc 0:1 ${loadaddr} ${bootimage};" \
> + "load mmc 0:1 ${fdtaddr} ${fdtimage}\0" \
> +
> +/* The rest of the configuration is shared */
> +#include 
> +
> +#undef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION   2

Why is this needed ? Just start U-Boot from partition 1 as all the other
SoCFPGAs do , esp. since this is a devkit, please keep it consistent.

Looks great otherwise :)

> +#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
> +
> +#endif   /* __CONFIG_TERASIC_DE1_SOC_H__ */
> 


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

[U-Boot] [PATCH] socfpga: add support for Terasic DE1-SoC board

[Anatolij Gustschin]

Add CycloneV based Terasic DE1-SoC board. The board boots
from SD/MMC. Ethernet and USB host is supported.

Signed-off-by: Anatolij Gustschin 
Cc: Marek Vasut 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/socfpga_cyclone5_de1_soc.dts |  66 +++
 arch/arm/mach-socfpga/Kconfig |   7 +
 board/terasic/de1-soc/MAINTAINERS |   5 +
 board/terasic/de1-soc/Makefile|   9 +
 board/terasic/de1-soc/qts/iocsr_config.h  | 660 ++
 board/terasic/de1-soc/qts/pinmux_config.h | 219 ++
 board/terasic/de1-soc/qts/pll_config.h|  91 
 board/terasic/de1-soc/qts/sdram_config.h  | 344 
 board/terasic/de1-soc/socfpga.c   |  19 +
 configs/socfpga_de1_soc_defconfig |  50 +++
 include/configs/socfpga_de1_soc.h |  60 +++
 12 files changed, 1531 insertions(+)
 create mode 100644 arch/arm/dts/socfpga_cyclone5_de1_soc.dts
 create mode 100644 board/terasic/de1-soc/MAINTAINERS
 create mode 100644 board/terasic/de1-soc/Makefile
 create mode 100644 board/terasic/de1-soc/qts/iocsr_config.h
 create mode 100644 board/terasic/de1-soc/qts/pinmux_config.h
 create mode 100644 board/terasic/de1-soc/qts/pll_config.h
 create mode 100644 board/terasic/de1-soc/qts/sdram_config.h
 create mode 100644 board/terasic/de1-soc/socfpga.c
 create mode 100644 configs/socfpga_de1_soc_defconfig
 create mode 100644 include/configs/socfpga_de1_soc.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 836a8c4..36bda16 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -128,6 +128,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=   
\
socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_de0_nano_soc.dtb   \
+   socfpga_cyclone5_de1_soc.dtb\
socfpga_cyclone5_sockit.dtb \
socfpga_cyclone5_socrates.dtb   \
socfpga_cyclone5_sr1500.dtb \
diff --git a/arch/arm/dts/socfpga_cyclone5_de1_soc.dts 
b/arch/arm/dts/socfpga_cyclone5_de1_soc.dts
new file mode 100644
index 000..a583990
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_de1_soc.dts
@@ -0,0 +1,66 @@
+/*
+ * Copyright Altera Corporation (C) 2015
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "Terasic DE1-SoC";
+   compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   aliases {
+   ethernet0 = 
+   udc0 = 
+   };
+
+   memory {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x4000>; /* 1GB */
+   };
+
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+
+   rxd0-skew-ps = <420>;
+   rxd1-skew-ps = <420>;
+   rxd2-skew-ps = <420>;
+   rxd3-skew-ps = <420>;
+   txen-skew-ps = <0>;
+   txc-skew-ps = <1860>;
+   rxdv-skew-ps = <420>;
+   rxc-skew-ps = <1680>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index d91b8bb..6991af8 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -74,6 +74,10 @@ config TARGET_SOCFPGA_TERASIC_DE0_NANO
bool "Terasic DE0-Nano-Atlas (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
 
+config TARGET_SOCFPGA_TERASIC_DE1_SOC
+   bool "Terasic DE1-SoC (Cyclone V)"
+   select TARGET_SOCFPGA_CYCLONE5
+
 config TARGET_SOCFPGA_TERASIC_SOCKIT
bool "Terasic SoCkit (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
@@ -84,6 +88,7 @@ config SYS_BOARD
default "arria5-socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
default "cyclone5-socdk" if TARGET_SOCFPGA_CYCLONE5_SOCDK
default "de0-nano-soc" if TARGET_SOCFPGA_TERASIC_DE0_NANO
+   default "de1-soc" if TARGET_SOCFPGA_TERASIC_DE1_SOC
default "is1" if TARGET_SOCFPGA_IS1
default "mcvevk" if TARGET_SOCFPGA_DENX_MCVEVK
default "sockit" if TARGET_SOCFPGA_TERASIC_SOCKIT
@@ -98,6 +103,7 @@ config SYS_VENDOR
default "ebv" if TARGET_SOCFPGA_EBV_SOCRATES
default "samtec" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
default "terasic" if TARGET_SOCFPGA_TERASIC_DE0_NANO
+   default "terasic" if TARGET_SOCFPGA_TERASIC_DE1_SOC
default "terasic" if TARGET_SOCFPGA_TERASIC_SOCKIT
 
 config SYS_SOC
@@ -107,6 +113,7 @@ config SYS_CONFIG_NAME
default "socfpga_arria5_socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
default "socfpga_cyclone5_socdk" if 

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Maxime Ripard]

On Mon, Nov 14, 2016 at 12:29:25PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 14-11-16 12:18, Hans de Goede wrote:
> > Hi,
> > 
> > On 08-11-16 17:21, Maxime Ripard wrote:
> > > This program generates raw SPL images that can be flashed on the NAND with
> > > the ECC and randomizer properly set up.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > 
> > Looks good to me:
> > 
> > Reviewed-by: Hans de Goede 
> 
> Note this causes a cpu_to_be32 redefine compiler warning
> I've fixed this up locally.

I'll have to send a v2 based on Tom's comments. How did you fix this?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH] MAINTAINERS: mark sunxi status as Orphan

[Ian Campbell]

On Mon, 2016-11-14 at 12:53 +0100, Hans de Goede wrote:
> Ian has not had any time for sunxi for some time now and I'm
> in the same situation now, so I'm stepping down as sunxi
> custodian and marking the sunxi support as Orphan.
> 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Ian Campbell 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 

:-(

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

Re: [U-Boot] [PATCH RESEND 6/9] eeprom: Add DS2431 support

[Maxime Ripard]

Hi,

On Fri, Nov 11, 2016 at 11:16:39AM -0800, Moritz Fischer wrote:
> > +U_BOOT_DRIVER(ds2431) = {
> > +   .name   = "ds2431",
> > +   .id = UCLASS_EEPROM,
> > +   .ops= _ops,
> 
> Do you want to add a .flags = DM_UC_FLAG_SEQ_ALIAS here?

I don't know. I was kind of wondering why U-Boot relies on aliases so
much, especially when the Linux DT maintainers are saying that aliases
should be avoided entirely, and we'll won't be able to upstream those
changes.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH RESEND 5/9] EEPROM: Add an EEPROM uclass

[Maxime Ripard]

Hi Moritz,

On Fri, Nov 11, 2016 at 11:13:39AM -0800, Moritz Fischer wrote:
> Hi Maxime,
> 
> On Fri, Nov 11, 2016 at 8:17 AM, Simon Glass  wrote:
> > Hi Maxime,
> >
> > On 8 November 2016 at 03:19, Maxime Ripard
> >  wrote:
> >> We might want to access data stored onto EEPROMs. Create a framework to
> >> provide a consistent API.
> >
> > We have UCLASS_I2C_EEPROM. Can we unify these? If not, please add a
> > sandbox driver and test.
> 
> I've been working on something very similar (the API looks the same obviously,
> since the ops are pretty trivial, modulo function names)
> In my opinion it should be working as follows:
> 
> UCLASS_EEPROM
>   \... I2C_EEPROM
>   \SPI_EEPROM (AT25)

I agree. Different board variations might be using different buses to
store the same data, and it's all EEPROM anyway.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH 4/9] w1: Add 1-Wire gpio driver

[Maxime Ripard]

Hi Simon,

On Fri, Nov 11, 2016 at 09:17:20AM -0700, Simon Glass wrote:
> Hi Maxime,
> 
> On 8 November 2016 at 03:06, Maxime Ripard
>  wrote:
> > Add a bus driver for bitbanging a 1-Wire bus over a GPIO.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/w1/Kconfig   |   6 ++-
> >  drivers/w1/Makefile  |   1 +-
> >  drivers/w1/w1-gpio.c | 160 -
> >  3 files changed, 167 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/w1/w1-gpio.c
> >
> > diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
> > index 0c056b4c06a9..ccc3ae15db86 100644
> > --- a/drivers/w1/Kconfig
> > +++ b/drivers/w1/Kconfig
> > @@ -12,6 +12,12 @@ config W1
> >
> >  if W1
> >
> > +config W1_GPIO
> > +   bool "Enable 1-Wire GPIO bitbanging"
> > +   depends on DM_GPIO
> > +   help
> > + Emulate a 1-Wire bus using a GPIO.
> 
> Any more details? How many GPIOs? Any particular chips that are
> supported?

1-Wire works on a single line, hence it's name. You usually have
either a controller (which is quite rare, but some SoCs have one) or
you can bitbang the bus. It's low bandwidth enough that it doesn't
really matter.

I'm not sure if it answers your question. I'll address your other
comments.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] Stepping down as sunxi u-boot custodian (for real this time)

[Tom Rini]

On Mon, Nov 14, 2016 at 12:53:13PM +0100, Hans de Goede wrote:
> Hi All,
> 
> A while back I wrote:
> 
> "Between my $dayjob, linux-sunxi, other foss projects and last but
> not least spending time with my wife and children I'm way too
> busy lately.
> 
> So I've decided to seriously scale back my involvement in
> linux-sunxi, as such I'm going to step down as u-boot sunxi
> custodian."
> 
> After that I did get some breathing room, and kept doing
> sunxi u-boot maintenance until now, but this still feels
> too much like a job rather then a hobby. The problem is
> that I don't want to think during the weekend:
> "Oh !@#$ I still need to prep a u-boot sunxi pull-req"
> 
> This is nothing against the u-boot community, I think
> you're all great and I still love thinkering with this
> kind of stuff, but when a hobby starts feeling as a chore
> something is wrong.
> 
> So after this mail I'm going to send a mail updating
> the MAINTAINERS status of sunxi to orphan and I will also
> unsubscribe myself from the u-boot list to protect myself
> against getting dragged in again.
> 
> I do expect (after taking a break for a couple of weeks)
> that I will likely submit the occasional patch, but at
> this point in time I do not want any maintainer
> responsibilities.
> 
> Yesterday and today I've gone over my pending patches
> queue, reviewed then all and I've merged all the ones
> which looked good into u-boot-sunxi/next, so that
> should be a good starting point for the next
> maintainer.

I just want to thank you for all the time and effort you've put in on
U-Boot you've put in.  We would not be where we are today without what
you've done, so once again, thanks!

-- 
Tom


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

[U-Boot] [PATCH] [resend] net: fman: fix 2.5G SGMII settings

[Shaohui Xie]

The settings for 2.5G SGMII are wrong, which the 2.5G case is missed in
set_if_mode(), and the serdes PCS configuration are wrong, this patch uses
the correct settings took from Linux.

Signed-off-by: Shaohui Xie 
---
not sure what was wrong, the patch did not show in patchwork, so resend it.
Sorry for the bothering.

 drivers/net/fm/eth.c   | 32 ++--
 drivers/net/fm/memac.c |  1 +
 include/fsl_memac.h|  1 +
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index eb8e936..543aaa8 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -45,9 +45,11 @@ static void dtsec_configure_serdes(struct fm_eth *priv)
 
 qsgmii_loop:
/* SGMII IF mode + AN enable only for 1G SGMII, not for 2.5G */
-   value = PHY_SGMII_IF_MODE_SGMII;
-   if (!sgmii_2500)
-   value |= PHY_SGMII_IF_MODE_AN;
+   value = PHY_SGMII_IF_MODE_SGMII | PHY_SGMII_IF_MODE_AN;
+   if (sgmii_2500)
+   value = PHY_SGMII_CR_PHY_RESET |
+   PHY_SGMII_IF_SPEED_GIGABIT |
+   PHY_SGMII_IF_MODE_SGMII;
 
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x14, value);
 
@@ -55,15 +57,24 @@ qsgmii_loop:
value = PHY_SGMII_DEV_ABILITY_SGMII;
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x4, value);
 
-   /* Adjust link timer for SGMII  -
-   1.6 ms in units of 8 ns = 2 * 10^5 = 0x30d40 */
-   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x3);
-   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xd40);
+   if (sgmii_2500) {
+   /* Adjust link timer for 2.5G SGMII,
+* 1.6 ms in units of 3.2 ns:
+* 1.6ms / 3.2ns = 5 * 10^5 = 0x7a120.
+*/
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x0007);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xa120);
+   } else {
+   /* Adjust link timer for SGMII,
+* 1.6 ms in units of 8 ns:
+* 1.6ms / 8ns = 2 * 10^5 = 0x30d40.
+*/
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x13, 0x3);
+   memac_mdio_write(, i, MDIO_DEVAD_NONE, 0x12, 0xd40);
+   }
 
/* Restart AN */
-   value = PHY_SGMII_CR_DEF_VAL;
-   if (!sgmii_2500)
-   value |= PHY_SGMII_CR_RESET_AN;
+   value = PHY_SGMII_CR_DEF_VAL | PHY_SGMII_CR_RESET_AN;
memac_mdio_write(, i, MDIO_DEVAD_NONE, 0, value);
 
if ((priv->enet_if == PHY_INTERFACE_MODE_QSGMII) && (i < 3)) {
@@ -391,6 +402,7 @@ static int fm_eth_startup(struct fm_eth *fm_eth)
 
/* For some reason we need to set SPEED_100 */
if (((fm_eth->enet_if == PHY_INTERFACE_MODE_SGMII) ||
+(fm_eth->enet_if == PHY_INTERFACE_MODE_SGMII_2500) ||
 (fm_eth->enet_if == PHY_INTERFACE_MODE_QSGMII)) &&
  mac->set_if_mode)
mac->set_if_mode(mac, fm_eth->enet_if, SPEED_100);
diff --git a/drivers/net/fm/memac.c b/drivers/net/fm/memac.c
index 81a64bf..1b5779c 100644
--- a/drivers/net/fm/memac.c
+++ b/drivers/net/fm/memac.c
@@ -90,6 +90,7 @@ static void memac_set_interface_mode(struct fsl_enet_mac *mac,
if_mode |= (IF_MODE_GMII | IF_MODE_RM);
break;
case PHY_INTERFACE_MODE_SGMII:
+   case PHY_INTERFACE_MODE_SGMII_2500:
case PHY_INTERFACE_MODE_QSGMII:
if_mode &= ~IF_MODE_MASK;
if_mode |= (IF_MODE_GMII);
diff --git a/include/fsl_memac.h b/include/fsl_memac.h
index bed2a40..431c2a0 100644
--- a/include/fsl_memac.h
+++ b/include/fsl_memac.h
@@ -226,6 +226,7 @@ struct memac {
 #define PHY_SGMII_CR_PHY_RESET  0x8000
 #define PHY_SGMII_CR_RESET_AN   0x0200
 #define PHY_SGMII_CR_DEF_VAL0x1140
+#define PHY_SGMII_IF_SPEED_GIGABIT  0x0008
 #define PHY_SGMII_DEV_ABILITY_SGMII 0x4001
 #define PHY_SGMII_IF_MODE_AN0x0002
 #define PHY_SGMII_IF_MODE_SGMII 0x0001
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] Stepping down as sunxi u-boot custodian (for real this time)

[Stefan Roese]

Hi Hans,

On 14.11.2016 12:53, Hans de Goede wrote:

A while back I wrote:

"Between my $dayjob, linux-sunxi, other foss projects and last but
not least spending time with my wife and children I'm way too
busy lately.

So I've decided to seriously scale back my involvement in
linux-sunxi, as such I'm going to step down as u-boot sunxi
custodian."

After that I did get some breathing room, and kept doing
sunxi u-boot maintenance until now, but this still feels
too much like a job rather then a hobby. The problem is
that I don't want to think during the weekend:
"Oh !@#$ I still need to prep a u-boot sunxi pull-req"

This is nothing against the u-boot community, I think
you're all great and I still love thinkering with this
kind of stuff, but when a hobby starts feeling as a chore
something is wrong.

So after this mail I'm going to send a mail updating
the MAINTAINERS status of sunxi to orphan and I will also
unsubscribe myself from the u-boot list to protect myself
against getting dragged in again.


This is very sad and unfortunate for the U-Boot community. I'm really
sorry to hear this. But I can fully understand you and totally
respect your decision.

I would like to thank you for all your input and hard work that
you've done for this project in the last years. Your comments
have always been very productive and your dedicated involvement
has taken the sunxi U-Boot support to the next level and also
improved U-Boot in general.

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

Re: [U-Boot] [PATCH 2/4] mmc: sunxi: Enable 8bits bus width for sun8i

[Jaehoon Chung]

On 11/14/2016 03:51 AM, Hans de Goede wrote:
> Hi,
> 
> On 04-11-16 16:18, Maxime Ripard wrote:
>> The sun8i SoCs also have a 8 bits capable MMC2 controller. Enable the
>> support for those too.
>>
>> Signed-off-by: Maxime Ripard 
> 
> LGTM:
> 
> Reviewed-by: Hans de Goede 

Applied on u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> Regards,
> 
> Hans
> 
> 
>> ---
>>  drivers/mmc/sunxi_mmc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
>> index 6953accce123..b8716c93cb06 100644
>> --- a/drivers/mmc/sunxi_mmc.c
>> +++ b/drivers/mmc/sunxi_mmc.c
>> @@ -463,7 +463,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>>
>>  cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
>>  cfg->host_caps = MMC_MODE_4BIT;
>> -#ifdef CONFIG_MACH_SUN50I
>> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
>>  if (sdc_no == 2)
>>  cfg->host_caps = MMC_MODE_8BIT;
>>  #endif
>>
> 
> 
> 

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

Re: [U-Boot] [PATCH 4/4] sunxi: sina33: Enable the LCD

[Jaehoon Chung]

On 11/14/2016 03:51 AM, Hans de Goede wrote:
> Hi,
> 
> On 04-11-16 16:18, Maxime Ripard wrote:
>> The SinA33 comes with an optional 7" display. Enable it in the
>> configuration.
>>
>> Signed-off-by: Maxime Ripard 
> 
> LGTM:
> 
> Reviewed-by: Hans de Goede 

Applied on u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> Regards,
> 
> Hans
> 
> 
> 
>> ---
>>  configs/Sinlinx_SinA33_defconfig | 4 
>>  1 file changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/configs/Sinlinx_SinA33_defconfig 
>> b/configs/Sinlinx_SinA33_defconfig
>> index f4719db2d501..26b119a9b92f 100644
>> --- a/configs/Sinlinx_SinA33_defconfig
>> +++ b/configs/Sinlinx_SinA33_defconfig
>> @@ -6,6 +6,10 @@ CONFIG_DRAM_ZQ=15291
>>  CONFIG_MMC0_CD_PIN="PB4"
>>  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>>  CONFIG_USB0_ID_DET="PH8"
>> +CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:66000,le:90,ri:160,up:3,lo:127,hs:70,vs:20,sync:3,vmode:0"
>> +CONFIG_VIDEO_LCD_DCLK_PHASE=0
>> +CONFIG_VIDEO_LCD_BL_EN="PH6"
>> +CONFIG_VIDEO_LCD_BL_PWM="PH0"
>>  CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
>>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>>  CONFIG_SPL=y
>>
> 
> 
> 

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

Re: [U-Boot] [PATCH 3/4] sunxi: sina33: Enable the eMMC

[Jaehoon Chung]

On 11/14/2016 03:51 AM, Hans de Goede wrote:
> Hi,
> 
> On 04-11-16 16:18, Maxime Ripard wrote:
>> The SinA33 has an 4GB Toshiba eMMC connected to the MMC2 controller.
>> Enable it.
>>
>> Signed-off-by: Maxime Ripard 
> 
> LGTM:
> 
> Reviewed-by: Hans de Goede 

Applied on u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> Regards,
> 
> Hans
> 
> 
>> ---
>>  configs/Sinlinx_SinA33_defconfig | 1 +
>>  1 file changed, 1 insertion(+), 0 deletions(-)
>>
>> diff --git a/configs/Sinlinx_SinA33_defconfig 
>> b/configs/Sinlinx_SinA33_defconfig
>> index 2a5f985dd303..f4719db2d501 100644
>> --- a/configs/Sinlinx_SinA33_defconfig
>> +++ b/configs/Sinlinx_SinA33_defconfig
>> @@ -4,6 +4,7 @@ CONFIG_MACH_SUN8I_A33=y
>>  CONFIG_DRAM_CLK=552
>>  CONFIG_DRAM_ZQ=15291
>>  CONFIG_MMC0_CD_PIN="PB4"
>> +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>>  CONFIG_USB0_ID_DET="PH8"
>>  CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
>>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>>
> 
> 
> 

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

Re: [U-Boot] [PATCH 1/4] mmc: Retry the switch command

[Jaehoon Chung]

On 11/14/2016 03:50 AM, Hans de Goede wrote:
> Hi,
> 
> On 04-11-16 16:18, Maxime Ripard wrote:
>> Some eMMC will fail at the first switch, but would succeed in a subsequent
>> one.
>>
>> Make sure we try several times to cover those cases. The number of retries
>> (and the behaviour) is currently what is being used in Linux.
>>
>> Signed-off-by: Maxime Ripard 
> 
> LGTM:
> 
> Reviewed-by: Hans de Goede 
> 
> Pantelis or Tom, can you pick this up please ?

Applied on u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> Regards,
> 
> Hans
> 
> 
>> ---
>>  drivers/mmc/mmc.c | 15 +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index 4380c7c195a6..d6b7e4f510c9 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -494,6 +494,7 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 
>> value)
>>  {
>>  struct mmc_cmd cmd;
>>  int timeout = 1000;
>> +int retries = 3;
>>  int ret;
>>
>>  cmd.cmdidx = MMC_CMD_SWITCH;
>> @@ -502,11 +503,17 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 
>> value)
>>   (index << 16) |
>>   (value << 8);
>>
>> -ret = mmc_send_cmd(mmc, , NULL);
>> +while (retries > 0) {
>> +ret = mmc_send_cmd(mmc, , NULL);
>>
>> -/* Waiting for the ready status */
>> -if (!ret)
>> -ret = mmc_send_status(mmc, timeout);
>> +/* Waiting for the ready status */
>> +if (!ret) {
>> +ret = mmc_send_status(mmc, timeout);
>> +return ret;
>> +}
>> +
>> +retries--;
>> +}
>>
>>  return ret;
>>
>>
> 
> 
> 

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

[U-Boot] [PATCH] MAINTAINERS: mark sunxi status as Orphan

[Hans de Goede]

Ian has not had any time for sunxi for some time now and I'm
in the same situation now, so I'm stepping down as sunxi
custodian and marking the sunxi support as Orphan.

Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: Ian Campbell 
Signed-off-by: Hans de Goede 
---
 MAINTAINERS | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0bd8995..83a70df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -167,9 +167,7 @@ F:  arch/arm/cpu/armv7/stv0991/
 F: arch/arm/include/asm/arch-stv0991/
 
 ARM SUNXI
-M: Ian Campbell 
-M: Hans De Goede 
-S: Maintained
+S: Orphan
 T: git git://git.denx.de/u-boot-sunxi.git
 F: arch/arm/cpu/armv7/sunxi/
 F: arch/arm/include/asm/arch-sunxi/
-- 
2.9.3

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

[U-Boot] Stepping down as sunxi u-boot custodian (for real this time)

[Hans de Goede]

Hi All,

A while back I wrote:

"Between my $dayjob, linux-sunxi, other foss projects and last but
not least spending time with my wife and children I'm way too
busy lately.

So I've decided to seriously scale back my involvement in
linux-sunxi, as such I'm going to step down as u-boot sunxi
custodian."

After that I did get some breathing room, and kept doing
sunxi u-boot maintenance until now, but this still feels
too much like a job rather then a hobby. The problem is
that I don't want to think during the weekend:
"Oh !@#$ I still need to prep a u-boot sunxi pull-req"

This is nothing against the u-boot community, I think
you're all great and I still love thinkering with this
kind of stuff, but when a hobby starts feeling as a chore
something is wrong.

So after this mail I'm going to send a mail updating
the MAINTAINERS status of sunxi to orphan and I will also
unsubscribe myself from the u-boot list to protect myself
against getting dragged in again.

I do expect (after taking a break for a couple of weeks)
that I will likely submit the occasional patch, but at
this point in time I do not want any maintainer
responsibilities.

Yesterday and today I've gone over my pending patches
queue, reviewed then all and I've merged all the ones
which looked good into u-boot-sunxi/next, so that
should be a good starting point for the next
maintainer.

Jagan (in the Cc) has indicated in the past that he is
interested in taking over as sunxi custodian, Jagan already
is the SPI custodian, so I believe that he will do well.

So Jagan, if you still want the job, go for it.

Regards,

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

Re: [U-Boot] [PATCH 6/7] scripts: sunxi: Build an raw SPL image

[Hans de Goede]

Hi,

On 14-11-16 12:19, Hans de Goede wrote:

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

Introduce a new sunxi-spl-with-ecc.bin image with already the right header,
ECC, randomizer and padding for the BROM to be able to read it.

It needs to be flashed using a raw access to the NAND so that the
controller doesn't change a thing to it, since we already have all the
right parameters.

Signed-off-by: Maxime Ripard 


Looks good to me:

Reviewed-by: Hans de Goede 


Scrap that, this causes all sunxi boars to fail to build:

+--page is missing
+sunxi-nand-image-builder 2016.11-rc3-00069-gabe4d57
+Usage: sunxi-nand-image-builder [OPTIONS] source-image output-image
+Creates a raw NAND image that can be read by the sunxi NAND controller.
+-h   --help   Display this help and exit
+-c /  --ecc=/   ECC config (strength/step-size)
+-p --page=Page size
+-o --oob= OOB size
+-u --usable=  Usable page size
+-e --eraseblock=  Erase block size
+-b   --boot0  Build a boot0 image.
+-s   --scramble   Scramble data
+  Valid ECC strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64
+  Valid ECC step size: 512 and 1024
+If you are building a boot0 image, you'll have specify extra options.
+These options should be chosen based on the layouts described here:
+  http://linux-sunxi.org/NAND#More_information_on_BROM_NAND
+  --usable should be assigned the 'Hardware page' value
+  --ecc should be assigned the 'ECC capacity'/'ECC page' values
+  --usable should be smaller than --page
+The --address option is only required for non-boot0 images that are
+meant to be programmed at a non eraseblock aligned offset.
+Examples:
+  The H27UCG8T2BTR-BC NAND exposes
+  * 16k pages
+  * 1280 OOB bytes per page
+  * 4M eraseblocks
+  * requires data scrambling
+  * expects a minimum ECC of 40bits/1024bytes
+  A normal image can be generated with
+sunxi-nand-image-builder -p 16384 -o 1280 -e 0x40 -s -c 40/1024
+  A boot0 image can be generated with
+sunxi-nand-image-builder -p 16384 -o 1280 -e 0x40 -s -b -u 4096 -c 
64/1024
+make[2]: *** [spl/sunxi-spl-with-ecc.bin] Error 255
+make[1]: *** [spl/u-boot-spl] Error 2

I've dropped this patch.


Regards,

Hans




Regards,

Hans




---
 Makefile |  3 +++
 scripts/Makefile.spl | 12 
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 37cbcb28f75e..12a248e297b5 100644
--- a/Makefile
+++ b/Makefile
@@ -1345,6 +1345,9 @@ spl/u-boot-spl: tools prepare \
 spl/sunxi-spl.bin: spl/u-boot-spl
 @:

+spl/sunxi-spl-with-ecc.bin: spl/sunxi-spl.bin
+@:
+
 spl/u-boot-spl.sfp: spl/u-boot-spl
 @:

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index e0b0117dc9b6..b41b4e427cc5 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -168,6 +168,7 @@ endif

 ifdef CONFIG_ARCH_SUNXI
 ALL-y+= $(obj)/sunxi-spl.bin
+ALL-y+= $(obj)/sunxi-spl-with-ecc.bin
 endif

 ifeq ($(CONFIG_SYS_SOC),"at91")
@@ -276,6 +277,17 @@ cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
 $(call if_changed,mksunxiboot)

+quiet_cmd_sunxi_spl_image_builder = SUNXI_SPL_IMAGE_BUILDER $@
+cmd_sunxi_spl_image_builder = $(objtree)/tools/sunxi-spl-image-builder \
+-c 
$(CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH)/$(CONFIG_NAND_SUNXI_SPL_ECC_SIZE) \
+-p $(CONFIG_SYS_NAND_PAGE_SIZE) \
+-o $(CONFIG_SYS_NAND_OOBSIZE) \
+-u $(CONFIG_NAND_SUNXI_SPL_USABLE_PAGE_SIZE) \
+-e $(CONFIG_SYS_NAND_BLOCK_SIZE) \
+-s -b $< $@
+$(obj)/sunxi-spl-with-ecc.bin: $(obj)/sunxi-spl.bin
+$(call if_changed,sunxi_spl_image_builder)
+
 # Rule to link u-boot-spl
 # May be overridden by arch/$(ARCH)/config.mk
 quiet_cmd_u-boot-spl ?= LD  $@


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

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Hans de Goede]

Hi,

On 14-11-16 12:18, Hans de Goede wrote:

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

This program generates raw SPL images that can be flashed on the NAND with
the ECC and randomizer properly set up.

Signed-off-by: Maxime Ripard 


Looks good to me:

Reviewed-by: Hans de Goede 


Note this causes a cpu_to_be32 redefine compiler warning
I've fixed this up locally.

Regards,

Hans




Regards,

Hans




---
 tools/.gitignore|1 +-
 tools/Makefile  |1 +-
 tools/sunxi-spl-image-builder.c | 1113 -
 3 files changed, 1115 insertions(+), 0 deletions(-)
 create mode 100644 tools/sunxi-spl-image-builder.c

diff --git a/tools/.gitignore b/tools/.gitignore
index cb1e722d4575..16574467544c 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -15,6 +15,7 @@
 /mkexynosspl
 /mxsboot
 /mksunxiboot
+/sunxi-spl-image-builder
 /ncb
 /proftool
 /relocate-rela
diff --git a/tools/Makefile b/tools/Makefile
index 400588cf0f5c..dfeeb23484ce 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -171,6 +171,7 @@ hostprogs-$(CONFIG_MX28) += mxsboot
 HOSTCFLAGS_mxsboot.o := -pedantic

 hostprogs-$(CONFIG_ARCH_SUNXI) += mksunxiboot
+hostprogs-$(CONFIG_ARCH_SUNXI) += sunxi-spl-image-builder

 hostprogs-$(CONFIG_NETCONSOLE) += ncb
 hostprogs-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1
diff --git a/tools/sunxi-spl-image-builder.c b/tools/sunxi-spl-image-builder.c
new file mode 100644
index ..0f915eb2bdf5
--- /dev/null
+++ b/tools/sunxi-spl-image-builder.c
@@ -0,0 +1,1113 @@
+/*
+ * Generic binary BCH encoding/decoding library
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * For the BCH implementation:
+ *
+ * Copyright © 2011 Parrot S.A.
+ *
+ * Author: Ivan Djelic 
+ *
+ * See also:
+ * http://lxr.free-electrons.com/source/lib/bch.c
+ *
+ * For the randomizer and image builder implementation:
+ *
+ * Copyright © 2016 NextThing Co.
+ * Copyright © 2016 Free Electrons
+ *
+ * Author: Boris Brezillon 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_BCH_CONST_PARAMS)
+#define GF_M(_p)   (CONFIG_BCH_CONST_M)
+#define GF_T(_p)   (CONFIG_BCH_CONST_T)
+#define GF_N(_p)   ((1 << (CONFIG_BCH_CONST_M))-1)
+#else
+#define GF_M(_p)   ((_p)->m)
+#define GF_T(_p)   ((_p)->t)
+#define GF_N(_p)   ((_p)->n)
+#endif
+
+#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+
+#define BCH_ECC_WORDS(_p)  DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 32)
+#define BCH_ECC_BYTES(_p)  DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 8)
+
+#ifndef dbg
+#define dbg(_fmt, args...) do {} while (0)
+#endif
+
+#define cpu_to_be32 htobe32
+#define kfree free
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+#define BCH_PRIMITIVE_POLY0x5803
+
+struct image_info {
+int ecc_strength;
+int ecc_step_size;
+int page_size;
+int oob_size;
+int usable_page_size;
+int eraseblock_size;
+int scramble;
+int boot0;
+off_t offset;
+const char *source;
+const char *dest;
+};
+
+/**
+ * struct bch_control - BCH control structure
+ * @m:  Galois field order
+ * @n:  maximum codeword size in bits (= 2^m-1)
+ * @t:  error correction capability in bits
+ * @ecc_bits:   ecc exact size in bits, i.e. generator polynomial degree 
(<=m*t)
+ * @ecc_bytes:  ecc max size (m*t bits) in bytes
+ * @a_pow_tab:  Galois field GF(2^m) exponentiation lookup table
+ * @a_log_tab:  Galois field GF(2^m) log lookup table
+ * @mod8_tab:   remainder generator polynomial lookup tables
+ * @ecc_buf:ecc parity words buffer
+ * @ecc_buf2:   ecc parity words buffer
+ * @xi_tab: GF(2^m) base for solving degree 2 polynomial roots
+ * @syn:syndrome buffer
+ * @cache:  log-based polynomial representation buffer
+ * @elp:error locator polynomial
+ * @poly_2t:temporary polynomials of degree 2t
+ */
+struct bch_control {
+unsigned intm;
+unsigned intn;
+unsigned intt;
+unsigned intecc_bits;
+unsigned intecc_bytes;
+/* private: */
+uint16_t   *a_pow_tab;
+uint16_t   *a_log_tab;
+uint32_t   

Re: [U-Boot] [PATCH] Do not force master mode on unaffected PHY's

[Hans de Goede]

Hi,

On 08-11-16 17:38, Olliver Schinagl wrote:

The current implementation to force the PHY into master mode is to have a
define which affects all realtek PHY's. This is not needed as the problem
only exists in the RTL8211C chips. Let us thus turn this into a quirk flag
instead.


Series looks good to me:

Reviewed-by: Hans de Goede 

Regards,

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

Re: [U-Boot] [PATCH 00/10] sunxi: Add basic PSCI support to enable SMP on the A80's first cluster

[Chen-Yu Tsai]

Hi,

On Wed, Nov 9, 2016 at 6:38 PM, Hans de Goede  wrote:
> Hi,
>
> On 09-11-16 11:21, Chen-Yu Tsai wrote:
>>
>> Hi everyone,
>>
>> This series adds basic PSCI support for the A80 to enable SMP on the
>> first cluster. This at least allows people to use more than one core.
>> The term "basic" is used because the series does not add support for
>> multi-cluster cache and power management.
>>
>> The PSCI code is based on existing code for all the single cluster
>> SoCs, and the kernel patches for MCPM SMP I did some time ago.
>>
>> Unfortunately only SMP works at this time. The last patch does not
>> actually work. While the system is indeed booted non-secure, tested
>> by trying to write to secure SRAM and the results not sticking, reads
>> from the GIC CPU interface shows that it's still returning the secure
>> copy of registers, and since we use a secure monitor FIQ to do core
>> power down, the FIQ gets passed to the kernel. The patch is included
>> so people with in-depth ARM knowledge could probably help work out
>> what is wrong.
>
>
> Cools stuff, when I find some time I will review and merge
> patches 1-9 to sunxi-next.
>
> First a question though, do you see any chance that merging this might
> get in the way of enabling support for both clusters in the future?
>
> Since the interface between u-boot and the kernel here is well defined
> (and outside our control) I guess in the worst case, we would need to
> revert some bits of this series from u-boot if they turn out to be non
> suitable, right?

So I started digging through why CPU power off is sending FIQs to the
kernel. So it turns out that the GIC base address programmed in the
CPU's CBAR is incorrect, so the GIC is not blocking secure interrupts,
and when the interrupt returns the CPU seems to get switched to secure
mode.

After hard-coding in the correct address, the system no longer boots.
It hangs when it tries to bring up the second core. I'm not sure
what's going on though. Need to add some more trace code.

I might have opened a can of worms...

ChenYu

>
> Regards,
>
> Hans
>
>
>
>
>>
>>
>> Regards
>> ChenYu
>>
>> Chen-Yu Tsai (10):
>>   ARM: PSCI: Set ARMV7_PSCI_NR_CPUS default to 8 for sun9i/A80
>>   sunxi: Add CCI-400 and CPUCFG registers base address for sun9i/A80
>>   sunxi: Add base address of secure SRAM B for sun9i/A80
>>   sunxi: Use secure SRAM B for secure RAM for sun9i/A80
>>   sunxi: Add PRCM register definition for sun9i/A80
>>   sunxi: Add CPUCFG register definitions for sun9i/A80
>>   sunxi: Add support for TZPC on sun9i/A80
>>   sunxi: Add basic PSCI implementation for A80
>>   sunxi: Enable PSCI on sun9i/A80
>>   sunxi: Add PSCI core power off support for A80's first cluster
>>
>>  arch/arm/cpu/armv7/Kconfig |   1 +
>>  arch/arm/cpu/armv7/sunxi/Makefile  |   5 +
>>  arch/arm/cpu/armv7/sunxi/psci-mcpm.c   | 322
>> +
>>  arch/arm/cpu/armv7/sunxi/tzpc.c|   6 +
>>  arch/arm/include/asm/arch-sunxi/cpu_sun9i.h|   5 +
>>  arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h |  51 
>>  arch/arm/include/asm/arch-sunxi/prcm_sun9i.h   |  55 +
>>  arch/arm/include/asm/arch-sunxi/tzpc.h |   4 +
>>  arch/arm/mach-sunxi/board.c|   3 +-
>>  board/sunxi/Kconfig|   4 +
>>  include/configs/sun9i.h|   4 +
>>  11 files changed, 459 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c
>>  create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
>>  create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun9i.h
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/7] sunxi: Add support for the CHIP Pro

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

The CHIP Pro is a SoM that features the GR8 SIP, an AXP209, a BT/WiFi chip
and a 512MiB SLC NAND.

This it's an SLC NAND, it doesn't suffer the same drawbacks than found on
the MLC NANDs, and we can enable it right away.

Signed-off-by: Maxime Ripard 


Patch 3/3 needs a v3 before this can be merged, otherwise this
looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


---
 configs/CHIP_pro_defconfig | 27 +++
 1 file changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 configs/CHIP_pro_defconfig

diff --git a/configs/CHIP_pro_defconfig b/configs/CHIP_pro_defconfig
new file mode 100644
index ..6008f44f485c
--- /dev/null
+++ b/configs/CHIP_pro_defconfig
@@ -0,0 +1,27 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL_I2C_SUPPORT=y
+# CONFIG_SPL_MMC_SUPPORT is not set
+CONFIG_MACH_SUN5I=y
+CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y
+# CONFIG_MMC is not set
+CONFIG_USB0_VBUS_PIN="PB10"
+CONFIG_DEFAULT_DEVICE_TREE="ntc-gr8-chip-pro"
+CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,SYS_NAND_BLOCK_SIZE=0x4,SYS_NAND_PAGE_SIZE=4096,SYS_NAND_OOBSIZE=256,ENV_IS_IN_NAND"
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_DFU=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_DFU_RAM=y
+CONFIG_AXP_ALDO3_VOLT=3300
+CONFIG_AXP_ALDO4_VOLT=3300
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Allwinner Technology"
+CONFIG_G_DNL_VENDOR_NUM=0x1f3a
+CONFIG_G_DNL_PRODUCT_NUM=0x1010
+CONFIG_NAND_SUNXI=y
+CONFIG_SPL_NAND_SUPPORT=y
+CONFIG_MTD_UBI=y


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

Re: [U-Boot] [PATCH 5/7] nand: sunxi: Add options for the SPL NAND configuration

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

The SPL image needs to be built with a different ECC configuration than the
U-Boot binary.

Add Kconfig options with defaults to provide a value that should work for
anyone, but is still configurable if needs be.

Signed-off-by: Maxime Ripard 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans




---
 drivers/mtd/nand/Kconfig | 16 
 1 file changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index df154bfd32b9..a60abb625ee5 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -73,6 +73,22 @@ config NAND_SUNXI
The SPL driver only supports reading from the NAND using DMA
transfers.

+if NAND_SUNXI
+
+config NAND_SUNXI_SPL_ECC_STRENGTH
+   int "Allwinner NAND SPL ECC Strength"
+   default 64
+
+config NAND_SUNXI_SPL_ECC_SIZE
+   int "Allwinner NAND SPL ECC Step Size"
+   default 1024
+
+config NAND_SUNXI_SPL_USABLE_PAGE_SIZE
+   int "Allwinner NAND SPL Usable Page Size"
+   default 1024
+
+endif
+
 config NAND_ARASAN
bool "Configure Arasan Nand"
help


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

Re: [U-Boot] [PATCH 6/7] scripts: sunxi: Build an raw SPL image

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

Introduce a new sunxi-spl-with-ecc.bin image with already the right header,
ECC, randomizer and padding for the BROM to be able to read it.

It needs to be flashed using a raw access to the NAND so that the
controller doesn't change a thing to it, since we already have all the
right parameters.

Signed-off-by: Maxime Ripard 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans




---
 Makefile |  3 +++
 scripts/Makefile.spl | 12 
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 37cbcb28f75e..12a248e297b5 100644
--- a/Makefile
+++ b/Makefile
@@ -1345,6 +1345,9 @@ spl/u-boot-spl: tools prepare \
 spl/sunxi-spl.bin: spl/u-boot-spl
@:

+spl/sunxi-spl-with-ecc.bin: spl/sunxi-spl.bin
+   @:
+
 spl/u-boot-spl.sfp: spl/u-boot-spl
@:

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index e0b0117dc9b6..b41b4e427cc5 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -168,6 +168,7 @@ endif

 ifdef CONFIG_ARCH_SUNXI
 ALL-y  += $(obj)/sunxi-spl.bin
+ALL-y  += $(obj)/sunxi-spl-with-ecc.bin
 endif

 ifeq ($(CONFIG_SYS_SOC),"at91")
@@ -276,6 +277,17 @@ cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mksunxiboot)

+quiet_cmd_sunxi_spl_image_builder = SUNXI_SPL_IMAGE_BUILDER $@
+cmd_sunxi_spl_image_builder = $(objtree)/tools/sunxi-spl-image-builder \
+   -c 
$(CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH)/$(CONFIG_NAND_SUNXI_SPL_ECC_SIZE) \
+   -p $(CONFIG_SYS_NAND_PAGE_SIZE) \
+   -o $(CONFIG_SYS_NAND_OOBSIZE) \
+   -u $(CONFIG_NAND_SUNXI_SPL_USABLE_PAGE_SIZE) \
+   -e $(CONFIG_SYS_NAND_BLOCK_SIZE) \
+   -s -b $< $@
+$(obj)/sunxi-spl-with-ecc.bin: $(obj)/sunxi-spl.bin
+   $(call if_changed,sunxi_spl_image_builder)
+
 # Rule to link u-boot-spl
 # May be overridden by arch/$(ARCH)/config.mk
 quiet_cmd_u-boot-spl ?= LD  $@


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

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

This program generates raw SPL images that can be flashed on the NAND with
the ECC and randomizer properly set up.

Signed-off-by: Maxime Ripard 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans




---
 tools/.gitignore|1 +-
 tools/Makefile  |1 +-
 tools/sunxi-spl-image-builder.c | 1113 -
 3 files changed, 1115 insertions(+), 0 deletions(-)
 create mode 100644 tools/sunxi-spl-image-builder.c

diff --git a/tools/.gitignore b/tools/.gitignore
index cb1e722d4575..16574467544c 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -15,6 +15,7 @@
 /mkexynosspl
 /mxsboot
 /mksunxiboot
+/sunxi-spl-image-builder
 /ncb
 /proftool
 /relocate-rela
diff --git a/tools/Makefile b/tools/Makefile
index 400588cf0f5c..dfeeb23484ce 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -171,6 +171,7 @@ hostprogs-$(CONFIG_MX28) += mxsboot
 HOSTCFLAGS_mxsboot.o := -pedantic

 hostprogs-$(CONFIG_ARCH_SUNXI) += mksunxiboot
+hostprogs-$(CONFIG_ARCH_SUNXI) += sunxi-spl-image-builder

 hostprogs-$(CONFIG_NETCONSOLE) += ncb
 hostprogs-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1
diff --git a/tools/sunxi-spl-image-builder.c b/tools/sunxi-spl-image-builder.c
new file mode 100644
index ..0f915eb2bdf5
--- /dev/null
+++ b/tools/sunxi-spl-image-builder.c
@@ -0,0 +1,1113 @@
+/*
+ * Generic binary BCH encoding/decoding library
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * For the BCH implementation:
+ *
+ * Copyright © 2011 Parrot S.A.
+ *
+ * Author: Ivan Djelic 
+ *
+ * See also:
+ * http://lxr.free-electrons.com/source/lib/bch.c
+ *
+ * For the randomizer and image builder implementation:
+ *
+ * Copyright © 2016 NextThing Co.
+ * Copyright © 2016 Free Electrons
+ *
+ * Author: Boris Brezillon 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_BCH_CONST_PARAMS)
+#define GF_M(_p)   (CONFIG_BCH_CONST_M)
+#define GF_T(_p)   (CONFIG_BCH_CONST_T)
+#define GF_N(_p)   ((1 << (CONFIG_BCH_CONST_M))-1)
+#else
+#define GF_M(_p)   ((_p)->m)
+#define GF_T(_p)   ((_p)->t)
+#define GF_N(_p)   ((_p)->n)
+#endif
+
+#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+
+#define BCH_ECC_WORDS(_p)  DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 32)
+#define BCH_ECC_BYTES(_p)  DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 8)
+
+#ifndef dbg
+#define dbg(_fmt, args...) do {} while (0)
+#endif
+
+#define cpu_to_be32 htobe32
+#define kfree free
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+#define BCH_PRIMITIVE_POLY 0x5803
+
+struct image_info {
+   int ecc_strength;
+   int ecc_step_size;
+   int page_size;
+   int oob_size;
+   int usable_page_size;
+   int eraseblock_size;
+   int scramble;
+   int boot0;
+   off_t offset;
+   const char *source;
+   const char *dest;
+};
+
+/**
+ * struct bch_control - BCH control structure
+ * @m:  Galois field order
+ * @n:  maximum codeword size in bits (= 2^m-1)
+ * @t:  error correction capability in bits
+ * @ecc_bits:   ecc exact size in bits, i.e. generator polynomial degree 
(<=m*t)
+ * @ecc_bytes:  ecc max size (m*t bits) in bytes
+ * @a_pow_tab:  Galois field GF(2^m) exponentiation lookup table
+ * @a_log_tab:  Galois field GF(2^m) log lookup table
+ * @mod8_tab:   remainder generator polynomial lookup tables
+ * @ecc_buf:ecc parity words buffer
+ * @ecc_buf2:   ecc parity words buffer
+ * @xi_tab: GF(2^m) base for solving degree 2 polynomial roots
+ * @syn:syndrome buffer
+ * @cache:  log-based polynomial representation buffer
+ * @elp:error locator polynomial
+ * @poly_2t:temporary polynomials of degree 2t
+ */
+struct bch_control {
+   unsigned intm;
+   unsigned intn;
+   unsigned intt;
+   unsigned intecc_bits;
+   unsigned intecc_bytes;
+/* private: */
+   uint16_t   *a_pow_tab;
+   uint16_t   *a_log_tab;
+   uint32_t   *mod8_tab;
+   uint32_t   *ecc_buf;
+   uint32_t   *ecc_buf2;
+   unsigned int   

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

From: Hans de Goede 

Enable the NAND and UBI support in the configuration header so that we can
(finally) use it.

Signed-off-by: Hans de Goede 
Signed-off-by: Maxime Ripard 
---
 include/configs/sunxi-common.h | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 8363414828fa..1733767ba53b 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -129,9 +129,23 @@
 #define CONFIG_SERIAL_TAG

 #ifdef CONFIG_NAND_SUNXI
+#define CONFIG_SYS_NAND_U_BOOT_OFFS(8 << 20) /* 8 MiB */


As Boris already said, please put this in Kconfig.


 #define CONFIG_SYS_NAND_MAX_ECCPOS 1664
 #define CONFIG_SYS_NAND_ONFI_DETECTION
 #define CONFIG_SYS_MAX_NAND_DEVICE 8
+
+/* Requirements for UBI */
+#define CONFIG_RBTREE
+#define CONFIG_LZO
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+#define CONFIG_MTD_DEVICE
+
+#define CONFIG_MTD_PARTITIONS
+
+#define CONFIG_CMD_NAND
+#define CONFIG_CMD_NAND_TRIMFFS
 #endif

 #ifdef CONFIG_SPL_SPI_SUNXI
@@ -143,7 +157,14 @@
 #define CONFIG_GENERIC_MMC
 #define CONFIG_MMC_SUNXI
 #define CONFIG_MMC_SUNXI_SLOT  0
-#define CONFIG_ENV_IS_IN_MMC
+#endif
+
+#if defined(CONFIG_ENV_IS_IN_NAND)
+#define CONFIG_ENV_OFFSET  0xc0
+#define CONFIG_ENV_SIZE0x40
+#elif defined(CONFIG_ENV_IS_IN_MMC)
+#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) 
KiB */
+#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB 
*/
 #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
controller */
 #endif



I would greatly prefer putting the env in an UBI partition,
I thought that we had agreed on doing that ?

Regards,

Hans




@@ -175,9 +196,6 @@

 #define CONFIG_SYS_MONITOR_LEN (768 << 10)   /* 768 KiB */

-#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) KiB */
-#define CONFIG_ENV_SIZE(128 << 10)   /* 128 KiB */
-
 #define CONFIG_FAT_WRITE   /* enable write access */

 #define CONFIG_SPL_FRAMEWORK


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

Re: [U-Boot] [PATCH 2/7] mtd: nand: add support for the TC58NVG2S0H chip

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

From: Boris Brezillon 

Add the description of the Toshiba TC58NVG2S0H SLC nand to the nand_ids
table so we can use the NAND ECC infos and the ONFI timings.

Signed-off-by: Boris Brezillon 
Signed-off-by: Maxime Ripard 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans




---
 drivers/mtd/nand/nand_ids.c | 3 +++
 1 file changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index ce0a14e28abb..d36f9006c99d 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -46,6 +46,9 @@ struct nand_flash_dev nand_flash_ids[] = {
{"TC58NVG2S0F 4G 3.3V 8-bit",
{ .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
  SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },
+   {"TC58NVG2S0H 4G 3.3V 8-bit",
+   { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x16, 0x08, 0x00} },
+ SZ_4K, SZ_512, SZ_256K, 0, 8, 256, NAND_ECC_INFO(8, SZ_512) },
{"TC58NVG3S0F 8G 3.3V 8-bit",
{ .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
  SZ_4K, SZ_1K, SZ_256K, 0, 8, 232, NAND_ECC_INFO(4, SZ_512) },


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

Re: [U-Boot] [PATCH 1/7] sunxi: Sync GR8 DTS and AXP209 with the kernel

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

Those DT will be part of 4.10, sync them so we can have our own config.

Signed-off-by: Maxime Ripard 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 arch/arm/dts/Makefile |1 +-
 arch/arm/dts/axp209.dtsi  |6 +-
 arch/arm/dts/ntc-gr8-chip-pro.dts |  266 +++-
 arch/arm/dts/ntc-gr8.dtsi | 1132 ++-
 4 files changed, 1405 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/dts/ntc-gr8-chip-pro.dts
 create mode 100644 arch/arm/dts/ntc-gr8.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 836a8c4d1ee2..932dbe07cf14 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -180,6 +180,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-pcduino2.dtb \
sun4i-a10-pov-protab2-ips9.dtb
 dtb-$(CONFIG_MACH_SUN5I) += \
+   ntc-gr8-chip-pro.dtb \
sun5i-a10s-auxtek-t003.dtb \
sun5i-a10s-auxtek-t004.dtb \
sun5i-a10s-mk802.dtb \
diff --git a/arch/arm/dts/axp209.dtsi b/arch/arm/dts/axp209.dtsi
index afbe89c01df5..675bb0f30825 100644
--- a/arch/arm/dts/axp209.dtsi
+++ b/arch/arm/dts/axp209.dtsi
@@ -53,6 +53,12 @@
interrupt-controller;
#interrupt-cells = <1>;

+   axp_gpio: gpio {
+   compatible = "x-powers,axp209-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <1500>;
diff --git a/arch/arm/dts/ntc-gr8-chip-pro.dts 
b/arch/arm/dts/ntc-gr8-chip-pro.dts
new file mode 100644
index ..c4be912df481
--- /dev/null
+++ b/arch/arm/dts/ntc-gr8-chip-pro.dts
@@ -0,0 +1,266 @@
+/*
+ * Copyright 2016 Free Electrons
+ * Copyright 2016 NextThing Co
+ *
+ * Maxime Ripard 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "ntc-gr8.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "NextThing C.H.I.P. Pro";
+   compatible = "nextthing,chip-pro", "nextthing,gr8";
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   status {
+   label = "chip-pro:white:status";
+   gpios = <_gpio 2 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
+   mmc0_pwrseq: mmc0_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <_reg_on_pin_chip_pro>;
+   reset-gpios = < 1 10 GPIO_ACTIVE_LOW>; /* PB10 */
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status 

Re: [U-Boot] [PATCH RESEND 0/9] sunxi: chip: Enable the DIP auto-detection

[Hans de Goede]

Hi,

On 08-11-16 11:19, Maxime Ripard wrote:

The NextThing's C.H.I.P. can have expansion boards called DIPs. Those DIPs
are connected through the external headers, and comes with an
identification mechanism based on 1-Wire EEPROMs.

That auto-detection works great, because 1-Wire allows the enumeration, and
the EEPROMs are guaranteed to have different addresses, which allows us to
stack as many DIPs as possible, without any constraints.

Since those DIPs can be close to anything, ranging from a simple PWM-based
buzzer to a full featured device such as the PocketCHIP (which comes with a
touchscreen, a keyboard, a battery, etc), some adjustments might be needed
in U-Boot to be able to present something that just works to the user.

In particular, we need to:
  - Apply an overlay if the device is something that should be dealt with
early in the boot process (display, storage device)
  - Adjust the U-Boot environment if the DIP has a display to change the
default video output
  - Adjust the kernel command line in previous case for Linux to have the
same default

In order to achieve that, we introduced some logic optionally hooked into
the sunxi board, two new uclasses for 1-Wire and EEPROMs, and a bunch of
new environment variables:
  - dip-auto-video to control the automatic video set up (default to yes)
  - dip_overlay_cmd that is a script to load the overlay $dip_overlay_name
to $dip_addr_r, from whatever place it was stored in, and later apply
it.
  - kernelarg_video to host the default kernel output in the kernel
command line

I think the biggest drawback at the moment is that we maintain a list of
DIPs and the actions needed directly into the C code, which will make it
quite hard to customise for end users and tedious to maintain in the long
term. I couldn't really get my head around a better solution, so feel free
to suggest alternative approaches.

Let me know what you think,


The sunxi specific bits look fine to me. I will leave reviewing of the
uclass bits to Simon.

Regards,

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

Re: [U-Boot] [PATCH 4/4] sunxi: sina33: Enable the LCD

[Jaehoon Chung]

Hi Hans,

On 11/14/2016 03:51 AM, Hans de Goede wrote:
> Hi,
> 
> On 04-11-16 16:18, Maxime Ripard wrote:
>> The SinA33 comes with an optional 7" display. Enable it in the
>> configuration.
>>
>> Signed-off-by: Maxime Ripard 
> 
> LGTM:
> 
> Reviewed-by: Hans de Goede 

This patch is not on MMC side. But i picked with other patches.
If there is other issue, let me know, plz.

Best Regards,
Jaehoon Chung

> 
> Regards,
> 
> Hans
> 
> 
> 
>> ---
>>  configs/Sinlinx_SinA33_defconfig | 4 
>>  1 file changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/configs/Sinlinx_SinA33_defconfig 
>> b/configs/Sinlinx_SinA33_defconfig
>> index f4719db2d501..26b119a9b92f 100644
>> --- a/configs/Sinlinx_SinA33_defconfig
>> +++ b/configs/Sinlinx_SinA33_defconfig
>> @@ -6,6 +6,10 @@ CONFIG_DRAM_ZQ=15291
>>  CONFIG_MMC0_CD_PIN="PB4"
>>  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>>  CONFIG_USB0_ID_DET="PH8"
>> +CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:66000,le:90,ri:160,up:3,lo:127,hs:70,vs:20,sync:3,vmode:0"
>> +CONFIG_VIDEO_LCD_DCLK_PHASE=0
>> +CONFIG_VIDEO_LCD_BL_EN="PH6"
>> +CONFIG_VIDEO_LCD_BL_PWM="PH0"
>>  CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
>>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>>  CONFIG_SPL=y
>>
> 
> 
> 

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

Re: [U-Boot] [PATCH 1/4] mmc: Retry the switch command

[Jaehoon Chung]

On 11/14/2016 06:56 PM, Hans de Goede wrote:
> Hi,
> 
> On 14-11-16 01:34, Jaehoon Chung wrote:
>> On 11/14/2016 07:50 AM, Tom Rini wrote:
>>> On Sun, Nov 13, 2016 at 07:50:53PM +0100, Hans de Goede wrote:
 Hi,

 On 04-11-16 16:18, Maxime Ripard wrote:
> Some eMMC will fail at the first switch, but would succeed in a subsequent
> one.
>
> Make sure we try several times to cover those cases. The number of retries
> (and the behaviour) is currently what is being used in Linux.
>
> Signed-off-by: Maxime Ripard 

 LGTM:

 Reviewed-by: Hans de Goede 
>>>
>>> Reviewed-by: Tom Rini 
>>>
 Pantelis or Tom, can you pick this up please ?
>>>
>>> Want to just pick it up with the rest of the series in the sunxi tree?
>>
>> Sorry for late..If you are ok, i will pick these on today.
> 
> Go ahead and pick these up please.

Ok. I will pick these series.

Thanks!

Best Regards,
Jaehoon Chung

> 
>> If you already picked this..let me know, plz.
> 
> Regards,
> 
> Hans
> 
> 
> 

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

Re: [U-Boot] [PATCH 4/4] rk3036: enable the vbus regulator when borad_init

[Kever Yang]

Hi Simon,

On 11/12/2016 12:17 AM, Simon Glass wrote:

Hi Kever,

On 8 November 2016 at 03:13, Kever Yang  wrote:

enable the vbus for usb host in board_init().

Note 'borad_init' typo in subject.


Will fix in next version.



Signed-off-by: Kever Yang 
---

  arch/arm/mach-rockchip/rk3036-board.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-rockchip/rk3036-board.c 
b/arch/arm/mach-rockchip/rk3036-board.c
index bf2b268..90d3d33 100644
--- a/arch/arm/mach-rockchip/rk3036-board.c
+++ b/arch/arm/mach-rockchip/rk3036-board.c
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 

  DECLARE_GLOBAL_DATA_PTR;

@@ -57,7 +58,26 @@ int board_late_init(void)

  int board_init(void)
  {
+   int ret;
+   struct udevice *regulator;
+
+   ret = regulator_get_by_platname("vcc5v0_host", );

Can this be done in the USB driver? Then you might be able to use
device_get_supply_regulator().


In dwc2 controller, there do have a bit for host power to control a signal
named HOST_DRV_VBUS and init at dwc_otg_core_host_init(), but we do not
using that controller signal, and using a GPIO instead, which may be 
different

in different board, so we usually enable it in board file.

Let me have a try if we can move it to USB driver.



In fact it looks like board_usb_init() should move into a driver.


We are not using board_usb_init() for usb host now, this function is 
only used

for usb gadget/udc.

Thanks,
- Kever




+   if (ret) {
+   printf("%s vcc5v0_host init fail! ret %d\n", __func__, ret);
+   goto out;
+   }
+
+   ret = regulator_set_enable(regulator, true);
+   if (ret) {
+   printf("%s vcc5v0-host enable fail!\n", __func__);
+   goto out;
+   }
+
 return 0;
+out:
+   printf("%s board ini error %x\n", __func__, ret);
+
+   return ret;
  }

  int dram_init(void)
--
1.9.1







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

Re: [U-Boot] [PATCH 1/4] mmc: Retry the switch command

[Hans de Goede]

Hi,

On 14-11-16 01:34, Jaehoon Chung wrote:

On 11/14/2016 07:50 AM, Tom Rini wrote:

On Sun, Nov 13, 2016 at 07:50:53PM +0100, Hans de Goede wrote:

Hi,

On 04-11-16 16:18, Maxime Ripard wrote:

Some eMMC will fail at the first switch, but would succeed in a subsequent
one.

Make sure we try several times to cover those cases. The number of retries
(and the behaviour) is currently what is being used in Linux.

Signed-off-by: Maxime Ripard 


LGTM:

Reviewed-by: Hans de Goede 


Reviewed-by: Tom Rini 


Pantelis or Tom, can you pick this up please ?


Want to just pick it up with the rest of the series in the sunxi tree?


Sorry for late..If you are ok, i will pick these on today.


Go ahead and pick these up please.


If you already picked this..let me know, plz.


Regards,

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

Re: [U-Boot] [U-Boot, v2, 4/5] bcm2835 video: Map frame buffer as 32bpp

[Alexander Graf]

On 14/11/2016 10:23, Alexander Graf wrote:

To enable working efifb support, let's map the frame buffer as 32bpp
instead of 16bpp.

Signed-off-by: Alexander Graf 


Thanks, applied to efi-next

Alex



Sorry, that was script magic going wild. Bcm2835 patches obviously have 
to go via Stephen's tree :)



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

Re: [U-Boot] [U-Boot, v2, 4/5] bcm2835 video: Map frame buffer as 32bpp

[Alexander Graf]

> To enable working efifb support, let's map the frame buffer as 32bpp
> instead of 16bpp.
> 
> Signed-off-by: Alexander Graf 

Thanks, applied to efi-next

Alex

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

Re: [U-Boot] [U-Boot, v2, 5/5] bcm2835: Reserve the spin table in efi memory map

[Alexander Graf]

> Firmware provides a spin table on the raspberry pi. This table shouldn't
> get overwritten by payloads, so we need to mark it as reserved.
> 
> Signed-off-by: Alexander Graf 

Thanks, applied to efi-next

Alex

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

Re: [U-Boot] [U-Boot, v2, 2/5] ARM: bcm283x: Implement EFI RTS reset_system

[Alexander Graf]

> The rpi has a pretty simple way of resetting the whole system. All it takes
> is to poke a few registers at a well defined location in MMIO space.
> 
> This patch adds support for the EFI loader implementation to allow an OS to
> reset and power off the system when we're outside of boot time.
> 
> Signed-off-by: Alexander Graf 

Thanks, applied to efi-next

Alex

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

[U-Boot] [PATCH] drivers: net: keystone_net: add rgmii link type support when parsing dt

[Mugunthan V N]

Add support to detect RGMII link interface from link-interface
device tree entry. Also rename the existing link type enums so
that it provides meaning full interface like SGMII.

Signed-off-by: Mugunthan V N 
---

Without this support there is a crash in K2G EVM tftp boot [1].
Verified this with tftp download on K2G EVM [2]

[1] - http://pastebin.ubuntu.com/23474751/
[2] - http://pastebin.ubuntu.com/23474748/

---
 drivers/net/keystone_net.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index f88d83e727..a5120e01ad 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -56,13 +56,16 @@ struct rx_buff_desc net_rx_buffs = {
 #ifdef CONFIG_DM_ETH
 
 enum link_type {
-   LINK_TYPE_MAC_TO_MAC_AUTO = 0,
-   LINK_TYPE_MAC_TO_PHY_MODE = 1,
-   LINK_TYPE_MAC_TO_MAC_FORCED_MODE = 2,
-   LINK_TYPE_MAC_TO_FIBRE_MODE = 3,
-   LINK_TYPE_MAC_TO_PHY_NO_MDIO_MODE = 4,
-   LINK_TYPE_10G_MAC_TO_PHY_MODE = 10,
-   LINK_TYPE_10G_MAC_TO_MAC_FORCED_MODE = 11,
+   LINK_TYPE_SGMII_MAC_TO_MAC_AUTO = 0,
+   LINK_TYPE_SGMII_MAC_TO_PHY_MODE = 1,
+   LINK_TYPE_SGMII_MAC_TO_MAC_FORCED_MODE  = 2,
+   LINK_TYPE_SGMII_MAC_TO_FIBRE_MODE   = 3,
+   LINK_TYPE_SGMII_MAC_TO_PHY_NO_MDIO_MODE = 4,
+   LINK_TYPE_RGMII_LINK_MAC_PHY= 5,
+   LINK_TYPE_RGMII_LINK_MAC_MAC_FORCED = 6,
+   LINK_TYPE_RGMII_LINK_MAC_PHY_NO_MDIO= 7,
+   LINK_TYPE_10G_MAC_TO_PHY_MODE   = 10,
+   LINK_TYPE_10G_MAC_TO_MAC_FORCED_MODE= 11,
 };
 
 #define mac_hi(mac) (((mac)[0] << 0) | ((mac)[1] << 8) |\
@@ -1077,11 +1080,15 @@ static int ks2_eth_parse_slave_interface(int netcp, int 
slave,
priv->mdio_base = (void *)fdtdec_get_addr(fdt, mdio, "reg");
}
 
-   if (priv->link_type == LINK_TYPE_MAC_TO_PHY_MODE) {
+   if (priv->link_type == LINK_TYPE_SGMII_MAC_TO_PHY_MODE) {
priv->phy_if = PHY_INTERFACE_MODE_SGMII;
pdata->phy_interface = priv->phy_if;
priv->sgmii_link_type = SGMII_LINK_MAC_PHY;
priv->has_mdio = true;
+   } else if (priv->link_type == LINK_TYPE_RGMII_LINK_MAC_PHY) {
+   priv->phy_if = PHY_INTERFACE_MODE_RGMII;
+   pdata->phy_interface = priv->phy_if;
+   priv->has_mdio = true;
}
 
return 0;
-- 
2.11.0.rc0.7.gbe5a750

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

Re: [U-Boot] [PATCHv2 09/15] pci: layerscape: add pci driver based on DM

[Z.Q. Hou]

Hi Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2016年11月12日 0:18
> To: Z.Q. Hou 
> Cc: U-Boot Mailing List ; Albert ARIBAUD
> ; Prabhakar Kushwaha
> ; Huan Wang-B18965
> ; Sumit Garg ; Ruchika
> Gupta ; Saksham Jain
> ; york sun ; M.H. Lian
> ; Bin Meng ; Mingkai Hu
> 
> Subject: Re: [PATCHv2 09/15] pci: layerscape: add pci driver based on DM
> 
> On 10 November 2016 at 03:58, Zhiqiang Hou 
> wrote:
> > From: Minghuan Lian 
> >
> > There are more than five kinds of Layerscape SoCs. unfortunately, PCIe
> > controller of each SoC is a little bit different. In order to avoid
> > too many macro definitions, the patch addes a new implementation of
> > PCIe driver based on DM. PCIe dts node is used to describe the
> > difference.
> >
> > Signed-off-by: Minghuan Lian 
> > Signed-off-by: Hou Zhiqiang 
> > ---
> > V2:
> >  - Rebased the driver against the latest code.
> >
> >  drivers/pci/Kconfig   |   8 +
> >  drivers/pci/pcie_layerscape.c | 761
> > ++
> >  2 files changed, 769 insertions(+)
> 
> Reviewed-by: Simon Glass 
> 
> So far as I understand it
> 

Thanks for your review!

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

Re: [U-Boot] [PATCH v7 0/5] net: fec_mxc: Convert to DM

[Stefano Babic]

Hi Jagan,

On 19/10/2016 13:23, Jagan Teki wrote:
> From: Jagan Teki 
> 
> This series convert fec_mxc to DM and tested both dm and
> non-dm code and it is on top of [1] with u-boot-imx/master
> branch.
> 
> Changes for v7:
> - Remove fec_set_dev_name in dm probe
> 
> Changes for v6:
> - Add Acked-by tags in commit message
> 
> Changes for v5:
> - Add stub fec calls to minimize the #ifdef's
> - Use same func names on eth_ops
> - Remove reset_gpio in fec_mxc.h
> - Add new patches, for cleanup driver
> 
> Changes for v4:
> - rebase to u-boot-imx/master
> 
> Changes for v3:
> - Add ARM: dts: imx6qdl-icore: Add FEC support
> - icorem6: Use CONFIG_DM_ETH support
> 
> Changes for v2:
> - Add TODO for implementing the enet reset code
> 
> [1] [PATCH v7 00/21] imx6: Add Engicam i.CoreM6 QDL support
> 
> Jagan Teki (5):
>   net: fec_mxc: Remove unneeded eth_device arg from fec_get_hwaddr
>   net: fec_mxc: Convert into driver model
>   net: fec_mxc: Driver cleanups
>   ARM: dts: imx6qdl-icore: Add FEC support
>   icorem6: Use CONFIG_DM_ETH support
> 
>  arch/arm/cpu/armv7/mx6/Kconfig   |   1 +
>  arch/arm/dts/imx6qdl-icore.dtsi  |  24 ++
>  board/engicam/icorem6/icorem6.c  |  71 -
>  configs/imx6qdl_icore_mmc_defconfig  |   1 -
>  configs/imx6qdl_icore_nand_defconfig |   1 -
>  drivers/net/fec_mxc.c| 516 
> +++
>  drivers/net/fec_mxc.h|  31 +--
>  7 files changed, 378 insertions(+), 267 deletions(-)
> 

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] mx35, flea3: updates for the imx35 based flea3 board

[Stefano Babic]

On 17/10/2016 15:51, Heiko Schocher wrote:
> post some small updates for the imx35 based flea3 board
> - add DT support
> - factorize SDRAM setup
> - add GPIO setup
> - adjust default environment
> 
> 
> Heiko Schocher (2):
>   mx35: add DT support to flea3 board
>   mx35: adjust default environment for flea3 board
> 
> Stefano Babic (2):
>   mx35: factorize SDRAM setup in flea3
>   mx35: add GPIO setup on flea3 board
> 
>  board/CarMediaLab/flea3/flea3.c | 124 
> +++-
>  configs/flea3_defconfig |   4 ++
>  include/configs/flea3.h |   9 ++-
>  3 files changed, 42 insertions(+), 95 deletions(-)
> 

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx6ull: update the REFTOP_VBGADJ setting

[Stefano Babic]

On 08/10/2016 11:03, Peng Fan wrote:
> According to design team, we need to set REFTOP_VBGADJ
> in PMU MISC0 according to the REFTOP_TRIM[2:0] fuse. the
> actually table is as below:
> 
>   '000" - set REFTOP_VBGADJ[2:0] to 3'b000
>   '001" - set REFTOP_VBGADJ[2:0] to 3'b001
>   '010" - set REFTOP_VBGADJ[2:0] to 3'b010
>   '011" - set REFTOP_VBGADJ[2:0] to 3'b011
>   '100" - set REFTOP_VBGADJ[2:0] to 3'b100
>   '101" - set REFTOP_VBGADJ[2:0] to 3'b101
>   '110" - set REFTOP_VBGADJ[2:0] to 3'b110
>   '111" - set REFTOP_VBGADJ[2:0] to 3'b111
> 
> Signed-off-by: Peng Fan 
> Signed-off-by: Bai Ping 
> ---


Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx6sx: Disable ENET clock before switching clock parent

[Stefano Babic]

Hi Peng,

On 08/10/2016 10:58, Peng Fan wrote:
> From: "Ye.Li" 
> 
> Need to gate ENET clock when switching to a new clock parent, because
> the mux is not glitchless.
> 
> Signed-off-by: Peng Fan 
> Signed-off-by: Ye.Li 
> Cc: Stefano Babic 
> ---
>  arch/arm/cpu/armv7/mx6/clock.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index ae3143c..96fbd81 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -881,6 +881,11 @@ int enable_fec_anatop_clock(int fec_id, enum enet_freq 
> freq)
>   writel(reg, >pll_enet);
>  
>  #ifdef CONFIG_MX6SX
> + /* Disable enet system clcok before switching clock parent */
> + reg = readl(_ccm->CCGR3);
> + reg &= ~MXC_CCM_CCGR3_ENET_MASK;
> + writel(reg, _ccm->CCGR3);
> +
>   /*
>* Set enet ahb clock to 200MHz
>* pll2_pfd2_396m-> ENET_PODF-> ENET_AHB
> 

Applied to u-boot-imx, -next branch, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot