[U-Boot] [PATCH] powerpc: e6500: Lock/unlock 1 cache instead of L1 as init_ram

2017-03-01 Thread Ruchika Gupta
Fir E6500 cores, L2 cache has been used as init_ram. L1 cache is a write
through cache on E6500.If lines are not locked in both L1 and L2 caches,
crashes are observed during secure boot. This patch locks/unlocks both L1
as well as L2 cache to prevent the crash.

Signed-off-by: Ruchika Gupta 
---
 arch/powerpc/cpu/mpc85xx/start.S | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index c3e1234..b9a4cb5 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1145,8 +1145,9 @@ switch_as:
li  r0,0
 1:
dcbzr0,r3
-#ifdef CONFIG_E6500/* Lock/unlock L2 cache instead of L1 */
+#ifdef CONFIG_E6500/* Lock/unlock L2 cache long with L1 */
dcbtls  2, r0, r3
+   dcbtls  0, r0, r3
 #else
dcbtls  0, r0, r3
 #endif
@@ -1790,8 +1791,9 @@ unlock_ram_in_cache:
slwir4,r4,(10 - 1 - L1_CACHE_SHIFT)
mtctr   r4
 1: dcbir0,r3
-#ifdef CONFIG_E6500/* lock/unlock L2 cache instead of L1 */
+#ifdef CONFIG_E6500/* lock/unlock L2 cache long with L1 */
dcblc   2, r0, r3
+   dcblc   0, r0, r3
 #else
dcblc   r0,r3
 #endif
-- 
1.9.1

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


[U-Boot] [PATCH] powerpc: e6500: Lock/unlock 1 cache instead of L1 as init_ram

2017-03-01 Thread Ruchika Gupta
Fir E6500 cores, L2 cache has been used as init_ram. L1 cache is a write
through cache on E6500.If lines are not locked in both L1 and L2 caches,
crashes are observed during secure boot. This patch locks/unlocks both L1
as well as L2 cache to prevent the crash.

Signed-off-by: Ruchika Gupta 
---
 arch/powerpc/cpu/mpc85xx/start.S | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index c3e1234..b9a4cb5 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1145,8 +1145,9 @@ switch_as:
li  r0,0
 1:
dcbzr0,r3
-#ifdef CONFIG_E6500/* Lock/unlock L2 cache instead of L1 */
+#ifdef CONFIG_E6500/* Lock/unlock L2 cache long with L1 */
dcbtls  2, r0, r3
+   dcbtls  0, r0, r3
 #else
dcbtls  0, r0, r3
 #endif
@@ -1790,8 +1791,9 @@ unlock_ram_in_cache:
slwir4,r4,(10 - 1 - L1_CACHE_SHIFT)
mtctr   r4
 1: dcbir0,r3
-#ifdef CONFIG_E6500/* lock/unlock L2 cache instead of L1 */
+#ifdef CONFIG_E6500/* lock/unlock L2 cache long with L1 */
dcblc   2, r0, r3
+   dcblc   0, r0, r3
 #else
dcblc   r0,r3
 #endif
-- 
1.9.1

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


Re: [U-Boot] [PATCHv2 3/3] lib: move hash CONFIG options to Kconfig

2017-03-01 Thread Tom Rini
On Thu, Mar 02, 2017 at 10:35:53AM +0900, Masahiro Yamada wrote:
> Hi Tom,
> 
> 
> 2017-03-02 6:52 GMT+09:00 Tom Rini :
> > From: Masahiro Yamada 
> >
> > Commit 94e3c8c4fd7b ("crypto/fsl - Add progressive hashing support
> > using hardware acceleration.") created entries for CONFIG_SHA1,
> > CONFIG_SHA256, CONFIG_SHA_HW_ACCEL, and CONFIG_SHA_PROG_HW_ACCEL.
> > However, no defconfig has migrated to it.  Complete the move with
> > moveconfig tool.  In many cases we can select these because they are
> > required to implement other drivers.  We also correct how we include
> > the various hashing algorithms in SPL.
> >
> > This commit was generated as follows:
> >
> > [1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
> > [2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL
> >
> > Note:
> > We cannot move SHA_HW_ACCEL and SHA_PROG_HW_ACCEL simultaneously
> > because there is dependency between them.
> >
> > Cc: Poonam Aggrwal 
> > Cc: Naveen Burmi 
> > Cc: Po Liu 
> > Cc: Shengzhou Liu 
> > Cc: Priyanka Jain 
> > Cc: Shaohui Xie 
> > Cc: Chunhe Lan 
> > Cc: Chander Kashyap 
> > Cc: Steve Rae 
> > Cc: Dirk Eibach 
> > Cc: Feng Li 
> > Cc: Alison Wang 
> > Cc: Sumit Garg 
> > Cc: Mingkai Hu 
> > Cc: York Sun 
> > Cc: Prabhakar Kushwaha 
> > Cc: Jaehoon Chung 
> > Cc: Akshay Saraswat 
> > Cc: Simon Glass 
> > Cc: Heiko Schocher 
> > Cc: Jagan Teki 
> > Signed-off-by: Masahiro Yamada 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - Add a large number of select statements so that our overall delta
> >   is fairly small.  This is not size neutral but is I believe correct.
> >   We had a number of cases before where we did not enable hw assist in
> >   the hash command and only made use of it in certain back end locations.
> 
> 
> Thanks a lot for arranging and improving this work!
> (I also thought about the possible "select", but I was just compromised in 
> v1.)
> 
> v2 is OK with me, and it is nicer to use "select" where possible
> but I do not have time to check the diffs in v2.
> 
> And, I am not comfortable with my Author and Signed-off-by
> because most of the efforts were done by you.
> (What I did for v1 was just to run the moveconfig.py,
> even did not do build-testing.)
> 
> So, could you replace the Author/SOB tags with yours?
> 
> I am happy to hand it off to anybody who does a better job.
> (and I do not require to record that the flag was raised by me)
> 
> 
> Also, the git-log:
>This commit was generated as follows:
>[1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
>[2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL
> is no longer valid because v2 includes manual works.
> Can you rephrase (or drop) it (in any way you think good).
> 
> Again, thank you for taking care of this!

Oh sure, I'll do a v3 in a day or two if there's no further comments,
and re-word the commit and grab authorship.  Thanks again!

-- 
Tom


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


Re: [U-Boot] [PATCHv2 3/3] lib: move hash CONFIG options to Kconfig

2017-03-01 Thread Masahiro Yamada
Hi Tom,


2017-03-02 6:52 GMT+09:00 Tom Rini :
> From: Masahiro Yamada 
>
> Commit 94e3c8c4fd7b ("crypto/fsl - Add progressive hashing support
> using hardware acceleration.") created entries for CONFIG_SHA1,
> CONFIG_SHA256, CONFIG_SHA_HW_ACCEL, and CONFIG_SHA_PROG_HW_ACCEL.
> However, no defconfig has migrated to it.  Complete the move with
> moveconfig tool.  In many cases we can select these because they are
> required to implement other drivers.  We also correct how we include
> the various hashing algorithms in SPL.
>
> This commit was generated as follows:
>
> [1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
> [2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL
>
> Note:
> We cannot move SHA_HW_ACCEL and SHA_PROG_HW_ACCEL simultaneously
> because there is dependency between them.
>
> Cc: Poonam Aggrwal 
> Cc: Naveen Burmi 
> Cc: Po Liu 
> Cc: Shengzhou Liu 
> Cc: Priyanka Jain 
> Cc: Shaohui Xie 
> Cc: Chunhe Lan 
> Cc: Chander Kashyap 
> Cc: Steve Rae 
> Cc: Dirk Eibach 
> Cc: Feng Li 
> Cc: Alison Wang 
> Cc: Sumit Garg 
> Cc: Mingkai Hu 
> Cc: York Sun 
> Cc: Prabhakar Kushwaha 
> Cc: Jaehoon Chung 
> Cc: Akshay Saraswat 
> Cc: Simon Glass 
> Cc: Heiko Schocher 
> Cc: Jagan Teki 
> Signed-off-by: Masahiro Yamada 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - Add a large number of select statements so that our overall delta
>   is fairly small.  This is not size neutral but is I believe correct.
>   We had a number of cases before where we did not enable hw assist in
>   the hash command and only made use of it in certain back end locations.


Thanks a lot for arranging and improving this work!
(I also thought about the possible "select", but I was just compromised in v1.)

v2 is OK with me, and it is nicer to use "select" where possible
but I do not have time to check the diffs in v2.

And, I am not comfortable with my Author and Signed-off-by
because most of the efforts were done by you.
(What I did for v1 was just to run the moveconfig.py,
even did not do build-testing.)

So, could you replace the Author/SOB tags with yours?

I am happy to hand it off to anybody who does a better job.
(and I do not require to record that the flag was raised by me)


Also, the git-log:
   This commit was generated as follows:
   [1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
   [2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL
is no longer valid because v2 includes manual works.
Can you rephrase (or drop) it (in any way you think good).

Again, thank you for taking care of this!


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


Re: [U-Boot] i.MX6QP sd boot issue

2017-03-01 Thread Peng Fan


> -Original Message-
> From: Jagan Teki [mailto:ja...@openedev.com]
> Sent: Wednesday, March 01, 2017 10:12 PM
> To: Peng Fan 
> Cc: Jagan Teki ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] i.MX6QP sd boot issue
> 
> On Wed, Mar 1, 2017 at 6:28 PM, Peng Fan  wrote:
> > Hi Jagan,
> >
> > Did you put J3 to connect 1-2?
> 
> What is J3, I couldn't find it. I saw J1 PCIe connector and J2 Headphone Jack.
> Can you point me J3.

There is J2 and J3 beside the boot mode switch s2.
I only have a base board. So J2 needs to be 1-2 connected. J3 1-2 connected to 
not boot from SPI.

You could have a try.
If your board runs into serial download mode, then J3 maybe wrong connection. 
If your board does not run into serial download mode, J2 maybe wrong connection.

Regards,
Peng.
> 
> >
> > Jumper Boot Selection
> > 1 - 2 Do not boot from SPI NOR (default)
> > 2 - 3 Boot from SPI NOR
> >
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:ja...@openedev.com]
> >> Sent: Wednesday, March 01, 2017 8:56 PM
> >> To: u-boot@lists.denx.de
> >> Cc: Peng Fan ; Stefano Babic 
> >> Subject: Re: [U-Boot] i.MX6QP sd boot issue
> >>
> >> + ML
> >>
> >> On Wed, Mar 1, 2017 at 6:23 PM, Jagan Teki  wrote:
> >> > Hi Peng and All,
> >> >
> >> > I'm trying to boot from SD, on imx6qplus sabre board.
> >> >
> >> > - SW6: D1-D8 => 0100 0010
> >> > - SD card on SD3
> >> > - D12 with USB-to-Serial 115200 8N1
> >> > - Power supply Output 5V
> >> >
> >> > Build:
> >> > $  make mx6qpsabreauto_defconfig; make $ dd if=u-boot.imx
> >> > of=/dev/sda
> >> > bs=512 seek=2
> >> >
> >> > When I plug-in power, power supply slot D1, D2 are green and D3
> >> > glow red not able to get the log on uart.
> >> >
> >> > Any help?
> >>
> >> thanks!
> >> --
> >> Jagan Teki
> >> Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream
> >> Maintainer Hyderabad, India.
> >
> > Regards,
> > Peng.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/listinfo/u-boot
> 
> 
> 
> --
> 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/listinfo/u-boot


Re: [U-Boot] [PATCH v2 6/8] dts: socfpga: Add trigger-address property to QSPI device

2017-03-01 Thread Dinh Nguyen


On 03/01/2017 05:07 PM, Rush, Jason A. wrote:
> Dinh Nguyen wrote:
>> Hi Jason,
>>
>> On 03/01/2017 10:38 AM, Rush, Jason A. wrote:
>>> Add the 'cdns,trigger-address' property to the cadence QSPI device
>>> node for Altera SoC devices.
>>>
>>> Signed-off-by: Jason A. Rush 
>>> ---
>>> Changed in v2:
>>>  - renamed trigger-base to trigger-address
>>>
>>>  arch/arm/dts/socfpga.dtsi | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
>>> index 8588221e57..ac26d05722 100644
>>> --- a/arch/arm/dts/socfpga.dtsi
>>> +++ b/arch/arm/dts/socfpga.dtsi
>>> @@ -646,6 +646,7 @@
>>> num-cs = <4>;
>>> fifo-depth = <128>;
>>> sram-size = <128>;
>>> +   trigger-address = <0x>;
>>
>> According to the documentation I see, the indaddrtrig on SoCFPGA is at
>> offset of 0x1C.
>>
> 
> Yes, the indaddrtrig register is at offset 0x1C, but the 'trigger-address'
> property is the value written to that address.
> 
> In older versions of U-Boot (where the CQSPI worked) the value was
> Written into the indaddrtrig register with the following code:
> 
>   ((u32)plat->ahbbase & CQSPI_INDIRECTTRIGGER_ADDR_MASK)
> 
> ahbbase is 0xffa0 and the mask is 0xF, which resulted in writing
> a 0x0 into the indaddrtrig register.
> 
> Later changes to the CQSPI code removed that mask, so the indaddrtrig
> register was programmed with 0xffa0 which resulted in the CPU
> resetting whenever a read/write was performed.
> 
> You can see this same change has been incorporated into the 4.10 kernel:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/socfpga.dtsi?id=refs/tags/v4.10#n727
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/spi-nor/cadence-quadspi.c?id=refs/tags/v4.10#n1054
> 

Ah ok. Thanks for the explanation, and sorry for the noise.

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


Re: [U-Boot] [PATCH v2 6/8] dts: socfpga: Add trigger-address property to QSPI device

2017-03-01 Thread Rush, Jason A.
Dinh Nguyen wrote:
> Hi Jason,
> 
> On 03/01/2017 10:38 AM, Rush, Jason A. wrote:
>> Add the 'cdns,trigger-address' property to the cadence QSPI device
>> node for Altera SoC devices.
>>
>> Signed-off-by: Jason A. Rush 
>> ---
>> Changed in v2:
>>  - renamed trigger-base to trigger-address
>>
>>  arch/arm/dts/socfpga.dtsi | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
>> index 8588221e57..ac26d05722 100644
>> --- a/arch/arm/dts/socfpga.dtsi
>> +++ b/arch/arm/dts/socfpga.dtsi
>> @@ -646,6 +646,7 @@
>>  num-cs = <4>;
>>  fifo-depth = <128>;
>>  sram-size = <128>;
>> +trigger-address = <0x>;
> 
> According to the documentation I see, the indaddrtrig on SoCFPGA is at
> offset of 0x1C.
> 

Yes, the indaddrtrig register is at offset 0x1C, but the 'trigger-address'
property is the value written to that address.

In older versions of U-Boot (where the CQSPI worked) the value was
Written into the indaddrtrig register with the following code:

  ((u32)plat->ahbbase & CQSPI_INDIRECTTRIGGER_ADDR_MASK)

ahbbase is 0xffa0 and the mask is 0xF, which resulted in writing
a 0x0 into the indaddrtrig register.

Later changes to the CQSPI code removed that mask, so the indaddrtrig
register was programmed with 0xffa0 which resulted in the CPU
resetting whenever a read/write was performed.

You can see this same change has been incorporated into the 4.10 kernel:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/socfpga.dtsi?id=refs/tags/v4.10#n727
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/spi-nor/cadence-quadspi.c?id=refs/tags/v4.10#n1054

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


Re: [U-Boot] [PATCH v2 6/8] dts: socfpga: Add trigger-address property to QSPI device

2017-03-01 Thread Dinh Nguyen
Hi Jason,

On 03/01/2017 10:38 AM, Rush, Jason A. wrote:
> Add the 'cdns,trigger-address' property to the cadence QSPI device
> node for Altera SoC devices.
> 
> Signed-off-by: Jason A. Rush 
> ---
> Changed in v2:
>  - renamed trigger-base to trigger-address
> 
>  arch/arm/dts/socfpga.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
> index 8588221e57..ac26d05722 100644
> --- a/arch/arm/dts/socfpga.dtsi
> +++ b/arch/arm/dts/socfpga.dtsi
> @@ -646,6 +646,7 @@
>   num-cs = <4>;
>   fifo-depth = <128>;
>   sram-size = <128>;
> + trigger-address = <0x>;

According to the documentation I see, the indaddrtrig on SoCFPGA is at
offset of 0x1C.

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


[U-Boot] [PATCHv2 3/3] lib: move hash CONFIG options to Kconfig

2017-03-01 Thread Tom Rini
From: Masahiro Yamada 

Commit 94e3c8c4fd7b ("crypto/fsl - Add progressive hashing support
using hardware acceleration.") created entries for CONFIG_SHA1,
CONFIG_SHA256, CONFIG_SHA_HW_ACCEL, and CONFIG_SHA_PROG_HW_ACCEL.
However, no defconfig has migrated to it.  Complete the move with
moveconfig tool.  In many cases we can select these because they are
required to implement other drivers.  We also correct how we include
the various hashing algorithms in SPL.

This commit was generated as follows:

[1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
[2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL

Note:
We cannot move SHA_HW_ACCEL and SHA_PROG_HW_ACCEL simultaneously
because there is dependency between them.

Cc: Poonam Aggrwal 
Cc: Naveen Burmi 
Cc: Po Liu 
Cc: Shengzhou Liu 
Cc: Priyanka Jain 
Cc: Shaohui Xie 
Cc: Chunhe Lan 
Cc: Chander Kashyap 
Cc: Steve Rae 
Cc: Dirk Eibach 
Cc: Feng Li 
Cc: Alison Wang 
Cc: Sumit Garg 
Cc: Mingkai Hu 
Cc: York Sun 
Cc: Prabhakar Kushwaha 
Cc: Jaehoon Chung 
Cc: Akshay Saraswat 
Cc: Simon Glass 
Cc: Heiko Schocher 
Cc: Jagan Teki 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Add a large number of select statements so that our overall delta
  is fairly small.  This is not size neutral but is I believe correct.
  We had a number of cases before where we did not enable hw assist in
  the hash command and only made use of it in certain back end locations.

 Kconfig  | 2 ++
 arch/arm/include/asm/fsl_secure_boot.h   | 2 --
 arch/powerpc/include/asm/fsl_secure_boot.h   | 1 -
 board/freescale/common/Kconfig   | 2 ++
 common/spl/Kconfig   | 4 
 configs/B4420QDS_NAND_defconfig  | 1 +
 configs/B4420QDS_SPIFLASH_defconfig  | 1 +
 configs/B4420QDS_defconfig   | 1 +
 configs/B4860QDS_NAND_defconfig  | 1 +
 configs/B4860QDS_SPIFLASH_defconfig  | 1 +
 configs/B4860QDS_SRIO_PCIE_BOOT_defconfig| 1 +
 configs/B4860QDS_defconfig   | 1 +
 configs/BSC9131RDB_NAND_SYSCLK100_defconfig  | 1 +
 configs/BSC9131RDB_NAND_defconfig| 1 +
 configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig  | 1 +
 configs/BSC9131RDB_SPIFLASH_defconfig| 1 +
 configs/BSC9132QDS_NAND_DDRCLK100_defconfig  | 1 +
 configs/BSC9132QDS_NAND_DDRCLK133_defconfig  | 1 +
 configs/BSC9132QDS_NOR_DDRCLK100_defconfig   | 1 +
 configs/BSC9132QDS_NOR_DDRCLK133_defconfig   | 1 +
 configs/BSC9132QDS_SDCARD_DDRCLK100_defconfig| 1 +
 configs/BSC9132QDS_SDCARD_DDRCLK133_defconfig| 1 +
 configs/BSC9132QDS_SPIFLASH_DDRCLK100_defconfig  | 1 +
 configs/BSC9132QDS_SPIFLASH_DDRCLK133_defconfig  | 1 +
 configs/C29XPCIE_NAND_defconfig  | 1 +
 configs/C29XPCIE_SPIFLASH_defconfig  | 1 +
 configs/C29XPCIE_defconfig   | 1 +
 configs/P1010RDB-PA_36BIT_NAND_defconfig | 1 +
 configs/P1010RDB-PA_36BIT_NOR_defconfig  | 1 +
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig   | 1 +
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 1 +
 configs/P1010RDB-PA_NAND_defconfig   | 1 +
 configs/P1010RDB-PA_NOR_defconfig| 1 +
 configs/P1010RDB-PA_SDCARD_defconfig | 1 +
 configs/P1010RDB-PA_SPIFLASH_defconfig   | 1 +
 configs/P1010RDB-PB_36BIT_NAND_defconfig | 1 +
 configs/P1010RDB-PB_36BIT_NOR_defconfig  | 1 +
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig   | 1 +
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 1 +
 configs/P1010RDB-PB_NAND_defconfig   | 1 +
 configs/P1010RDB-PB_NOR_defconfig| 1 +
 configs/P1010RDB-PB_SDCARD_defconfig | 1 +
 configs/P1010RDB-PB_SPIFLASH_defconfig   | 1 +
 configs/P2041RDB_NAND_defconfig  | 1 +
 configs/P2041RDB_SDCARD_defconfig| 1 +
 configs/P2041RDB_SPIFLASH_defconfig  | 1 +
 configs/P2041RDB_SRIO_PCIE_BOOT_defconfig| 1 +
 configs/P2041RDB_defconfig   | 1 +
 configs/P3041DS_NAND_defconfig   | 1 +
 configs/P3041DS_SDCARD_defconfig | 1 +
 configs/P3041DS_SPIFLASH_defconfig   | 1 +
 configs/P3041DS_SRIO_PCIE_BOOT_defconfig | 1 +
 configs/P3041DS_defconfig| 1 +
 configs/P4080DS_SDCARD_defconfig | 1 +
 configs/P4080DS_SPIFLASH_defconfig   | 1 +
 configs/P4080DS_SRIO_PCIE_BOOT_defconfig | 1 +
 configs/P4080DS_defconfig| 1 +
 configs/P5020DS_NAND_defconfig   | 1 +
 configs/P5020DS_SDCARD_defconfig | 1 +
 configs/

[U-Boot] [PATCHv2 2/3] FIT: Rename FIT_DISABLE_SHA256 to FIT_ENABLE_SHA256_SUPPORT

2017-03-01 Thread Tom Rini
We rename CONFIG_FIT_DISABLE_SHA256 to CONFIG_FIT_ENABLE_SHA256_SUPPORT which
is enabled by default and now a positive option.  Convert the handful of boards
that were disabling it before to save space.


Cc: Dirk Eibach 
Cc: Lukasz Dalek 
Signed-off-by: Tom Rini 
---
Changes in v2: New patch

 Kconfig| 13 +
 README |  9 -
 configs/dlvision-10g_defconfig |  1 +
 configs/dlvision_defconfig |  1 +
 configs/h2200_defconfig|  1 +
 configs/io_defconfig   |  1 +
 configs/iocon_defconfig|  1 +
 configs/neo_defconfig  |  1 +
 include/configs/dlvision-10g.h |  3 ---
 include/configs/dlvision.h |  3 ---
 include/configs/h2200.h|  1 -
 include/configs/io.h   |  3 ---
 include/configs/iocon.h|  3 ---
 include/configs/neo.h  |  3 ---
 include/image.h| 15 +--
 scripts/config_whitelist.txt   |  1 -
 16 files changed, 24 insertions(+), 36 deletions(-)

diff --git a/Kconfig b/Kconfig
index 81b4226..d565e7a 100644
--- a/Kconfig
+++ b/Kconfig
@@ -156,6 +156,19 @@ config FIT
 
 if FIT
 
+config FIT_ENABLE_SHA256_SUPPORT
+   bool "Support SHA256 checksum of FIT image contents"
+   default y
+   help
+ Enable this to support SHA256 checksum of FIT image contents. A
+ SHA256 checksum is a 256-bit (32-byte) hash value used to check that
+ the image contents have not been corrupted. SHA256 is recommended
+ for use in secure applications since (as at 2016) there is no known
+ feasible attack that could produce a 'collision' with differing
+ input data. Use this for the highest security. Note that only the
+ SHA256 variant is supported: SHA512 and others are not currently
+ supported in U-Boot.
+
 config FIT_SIGNATURE
bool "Enable signature verification of FIT uImages"
depends on DM
diff --git a/README b/README
index 4f0dbd4..daa39a5 100644
--- a/README
+++ b/README
@@ -3091,15 +3091,6 @@ FIT uImage format:
This define is introduced, as the legacy image format is
enabled per default for backward compatibility.
 
-- FIT image support:
-   CONFIG_FIT_DISABLE_SHA256
-   Supporting SHA256 hashes has quite an impact on binary size.
-   For constrained systems sha256 hash support can be disabled
-   with this option.
-
-   TODO(s...@chromium.org): Adjust this option to be positive,
-   and move it to Kconfig
-
 - Standalone program support:
CONFIG_STANDALONE_LOAD_ADDR
 
diff --git a/configs/dlvision-10g_defconfig b/configs/dlvision-10g_defconfig
index c3574e1..44f7527 100644
--- a/configs/dlvision-10g_defconfig
+++ b/configs/dlvision-10g_defconfig
@@ -3,6 +3,7 @@ CONFIG_IDENT_STRING=" dlvision-10g 0.06"
 CONFIG_4xx=y
 CONFIG_TARGET_DLVISION_10G=y
 CONFIG_FIT=y
+# CONFIG_FIT_ENABLE_SHA256_SUPPORT is not set
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTDELAY=5
diff --git a/configs/dlvision_defconfig b/configs/dlvision_defconfig
index f9f07ee..4dd09a2 100644
--- a/configs/dlvision_defconfig
+++ b/configs/dlvision_defconfig
@@ -3,6 +3,7 @@ CONFIG_IDENT_STRING=" dlvision 0.02"
 CONFIG_4xx=y
 CONFIG_TARGET_DLVISION=y
 CONFIG_FIT=y
+# CONFIG_FIT_ENABLE_SHA256_SUPPORT is not set
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTDELAY=5
diff --git a/configs/h2200_defconfig b/configs/h2200_defconfig
index b85ed59..9d3698c 100644
--- a/configs/h2200_defconfig
+++ b/configs/h2200_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_TARGET_H2200=y
 CONFIG_FIT=y
+# CONFIG_FIT_ENABLE_SHA256_SUPPORT is not set
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/configs/io_defconfig b/configs/io_defconfig
index 5dca2b1..27edc59 100644
--- a/configs/io_defconfig
+++ b/configs/io_defconfig
@@ -3,6 +3,7 @@ CONFIG_IDENT_STRING=" io 0.06"
 CONFIG_4xx=y
 CONFIG_TARGET_IO=y
 CONFIG_FIT=y
+# CONFIG_FIT_ENABLE_SHA256_SUPPORT is not set
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTDELAY=5
diff --git a/configs/iocon_defconfig b/configs/iocon_defconfig
index 211a734..6c62052 100644
--- a/configs/iocon_defconfig
+++ b/configs/iocon_defconfig
@@ -3,6 +3,7 @@ CONFIG_IDENT_STRING=" iocon 0.06"
 CONFIG_4xx=y
 CONFIG_TARGET_IOCON=y
 CONFIG_FIT=y
+# CONFIG_FIT_ENABLE_SHA256_SUPPORT is not set
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTDELAY=5
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
diff --git a/configs/neo_defconfig b/configs/neo_defconfig
index fbb2da4..1bf5151 100644
--- a/configs/neo_defconfig
+++ b/configs/neo_defconfig
@@ -3,6 +3,7 @@ CONFIG_IDENT_STRING=" neo 0.02"
 CONFIG_4xx=y
 CONFIG_TARGET_NEO=y
 CONFIG_FIT=y
+# CONFIG_FIT_ENABLE_SHA256_SUPPORT is not set
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTDELAY=5
diff --git a/include/configs/dlvision-10g.h b/include/configs/dlvision-10g.h
index 6b

[U-Boot] [PATCH v1] i2c: sunxi: add device-model support for i2c

2017-03-01 Thread Philipp Tomsich
The I2C block in sunxi (Allwinner SoCs) is based on Designware and uses
the same driver as the Marvell Orion 5x and Kirkwood families.

This change adds a compatible id matching the binding for sunxi
devices, supports configuring the clocks and to release the module
reset on sunxi platforms as directed by the device tree.

As we enable DT control of this driver, we need to make sure the
common config header (sunxi-common.h) does try to turn on support for
the legacy I2C support.

Signed-off-by: Philipp Tomsich 
---
 drivers/i2c/mvtwsi.c   | 42 ++
 include/configs/sunxi-common.h |  9 ++---
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 648a96e..475131b 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -16,6 +16,12 @@
 #ifdef CONFIG_DM_I2C
 #include 
 #endif
+#if defined(CONFIG_CLK)
+#include 
+#endif
+#if defined(CONFIG_DM_RESET)
+#include 
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -36,6 +42,12 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif
 #endif /* CONFIG_DM_I2C */
 
+/* On SUNXI, we get CONFIG_SYS_TCLK from this include, so we want to
+   always have it. */
+#if defined(CONFIG_DM_I2C) && defined(CONFIG_ARCH_SUNXI)
+#include 
+#endif
+
 /*
  * TWSI register structure
  */
@@ -81,6 +93,14 @@ struct mvtwsi_i2c_dev {
uint speed;
/* The current length of a clock period (depending on speed) */
uint tick;
+#if defined(CONFIG_DM_RESET)
+   bool reset_valid;
+   struct reset_ctl reset;
+#endif
+#if defined(CONFIG_CLK)
+   bool clk_gate_valid;
+   struct clk clk_gate;
+#endif
 };
 #endif /* CONFIG_DM_I2C */
 
@@ -781,6 +801,14 @@ static int mvtwsi_i2c_ofdata_to_platdata(struct udevice 
*bus)
   "u-boot,i2c-slave-addr", 0x0);
dev->speed = fdtdec_get_int(gd->fdt_blob, dev_of_offset(bus),
"clock-frequency", 10);
+#if defined(CONFIG_DM_RESET)
+   if (reset_get_by_index(bus, 0, &dev->reset) == 0)
+   dev->reset_valid = true;
+#endif
+#if defined(CONFIG_CLK)
+   if (clk_get_by_index(bus, 0, &dev->clk_gate) == 0)
+   dev->clk_gate_valid = true;
+#endif
return 0;
 }
 
@@ -789,6 +817,17 @@ static int mvtwsi_i2c_probe(struct udevice *bus)
struct mvtwsi_i2c_dev *dev = dev_get_priv(bus);
uint actual_speed;
 
+#if defined(CONFIG_DM_RESET)
+   /* Enable the controller */
+   if (dev->reset_valid)
+   reset_deassert(&dev->reset);
+#endif
+#if defined(CONFIG_CLK)
+   /* Open the clock-gate */
+   if (dev->clk_gate_valid)
+   clk_enable(&dev->clk_gate);
+#endif
+
__twsi_i2c_init(dev->base, dev->speed, dev->slaveadd, &actual_speed);
dev->speed = actual_speed;
dev->tick = calc_tick(dev->speed);
@@ -831,6 +870,9 @@ static const struct dm_i2c_ops mvtwsi_i2c_ops = {
 static const struct udevice_id mvtwsi_i2c_ids[] = {
{ .compatible = "marvell,mv64xxx-i2c", },
{ .compatible = "marvell,mv78230-i2c", },
+#if defined(CONFIG_ARCH_SUNXI)
+   { .compatible = "allwinner,sun6i-a31-i2c", },
+#endif
{ /* sentinel */ }
 };
 
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 4f566fa..aaab809 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -262,11 +262,14 @@
 defined CONFIG_SY8106A_POWER
 #endif
 
-#if defined CONFIG_I2C0_ENABLE || defined CONFIG_I2C1_ENABLE || \
-defined CONFIG_I2C2_ENABLE || defined CONFIG_I2C3_ENABLE || \
-defined CONFIG_I2C4_ENABLE || defined CONFIG_R_I2C_ENABLE
+#if !defined(CONFIG_DM_I2C) && \
+   (defined CONFIG_I2C0_ENABLE || defined CONFIG_I2C1_ENABLE ||\
+defined CONFIG_I2C2_ENABLE || defined CONFIG_I2C3_ENABLE ||\
+defined CONFIG_I2C4_ENABLE || defined CONFIG_R_I2C_ENABLE)
 #define CONFIG_SYS_I2C
+#if !defined(CONFIG_SYS_I2C_MVTWSI)
 #define CONFIG_SYS_I2C_MVTWSI
+#endif
 #define CONFIG_SYS_I2C_SPEED   40
 #define CONFIG_SYS_I2C_SLAVE   0x7f
 #endif
-- 
1.9.1

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


[U-Boot] [PATCH v2 2/2] sunxi_spi: add support for dual-IO flashes

2017-03-01 Thread Philipp Tomsich
The SPI controller in the Allwinner A64 SoC supports dual-IO for
the RX phase of transmission.  This can be used with the command
'fast read dual output' (cmd, addr and dummy byte are transmitted
in single-IO mode; data is received in dual-IO mode) to quickly
read out SPI flashes, when the device-tree marks the flash as
having 'spi-rx-bus-width = <2>'.

Unfortunately, the SPI-NOR flash layer in U-Boot does not manage
the single-IO and dual-IO transition (partially due to the fact
that spi_xfer(...) does not allow to convery such information),
but correctly chooses the FAST_READ_DUAL_OUTPUT (0x3b) opcode.
The net result of this is that a dual-IO read is initiated, but
the data reception will capture only every other bit...

This change puts a temporary fix in place, which identifies a
0x3b opcode being sent in a transaction with a SPI flash and then
manages the switching to dual-IO within the driver.

This change should be reverted, once more permanent solutions
in the higher layers and in the SPI driver model have been agreed
on and have been put in place.

Tested on an A64 (sun50iw1p1) against a Winbond W25Q80DV flash at
up to 100MHz (i.e. 200MBit/s read bursts).

X-AffectedPlatforms: A64-uQ7
Signed-off-by: Philipp Tomsich 
---
 drivers/spi/sunxi_spi.c | 68 -
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/sunxi_spi.c b/drivers/spi/sunxi_spi.c
index f26becf..871c88d 100644
--- a/drivers/spi/sunxi_spi.c
+++ b/drivers/spi/sunxi_spi.c
@@ -24,6 +24,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/* The SPI flash opcode for a FAST READ DUAL OUTPUT operation. */
+#define CMD_READ_DUAL_OUTPUT_FAST 0x3b
+
 struct sunxi_spi_platdata {
void *base;
unsigned int max_hz;
@@ -47,7 +50,13 @@ struct sunxi_spi_driverdata {
unsigned int  fifo_depth;
 };
 
+enum {
+   NONE = 0,
+   OPC_READ_DUAL_CMD,
+};
+
 struct sunxi_spi_privdata {
+   int  transaction_type;
ulong last_transaction_us;  /* Time of last transaction end */
unsigned int hz_requested;  /* last requested bitrate */
unsigned int hz_actual; /* currently set bitrate */
@@ -211,6 +220,43 @@ static inline uint8_t *spi_drain_readfifo(struct 
sunxi_spi_reg *spi,
return din;
 }
 
+static int sunxi_spi_trans_setup(struct sunxi_spi_privdata *priv,
+const uint8_t *dout,
+const uint8_t *din,
+unsigned int n_bytes)
+{
+   if (!dout) {
+   error("%s: SPI flash command requires at least an opcode\n",
+ __func__);
+   return -EPROTO;
+   }
+
+   /* Detect dual-IO read commands */
+   if (dout[0] == CMD_READ_DUAL_OUTPUT_FAST) {
+   /* This is always called as two xfer-requests from the
+* higher layers:
+*  1. a write-only request with the 1-byte opcode,
+* 4-byte address and a dummy byte
+*  2. a read-only for the requested amount of data
+*/
+
+   /* TODO: The "cmd, addr, dummy" sequence should be
+*   changed to "cmd, addr" w/ the controller
+*   generating the dummy cycles, so the Hi-Z
+*   state for IO0 and IO1 can already be
+*   generated during the dummy cycles.
+*/
+   priv->transaction_type = OPC_READ_DUAL_CMD;
+   }
+
+   return 0;
+}
+
+static void sunxi_spi_trans_end(struct sunxi_spi_privdata *priv)
+{
+   priv->transaction_type = NONE;
+}
+
 static int sunxi_spi_xfer(struct udevice *dev, unsigned int bitlen,
  const void *out, void *in, unsigned long flags)
 {
@@ -239,6 +285,18 @@ static int sunxi_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
  dev->name, __func__, spi, bitlen, din, flags, fifo_depth);
 
if (flags & SPI_XFER_BEGIN) {
+   /* For dual-IO support, we need to detect flash read
+* commands here... this is actually a layering
+* violation, but can't be fixed non-intrusively now
+* and other drivers (e.g. Freescale QSPI, Intel ICH)
+* follow this pattern as well.
+*/
+   if (device_get_uclass_id(dev) == UCLASS_SPI_FLASH) {
+   ret = sunxi_spi_trans_setup(priv, dout, din, n_bytes);
+   if (ret < 0)
+   return ret;
+   }
+
ret = sunxi_spi_cs_activate(dev, slave->cs);
if (ret < 0) {
error("%s: failed to activate chip-select %d\n",
@@ -263,6 +321,12 @@ static int sunxi_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
if (!din)
setbits_le32(&spi->TCR, TCR_DHB);
 
+   /* Set the dual-mode input bit */
+   if (priv->tran

[U-Boot] [PATCH v2 1/2] spi: sunxi_spi: Add DM SPI driver for A31/A80/A64

2017-03-01 Thread Philipp Tomsich
This adds a rewrite of the SPI driver we had in use for the A31-uQ7
(sun6i), A80-Q7 (sun9i) and A64-uQ7 (sun50i) boards, which includes
support for:
 * cs-gpios (i.e. GPIOs as additional chip-selects)
 * clocking, reset and pinctrl based on the device-model
 * dual-IO data receive for controllers that support it (sun50i)

The key difference to the earlier incarnation that we provided as part
of our BSP is the removal of the legacy reset and clocking code and
added resilience to configuration errors (i.e. timeouts for the inner
loops) and converstion to the device-model. This was possible due to a
non-device-model driver now being present for use with in the SPL.

This has been verified against the A64-uQ7 with data rates up to
100MHz and dual-IO ("Fast Read Dual Output" opcode) from the on-board
SPI-NOR flash.

Signed-off-by: Philipp Tomsich 
---
 drivers/spi/Kconfig |  14 ++
 drivers/spi/Makefile|   1 +
 drivers/spi/sunxi_spi.c | 516 
 3 files changed, 531 insertions(+)
 create mode 100644 drivers/spi/sunxi_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index f3f7dbe..64b6430 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -132,6 +132,20 @@ config STM32_QSPI
  used to access the SPI NOR flash chips on platforms embedding
  this ST IP core.
 
+config SUNXI_SPI
+   bool "Allwinner (sunxi) SPI driver"
+   help
+ Enable the SPI driver for Allwinner SoCs.
+
+ This driver can be used to access the SPI NOR flash on for
+ communciation with SPI peripherals platforms embedding the
+ Allwinner SoC.  This driver supports the device-model (only)
+ and has support for GPIOs as additional chip-selects.
+
+ For recent platforms (e.g. sun50i), dual-IO receive mode is
+ also supported, when configured for a SPI-NOR flash in the
+ device tree.
+
 config TEGRA114_SPI
bool "nVidia Tegra114 SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index fa9a1d2..aab31b4 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
 obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o
 obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
+obj-$(CONFIG_SUNXI_SPI) += sunxi_spi.o
 obj-$(CONFIG_SH_SPI) += sh_spi.o
 obj-$(CONFIG_SH_QSPI) += sh_qspi.o
 obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o
diff --git a/drivers/spi/sunxi_spi.c b/drivers/spi/sunxi_spi.c
new file mode 100644
index 000..f26becf
--- /dev/null
+++ b/drivers/spi/sunxi_spi.c
@@ -0,0 +1,516 @@
+/*
+ * SPI driver for Allwinner sunxi SoCs
+ *
+ * Copyright (C) 2015-2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * This program 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.
+ */
+
+#include 
+#ifdef CONFIG_DM_GPIO
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sunxi_spi_platdata {
+   void *base;
+   unsigned int max_hz;
+
+   struct reset_ctl reset_ctl;
+   struct clk ahb_clk_gate;
+   struct clk spi_clk;
+
+   /* We could do with a single delay counter, but it won't do harm
+  to have two, as the same is the case for most other driver. */
+   uint deactivate_delay_us;   /* Delay to wait after deactivate */
+   uint activate_delay_us; /* Delay to wait after activate */
+
+#if defined(CONFIG_DM_GPIO)
+   int cs_gpios_num;
+   struct gpio_desc *cs_gpios;
+#endif
+};
+
+struct sunxi_spi_driverdata {
+   unsigned int  fifo_depth;
+};
+
+struct sunxi_spi_privdata {
+   ulong last_transaction_us;  /* Time of last transaction end */
+   unsigned int hz_requested;  /* last requested bitrate */
+   unsigned int hz_actual; /* currently set bitrate */
+};
+
+struct sunxi_spi_reg {
+   u8  _rsvd[0x4];
+   u32 GCR;   /* SPI Global Control register */
+   u32 TCR;   /* SPI Transfer Control register */
+   u8  _rsvd1[0x4];
+   u32 IER;   /* SPI Interrupt Control register */
+   u32 ISR;   /* SPI Interrupt Status register */
+   u32 FCR;   /* SPI FIFO Control register */
+   u32 FSR;   /* SPI FIFO Status register */
+   u32 WCR;   /* SPI Wait Clock Counter register */
+   u32 CCR;   /* SPI Clock Rate Control register */
+   u8  _rsvd2[0x8];
+   u32 MBC;   /* SPI Burst Counter register */
+   u32 MTC;   /* SPI Transmit Counter register */
+   u32 BCC;   /* SPI Burst Control register */
+   u8  _rsvd3[0x4c];
+   u32 NDMA_MODE_CTL;
+   u8  _rsvd4[0x174];
+   u32 TXD;   /* SPI TX Data register 

[U-Boot] [PATCH v2 0/2] sunxi: DM-based driver for SPI

2017-03-01 Thread Philipp Tomsich
A new iteration of the dual-IO aware device-model based SPI driver
for sunxi (Allwinner SoCs).

As before, this has been tested with dual-IO flashes (Winbond
W25Q80DV) on our A64-uQ7 at up to 100MHz.

Changes in v2:
 * Uses wait_bit instead of readl_poll_... for better readability
 * To address Jagan's concerns regarding the layering violation from
   detecting SPI-NOR transactions and parsing the command-byte to
   detect dual-IO reads, I split this off into a separate patch (to
   make it easier to revert, once the SPI flash subsystem is able to
   handle this for us)---see the commit message for even more info.


Philipp Tomsich (2):
  spi: sunxi_spi: Add DM SPI driver for A31/A80/A64
  sunxi_spi: add support for dual-IO flashes

 drivers/spi/Kconfig |  14 ++
 drivers/spi/Makefile|   1 +
 drivers/spi/sunxi_spi.c | 582 
 3 files changed, 597 insertions(+)
 create mode 100644 drivers/spi/sunxi_spi.c

-- 
1.9.1

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


Re: [U-Boot] [PATCH 1/2 RFT] sunxi: power: Add AXP806 and AXP808 support

2017-03-01 Thread Rask Ingemann Lambertsen
On Mon, Feb 27, 2017 at 11:26:33AM +0800, Chen-Yu Tsai wrote:
> On Mon, Feb 27, 2017 at 3:01 AM, Rask Ingemann Lambertsen
>  wrote:
> > An X-Powers AXP806 or AXP808 PMIC is usually found on boards using the
> > Allwinner A80 ARM SoC. This patch adds support for the PMIC's regulators
> > and sets up the runtime address and master/slave mode in pmic_bus_init().
> >
> > AXP806/AXP808 support is enabled by default on all MACH_SUN9I boards.
> >
> > Because there are boards with both an AXP806 and an AXP809,
> > drivers/power/Kconfig and arch/arm/mach-sunxi/pmic_bus.c are changed to
> > make it possible to have more than one PMIC enabled at a time.
> >
> > Signed-off-by: Rask Ingemann Lambertsen 
> > ---
> > This patch needs to be tested on the following boards which I don't have:
> > Cubietech Cubieboard4
> > Merrii A80 Optimus
[...]
> > diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
> > index 7c57f02..a2da40c 100644
> > --- a/arch/arm/mach-sunxi/pmic_bus.c
> > +++ b/arch/arm/mach-sunxi/pmic_bus.c
[...]
> > +#ifdef CONFIG_AXP806_POWER
> > +int pmic2_bus_read(u8 reg, u8 *data)
> >  {
> > -   int ret;
> > -   u8 val;
> > -
> > -   ret = pmic_bus_read(reg, &val);
> > -   if (ret)
> > -   return ret;
> > -
> > -   val &= ~bits;
> > -   return pmic_bus_write(reg, val);
> > +   return rsb_read(AXP806_RUNTIME_ADDR, reg, data);
> >  }
> > +
> > +int pmic2_bus_write(u8 reg, u8 data)
> > +{
> > +   return rsb_write(AXP806_RUNTIME_ADDR, reg, data);
> > +}
> > +
> > +int pmic2_bus_setbits(u8 reg, u8 bits)
> > +PMIC_BUS_SETBITS(pmic2_bus_read, pmic2_bus_write, reg, bits)
> > +
> > +int pmic2_bus_clrbits(u8 reg, u8 bits)
> > +PMIC_BUS_CLRBITS(pmic2_bus_read, pmic2_bus_write, reg, bits)
> > +#endif
> 
> Please split the pmic_bus changes into separate patches, such as the 
> following:
> 
>   - Pull out PMIC_BUS_*. However please don't use macros. Just make some
> static functions. The compiler can choose to inline them.
> 
>   - Add AXP806 support in master mode
> 
>   - Add support for second PMIC to pmic_bus
> 
>   - Add AXP806 slave mode support.

OK. I'll take care to not leave a broken state between individual patches.

> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index 5365638..7847837 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -540,6 +540,26 @@ void sunxi_board_init(void)
> > power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
> >  #endif
> >  #endif
> > +#ifdef CONFIG_AXP806_POWER
> > +   power_failed |= axp2_init();
> > +
> > +   power_failed |= axp_set_dcdca(CONFIG_AXP_DCDCA_VOLT);
> > +   power_failed |= axp_set_dcdcb(CONFIG_AXP_DCDCB_VOLT);
> > +   power_failed |= axp_set_dcdcc(CONFIG_AXP_DCDCC_VOLT);
> > +   power_failed |= axp_set_dcdcd(CONFIG_AXP_DCDCD_VOLT);
> > +   power_failed |= axp_set_dcdce(CONFIG_AXP_DCDCE_VOLT);
> > +   power_failed |= axp2_set_aldo(1, CONFIG_AXP2_ALDO1_VOLT);
> > +   power_failed |= axp2_set_aldo(2, CONFIG_AXP2_ALDO2_VOLT);
> > +   power_failed |= axp2_set_aldo(3, CONFIG_AXP2_ALDO3_VOLT);
> 
> Allwinner code calls them s_aldo.

OK.

> > +   power_failed |= axp2_set_sw(IS_ENABLED(CONFIG_AXP2_SW_ON));
> 
> And this s_sw.

OK.

> > diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> > index f2c5629..aa32e5a 100644
> > --- a/drivers/power/Kconfig
> > +++ b/drivers/power/Kconfig
> > @@ -6,19 +6,18 @@ source "drivers/power/pmic/Kconfig"
> >
> >  source "drivers/power/regulator/Kconfig"
> >
> > -choice
> > -   prompt "Select Sunxi PMIC Variant"
> > -   depends on ARCH_SUNXI
> > -   default AXP209_POWER if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
> > -   default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || 
> > MACH_SUN8I_A33
> > -   default AXP818_POWER if MACH_SUN8I_A83T
> > -   default SUNXI_NO_PMIC if MACH_SUN8I_H3 || MACH_SUN50I
> > +if ARCH_SUNXI
> > +
> > +comment "Select Sunxi PMIC Variant"
> 
> Would this change break existing defconfigs?

It was fine with the six or so that I checked, but that's just 0.5 % of the
defconfigs. It might actually be feasible to check them all, so I'll try
that.

> > @@ -141,6 +164,63 @@ config AXP_DCDC5_VOLT
> > On A23 / A31 / A33 / A80 / A83T boards dcdc5 is VCC-DRAM and
> > should be 1.5V, 1.35V if DDR3L is used.
> >
> > +config AXP_DCDCA_VOLT
> > +   int "axp pmic dcdca voltage"
> > +   depends on AXP806_POWER
> > +   default 900 if MACH_SUN9I
> > +   ---help---
> > +   Set the voltage (mV) to program the axp pmic dcdca at, set to 0 to
> > +   disable dcdca.
> > +   On the Cubietech Cubieboard4 and Merrii A80 Optimus boards, dcdca
> > +   powers the Cortex-A15 cores (VDD-CPUB) and should be 0.9 V.
> > +   On the Sunchip CX-A99 board, dcdca powers the Cortex-A7 cores
> > +   (VDD-CPUA) and should be 0.9 V at the default 1008 MHz clock 
> > frequency.
> 
> Don't mention board names. Inst

[U-Boot] [PATCH v3 9/9] cmd: move CONFIG_CMD_CLK to Kconfig

2017-03-01 Thread Philipp Tomsich
The CMD_CLK configuration allows the clk-command today (having only
the 'clk dump' action for printing the clock configuration using a
per-SoC weak function).

It is currently only selected by ZYNC and PIC32. To make it easier
to use this command for other platforms and to select it via defconfig,
we are moving it into Kconfig.

Given that this is a debug/maintainer command, the default was chosen
as 'n' and thus should cause no warning messages to board that still
enable it in their respective header files.

Signed-off-by: Philipp Tomsich 
---
 cmd/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index ef53156..119a600 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -144,6 +144,16 @@ config CMD_CONSOLE
help
  Print console devices and information.
 
+config CMD_CLK
+bool "clk"
+   default n
+   help
+ Print information about clocks.
+
+ This normally shows a list of clocks and their current
+ configuration.  The implementation and details of the output
+ are manufacturer specific.
+
 config CMD_CPU
bool "cpu"
help
-- 
1.9.1

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


[U-Boot] [PATCH v3 0/9] sunxi: DM-based CLK, RESET and PINCTRL

2017-03-01 Thread Philipp Tomsich
Hi everyone,

here's the the new version of CLK, RESET and PINCTRL drivers to
configure sunxi from the device-tree.  This adds support for the
upstream CCU node (for reset and pinctrl) and tries to address the
various concerns people had.

Note that (to stay in sync with the Linux files), some of the
patches may not fully adhere to the style (e.g. some of the code
reused verbatim from Linux and in the config tables).

This has been tested with Ethernet, I2C, SPI and MMC on the A64-uQ7.
See my separate patchsets for the conversion of these drivers over
to support DM-based CLK, RESET and PINCTRL configuration.

Changes is v3:
 * add support for the 'new-style' clock subsystem (CCU) by porting
   from Linux and adding the necessary glue implementation
   - add a CCU reset-driver (in addition to the legacy driver, which
 will still be required for the R_* device nodes), which reuses
 the reset-table from ccu-.c
   - add a clk-sunxi-ccu.c implementation based on Linux and reusing
 both the low-level clock implementation (ccu_*.h) and the config
 table (ccu-.c) from Linux
 * reuse the 'allwinner,pinctrl.txt' documentation for the pinctrl
   binding from Linux
 * adds the includes for the CCU dt-bindings from Linux
 * adds support for printing the CCU subsystem via 'clk dump'


Philipp Tomsich (9):
  sunxi: add pinctrl (UCLASS_PINCTRL) support for sunxi
  dm: core: Allow multiple drivers to bind for a single node
  sunxi: CONFIG_DM_ALLOW_MULTIPLE_DRIVERS for gpio/pinctrl binding
  Kconfig: sunxi: Select new option for allow multiple drivers to bind
  sunxi: add module reset (UCLASS_RESET) support for sunxi
  linux/kernel.h: sync DIV_ROUND_UP_ULL from kernel
  clk: clk-uclass: add clk_get_by_output_name
  sunxi: add clock driver (UCLASS_CLK) support for sunxi
  cmd: move CONFIG_CMD_CLK to Kconfig

 arch/arm/Kconfig   |   1 +
 arch/arm/include/asm/arch-sunxi/gpio-internal.h|  19 +
 cmd/Kconfig|  10 +
 .../pinctrl/allwinner,pinctrl.txt  | 142 
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-uclass.c   |  30 +
 drivers/clk/sunxi/Makefile |  30 +
 drivers/clk/sunxi/ccu-compatibility.h  | 232 ++
 drivers/clk/sunxi/ccu-runtime-divider.c| 115 +++
 drivers/clk/sunxi/ccu-runtime-fixedfactor.c|  17 +
 drivers/clk/sunxi/ccu-sun50i-a64.c | 810 +
 drivers/clk/sunxi/ccu-sun50i-a64.h |  64 ++
 drivers/clk/sunxi/ccu_common.c |  27 +
 drivers/clk/sunxi/ccu_common.h |  67 ++
 drivers/clk/sunxi/ccu_div.c| 134 
 drivers/clk/sunxi/ccu_div.h| 170 +
 drivers/clk/sunxi/ccu_frac.c   | 106 +++
 drivers/clk/sunxi/ccu_frac.h   |  46 ++
 drivers/clk/sunxi/ccu_gate.c   |  80 ++
 drivers/clk/sunxi/ccu_gate.h   |  45 ++
 drivers/clk/sunxi/ccu_mp.c | 159 
 drivers/clk/sunxi/ccu_mp.h |  70 ++
 drivers/clk/sunxi/ccu_mult.h   |  39 +
 drivers/clk/sunxi/ccu_mux.c| 201 +
 drivers/clk/sunxi/ccu_mux.h| 105 +++
 drivers/clk/sunxi/ccu_nk.c | 154 
 drivers/clk/sunxi/ccu_nk.h |  64 ++
 drivers/clk/sunxi/ccu_nkm.c| 184 +
 drivers/clk/sunxi/ccu_nkm.h|  84 +++
 drivers/clk/sunxi/ccu_nkmp.c   | 171 +
 drivers/clk/sunxi/ccu_nkmp.h   |  64 ++
 drivers/clk/sunxi/ccu_nm.c | 148 
 drivers/clk/sunxi/ccu_nm.h |  84 +++
 drivers/clk/sunxi/clk-sunxi-ccu.c  | 550 ++
 drivers/clk/sunxi/clk-sunxi-gate.c |  92 +++
 drivers/clk/sunxi/clk-sunxi-mod.c  | 241 ++
 drivers/core/Kconfig   |  14 +
 drivers/core/lists.c   |  12 +-
 drivers/gpio/sunxi_gpio.c  |  15 +-
 drivers/pinctrl/Kconfig|  10 +
 drivers/pinctrl/Makefile   |   2 +
 drivers/pinctrl/sunxi/Makefile |  10 +
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c   |  92 +++
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c | 577 +++
 drivers/pinctrl/sunxi/pinctrl-sunxi.c  | 355 +
 drivers/pinctrl/sunxi/pinctrl-sunxi.h  | 311 
 drivers/reset/Kconfig  |   9 +
 drivers/reset/Makefile |   1 +
 drivers/reset/sunxi/Makefile   |   6 +
 drivers/reset/sunxi/ccu-sun50i-a64.c   |  75 ++
 drivers/reset/sunxi/ccu_reset.h  

[U-Boot] [PATCH v3 6/9] linux/kernel.h: sync DIV_ROUND_UP_ULL from kernel

2017-03-01 Thread Philipp Tomsich
The DIV_ROUND_UP_ULL is required for porting the sunxi clock (CCU)
binding from linux.
---
 include/linux/kernel.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 0b61671..dc3f36a 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -56,6 +56,8 @@
 
 #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
 #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+#define DIV_ROUND_UP_ULL(ll,d) \
+   ({ unsigned long long _tmp = (ll)+(d)-1; do_div(_tmp, d); _tmp; })
 
 #if BITS_PER_LONG == 32
 # define DIV_ROUND_UP_SECTOR_T(ll,d) DIV_ROUND_UP_ULL(ll, d)
-- 
1.9.1

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


[U-Boot] [PATCH v3 7/9] clk: clk-uclass: add clk_get_by_output_name

2017-03-01 Thread Philipp Tomsich
Signed-off-by: Philipp Tomsich 
---
 drivers/clk/clk-uclass.c | 30 ++
 include/clk.h| 22 ++
 2 files changed, 52 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 6fcfd69..a6a65b2 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -113,6 +114,35 @@ int clk_get_by_name(struct udevice *dev, const char *name, 
struct clk *clk)
 
return clk_get_by_index(dev, index, clk);
 }
+
+int clk_get_by_output_name(const char *output_name, struct clk *clk)
+{
+   struct udevice *dev;
+   int idx;
+   int ret;
+
+   debug("%s(output=%s, clk==%p)\n", __func__, output_name, clk);
+
+   /* Try to find the clock among the already registered devices */
+   for (ret = uclass_find_first_device(UCLASS_CLK, &dev); dev;
+ret = uclass_find_next_device(&dev)) {
+   if (ret)
+   continue;
+
+   idx = fdt_stringlist_search(gd->fdt_blob,
+   dev_of_offset(dev),
+   "clock-output-names",
+   output_name);
+   if (idx < 0)
+   continue;
+
+   clk->dev = dev;
+   clk->id = idx;
+   return idx;
+   }
+
+   return -ENOENT;
+}
 #endif /* OF_CONTROL */
 
 int clk_request(struct udevice *dev, struct clk *clk)
diff --git a/include/clk.h b/include/clk.h
index 5a5c2ff..d12b896 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -98,6 +98,22 @@ int clk_get_by_index(struct udevice *dev, int index, struct 
clk *clk);
  * @return 0 if OK, or a negative error code.
  */
 int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk);
+
+/**
+ * clk_get_by_output_name - Get a clock by its output name
+ *
+ * This looks up a clock from the bound clock-devices. The output_name
+ * is a string that should be present in the 'clock-output-names' list
+ * of one of those clocks.
+ *
+ * @output_name: A name contained in the output-name list of the node
+ *   associated with the target node.
+ * @clk: A pointer to a clock structure to initialize.
+ * @return the index (of the name in the output-name list) if found, or
+ * a negative error code.
+ */
+
+int clk_get_by_output_name(const char *output_name, struct clk *clk);
 #else
 static inline int clk_get_by_index(struct udevice *dev, int index,
   struct clk *clk)
@@ -110,6 +126,12 @@ static inline int clk_get_by_name(struct udevice *dev, 
const char *name,
 {
return -ENOSYS;
 }
+
+static inline int clk_get_by_output_name(const char *output_name,
+struct clk *clk)
+{
+   return -ENOSYS;
+}
 #endif
 
 /**
-- 
1.9.1

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


[U-Boot] [PATCH v3 2/9] dm: core: Allow multiple drivers to bind for a single node

2017-03-01 Thread Philipp Tomsich
Currently, driver binding stops once it encounters the first
compatible driver that doesn't refuse to bind. However, there are
cases where a single node will need to be handled by multiple driver
classes. For those cases we provide a configurable option to continue
to bind after the first driver has been found.

The first use cases for this are from the DM conversion of the sunxi
(Allwinner) architecture:
 * pinctrl (UCLASS_PINCTRL) and gpio (UCLASS_GPIO) drivers need to
   bind against a single node
 * clock (UCLASS_CLK) and reset (UCLASS_RESET) drivers also need to
   bind against a single node

Signed-off-by: Philipp Tomsich 
---
 drivers/core/Kconfig | 14 ++
 drivers/core/lists.c | 12 +++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 8749561..913101c 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -31,6 +31,20 @@ config DM_WARN
  This will cause dm_warn() to be compiled out - it will do nothing
  when called.
 
+config DM_ALLOW_MULTIPLE_DRIVERS
+bool "Allow multiple drivers to bind for one node"
+   depends on DM
+   default n
+   help
+ The driver model in U-Boot originally did not allow multiple
+ drivers to bind for a single device node.
+
+ If enabled, multiple drivers can now bind for a single node
+ by using the same compatible string for matching: lists_bind_fdt()
+ will assume that binding multiple drivers is desirable, if the
+ caller does not request the pointer to the udevice structure to
+ be returned (i.e. if devp is NULL).
+
 config DM_DEVICE_REMOVE
bool "Support device removal"
depends on DM
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 23b6ba7..9124693 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -166,7 +166,11 @@ int lists_bind_fdt(struct udevice *parent, const void 
*blob, int offset,
dm_dbg("   - attempt to match compatible string '%s'\n",
   compat);
 
-   for (entry = driver; entry != driver + n_ents; entry++) {
+   entry = driver;
+#if defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
+allow_more_matches:
+#endif
+   for (; entry != driver + n_ents; entry++) {
ret = driver_check_compatible(entry->of_match, &id,
  compat);
if (!ret)
@@ -190,6 +194,12 @@ int lists_bind_fdt(struct udevice *parent, const void 
*blob, int offset,
found = true;
if (devp)
*devp = dev;
+#if defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
+   else {
+   entry++;
+   goto allow_more_matches;
+   }
+#endif
}
break;
}
-- 
1.9.1

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


[U-Boot] [PATCH v3 5/9] sunxi: add module reset (UCLASS_RESET) support for sunxi

2017-03-01 Thread Philipp Tomsich
In order to have the device model describe the module reset bits
on sunxi (well, at least for anything newer than sun6i), we need
a (rather simple) driver for 'allwinner,sun6i-a31-clock-reset'
nodes.

Signed-off-by: Philipp Tomsich 
---
 drivers/reset/Kconfig  |   9 ++
 drivers/reset/Makefile |   1 +
 drivers/reset/sunxi/Makefile   |   6 ++
 drivers/reset/sunxi/ccu-sun50i-a64.c   |  75 +
 drivers/reset/sunxi/ccu_reset.h|   9 ++
 drivers/reset/sunxi/reset-sunxi.c  | 168 +
 include/dt-bindings/reset/sun50i-a64-ccu.h |  98 +
 7 files changed, 366 insertions(+)
 create mode 100644 drivers/reset/sunxi/Makefile
 create mode 100644 drivers/reset/sunxi/ccu-sun50i-a64.c
 create mode 100644 drivers/reset/sunxi/ccu_reset.h
 create mode 100644 drivers/reset/sunxi/reset-sunxi.c
 create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c42b0bc..8db25fc 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -43,4 +43,13 @@ config RESET_UNIPHIER
  Say Y if you want to control reset signals provided by System Control
  block, Media I/O block, Peripheral Block.
 
+config RESET_SUNXI
+bool "Reset controller driver for Allwiner SoCs"
+   depends on DM_RESET && ARCH_SUNXI
+   default y
+   help
+ Support for reset controllers on Allwinner SoCs.
+ Say Y if you want to control reset signals provided by CCU (e.g. 
sun50i)
+ or PRCM (e.g. sun6i, sun9i) blocks.
+
 endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 5c4305c..a4994e9 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_SANDBOX_MBOX) += sandbox-reset-test.o
 obj-$(CONFIG_TEGRA_CAR_RESET) += tegra-car-reset.o
 obj-$(CONFIG_TEGRA186_RESET) += tegra186-reset.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
+obj-$(CONFIG_RESET_SUNXI) += sunxi/
diff --git a/drivers/reset/sunxi/Makefile b/drivers/reset/sunxi/Makefile
new file mode 100644
index 000..559c79a
--- /dev/null
+++ b/drivers/reset/sunxi/Makefile
@@ -0,0 +1,6 @@
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += reset-sunxi.o
+obj-$(CONFIG_MACH_SUN50I) += ccu-sun50i-a64.o
\ No newline at end of file
diff --git a/drivers/reset/sunxi/ccu-sun50i-a64.c 
b/drivers/reset/sunxi/ccu-sun50i-a64.c
new file mode 100644
index 000..f7c388e
--- /dev/null
+++ b/drivers/reset/sunxi/ccu-sun50i-a64.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * The tabular data contained in this file is reused verbatim from
+ * Linux (drivers/clk/sunxi-ng.c), which is:
+ *   Copyright (c) 2016 Maxime Ripard. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+
+#include 
+#include 
+
+#include "ccu_reset.h"
+
+const struct ccu_reset_map sun50i_a64_ccu_resets[] = {
+   [RST_USB_PHY0]  =  { 0x0cc, BIT(0) },
+   [RST_USB_PHY1]  =  { 0x0cc, BIT(1) },
+   [RST_USB_HSIC]  =  { 0x0cc, BIT(2) },
+
+   [RST_DRAM]  =  { 0x0f4, BIT(31) },
+   [RST_MBUS]  =  { 0x0fc, BIT(31) },
+
+   [RST_BUS_MIPI_DSI]  =  { 0x2c0, BIT(1) },
+   [RST_BUS_CE]=  { 0x2c0, BIT(5) },
+   [RST_BUS_DMA]   =  { 0x2c0, BIT(6) },
+   [RST_BUS_MMC0]  =  { 0x2c0, BIT(8) },
+   [RST_BUS_MMC1]  =  { 0x2c0, BIT(9) },
+   [RST_BUS_MMC2]  =  { 0x2c0, BIT(10) },
+   [RST_BUS_NAND]  =  { 0x2c0, BIT(13) },
+   [RST_BUS_DRAM]  =  { 0x2c0, BIT(14) },
+   [RST_BUS_EMAC]  =  { 0x2c0, BIT(17) },
+   [RST_BUS_TS]=  { 0x2c0, BIT(18) },
+   [RST_BUS_HSTIMER]   =  { 0x2c0, BIT(19) },
+   [RST_BUS_SPI0]  =  { 0x2c0, BIT(20) },
+   [RST_BUS_SPI1]  =  { 0x2c0, BIT(21) },
+   [RST_BUS_OTG]   =  { 0x2c0, BIT(23) },
+   [RST_BUS_EHCI0] =  { 0x2c0, BIT(24) },
+   [RST_BUS_EHCI1] =  { 0x2c0, BIT(25) },
+   [RST_BUS_OHCI0] =  { 0x2c0, BIT(28) },
+   [RST_BUS_OHCI1] =  { 0x2c0, BIT(29) },
+
+   [RST_BUS_VE]=  { 0x2c4, BIT(0) },
+   [RST_BUS_TCON0] =  { 0x2c4, BIT(3) },
+   [RST_BUS_TCON1] =  { 0x2c4, BIT(4) },
+   [RST_BUS_DEINTERLACE]   =  { 0x2c4, BIT(5) },
+   [RST_BUS_CSI]   =  { 0x2c4, BIT(8) },
+   [RST_BUS_HDMI0] =  { 0x2c4, BIT(10) },
+   [RST_BUS_HDMI1] =  { 0x2c4, BIT(11) },
+   [RST_BUS_DE]=  { 0x2c4, BIT(12) },
+   [RST_BUS_GPU]   =  { 0x2c4, BIT(20) },
+   [RST_BUS_MSGBOX]=  { 0x2c4, BIT(21) },
+   [RST_BUS_SPINLOCK]  =  { 0x2c4, BIT(22) },
+   [RST_BUS_DBG]   =  { 0x2c4, BIT(31) },
+
+   [RST_BUS_LVDS]  =  { 0x2c8, BIT(0) },
+
+   [RST_BUS_CODEC]   

[U-Boot] [PATCH v3 4/9] Kconfig: sunxi: Select new option for allow multiple drivers to bind

2017-03-01 Thread Philipp Tomsich
For pinctrl & gpio and reset & clk, the sunxi (Allwinner SoC) board
support needs to bind multiple drivers to a single DT node.  Select
the necessary config-option when selecting ARCH_SUNXI.

Signed-off-by: Philipp Tomsich 
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0229800..c62d61b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -644,6 +644,7 @@ config ARCH_SUNXI
select CMD_MMC if MMC
select CMD_USB if DISTRO_DEFAULTS
select DM
+   select DM_ALLOW_MULTIPLE_DRIVERS
select DM_ETH
select DM_GPIO
select DM_KEYBOARD
-- 
1.9.1

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


[U-Boot] [PATCH v3 3/9] sunxi: CONFIG_DM_ALLOW_MULTIPLE_DRIVERS for gpio/pinctrl binding

2017-03-01 Thread Philipp Tomsich
Our gpio and pinctrl driver need to be bound against the same
node. While this can be done by hand (i.e. explicitly looking up the
driver, creating the driver-data and binding the device), it is much
easier done when the new option for the binding of multiple drivers
against a single node is configured.

Signed-off-by: Philipp Tomsich 
---
 drivers/gpio/sunxi_gpio.c | 4 ++--
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 8 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index fd0c1ac..cbec1b9 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -349,7 +349,7 @@ static const struct udevice_id sunxi_gpio_ids[] = {
ID("allwinner,sun8i-a83t-pinctrl",  a_all),
ID("allwinner,sun8i-h3-pinctrl",a_all),
ID("allwinner,sun9i-a80-pinctrl",   a_all),
-#if !defined(CONFIG_SUNXI_PINCTRL)
+#if !defined(CONFIG_SUNXI_PINCTRL) || defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
/* This is not strictly correct for the A64, as it is missing
 * bank 'A'. Yet, the register layout in the pinctrl block is
 * backward compatible and any accesses to the registers that
@@ -362,7 +362,7 @@ static const struct udevice_id sunxi_gpio_ids[] = {
ID("allwinner,sun8i-a83t-r-pinctrl",l_1),
ID("allwinner,sun8i-h3-r-pinctrl",  l_1),
ID("allwinner,sun9i-a80-r-pinctrl", l_3),
-#if !defined(CONFIG_SUNXI_PINCTRL)
+#if !defined(CONFIG_SUNXI_PINCTRL) || defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
ID("allwinner,sun50i-a64-r-pinctrl",l_1),
 #endif
{ }
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 1e659fc..dc1a1f7 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -16,7 +16,9 @@
 #include 
 #include 
 #include 
+#if defined(CONFIG_DM_GPIO) && !defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -29,7 +31,7 @@ DECLARE_GLOBAL_DATA_PTR;
 
 struct sunxi_pctrl_priv {
void *base;
-#if defined(CONFIG_DM_GPIO)
+#if defined(CONFIG_DM_GPIO) && !defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
struct sunxi_gpio_soc_data gpio_soc_data;
struct udevice *gpio_dev;
 #endif
@@ -251,6 +253,7 @@ static int sunxi_pctrl_set_state(struct udevice *dev, 
struct udevice *config)
return 0;
 }
 
+#if defined(CONFIG_DM_GPIO) && !defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
 static inline void soc_data_from_desc(const struct sunxi_pinctrl_desc *data,
  struct sunxi_gpio_soc_data *soc_data)
 {
@@ -270,10 +273,11 @@ static inline void soc_data_from_desc(const struct 
sunxi_pinctrl_desc *data,
soc_data->start = low;
soc_data->no_banks = high - low + 1;
 }
+#endif
 
 static int sunxi_pctrl_bind_gpio(struct udevice *dev)
 {
-#if defined(CONFIG_DM_GPIO)
+#if defined(CONFIG_DM_GPIO) && !defined(CONFIG_DM_ALLOW_MULTIPLE_DRIVERS)
struct sunxi_pctrl_priv *priv = dev_get_priv(dev);
const struct sunxi_pinctrl_desc *data =
(struct sunxi_pinctrl_desc *)dev_get_driver_data(dev);
-- 
1.9.1

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


[U-Boot] [PATCH v3 1/9] sunxi: add pinctrl (UCLASS_PINCTRL) support for sunxi

2017-03-01 Thread Philipp Tomsich
This change adds a full device-model pinctrl driver for sunxi (tested with
sun50iw1p1) based on the support available in Linux.

Details are:
 * implements a driver for pinctrl devices and assigns sun50i-a64-pinctrl
   and sun50i-a64-r-pinctrl to it
 * dynamically creates the driver_data for a sunxi_gpio (see sunxi_gpio.c)
   driver and binds it to the same device-tree node
 * lifts and reuses the pinctrl-sunxi.h and pinctrl-sun50i-a64.c files from
   Linux (thanks to Maxime and Andre) and adds a pinctrl-sun50i-a64-r.c (to
   be picked up for inclusion into Linux again)

Signed-off-by: Philipp Tomsich 
---
 arch/arm/include/asm/arch-sunxi/gpio-internal.h|  19 +
 .../pinctrl/allwinner,pinctrl.txt  | 142 +
 drivers/gpio/sunxi_gpio.c  |  15 +-
 drivers/pinctrl/Kconfig|  10 +
 drivers/pinctrl/Makefile   |   2 +
 drivers/pinctrl/sunxi/Makefile |  10 +
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c   |  92 
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c | 577 +
 drivers/pinctrl/sunxi/pinctrl-sunxi.c  | 351 +
 drivers/pinctrl/sunxi/pinctrl-sunxi.h  | 311 +++
 10 files changed, 1522 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/gpio-internal.h
 create mode 100644 doc/device-tree-bindings/pinctrl/allwinner,pinctrl.txt
 create mode 100644 drivers/pinctrl/sunxi/Makefile
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sunxi.c
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sunxi.h

diff --git a/arch/arm/include/asm/arch-sunxi/gpio-internal.h 
b/arch/arm/include/asm/arch-sunxi/gpio-internal.h
new file mode 100644
index 000..4dcdd34
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/gpio-internal.h
@@ -0,0 +1,19 @@
+/*
+ * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+
+#ifndef _SUNXI_GPIO_INTERNAL_H
+#define _SUNXI_GPIO_INTERNAL_H
+
+/* This data structure is shared between the sunxi_gpio driver and
+ * the sunxi_pinctrl driver.
+ */
+struct sunxi_gpio_soc_data {
+   int start;
+   int no_banks;
+};
+
+#endif
diff --git a/doc/device-tree-bindings/pinctrl/allwinner,pinctrl.txt 
b/doc/device-tree-bindings/pinctrl/allwinner,pinctrl.txt
new file mode 100644
index 000..de1378b
--- /dev/null
+++ b/doc/device-tree-bindings/pinctrl/allwinner,pinctrl.txt
@@ -0,0 +1,142 @@
+* Allwinner A1X Pin Controller
+
+The pins controlled by sunXi pin controller are organized in banks,
+each bank has 32 pins.  Each pin has 7 multiplexing functions, with
+the first two functions being GPIO in and out. The configuration on
+the pins includes drive strength and pull-up.
+
+Required properties:
+- compatible: Should be one of the followings (depending on you SoC):
+  "allwinner,sun4i-a10-pinctrl"
+  "allwinner,sun5i-a10s-pinctrl"
+  "allwinner,sun5i-a13-pinctrl"
+  "allwinner,sun6i-a31-pinctrl"
+  "allwinner,sun6i-a31s-pinctrl"
+  "allwinner,sun6i-a31-r-pinctrl"
+  "allwinner,sun7i-a20-pinctrl"
+  "allwinner,sun8i-a23-pinctrl"
+  "allwinner,sun8i-a23-r-pinctrl"
+  "allwinner,sun8i-a33-pinctrl"
+  "allwinner,sun9i-a80-pinctrl"
+  "allwinner,sun9i-a80-r-pinctrl"
+  "allwinner,sun8i-a83t-pinctrl"
+  "allwinner,sun8i-h3-pinctrl"
+  "allwinner,sun8i-h3-r-pinctrl"
+  "allwinner,sun50i-a64-pinctrl"
+  "nextthing,gr8-pinctrl"
+
+- reg: Should contain the register physical address and length for the
+  pin controller.
+
+- clocks: phandle to the clocks feeding the pin controller:
+  - "apb": the gated APB parent clock
+  - "hosc": the high frequency oscillator in the system
+  - "losc": the low frequency oscillator in the system
+
+Note: For backward compatibility reasons, the hosc and losc clocks are only
+required if you need to use the optional input-debounce property. Any new
+device tree should set them.
+
+Optional properties:
+  - input-debounce: Array of debouncing periods in microseconds. One period per
+irq bank found in the controller. 0 if no setup required.
+
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+A pinctrl node should contain at least one subnodes representing the
+pinctrl groups available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, drive strength and pullups. If one of these options is
+not set, its actual value will be unspecified.
+
+This driver supports the generic pin multiplexing and configuration
+bindings. For details on each properties, you can refer to
+./pinctrl-bindings.txt.
+
+Required sub-node properties:
+  - pins
+  - function
+
+Optional sub-node properties:
+  - bias-disable
+  - bias-pull-up
+  - bia

[U-Boot] [PATCH v3 3/3] part_efi: document device-tree binding for part_efi configuration

2017-03-01 Thread Philipp Tomsich
This adds documentation on the u-boot,efi-partition-entries-offset
property (which overrides CONFIG_EFI_PARTITION_ENTRIES_OFF, if
present).

Signed-off-by: Philipp Tomsich 
Reviewed-by: Simon Glass 
---
 doc/device-tree-bindings/config.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/device-tree-bindings/config.txt 
b/doc/device-tree-bindings/config.txt
index ebb9bd4..5640bae 100644
--- a/doc/device-tree-bindings/config.txt
+++ b/doc/device-tree-bindings/config.txt
@@ -12,3 +12,11 @@ silent-console
 
 no-keyboard
Tells U-Boot not to expect an attached keyboard with a VGA console
+
+u-boot,efi-partition-entries-offset
+   If present, this provides an offset (in bytes, from the start of a
+   device) that should be skipped over before the partition entries.
+   This is used by the EFI/GPT partition implementation when a device
+   is formatted.
+
+   This setting will override any values configured via Kconfig.
-- 
1.9.1

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


[U-Boot] [PATCH v3 2/3] doc: move documentation for /config node into a separate file

2017-03-01 Thread Philipp Tomsich
This moves the description of the /config node from README.fdt-control
into a separate file doc/device-tree-bindings/config.txt.

Signed-off-by: Philipp Tomsich 
Reviewed-by: Simon Glass 
---
 doc/README.fdt-control  | 16 
 doc/device-tree-bindings/config.txt | 14 ++
 2 files changed, 14 insertions(+), 16 deletions(-)
 create mode 100644 doc/device-tree-bindings/config.txt

diff --git a/doc/README.fdt-control b/doc/README.fdt-control
index 2913fcb..c965629 100644
--- a/doc/README.fdt-control
+++ b/doc/README.fdt-control
@@ -168,22 +168,6 @@ After board configuration is done, fdt supported u-boot 
can be build in two ways
 $ make DEVICE_TREE=
 
 
-Configuration Options
--
-
-A number of run-time configuration options are provided in the /config node
-of the control device tree. You can access these using fdtdec_get_config_int(),
-fdtdec_get_config_bool() and fdtdec_get_config_string().
-
-Available options are:
-
-silent-console
-   If present and non-zero, the console is silenced by default on boot.
-
-no-keyboard
-   Tells U-Boot not to expect an attached keyboard with a VGA console
-
-
 Limitations
 ---
 
diff --git a/doc/device-tree-bindings/config.txt 
b/doc/device-tree-bindings/config.txt
new file mode 100644
index 000..ebb9bd4
--- /dev/null
+++ b/doc/device-tree-bindings/config.txt
@@ -0,0 +1,14 @@
+The /config node (Configuration Options)
+
+
+A number of run-time configuration options are provided in the /config node
+of the control device tree. You can access these using fdtdec_get_config_int(),
+fdtdec_get_config_bool() and fdtdec_get_config_string().
+
+Available options are:
+
+silent-console
+   If present and non-zero, the console is silenced by default on boot.
+
+no-keyboard
+   Tells U-Boot not to expect an attached keyboard with a VGA console
-- 
1.9.1

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


[U-Boot] [PATCH v3 1/3] part_efi: support padding between the GPT header and partition entries

2017-03-01 Thread Philipp Tomsich
Some architectures require their SPL loader at a fixed address within
the first 16KB of the disk. To avoid an overlap with the partition
entries of the EFI partition table, the first safe offset (in bytes,
from the start of the device) for the entries can be set through
CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig)

When formatting a device with an EFI partition table, we may need to
leave a gap between the GPT header (always in LBA 1) and the partition
entries. The GPT header already contains a field to specify the
on-disk location, which has so far always been set to LBA 2. With this
change, a configurable offset will be translated into a LBA address
indicating where to put the entries.

Now also allows an override via device-tree using a config-node (see
doc/device-tree-bindings/config.txt for documentation).

Tested (exporting an internal MMC formatted with this) against Linux,
MacOS X and Windows.

Signed-off-by: Philipp Tomsich 
Reviewed-by: Simon Glass 
---
 disk/Kconfig| 13 +
 disk/part_efi.c | 54 ++
 2 files changed, 63 insertions(+), 4 deletions(-)

diff --git a/disk/Kconfig b/disk/Kconfig
index 16ff52d..8e328b4 100644
--- a/disk/Kconfig
+++ b/disk/Kconfig
@@ -79,6 +79,19 @@ config EFI_PARTITION
  common when EFI is the bootloader.  Note 2TB partition limit;
  see disk/part_efi.c
 
+config EFI_PARTITION_ENTRIES_OFF
+int "Offset (in bytes) of the EFI partition entries"
+   depends on EFI_PARTITION
+   default 0
+   help
+ Specify an earliest location (in bytes) where the partition
+ entries may be located. This is meant to allow "punching a
+ hole into a device" to create a gap for an SPL, its payload
+ and the U-Boot environment.
+
+ If unsure, leave at 0 (which will locate the partition
+ entries at the first possible LBA following the GPT header).
+
 config SPL_EFI_PARTITION
bool "Enable EFI GPT partition table for SPL"
depends on  SPL && PARTITIONS
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 893cbbd..1351bbf 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -373,8 +374,8 @@ int write_gpt_table(struct blk_desc *dev_desc,
if (blk_dwrite(dev_desc, 1, 1, gpt_h) != 1)
goto err;
 
-   if (blk_dwrite(dev_desc, 2, pte_blk_cnt, gpt_e)
-   != pte_blk_cnt)
+   if (blk_dwrite(dev_desc, le64_to_cpu(gpt_h->partition_entry_lba),
+  pte_blk_cnt, gpt_e) != pte_blk_cnt)
goto err;
 
prepare_backup_gpt_header(gpt_h);
@@ -498,6 +499,49 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
return 0;
 }
 
+static uint32_t partition_entries_offset(struct blk_desc *dev_desc)
+{
+   uint32_t offset_blks = 2;
+   int config_offset;
+
+#if defined(CONFIG_EFI_PARTITION_ENTRIES_OFF)
+   /*
+* Some architectures require their SPL loader at a fixed
+* address within the first 16KB of the disk.  To avoid an
+* overlap with the partition entries of the EFI partition
+* table, the first safe offset (in bytes, from the start of
+* the disk) for the entries can be set in
+* CONFIG_EFI_PARTITION_ENTRIES_OFF.
+*/
+   offset_blks =
+   PAD_TO_BLOCKSIZE(CONFIG_EFI_PARTITION_ENTRIES_OFF, dev_desc);
+#endif
+
+#if defined(CONFIG_OF_CONTROL)
+   /*
+* Allow the offset of the first partition entires (in bytes
+* from the start of the device) to be specified as a property
+* of the device tree '/config' node.
+*/
+   config_offset = fdtdec_get_config_int(gd->fdt_blob,
+ 
"u-boot,efi-partition-entries-offset",
+ -EINVAL);
+   if (config_offset != -EINVAL)
+   offset_blks = PAD_TO_BLOCKSIZE(config_offset, dev_desc);
+#endif
+
+   debug("efi: partition entries offset (in blocks): %d\n", offset_blks);
+
+   /*
+* The earliest LBA this can be at is LBA#2 (i.e. right behind
+* the (protective) MBR and the GPT header.
+*/
+   if (offset_blks < 2)
+   offset_blks = 2;
+
+   return offset_blks;
+}
+
 int gpt_fill_header(struct blk_desc *dev_desc, gpt_header *gpt_h,
char *str_guid, int parts_count)
 {
@@ -506,9 +550,11 @@ int gpt_fill_header(struct blk_desc *dev_desc, gpt_header 
*gpt_h,
gpt_h->header_size = cpu_to_le32(sizeof(gpt_header));
gpt_h->my_lba = cpu_to_le64(1);
gpt_h->alternate_lba = cpu_to_le64(dev_desc->lba - 1);
-   gpt_h->first_usable_lba = cpu_to_le64(34);
gpt_h->last_usable_lba = cpu_to_le64(dev_desc->lba - 34);
-   gpt_h->partition_entry_lba = cpu_to_le64(2);
+   gpt_h->partition_entry_lba =
+   cpu_to_le64(partition_ent

[U-Boot] [PATCH v3 0/3] disk: efi: allow gap before partition entries

2017-03-01 Thread Philipp Tomsich
Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs
(the SPL code needs to reside an 8K offset into the device), we add
support for leaving a gap between the MBR (LBA#0), GPT header (LBA#1)
and GPT partition entries (linked from field in the GPT header).

Changes in v2:
 * CONFIG_EFI_PARTITION_ENTRIES_OFF is configurable via Kconfig
 * added clamping to ensure that the parititions are never put into
   the first to LBAs of a device
 * documented the new /config property (and moved the documentation of
   /config properties into a separate file per Simon's review comment)

Changes in v3:
 * fixed comment styles
 * split documentation content move and adding new content into two
   patches



Philipp Tomsich (3):
  part_efi: support padding between the GPT header and partition entries
  doc: move documentation for /config node into a separate file
  part_efi: document device-tree binding for part_efi configuration

 disk/Kconfig| 13 +
 disk/part_efi.c | 54 ++---
 doc/README.fdt-control  | 16 ---
 doc/device-tree-bindings/config.txt | 22 +++
 4 files changed, 85 insertions(+), 20 deletions(-)
 create mode 100644 doc/device-tree-bindings/config.txt

-- 
1.9.1

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


[U-Boot] [PATCH v4] armv8: spl: Call spl_relocate_stack_gd for ARMv8

2017-03-01 Thread Philipp Tomsich
As part of the startup process for boards using the SPL, we need to
call spl_relocate_stack_gd. This is needed to set up malloc with its
DRAM buffer.

Signed-off-by: Philipp Tomsich 
Reviewed-by: Andre Przywara 
Reviewed-by: Simon Glass 
---
 arch/arm/lib/crt0_64.S | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index 19c6a98..57e728f 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -109,8 +109,18 @@ relocation_return:
  */
bl  c_runtime_cpu_setup /* still call old routine */
 #endif /* !CONFIG_SPL_BUILD */
-
-/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
+#if defined(CONFIG_SPL_BUILD)
+   bl  spl_relocate_stack_gd   /* may return NULL */
+   /*
+* Perform 'sp = (x0 != NULL) ? x0 : sp' while working
+* around the constraint that conditional moves can not
+* have 'sp' as an operand
+*/
+   mov x1, sp
+   cmp x0, #0
+   cselx0, x0, x1, ne
+   mov sp, x0
+#endif
 
 /*
  * Clear BSS section
-- 
1.9.1

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


[U-Boot] [PATCH v4 08/11] armv8: layerscape: Fix the sequence of changing MMU table

2017-03-01 Thread York Sun
This patch follows the break-before-make process when making changes
to MMU table. MMU is disabled before changing TTBR to avoid any
potential race condition.

Signed-off-by: York Sun 

---

Changes in v4:
  Revert the change of C bit in v3 patch.

Changes in v3:
  Instead of flushing d-cache, following the break-before-make process
  to change MMU table.

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 800ad62..afb6cd1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -181,21 +181,14 @@ static inline void final_mmu_setup(void)
setup_pgtables();
gd->arch.tlb_addr = tlb_addr_save;
 
-   /* flush new MMU table */
-   flush_dcache_range(gd->arch.tlb_addr,
-  gd->arch.tlb_addr + gd->arch.tlb_size);
+   /* Disable cache and MMU */
+   dcache_disable();   /* TLBs are invalidated */
+   invalidate_icache_all();
 
/* point TTBR to the new table */
set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(el, NULL, NULL),
  MEMORY_ATTRIBUTES);
-   /*
-* EL3 MMU is already enabled, just need to invalidate TLB to load the
-* new table. The new table is compatible with the current table, if
-* MMU somehow walks through the new table before invalidation TLB,
-* it still works. So we don't need to turn off MMU here.
-* When EL2 MMU table is created by calling this function, MMU needs
-* to be enabled.
-*/
+
set_sctlr(get_sctlr() | CR_M);
 }
 
-- 
2.7.4

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


[U-Boot] [PATCH v3 03/11] armv8: ls2080a: Move CONFIG_SYS_MC_RSV_MEM_ALIGN to Kconfig

2017-03-01 Thread York Sun
Use Kconfig option instead of config macro in header file.

Signed-off-by: York Sun 
---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 8 
 include/configs/ls2080a_common.h  | 1 -
 scripts/config_whitelist.txt  | 1 -
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index ad9c982..55760ad 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -307,3 +307,11 @@ config SYS_FSL_ERRATUM_A009660
 
 config SYS_FSL_ERRATUM_A009929
bool
+
+config SYS_MC_RSV_MEM_ALIGN
+   hex "Management Complex reserved memory alignment"
+   depends on RESV_RAM_TOP
+   default 0x2000
+   help
+ Reserved memory needs to be aligned for MC to use. Default value
+ is 512MB.
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 7719224..4173d9a 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -160,7 +160,6 @@ unsigned long long get_qixis_addr(void);
  */
 #ifdef CONFIG_FSL_MC_ENET
 #define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024 * 1024)
-#define CONFIG_SYS_MC_RSV_MEM_ALIGN(512UL * 1024 * 1024)
 #endif
 
 /* Command line configuration */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index ca3667d..66900e6 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -5043,7 +5043,6 @@ CONFIG_SYS_MCKR_VAL
 CONFIG_SYS_MCLINK_MAX
 CONFIG_SYS_MCMEM0_VAL
 CONFIG_SYS_MCMEM1_VAL
-CONFIG_SYS_MC_RSV_MEM_ALIGN
 CONFIG_SYS_MDC1_PIN
 CONFIG_SYS_MDCNFG_VAL
 CONFIG_SYS_MDC_PIN
-- 
2.7.4

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


Re: [U-Boot] arm: cache: misaligned operation with fastboot

2017-03-01 Thread Fabio Estevam
Hi Gary,

On Wed, Mar 1, 2017 at 12:12 PM, Gary Bisson
 wrote:
> Hi Fabio, Lukasz,
>
> On Wed, Feb 15, 2017 at 02:24:40PM -0200, Fabio Estevam wrote:
>> On Wed, Feb 15, 2017 at 2:04 PM, Gary Bisson
>>  wrote:
>> > Hi,
>> >
>> > I've been testing fastboot to flash a sparse image on a i.MX6Q platform
>> > (Nitrogen6x) with U-Boot v2017.01.
>> >
>> > This test shows a lot of "misaligned operation" traces:
>> > => fastboot 0
>> > Starting download of 415679660 bytes
>> > ...
>> > downloading of 415679660 bytes finished
>> > Flashing sparse image at offset 82124
>> > Flashing Sparse Image
>> > CACHE: Misaligned operation at range [1228, 12028028]
>> > CACHE: Misaligned operation at range [12028044, 1208f044]
>> > CACHE: Misaligned operation at range [1208f060, 123fd060]
>> > ...
>> >
>> > Has any of you seen that behavior?
>> >
>> > Note that this behavior only happens for sparse images, flashing a raw
>> > image doesn't exhibit the problem.
>>
>> Adding DFU maintainer, Lukasz on Cc.
>
> Any update on this? Has anyone been able to reproduce?

I have never used fastboot. Hopefully someone else could give you some advice.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 08/11] armv8: layerscape: Fix the sequence of changing MMU table

2017-03-01 Thread york sun
On 03/01/2017 11:32 AM, York Sun wrote:
> This patch follows the break-before-make process when making changes
> to MMU table. MMU is disabled before changing TTBR to avoid any
> potential race condition.
>
> Signed-off-by: York Sun 
>
> ---
>
> Changes in v3:
>   Instead of flushing d-cache, following the break-before-make process
>   to change MMU table.
>
> Changes in v2: None
>
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 18 ++
>  1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index 800ad62..3113543 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -181,22 +181,16 @@ static inline void final_mmu_setup(void)
>   setup_pgtables();
>   gd->arch.tlb_addr = tlb_addr_save;
>
> - /* flush new MMU table */
> - flush_dcache_range(gd->arch.tlb_addr,
> -gd->arch.tlb_addr + gd->arch.tlb_size);
> + /* Disable cache and MMU */
> + dcache_disable();   /* TLBs are invalidated */
> + invalidate_icache_all();
>
>   /* point TTBR to the new table */
>   set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(el, NULL, NULL),
> MEMORY_ATTRIBUTES);
> - /*
> -  * EL3 MMU is already enabled, just need to invalidate TLB to load the
> -  * new table. The new table is compatible with the current table, if
> -  * MMU somehow walks through the new table before invalidation TLB,
> -  * it still works. So we don't need to turn off MMU here.
> -  * When EL2 MMU table is created by calling this function, MMU needs
> -  * to be enabled.
> -  */
> - set_sctlr(get_sctlr() | CR_M);
> +
> + /* Enable MMU and D-cache */
> + set_sctlr(get_sctlr() | CR_M | CR_C);

I made a mistake by enabling the C bit here. Will send a new version.

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


[U-Boot] [PATCH v3 06/11] driver: net: fsl-mc: Update calculation of MC RAM

2017-03-01 Thread York Sun
Since the reserved RAM is tracked by gd->arch.resv_ram, calculation
of MC memory blocks can be simplified. The MC RAM is guaranteed to be
aligned by the reservation process.

Signed-off-by: York Sun 
CC: Priyanka Jain 
---

Changes in v3: None
Changes in v2: None

 drivers/net/fsl-mc/mc.c | 59 +++--
 1 file changed, 8 insertions(+), 51 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 231a6d5..9f69d75 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -154,48 +154,6 @@ int parse_mc_firmware_fit_image(u64 mc_fw_addr,
 }
 #endif
 
-/*
- * Calculates the values to be used to specify the address range
- * for the MC private DRAM block, in the MCFBALR/MCFBAHR registers.
- * It returns the highest 512MB-aligned address within the given
- * address range, in '*aligned_base_addr', and the number of 256 MiB
- * blocks in it, in 'num_256mb_blocks'.
- */
-static int calculate_mc_private_ram_params(u64 mc_private_ram_start_addr,
-  size_t mc_ram_size,
-  u64 *aligned_base_addr,
-  u8 *num_256mb_blocks)
-{
-   u64 addr;
-   u16 num_blocks;
-
-   if (mc_ram_size % MC_RAM_SIZE_ALIGNMENT != 0) {
-   printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
-  mc_ram_size);
-   return -EINVAL;
-   }
-
-   num_blocks = mc_ram_size / MC_RAM_SIZE_ALIGNMENT;
-   if (num_blocks < 1 || num_blocks > 0xff) {
-   printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
-  mc_ram_size);
-   return -EINVAL;
-   }
-
-   addr = (mc_private_ram_start_addr + mc_ram_size - 1) &
-   MC_RAM_BASE_ADDR_ALIGNMENT_MASK;
-
-   if (addr < mc_private_ram_start_addr) {
-   printf("fsl-mc: ERROR: bad start address %#llx\n",
-  mc_private_ram_start_addr);
-   return -EFAULT;
-   }
-
-   *aligned_base_addr = addr;
-   *num_256mb_blocks = num_blocks;
-   return 0;
-}
-
 static int mc_fixup_dpc_mac_addr(void *blob, int noff, int dpmac_id,
struct eth_device *eth_dev)
 {
@@ -550,17 +508,16 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
size_t raw_image_size = 0;
 #endif
struct mc_version mc_ver_info;
-   u64 mc_ram_aligned_base_addr;
u8 mc_ram_num_256mb_blocks;
size_t mc_ram_size = mc_get_dram_block_size();
 
-
-   error = calculate_mc_private_ram_params(mc_ram_addr,
-   mc_ram_size,
-   &mc_ram_aligned_base_addr,
-   &mc_ram_num_256mb_blocks);
-   if (error != 0)
+   mc_ram_num_256mb_blocks = mc_ram_size / MC_RAM_SIZE_ALIGNMENT;
+   if (mc_ram_num_256mb_blocks < 1 || mc_ram_num_256mb_blocks > 0xff) {
+   error = -EINVAL;
+   printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
+  mc_ram_size);
goto out;
+   }
 
/*
 * Management Complex cores should be held at reset out of POR.
@@ -602,11 +559,11 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
/*
 * Tell MC what is the address range of the DRAM block assigned to it:
 */
-   reg_mcfbalr = (u32)mc_ram_aligned_base_addr |
+   reg_mcfbalr = (u32)mc_ram_addr |
  (mc_ram_num_256mb_blocks - 1);
out_le32(&mc_ccsr_regs->reg_mcfbalr, reg_mcfbalr);
out_le32(&mc_ccsr_regs->reg_mcfbahr,
-(u32)(mc_ram_aligned_base_addr >> 32));
+(u32)(mc_ram_addr >> 32));
out_le32(&mc_ccsr_regs->reg_mcfapr, FSL_BYPASS_AMQ);
 
/*
-- 
2.7.4

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


[U-Boot] [PATCH v3 10/11] armv8: mmu: Add a function to change mapping attributes

2017-03-01 Thread York Sun
Function mmu_change_region_attr() is added to change existing mapping
with updated PXN, UXN and memory type. This is a break-before-make
process during which the mapping becomes fault (invalid) before final
attributres are set.

Signed-off-by: York Sun 
---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv8/cache_v8.c| 72 +---
 arch/arm/include/asm/armv8/mmu.h |  5 +++
 arch/arm/include/asm/system.h|  1 +
 3 files changed, 74 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 6c5630c..bd1c3e0 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -501,7 +501,8 @@ static bool is_aligned(u64 addr, u64 size, u64 align)
return !(addr & (align - 1)) && !(size & (align - 1));
 }
 
-static u64 set_one_region(u64 start, u64 size, u64 attrs, int level)
+/* Use flag to indicate if attrs has more than d-cache attributes */
+static u64 set_one_region(u64 start, u64 size, u64 attrs, bool flag, int level)
 {
int levelshift = level2shift(level);
u64 levelsize = 1ULL << levelshift;
@@ -509,8 +510,13 @@ static u64 set_one_region(u64 start, u64 size, u64 attrs, 
int level)
 
/* Can we can just modify the current level block PTE? */
if (is_aligned(start, size, levelsize)) {
-   *pte &= ~PMD_ATTRINDX_MASK;
-   *pte |= attrs;
+   if (flag) {
+   *pte &= ~PMD_ATTRMASK;
+   *pte |= attrs & PMD_ATTRMASK;
+   } else {
+   *pte &= ~PMD_ATTRINDX_MASK;
+   *pte |= attrs & PMD_ATTRINDX_MASK;
+   }
debug("Set attrs=%llx pte=%p level=%d\n", attrs, pte, level);
 
return levelsize;
@@ -560,7 +566,8 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
u64 r;
 
for (level = 1; level < 4; level++) {
-   r = set_one_region(start, size, attrs, level);
+   /* Set d-cache attributes only */
+   r = set_one_region(start, size, attrs, false, level);
if (r) {
/* PTE successfully replaced */
size -= r;
@@ -581,6 +588,63 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
flush_dcache_range(real_start, real_start + real_size);
 }
 
+/*
+ * Modify MMU table for a region with updated PXN/UXN/Memory type/valid bits.
+ * The procecess is break-before-make. The target region will be marked as
+ * invalid during the process of changing.
+ */
+void mmu_change_region_attr(phys_addr_t addr, size_t siz, u64 attrs)
+{
+   int level;
+   u64 r, size, start;
+
+   start = addr;
+   size = siz;
+   /*
+* Loop through the address range until we find a page granule that fits
+* our alignment constraints, then set it to "invalid".
+*/
+   while (size > 0) {
+   for (level = 1; level < 4; level++) {
+   /* Set PTE to fault */
+   r = set_one_region(start, size, PTE_TYPE_FAULT, true,
+  level);
+   if (r) {
+   /* PTE successfully invalidated */
+   size -= r;
+   start += r;
+   break;
+   }
+   }
+   }
+
+   flush_dcache_range(gd->arch.tlb_addr,
+  gd->arch.tlb_addr + gd->arch.tlb_size);
+   __asm_invalidate_tlb_all();
+
+   /*
+* Loop through the address range until we find a page granule that fits
+* our alignment constraints, then set it to the new cache attributes
+*/
+   start = addr;
+   size = siz;
+   while (size > 0) {
+   for (level = 1; level < 4; level++) {
+   /* Set PTE to new attributes */
+   r = set_one_region(start, size, attrs, true, level);
+   if (r) {
+   /* PTE successfully updated */
+   size -= r;
+   start += r;
+   break;
+   }
+   }
+   }
+   flush_dcache_range(gd->arch.tlb_addr,
+  gd->arch.tlb_addr + gd->arch.tlb_size);
+   __asm_invalidate_tlb_all();
+}
+
 #else  /* CONFIG_SYS_DCACHE_OFF */
 
 /*
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index e9b4cdb..a349903 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -53,6 +53,7 @@
 #define PTE_TYPE_FAULT (0 << 0)
 #define PTE_TYPE_TABLE (3 << 0)
 #define PTE_TYPE_BLOCK (1 << 0)
+#define PTE_TYPE_VALID 

[U-Boot] [PATCH v3 07/11] armv8: layerscape: Update MMU mapping with actual DDR size

2017-03-01 Thread York Sun
Update mapping with actual DDR size. Non-existing memory should not
be mapped as "normal" memory to avoid speculative access.

Signed-off-by: York Sun 
---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 42 +++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 36451a2..800ad62 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -101,12 +101,50 @@ static inline void final_mmu_setup(void)
 {
u64 tlb_addr_save = gd->arch.tlb_addr;
unsigned int el = current_el();
-#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
int index;
-#endif
 
mem_map = final_map;
 
+   /* Update mapping for DDR to actual size */
+   for (index = 0; index < ARRAY_SIZE(final_map) - 2; index++) {
+   /*
+* Find the entry for DDR mapping and update the address and
+* size. Zero-sized mapping will be skipped when creating MMU
+* table.
+*/
+   switch (final_map[index].virt) {
+   case CONFIG_SYS_FSL_DRAM_BASE1:
+   final_map[index].virt = gd->bd->bi_dram[0].start;
+   final_map[index].phys = gd->bd->bi_dram[0].start;
+   final_map[index].size = gd->bd->bi_dram[0].size;
+   break;
+#ifdef CONFIG_SYS_FSL_DRAM_BASE2
+   case CONFIG_SYS_FSL_DRAM_BASE2:
+#if (CONFIG_NR_DRAM_BANKS >= 2)
+   final_map[index].virt = gd->bd->bi_dram[1].start;
+   final_map[index].phys = gd->bd->bi_dram[1].start;
+   final_map[index].size = gd->bd->bi_dram[1].size;
+#else
+   final_map[index].size = 0;
+#endif
+   break;
+#endif
+#ifdef CONFIG_SYS_FSL_DRAM_BASE3
+   case CONFIG_SYS_FSL_DRAM_BASE3:
+#if (CONFIG_NR_DRAM_BANKS >= 3)
+   final_map[index].virt = gd->bd->bi_dram[2].start;
+   final_map[index].phys = gd->bd->bi_dram[2].start;
+   final_map[index].size = gd->bd->bi_dram[2].size;
+#else
+   final_map[index].size = 0;
+#endif
+   break;
+#endif
+   default:
+   break;
+   }
+   }
+
 #ifdef CONFIG_SYS_MEM_RESERVE_SECURE
if (gd->arch.secure_ram & MEM_RESERVE_SECURE_MAINTAINED) {
if (el == 3) {
-- 
2.7.4

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


[U-Boot] [PATCH v3 05/11] armv8: layerscape: Rewrite memory reservation

2017-03-01 Thread York Sun
For ARMv8 Layerscape SoCs, secure memory and MC memorey are reserved
at the end of DDR. DDR is spit into two or three banks. This patch
reverts commit aabd7ddb and simplifies the calculation of reserved
memory, and moves the code into common SoC file. Secure memory is
carved out first. DDR bank size is reduced. Reserved memory is then
allocated on the top of available memory. U-Boot still has access
to reserved memory as data transferring is needed. Device tree is
fixed with reduced memory size to hide the reserved memory from OS.
The same region is reserved for efi_loader.

Signed-off-by: York Sun 

---

Changes in v3: None
Changes in v2:
  Implement SoC level efi_add_known_memory(). DP-DDR is skipped so no
  need to add it as reserved memory later.

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c   | 198 +-
 arch/arm/include/asm/arch-fsl-layerscape/config.h |   4 +-
 board/freescale/ls1012afrdm/ls1012afrdm.c |  29 
 board/freescale/ls1012aqds/ls1012aqds.c   |  29 
 board/freescale/ls1012ardb/ls1012ardb.c   |  29 
 board/freescale/ls1043aqds/ddr.c  |  29 
 board/freescale/ls1043ardb/ddr.c  |  29 
 board/freescale/ls1046aqds/ddr.c  |  29 
 board/freescale/ls1046ardb/ddr.c  |  29 
 board/freescale/ls2080a/ddr.c |  55 --
 board/freescale/ls2080a/ls2080a.c |  10 ++
 board/freescale/ls2080aqds/ddr.c  |  55 --
 board/freescale/ls2080aqds/ls2080aqds.c   |  10 ++
 board/freescale/ls2080ardb/ddr.c  |  55 --
 board/freescale/ls2080ardb/ls2080ardb.c   |  18 +-
 common/board_f.c  |  32 +---
 drivers/net/fsl-mc/mc.c   |  16 +-
 17 files changed, 233 insertions(+), 423 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 335f225..36451a2 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -524,15 +524,201 @@ phys_size_t board_reserve_ram_top(phys_size_t ram_size)
 {
phys_size_t ram_top = ram_size;
 
-#ifdef CONFIG_SYS_MEM_TOP_HIDE
-#error CONFIG_SYS_MEM_TOP_HIDE not to be used together with this function
-#endif
-
-/* Carve the MC private DRAM block from the end of DRAM */
 #ifdef CONFIG_FSL_MC_ENET
+   /* The start address of MC reserved memory needs to be aligned. */
ram_top -= mc_get_dram_block_size();
ram_top &= ~(CONFIG_SYS_MC_RSV_MEM_ALIGN - 1);
 #endif
 
-   return ram_top;
+   return ram_size - ram_top;
+}
+
+phys_size_t get_effective_memsize(void)
+{
+   phys_size_t ea_size, rem = 0;
+
+   /*
+* For ARMv8 SoCs, DDR memory is split into two or three regions. The
+* first region is 2GB space at 0x8000_. If the memory extends to
+* the second region (or the third region if applicable), the secure
+* memory and Management Complex (MC) memory should be put into the
+* highest region, i.e. the end of DDR memory. CONFIG_MAX_MEM_MAPPED
+* is set to the size of first region so U-Boot doesn't relocate itself
+* into higher address. Should DDR be configured to skip the first
+* region, this function needs to be adjusted.
+*/
+   if (gd->ram_size > CONFIG_MAX_MEM_MAPPED) {
+   ea_size = CONFIG_MAX_MEM_MAPPED;
+   rem = gd->ram_size - ea_size;
+   } else {
+   ea_size = gd->ram_size;
+   }
+
+#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
+   /* Check if we have enough space for secure memory */
+   if (rem > CONFIG_SYS_MEM_RESERVE_SECURE) {
+   rem -= CONFIG_SYS_MEM_RESERVE_SECURE;
+   } else {
+   if (ea_size > CONFIG_SYS_MEM_RESERVE_SECURE) {
+   ea_size -= CONFIG_SYS_MEM_RESERVE_SECURE;
+   rem = 0;/* Presume MC requires more memory */
+   } else {
+   printf("Error: No enough space for secure memory.\n");
+   }
+   }
+#endif
+   /* Check if we have enough memory for MC */
+   if (rem < board_reserve_ram_top(rem)) {
+   /* Not enough memory in high region to reserve */
+   if (ea_size > board_reserve_ram_top(rem))
+   ea_size -= board_reserve_ram_top(rem);
+   else
+   printf("Error: No enough space for reserved memory.\n");
+   }
+
+   return ea_size;
+}
+
+void dram_init_banksize(void)
+{
+#ifdef CONFIG_SYS_DP_DDR_BASE_PHY
+   phys_size_t dp_ddr_size;
+#endif
+
+   /*
+* gd->ram_size has the total size of DDR memory, less reserved secure
+* memory. The DDR extends from low region to high region(s) presuming
+* no hole is created with DDR configuration. gd->arch.secure_ram tracks
+* the location of secure memo

[U-Boot] [PATCH v3 08/11] armv8: layerscape: Fix the sequence of changing MMU table

2017-03-01 Thread York Sun
This patch follows the break-before-make process when making changes
to MMU table. MMU is disabled before changing TTBR to avoid any
potential race condition.

Signed-off-by: York Sun 

---

Changes in v3:
  Instead of flushing d-cache, following the break-before-make process
  to change MMU table.

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 800ad62..3113543 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -181,22 +181,16 @@ static inline void final_mmu_setup(void)
setup_pgtables();
gd->arch.tlb_addr = tlb_addr_save;
 
-   /* flush new MMU table */
-   flush_dcache_range(gd->arch.tlb_addr,
-  gd->arch.tlb_addr + gd->arch.tlb_size);
+   /* Disable cache and MMU */
+   dcache_disable();   /* TLBs are invalidated */
+   invalidate_icache_all();
 
/* point TTBR to the new table */
set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(el, NULL, NULL),
  MEMORY_ATTRIBUTES);
-   /*
-* EL3 MMU is already enabled, just need to invalidate TLB to load the
-* new table. The new table is compatible with the current table, if
-* MMU somehow walks through the new table before invalidation TLB,
-* it still works. So we don't need to turn off MMU here.
-* When EL2 MMU table is created by calling this function, MMU needs
-* to be enabled.
-*/
-   set_sctlr(get_sctlr() | CR_M);
+
+   /* Enable MMU and D-cache */
+   set_sctlr(get_sctlr() | CR_M | CR_C);
 }
 
 u64 get_page_table_size(void)
-- 
2.7.4

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


[U-Boot] [PATCH v3 11/11] armv8: layerscape: Update early MMU for DDR after initialization

2017-03-01 Thread York Sun
In early MMU table, DDR has to be mapped as device memory to avoid
speculative access. After DDR is initialized, it needs to be updated
to normal memory to allow code execution. To simplify the code,
dram_init() is moved into a common file as a weak function.

Signed-off-by: York Sun 

---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 76 ++
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 12 +++-
 arch/arm/include/asm/arch-fsl-layerscape/mmu.h |  2 +-
 board/freescale/ls1012afrdm/ls1012afrdm.c  |  5 ++
 board/freescale/ls1012aqds/ls1012aqds.c|  5 ++
 board/freescale/ls1012ardb/ls1012ardb.c|  5 ++
 board/freescale/ls1043aqds/ls1043aqds.c|  5 ++
 board/freescale/ls1043ardb/ls1043ardb.c|  7 ---
 board/freescale/ls1046aqds/ls1046aqds.c|  5 ++
 board/freescale/ls1046ardb/ls1046ardb.c|  7 ---
 board/freescale/ls2080a/ls2080a.c  |  7 ---
 board/freescale/ls2080aqds/ls2080aqds.c|  7 ---
 board/freescale/ls2080ardb/ls2080ardb.c|  8 +--
 13 files changed, 113 insertions(+), 38 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 3113543..4e9f8ad 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -754,3 +754,79 @@ void efi_add_known_memory(void)
}
 }
 #endif
+
+/*
+ * Before DDR size is known, early MMU table have DDR mapped as device memory
+ * to avoid speculative access. To relocate U-Boot to DDR, "normal memory"
+ * needs to be set for these mappings.
+ * If a special case configures DDR with holes in the mapping, the holes need
+ * to be marked as invalid. This is not implemented in this function.
+ */
+void update_early_mmu_table(void)
+{
+   if (!gd->arch.tlb_addr)
+   return;
+
+   if (gd->ram_size <= CONFIG_SYS_FSL_DRAM_SIZE1) {
+   mmu_change_region_attr(
+   CONFIG_SYS_SDRAM_BASE,
+   gd->ram_size,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+   } else {
+   mmu_change_region_attr(
+   CONFIG_SYS_SDRAM_BASE,
+   CONFIG_SYS_DDR_BLOCK1_SIZE,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+#ifdef CONFIG_SYS_DDR_BLOCK3_BASE
+#ifndef CONFIG_SYS_DDR_BLOCK2_SIZE
+#error "Missing CONFIG_SYS_DDR_BLOCK2_SIZE"
+#endif
+   if (gd->ram_size - CONFIG_SYS_DDR_BLOCK1_SIZE >
+   CONFIG_SYS_DDR_BLOCK2_SIZE) {
+   mmu_change_region_attr(
+   CONFIG_SYS_DDR_BLOCK2_BASE,
+   CONFIG_SYS_DDR_BLOCK2_SIZE,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+   mmu_change_region_attr(
+   CONFIG_SYS_DDR_BLOCK3_BASE,
+   gd->ram_size -
+   CONFIG_SYS_DDR_BLOCK1_SIZE -
+   CONFIG_SYS_DDR_BLOCK2_SIZE,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+   } else
+#endif
+   {
+   mmu_change_region_attr(
+   CONFIG_SYS_DDR_BLOCK2_BASE,
+   gd->ram_size -
+   CONFIG_SYS_DDR_BLOCK1_SIZE,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+   }
+   }
+}
+
+__weak int dram_init(void)
+{
+   gd->ram_size = initdram(0);
+#if !defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD)
+   /* This will break-before-make MMU for DDR */
+   update_early_mmu_table();
+#endif
+
+   return 0;
+}
diff --git a/arch/a

[U-Boot] [PATCH v3 02/11] armv8: ls2080a: Move CONFIG_FSL_MC_ENET to Kconfig

2017-03-01 Thread York Sun
Use Kconfig option instead of config macro in header file.
Clean up existing usage.

Signed-off-by: York Sun 
---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 8 
 include/configs/ls2080a_common.h  | 1 -
 scripts/config_whitelist.txt  | 1 -
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index a40556f..ad9c982 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -85,6 +85,14 @@ config FSL_LSCH3
select SYS_FSL_SRDS_1
select SYS_HAS_SERDES
 
+config FSL_MC_ENET
+   bool "Management Complex network"
+   depends on ARCH_LS2080A
+   default y
+   select RESV_RAM_TOP
+   help
+ Enable Management Complex (MC) network
+
 menu "Layerscape architecture"
depends on FSL_LSCH2 || FSL_LSCH3
 
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 4bfd0ac..7719224 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -143,7 +143,6 @@ unsigned long long get_qixis_addr(void);
 #define CONFIG_SYS_NAND_BASE_PHYS  0x3000
 
 /* MC firmware */
-#define CONFIG_FSL_MC_ENET
 /* TODO Actual DPL max length needs to be confirmed with the MC FW team */
 #define CONFIG_SYS_LS_MC_DPC_MAX_LENGTH0x2
 #define CONFIG_SYS_LS_MC_DRAM_DPC_OFFSET0x00F0
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index f6c9101..ca3667d 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1194,7 +1194,6 @@ CONFIG_FSL_LAYERSCAPE
 CONFIG_FSL_LBC
 CONFIG_FSL_LINFLEXUART
 CONFIG_FSL_MC9SDZ60
-CONFIG_FSL_MC_ENET
 CONFIG_FSL_MEMAC
 CONFIG_FSL_NFC_CHIPS
 CONFIG_FSL_NFC_SPARE_SIZE
-- 
2.7.4

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


[U-Boot] [PATCH v3 04/11] efi: Add a hook to allow adding memory mapping

2017-03-01 Thread York Sun
Instead of adding all memory banks, add a hook so individual SoC/board
can has its own implementation.

Signed-off-by: York Sun 
CC: Alexander Graf 
Reviewed-by: Alexander Graf 

---

Changes in v3: None
Changes in v2:
  Add change to efi mapping

 lib/efi_loader/efi_memory.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 95aa590..db2ae19 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -431,11 +431,8 @@ efi_status_t efi_get_memory_map(unsigned long 
*memory_map_size,
return EFI_SUCCESS;
 }
 
-int efi_memory_init(void)
+__weak void efi_add_known_memory(void)
 {
-   unsigned long runtime_start, runtime_end, runtime_pages;
-   unsigned long uboot_start, uboot_pages;
-   unsigned long uboot_stack_size = 16 * 1024 * 1024;
int i;
 
/* Add RAM */
@@ -448,6 +445,15 @@ int efi_memory_init(void)
efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
   false);
}
+}
+
+int efi_memory_init(void)
+{
+   unsigned long runtime_start, runtime_end, runtime_pages;
+   unsigned long uboot_start, uboot_pages;
+   unsigned long uboot_stack_size = 16 * 1024 * 1024;
+
+   efi_add_known_memory();
 
/* Add U-Boot */
uboot_start = (gd->start_addr_sp - uboot_stack_size) & ~EFI_PAGE_MASK;
-- 
2.7.4

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


[U-Boot] [PATCH v3 09/11] armv8: ls2080a: Drop early MMU for SPL build

2017-03-01 Thread York Sun
Early MMU improves performance especially on emulators. However, the
early MMU is left enabled after the first stage of SPL boot. Instead
of flushing D-cache and dealing with re-enabling MMU for the second
stage U-Boot, disabling it for SPL build simplifies the process. The
performance penalty is unnoticeable on the real hardware. As of now,
SPL boot is not supported by existing emulators. So this should have
no impact on emulators.

Signed-off-by: York Sun 

---

Changes in v3:
  Add a patch to drop early MMU setup for LS2080A SPL build.

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/spl.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c 
b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
index 1dabdbb..73a8680 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
@@ -45,9 +45,6 @@ void board_init_f(ulong dummy)
 {
/* Clear global data */
memset((void *)gd, 0, sizeof(gd_t));
-#ifdef CONFIG_LS2080A
-   arch_cpu_init();
-#endif
board_early_init_f();
timer_init();
 #ifdef CONFIG_LS2080A
-- 
2.7.4

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


[U-Boot] [PATCH v3 01/11] armv8: Add global variable resv_ram

2017-03-01 Thread York Sun
Use gd->arch.resv_ram to track reserved memory allocation.

Signed-off-by: York Sun 
---

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 6 ++
 arch/arm/include/asm/global_data.h| 3 +++
 cmd/bdinfo.c  | 4 
 3 files changed, 13 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index adccdf1..a40556f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -273,6 +273,12 @@ config SYS_FSL_SDHC_CLK_DIV
  clock, in another word SDHC_clk = Platform_clk / this_divider.
 endmenu
 
+config RESV_RAM_TOP
+   bool
+   help
+ Reserve memory from the top, tracked by gd->arch.resv_ram. It's up
+ to implementation to allow access to this reserved memory or not.
+
 config SYS_FSL_ERRATUM_A008336
bool
 
diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index aee87cd..b1fc410 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -59,6 +59,9 @@ struct arch_global_data {
phys_addr_t secure_ram;
unsigned long tlb_allocated;
 #endif
+#ifdef CONFIG_RESV_RAM_TOP
+   phys_addr_t resv_ram;
+#endif
 
 #ifdef CONFIG_ARCH_OMAP2
u32 omap_boot_device;
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index ae3027a..0c5fa56 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -392,6 +392,10 @@ static int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
  gd->arch.secure_ram & MEM_RESERVE_SECURE_ADDR_MASK);
}
 #endif
+#ifdef CONFIG_RESV_RAM_TOP
+   if (gd->arch.resv_ram)
+   print_num("Reserved ram", gd->arch.resv_ram);
+#endif
 #if defined(CONFIG_CMD_NET) && !defined(CONFIG_DM_ETH)
print_eths();
 #endif
-- 
2.7.4

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


Re: [U-Boot] [PATCH] arm: dra7xx: Update bootloader partition size

2017-03-01 Thread Sam Protsenko
On Wed, Mar 1, 2017 at 5:29 PM, Tom Rini  wrote:
> On Tue, Feb 21, 2017 at 09:51:31PM +0200, Sam Protsenko wrote:
>
>> The current size of U-Boot is already ~840 KiB.
>>
>> This patch is to increase bootloader partition size up to 1 MiB
>> and thereby fix flashing error.
>>
>> Also fix U-Boot environment address on eMMC ("reserved" partition), as
>> it's being shifted by above change.
>>
>> Signed-off-by: Sam Protsenko 
>
> I know I'm late chiming in here, but I want to now, all the same.
> First, we need to explain _why_ things are getting so huge.  The answer
> is that we're including so many (complete, from Linux) device trees.  So
> we should probably update the comments around this area to note why the
> bootloader partition is so large, and then pick a good, large, and
> aligned with the underlying erase block size partition.
>

Tom,

Your comment is absolutely correct, I was just in a little bit hurry
when sending this patch. Please don't merge it yet, I'm gonna get back
to it after Linaro Connect. Things you mentioned will be added to
commit message, and we are probably going to change that partition
size one more time. So let's hold on on this change for now.

Thanks.

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


Re: [U-Boot] [linux-sunxi] [PATCH 05/12] sunxi: Set PLL lock enable bits for R40

2017-03-01 Thread Jernej Škrabec
Hi!

Dne sreda, 01. marec 2017 ob 08:04:40 CET je Chen-Yu Tsai napisal(a):
> According to the BSP released by Banana Pi, the R40 (sun8iw11p1) has
> an extra "PLL lock control" register in the CCU, which controls whether
> the individual PLL lock status bits in each PLL's control register work
> or not.
> 

This register is also present on A64, but I'm not sure if it is needed there.

Best regards,
Jernej

> This patch enables it for all the PLLs.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 2 ++
>  arch/arm/mach-sunxi/clock_sun6i.c | 5 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h index
> 1bfb48bd52df..1aefd5a64c1f 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -142,6 +142,8 @@ struct sunxi_ccm_reg {
>   u32 apb2_reset_cfg; /* 0x2d8 APB2 Reset config */
>   u32 reserved25[5];
>   u32 ccu_sec_switch; /* 0x2f0 CCU Security Switch, H3 only */
> + u32 reserved26[11];
> + u32 pll_lock_ctrl;  /* 0x320 PLL lock control, R40 only */
>  };
> 
>  /* apb2 bit field */
> diff --git a/arch/arm/mach-sunxi/clock_sun6i.c
> b/arch/arm/mach-sunxi/clock_sun6i.c index 4762fbf0c3f0..3c8c53fcf76b 100644
> --- a/arch/arm/mach-sunxi/clock_sun6i.c
> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
> @@ -35,6 +35,11 @@ void clock_init_safe(void)
>   clrbits_le32(&prcm->pll_ctrl1, PRCM_PLL_CTRL_LDO_KEY_MASK);
>  #endif
> 
> +#ifdef CONFIG_MACH_SUN8I_R40
> + /* Set PLL lock enable bits and switch to old lock mode */
> + writel(GENMASK(12, 0), &ccm->pll_lock_ctrl);
> +#endif
> +
>   clock_set_pll1(40800);
> 
>   writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
> --
> 2.11.0
> 
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group. To unsubscribe from this group and stop receiving
> emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


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


[U-Boot] [PATCH v2 8/8] dts: stv0991: Add trigger-address property to QSPI device

2017-03-01 Thread Rush, Jason A.
Add the 'cdns,trigger-address' property to the cadence QSPI device
node for the ST STV0991 application board.

Signed-off-by: Jason A. Rush 
---
Changed in v2:
 - renamed trigger-base to trigger-address

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

diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
index fa3fd641b2..f83b1efd9d 100644
--- a/arch/arm/dts/stv0991.dts
+++ b/arch/arm/dts/stv0991.dts
@@ -33,6 +33,7 @@
<0x4000 0x100>;
clocks = <375>;
sram-size = <256>;
+   trigger-address = <0x4000>;
status = "okay";
 
flash0: n25q32@0 {
-- 
2.11.0

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


[U-Boot] [PATCH v2 7/8] dts: k2g: Add trigger-address property to QSPI device

2017-03-01 Thread Rush, Jason A.
Add the 'cdns,trigger-address' property to the cadence QSPI device
node for Texas Instruments K2G SoC devices.

Signed-off-by: Jason A. Rush 
---
Changed in v2:
 - renamed trigger-base to trigger-address

 arch/arm/dts/keystone-k2g.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/keystone-k2g.dtsi b/arch/arm/dts/keystone-k2g.dtsi
index 2193f9fa21..d49d419b05 100644
--- a/arch/arm/dts/keystone-k2g.dtsi
+++ b/arch/arm/dts/keystone-k2g.dtsi
@@ -95,6 +95,7 @@
num-cs = <4>;
fifo-depth = <256>;
sram-size = <256>;
+   trigger-address = <0x2400>;
status = "disabled";
};
 
-- 
2.11.0

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


[U-Boot] [PATCH v2 6/8] dts: socfpga: Add trigger-address property to QSPI device

2017-03-01 Thread Rush, Jason A.
Add the 'cdns,trigger-address' property to the cadence QSPI device
node for Altera SoC devices.

Signed-off-by: Jason A. Rush 
---
Changed in v2:
 - renamed trigger-base to trigger-address

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

diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 8588221e57..ac26d05722 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -646,6 +646,7 @@
num-cs = <4>;
fifo-depth = <128>;
sram-size = <128>;
+   trigger-address = <0x>;
bus-num = <2>;
status = "disabled";
};
-- 
2.11.0

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


[U-Boot] [PATCH v2 5/8] spi: cadence_spi: Add cdns, trigger-address DT property

2017-03-01 Thread Rush, Jason A.
The socfpga arch uses a different value for the indaddrtrig reg than
the ahbbase address. Adopting the trigger-address DT bindings from
the Linux kernel allows the indaddrtrig reg to be set correctly on
the socfpga arch.

Tested on Terasic SoCKit dev board (Altera Cyclone V)

Signed-off-by: Jason A. Rush 
---
Changed in v2:
 - renamed DT property to trigger-address
 - load trigger-address as a u32

 drivers/spi/cadence_qspi.c | 1 +
 drivers/spi/cadence_qspi.h | 1 +
 drivers/spi/cadence_qspi_apb.c | 4 ++--
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 09f2ec3528..92d08eb3c6 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -300,6 +300,7 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
}
 
plat->sram_size = fdtdec_get_int(blob, node, "sram-size", 128);
+   plat->trigger_address = fdtdec_get_uint(blob, node, "trigger-address", 
0);
 
/* All other paramters are embedded in the child node */
subnode = fdt_first_subnode(blob, node);
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index da21b1346d..d607974cbe 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -26,6 +26,7 @@ struct cadence_spi_platdata {
u32 tchsh_ns;
u32 tslch_ns;
u32 sram_size;
+   u32 trigger_address;
 };
 
 struct cadence_spi_priv {
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 52ec892c4a..89fa3eaa21 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -559,7 +559,7 @@ int cadence_qspi_apb_indirect_read_setup(struct 
cadence_spi_platdata *plat,
addr_bytes = cmdlen - 1;
 
/* Setup the indirect trigger address */
-   writel((u32)plat->ahbbase,
+   writel(plat->trigger_address,
   plat->regbase + CQSPI_REG_INDIRECTTRIGGER);
 
/* Configure the opcode */
@@ -699,7 +699,7 @@ int cadence_qspi_apb_indirect_write_setup(struct 
cadence_spi_platdata *plat,
return -EINVAL;
}
/* Setup the indirect trigger address */
-   writel((u32)plat->ahbbase,
+   writel(plat->trigger_address,
   plat->regbase + CQSPI_REG_INDIRECTTRIGGER);
 
/* Configure the opcode */
-- 
2.11.0

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


[U-Boot] [PATCH v2 4/8] spi: cadence_qspi: Cleanup register loading/accesses

2017-03-01 Thread Rush, Jason A.
Load the regbase/ahbbase 'reg' DT properties using the standard
dev_get_addr_index function, and add __iomem to all register variables
declarations.

Signed-off-by: Jason A. Rush 
---
Changed in v2: None

 drivers/spi/cadence_qspi.c | 25 ++---
 drivers/spi/cadence_qspi.h | 28 ++--
 drivers/spi/cadence_qspi_apb.c | 24 
 3 files changed, 40 insertions(+), 37 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 9a6e41f330..09f2ec3528 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -40,7 +40,7 @@ static int cadence_spi_write_speed(struct udevice *bus, uint 
hz)
 static int spi_calibration(struct udevice *bus, uint hz)
 {
struct cadence_spi_priv *priv = dev_get_priv(bus);
-   void *base = priv->regbase;
+   void __iomem *base = priv->regbase;
u8 opcode_rdid = 0x9F;
unsigned int idcode = 0, temp = 0;
int err = 0, i, range_lo = -1, range_hi = -1;
@@ -190,7 +190,7 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
struct cadence_spi_platdata *plat = bus->platdata;
struct cadence_spi_priv *priv = dev_get_priv(bus);
struct dm_spi_slave_platdata *dm_plat = dev_get_parent_platdata(dev);
-   void *base = priv->regbase;
+   void __iomem *base = priv->regbase;
u8 *cmd_buf = priv->cmd_buf;
size_t data_bytes;
int err = 0;
@@ -284,18 +284,21 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
const void *blob = gd->fdt_blob;
int node = dev_of_offset(bus);
int subnode;
-   u32 data[4];
-   int ret;
 
-   /* 2 base addresses are needed, lets get them from the DT */
-   ret = fdtdec_get_int_array(blob, node, "reg", data, ARRAY_SIZE(data));
-   if (ret) {
-   printf("Error: Can't get base addresses (ret=%d)!\n", ret);
-   return -ENODEV;
+   /* Load the regbase from the first 'reg' property */
+   plat->regbase = (void __iomem *)dev_get_addr_index(bus, 0);
+   if (IS_ERR(plat->regbase)) {
+   printf("Error: Can't get regbase address!\n");
+   return PTR_ERR(plat->regbase);
+   }
+
+   /* Load the ahbbase from the second 'reg' property */
+   plat->ahbbase = (void __iomem *)dev_get_addr_index(bus, 1);
+   if (IS_ERR(plat->ahbbase)) {
+   printf("Error: Can't get ahbbase address!\n");
+   return PTR_ERR(plat->ahbbase);
}
 
-   plat->regbase = (void *)data[0];
-   plat->ahbbase = (void *)data[2];
plat->sram_size = fdtdec_get_int(blob, node, "sram-size", 128);
 
/* All other paramters are embedded in the child node */
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index d1927a4003..da21b1346d 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -16,8 +16,8 @@
 
 struct cadence_spi_platdata {
unsigned intmax_hz;
-   void*regbase;
-   void*ahbbase;
+   void __iomem*regbase;
+   void __iomem*ahbbase;
 
u32 page_size;
u32 block_size;
@@ -29,8 +29,8 @@ struct cadence_spi_platdata {
 };
 
 struct cadence_spi_priv {
-   void*regbase;
-   void*ahbbase;
+   void __iomem*regbase;
+   void __iomem*ahbbase;
size_t  cmd_len;
u8  cmd_buf[32];
size_t  data_len;
@@ -43,12 +43,12 @@ struct cadence_spi_priv {
 
 /* Functions call declaration */
 void cadence_qspi_apb_controller_init(struct cadence_spi_platdata *plat);
-void cadence_qspi_apb_controller_enable(void *reg_base_addr);
-void cadence_qspi_apb_controller_disable(void *reg_base_addr);
+void cadence_qspi_apb_controller_enable(void __iomem *reg_base_addr);
+void cadence_qspi_apb_controller_disable(void __iomem *reg_base_addr);
 
-int cadence_qspi_apb_command_read(void *reg_base_addr,
+int cadence_qspi_apb_command_read(void __iomem *reg_base_addr,
unsigned int cmdlen, const u8 *cmdbuf, unsigned int rxlen, u8 *rxbuf);
-int cadence_qspi_apb_command_write(void *reg_base_addr,
+int cadence_qspi_apb_command_write(void __iomem *reg_base_addr,
unsigned int cmdlen, const u8 *cmdbuf,
unsigned int txlen,  const u8 *txbuf);
 
@@ -61,17 +61,17 @@ int cadence_qspi_apb_indirect_write_setup(struct 
cadence_spi_platdata *plat,
 int cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata *plat,
unsigned int txlen, const u8 *txbuf);
 
-void cadence_qspi_apb_chipselect(void *reg_base,
+void cadence_qspi_apb_chipselect(void __iomem *reg_base,
unsigned int chip_select, unsigned int decoder_enable);
-void cadence_qspi_apb_set_clk_mode(void *reg_base, uint mode);
-void cadence_qspi_apb_config_baudrate_div(void *reg_base,
+void cadence_qspi_apb_set_clk_m

[U-Boot] [PATCH v2 3/8] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

2017-03-01 Thread Rush, Jason A.
From: Vignesh R 

According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
data interface writes until the last word of an indirect transfer
otherwise indirect writes is known to fails sometimes. So, make sure
that QSPI indirect writes are 32 bit sized except for the last write.

[1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf

Signed-off-by: Vignesh R 
Signed-off-by: Jason A. Rush 
---
Changed in v2:
 - changed reg name to match current reg names

 drivers/spi/cadence_qspi_apb.c | 41 +++--
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index df6a91fc9f..907c6edf0a 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -722,23 +722,44 @@ int cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_platdata *plat,
 {
unsigned int page_size = plat->page_size;
unsigned int remaining = n_tx;
-   unsigned int write_bytes;
+   unsigned int write_bytes = 0;
int ret;
 
+   /* Handle non-4-byte aligned access to avoid data abort. */
+   if ((uintptr_t) txbuf % 4) {
+   write_bytes = n_tx > 3 ? 4 - ((uintptr_t)txbuf % 4) : n_tx;
+   /* Configure the indirect read transfer bytes */
+   writel(write_bytes, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
+   /* Start the indirect write transfer */
+   writel(CQSPI_REG_INDIRECTWR_START,
+  plat->regbase + CQSPI_REG_INDIRECTWR);
+   writesb(plat->ahbbase, txbuf, write_bytes);
+   txbuf += write_bytes;
+   remaining -= write_bytes;
+   if (remaining > 0) {
+   u32 start_addr = readl(plat->regbase +
+  CQSPI_REG_INDIRECTWRSTARTADDR);
+   start_addr += write_bytes;
+   writel(start_addr, plat->regbase +
+  CQSPI_REG_INDIRECTWRSTARTADDR);
+   }
+   }
+
/* Configure the indirect read transfer bytes */
-   writel(n_tx, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
+   writel(n_tx - write_bytes, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
 
-   /* Start the indirect write transfer */
-   writel(CQSPI_REG_INDIRECTWR_START,
-  plat->regbase + CQSPI_REG_INDIRECTWR);
+   if (remaining > 0)
+   writel(CQSPI_REG_INDIRECTWR_START,
+  plat->regbase + CQSPI_REG_INDIRECTWR);
 
while (remaining > 0) {
write_bytes = remaining > page_size ? page_size : remaining;
-   /* Handle non-4-byte aligned access to avoid data abort. */
-   if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
-   writesb(plat->ahbbase, txbuf, write_bytes);
-   else
-   writesl(plat->ahbbase, txbuf, write_bytes >> 2);
+
+   writesl(plat->ahbbase, txbuf, write_bytes >> 2);
+   if (write_bytes % 4)
+   writesb(plat->ahbbase,
+   txbuf + rounddown(write_bytes, 4),
+   write_bytes % 4);
 
ret = wait_for_bit("QSPI", plat->regbase + CQSPI_REG_SDRAMLEVEL,
   CQSPI_REG_SDRAMLEVEL_WR_MASK <<
-- 
2.11.0

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


[U-Boot] [PATCH v2 2/8] Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible"

2017-03-01 Thread Rush, Jason A.
This reverts commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f.

The Cadence QSPI device does not work with caching (introduced with
the bounce buffer in this commit) on the Altera SoC platform.

Signed-off-by: Jason A. Rush 
---
Changed in v2: None

 drivers/spi/cadence_qspi_apb.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index a6787c3b47..df6a91fc9f 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -633,8 +633,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
 {
unsigned int remaining = n_rx;
unsigned int bytes_to_read = 0;
-   struct bounce_buffer bb;
-   u8 *bb_rxbuf;
int ret;
 
writel(n_rx, plat->regbase + CQSPI_REG_INDIRECTRDBYTES);
@@ -643,11 +641,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
writel(CQSPI_REG_INDIRECTRD_START,
   plat->regbase + CQSPI_REG_INDIRECTRD);
 
-   ret = bounce_buffer_start(&bb, (void *)rxbuf, n_rx, GEN_BB_WRITE);
-   if (ret)
-   return ret;
-   bb_rxbuf = bb.bounce_buffer;
-
while (remaining > 0) {
ret = cadence_qspi_wait_for_data(plat);
if (ret < 0) {
@@ -661,13 +654,12 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
bytes_to_read *= CQSPI_FIFO_WIDTH;
bytes_to_read = bytes_to_read > remaining ?
remaining : bytes_to_read;
-   readsl(plat->ahbbase, bb_rxbuf, bytes_to_read >> 2);
-   if (bytes_to_read % 4)
-   readsb(plat->ahbbase,
-  bb_rxbuf + rounddown(bytes_to_read, 4),
-  bytes_to_read % 4);
-
-   bb_rxbuf += bytes_to_read;
+   /* Handle non-4-byte aligned access to avoid data 
abort. */
+   if (((uintptr_t)rxbuf % 4) || (bytes_to_read % 4))
+   readsb(plat->ahbbase, rxbuf, bytes_to_read);
+   else
+   readsl(plat->ahbbase, rxbuf, bytes_to_read >> 
2);
+   rxbuf += bytes_to_read;
remaining -= bytes_to_read;
bytes_to_read = cadence_qspi_get_rd_sram_level(plat);
}
@@ -684,7 +676,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
/* Clear indirect completion status */
writel(CQSPI_REG_INDIRECTRD_DONE,
   plat->regbase + CQSPI_REG_INDIRECTRD);
-   bounce_buffer_stop(&bb);
 
return 0;
 
@@ -692,7 +683,6 @@ failrd:
/* Cancel the indirect read */
writel(CQSPI_REG_INDIRECTRD_CANCEL,
   plat->regbase + CQSPI_REG_INDIRECTRD);
-   bounce_buffer_stop(&bb);
return ret;
 }
 
-- 
2.11.0

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


[U-Boot] [PATCH v2 1/8] Revert "spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible"

2017-03-01 Thread Rush, Jason A.
This reverts commit 57897c13de03ac0136d64641a3eab526c6810387.

The Cadence QSPI device does not work with caching (introduced with
the bounce buffer in this commit) on the Altera SoC platform.

Signed-off-by: Jason A. Rush 
---
Changed in v2: None

 drivers/spi/cadence_qspi_apb.c   | 26 ++
 include/configs/k2g_evm.h|  1 -
 include/configs/socfpga_common.h |  1 -
 include/configs/stv0991.h|  1 -
 4 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index e02f2217f4..a6787c3b47 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "cadence_qspi.h"
 
 #define CQSPI_REG_POLL_US  1 /* 1us */
@@ -735,17 +734,6 @@ int cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_platdata *plat,
unsigned int remaining = n_tx;
unsigned int write_bytes;
int ret;
-   struct bounce_buffer bb;
-   u8 *bb_txbuf;
-
-   /*
-* Handle non-4-byte aligned accesses via bounce buffer to
-* avoid data abort.
-*/
-   ret = bounce_buffer_start(&bb, (void *)txbuf, n_tx, GEN_BB_READ);
-   if (ret)
-   return ret;
-   bb_txbuf = bb.bounce_buffer;
 
/* Configure the indirect read transfer bytes */
writel(n_tx, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
@@ -756,11 +744,11 @@ int cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_platdata *plat,
 
while (remaining > 0) {
write_bytes = remaining > page_size ? page_size : remaining;
-   writesl(plat->ahbbase, bb_txbuf, write_bytes >> 2);
-   if (write_bytes % 4)
-   writesb(plat->ahbbase,
-   bb_txbuf + rounddown(write_bytes, 4),
-   write_bytes % 4);
+   /* Handle non-4-byte aligned access to avoid data abort. */
+   if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
+   writesb(plat->ahbbase, txbuf, write_bytes);
+   else
+   writesl(plat->ahbbase, txbuf, write_bytes >> 2);
 
ret = wait_for_bit("QSPI", plat->regbase + CQSPI_REG_SDRAMLEVEL,
   CQSPI_REG_SDRAMLEVEL_WR_MASK <<
@@ -770,7 +758,7 @@ int cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_platdata *plat,
goto failwr;
}
 
-   bb_txbuf += write_bytes;
+   txbuf += write_bytes;
remaining -= write_bytes;
}
 
@@ -781,7 +769,6 @@ int cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_platdata *plat,
printf("Indirect write completion error (%i)\n", ret);
goto failwr;
}
-   bounce_buffer_stop(&bb);
 
/* Clear indirect completion status */
writel(CQSPI_REG_INDIRECTWR_DONE,
@@ -792,7 +779,6 @@ failwr:
/* Cancel the indirect write */
writel(CQSPI_REG_INDIRECTWR_CANCEL,
   plat->regbase + CQSPI_REG_INDIRECTWR);
-   bounce_buffer_stop(&bb);
return ret;
 }
 
diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index bd252312a2..a5e72a331b 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -73,7 +73,6 @@
 #define CONFIG_CADENCE_QSPI
 #define CONFIG_CQSPI_REF_CLK 38400
 #define CONFIG_CQSPI_DECODER 0x0
-#define CONFIG_BOUNCE_BUFFER
 #endif
 
 #endif /* __CONFIG_K2G_EVM_H */
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 582b04af3d..a3fa28c791 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -200,7 +200,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #define CONFIG_CQSPI_REF_CLK   cm_get_qspi_controller_clk_hz()
 #endif
 #define CONFIG_CQSPI_DECODER   0
-#define CONFIG_BOUNCE_BUFFER
 
 /*
  * Designware SPI support
diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h
index 24dd81856b..5d180d7419 100644
--- a/include/configs/stv0991.h
+++ b/include/configs/stv0991.h
@@ -71,7 +71,6 @@
 #ifdef CONFIG_OF_CONTROL   /* QSPI is controlled via DT */
 #define CONFIG_CQSPI_DECODER   0
 #define CONFIG_CQSPI_REF_CLK   ((30/4)/2)*1000*1000
-#define CONFIG_BOUNCE_BUFFER
 
 #endif
 
-- 
2.11.0

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


[U-Boot] [PATCH v2 0/8] spi: cadence: Fix read/write on socfpga

2017-03-01 Thread Rush, Jason A.
This patch series addresses two problems with reads/writes not
working with the Cadence QSPI device on the socfpga arch.

The first issue is reads/writes to the Cadence QSPI device
do not work correctly with caching enabled on the socfpga.
This problem was introduced with previous commits that use
a bounce buffer to support unaligned read/writes. Patches 1-3
address this issue by replacing the bounce buffer with a
non-cached version.

The second issue with the Cadence QSPI device on the socfpga
device is that the indaddrtrig register needs a different value
than the ahbbase address.  Adopting the trigger-address DT
bindings from the Linux kernel allows the indaddrtrig reg to
be set correctly for the socfpga arch.

Jason A. Rush (7):
  Revert "spi: cadence_qspi_apb: Use 32 bit indirect write transaction
when possible"
  Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction
when possible"
  spi: cadence_qspi: Cleanup register loading/accesses
  spi: cadence_spi: Add cdns,trigger-address DT property
  dts: socfpga: Add trigger-address property to QSPI device
  dts: k2g: Add trigger-address property to QSPI device
  dts: stv0991: Add trigger-address property to QSPI device

Vignesh R (1):
  spi: cadence_qspi_apb: Use 32 bit indirect write transaction when
possible

 arch/arm/dts/keystone-k2g.dtsi   |  1 +
 arch/arm/dts/socfpga.dtsi|  1 +
 arch/arm/dts/stv0991.dts |  1 +
 drivers/spi/cadence_qspi.c   | 26 ++-
 drivers/spi/cadence_qspi.h   | 29 ++--
 drivers/spi/cadence_qspi_apb.c   | 99 +++-
 include/configs/k2g_evm.h|  1 -
 include/configs/socfpga_common.h |  1 -
 include/configs/stv0991.h|  1 -
 9 files changed, 81 insertions(+), 79 deletions(-)

-- 
2.11.0

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


Re: [U-Boot] [linux-sunxi] [PATCH 6/8] power: axp209: Add support for voltage rate control on LDO3

2017-03-01 Thread Chen-Yu Tsai
On Thu, Mar 2, 2017 at 12:02 AM, Olliver Schinagl
 wrote:
> Hey Marcus,
>
> On 01-03-17 16:10, Marcus Weseloh wrote:
>>
>> Hi Oliver,
>>
>> 2017-03-01 13:52 GMT+01:00 Olliver Schinagl > >:
>>
>> +#define AXP209_VRC_LDO3_EN BIT(3)
>> +#define AXP209_VRC_DCDC2_ENBIT(2)
>> +#define AXP209_VRC_LDO3_800uV_uS   (BIT(1) | AXP209_VRC_LDO3_EN)
>> +#define AXP209_VRC_LDO3_1600uV_uS  AXP209_VRC_LDO3_EN
>>
>>
>> Does that mean that the description of the LDO3/DCDC2 VRC control on the
>> linux-sunxi wiki [1] and the PDF datasheet [2] are wrong? They say that
>> VRC for LDO3 is enabled if the bit is 0, disabled when the bit is 1. And
>> that the default value is enabled.
>
>
> Yes you are correct (and well spotted) that the datasheet is wrong. It took
> us some time to figure out why it wasn't working :)
>
> I thought I updated the wiki, but I must have done it incorrectly. I will
> fix it immediatly.

Please also leave a note there saying the datasheet is wrong.

Thanks
ChenYu

>
> olliver
>
>
>
>>
>> [1]
>>
>> http://linux-sunxi.org/AXP209#REG_25H:_DC-DC2.2FLDO3_dynamic_voltage_scaling_parameter_settings
>> [2] http://dl.linux-sunxi.org/AXP/AXP209_Datasheet_v1.0en.pdf
>>
>> Cheers,
>>
>>   Marcus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [linux-sunxi] Re: [PATCH 14/17] sunxi: Pine64: defconfig: enable SPL FIT support

2017-03-01 Thread Icenowy Zheng

2017年3月1日 23:51于 Maxime Ripard 写道:
>
> Hi Andre, 
>
> On Wed, Mar 01, 2017 at 02:25:26AM +, Andre Przywara wrote: 
> > The Pine64 (and all other 64-bit Allwinner boards) need to load an 
> > ARM Trusted Firmware image beside the actual U-Boot proper. 
> > This can now be easily achieved by using the just extended SPL FIT 
> > loading support, so enable it in the Pine64 defconfig. 
> > Also add the FIT image as a build target to 64-bit sunxi board to 
> > trigger the respective Makefile rules. 
> > 
> > Signed-off-by: Andre Przywara  
> > --- 
> >  configs/pine64_plus_defconfig  | 6 ++ 
> >  include/configs/sunxi-common.h | 4  
> >  2 files changed, 10 insertions(+) 
> > 
> > diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig 
> > index 7c7d86f..2b47157 100644 
> > --- a/configs/pine64_plus_defconfig 
> > +++ b/configs/pine64_plus_defconfig 
> > @@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y 
> >  CONFIG_ARCH_SUNXI=y 
> >  CONFIG_MACH_SUN50I=y 
> >  CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus" 
> > +CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus" 
> >  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set 
> >  CONFIG_CONSOLE_MUX=y 
> >  CONFIG_SPL=y 
> > +CONFIG_FIT=y 
> > +CONFIG_SPL_FIT=y 
> > +CONFIG_SPL_LOAD_FIT=y 
> > +CONFIG_SPL_OF_LIBFDT=y 
>
> I'm not sure we want to force down that support to all our users. 

A64 boards are now unusable without proper ATF.

>
> We should definitely make that easy (basically just switching on an 
> option), for example a few selects here might be good. But switching 
> that on, and only for a few boards seems both weird and inconsistent. 
>
> >  # CONFIG_CMD_IMLS is not set 
> >  # CONFIG_CMD_FLASH is not set 
> >  # CONFIG_CMD_FPGA is not set 
> > @@ -14,3 +19,4 @@ CONFIG_SPL=y 
> >  # CONFIG_SPL_EFI_PARTITION is not set 
> >  CONFIG_SUN8I_EMAC=y 
> >  CONFIG_USB_EHCI_HCD=y 
> > +CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh" 
>
> And that could be a default value. 
>
> Maxime 
>
> -- 
> Maxime Ripard, Free Electrons 
> Embedded Linux and Kernel engineering 
> http://free-electrons.com 
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group. 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com. 
> For more options, visit https://groups.google.com/d/optout. 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1] tools: Remove CONFIG_SYS_TEXT_BASE in Makefile

2017-03-01 Thread Tom Rini
On Tue, Feb 28, 2017 at 07:29:11PM +0100, Patrick Delaunay wrote:

> This define is not used in tools sources and can be removed
> to avoid unnecessary link between tools and defconfig
> 
> Signed-off-by: Patrick Delaunay 

Reviewed-by: Tom Rini 

-- 
Tom


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


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

2017-03-01 Thread Tom Rini
On Mon, Feb 27, 2017 at 06:22:15PM +0100, 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 
> Reviewed-by: Hans de Goede 
> ---
>  configs/CHIP_pro_defconfig | 33 +
[snip]
> +CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,SYS_NAND_BLOCK_SIZE=0x4,SYS_NAND_PAGE_SIZE=4096,SYS_NAND_OOBSIZE=256"

Conversion itself won't be fun (I can see it'll take some regex'ing
before hand to convert various values to a number) but can you please
add Kconfig entires for SYS_NAND_xxx values and populate those for this
baord instead of adding more SYS_EXTRA_OPTIONS?  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] armv5te: make 'ret lr' produce iinterworking 'bx lr'

2017-03-01 Thread Tom Rini
On Mon, Feb 27, 2017 at 08:19:07PM +0100, Albert ARIBAUD wrote:
> Current ARM assembler helper for the 'return to caller' pseudo-instruction
> turns 'ret lr' into 'mov pc, lr' for ARMv5TE. This causes the core to remain
> in its current ARM state even when the routine doing the 'ret' was called
> from Thumb-1 state, triggering an undefined instruction exception.
> 
> This causes early run-time failures in all boards compiled using the Thumb-1
> instruction set (for instance the Open-RD family).
> 
> ARMv5TE supports 'bx lr' which properly implements interworking and thus
> correctly returns to Thumb-1 state from ARM state.
> 
> This change makes 'ret lr' turn into 'bx lr' for ARMv5TE.
> 
> Signed-off-by: Albert ARIBAUD 
> ---
> Note: this patch supersedes patch "openrd: disable private arch memset,
> memcpy and libgcc" dated Sun, 26 Feb 2017 16:29:32 +0100.
> 
>  arch/arm/include/asm/assembler.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/assembler.h 
> b/arch/arm/include/asm/assembler.h
> index ae1e42fc06..c56daf2a1f 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -59,7 +59,7 @@
>  
>   .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
>   .macro  ret\c, reg
> -#if defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__)
> +#if defined(__ARM_ARCH_5E__)
>   mov\c   pc, \reg
>  #else
>   .ifeqs  "\reg", "lr"

Emperical wins over theory, so I'll take this patch so we don't break
things.  But looking at the kernel, the above is a test for
__LINUX_ARM_ARCH__ < 6 instead.  But the kernel is hardly ever built and
run in Thumb mode rather than ARM mode, so they wouldn't be tickling
this particular issue.  I guess my big question now is, when can /
should we not just use 'bx lr' over 'mov pc, lr' ?

-- 
Tom


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


Re: [U-Boot] [PATCH 14/17] sunxi: Pine64: defconfig: enable SPL FIT support

2017-03-01 Thread Maxime Ripard
Hi Andre,

On Wed, Mar 01, 2017 at 02:25:26AM +, Andre Przywara wrote:
> The Pine64 (and all other 64-bit Allwinner boards) need to load an
> ARM Trusted Firmware image beside the actual U-Boot proper.
> This can now be easily achieved by using the just extended SPL FIT
> loading support, so enable it in the Pine64 defconfig.
> Also add the FIT image as a build target to 64-bit sunxi board to
> trigger the respective Makefile rules.
> 
> Signed-off-by: Andre Przywara 
> ---
>  configs/pine64_plus_defconfig  | 6 ++
>  include/configs/sunxi-common.h | 4 
>  2 files changed, 10 insertions(+)
> 
> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
> index 7c7d86f..2b47157 100644
> --- a/configs/pine64_plus_defconfig
> +++ b/configs/pine64_plus_defconfig
> @@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_MACH_SUN50I=y
>  CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
> +CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus"
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  CONFIG_CONSOLE_MUX=y
>  CONFIG_SPL=y
> +CONFIG_FIT=y
> +CONFIG_SPL_FIT=y
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_SPL_OF_LIBFDT=y

I'm not sure we want to force down that support to all our users.

We should definitely make that easy (basically just switching on an
option), for example a few selects here might be good. But switching
that on, and only for a few boards seems both weird and inconsistent.

>  # CONFIG_CMD_IMLS is not set
>  # CONFIG_CMD_FLASH is not set
>  # CONFIG_CMD_FPGA is not set
> @@ -14,3 +19,4 @@ CONFIG_SPL=y
>  # CONFIG_SPL_EFI_PARTITION is not set
>  CONFIG_SUN8I_EMAC=y
>  CONFIG_USB_EHCI_HCD=y
> +CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh"

And that could be a default value.

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/listinfo/u-boot


Re: [U-Boot] arm: mach-omap2: Flush cache after FIT post-processing image

2017-03-01 Thread Tom Rini
On Wed, Feb 22, 2017 at 05:46:39PM -0600, Andrew F. Davis wrote:

> After we authenticate/decrypt an image we need to flush the caches
> as they may still contain bits of the encrypted image. This will
> cause failures if we attempt to jump to this image.
> 
> Reported-by: Yogesh Siraswar
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Tom Rini 

Applied prior to v2017.03-rc3 to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v3 00/10] stm32f7: add clock and pin control drivers

2017-03-01 Thread Tom Rini
On Mon, Feb 27, 2017 at 05:33:58PM +, Vikas MANOCHA wrote:

> Hi Tom,
> 
> If it is ok,  please apply this patchset.

I'll pick it up early in the next release, thanks!

-- 
Tom


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


Re: [U-Boot] [PULL] Please pull u-boot-imx

2017-03-01 Thread Tom Rini
On Mon, Feb 27, 2017 at 06:08:59PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> 
> The following changes since commit 66c246cce7c66019a93ff7105157c3e2126dd277:
> 
>   ARM: DRA7xx: Fix memory allocation overflow (2017-02-17 17:24:35 -0500)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to dc05e47a10b11f4266e3a41df96748d486193e6d:
> 
>   tqma6: [cosmetic] sanitize environment defines (2017-02-19 17:16:51 +0100)
> 

Applied prior to v2017.03-rc3 to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/3] drivers/net/Kconfig: Correct use of apostrophe

2017-03-01 Thread Tom Rini
On Mon, Feb 20, 2017 at 09:38:03AM -0500, Tom Rini wrote:

> Signed-off-by: Tom Rini 

Applied prior to v2017.03-rc3 to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] arm: OMAP2+: nandecc: propagate error to command return status

2017-03-01 Thread Tom Rini
On Sun, Feb 19, 2017 at 12:29:24AM +0100, Ladislav Michl wrote:

Please explain the changes a little bit here, thanks!

> Signed-off-by: Ladislav Michl 

-- 
Tom


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


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

2017-03-01 Thread Tom Rini
On Mon, Feb 27, 2017 at 04:22:54PM +0100, Anatolij Gustschin wrote:

> Hi Tom,
> 
> please pull two bug fixes for -rc3. Thanks!
> 
> The following changes since commit a0f3e3df4adc451bf56159c0672e570f9c934ee8:
> 
>   travis-ci: Temporarily disable using a newer device tree compiler 
> (2017-02-26 15:25:30 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-video.git master
> 
> for you to fetch changes up to 94412745cd4339f8f6fa7be5f3b460fde65eff85:
> 
>   rockchip: video: fix 8350 clock mistake in rockchip HDMI (2017-02-27 
> 16:10:45 +0100)
> 

Applied prior to v2017.03-rc3 to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] arm: dra7xx: Update bootloader partition size

2017-03-01 Thread Tom Rini
On Tue, Feb 21, 2017 at 09:51:31PM +0200, Sam Protsenko wrote:

> The current size of U-Boot is already ~840 KiB.
> 
> This patch is to increase bootloader partition size up to 1 MiB
> and thereby fix flashing error.
> 
> Also fix U-Boot environment address on eMMC ("reserved" partition), as
> it's being shifted by above change.
> 
> Signed-off-by: Sam Protsenko 

I know I'm late chiming in here, but I want to now, all the same.
First, we need to explain _why_ things are getting so huge.  The answer
is that we're including so many (complete, from Linux) device trees.  So
we should probably update the comments around this area to note why the
bootloader partition is so large, and then pick a good, large, and
aligned with the underlying erase block size partition.

-- 
Tom


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


Re: [U-Boot] i.MX6QP sd boot issue

2017-03-01 Thread Jagan Teki
Hi Fabio,

On Wed, Mar 1, 2017 at 7:46 PM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Wed, Mar 1, 2017 at 9:55 AM, Jagan Teki  wrote:
>> + ML
>>
>> On Wed, Mar 1, 2017 at 6:23 PM, Jagan Teki  wrote:
>>> Hi Peng and All,
>>>
>>> I'm trying to boot from SD, on imx6qplus sabre board.
>>>
>>> - SW6: D1-D8 => 0100 0010
>>> - SD card on SD3
>>> - D12 with USB-to-Serial 115200 8N1
>>> - Power supply Output 5V
>>>
>>> Build:
>>> $  make mx6qpsabreauto_defconfig; make
>>> $ dd if=u-boot.imx of=/dev/sda bs=512 seek=2
>
> I don't have a imx6qp sabresd board handy, but can you try the SPL
> config instead?
>
> make mx6sabresd_spl_defconfig
> dd if=SPL of=/dev/mmcblk0 bs=1k seek=1; sync
> dd if=u-boot.img of=/dev/mmcblk0 bs=1k seek=69; sync
>
> It worked for me the last time I tried it with mainline U-Boot.

Yes, able to boot with SPL config.

U-Boot SPL 2017.03-rc3 (Mar 01 2017 - 20:46:00)
Trying to boot from MMC1


U-Boot 2017.03-rc3 (Mar 01 2017 - 20:46:00 +0530)

CPU:   Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 35C
Reset cause: POR
Board: MX6-SabreSD
I2C:   ready
DRAM:  1 GiB
PMIC:  PFUZE100 ID=0x10
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
*** Warning - bad CRC, using default environment

PCI:   pcie phy link never came up
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0
=>

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/listinfo/u-boot


Re: [U-Boot] [linux-sunxi] Re: [PATCH 01/12] sunxi: Add initial support for R40

2017-03-01 Thread Icenowy Zheng


01.03.2017, 22:57, "Maxime Ripard" :
> 1;4601;0c
> On Wed, Mar 01, 2017 at 08:10:55PM +0800, Chen-Yu Tsai wrote:
>>  On Wed, Mar 1, 2017 at 6:55 PM, Maxime Ripard
>>   wrote:
>>  > Hi Chen-Yu
>>  >
>>  > On Wed, Mar 01, 2017 at 03:04:36PM +0800, Chen-Yu Tsai wrote:
>>  >> The R40 is the successor to the A20. It is a hybrid of the A20, A33
>>  >> and the H3.
>>  >>
>>  >> The R40's PIO controller is compatible with the A20,
>>  >> Reuse the A20 UART and I2C muxing code by adding the R40's macro.
>>  >>
>>  >> The display pipeline is the newer DE 2.0 variant.
>>  >> Block enabling video on R40 for now.
>>  >>
>>  >> Signed-off-by: Chen-Yu Tsai 
>>  >> ---
>>  >> arch/arm/mach-sunxi/board.c | 10 +++---
>>  >> arch/arm/mach-sunxi/cpu_info.c | 2 ++
>>  >> board/sunxi/Kconfig | 9 +++--
>>  >> board/sunxi/board.c | 19 ++-
>>  >> 4 files changed, 30 insertions(+), 10 deletions(-)
>>  >>
>>  >> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
>>  >> index 5e03d039433a..5a74c9717d84 100644
>>  >> --- a/arch/arm/mach-sunxi/board.c
>>  >> +++ b/arch/arm/mach-sunxi/board.c
>>  >> @@ -69,12 +69,14 @@ struct mm_region *mem_map = sunxi_mem_map;
>>  >> static int gpio_init(void)
>>  >> {
>>  >> #if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
>>  >> -#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
>>  >> +#if defined(CONFIG_MACH_SUN4I) || \
>>  >> + defined(CONFIG_MACH_SUN7I) || \
>>  >> + defined(CONFIG_MACH_SUN8I_R40)
>>  >> /* disable GPB22,23 as uart0 tx,rx to avoid conflict */
>>  >> sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUNXI_GPIO_INPUT);
>>  >> sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT);
>>  >> #endif
>>  >> -#if defined(CONFIG_MACH_SUN8I)
>>  >> +#if defined(CONFIG_MACH_SUN8I) && !defined(CONFIG_MACH_SUN8I_R40)
>>  >> sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0);
>>  >> sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
>>  >> #else
>>  >> @@ -82,7 +84,9 @@ static int gpio_init(void)
>>  >> sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0);
>>  >> #endif
>>  >> sunxi_gpio_set_pull(SUNXI_GPF(4), 1);
>>  >> -#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || 
>> defined(CONFIG_MACH_SUN7I))
>>  >> +#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || \
>>  >> + defined(CONFIG_MACH_SUN7I) || \
>>  >> + defined(CONFIG_MACH_SUN8I_R40))
>>  >> sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB_UART0);
>>  >> sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB_UART0);
>>  >> sunxi_gpio_set_pull(SUNXI_GPB(23), SUNXI_GPIO_PULL_UP);
>>  >> diff --git a/arch/arm/mach-sunxi/cpu_info.c 
>> b/arch/arm/mach-sunxi/cpu_info.c
>>  >> index 85633ccec216..7851de299ab5 100644
>>  >> --- a/arch/arm/mach-sunxi/cpu_info.c
>>  >> +++ b/arch/arm/mach-sunxi/cpu_info.c
>>  >> @@ -87,6 +87,8 @@ int print_cpuinfo(void)
>>  >> printf("CPU: Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
>>  >> #elif defined CONFIG_MACH_SUN8I_H3
>>  >> printf("CPU: Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
>>  >> +#elif defined CONFIG_MACH_SUN8I_R40
>>  >> + printf("CPU: Allwinner R40 (SUN8I %04x)\n", sunxi_get_sram_id());
>>  >> #elif defined CONFIG_MACH_SUN9I
>>  >> puts("CPU: Allwinner A80 (SUN9I)\n");
>>  >> #elif defined CONFIG_MACH_SUN50I
>>  >> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
>>  >> index 3e0e2624737e..8e8b9cd0d5fd 100644
>>  >> --- a/board/sunxi/Kconfig
>>  >> +++ b/board/sunxi/Kconfig
>>  >> @@ -132,6 +132,11 @@ config MACH_SUN8I_H3
>>  >> select MACH_SUNXI_H3_H5
>>  >> select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
>>  >>
>>  >> +config MACH_SUN8I_R40
>>  >> + bool "sun8i (Allwinner R40)"
>>  >> + select CPU_V7
>>  >> + select SUNXI_GEN_SUN6I
>>  >> +
>>  >> config MACH_SUN9I
>>  >> bool "sun9i (Allwinner A80)"
>>  >> select CPU_V7
>>  >> @@ -157,7 +162,7 @@ endchoice
>>  >> # The sun8i SoCs share a lot, this helps to avoid a lot of "if A23 || 
>> A33"
>>  >> config MACH_SUN8I
>>  >> bool
>>  >> - default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUNXI_H3_H5 || 
>> MACH_SUN8I_A83T
>>  >> + default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUNXI_H3_H5 || 
>> MACH_SUN8I_A83T || MACH_SUN8I_R40
>>  >
>>  > You should really wrap that line too (and CONFIG_VIDEO below).
>>
>>  Kconfig doesn't seem to like line wrapping. I can split both into
>>  1 symbol per line though. Would that be taking it to far?

Kconfig can accept line wrapping. But you need \.

>
> Something like:
>
> default y if MACH_SUN8I_A23
> default y if MACH_SUN8I_A33
>
> ?
>
> I didn't know it was possible.. But if it works, yes, please that will
> even be easier to review / extend.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googleg

Re: [U-Boot] [PATCH v4 3/7] usb: host: xhci-omap: fix double weak board_usb_init functions

2017-03-01 Thread Roger Quadros


On 23/02/17 15:39, Uri Mashiach wrote:
> A weak version of the function board_usb_init is implemented in:
> common/usb.c
> drivers/usb/host/xhci-omap.c
> 
> To fix the double implementations:
> * Convert the board_usb_init function in drivers/usb/host/xhci-omap.c
>   normal (not weak).
> * The function board_usb_init in drivers/usb/host/xhci-omap.c calls to
>   the weak function omap_xhci_board_usb_init.
> * Rename board version of the function board_usb_init to
>   omap_xhci_board_usb_init.
>   Done only for boards that defines CONFIG_USB_XHCI_OMAP.
> 
> To achieve the same flexibility with the function board_usb_cleanup:
> * Add a normal (not weak) implementation of the function
>   board_usb_cleanup in drivers/usb/host/xhci-omap.c
> * The function board_usb_cleanup in drivers/usb/host/xhci-omap.c calls
>   to the weak function omap_xhci_board_usb_cleanup.
> * Rename board version of the function board_usb_cleanup to
>   omap_xhci_board_usb_cleanup.
>   Done only for boards that defines CONFIG_USB_XHCI_OMAP.
> 
> Cc: Lokesh Vutla 
> Signed-off-by: Uri Mashiach 
> Acked-by: Marek Vasut 
> Reviewed-by: Tom Rini 

Reviewed-by: Roger Quadros 

> ---
> V1 -> V2: Use __weak instead of attribute block
> V2 -> V4: none
> 
>  board/compulab/cl-som-am57x/cl-som-am57x.c |  2 +-
>  board/ti/am43xx/board.c|  4 ++--
>  board/ti/am57xx/board.c|  4 ++--
>  board/ti/dra7xx/evm.c  |  4 ++--
>  drivers/usb/host/xhci-omap.c   | 17 +++--
>  5 files changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/board/compulab/cl-som-am57x/cl-som-am57x.c 
> b/board/compulab/cl-som-am57x/cl-som-am57x.c
> index bdd0a2b..fe1468f 100644
> --- a/board/compulab/cl-som-am57x/cl-som-am57x.c
> +++ b/board/compulab/cl-som-am57x/cl-som-am57x.c
> @@ -54,7 +54,7 @@ int board_mmc_init(bd_t *bis)
>  #endif /* CONFIG_GENERIC_MMC */
>  
>  #ifdef CONFIG_USB_XHCI_OMAP
> -int board_usb_init(int index, enum usb_init_type init)
> +int omap_xhci_board_usb_init(int index, enum usb_init_type init)
>  {
>   setbits_le32((*prcm)->cm_l3init_usb_otg_ss1_clkctrl,
>OTG_SS_CLKCTRL_MODULEMODE_HW | OPTFCLKEN_REFCLK960M);
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index 390cc16..2572029 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -694,7 +694,7 @@ int usb_gadget_handle_interrupts(int index)
>  #endif /* CONFIG_USB_DWC3 */
>  
>  #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
> -int board_usb_init(int index, enum usb_init_type init)
> +int omap_xhci_board_usb_init(int index, enum usb_init_type init)
>  {
>   enable_usb_clocks(index);
>  #ifdef CONFIG_USB_DWC3
> @@ -725,7 +725,7 @@ int board_usb_init(int index, enum usb_init_type init)
>   return 0;
>  }
>  
> -int board_usb_cleanup(int index, enum usb_init_type init)
> +int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
>  {
>  #ifdef CONFIG_USB_DWC3
>   switch (index) {
> diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
> index 1611514..4afa914 100644
> --- a/board/ti/am57xx/board.c
> +++ b/board/ti/am57xx/board.c
> @@ -618,7 +618,7 @@ int usb_gadget_handle_interrupts(int index)
>  #endif /* CONFIG_USB_DWC3 */
>  
>  #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
> -int board_usb_init(int index, enum usb_init_type init)
> +int omap_xhci_board_usb_init(int index, enum usb_init_type init)
>  {
>   enable_usb_clocks(index);
>   switch (index) {
> @@ -652,7 +652,7 @@ int board_usb_init(int index, enum usb_init_type init)
>   return 0;
>  }
>  
> -int board_usb_cleanup(int index, enum usb_init_type init)
> +int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
>  {
>  #ifdef CONFIG_USB_DWC3
>   switch (index) {
> diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
> index bd1c809..65bce93 100644
> --- a/board/ti/dra7xx/evm.c
> +++ b/board/ti/dra7xx/evm.c
> @@ -727,7 +727,7 @@ static struct ti_usb_phy_device usb_phy2_device = {
>   .index = 1,
>  };
>  
> -int board_usb_init(int index, enum usb_init_type init)
> +int omap_xhci_board_usb_init(int index, enum usb_init_type init)
>  {
>   enable_usb_clocks(index);
>   switch (index) {
> @@ -764,7 +764,7 @@ int board_usb_init(int index, enum usb_init_type init)
>   return 0;
>  }
>  
> -int board_usb_cleanup(int index, enum usb_init_type init)
> +int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
>  {
>   switch (index) {
>   case 0:
> diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
> index b881b19..a1b4f2f 100644
> --- a/drivers/usb/host/xhci-omap.c
> +++ b/drivers/usb/host/xhci-omap.c
> @@ -27,12 +27,25 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  static struct omap_xhci omap;
>  
> -__weak int __board_usb_init(int index, enum usb_init_type init)
> +__weak int omap_xhci_board_usb_init(int index, enum usb_init_type init)
>  {
>   return 0;
>  

Re: [U-Boot] [PATCH v4 3/7] usb: host: xhci-omap: fix double weak board_usb_init functions

2017-03-01 Thread Roger Quadros
On 01/03/17 11:12, Uri Mashiach wrote:
> On 02/28/2017 03:13 PM, Roger Quadros wrote:
>> On 28/02/17 10:00, Uri Mashiach wrote:
>>> Hi,
>>>
>>> On 02/27/2017 06:22 PM, Roger Quadros wrote:
 Hi,

 On 23/02/17 15:39, Uri Mashiach wrote:
> A weak version of the function board_usb_init is implemented in:
> common/usb.c
> drivers/usb/host/xhci-omap.c
> 
> [...]
> 
>  board/compulab/cl-som-am57x/cl-som-am57x.c |  2 +-
>  board/ti/am43xx/board.c|  4 ++--
>  board/ti/am57xx/board.c|  4 ++--
>  board/ti/dra7xx/evm.c  |  4 ++--
>  drivers/usb/host/xhci-omap.c   | 17 +++--

 What about board/ti/omap5_uevm/evm.c ?
>>>
>>> The symbol CONFIG_USB_XHCI_OMAP is not included in the file 
>>> include/configs/omap5_uevm.h, therefore:
>>> The file drivers/usb/host/xhci-omap.c is not included in the compilation - 
>>> no double implementations to fix.
>>>
>>
>> But if someone wants to use the XHCI host he will enable the 
>> CONFIG_USB_XHCI_OMAP for omap5_uevm right?
>> We need to ensure it doesn't break then.
>>
> Compilation errors are generated for compilation attempt of U-Boot for the 
> target ti/omap5_uevm with CONFIG_USB_XHCI_OMAP.
> Maybe the adjustments relevant for the current commit should be applied after 
> the CONFIG_USB_XHCI_OMAP adjustments?

I'm fine with that. 

> 
> Generated error messages:
> 
> In file included from include/asm/arch/sys_proto.h:12:0,
>  from /home/work/u-boot/board/ti/omap5_uevm/evm.c:12:
> /home/work/u-boot/board/ti/omap5_uevm/evm.c: In function 'enable_host_clocks':
> /home/work/u-boot/board/ti/omap5_uevm/evm.c:172:22: error: 'const struct 
> prcm_regs' has no member named 'cm_l3init_usb_otg_ss_clkctrl'
>   setbits_le32((*prcm)->cm_l3init_usb_otg_ss_clkctrl,
>   ^
> /home/work/u-boot/arch/arm/include/asm/io.h:78:55: note: in definition of 
> macro '__arch_putl'
>  #define __arch_putl(v,a)  (*(volatile unsigned int *)(a) = (v))
>^
> /home/work/u-boot/arch/arm/include/asm/io.h:175:35: note: in expansion of 
> macro '__raw_writel'
>  #define out_arch(type,endian,a,v) __raw_write##type(cpu_to_##endian(v),a)
>^
> /home/work/u-boot/arch/arm/include/asm/io.h:179:23: note: in expansion of 
> macro 'out_arch'
>  #define out_le32(a,v) out_arch(l,le32,a,v)
>^
> /home/work/u-boot/arch/arm/include/asm/io.h:199:2: note: in expansion of 
> macro 'out_le32'
>   out_##type((addr), in_##type(addr) | (set))
>   ^
> /home/work/u-boot/arch/arm/include/asm/io.h:209:33: note: in expansion of 
> macro 'setbits'
>  #define setbits_le32(addr, set) setbits(le32, addr, set)
>  ^
> /home/work/u-boot/board/ti/omap5_uevm/evm.c:172:2: note: in expansion of 
> macro 'setbits_le32'
>   setbits_le32((*prcm)->cm_l3init_usb_otg_ss_clkctrl,
>   ^
> /home/work/u-boot/board/ti/omap5_uevm/evm.c:172:22: error: 'const struct 
> prcm_regs' has no member named 'cm_l3init_usb_otg_ss_clkctrl'
>   setbits_le32((*prcm)->cm_l3init_usb_otg_ss_clkctrl,
>   ^
> /home/work/u-boot/arch/arm/include/asm/io.h:78:61: note: in definition of 
> macro '__arch_putl'
>  #define __arch_putl(v,a)  (*(volatile unsigned int *)(a) = (v))
>  ^
> /home/work/u-boot/arch/arm/include/asm/io.h:175:35: note: in expansion of 
> macro '__raw_writel'
>  #define out_arch(type,endian,a,v) __raw_write##type(cpu_to_##endian(v),a)
>^
> /home/work/u-boot/include/linux/byteorder/generic.h:89:21: note: in expansion 
> of macro '__cpu_to_le32'
>  #define cpu_to_le32 __cpu_to_le32
>  ^
> /home/work/u-boot/arch/arm/include/asm/io.h:179:23: note: in expansion of 
> macro 'out_arch'
>  #define out_le32(a,v) out_arch(l,le32,a,v)
>^
> /home/work/u-boot/arch/arm/include/asm/io.h:199:2: note: in expansion of 
> macro 'out_le32'
>   out_##type((addr), in_##type(addr) | (set))
>   ^
> /home/work/u-boot/include/linux/byteorder/generic.h:90:21: note: in expansion 
> of macro '__le32_to_cpu'
>  #define le32_to_cpu __le32_to_cpu
>  ^
> /home/work/u-boot/arch/arm/include/asm/io.h:133:25: note: in expansion of 
> macro '__arch_getl'
>  #define __raw_readl(a)  __arch_getl(a)
>  ^
> /home/work/u-boot/arch/arm/include/asm/io.h:176:49: note: in expansion of 
> macro '__raw_readl'
>  #define in_arch(type,endian,a)  endian##_to_cpu(__raw_read##type(a))
>  ^
> /home/work/u-boot/arch/arm/include/asm/io.h:183:20: note: in expansion of 
> macro 'in_arch'
>  #define in_le32(a) in_arch(l,le32,a)
> ^
> /home/work/u-boot/arch/arm/include/asm/io.h:199:21: note: in expansion of 
> macro 'in_le32'
>   out_##type((addr), in_##t

Re: [U-Boot] arm: cache: misaligned operation with fastboot

2017-03-01 Thread Gary Bisson
Hi Fabio, Lukasz,

On Wed, Feb 15, 2017 at 02:24:40PM -0200, Fabio Estevam wrote:
> On Wed, Feb 15, 2017 at 2:04 PM, Gary Bisson
>  wrote:
> > Hi,
> >
> > I've been testing fastboot to flash a sparse image on a i.MX6Q platform
> > (Nitrogen6x) with U-Boot v2017.01.
> >
> > This test shows a lot of "misaligned operation" traces:
> > => fastboot 0
> > Starting download of 415679660 bytes
> > ...
> > downloading of 415679660 bytes finished
> > Flashing sparse image at offset 82124
> > Flashing Sparse Image
> > CACHE: Misaligned operation at range [1228, 12028028]
> > CACHE: Misaligned operation at range [12028044, 1208f044]
> > CACHE: Misaligned operation at range [1208f060, 123fd060]
> > ...
> >
> > Has any of you seen that behavior?
> >
> > Note that this behavior only happens for sparse images, flashing a raw
> > image doesn't exhibit the problem.
> 
> Adding DFU maintainer, Lukasz on Cc.

Any update on this? Has anyone been able to reproduce?

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


Re: [U-Boot] [PATCH 12/12] sunxi: Add support for Bananapi M2 Ultra

2017-03-01 Thread Maxime Ripard
On Wed, Mar 01, 2017 at 03:04:47PM +0800, Chen-Yu Tsai wrote:
> The Bananapi M2 Ultra is the first publicly available development board
> featuring the R40 SoC.
> 
> This patch add barebone dtsi/dts files for the R40 and Bananapi M2 Ultra,
> as well as a defconfig for it.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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/listinfo/u-boot


Re: [U-Boot] [PATCH 01/12] sunxi: Add initial support for R40

2017-03-01 Thread Maxime Ripard
1;4601;0c
On Wed, Mar 01, 2017 at 08:10:55PM +0800, Chen-Yu Tsai wrote:
> On Wed, Mar 1, 2017 at 6:55 PM, Maxime Ripard
>  wrote:
> > Hi Chen-Yu
> >
> > On Wed, Mar 01, 2017 at 03:04:36PM +0800, Chen-Yu Tsai wrote:
> >> The R40 is the successor to the A20. It is a hybrid of the A20, A33
> >> and the H3.
> >>
> >> The R40's PIO controller is compatible with the A20,
> >> Reuse the A20 UART and I2C muxing code by adding the R40's macro.
> >>
> >> The display pipeline is the newer DE 2.0 variant.
> >> Block enabling video on R40 for now.
> >>
> >> Signed-off-by: Chen-Yu Tsai 
> >> ---
> >>  arch/arm/mach-sunxi/board.c| 10 +++---
> >>  arch/arm/mach-sunxi/cpu_info.c |  2 ++
> >>  board/sunxi/Kconfig|  9 +++--
> >>  board/sunxi/board.c| 19 ++-
> >>  4 files changed, 30 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> >> index 5e03d039433a..5a74c9717d84 100644
> >> --- a/arch/arm/mach-sunxi/board.c
> >> +++ b/arch/arm/mach-sunxi/board.c
> >> @@ -69,12 +69,14 @@ struct mm_region *mem_map = sunxi_mem_map;
> >>  static int gpio_init(void)
> >>  {
> >>  #if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
> >> -#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
> >> +#if defined(CONFIG_MACH_SUN4I) || \
> >> +defined(CONFIG_MACH_SUN7I) || \
> >> +defined(CONFIG_MACH_SUN8I_R40)
> >>   /* disable GPB22,23 as uart0 tx,rx to avoid conflict */
> >>   sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUNXI_GPIO_INPUT);
> >>   sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT);
> >>  #endif
> >> -#if defined(CONFIG_MACH_SUN8I)
> >> +#if defined(CONFIG_MACH_SUN8I) && !defined(CONFIG_MACH_SUN8I_R40)
> >>   sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0);
> >>   sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
> >>  #else
> >> @@ -82,7 +84,9 @@ static int gpio_init(void)
> >>   sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0);
> >>  #endif
> >>   sunxi_gpio_set_pull(SUNXI_GPF(4), 1);
> >> -#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || 
> >> defined(CONFIG_MACH_SUN7I))
> >> +#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || \
> >> +  defined(CONFIG_MACH_SUN7I) || \
> >> +  defined(CONFIG_MACH_SUN8I_R40))
> >>   sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB_UART0);
> >>   sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB_UART0);
> >>   sunxi_gpio_set_pull(SUNXI_GPB(23), SUNXI_GPIO_PULL_UP);
> >> diff --git a/arch/arm/mach-sunxi/cpu_info.c 
> >> b/arch/arm/mach-sunxi/cpu_info.c
> >> index 85633ccec216..7851de299ab5 100644
> >> --- a/arch/arm/mach-sunxi/cpu_info.c
> >> +++ b/arch/arm/mach-sunxi/cpu_info.c
> >> @@ -87,6 +87,8 @@ int print_cpuinfo(void)
> >>   printf("CPU:   Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
> >>  #elif defined CONFIG_MACH_SUN8I_H3
> >>   printf("CPU:   Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
> >> +#elif defined CONFIG_MACH_SUN8I_R40
> >> + printf("CPU:   Allwinner R40 (SUN8I %04x)\n", sunxi_get_sram_id());
> >>  #elif defined CONFIG_MACH_SUN9I
> >>   puts("CPU:   Allwinner A80 (SUN9I)\n");
> >>  #elif defined CONFIG_MACH_SUN50I
> >> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> >> index 3e0e2624737e..8e8b9cd0d5fd 100644
> >> --- a/board/sunxi/Kconfig
> >> +++ b/board/sunxi/Kconfig
> >> @@ -132,6 +132,11 @@ config MACH_SUN8I_H3
> >>   select MACH_SUNXI_H3_H5
> >>   select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
> >>
> >> +config MACH_SUN8I_R40
> >> + bool "sun8i (Allwinner R40)"
> >> + select CPU_V7
> >> + select SUNXI_GEN_SUN6I
> >> +
> >>  config MACH_SUN9I
> >>   bool "sun9i (Allwinner A80)"
> >>   select CPU_V7
> >> @@ -157,7 +162,7 @@ endchoice
> >>  # The sun8i SoCs share a lot, this helps to avoid a lot of "if A23 || A33"
> >>  config MACH_SUN8I
> >>   bool
> >> - default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUNXI_H3_H5 || 
> >> MACH_SUN8I_A83T
> >> + default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUNXI_H3_H5 || 
> >> MACH_SUN8I_A83T || MACH_SUN8I_R40
> >
> > You should really wrap that line too (and CONFIG_VIDEO below).
> 
> Kconfig doesn't seem to like line wrapping. I can split both into
> 1 symbol per line though. Would that be taking it to far?

Something like:

default y if MACH_SUN8I_A23
default y if MACH_SUN8I_A33

?

I didn't know it was possible.. But if it works, yes, please that will
even be easier to review / extend.

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/listinfo/u-boot


Re: [U-Boot] [PATCH 10/12] sunxi: Fix CPUCFG address for R40

2017-03-01 Thread Maxime Ripard
On Wed, Mar 01, 2017 at 03:04:45PM +0800, Chen-Yu Tsai wrote:
> The R40 has the CPUCFG block at the same address as the A20.
> Fix it.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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/listinfo/u-boot


Re: [U-Boot] [PATCH 11/12] sunxi: Add PSCI support for R40

2017-03-01 Thread Maxime Ripard
On Wed, Mar 01, 2017 at 03:04:46PM +0800, Chen-Yu Tsai wrote:
> The R40's CPU controls are a combination of sun6i and sun7i.
> 
> All controls are in the CPUCFG block, and it seems the R40 does not
> have a PRCM block. The core reset, power gating and clamp controls
> are grouped like sun6i.
> 
> Last, the R40 does not have a secure SRAM block.
> 
> This patch adds a PSCI implementation for CPU bring-up and hotplug
> for the R40.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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/listinfo/u-boot


Re: [U-Boot] [PATCH 08/12] sunxi: Use H3/A64 DRAM initialization code for R40

2017-03-01 Thread Maxime Ripard
On Wed, Mar 01, 2017 at 03:04:43PM +0800, Chen-Yu Tsai wrote:
> The R40 seems to have a variant of the memory controller found in
> the H3 and A64 SoCs. Adapt the code for use on the R40. The changes
> are based on released DRAM code and comparing register dumps from
> boot0.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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/listinfo/u-boot


Re: [U-Boot] [PATCH 09/12] sunxi: Enable SPL for R40

2017-03-01 Thread Maxime Ripard
On Wed, Mar 01, 2017 at 03:04:44PM +0800, Chen-Yu Tsai wrote:
> Now that we can do DRAM initialization for the R40, we can enable
> SPL support for it.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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/listinfo/u-boot


Re: [U-Boot] [PATCH 07/12] gpio: sunxi: Add compatible string for R40 PIO

2017-03-01 Thread Maxime Ripard
On Wed, Mar 01, 2017 at 03:04:42PM +0800, Chen-Yu Tsai wrote:
> The PIO on the R40 SoC is mostly compatible with the A20.
> Only a few pin functions for mmc2 were added to the PC
> pingroup, to support 8 bit eMMCs.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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/listinfo/u-boot


Re: [U-Boot] [PATCH 06/12] sunxi: Provide defaults for R40 DRAM settings

2017-03-01 Thread Maxime Ripard
On Wed, Mar 01, 2017 at 03:04:41PM +0800, Chen-Yu Tsai wrote:
> These values were taken from the Banana Pi M2 Ultra fex file
> found in the released vendor BSP. This is the only publicly
> available R40 device at the time of this writing.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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/listinfo/u-boot


Re: [U-Boot] [PATCH 05/12] sunxi: Set PLL lock enable bits for R40

2017-03-01 Thread Maxime Ripard
On Wed, Mar 01, 2017 at 03:04:40PM +0800, Chen-Yu Tsai wrote:
> According to the BSP released by Banana Pi, the R40 (sun8iw11p1) has
> an extra "PLL lock control" register in the CCU, which controls whether
> the individual PLL lock status bits in each PLL's control register work
> or not.
> 
> This patch enables it for all the PLLs.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] lib: move hash CONFIG options to Kconfig

2017-03-01 Thread Tom Rini
On Sat, Feb 18, 2017 at 11:57:49AM +0900, Masahiro Yamada wrote:

> Commit 94e3c8c4fd7b ("crypto/fsl - Add progressive hashing support
> using hardware acceleration.") created entries for CONFIG_SHA1,
> CONFIG_SHA256, CONFIG_SHA_HW_ACCEL, and CONFIG_SHA_PROG_HW_ACCEL.
> However, no defconfig has migrated to it.  Complete the move with
> moveconfig tool.
> 
> This commit was generated as follows:
> 
> [1] tools/moveconfig.py -y SHA1 SHA256 SHA_HW_ACCEL
> [2] tools/moveconfig.py -y SHA_PROG_HW_ACCEL
> 
> Note:
> We cannot move SHA_HW_ACCEL and SHA_PROG_HW_ACCEL simultaneously
> because there is dependency between them.
> 
> Signed-off-by: Masahiro Yamada 

I'm working on a v2 of this patch.  First, we need to (and I've done)
migrate FIT_DISABLE_SHA256 (and make positive).  Second we can in a
large number of cases here know that we need these because we have
FSL_CAAM, which also needs to be migrated.  Thanks for the poke! :)

-- 
Tom


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


Re: [U-Boot] i.MX6QP sd boot issue

2017-03-01 Thread Fabio Estevam
Hi Jagan,

On Wed, Mar 1, 2017 at 9:55 AM, Jagan Teki  wrote:
> + ML
>
> On Wed, Mar 1, 2017 at 6:23 PM, Jagan Teki  wrote:
>> Hi Peng and All,
>>
>> I'm trying to boot from SD, on imx6qplus sabre board.
>>
>> - SW6: D1-D8 => 0100 0010
>> - SD card on SD3
>> - D12 with USB-to-Serial 115200 8N1
>> - Power supply Output 5V
>>
>> Build:
>> $  make mx6qpsabreauto_defconfig; make
>> $ dd if=u-boot.imx of=/dev/sda bs=512 seek=2

I don't have a imx6qp sabresd board handy, but can you try the SPL
config instead?

make mx6sabresd_spl_defconfig
dd if=SPL of=/dev/mmcblk0 bs=1k seek=1; sync
dd if=u-boot.img of=/dev/mmcblk0 bs=1k seek=69; sync

It worked for me the last time I tried it with mainline U-Boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] i.MX6QP sd boot issue

2017-03-01 Thread Jagan Teki
On Wed, Mar 1, 2017 at 6:28 PM, Peng Fan  wrote:
> Hi Jagan,
>
> Did you put J3 to connect 1-2?

What is J3, I couldn't find it. I saw J1 PCIe connector and J2
Headphone Jack. Can you point me J3.

>
> Jumper Boot Selection
> 1 - 2 Do not boot from SPI NOR (default)
> 2 - 3 Boot from SPI NOR
>
>
>> -Original Message-
>> From: Jagan Teki [mailto:ja...@openedev.com]
>> Sent: Wednesday, March 01, 2017 8:56 PM
>> To: u-boot@lists.denx.de
>> Cc: Peng Fan ; Stefano Babic 
>> Subject: Re: [U-Boot] i.MX6QP sd boot issue
>>
>> + ML
>>
>> On Wed, Mar 1, 2017 at 6:23 PM, Jagan Teki  wrote:
>> > Hi Peng and All,
>> >
>> > I'm trying to boot from SD, on imx6qplus sabre board.
>> >
>> > - SW6: D1-D8 => 0100 0010
>> > - SD card on SD3
>> > - D12 with USB-to-Serial 115200 8N1
>> > - Power supply Output 5V
>> >
>> > Build:
>> > $  make mx6qpsabreauto_defconfig; make $ dd if=u-boot.imx of=/dev/sda
>> > bs=512 seek=2
>> >
>> > When I plug-in power, power supply slot D1, D2 are green and D3 glow
>> > red not able to get the log on uart.
>> >
>> > Any help?
>>
>> thanks!
>> --
>> Jagan Teki
>> Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream
>> Maintainer Hyderabad, India.
>
> Regards,
> Peng.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/listinfo/u-boot



-- 
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/listinfo/u-boot


Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/8] Stop AXP from crashing when enabeling LDO3

2017-03-01 Thread Icenowy Zheng


01.03.2017, 21:45, "Olliver Schinagl" :
> Hey Maxime,
>
> On 01-03-17 14:00, Maxime Ripard wrote:
>>  Hi Oliver,
>>
>>  On Wed, Mar 01, 2017 at 01:52:16PM +0100, Olliver Schinagl wrote:
>>>  Hi list,
>>>
>>>  When powering up an AXP209, the default value for LDO3 output is enabled. 
>>> This
>>>  works fine. However if for whatever reason, LDO3 is disabled, for example 
>>> by OS
>>>  during reboot and u-boot enables LDO3 again, the PMIC shutsdown (without
>>>  setting an interrupt) causing the board to hang. This behavior has been 
>>> seen
>>>  from Linux as well, u-boot disables LDO3 as a default value, the kernel 
>>> enables
>>>  it per its DTS, the kernel hangs as the PMIC gets shut down.
>>>
>>>  The root cause is that some boards have to high capacitance on the LDO3 
>>> output
>>>  port causing inrush currents exceeding the maximum of the AXP209.
>>>
>>>  The fix is to turn on the LDO3 at the lowest possible voltage and then set 
>>> the
>>>  final voltage.
>>>
>>>  If the capacitance is really big (due to a connected device for example) 
>>> the
>>>  AXP209 also features VRC, or Voltage Rate Control, which allows the voltage
>>>  ramp up to be even slower.
>>>
>>>  This patch series implements the above with a few tiny, cleanups I ran into
>>>  underway.
>>>
>>>  The initial discussion with some scope screenshots can be found in the
>>>  linux-sunxi mailing list [0].
>>
>>  If you don't CC the proper maintainers, no one is going to pick the patches.
>
> who did I miss? I did use the get_maintainers script, and added you
> explicitly.
>
> There is no sunxi custodian anymore, it is orphaned.

Currently maintainers are Maxime Ripard and Jegan Teki.

>
>>  Maxime
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [linux-sunxi] [PATCH 1/8] sunxi: board: Print error after power initialization fails

2017-03-01 Thread Icenowy Zheng


01.03.2017, 20:52, "Olliver Schinagl" :
> Currently during init, we enable all power, then enable the dram and
> after that check if there was an error during power-up.
>
> This makes little sense, we should enable power and then check if power
> was brought up properly initializing other things.
>
> This patch moves the DRAM init after the power failure check.

Seems meaningful... at least some Pine64 wrongly set its DRAM voltage
when booting.

>
> Signed-off-by: Olliver Schinagl 
> ---
>  board/sunxi/board.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 53656383d5..5467015860 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -540,11 +540,6 @@ void sunxi_board_init(void)
>  power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
>  #endif
>  #endif
> - printf("DRAM:");
> - ramsize = sunxi_dram_init();
> - printf(" %d MiB\n", (int)(ramsize >> 20));
> - if (!ramsize)
> - hang();
>
>  /*
>   * Only clock up the CPU to full speed if we are reasonably
> @@ -553,7 +548,14 @@ void sunxi_board_init(void)
>  if (!power_failed)
>  clock_set_pll1(CONFIG_SYS_CLK_FREQ);
>  else
> - printf("Failed to set core voltage! Can't set CPU frequency\n");
> + printf("Error setting up the power controller.\n \
> + CPU frequency not set.\n");
> +
> + printf("DRAM:");
> + ramsize = sunxi_dram_init();
> + printf(" %d MiB\n", (int)(ramsize >> 20));
> + if (!ramsize)
> + hang();
>  }
>  #endif
>
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 0/8] Stop AXP from crashing when enabeling LDO3

2017-03-01 Thread Maxime Ripard
Hi Oliver,

On Wed, Mar 01, 2017 at 01:52:16PM +0100, Olliver Schinagl wrote:
> Hi list,
> 
> When powering up an AXP209, the default value for LDO3 output is enabled. This
> works fine. However if for whatever reason, LDO3 is disabled, for example by 
> OS
> during reboot and u-boot enables LDO3 again, the PMIC shutsdown (without
> setting an interrupt) causing the board to hang. This behavior has been seen
> from Linux as well, u-boot disables LDO3 as a default value, the kernel 
> enables
> it per its DTS, the kernel hangs as the PMIC gets shut down.
> 
> The root cause is that some boards have to high capacitance on the LDO3 output
> port causing inrush currents exceeding the maximum of the AXP209.
> 
> The fix is to turn on the LDO3 at the lowest possible voltage and then set the
> final voltage.
> 
> If the capacitance is really big (due to a connected device for example) the
> AXP209 also features VRC, or Voltage Rate Control, which allows the voltage
> ramp up to be even slower.
> 
> This patch series implements the above with a few tiny, cleanups I ran into
> underway.
> 
> The initial discussion with some scope screenshots can be found in the
> linux-sunxi mailing list [0].

If you don't CC the proper maintainers, no one is going to pick the patches.

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/listinfo/u-boot


Re: [U-Boot] i.MX6QP sd boot issue

2017-03-01 Thread Peng Fan
Hi Jagan,

Did you put J3 to connect 1-2?

Jumper Boot Selection
1 - 2 Do not boot from SPI NOR (default)
2 - 3 Boot from SPI NOR


> -Original Message-
> From: Jagan Teki [mailto:ja...@openedev.com]
> Sent: Wednesday, March 01, 2017 8:56 PM
> To: u-boot@lists.denx.de
> Cc: Peng Fan ; Stefano Babic 
> Subject: Re: [U-Boot] i.MX6QP sd boot issue
> 
> + ML
> 
> On Wed, Mar 1, 2017 at 6:23 PM, Jagan Teki  wrote:
> > Hi Peng and All,
> >
> > I'm trying to boot from SD, on imx6qplus sabre board.
> >
> > - SW6: D1-D8 => 0100 0010
> > - SD card on SD3
> > - D12 with USB-to-Serial 115200 8N1
> > - Power supply Output 5V
> >
> > Build:
> > $  make mx6qpsabreauto_defconfig; make $ dd if=u-boot.imx of=/dev/sda
> > bs=512 seek=2
> >
> > When I plug-in power, power supply slot D1, D2 are green and D3 glow
> > red not able to get the log on uart.
> >
> > Any help?
> 
> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream
> Maintainer Hyderabad, India.

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


Re: [U-Boot] i.MX6QP sd boot issue

2017-03-01 Thread Jagan Teki
+ ML

On Wed, Mar 1, 2017 at 6:23 PM, Jagan Teki  wrote:
> Hi Peng and All,
>
> I'm trying to boot from SD, on imx6qplus sabre board.
>
> - SW6: D1-D8 => 0100 0010
> - SD card on SD3
> - D12 with USB-to-Serial 115200 8N1
> - Power supply Output 5V
>
> Build:
> $  make mx6qpsabreauto_defconfig; make
> $ dd if=u-boot.imx of=/dev/sda bs=512 seek=2
>
> When I plug-in power, power supply slot D1, D2 are green and D3 glow
> red not able to get the log on uart.
>
> Any help?

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/listinfo/u-boot


[U-Boot] [PATCH 5/8] power: axp209: Reduce magic values by adding defines for LDO[234]

2017-03-01 Thread Olliver Schinagl
The AXP209 has a few 'magisc-ish' values that are better served with
clear defines.

Signed-off-by: Olliver Schinagl 
---
 drivers/power/axp209.c | 10 --
 include/axp209.h   | 14 ++
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index d496f675a1..a5d38cdf76 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -82,8 +82,7 @@ int axp_set_aldo2(unsigned int mvolt)
if (rc)
return rc;
 
-   /* LDO2 configuration is in upper 4 bits */
-   reg = (reg & 0x0f) | (cfg << 4);
+   reg |= AXP209_LDO24_LDO2_SET(reg, cfg);
rc = pmic_bus_write(AXP209_LDO24_VOLTAGE, reg);
if (rc)
return rc;
@@ -101,9 +100,9 @@ int axp_set_aldo3(unsigned int mvolt)
AXP209_OUTPUT_CTRL_LDO3);
 
if (mvolt == -1)
-   cfg = 0x80; /* determined by LDO3IN pin */
+   cfg = AXP209_LDO3_VOLTAGE_FROM_LDO3IN;
else
-   cfg = axp209_mvolt_to_cfg(mvolt, 700, 3500, 25);
+   cfg = AXP209_LDO3_VOLTAGE_SET(axp209_mvolt_to_cfg(mvolt, 700, 
3500, 25));
 
rc = pmic_bus_write(AXP209_LDO3_VOLTAGE, cfg);
if (rc)
@@ -132,8 +131,7 @@ int axp_set_aldo4(unsigned int mvolt)
if (rc)
return rc;
 
-   /* LDO4 configuration is in lower 4 bits */
-   reg = (reg & 0xf0) | (cfg << 0);
+   reg |= AXP209_LDO24_LDO4_SET(reg, cfg);
rc = pmic_bus_write(AXP209_LDO24_VOLTAGE, reg);
if (rc)
return rc;
diff --git a/include/axp209.h b/include/axp209.h
index 51d2e88dd2..e4210eca00 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -35,6 +35,20 @@ enum axp209_reg {
 #define AXP209_OUTPUT_CTRL_DCDC2   BIT(4)
 #define AXP209_OUTPUT_CTRL_LDO3BIT(6)
 
+#define AXP209_LDO24_LDO2_MASK 0xf0
+#define AXP209_LDO24_LDO4_MASK 0x0f
+#define AXP209_LDO24_LDO2_SET(reg, cfg)\
+   (((reg) & ~AXP209_LDO24_LDO2_MASK) | \
+   (((cfg) << 4) & AXP209_LDO24_LDO2_MASK))
+#define AXP209_LDO24_LDO4_SET(reg, cfg)\
+   (((reg) & ~AXP209_LDO24_LDO4_MASK) | \
+   (((cfg) << 0) & AXP209_LDO24_LDO4_MASK))
+
+
+#define AXP209_LDO3_VOLTAGE_FROM_LDO3INBIT(7)
+#define AXP209_LDO3_VOLTAGE_MASK   0x7f
+#define AXP209_LDO3_VOLTAGE_SET(x) ((x) & AXP209_LDO3_VOLTAGE_MASK)
+
 #define AXP209_IRQ5_PEK_UP BIT(6)
 #define AXP209_IRQ5_PEK_DOWN   BIT(5)
 
-- 
2.11.0

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


[U-Boot] [PATCH 6/8] power: axp209: Add support for voltage rate control on LDO3

2017-03-01 Thread Olliver Schinagl
The AXP209 has voltage rate control, or can set a slew rate, for LDO3.
This allows for the power to gradually rise to the desired voltage,
instead of spiking up quickly. Reason to have this can be to reduce the
inrush currents for example.

There are 3 slopes to choose from, the default, 'none' is a voltage rise
of 0.0167 V/uS, a 1.6 mV/uS and a 0.8 mV/uS voltage rise.

Signed-off-by: Olliver Schinagl 
---
 drivers/power/Kconfig  | 33 +
 drivers/power/axp209.c | 24 
 include/axp209.h   | 16 
 3 files changed, 73 insertions(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index f2c5629be2..3f10f84a89 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -188,6 +188,39 @@ config AXP_ALDO3_VOLT
On A83T / H8 boards aldo3 is AVCC, VCC-PL, and VCC-LED, and should be
3.0V.
 
+choice
+   prompt "axp pmic (a)ldo3 voltage rate control"
+   depends on AXP209_POWER && (AXP_ALDO3_VOLT != 0)
+   default AXP_ALDO3_VOLT_SLOPE_NONE
+   ---help---
+   The AXP can slowly ramp up voltage to reduce the inrush current when
+   changing voltages.
+   Note, this does not apply when enabeling/disableing LDO3. See
+   "axp pmic (a)ldo3 inrush quirk" below to enable a slew rate to limit
+   inrush current on broken board designs.
+
+config AXP_ALDO3_VOLT_SLOPE_NONE
+   bool "No voltage slope"
+   ---help---
+   Tries to reach the next voltage setting near instantaneous. Measurements
+   indicate that this is about 0.0167 V/uS.
+
+config AXP_ALDO3_VOLT_SLOPE_16
+   bool "1.6 mV per uS"
+   ---help---
+   Increases the voltage by 1.6 mV per uS until the final voltage has
+   been reached. Note that the scaling is in 25 mV steps however and thus
+   the slew rate is 25 mV/31.250 uS in reality.
+
+config AXP_ALDO3_VOLT_SLOPE_08
+   bool "0.8 mV per uS"
+   ---help---
+   Increases the voltage by 0.8 mV per uS until the final voltage has
+   been reached. Note that the scaling is in 25 mV steps however and thus
+   the slew rate is 25 mV/15.625 uS in reality. This is the slowest rate.
+
+endchoice
+
 config AXP_ALDO4_VOLT
int "axp pmic (a)ldo4 voltage"
depends on AXP209_POWER
diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index a5d38cdf76..8f9269cb40 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -10,6 +10,16 @@
 #include 
 #include 
 
+#ifdef CONFIG_AXP_ALDO3_VOLT_SLOPE_08
+#  define AXP209_VRC_SLOPE AXP209_VRC_LDO3_800uV_uS
+#endif
+#ifdef CONFIG_AXP_ALDO3_VOLT_SLOPE_16
+#  define AXP209_VRC_SLOPE AXP209_VRC_LDO3_1600uV_uS
+#endif
+#if defined CONFIG_AXP_ALDO3_VOLT_SLOPE_NONE || !defined AXP209_VRC_SLOPE
+#  define AXP209_VRC_SLOPE 0x00
+#endif
+
 static u8 axp209_mvolt_to_cfg(int mvolt, int min, int max, int div)
 {
if (mvolt < min)
@@ -99,6 +109,20 @@ int axp_set_aldo3(unsigned int mvolt)
return pmic_bus_clrbits(AXP209_OUTPUT_CTRL,
AXP209_OUTPUT_CTRL_LDO3);
 
+   /*
+* Some boards have trouble reaching the target voltage without causing
+* great inrush currents. To prevent this, boards can enable a certain
+* slope to ramp up voltage. Note, this only works when changing an
+* already active power rail. When toggling power on, the AXP ramps up
+* steeply at 0.0167 V/uS.
+*/
+   rc = pmic_bus_read(AXP209_VRC_DCDC2_LDO3, &cfg);
+   cfg = AXP209_VRC_LDO3_SLOPE_SET(cfg, AXP209_VRC_SLOPE);
+   rc |= pmic_bus_write(AXP209_VRC_DCDC2_LDO3, cfg);
+
+   if (rc)
+   return rc;
+
if (mvolt == -1)
cfg = AXP209_LDO3_VOLTAGE_FROM_LDO3IN;
else
diff --git a/include/axp209.h b/include/axp209.h
index e4210eca00..62be93b806 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -11,6 +11,7 @@ enum axp209_reg {
AXP209_CHIP_VERSION = 0x03,
AXP209_OUTPUT_CTRL = 0x12,
AXP209_DCDC2_VOLTAGE = 0x23,
+   AXP209_VRC_DCDC2_LDO3 = 0x25,
AXP209_DCDC3_VOLTAGE = 0x27,
AXP209_LDO24_VOLTAGE = 0x28,
AXP209_LDO3_VOLTAGE = 0x29,
@@ -35,6 +36,21 @@ enum axp209_reg {
 #define AXP209_OUTPUT_CTRL_DCDC2   BIT(4)
 #define AXP209_OUTPUT_CTRL_LDO3BIT(6)
 
+#define AXP209_VRC_LDO3_EN BIT(3)
+#define AXP209_VRC_DCDC2_ENBIT(2)
+#define AXP209_VRC_LDO3_800uV_uS   (BIT(1) | AXP209_VRC_LDO3_EN)
+#define AXP209_VRC_LDO3_1600uV_uS  AXP209_VRC_LDO3_EN
+#define AXP209_VRC_DCDC2_800uV_uS  (BIT(0) | AXP209_VRC_DCDC2_EN)
+#define AXP209_VRC_DCDC2_1600uV_uS AXP209_VRC_DCDC2_EN
+#define AXP209_VRC_LDO3_MASK   0xa
+#define AXP209_VRC_DCDC2_MASK  0x5
+#define AXP209_VRC_DCDC2_SLOPE_SET(reg, cfg) \
+   (((reg) & ~AXP209_VRC_DCDC2_MASK) | \
+   ((cfg) & AXP209_VRC_DCDC2_MASK))
+#define AXP209_VRC_LDO3_SLOPE_SET(reg, cfg) \
+   (((re

[U-Boot] [PATCH 4/8] power: axp209: Define the chip version mask

2017-03-01 Thread Olliver Schinagl
Use a define for the chip version mask on the axp209.

Signed-off-by: Olliver Schinagl 
---
 drivers/power/axp209.c | 5 +
 include/axp209.h   | 2 ++
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index 731b75e50a..d496f675a1 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -154,10 +154,7 @@ int axp_init(void)
if (rc)
return rc;
 
-   /* Low 4 bits is chip version */
-   ver &= 0x0f;
-
-   if (ver != 0x1)
+   if ((ver & AXP209_CHIP_VERSION_MASK) != 0x1)
return -1;
 
/* Mask all interrupts */
diff --git a/include/axp209.h b/include/axp209.h
index 7803300328..51d2e88dd2 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -26,6 +26,8 @@ enum axp209_reg {
 #define AXP209_POWER_STATUS_ON_BY_DC   BIT(0)
 #define AXP209_POWER_STATUS_VBUS_USABLEBIT(4)
 
+#define AXP209_CHIP_VERSION_MASK   0x0f
+
 #define AXP209_OUTPUT_CTRL_EXTEN   BIT(0)
 #define AXP209_OUTPUT_CTRL_DCDC3   BIT(1)
 #define AXP209_OUTPUT_CTRL_LDO2BIT(2)
-- 
2.11.0

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


[U-Boot] [PATCH 7/8] power: axp209: Limit inrush current for broken boards

2017-03-01 Thread Olliver Schinagl
Some boards feature a capacitance on LDO3's output that is to large,
causing inrush currents which as a result, shut down the AXP209. This
has been reported before, without knowing the actual cause.

A fix appeared to be done with commit 0e6e34ac8db ("sunxi: Olimex A20
boards: Enable LDO3 and LDO4 regulators").

The description there is a bit misleading, the kernel does not hang
during AXP209 initialization, the PMIC shuts down, causing voltages to
drop and thus the whole system to freeze.

While the AXP209 does have the ability to ramp up the voltage slowly, to
reduce these inrush currents, the voltage rate control (VRC) however is
not applicable when switching on the LDO3 output. Only when going from
an enabled lower voltage setting, to a higher voltage setting is the VRC
in effect.

To work around this problem, we set LDO3 to the lowest possible setting
of 0.7 V if it was not yet enabled, and then let the VRC (if enabled) do
its thing. It should be noted, that for some undocumented reason, there
is a short delay needed between setting the LDO3 voltage register and
enabling the power. One would expect that this delay ought to be just
after enabling the output power at 0.7 V, but this did not work.

Signed-off-by: Olliver Schinagl 
---
 drivers/power/Kconfig  |  9 +
 drivers/power/axp209.c | 22 ++
 2 files changed, 31 insertions(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 3f10f84a89..644f206b4d 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -221,6 +221,15 @@ config AXP_ALDO3_VOLT_SLOPE_08
 
 endchoice
 
+config AXP_ALDO3_INRUSH_QUIRK
+   bool "axp pmic (a)ldo3 inrush quirk"
+   depends on AXP209_POWER
+   default n
+   ---help---
+   The reference design denotes a value of 4.7 uF for the output capacitor
+   of LDO3. Some boards have to higher capacitance than that which causes
+   an inrush current and causes an AXP209 shutdown.
+
 config AXP_ALDO4_VOLT
int "axp pmic (a)ldo4 voltage"
depends on AXP209_POWER
diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index 8f9269cb40..2121b88e0c 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -123,6 +123,28 @@ int axp_set_aldo3(unsigned int mvolt)
if (rc)
return rc;
 
+   /*
+* On some boards, LDO3 has a to big capacitor installed. When
+* turning on LDO3, this causes the AXP209 to shutdown on
+* voltages over 1.9 volt. As a work around, we enable LDO3
+* first with the lowest possible voltage. If this still causes
+* high inrush currents, the voltage slope should be increased.
+*/
+#ifdef CONFIG_AXP_ALDO3_INRUSH_QUIRK
+   rc = pmic_bus_read(AXP209_OUTPUT_CTRL, &cfg);
+   if (rc)
+   return rc;
+
+   if (!(cfg & AXP209_OUTPUT_CTRL_LDO3)) {
+   rc = pmic_bus_write(AXP209_LDO3_VOLTAGE, 0x0); /* 0.7 Volt */
+   mdelay(1);
+   rc |= pmic_bus_setbits(AXP209_OUTPUT_CTRL, 
AXP209_OUTPUT_CTRL_LDO3);
+
+   if (rc)
+   return rc;
+   }
+#endif
+
if (mvolt == -1)
cfg = AXP209_LDO3_VOLTAGE_FROM_LDO3IN;
else
-- 
2.11.0

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


[U-Boot] [PATCH 8/8] arm: sunxi: Enable inrush quirk on Olimex OLinuXino-A20-Lime2

2017-03-01 Thread Olliver Schinagl
The lime2 features a too large capacitor on the LDO3 output, which
causes the PMIC to shutdown when enabling power. To be able to still
boot up however, we must gradually enable power on LDO3 for this board.

Signed-off-by: Olliver Schinagl 
---
 configs/A20-OLinuXino-Lime2_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index 8fd7c64e77..72bb8beb2e 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -19,6 +19,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_DFU_RAM=y
 CONFIG_RTL8211X_PHY_FORCE_MASTER=y
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_AXP_ALDO3_INRUSH_QUIRK=y
 CONFIG_AXP_ALDO3_VOLT=2800
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_USB_EHCI_HCD=y
-- 
2.11.0

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


Re: [U-Boot] [PATCH] drivers/usb/ehci: Use platform-specific accessors

2017-03-01 Thread Alexey Brodkin
Hi Marek,

On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote:
> On 02/10/2017 09:23 PM, Alexey Brodkin wrote:
> > 
> > Current implementation doesn't allow utilization of platform-specific
> > reads and writes.
> > 
> > But some arches or platforms may want to use their accessors that do
> > some extra work like adding barriers for data serialization etc.
> > 
> > Interesting enough OHCI accessors already do that so just aligning
> > EHCI to it now.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Marek Vasut 
> > Cc: Simon Glass 
> > Cc: Mateusz Kulikowski 
> 
> IMO looks OK,
> 
> Acked-by: Marek Vasut 
> 
> I'd like to have a few more reviews of this before applying it for
> 2017.05 . Also CCing Wills, it'd be great to get a test on atheros
> MIPS .

It's been quite some time since your request to try the patch
on other systems and so far nobody answered. May we consider that
one for application then?

Essentially I'm not talking about current Tom's master branch
but would be good if the patch lands somewhere and once 2017.03
gets cut is merged in the main branch?

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


[U-Boot] [PATCH 3/8] power: axp209: Use BIT() macro

2017-03-01 Thread Olliver Schinagl
Use the standard BIT() macro to define BITS.

Signed-off-by: Olliver Schinagl 
---
 include/axp209.h | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/include/axp209.h b/include/axp209.h
index e1b22e3442..7803300328 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -4,6 +4,8 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include 
+
 enum axp209_reg {
AXP209_POWER_STATUS = 0x00,
AXP209_CHIP_VERSION = 0x03,
@@ -21,29 +23,29 @@ enum axp209_reg {
AXP209_SHUTDOWN = 0x32,
 };
 
-#define AXP209_POWER_STATUS_ON_BY_DC   (1 << 0)
-#define AXP209_POWER_STATUS_VBUS_USABLE(1 << 4)
+#define AXP209_POWER_STATUS_ON_BY_DC   BIT(0)
+#define AXP209_POWER_STATUS_VBUS_USABLEBIT(4)
 
-#define AXP209_OUTPUT_CTRL_EXTEN   (1 << 0)
-#define AXP209_OUTPUT_CTRL_DCDC3   (1 << 1)
-#define AXP209_OUTPUT_CTRL_LDO2(1 << 2)
-#define AXP209_OUTPUT_CTRL_LDO4(1 << 3)
-#define AXP209_OUTPUT_CTRL_DCDC2   (1 << 4)
-#define AXP209_OUTPUT_CTRL_LDO3(1 << 6)
+#define AXP209_OUTPUT_CTRL_EXTEN   BIT(0)
+#define AXP209_OUTPUT_CTRL_DCDC3   BIT(1)
+#define AXP209_OUTPUT_CTRL_LDO2BIT(2)
+#define AXP209_OUTPUT_CTRL_LDO4BIT(3)
+#define AXP209_OUTPUT_CTRL_DCDC2   BIT(4)
+#define AXP209_OUTPUT_CTRL_LDO3BIT(6)
 
-#define AXP209_IRQ5_PEK_UP (1 << 6)
-#define AXP209_IRQ5_PEK_DOWN   (1 << 5)
+#define AXP209_IRQ5_PEK_UP BIT(6)
+#define AXP209_IRQ5_PEK_DOWN   BIT(5)
 
-#define AXP209_POWEROFF(1 << 7)
+#define AXP209_POWEROFFBIT(7)
 
 /* For axp_gpio.c */
 #define AXP_POWER_STATUS   0x00
-#define AXP_POWER_STATUS_VBUS_PRESENT  (1 << 5)
+#define AXP_POWER_STATUS_VBUS_PRESENT  BIT(5)
 #define AXP_GPIO0_CTRL 0x90
 #define AXP_GPIO1_CTRL 0x92
 #define AXP_GPIO2_CTRL 0x93
-#define AXP_GPIO_CTRL_OUTPUT_LOW   0x00 /* Drive pin low */
-#define AXP_GPIO_CTRL_OUTPUT_HIGH  0x01 /* Drive pin high */
-#define AXP_GPIO_CTRL_INPUT0x02 /* Input */
+#define AXP_GPIO_CTRL_OUTPUT_LOW   0x00 /* Drive pin low */
+#define AXP_GPIO_CTRL_OUTPUT_HIGH  0x01 /* Drive pin high */
+#define AXP_GPIO_CTRL_INPUT0x02 /* Input */
 #define AXP_GPIO_STATE 0x94
-#define AXP_GPIO_STATE_OFFSET  4
+#define AXP_GPIO_STATE_OFFSET  4
-- 
2.11.0

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


[U-Boot] [PATCH 2/8] sunxi: pmic_bus: Decrease boot time by not writing duplicate data

2017-03-01 Thread Olliver Schinagl
When we set or clear a pmic_bus bit, we do a read-modify-write
operation. We waste some time however, by writing back the exact same
value that was already set in the chip. Let us thus only configure the
chip if the data is different.

Signed-off-by: Olliver Schinagl 
---
 arch/arm/mach-sunxi/pmic_bus.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
index 7c57f02792..dc3d328c1b 100644
--- a/arch/arm/mach-sunxi/pmic_bus.c
+++ b/arch/arm/mach-sunxi/pmic_bus.c
@@ -95,6 +95,9 @@ int pmic_bus_setbits(u8 reg, u8 bits)
if (ret)
return ret;
 
+   if (val & bits)
+   return 0;
+
val |= bits;
return pmic_bus_write(reg, val);
 }
@@ -108,6 +111,9 @@ int pmic_bus_clrbits(u8 reg, u8 bits)
if (ret)
return ret;
 
+   if (!(val & bits))
+   return 0;
+
val &= ~bits;
return pmic_bus_write(reg, val);
 }
-- 
2.11.0

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


[U-Boot] [PATCH 1/8] sunxi: board: Print error after power initialization fails

2017-03-01 Thread Olliver Schinagl
Currently during init, we enable all power, then enable the dram and
after that check if there was an error during power-up.

This makes little sense, we should enable power and then check if power
was brought up properly initializing other things.

This patch moves the DRAM init after the power failure check.

Signed-off-by: Olliver Schinagl 
---
 board/sunxi/board.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 53656383d5..5467015860 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -540,11 +540,6 @@ void sunxi_board_init(void)
power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
 #endif
 #endif
-   printf("DRAM:");
-   ramsize = sunxi_dram_init();
-   printf(" %d MiB\n", (int)(ramsize >> 20));
-   if (!ramsize)
-   hang();
 
/*
 * Only clock up the CPU to full speed if we are reasonably
@@ -553,7 +548,14 @@ void sunxi_board_init(void)
if (!power_failed)
clock_set_pll1(CONFIG_SYS_CLK_FREQ);
else
-   printf("Failed to set core voltage! Can't set CPU frequency\n");
+   printf("Error setting up the power controller.\n \
+   CPU frequency not set.\n");
+
+   printf("DRAM:");
+   ramsize = sunxi_dram_init();
+   printf(" %d MiB\n", (int)(ramsize >> 20));
+   if (!ramsize)
+   hang();
 }
 #endif
 
-- 
2.11.0

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


[U-Boot] [PATCH 0/8] Stop AXP from crashing when enabeling LDO3

2017-03-01 Thread Olliver Schinagl
Hi list,

When powering up an AXP209, the default value for LDO3 output is enabled. This
works fine. However if for whatever reason, LDO3 is disabled, for example by OS
during reboot and u-boot enables LDO3 again, the PMIC shutsdown (without
setting an interrupt) causing the board to hang. This behavior has been seen
from Linux as well, u-boot disables LDO3 as a default value, the kernel enables
it per its DTS, the kernel hangs as the PMIC gets shut down.

The root cause is that some boards have to high capacitance on the LDO3 output
port causing inrush currents exceeding the maximum of the AXP209.

The fix is to turn on the LDO3 at the lowest possible voltage and then set the
final voltage.

If the capacitance is really big (due to a connected device for example) the
AXP209 also features VRC, or Voltage Rate Control, which allows the voltage
ramp up to be even slower.

This patch series implements the above with a few tiny, cleanups I ran into
underway.

The initial discussion with some scope screenshots can be found in the
linux-sunxi mailing list [0].

Signed-off-by: Olliver Schinagl 

[0] https://groups.google.com/forum/m/#!topic/linux-sunxi/EDvEsbHHqQI

Olliver Schinagl (8):
  sunxi: board: Print error after power initialization fails
  sunxi: pmic_bus: Decrease boot time by not writing duplicate data
  power: axp209: Use BIT() macro
  power: axp209: Define the chip version mask
  power: axp209: Reduce magic values by adding defines for LDO[234]
  power: axp209: Add support for voltage rate control on LDO3
  power: axp209: Limit inrush current for broken boards
  arm: sunxi: Enable inrush quirk on Olimex OLinuXino-A20-Lime2

 arch/arm/mach-sunxi/pmic_bus.c|  6 
 board/sunxi/board.c   | 14 
 configs/A20-OLinuXino-Lime2_defconfig |  1 +
 drivers/power/Kconfig | 42 ++
 drivers/power/axp209.c| 61 ++--
 include/axp209.h  | 66 ++-
 6 files changed, 158 insertions(+), 32 deletions(-)

-- 
2.11.0

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


Re: [U-Boot] [PATCH] spi: cadence_qspi_apb: Add trigger-base DT bindings from Linux

2017-03-01 Thread Vignesh R


On Tuesday 28 February 2017 10:36 PM, Rush, Jason A. wrote:
> R, Vignesh wrote:
>> On 2/28/2017 8:38 PM, Rush, Jason A. wrote:
>> [...]
>>>
>>> This also works.
>>>
>>> Marek - how do you feel about a patch series with the following:
>>>
>>> 1. revert commit 57897c13de03ac0136d64641a3eab526c6810387
>>>  spi: cadence_qspi_apb: Use 32 bit indirect write transaction when 
>>> possible
>>> 2. revert commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f
>>>  spi: cadence_qspi_apb: Use 32 bit indirect read transaction when 
>>> possible
>>> 3. Apply my slightly modified version of 
>>> https://patchwork.ozlabs.org/patch/693069/
>>>  (should I keep Vignesh as the signed-off?)
>>
>> Depends on how much you have changed the code. If the change is
>> significant then change the authorship to you and drop my signed-off.
>> Else, keep the authorship and signed-off.
>> If you are adding something new to the patch like adding code to make
>> sure that only 32bit data reads are issued, then I suggest you to submit
>> that change as separate patch.
> 
> Very minimal.  Another commit changed a #define from
> CQSPI_REG_INDIRECTWR_START_MASK to CQSPI_REG_INDIRECTWR_START,
> so I had to modify the patch to drop the _MASK so it would apply.  Other
> than that, it's identical in content.
> 

In that case you will have to retain my authorship and signed-off by and
add your signed-off by below that. Thanks!


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


  1   2   >