date:20161230

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

2016-12-30 Thread Lukasz Majewski

Hi Marek,

> On 12/30/2016 10:28 PM, Lukasz Majewski wrote:
> > Hi Marek,
> > 
> >> On 12/29/2016 04:26 PM, Tom Rini wrote:
> >>> On Thu, Dec 29, 2016 at 12:41:06AM +0100, Marek Vasut wrote:
>  On 12/28/2016 09:52 AM, Lukasz Majewski wrote:
> > Hi Marek,
> >
> >> On 12/26/2016 05:36 PM, Lukasz Majewski wrote:
> >>> Hi Marek,
> >>>
>  On 11/29/2016 07:18 PM, Tom Rini wrote:
> > On Tue, Nov 29, 2016 at 11:50:34AM +0100, Marek Vasut wrote:
> >> On 11/29/2016 10:11 AM, Lukasz Majewski wrote:
> >>> Hi Marek,
> >>>
>  On 11/28/2016 10:09 PM, Lukasz Majewski wrote:
> > This define gives the possibility to copy entire image
> > (including header - e.g. u-boot.img) from NOR parallel
> > memory to e.g. SDRAM. The current code only supports
> > loading the raw binary image (the u-boot.bin).
> >
> > The legacy behavior is preserved, since other board
> > don't enabled this option.
> 
>  So, what's the usecase again ? ;-) 
> >>>
> >>> :-)
> >>>
> >>> The use case is to allow u-boot.img being loaded from
> >>> Parallel NOR. The current code only supports u-boot.bin.
> >>
> >> Why is u-boot.bin (or the payload) not sufficient ? Why do
> >> you need the header ?
> >
> > Well, the general use-case and code flow is that we load
> > u-boot.img (or a FIT image) and if all else fails, fall back
> > to assuming a .bin and a known address).
> >
>  And exactly how is that whole image useful in RAM ? Sorry, I
>  still do not see it, usually you just need the executable
>  payload, although even that can be left in flash most of the
>  time.
> >>>
> >>> The use case is that I do want to boot from SD card/eMMC and
> >>> NOR with using u-boot.img.
> >>>
> >>> I would like to avoid situation when for NOR I must use
> >>> u-boot.bin and for eMMC u-boot.img.
> >>>
> >>> Such approach keeps things as simple as possible :-)
> >>
> >> Oh, so it allows you to detect bitrot for the content in SPI
> >> NOR ?
> >
> > I do not use SPI NOR, it is parallel NOR.
> 
>  Sorry, I meant parallel NOR of course.
> 
> >> It's a bit strange we had to use u-boot.bin with SPL there.
> >>
> >
> > This is how the legacy system behaves. It uses (by default)
> > Parallel NOR for booting (with advised/provided NOR memory
> > timings). After doing some measurements, it turned out that for
> > "tunned" u-boot/SPL there would be the best way to copy it to
> > ram and execute it from there (just like eMMC).
> >
> > Hence, I would like to use u-boot.img in both booting scenarios.
> 
>  I think I was mistaken yesterday, I don't think I understand why
>  copying the image including the header into RAM has any benefit
>  compared to copying just the image payload to RAM (and yes, we're
>  getting back to my original question).
> >>>
> >>> Code complexity and forward compatibility?
> >>
> >> This is adding code complexity, but this is not my point.
> >>
> >>> The general case in the SPL
> >>> framework is that we have either a "legacy" image or a FIT image
> >>> and we fall back to "well, just run it!".
> >>
> >> Well, this doesn't answer my question, because if I understand this
> >> patch correctly, it copies the entire legacy image (incl. header)
> >> into RAM instead of copying just the image payload (which we
> >> already do). I don't really understand why we want to do this. Or
> >> do I misunderstand something ?
> > 
> > No, you understood everything correctly. After some thoughts, I
> > think that only payload should be copied.
> 
> But that's what we already do, no ? So what is the point of this
> patch ?

That is why I need to double check it :-)

> 
> > I'll prepare test setup and double check this patch usability by
> > Monday.
> 
> OK
> 

Best regards,
Łukasz Majewski


pgp_2il8_BMcV.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

2016-12-30 Thread Marek Vasut

On 12/30/2016 10:28 PM, Lukasz Majewski wrote:
> Hi Marek,
> 
>> On 12/29/2016 04:26 PM, Tom Rini wrote:
>>> On Thu, Dec 29, 2016 at 12:41:06AM +0100, Marek Vasut wrote:
 On 12/28/2016 09:52 AM, Lukasz Majewski wrote:
> Hi Marek,
>
>> On 12/26/2016 05:36 PM, Lukasz Majewski wrote:
>>> Hi Marek,
>>>
 On 11/29/2016 07:18 PM, Tom Rini wrote:
> On Tue, Nov 29, 2016 at 11:50:34AM +0100, Marek Vasut wrote:
>> On 11/29/2016 10:11 AM, Lukasz Majewski wrote:
>>> Hi Marek,
>>>
 On 11/28/2016 10:09 PM, Lukasz Majewski wrote:
> This define gives the possibility to copy entire image
> (including header - e.g. u-boot.img) from NOR parallel
> memory to e.g. SDRAM. The current code only supports
> loading the raw binary image (the u-boot.bin).
>
> The legacy behavior is preserved, since other board don't
> enabled this option.

 So, what's the usecase again ? ;-) 
>>>
>>> :-)
>>>
>>> The use case is to allow u-boot.img being loaded from
>>> Parallel NOR. The current code only supports u-boot.bin.
>>
>> Why is u-boot.bin (or the payload) not sufficient ? Why do
>> you need the header ?
>
> Well, the general use-case and code flow is that we load
> u-boot.img (or a FIT image) and if all else fails, fall back
> to assuming a .bin and a known address).
>
 And exactly how is that whole image useful in RAM ? Sorry, I
 still do not see it, usually you just need the executable
 payload, although even that can be left in flash most of the
 time.
>>>
>>> The use case is that I do want to boot from SD card/eMMC and NOR
>>> with using u-boot.img.
>>>
>>> I would like to avoid situation when for NOR I must use
>>> u-boot.bin and for eMMC u-boot.img.
>>>
>>> Such approach keeps things as simple as possible :-)
>>
>> Oh, so it allows you to detect bitrot for the content in SPI
>> NOR ?
>
> I do not use SPI NOR, it is parallel NOR.

 Sorry, I meant parallel NOR of course.

>> It's a bit strange we had to use u-boot.bin with SPL there.
>>
>
> This is how the legacy system behaves. It uses (by default)
> Parallel NOR for booting (with advised/provided NOR memory
> timings). After doing some measurements, it turned out that for
> "tunned" u-boot/SPL there would be the best way to copy it to ram
> and execute it from there (just like eMMC).
>
> Hence, I would like to use u-boot.img in both booting scenarios.

 I think I was mistaken yesterday, I don't think I understand why
 copying the image including the header into RAM has any benefit
 compared to copying just the image payload to RAM (and yes, we're
 getting back to my original question).
>>>
>>> Code complexity and forward compatibility?
>>
>> This is adding code complexity, but this is not my point.
>>
>>> The general case in the SPL
>>> framework is that we have either a "legacy" image or a FIT image
>>> and we fall back to "well, just run it!".
>>
>> Well, this doesn't answer my question, because if I understand this
>> patch correctly, it copies the entire legacy image (incl. header) into
>> RAM instead of copying just the image payload (which we already do). I
>> don't really understand why we want to do this. Or do I misunderstand
>> something ?
> 
> No, you understood everything correctly. After some thoughts, I think
> that only payload should be copied.

But that's what we already do, no ? So what is the point of this patch ?

> I'll prepare test setup and double check this patch usability by Monday.

OK

-- 
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] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

2016-12-30 Thread Lukasz Majewski

Hi Marek,

> On 12/29/2016 04:26 PM, Tom Rini wrote:
> > On Thu, Dec 29, 2016 at 12:41:06AM +0100, Marek Vasut wrote:
> >> On 12/28/2016 09:52 AM, Lukasz Majewski wrote:
> >>> Hi Marek,
> >>>
>  On 12/26/2016 05:36 PM, Lukasz Majewski wrote:
> > Hi Marek,
> >
> >> On 11/29/2016 07:18 PM, Tom Rini wrote:
> >>> On Tue, Nov 29, 2016 at 11:50:34AM +0100, Marek Vasut wrote:
>  On 11/29/2016 10:11 AM, Lukasz Majewski wrote:
> > Hi Marek,
> >
> >> On 11/28/2016 10:09 PM, Lukasz Majewski wrote:
> >>> This define gives the possibility to copy entire image
> >>> (including header - e.g. u-boot.img) from NOR parallel
> >>> memory to e.g. SDRAM. The current code only supports
> >>> loading the raw binary image (the u-boot.bin).
> >>>
> >>> The legacy behavior is preserved, since other board don't
> >>> enabled this option.
> >>
> >> So, what's the usecase again ? ;-) 
> >
> > :-)
> >
> > The use case is to allow u-boot.img being loaded from
> > Parallel NOR. The current code only supports u-boot.bin.
> 
>  Why is u-boot.bin (or the payload) not sufficient ? Why do
>  you need the header ?
> >>>
> >>> Well, the general use-case and code flow is that we load
> >>> u-boot.img (or a FIT image) and if all else fails, fall back
> >>> to assuming a .bin and a known address).
> >>>
> >> And exactly how is that whole image useful in RAM ? Sorry, I
> >> still do not see it, usually you just need the executable
> >> payload, although even that can be left in flash most of the
> >> time.
> >
> > The use case is that I do want to boot from SD card/eMMC and NOR
> > with using u-boot.img.
> >
> > I would like to avoid situation when for NOR I must use
> > u-boot.bin and for eMMC u-boot.img.
> >
> > Such approach keeps things as simple as possible :-)
> 
>  Oh, so it allows you to detect bitrot for the content in SPI
>  NOR ?
> >>>
> >>> I do not use SPI NOR, it is parallel NOR.
> >>
> >> Sorry, I meant parallel NOR of course.
> >>
>  It's a bit strange we had to use u-boot.bin with SPL there.
> 
> >>>
> >>> This is how the legacy system behaves. It uses (by default)
> >>> Parallel NOR for booting (with advised/provided NOR memory
> >>> timings). After doing some measurements, it turned out that for
> >>> "tunned" u-boot/SPL there would be the best way to copy it to ram
> >>> and execute it from there (just like eMMC).
> >>>
> >>> Hence, I would like to use u-boot.img in both booting scenarios.
> >>
> >> I think I was mistaken yesterday, I don't think I understand why
> >> copying the image including the header into RAM has any benefit
> >> compared to copying just the image payload to RAM (and yes, we're
> >> getting back to my original question).
> > 
> > Code complexity and forward compatibility?
> 
> This is adding code complexity, but this is not my point.
> 
> > The general case in the SPL
> > framework is that we have either a "legacy" image or a FIT image
> > and we fall back to "well, just run it!".
> 
> Well, this doesn't answer my question, because if I understand this
> patch correctly, it copies the entire legacy image (incl. header) into
> RAM instead of copying just the image payload (which we already do). I
> don't really understand why we want to do this. Or do I misunderstand
> something ?

No, you understood everything correctly. After some thoughts, I think
that only payload should be copied.

I'll prepare test setup and double check this patch usability by Monday.

Best regards,
Łukasz Majewski


pgpzNU3WQwbjO.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix fastboot boot address

2016-12-30 Thread Steve Rae

On Thu, Sep 8, 2016 at 2:07 PM, Tom Rini  wrote:
> On Thu, Sep 08, 2016 at 08:51:57PM +, peter.ch...@data61.csiro.au wrote:
>
>> Fastboot loads an image at CONFIG_FASTBOOT_BUF_ADDR, but currently
>> tells do_bootm() to look for an image at $loadaddr.  This breaks if
>> CONFIG_FASTBOOT_BUF_ADDR is different from the current user-set
>> loadaddr.
>>
>> Instead, tell do_bootm() to pick up the image where it was laoded.
>>
>> Signed-off-by: Peter Chubb 
>
> Reviewed-by: Tom Rini 
>
> --
> Tom
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Acked-by: Steve Rae 

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

Re: [U-Boot] [PATCH v3 10/26] ARM: boot0 hook: remove macro, include whole header file

2016-12-30 Thread Steve Rae

Hi Andre,

On Sun, Dec 18, 2016 at 5:50 PM, Andre Przywara  wrote:
> For prepending some board specific header area to U-Boot images we
> were so far including a header file with a macro definition containing
> the actual header specification.
> This works fine if there are just a few statements and if there is only
> one alternative.
> However adding more complex code quickly gets messy with this approach,
> so let's just drop that intermediate macro and let the #include actually
> insert the code directly.
> This converts the callers and the callees, but doesn't change anything
> at this point.
>
> Signed-off-by: Andre Przywara 
> Reviewed-by: Simon Glass 
> ---
>  arch/arm/cpu/armv8/start.S | 1 -
>  arch/arm/include/asm/arch-bcm235xx/boot0.h | 8 +---
>  arch/arm/include/asm/arch-bcm281xx/boot0.h | 8 +---
>  arch/arm/include/asm/arch-sunxi/boot0.h| 8 +---
>  arch/arm/lib/vectors.S | 1 -
>  5 files changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index ee393d7..140609d 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -26,7 +26,6 @@ _start:
>   * use it here.
>   */
>  #include 
> -ARM_SOC_BOOT0_HOOK
>  #else
> b   reset
>  #endif
> diff --git a/arch/arm/include/asm/arch-bcm235xx/boot0.h 
> b/arch/arm/include/asm/arch-bcm235xx/boot0.h
> index 7e72882..9ff90b8 100644
> --- a/arch/arm/include/asm/arch-bcm235xx/boot0.h
> +++ b/arch/arm/include/asm/arch-bcm235xx/boot0.h
> @@ -4,12 +4,6 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>
> -#ifndef __BOOT0_H
> -#define __BOOT0_H
> -
>  /* BOOT0 header information */
> -#define ARM_SOC_BOOT0_HOOK \
> -   .word   0xbabeface; \
> +   .word   0xbabeface;
this trailing semi-colon is not necessary

> .word   _end - _start
> -
> -#endif /* __BOOT0_H */
> diff --git a/arch/arm/include/asm/arch-bcm281xx/boot0.h 
> b/arch/arm/include/asm/arch-bcm281xx/boot0.h
> index 7e72882..9ff90b8 100644
> --- a/arch/arm/include/asm/arch-bcm281xx/boot0.h
> +++ b/arch/arm/include/asm/arch-bcm281xx/boot0.h
> @@ -4,12 +4,6 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>
> -#ifndef __BOOT0_H
> -#define __BOOT0_H
> -
>  /* BOOT0 header information */
> -#define ARM_SOC_BOOT0_HOOK \
> -   .word   0xbabeface; \
> +   .word   0xbabeface;
this trailing semi-colon is not necessary

> .word   _end - _start
> -
> -#endif /* __BOOT0_H */
> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h 
> b/arch/arm/include/asm/arch-sunxi/boot0.h
> index 6f28d63..6a13db5 100644
> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
> @@ -4,12 +4,6 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>
> -#ifndef __BOOT0_H
> -#define __BOOT0_H
> -
>  /* reserve space for BOOT0 header information */
> -#define ARM_SOC_BOOT0_HOOK \
> -   b   reset;  \
> +   b   reset
> .space  1532
> -
> -#endif /* __BOOT0_H */
> diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S
> index 5cc132b..9fe7415 100644
> --- a/arch/arm/lib/vectors.S
> +++ b/arch/arm/lib/vectors.S
> @@ -67,7 +67,6 @@ _start:
>   * use it here.
>   */
>  #include 
> -ARM_SOC_BOOT0_HOOK
>  #endif
>
>  /*
> --
> 2.8.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Tested-by: Steve Rae 

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

Re: [U-Boot] [PATCH v2 09/23] ARM: boot0 hook: remove macro, include whole header file

2016-12-30 Thread Steve Rae

Hi Andre (3rd attempt...)

On Sun, Dec 4, 2016 at 5:52 PM, Andre Przywara  wrote:
> For prepending some board specific header area to U-Boot images we
> were so far including a header file with a macro definition containing
> the actual header specification.
> This works fine if there are just a few statements and if there is only
> one alternative.
> However adding more complex code quickly gets messy with this approach,
> so let's just drop that intermediate macro and let the #include actually
> insert the code directly.
> This converts the callers and the callees, but doesn't change anything
> at this point.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/start.S | 1 -
>  arch/arm/include/asm/arch-bcm235xx/boot0.h | 8 +---
>  arch/arm/include/asm/arch-bcm281xx/boot0.h | 8 +---
>  arch/arm/include/asm/arch-sunxi/boot0.h| 8 +---
>  arch/arm/lib/vectors.S | 1 -
>  5 files changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index ee393d7..140609d 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -26,7 +26,6 @@ _start:
>   * use it here.
>   */
>  #include 
> -ARM_SOC_BOOT0_HOOK
>  #else
> b   reset
>  #endif
> diff --git a/arch/arm/include/asm/arch-bcm235xx/boot0.h 
> b/arch/arm/include/asm/arch-bcm235xx/boot0.h
> index 7e72882..9ff90b8 100644
> --- a/arch/arm/include/asm/arch-bcm235xx/boot0.h
> +++ b/arch/arm/include/asm/arch-bcm235xx/boot0.h
> @@ -4,12 +4,6 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>
> -#ifndef __BOOT0_H
> -#define __BOOT0_H
> -
>  /* BOOT0 header information */
> -#define ARM_SOC_BOOT0_HOOK \
> -   .word   0xbabeface; \
> +   .word   0xbabeface;
the trailing semi-colon is not necessary

> .word   _end - _start
> -
> -#endif /* __BOOT0_H */
> diff --git a/arch/arm/include/asm/arch-bcm281xx/boot0.h 
> b/arch/arm/include/asm/arch-bcm281xx/boot0.h
> index 7e72882..9ff90b8 100644
> --- a/arch/arm/include/asm/arch-bcm281xx/boot0.h
> +++ b/arch/arm/include/asm/arch-bcm281xx/boot0.h
> @@ -4,12 +4,6 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>
> -#ifndef __BOOT0_H
> -#define __BOOT0_H
> -
>  /* BOOT0 header information */
> -#define ARM_SOC_BOOT0_HOOK \
> -   .word   0xbabeface; \
> +   .word   0xbabeface;
the trailing semi-colon is not necessary

> .word   _end - _start
> -
> -#endif /* __BOOT0_H */
> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h 
> b/arch/arm/include/asm/arch-sunxi/boot0.h
> index 6f28d63..6a13db5 100644
> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
> @@ -4,12 +4,6 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>
> -#ifndef __BOOT0_H
> -#define __BOOT0_H
> -
>  /* reserve space for BOOT0 header information */
> -#define ARM_SOC_BOOT0_HOOK \
> -   b   reset;  \
> +   b   reset
> .space  1532
> -
> -#endif /* __BOOT0_H */
> diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S
> index 5cc132b..9fe7415 100644
> --- a/arch/arm/lib/vectors.S
> +++ b/arch/arm/lib/vectors.S
> @@ -67,7 +67,6 @@ _start:
>   * use it here.
>   */
>  #include 
> -ARM_SOC_BOOT0_HOOK
>  #endif
>
>  /*
> --
> 2.8.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Tested-by: Steve Rae 

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

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

2016-12-30 Thread Marek Vasut

On 12/29/2016 04:26 PM, Tom Rini wrote:
> On Thu, Dec 29, 2016 at 12:41:06AM +0100, Marek Vasut wrote:
>> On 12/28/2016 09:52 AM, Lukasz Majewski wrote:
>>> Hi Marek,
>>>
 On 12/26/2016 05:36 PM, Lukasz Majewski wrote:
> Hi Marek,
>
>> On 11/29/2016 07:18 PM, Tom Rini wrote:
>>> On Tue, Nov 29, 2016 at 11:50:34AM +0100, Marek Vasut wrote:
 On 11/29/2016 10:11 AM, Lukasz Majewski wrote:
> Hi Marek,
>
>> On 11/28/2016 10:09 PM, Lukasz Majewski wrote:
>>> This define gives the possibility to copy entire image
>>> (including header - e.g. u-boot.img) from NOR parallel memory
>>> to e.g. SDRAM. The current code only supports loading the raw
>>> binary image (the u-boot.bin).
>>>
>>> The legacy behavior is preserved, since other board don't
>>> enabled this option.
>>
>> So, what's the usecase again ? ;-) 
>
> :-)
>
> The use case is to allow u-boot.img being loaded from Parallel
> NOR. The current code only supports u-boot.bin.

 Why is u-boot.bin (or the payload) not sufficient ? Why do you
 need the header ?
>>>
>>> Well, the general use-case and code flow is that we load
>>> u-boot.img (or a FIT image) and if all else fails, fall back to
>>> assuming a .bin and a known address).
>>>
>> And exactly how is that whole image useful in RAM ? Sorry, I still
>> do not see it, usually you just need the executable payload,
>> although even that can be left in flash most of the time.
>
> The use case is that I do want to boot from SD card/eMMC and NOR
> with using u-boot.img.
>
> I would like to avoid situation when for NOR I must use u-boot.bin
> and for eMMC u-boot.img.
>
> Such approach keeps things as simple as possible :-)

 Oh, so it allows you to detect bitrot for the content in SPI NOR ?
>>>
>>> I do not use SPI NOR, it is parallel NOR.
>>
>> Sorry, I meant parallel NOR of course.
>>
 It's a bit strange we had to use u-boot.bin with SPL there.

>>>
>>> This is how the legacy system behaves. It uses (by default) Parallel
>>> NOR for booting (with advised/provided NOR memory timings). After doing
>>> some measurements, it turned out that for "tunned" u-boot/SPL there
>>> would be the best way to copy it to ram and execute it from there (just
>>> like eMMC).
>>>
>>> Hence, I would like to use u-boot.img in both booting scenarios.
>>
>> I think I was mistaken yesterday, I don't think I understand why copying
>> the image including the header into RAM has any benefit compared to
>> copying just the image payload to RAM (and yes, we're
>> getting back to my original question).
> 
> Code complexity and forward compatibility?

This is adding code complexity, but this is not my point.

> The general case in the SPL
> framework is that we have either a "legacy" image or a FIT image and we
> fall back to "well, just run it!".

Well, this doesn't answer my question, because if I understand this
patch correctly, it copies the entire legacy image (incl. header) into
RAM instead of copying just the image payload (which we already do). I
don't really understand why we want to do this. Or do I misunderstand
something ?

-- 
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 v2 21/30] arm: socfpga: arria10: Enhanced socfpga_arria10_defconfig to support SPL

2016-12-30 Thread Marek Vasut

On 12/29/2016 05:54 AM, Chee, Tien Fong wrote:
> On Kha, 2016-12-29 at 00:51 +0100, Marek Vasut wrote:
>> On 12/28/2016 07:34 AM, Chee Tien Fong wrote:
>>>
>>> From: Tien Fong Chee 
>>>
>>> Enhanced defconfig file for Arria10 to enable SPL build and
>>> supporting
>>> device tree build for SDMMC.
>>>
>>> Signed-off-by: Tien Fong Chee 
>>> Cc: Marek Vasut 
>>> Cc: Dinh Nguyen 
>>> Cc: Chin Liang See 
>>> Cc: Tien Fong 
>>> ---
>>> Changes for V2
>>> - Removed boot header info setup since it already fixed in mainline
>>> ---
>>>  configs/socfpga_arria10_defconfig | 18 +-
>>>  1 file changed, 13 insertions(+), 5 deletions(-)
>> There's no arria10 defconfig in mainline ?
>> I only received patches 18/30 and on ?
>>
> patch1 to patch17 are 01-arria10 rebase on u-boot.git, i believe those
> patches not CC to you orginally. Could you get from U-Boot Digest, Vol
> 103, Issue 53, or you want me to edit those patches CC to you?

No, you cannot get them from the digest, it's a digest after all.
I can get them from the list, but please always CC maintainers on
relevant patches.

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

[U-Boot] any ongoing value to "CONFIG_SYS_FLASH_CHECKSUM" config variable?

2016-12-30 Thread Robert P. J. Day


 still going through common/board_r.c, and ran across the above CONFIG
variable, but it seems to have very little use these days. as you can
see from a recursive grep:

$ grep -r SYS_FLASH_CHECKSUM *

it shows up in board_r.c:

common/board_r.c:#ifdef CONFIG_SYS_FLASH_CHECKSUM
common/board_r.c:#endif /* CONFIG_SYS_FLASH_CHECKSUM */

then some under include/configs wherein only a small number of config
header files #define it (all the rest #undef it):

include/configs/P1010RDB.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M5249EVB.h:#define CONFIG_SYS_FLASH_CHECKSUM   <--
include/configs/MPC8315ERDB.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/socrates.h:#undef   CONFIG_SYS_FLASH_CHECKSUM
include/configs/yucca.h:#undef  CONFIG_SYS_FLASH_CHECKSUM
include/configs/mpc5121ads.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8323ERDB.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M52277EVB.h:#   define CONFIG_SYS_FLASH_CHECKSUM   <--
include/configs/MPC8544DS.h:#undef  CONFIG_SYS_FLASH_CHECKSUM
include/configs/bamboo.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8536DS.h:#undef  CONFIG_SYS_FLASH_CHECKSUM
include/configs/vme8349.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/ac14xx.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8641HPCN.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/katmai.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M54418TWR.h:#define CONFIG_SYS_FLASH_CHECKSUM  <--
include/configs/MPC837XEMDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/p1_twr.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/p1_p2_rdb_pc.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC832XEMDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/UCP1020.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8610HPCD.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8548CDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M5282EVB.h:#define CONFIG_SYS_FLASH_CHECKSUM   <--
include/configs/M54455EVB.h:#   define CONFIG_SYS_FLASH_CHECKSUM   <--
include/configs/redwood.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC837XERDB.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8568MDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8540ADS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/sbc8548.h:#undefCONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8349EMDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/M54451EVB.h:#   define CONFIG_SYS_FLASH_CHECKSUM   <--
include/configs/MPC8541CDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/TQM834x.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/sbc8641d.h:#undef   CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8572DS.h:#undef  CONFIG_SYS_FLASH_CHECKSUM
include/configs/BSC9132QDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8569MDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/sbc8349.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/mecp5123.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8560ADS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/aria.h:#undef CONFIG_SYS_FLASH_CHECKSUM
include/configs/MPC8555CDS.h:#undef CONFIG_SYS_FLASH_CHECKSUM
scripts/config_whitelist.txt:CONFIG_SYS_FLASH_CHECKSUM

and in:

scripts/config_whitelist.txt:CONFIG_SYS_FLASH_CHECKSUM

and that's it. the code in board_r.c is:

  #ifdef CONFIG_SYS_FLASH_CHECKSUM
/*
* Compute and print flash CRC if flashchecksum is set to 'y'
*
* NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
*/
if (getenv_yesno("flashchecksum") == 1) {
printf("  CRC: %08X", crc32(0,
(const unsigned char *) CONFIG_SYS_FLASH_BASE,
flash_size));
}
  #endif /* CONFIG_SYS_FLASH_CHECKSUM */

wherein, even if that variable is set, a further test is made of the
environment variable "flashchecksum."

  is there still value to this CONFIG variable given that only a
half-dozen boards define it? am i overlooking something obvious?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] [RESEND PATCH v3 1/2] mmc: rockchip_sdhci: add clock init for mmc

2016-12-30 Thread Stefan Herbrechtsmeier


Hi,

Am 30.12.2016 um 01:13 schrieb Jaehoon Chung:

Hi Stefan,

On 12/30/2016 12:41 AM, Stefan Herbrechtsmeier wrote:

Hi,

Am 29.12.2016 um 08:44 schrieb Jaehoon Chung:

Hi

On 12/29/2016 09:53 AM, Kever Yang wrote:

Hi Stefan,

  Thanks for your review comment.
On 12/29/2016 02:35 AM, Stefan Herbrechtsmeier wrote:

Hi,

Am 28.12.2016 um 12:01 schrieb Jaehoon Chung:

On 12/28/2016 12:32 PM, Kever Yang wrote:

Init the clock rate to max-frequency from dts with clock driver api.

Signed-off-by: Kever Yang 

Reviewed-by: Jaehoon Chung 

This is an incorrect use of the max-frequency property.

The max-frequency value limit the output clock of the mmc interface and depends 
on the controller, circuit (level shifter), board and so on. It doesn't 
represents the clock frequency of the controller.

The clock setup inside the clock framework should use the assigned-clock-rates 
property. The mmc driver should only enable the clock and pass the clock rate 
together with the max-frequency to the mmc framework.

I'm not good at mmc controller and driver framework, but seems that the sdhci 
core treats the max-frequency as the clock input from clock module, right?

This is true for the current u-boot implementation. But this code is wrong and 
differs from the kernel. The u-boot mmc framework doesn't distinguish between 
f_max of the mmc interface and max_clk of the host controller. I have already 
post a patch to fix this.


What if the mmc controller max-frequency is not equal to the clock module 
output which is possible? Does kernel deal with this, and how.

The kernel distinguish between clock module output frequency (host->max_clk) and 
max-frequency of the mmc interface (mmc->f_max).


If my understanding is right, some controller should be broken the CLOCK_BASE 
capability. (Refer to Linux kernel)
And then they needs to get value from CMU.

host->max_clk should be used the card's maximum value.

It represents the (input) base clock of the mmc controller and not the card. A 
divider of one leads to maximum value.


In Linux Kernel's case
if max_frequency property is defined, assigned to mmc->f_max
and host->f_max is assigned to clk_get_rate() value. (If Broken clock_base 
capability)

host->max_clk not host->f_max


And check "mmc->f_max > host->f_max" or "mmc->f_max == 0"
 if true
 then mmc->_f_max = f_max;
 else
 then mmc->f_max is used to "max_frequency" value.

In Conclusion,
 host's maximum value is used. ("max_frequency" property is used to 
QUIRK_BROKEN_CAP_CLOCK_BASE in Linux kernel.)

The conclusion is wrong. The host->max_clk isn't influenced by the max-frequency. The mmc 
drivers supplies the host->max_clk via the get_max_clock function if 
QUIRK_BROKEN_CAP_CLOCK_BASE is set. The mmc->f_max is equal to host->max_clk or 
max-frequency if set. This means you only need max-frequency if it is lower than the 
host->max_clk.

My comments refer to the linux kernel sdhci implementation.


host->max_clk is influenced by max-frequency.

Where is the host->max_clk influenced by the max-frequency?


get_max_clock function? where is get_max_clock() function used?
It is used in the kernel to set host->max_clk if the 
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN is set.



Your patches didn't apply yet. waiting for Michal's review.
Only one patch is waiting Michal's review and the mmc clock separation 
could be applied without the other patches.



Did you know what means the quirk for broken clock base?
It means host->max_clk can be 0 or other.
It means that the host->max_clk could not be extracted from the 
SDHCI_CAPABILITIES and need to be provided by the driver.



  Then it should be lower than min_clk likes your mentions.
To prevent this, getting from max_frequency property.

Why do you think that max-frequency influences the host->max_clk?
The host->max_clk could be read from the SDHCI_CAPABILITIES or need to 
be provided by the driver. The host->max_clk is a fixed clock rate and 
the mmc->f_max limits the generated frequencies of the sdhci controller. 
The host->max_clk depends on the processor and the mmc->f_max depends on 
the board, card and so on.



The host->max_clk is used for the calculation of the divider and multiplier. It 
represents the clock rate of the controller.
The mmc->f_max limits the clock rate of the card.

Yes, mmc->f_max is card's maximum frequency.
You can see how to control the clock in drivers/mmc/mmc.c

Kernel and u-boot have to check the card and host's clock values.
And needs to choose the one of them.. f_max is not getting from card. Also it's 
assigned from host controller.
The mmc->f_max and host->max_clk have different purposes. The mmc->f_max 
limits the requested frequency. The host->max_clk represents the clock 
frequency in front of the divider and optional multiplier and is used to 
calculate the divider and multiplier. The host->max_clk depends on the 
CMU and is never changed. The mmc->f_max depends on

[U-Boot] [PATCH] mmc: uniphier-sd: fix Kconfig dependency

2016-12-30 Thread Masahiro Yamada

Some MMC drivers describe operations with the DM_MMC_OPS form, but
there are still several drivers with older implementation.  We can
not compile drivers from different groups at the same time because
the core framework is shared with #ifdef CONFIG_DM_MMC_OPS.

Every driver should have "depends on DM_MMC_OPS" (or !DM_MMC_OPS)
explicitly to express which framework it is based on.  This will
avoid enabling drivers with incompatible interface at the same time.
It is incorrect to make a driver "select DM_MMC_OPS".

While we are here, add "depends on OF_CONTROL" as well because this
driver can be configured only by Device Tree.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index ff4344f..75b6ba1 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -107,8 +107,8 @@ config ROCKCHIP_SDHCI
 config MMC_UNIPHIER
bool "UniPhier SD/MMC Host Controller support"
depends on ARCH_UNIPHIER
-   depends on BLK
-   select DM_MMC_OPS
+   depends on BLK && DM_MMC_OPS
+   depends on OF_CONTROL
help
  This selects support for the SD/MMC Host Controller on UniPhier SoCs.
 
-- 
2.7.4

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

[U-Boot] any value to "#if defined(CONFIG_OXC) || defined(CONFIG_RMU)" test in board_r.c?

2016-12-30 Thread Robert P. J. Day


  still pawing through the flash support code in u-boot for my
personal edification, and ran across this snippet in common/board_r.c:

  #if defined(CONFIG_OXC) || defined(CONFIG_RMU)
/* flash mapped at end of memory map */
bd->bi_flashoffset = CONFIG_SYS_TEXT_BASE + flash_size;
  #elif CONFIG_SYS_MONITOR_BASE == CONFIG_SYS_FLASH_BASE
bd->bi_flashoffset = monitor_flash_len; /* reserved area for monitor */
  #endif

in that first test, the "defined(CONFIG_OXC)" part seems dead as the
OXC board was scrapped some time ago:

  OXC   powerpc MPC8240309a292 2011-12-07

and i'm not sure anything needs that second test either, does it? can
that entire first preprocessor test be deleted? or am i missing
something?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[U-Boot] [PATCH v2] mmc: sdhci-cadence: add Cadence SD4HC support

2016-12-30 Thread Masahiro Yamada

Add a driver for the Cadence SD4HC SD/SDIO/eMMC Controller.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Remove unneeded version setting
  - Add SoC specific compatible "socionext,uniphier-sd4hc"
  - Add "depends on BLK && DM_MMC_OPS && MMC_SDHCI"

 drivers/mmc/Kconfig |  12 +
 drivers/mmc/Makefile|   1 +
 drivers/mmc/sdhci-cadence.c | 125 
 3 files changed, 138 insertions(+)
 create mode 100644 drivers/mmc/sdhci-cadence.c

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 2ba1254..ff4344f 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -159,6 +159,18 @@ config MMC_SDHCI_BCM2835
 
  If unsure, say N.
 
+config MMC_SDHCI_CADENCE
+   bool "SDHCI support for the Cadence SD/SDIO/eMMC controller"
+   depends on BLK && DM_MMC_OPS
+   depends on MMC_SDHCI
+   depends on OF_CONTROL
+   help
+ This selects the Cadence SD/SDIO/eMMC driver.
+
+ If you have a controller with this interface, say Y here.
+
+ If unsure, say N.
+
 config MMC_SDHCI_KONA
bool "SDHCI support on Broadcom KONA platform"
depends on MMC_SDHCI
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 2b136ea..a543188 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_MSM_SDHCI) += msm_sdhci.o
 # SDHCI
 obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
 obj-$(CONFIG_MMC_SDHCI_BCM2835)+= bcm2835_sdhci.o
+obj-$(CONFIG_MMC_SDHCI_CADENCE)+= sdhci-cadence.o
 obj-$(CONFIG_MMC_SDHCI_KONA)   += kona_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_MV) += mv_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_S5P)+= s5p_sdhci.o
diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
new file mode 100644
index 000..2253bbc
--- /dev/null
+++ b/drivers/mmc/sdhci-cadence.c
@@ -0,0 +1,125 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* HRS - Host Register Set (specific to Cadence) */
+#define SDHCI_CDNS_HRS04   0x10/* PHY access port */
+#define   SDHCI_CDNS_HRS04_ACK BIT(26)
+#define   SDHCI_CDNS_HRS04_RD  BIT(25)
+#define   SDHCI_CDNS_HRS04_WR  BIT(24)
+#define   SDHCI_CDNS_HRS04_RDATA_SHIFT 12
+#define   SDHCI_CDNS_HRS04_WDATA_SHIFT 8
+#define   SDHCI_CDNS_HRS04_ADDR_SHIFT  0
+
+/* SRS - Slot Register Set (SDHCI-compatible) */
+#define SDHCI_CDNS_SRS_BASE0x200
+
+/* PHY */
+#define SDHCI_CDNS_PHY_DLY_SD_HS   0x00
+#define SDHCI_CDNS_PHY_DLY_SD_DEFAULT  0x01
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR12   0x02
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR25   0x03
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR50   0x04
+#define SDHCI_CDNS_PHY_DLY_UHS_DDR50   0x05
+#define SDHCI_CDNS_PHY_DLY_EMMC_LEGACY 0x06
+#define SDHCI_CDNS_PHY_DLY_EMMC_SDR0x07
+#define SDHCI_CDNS_PHY_DLY_EMMC_DDR0x08
+
+struct sdhci_cdns_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+   void __iomem *hrs_addr;
+};
+
+static void sdhci_cdns_write_phy_reg(struct sdhci_cdns_plat *plat,
+u8 addr, u8 data)
+{
+   void __iomem *reg = plat->hrs_addr + SDHCI_CDNS_HRS04;
+   u32 tmp;
+
+   tmp = (data << SDHCI_CDNS_HRS04_WDATA_SHIFT) |
+ (addr << SDHCI_CDNS_HRS04_ADDR_SHIFT);
+   writel(tmp, reg);
+
+   tmp |= SDHCI_CDNS_HRS04_WR;
+   writel(tmp, reg);
+
+   tmp &= ~SDHCI_CDNS_HRS04_WR;
+   writel(tmp, reg);
+}
+
+static void sdhci_cdns_phy_init(struct sdhci_cdns_plat *plat)
+{
+   sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_SD_HS, 4);
+   sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_SD_DEFAULT, 4);
+   sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_EMMC_LEGACY, 9);
+   sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_EMMC_SDR, 2);
+   sdhci_cdns_write_phy_reg(plat, SDHCI_CDNS_PHY_DLY_EMMC_DDR, 3);
+}
+
+static int sdhci_cdns_bind(struct udevice *dev)
+{
+   struct sdhci_cdns_plat *plat = dev_get_platdata(dev);
+
+   return sdhci_bind(dev, >mmc, >cfg);
+}
+
+static int sdhci_cdns_probe(struct udevice *dev)
+{
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct sdhci_cdns_plat *plat = dev_get_platdata(dev);
+   struct sdhci_host *host = dev_get_priv(dev);
+   fdt_addr_t base;
+   int ret;
+
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   plat->hrs_addr = devm_ioremap(dev, base, SZ_1K);
+   if (!plat->hrs_addr)
+   return -ENOMEM;
+
+   host->name = dev->name;
+   host->ioaddr = plat->hrs_addr + SDHCI_CDNS_SRS_BASE;
+   host->quirks |= SDHCI_QUIRK_WAIT_SEND_CMD;
+

Re: [U-Boot] [PATCHv2] power: change from meaningless value to error number

2016-12-30 Thread Tom Rini

On Fri, Dec 30, 2016 at 03:42:56PM +0900, Jaehoon Chung wrote:
> Hi all,
> 
> On 12/18/2016 07:48 AM, Simon Glass wrote:
> > On 15 December 2016 at 04:49, Jaehoon Chung  wrote:
> >> '-1' is absolutely meaningless value.
> >> This patch changed from meaningless value to error number.
> >>
> >> Signed-off-by: Jaehoon Chung 
> >> ---
> >> Changelog on V2
> >> - Fixes the missing error number in exynos-tmu.c
> >>
> >>  drivers/power/axp152.c |  2 +-
> >>  drivers/power/axp209.c |  2 +-
> >>  drivers/power/battery/bat_trats2.c |  2 +-
> >>  drivers/power/exynos-tmu.c |  8 
> >>  drivers/power/fuel_gauge/fg_max17042.c |  4 ++--
> >>  drivers/power/mfd/fg_max77693.c|  4 ++--
> >>  drivers/power/mfd/pmic_max77693.c  |  8 
> >>  drivers/power/palmas.c | 11 +++
> >>  drivers/power/pmic/pmic_hi6553.c   |  4 ++--
> >>  drivers/power/pmic/pmic_max77686.c | 18 +-
> >>  drivers/power/pmic/pmic_max8997.c  |  8 
> >>  drivers/power/power_core.c |  8 
> >>  drivers/power/power_i2c.c  | 22 +++---
> >>  drivers/power/power_spi.c  | 18 ++
> >>  drivers/power/tps6586x.c   | 12 ++--
> >>  15 files changed, 64 insertions(+), 67 deletions(-)
> > 
> > Reviewed-by: Simon Glass 
> 
> This patch was delegated to me..but i can't apply on u-boot-pmic repository.
> So If there is no issue, i will apply this patch on my u-boot-mmc 
> repository,(?)
> 
> how do I? let me know, plz.

I'm OK just taking the PR from the mmc repository for now, 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 29/30] arm: socfpga: arria10: Added Arria10 critical HW initialization to spl

2016-12-30 Thread Dinh Nguyen



On 12/28/2016 12:34 AM, Chee Tien Fong wrote:
> From: Tien Fong Chee 
> 
> This patch adding the Arria10 critical hardware initialization before
> enabling console print out in spl.
> 
> Signed-off-by: Tien Fong Chee 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> Cc: Tien Fong 
> ---
> Changes for V2
> - Release UART from reset before enalbing console, and reverting license
>   changes.
> ---
>  arch/arm/mach-socfpga/spl.c | 84 
> +++--
>  1 file changed, 82 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
> index fec4c7a..9e27f82 100644
> --- a/arch/arm/mach-socfpga/spl.c
> +++ b/arch/arm/mach-socfpga/spl.c
> @@ -1,5 +1,5 @@
>  /*
> - *  Copyright (C) 2012 Altera Corporation 
> + *  Copyright (C) 2012-2016 Altera Corporation 
>   *
>   * SPDX-License-Identifier:  GPL-2.0+
>   */
> @@ -19,22 +19,32 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> +#include 
> +#endif
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  static struct pl310_regs *const pl310 =
>   (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
>  static struct scu_registers *scu_regs =
>   (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
>  static struct nic301_registers *nic301_regs =
>   (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
> -static struct socfpga_system_manager *sysmgr_regs =
> +#endif
> +
> +static const struct socfpga_system_manager *sysmgr_regs =
>   (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
>  
>  u32 spl_boot_device(void)
>  {
>   const u32 bsel = readl(_regs->bootinfo);
>  
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>   switch (bsel & 0x7) {
>   case 0x1:   /* FPGA (HPS2FPGA Bridge) */
>   return BOOT_DEVICE_RAM;
> @@ -55,6 +65,24 @@ u32 spl_boot_device(void)
>   printf("Invalid boot device (bsel=%08x)!\n", bsel);
>   hang();
>   }
> +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> + switch ((bsel>>12) & 0x7) {

Spaces around the '>>'.

> + case 0x1:   /* FPGA (HPS2FPGA Bridge) */
> + return BOOT_DEVICE_RAM;
> + case 0x2:   /* NAND Flash (1.8V) */
> + case 0x3:   /* NAND Flash (3.0V) */
> + return BOOT_DEVICE_NAND;
> + case 0x4:   /* SD/MMC External Transceiver (1.8V) */
> + case 0x5:   /* SD/MMC Internal Transceiver (3.0V) */
> + return BOOT_DEVICE_MMC1;
> + case 0x6:   /* QSPI Flash (1.8V) */
> + case 0x7:   /* QSPI Flash (3.0V) */
> + return BOOT_DEVICE_SPI;
> + default:
> + printf("Invalid boot device (bsel=%08x)!\n", bsel);
> + hang();
> + }
> +#endif
>  }

You missed my comment from V1:

You should just do a shift define  here, so you don't have to add
all
this extra code here. Something like

switch ((bsel >> BOOTINFO_BSEL_SHIFT) & 0x7)


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

Re: [U-Boot] [PATCH] board: freescale: ls2080a: Intergrate and enable PPA on LS2080A

2016-12-30 Thread Prabhakar Kushwaha


> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Abhimanyu
> Saini
> Sent: Thursday, December 29, 2016 9:52 AM
> To: york sun ; u-boot@lists.denx.de
> Cc: Priyanka Jain 
> Subject: [U-Boot] [PATCH] board: freescale: ls2080a: Intergrate and enable PPA
> on LS2080A
> 
> Integrate and enable PPA on LS2080ARDB, LS2080AQDS, LS2088ARDB
> and LS2088AQDS boards.
> 
> Signed-off-by: Abhimanyu Saini 
> ---
>  board/freescale/ls2080aqds/ls2080aqds.c |  6 ++
>  board/freescale/ls2080ardb/ls2080ardb.c |  6 ++
>  include/configs/ls2080aqds.h| 10 ++
>  include/configs/ls2080ardb.h| 10 ++
>  4 files changed, 32 insertions(+)
> 
> diff --git a/board/freescale/ls2080aqds/ls2080aqds.c
> b/board/freescale/ls2080aqds/ls2080aqds.c
> index 73a61fd..811b9a6 100644
> --- a/board/freescale/ls2080aqds/ls2080aqds.c
> +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> @@ -19,6 +19,9 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_FSL_LS_PPA
> +#include 
> +#endif
> 
>  #include "../common/qixis.h"
>  #include "ls2080aqds_qixis.h"
> @@ -223,6 +226,9 @@ int board_init(void)
>  #endif
>   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
>   rtc_enable_32khz_output();
> +#ifdef CONFIG_FSL_LS_PPA
> + ppa_init();
> +#endif
> 
>   return 0;
>  }
> diff --git a/board/freescale/ls2080ardb/ls2080ardb.c
> b/board/freescale/ls2080ardb/ls2080ardb.c
> index 02954ef..339fa78 100644
> --- a/board/freescale/ls2080ardb/ls2080ardb.c
> +++ b/board/freescale/ls2080ardb/ls2080ardb.c
> @@ -19,6 +19,9 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_FSL_LS_PPA
> +#include 
> +#endif
> 
>  #include "../common/qixis.h"
>  #include "ls2080ardb_qixis.h"
> @@ -184,6 +187,9 @@ int board_init(void)
>   /* invert AQR405 IRQ pins polarity */
>   out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR405_IRQ_MASK);
>  #endif
> +#ifdef CONFIG_FSL_LS_PPA
> + ppa_init();
> +#endif
> 
>   return 0;
>  }
> diff --git a/include/configs/ls2080aqds.h b/include/configs/ls2080aqds.h
> index 838568f..5573e94 100644
> --- a/include/configs/ls2080aqds.h
> +++ b/include/configs/ls2080aqds.h
> @@ -14,6 +14,16 @@ unsigned long get_board_sys_clk(void);
>  unsigned long get_board_ddr_clk(void);
>  #endif
> 
> +#define CONFIG_FSL_LS_PPA

I am not finding CONFIG_FSL_LS_PPA being defined in board header file. 
Please refer arch/arm/cpu/armv8/fsl-layerscape/Kconfig. Looks like its 
enablement is govern from here.

--prabhakar



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

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

Re: [U-Boot] [PATCH] Fix fastboot boot address

Re: [U-Boot] [PATCH v3 10/26] ARM: boot0 hook: remove macro, include whole header file

Re: [U-Boot] [PATCH v2 09/23] ARM: boot0 hook: remove macro, include whole header file

Re: [U-Boot] [PATCH] SPL: NOR: Add CONFIG_SPL_NOR_COPY_ENTIRE_IMAGE define to enable whole image copy from NOR

Re: [U-Boot] [PATCH v2 21/30] arm: socfpga: arria10: Enhanced socfpga_arria10_defconfig to support SPL

[U-Boot] any ongoing value to "CONFIG_SYS_FLASH_CHECKSUM" config variable?

Re: [U-Boot] [RESEND PATCH v3 1/2] mmc: rockchip_sdhci: add clock init for mmc

[U-Boot] [PATCH] mmc: uniphier-sd: fix Kconfig dependency

[U-Boot] any value to "#if defined(CONFIG_OXC) || defined(CONFIG_RMU)" test in board_r.c?

[U-Boot] [PATCH v2] mmc: sdhci-cadence: add Cadence SD4HC support

Re: [U-Boot] [PATCHv2] power: change from meaningless value to error number

Re: [U-Boot] [PATCH v2 29/30] arm: socfpga: arria10: Added Arria10 critical HW initialization to spl

Re: [U-Boot] [PATCH] board: freescale: ls2080a: Intergrate and enable PPA on LS2080A

16 matches

Site Navigation

Mail list logo

Footer information