[U-Boot] [PATCH] ARM: UniPhier: adjust device trees for business transfer

[Masahiro Yamada]

Panasonic's System LSI products, UniPhier SoC family, have been
transferred to Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-ph1-ld4-ref.dts   |  7 ---
 arch/arm/dts/uniphier-ph1-ld4.dtsi  | 27 ++-
 arch/arm/dts/uniphier-ph1-pro4-ref.dts  |  7 ---
 arch/arm/dts/uniphier-ph1-pro4.dtsi | 33 +
 arch/arm/dts/uniphier-ph1-sld3-ref.dts  |  7 ---
 arch/arm/dts/uniphier-ph1-sld3.dtsi | 27 ++-
 arch/arm/dts/uniphier-ph1-sld8-ref.dts  |  7 ---
 arch/arm/dts/uniphier-ph1-sld8.dtsi | 27 ++-
 arch/arm/dts/uniphier-ref-daughter.dtsi |  3 ++-
 drivers/i2c/i2c-uniphier-f.c|  7 ---
 drivers/i2c/i2c-uniphier.c  |  7 ---
 drivers/serial/serial_uniphier.c|  7 ---
 drivers/usb/host/ehci-uniphier.c|  5 +++--
 lib/fdtdec.c|  2 +-
 14 files changed, 93 insertions(+), 80 deletions(-)

diff --git a/arch/arm/dts/uniphier-ph1-ld4-ref.dts 
b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
index d479be1..d972c02 100644
--- a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
@@ -2,7 +2,8 @@
  * Device Tree Source for UniPhier PH1-LD4 Reference Board
  *
  * Copyright (C) 2014-2015 Panasonic Corporation
- *   Author: Masahiro Yamada 
+ * Copyright (C) 2015  Socionext Inc.
+ *   Author: Masahiro Yamada 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -12,8 +13,8 @@
 /include/ "uniphier-ref-daughter.dtsi"
 
 / {
-   model = "Panasonic UniPhier PH1-LD4 Reference Board";
-   compatible = "panasonic,ph1-ld4-ref", "panasonic,ph1-ld4";
+   model = "UniPhier PH1-LD4 Reference Board";
+   compatible = "socionext,ph1-ld4-ref", "socionext,ph1-ld4";
 
memory {
device_type = "memory";
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index 8ed7bbf..c200838 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -2,7 +2,8 @@
  * Device Tree Source for UniPhier PH1-LD4 SoC
  *
  * Copyright (C) 2014-2015 Panasonic Corporation
- *   Author: Masahiro Yamada 
+ * Copyright (C) 2015  Socionext Inc.
+ *   Author: Masahiro Yamada 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -10,7 +11,7 @@
 /include/ "skeleton.dtsi"
 
 / {
-   compatible = "panasonic,ph1-ld4";
+   compatible = "socionext,ph1-ld4";
 
cpus {
#address-cells = <1>;
@@ -30,35 +31,35 @@
ranges;
 
uart0: serial@54006800 {
-   compatible = "panasonic,uniphier-uart";
+   compatible = "socionext,uniphier-uart";
status = "disabled";
reg = <0x54006800 0x20>;
clock-frequency = <36864000>;
};
 
uart1: serial@54006900 {
-   compatible = "panasonic,uniphier-uart";
+   compatible = "socionext,uniphier-uart";
status = "disabled";
reg = <0x54006900 0x20>;
clock-frequency = <36864000>;
};
 
uart2: serial@54006a00 {
-   compatible = "panasonic,uniphier-uart";
+   compatible = "socionext,uniphier-uart";
status = "disabled";
reg = <0x54006a00 0x20>;
clock-frequency = <36864000>;
};
 
uart3: serial@54006b00 {
-   compatible = "panasonic,uniphier-uart";
+   compatible = "socionext,uniphier-uart";
status = "disabled";
reg = <0x54006b00 0x20>;
clock-frequency = <36864000>;
};
 
i2c0: i2c@5840 {
-   compatible = "panasonic,uniphier-i2c";
+   compatible = "socionext,uniphier-i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x5840 0x40>;
@@ -67,7 +68,7 @@
};
 
i2c1: i2c@5848 {
-   compatible = "panasonic,uniphier-i2c";
+   compatible = "socionext,uniphier-i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x5848 0x40>;
@@ -76,7 +77,7 @@
};
 
i2c2: i2c@5850 {
-   compatible = "panasonic,uniphier-i2c";
+   compatible = "socionext,uniphier-i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x5850 0x40>;
@@ -85,7 +86,7 @@
};
 
i2c3: i2c@5858 

Re: [U-Boot] [PATCH] Don't apply: tools: add a tool to move automatically CONFIGs from headers to defconfigs

[Masahiro Yamada]

Hi Simon,
Sorry for my late reply.

2015-03-04 9:18 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 19 January 2015 at 05:12, Masahiro Yamada  
> wrote:
>> This tool can move CONFIG macros from C headers (include/configs/*.h)
>> to defconfigs (configs/*_defconfig) all over the boards.
>>
>> There are tons of CONFIGs in U-boot and moving them by hand is
>> absolutely tool painful.  I wrote this script for my local use,
>> so this patch might not clean enough to be applied to the code base.
>> It might contain some bugs.
>>
>> Please do not apply this patch!
>>
>> This patch is here because Simon requested me to share it.
>> See the discussion in here:
>> http://lists.denx.de/pipermail/u-boot/2015-January/201556.html
>>
>> Usage:
>>
>> [1] Please run "git status" and make sure your git repository is clean.
>>
>> [2] Describe the CONFIG option you want move in the file "~/.moveconfig"
>>
>>   Say, you want to move CONFIG_CMD_NAND, for example.
>>   In this case, the content of "~/.moveconfig" should be like this:
>>
>>   $ cat .moveconfig
>>   CONFIG_CMD_NAND bool n y
>>
>>   - The first field is the name of the CONFIG.
>>   - The second field is the type of the CONFIG such as "bool", "int", "hex", 
>> etc.
>>   - The third value is the default value.
>> The value that is same as the default is omitted in each defconfig.
>> If the type of the CONFIG is bool, the default value must be either 'y' 
>> or 'n'.
>>   - The forth field shows whether the CONFIG depends on CONFIG_SPL_BUILD.
>> For example, CONFIG_CMD_* makes sense only on the main-image.
>> (depends on !SPL_BUILD)  In this case, specify 'y' in the forth fields.
>> If the CONFIG should appear also on SPL, specify 'n' here.
>>
>> [4] Run "tools/moveconfig.py"
>>
>>   The log will be displayed like this
>>
>>   $ tools/moveconfig.py
>>   Moving CONFIG_CMD_NAND (type: bool, default: n, no_spl: y) ...  (jobs: 8)
>>   ms7750se : (default)
>>   davinci_sonata   : (default)
>>   tk71 : y
>>   db-mv784mp-gp: (default)
>>   cm_t3517 : y
>>   P2041RDB_SDCARD  : y
>> ...
>>
>>   The left-hand side field is the board[defconfig] name and the colon
>>   is followed by the value of the CONFIG.
>>
>>   At the last stage, you will be asked like this:
>>
>>   Clean up CONFIG_CMD_NAND in headers? [y/n]:
>>
>>   If you say 'y' here, the defines in C headers will be removed.
>>
>> Enjoy!
>
> Just a note to say that I used this tool to handle the BOOTSTAGE
> patch. It worked very nicely, thank you.!
>
> I don't think it would take much to get this into shape for applying.
> What do you think?

OK, I will do it.


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

Re: [U-Boot] 4K padding of ARM DT blob

[Masahiro Yamada]

Hi Yehuda, Tom, Simon,



2015-03-07 0:12 GMT+09:00 Tom Rini :
> On Thu, Mar 05, 2015 at 06:20:35PM +, Yehuda Yitschak wrote:
>> Hey Tom
>>
>> In arch/arm/dts/Makfile: line 56
>> "DTC_FLAGS += -R 4 -p 0x1000"
>>
>> this tell the dtc tool to add a 4K padding to the device tree blob.
>>
>> i can't figure out why this is needed.
>> Its creating a 4KB penalty on the dtb file so i guess it has some 
>> justification.
>
> That's interesting and I don't see a corresponding thing in the kernel.
> Masahiro?  This dates back to the introduction of the Makefile and
> that's you in the git log, thanks!

Not me!
I just converted the Makefile into Kbuild style.


The option "-R 4 -p 0x1000" was introduced by:

commit bbb0b128c3956ac549471addc314702fbe0ace63
Author: Simon Glass 
Date:   Sat Oct 15 05:48:21 2011 +

fdt: Add support for embedded device tree (CONFIG_OF_EMBED)


Simon,
Looks like the 4K padding was introduced by you.
Can you explain why?

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

Re: [U-Boot] [PATCH] Exynos: Clock: Fix exynos5_get_periph_rate for I2C.

[Joonyoung Shim]

Hi,

On 03/10/2015 05:52 PM, Guillaume Gardet wrote:
> 
> 
> Le 28/02/2015 08:59, Minkyu Kang a écrit :
>> Joonyoung,
>>
>> On 26/02/15 00:22, Guillaume GARDET wrote:
>>> Commit 2e82e9252695a612ab0cbf40fa0c7368515f6506 'Exynos: Clock: Cleanup
>>> soc_get_periph_rate' introduced a bug in I2C config. This patch makes 
>>> cros_ec
>>> keyboard working again on Samsung Chromebook (snow).
>>>
>>> Signed-off-by: Guillaume GARDET 
>>> Cc: Akshay Saraswat 
>>> Cc: Minkyu Kang 
>>> Cc: Joonyoung Shim 
>>>
>>> ---
>>>   arch/arm/cpu/armv7/exynos/clock.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
>>> b/arch/arm/cpu/armv7/exynos/clock.c
>>> index c6455c2..7f47d4d 100644
>>> --- a/arch/arm/cpu/armv7/exynos/clock.c
>>> +++ b/arch/arm/cpu/armv7/exynos/clock.c
>>> @@ -423,8 +423,8 @@ static unsigned long exynos5_get_periph_rate(int 
>>> peripheral)
>>>   case PERIPH_ID_I2C6:
>>>   case PERIPH_ID_I2C7:
>>>   src = EXYNOS_SRC_MPLL;
>>> -div = readl(&clk->div_top0);
>>> -sub_div = readl(&clk->div_top1);
>>> +sub_div = readl(&clk->div_top0);
>>> +div = readl(&clk->div_top1);

Could you keep order of assign statements of div and sub_div variables?

div = readl(&clk->div_top1);
sub_div = readl(&clk->div_top0);

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

[U-Boot] [PATCH 1/2] MAINTAINERS: update Masahiro's email address

[Masahiro Yamada]

I have transferred to Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a0de3d..26780f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -159,7 +159,7 @@ F:  arch/arm/include/asm/arch-omap*/
 F: arch/arm/include/asm/ti-common/
 
 ARM UNIPHIER
-M: Masahiro Yamada 
+M: Masahiro Yamada 
 S: Maintained
 T: git git://git.denx.de/u-boot-uniphier.git
 F: arch/arm/mach-uniphier/
-- 
1.9.1

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

[U-Boot] FW: [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue

[prabha...@freescale.com]

Resending as some issue in my mail-box.

Regards,
Prabhakar

-Original Message-
From: Kushwaha Prabhakar-B32579 
Sent: Wednesday, March 11, 2015 10:01 AM
To: 'Zhao Qiang'; u-boot@lists.denx.de; Sun York-R58495
Subject: RE: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for 
down-training issue

Hi Zhao,

Can you please rephrase the subject.
No need to mention T2080QDS twice in the subject

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Zhao 
> Qiang
> Sent: Tuesday, March 10, 2015 2:55 PM
> To: u-boot@lists.denx.de; Sun York-R58495
> Cc: Zhao Qiang-B45475
> Subject: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS 
> for down-training issue
> 
> T2080QDS PEX1/Slot#1 will down-train from x4 to x2, with SRDS_PRTCL_S1 
> =
> 0x66 and SRDS_PRTCL_S2 = 0x15.
> Soft reset PCIe can fix this issue, this is a workaround.
> 

Can you please rephrase the description.

is this issue  only occur with mentioned protocol or other SerDes protocol has 
not been tested?

> Signed-off-by: Zhao Qiang 
> ---
>  drivers/pci/fsl_pci_init.c | 17 +  
> include/configs/T208xQDS.h
> |  1 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c 
> index 231b075..327fa7d 100644
> --- a/drivers/pci/fsl_pci_init.c
> +++ b/drivers/pci/fsl_pci_init.c
> @@ -481,6 +481,23 @@ void fsl_pci_init(struct pci_controller *hose, 
> struct fsl_pci_info *pci_info)  #endif
>   }
> 
> +#ifdef CONFIG_FSL_PCIE_T2080QDS_RESET
> + int i;
> + /* assert PCIe reset */
> + setbits_be32(&pci->pdb_stat, 0x0800);
> + (void) in_be32(&pci->pdb_stat);
> + udelay(1000);
> + /* clear PCIe reset */
> + clrbits_be32(&pci->pdb_stat, 0x0800);
> + asm("sync;isync");
> + for (i = 0; i < 100 && ltssm < PCI_LTSSM_L0; i++) {
> + pci_hose_read_config_word(hose, dev, PCI_LTSSM,
> +    + udelay(1000);
> + }
> +
> +#endif
> +
>  #ifdef CONFIG_SYS_P4080_ERRATUM_PCIE_A003
>   if (enabled == 0) {
>   serdes_corenet_t *srds_regs = (void 
> *)CONFIG_SYS_FSL_CORENET_SERDES_ADDR;
> diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h 
> index
> 395472b..851b4f9 100644
> --- a/include/configs/T208xQDS.h
> +++ b/include/configs/T208xQDS.h
> @@ -558,6 +558,7 @@ unsigned long get_board_ddr_clk(void);
>  #define CONFIG_PCIE2 /* PCIE controler 2 */
>  #define CONFIG_PCIE3 /* PCIE controler 3 */
>  #define CONFIG_PCIE4 /* PCIE controler 4 */
> +#define CONFIG_FSL_PCIE_T2080QDS_RESET

As your patch is reseting PCIe independent of SerDes Protocols What about 
defining CONFIG_FSL_PCIE_RESET

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

[U-Boot] [PATCH 2/2] git-mailrc: update Masahiro's email address

[Masahiro Yamada]

I have transferred to Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

 doc/git-mailrc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/git-mailrc b/doc/git-mailrc
index 025c0b3..5f8438e 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -31,7 +31,7 @@ alias luka   Luka Perkov 
 alias lukma  Lukasz Majewski 
 alias macpaulMacpaul Lin 
 alias marex  Marek Vasut 
-alias masahiro   Masahiro Yamada 
+alias masahiro   Masahiro Yamada 
 alias monstr Michal Simek 
 alias panto  Pantelis Antoniou 
 alias prafulla   Prafulla Wadaskar 
-- 
1.9.1

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

Re: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue

[prabha...@freescale.com]

Hi Zhao,

Can you please rephrase the subject.
No need to mention T2080QDS twice in the subject

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Zhao Qiang
> Sent: Tuesday, March 10, 2015 2:55 PM
> To: u-boot@lists.denx.de; Sun York-R58495
> Cc: Zhao Qiang-B45475
> Subject: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for
> down-training issue
> 
> T2080QDS PEX1/Slot#1 will down-train from x4 to x2, with SRDS_PRTCL_S1 =
> 0x66 and SRDS_PRTCL_S2 = 0x15.
> Soft reset PCIe can fix this issue, this is a workaround.
> 

Can you please rephrase the description.

is this issue  only occur with mentioned protocol or other SerDes protocol has 
not been tested?

> Signed-off-by: Zhao Qiang 
> ---
>  drivers/pci/fsl_pci_init.c | 17 +  include/configs/T208xQDS.h
> |  1 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c index
> 231b075..327fa7d 100644
> --- a/drivers/pci/fsl_pci_init.c
> +++ b/drivers/pci/fsl_pci_init.c
> @@ -481,6 +481,23 @@ void fsl_pci_init(struct pci_controller *hose, struct
> fsl_pci_info *pci_info)  #endif
>   }
> 
> +#ifdef CONFIG_FSL_PCIE_T2080QDS_RESET
> + int i;
> + /* assert PCIe reset */
> + setbits_be32(&pci->pdb_stat, 0x0800);
> + (void) in_be32(&pci->pdb_stat);
> + udelay(1000);
> + /* clear PCIe reset */
> + clrbits_be32(&pci->pdb_stat, 0x0800);
> + asm("sync;isync");
> + for (i = 0; i < 100 && ltssm < PCI_LTSSM_L0; i++) {
> + pci_hose_read_config_word(hose, dev, PCI_LTSSM,
> +    + udelay(1000);
> + }
> +
> +#endif
> +
>  #ifdef CONFIG_SYS_P4080_ERRATUM_PCIE_A003
>   if (enabled == 0) {
>   serdes_corenet_t *srds_regs = (void
> *)CONFIG_SYS_FSL_CORENET_SERDES_ADDR;
> diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h index
> 395472b..851b4f9 100644
> --- a/include/configs/T208xQDS.h
> +++ b/include/configs/T208xQDS.h
> @@ -558,6 +558,7 @@ unsigned long get_board_ddr_clk(void);
>  #define CONFIG_PCIE2 /* PCIE controler 2 */
>  #define CONFIG_PCIE3 /* PCIE controler 3 */
>  #define CONFIG_PCIE4 /* PCIE controler 4 */
> +#define CONFIG_FSL_PCIE_T2080QDS_RESET

As your patch is reseting PCIe independent of SerDes Protocols
What about defining CONFIG_FSL_PCIE_RESET

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

Re: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue

[prabha...@freescale.com]

Resending because some issue in my mail-box.

Regards,
Prabhakar

-Original Message-
From: Kushwaha Prabhakar-B32579
Sent: Wednesday, March 11, 2015 10:01 AM
To: 'Zhao Qiang'; u-boot@lists.denx.de; Sun York-R58495
Subject: RE: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for 
down-training issue

Hi Zhao,

Can you please rephrase the subject.
No need to mention T2080QDS twice in the subject

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Zhao 
> Qiang
> Sent: Tuesday, March 10, 2015 2:55 PM
> To: u-boot@lists.denx.de; Sun York-R58495
> Cc: Zhao Qiang-B45475
> Subject: [U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS 
> for down-training issue
> 
> T2080QDS PEX1/Slot#1 will down-train from x4 to x2, with SRDS_PRTCL_S1 
> =
> 0x66 and SRDS_PRTCL_S2 = 0x15.
> Soft reset PCIe can fix this issue, this is a workaround.
> 

Can you please rephrase the description.

is this issue  only occur with mentioned protocol or other SerDes protocol has 
not been tested?

> Signed-off-by: Zhao Qiang 
> ---
>  drivers/pci/fsl_pci_init.c | 17 + 
> include/configs/T208xQDS.h
> |  1 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c 
> index 231b075..327fa7d 100644
> --- a/drivers/pci/fsl_pci_init.c
> +++ b/drivers/pci/fsl_pci_init.c
> @@ -481,6 +481,23 @@ void fsl_pci_init(struct pci_controller *hose, 
> struct fsl_pci_info *pci_info)  #endif
>   }
> 
> +#ifdef CONFIG_FSL_PCIE_T2080QDS_RESET
> + int i;
> + /* assert PCIe reset */
> + setbits_be32(&pci->pdb_stat, 0x0800);
> + (void) in_be32(&pci->pdb_stat);
> + udelay(1000);
> + /* clear PCIe reset */
> + clrbits_be32(&pci->pdb_stat, 0x0800);
> + asm("sync;isync");
> + for (i = 0; i < 100 && ltssm < PCI_LTSSM_L0; i++) {
> + pci_hose_read_config_word(hose, dev, PCI_LTSSM,
> +    + udelay(1000);
> + }
> +
> +#endif
> +
>  #ifdef CONFIG_SYS_P4080_ERRATUM_PCIE_A003
>   if (enabled == 0) {
>   serdes_corenet_t *srds_regs = (void 
> *)CONFIG_SYS_FSL_CORENET_SERDES_ADDR;
> diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h 
> index
> 395472b..851b4f9 100644
> --- a/include/configs/T208xQDS.h
> +++ b/include/configs/T208xQDS.h
> @@ -558,6 +558,7 @@ unsigned long get_board_ddr_clk(void);
>  #define CONFIG_PCIE2 /* PCIE controler 2 */
>  #define CONFIG_PCIE3 /* PCIE controler 3 */
>  #define CONFIG_PCIE4 /* PCIE controler 4 */
> +#define CONFIG_FSL_PCIE_T2080QDS_RESET

As your patch is reseting PCIe independent of SerDes Protocols What about 
defining CONFIG_FSL_PCIE_RESET

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

[U-Boot] [PATCH 1/2] MAINTAINERS: update Masahiro's email address

[Masahiro Yamada]

I have transferred to Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a0de3d..26780f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -159,7 +159,7 @@ F:  arch/arm/include/asm/arch-omap*/
 F: arch/arm/include/asm/ti-common/
 
 ARM UNIPHIER
-M: Masahiro Yamada 
+M: Masahiro Yamada 
 S: Maintained
 T: git git://git.denx.de/u-boot-uniphier.git
 F: arch/arm/mach-uniphier/
-- 
1.9.1

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

Re: [U-Boot] Please pull u-boot-tegra.git/master

[Tom Warren]

Thanks, Tom. Should I send future PRs to you instead of Albert?
 On Mar 10, 2015 5:55 PM, "Tom Rini"  wrote:

> On Tue, Mar 10, 2015 at 10:25:03PM +, Tom Warren wrote:
>
> > Albert – are you getting these emails? I know they’re bouncing from
> > the list (need to find a mailer that doesn’t use MIME64), but I
> > haven’t heard back from you for the last 2 PRs.
>
> FWIW, you can make git send-email do the sending of the PR and that may
> help.  Esp since it looks like you already have gmail setup to know your
> work email (if not it's an easy enough thing to make it send from it, I
> did it back at TI even).
>
> >
> > Should I send these to Tom Rini instead?  Please let me know.
>
> Yeah, I'm doing ARM SoC PRs now.
>
> >
> > Tom
> >
> > From: Tom Warren [mailto:tomcwarren3...@gmail.com]
> > Sent: Thursday, March 05, 2015 4:27 PM
> > To: Albert ARIBAUD
> > Cc: u-boot@lists.denx.de; Marcel Ziswiler; Stephen Warren; Tom Warren
> > Subject: Please pull u-boot-tegra.git/master
> >
> > Albert,
> > Please pull u-boot-tegra.git/master into ARM master.   ./MAKEALL -s
> tegra is clean. Stephen confirmed that Jetson-TK1 looks OK.
> > NOTE: This PR includes some of Stephen's patches from a previous PR that
> never went in AFAICT (Sent Feb 3rd).  I'm sending this from my Gmail
> account since my work Outlook always bounces from the list due to base64
> MIME errors.
> >
> > The following changes since commit
> 02251eefc95c477f4ff6aa7568dfd4be7c69c31f:
> >
> >   ARM: HYP/non-sec: relocation before enable secondary cores (2015-03-01
> 16:33:21 +0100)
> >
> > are available in the git repository at:
> >
> >   git://git.denx.de/u-boot-tegra.git
> master
> >
> > for you to fetch changes up to d5338c693e6a35a7108c184839d688a7377d117c:
> >
> >   apalis/colibri_t30: add misc cmds increase buf sizes and max args
> (2015-03-04 10:09:02 -0700)
> >
>
> Applied to u-boot/master, thanks!
>
> --
> Tom
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] git-mailrc: update Masahiro's email address

[Masahiro Yamada]

I have transferred to Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

 doc/git-mailrc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/git-mailrc b/doc/git-mailrc
index 025c0b3..5f8438e 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -31,7 +31,7 @@ alias luka   Luka Perkov 
 alias lukma  Lukasz Majewski 
 alias macpaulMacpaul Lin 
 alias marex  Marek Vasut 
-alias masahiro   Masahiro Yamada 
+alias masahiro   Masahiro Yamada 
 alias monstr Michal Simek 
 alias panto  Pantelis Antoniou 
 alias prafulla   Prafulla Wadaskar 
-- 
1.9.1

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

[U-Boot] [PATCH] x86: quark: Enable on-chip ethernet controllers

[Bin Meng]

Intel Quark SoC integrates two 10/100 ethernet controllers which can
be connected to an external RMII PHY. The MAC IP is from Designware.
Enable this support with the existing U-Boot Designware MAC driver
so that the ethernet port on Intel Galileo board can be used.

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/quark/quark.c | 19 +++
 include/configs/galileo.h  |  5 +
 2 files changed, 24 insertions(+)

diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c
index dccf7ac..25edcf7 100644
--- a/arch/x86/cpu/quark/quark.c
+++ b/arch/x86/cpu/quark/quark.c
@@ -6,6 +6,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -116,3 +118,20 @@ int cpu_mmc_init(bd_t *bis)
return pci_mmc_init("Quark SDHCI", mmc_supported,
ARRAY_SIZE(mmc_supported));
 }
+
+int cpu_eth_init(bd_t *bis)
+{
+   u32 base;
+   int ret0, ret1;
+
+   pci_read_config_dword(QUARK_EMAC0, PCI_BASE_ADDRESS_0, &base);
+   ret0 = designware_initialize(base, PHY_INTERFACE_MODE_RMII);
+
+   pci_read_config_dword(QUARK_EMAC1, PCI_BASE_ADDRESS_0, &base);
+   ret1 = designware_initialize(base, PHY_INTERFACE_MODE_RMII);
+
+   if (ret0 < 0 && ret1 < 0)
+   return -1;
+   else
+   return 0;
+}
diff --git a/include/configs/galileo.h b/include/configs/galileo.h
index d745f4e..65a2c3e 100644
--- a/include/configs/galileo.h
+++ b/include/configs/galileo.h
@@ -57,4 +57,9 @@
 #define CONFIG_MMC_SDMA
 #define CONFIG_CMD_MMC
 
+/* 10/100M Ethernet support */
+#define CONFIG_DESIGNWARE_ETH
+#define CONFIG_DW_ALTDESCRIPTOR
+#define CONFIG_PHYLIB
+
 #endif /* __CONFIG_H */
-- 
1.8.2.1

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

[U-Boot] Clearing silent environment variable not taking affect at boot

[Chris Packham]

Hi,

I have a board using SPI flash for it's boot-loader and environment,
I'm currently based of u-boot 2014.01. In my boards config file I have
the following

#define CONFIG_SILENT_CONSOLE
#define CONFIG_SILENT_U_BOOT_ONLY
#define CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC
#define CONFIG_BOARD_EXTRA_ENV_SETTINGS "silent=1"

By default I want u-boot to be silent, and that's what I get. But for
debugging I do want to be able to run "setenv silent; saveenv; reset"
to enable non-silent mode. Unfortunately this doesn't work for me.

I _think_ the problem is that when console_init_f() is called the
environment can't be read from SPI flash so I get the default silent=1
behaviour (and that's OK). After relocation the environment is read
from SPI flash for some reason the on_silent() callback isn't called
I'm not sure why but I'm guessing that hdelete_r() is bypassed
(possibly because the whole default environment is dropped) thus the
callback for silent being deleted is not invoked.

Is my thinking along the right lines?

Would there be any objection to doing something like this:

diff --git a/common/console.c b/common/console.c
index 29560c3..6719019 100644
--- a/common/console.c
+++ b/common/console.c
@@ -808,6 +808,11 @@ int console_init_r(void)
struct list_head *pos;
struct stdio_dev *dev;

+#ifdef CONFIG_SILENT_CONSOLE
+   if (getenv("silent") == NULL)
+   gd->flags &= ~GD_FLG_SILENT;
+#endif
+
 #ifdef CONFIG_SPLASH_SCREEN
/*
 * suppress all output if splash screen is enabled and we have

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

Re: [U-Boot] [PATCH] mmc: fsl_esdhc fix register offset

[Peng Fan]

Hi, Marek

On 3/11/2015 10:03 AM, Marek Vasut wrote:

On Wednesday, March 11, 2015 at 01:58:37 AM, Peng Fan wrote:

Hi, Marek

Hi!


On 3/10/2015 9:45 PM, Marek Vasut wrote:

On Tuesday, March 10, 2015 at 08:35:46 AM, Peng Fan wrote:

Commit f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1 introduces
error register offset.

Change the "char reserved3[59]" to "char reserved3[56]".

Signed-off-by: Peng Fan 

This should probably be applied to 2015.04 .

What are the symptoms of this bug please ?

I just found the reserved3 size is wrong, did not do test.
  From the driver, only the entry 'scr' of fsl_esdhc below reserved3 is
used, so the offset of scr is wrong if using `char reserved3[59]`

Uh, is the patch tested at all on real hardware ?
Still not test on real hardware. From commit 
f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1,

"
uintadsaddr;/* ADMA system address register */
-   charreserved2[160]; /* reserved */
+   charreserved2[100]; /* reserved */
+   uintvendorspec; /* Vendor Specific register */
+   charreserved3[59];  /* reserved */
uinthostver;/* Host controller version register */
"
It's clear that 160 bytes does not equal with (100 + 4 + 59)bytes.


Best regards,
Marek Vasut

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

Re: [U-Boot] [PATCH] mmc: fsl_esdhc fix register offset

[Marek Vasut]

On Wednesday, March 11, 2015 at 01:58:37 AM, Peng Fan wrote:
> Hi, Marek

Hi!

> On 3/10/2015 9:45 PM, Marek Vasut wrote:
> > On Tuesday, March 10, 2015 at 08:35:46 AM, Peng Fan wrote:
> >> Commit f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1 introduces
> >> error register offset.
> >> 
> >> Change the "char reserved3[59]" to "char reserved3[56]".
> >> 
> >> Signed-off-by: Peng Fan 
> > 
> > This should probably be applied to 2015.04 .
> > 
> > What are the symptoms of this bug please ?
> 
> I just found the reserved3 size is wrong, did not do test.
>  From the driver, only the entry 'scr' of fsl_esdhc below reserved3 is
> used, so the offset of scr is wrong if using `char reserved3[59]`

Uh, is the patch tested at all on real hardware ?

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

Re: [U-Boot] [PATCH] mmc: fsl_esdhc fix register offset

[Peng Fan]

Hi, Marek

On 3/10/2015 9:45 PM, Marek Vasut wrote:

On Tuesday, March 10, 2015 at 08:35:46 AM, Peng Fan wrote:

Commit f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1 introduces
error register offset.

Change the "char reserved3[59]" to "char reserved3[56]".

Signed-off-by: Peng Fan 

This should probably be applied to 2015.04 .

What are the symptoms of this bug please ?

I just found the reserved3 size is wrong, did not do test.
From the driver, only the entry 'scr' of fsl_esdhc below reserved3 is 
used, so the offset of scr is wrong if using `char reserved3[59]`


Thanks for spotting this!

Best regards,
Marek Vasut

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

Re: [U-Boot] Please pull u-boot-tegra.git/master

[Tom Rini]

On Tue, Mar 10, 2015 at 10:25:03PM +, Tom Warren wrote:

> Albert – are you getting these emails? I know they’re bouncing from
> the list (need to find a mailer that doesn’t use MIME64), but I
> haven’t heard back from you for the last 2 PRs.

FWIW, you can make git send-email do the sending of the PR and that may
help.  Esp since it looks like you already have gmail setup to know your
work email (if not it's an easy enough thing to make it send from it, I
did it back at TI even).

> 
> Should I send these to Tom Rini instead?  Please let me know.

Yeah, I'm doing ARM SoC PRs now.

> 
> Tom
> 
> From: Tom Warren [mailto:tomcwarren3...@gmail.com]
> Sent: Thursday, March 05, 2015 4:27 PM
> To: Albert ARIBAUD
> Cc: u-boot@lists.denx.de; Marcel Ziswiler; Stephen Warren; Tom Warren
> Subject: Please pull u-boot-tegra.git/master
> 
> Albert,
> Please pull u-boot-tegra.git/master into ARM master.   ./MAKEALL -s tegra is 
> clean. Stephen confirmed that Jetson-TK1 looks OK.
> NOTE: This PR includes some of Stephen's patches from a previous PR that 
> never went in AFAICT (Sent Feb 3rd).  I'm sending this from my Gmail account 
> since my work Outlook always bounces from the list due to base64 MIME errors.
> 
> The following changes since commit 02251eefc95c477f4ff6aa7568dfd4be7c69c31f:
> 
>   ARM: HYP/non-sec: relocation before enable secondary cores (2015-03-01 
> 16:33:21 +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-tegra.git 
> master
> 
> for you to fetch changes up to d5338c693e6a35a7108c184839d688a7377d117c:
> 
>   apalis/colibri_t30: add misc cmds increase buf sizes and max args 
> (2015-03-04 10:09:02 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v5 15/27] dm: eth: Pass the packet pointer as a parameter to recv

[Joe Hershberger]

On Tue, Mar 10, 2015 at 6:31 PM, Simon Glass  wrote:
>
> Hi Joe,
>
> On 10 March 2015 at 16:28, Joe Hershberger 
wrote:
> > On Wed, Mar 4, 2015 at 12:35 PM, Simon Glass  wrote:
> >>
> >> Hi Joe,
> >>
> >> On 3 March 2015 at 19:41, Joe Hershberger 
wrote:
> >> > Stop forcing drivers to call net_process_received_packet() - formerly
> >> > called NetReceive(). Now the uclass will handle calling the driver
for
> >> > each packet until the driver errors or has nothing to return. The
uclass
> >> > will then pass the good packets off to the network stack by calling
> >> > net_process_received_packet().
> >> >
> >> > Signed-off-by: Joe Hershberger 
> >> >
> >> > ---
> >> >
> >> > Changes in v5:
> >> > -New to v5
> >> >
> >> > Changes in v4: None
> >> > Changes in v3: None
> >> > Changes in v2: None
> >> >
> >> >  include/net.h |  2 +-
> >> >  net/eth.c | 13 -
> >> >  2 files changed, 13 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/include/net.h b/include/net.h
> >> > index 4e44832..37d1f36 100644
> >> > --- a/include/net.h
> >> > +++ b/include/net.h
> >> > @@ -110,7 +110,7 @@ struct eth_pdata {
> >> >  struct eth_ops {
> >> > int (*start)(struct udevice *dev);
> >> > int (*send)(struct udevice *dev, void *packet, int length);
> >> > -   int (*recv)(struct udevice *dev);
> >> > +   int (*recv)(struct udevice *dev, uchar **packetp);
> >>
> >> Need to update docs above. With serial we return -EAGAIN when there is
> >> nothing more to receive. So you might want to swallow that error
> >> instead of returning it from eth_rx().
> >
> > I was doing this filtering in the sandbox-raw driver, but I can easily
to it
> > here instead (or too) so that it doesn't leak through from other drivers
> > that do not do this check in the future.
>
> OK. My main concerns are:
>
> 1. Avoid wait loops in drivers (if needed they should be in the uclass
> triggered by -EAGAIN)

Drivers are expected to return and not wait. I've made this more clear in
the function comment.

> 2. Ensure that uclass ops methods are clearly documented as to
> purpose, parameters, return value, etc, so people don't have to resort
> to archaeology to do the right thing :-)

The new function comment looks like this:

+ * recv: Check if the hardware received a packet. If so, set the pointer
to the
+ *  packet buffer in the packetp parameter. If not, return an error or
0 to
+ *  indicate that the hardware receive FIFO is empty

> >
> >> > void (*stop)(struct udevice *dev);
> >> >  #ifdef CONFIG_MCAST_TFTP
> >> > int (*mcast)(struct udevice *dev, const u8 *enetaddr, int
join);
> >> > diff --git a/net/eth.c b/net/eth.c
> >> > index 1abf027..b66d253 100644
> >> > --- a/net/eth.c
> >> > +++ b/net/eth.c
> >> > @@ -259,6 +259,9 @@ int eth_send(void *packet, int length)
> >> >  int eth_rx(void)
> >> >  {
> >> > struct udevice *current;
> >> > +   uchar *packet;
> >> > +   int ret;
> >> > +   int i;
> >> >
> >> > current = eth_get_dev();
> >> > if (!current)
> >> > @@ -267,7 +270,15 @@ int eth_rx(void)
> >> > if (!device_active(current))
> >> > return -EINVAL;
> >> >
> >> > -   return eth_get_ops(current)->recv(current);
> >> > +   /* Process up to 32 packets at one time */
> >> > +   for (i = 0; i < 32; i++) {
> >> > +   ret = eth_get_ops(current)->recv(current, &packet);
> >> > +   if (ret > 0)
> >> > +   net_process_received_packet(packet, ret);
> >> > +   else
> >> > +   break;
> >> > +   }
> >> > +   return ret;
> >> >  }
> >> >
> >> >  static int eth_write_hwaddr(struct udevice *dev)
> >> > --
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 15/27] dm: eth: Pass the packet pointer as a parameter to recv

[Simon Glass]

Hi Joe,

On 10 March 2015 at 16:28, Joe Hershberger  wrote:
> On Wed, Mar 4, 2015 at 12:35 PM, Simon Glass  wrote:
>>
>> Hi Joe,
>>
>> On 3 March 2015 at 19:41, Joe Hershberger  wrote:
>> > Stop forcing drivers to call net_process_received_packet() - formerly
>> > called NetReceive(). Now the uclass will handle calling the driver for
>> > each packet until the driver errors or has nothing to return. The uclass
>> > will then pass the good packets off to the network stack by calling
>> > net_process_received_packet().
>> >
>> > Signed-off-by: Joe Hershberger 
>> >
>> > ---
>> >
>> > Changes in v5:
>> > -New to v5
>> >
>> > Changes in v4: None
>> > Changes in v3: None
>> > Changes in v2: None
>> >
>> >  include/net.h |  2 +-
>> >  net/eth.c | 13 -
>> >  2 files changed, 13 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/include/net.h b/include/net.h
>> > index 4e44832..37d1f36 100644
>> > --- a/include/net.h
>> > +++ b/include/net.h
>> > @@ -110,7 +110,7 @@ struct eth_pdata {
>> >  struct eth_ops {
>> > int (*start)(struct udevice *dev);
>> > int (*send)(struct udevice *dev, void *packet, int length);
>> > -   int (*recv)(struct udevice *dev);
>> > +   int (*recv)(struct udevice *dev, uchar **packetp);
>>
>> Need to update docs above. With serial we return -EAGAIN when there is
>> nothing more to receive. So you might want to swallow that error
>> instead of returning it from eth_rx().
>
> I was doing this filtering in the sandbox-raw driver, but I can easily to it
> here instead (or too) so that it doesn't leak through from other drivers
> that do not do this check in the future.

OK. My main concerns are:

1. Avoid wait loops in drivers (if needed they should be in the uclass
triggered by -EAGAIN)
2. Ensure that uclass ops methods are clearly documented as to
purpose, parameters, return value, etc, so people don't have to resort
to archaeology to do the right thing :-)

>
>> > void (*stop)(struct udevice *dev);
>> >  #ifdef CONFIG_MCAST_TFTP
>> > int (*mcast)(struct udevice *dev, const u8 *enetaddr, int join);
>> > diff --git a/net/eth.c b/net/eth.c
>> > index 1abf027..b66d253 100644
>> > --- a/net/eth.c
>> > +++ b/net/eth.c
>> > @@ -259,6 +259,9 @@ int eth_send(void *packet, int length)
>> >  int eth_rx(void)
>> >  {
>> > struct udevice *current;
>> > +   uchar *packet;
>> > +   int ret;
>> > +   int i;
>> >
>> > current = eth_get_dev();
>> > if (!current)
>> > @@ -267,7 +270,15 @@ int eth_rx(void)
>> > if (!device_active(current))
>> > return -EINVAL;
>> >
>> > -   return eth_get_ops(current)->recv(current);
>> > +   /* Process up to 32 packets at one time */
>> > +   for (i = 0; i < 32; i++) {
>> > +   ret = eth_get_ops(current)->recv(current, &packet);
>> > +   if (ret > 0)
>> > +   net_process_received_packet(packet, ret);
>> > +   else
>> > +   break;
>> > +   }
>> > +   return ret;
>> >  }
>> >
>> >  static int eth_write_hwaddr(struct udevice *dev)
>> > --

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

Re: [U-Boot] [PATCH v5 15/27] dm: eth: Pass the packet pointer as a parameter to recv

[Joe Hershberger]

On Wed, Mar 4, 2015 at 12:35 PM, Simon Glass  wrote:
>
> Hi Joe,
>
> On 3 March 2015 at 19:41, Joe Hershberger  wrote:
> > Stop forcing drivers to call net_process_received_packet() - formerly
> > called NetReceive(). Now the uclass will handle calling the driver for
> > each packet until the driver errors or has nothing to return. The uclass
> > will then pass the good packets off to the network stack by calling
> > net_process_received_packet().
> >
> > Signed-off-by: Joe Hershberger 
> >
> > ---
> >
> > Changes in v5:
> > -New to v5
> >
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> >  include/net.h |  2 +-
> >  net/eth.c | 13 -
> >  2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/net.h b/include/net.h
> > index 4e44832..37d1f36 100644
> > --- a/include/net.h
> > +++ b/include/net.h
> > @@ -110,7 +110,7 @@ struct eth_pdata {
> >  struct eth_ops {
> > int (*start)(struct udevice *dev);
> > int (*send)(struct udevice *dev, void *packet, int length);
> > -   int (*recv)(struct udevice *dev);
> > +   int (*recv)(struct udevice *dev, uchar **packetp);
>
> Need to update docs above. With serial we return -EAGAIN when there is
> nothing more to receive. So you might want to swallow that error
> instead of returning it from eth_rx().

I was doing this filtering in the sandbox-raw driver, but I can easily to
it here instead (or too) so that it doesn't leak through from other drivers
that do not do this check in the future.

> > void (*stop)(struct udevice *dev);
> >  #ifdef CONFIG_MCAST_TFTP
> > int (*mcast)(struct udevice *dev, const u8 *enetaddr, int join);
> > diff --git a/net/eth.c b/net/eth.c
> > index 1abf027..b66d253 100644
> > --- a/net/eth.c
> > +++ b/net/eth.c
> > @@ -259,6 +259,9 @@ int eth_send(void *packet, int length)
> >  int eth_rx(void)
> >  {
> > struct udevice *current;
> > +   uchar *packet;
> > +   int ret;
> > +   int i;
> >
> > current = eth_get_dev();
> > if (!current)
> > @@ -267,7 +270,15 @@ int eth_rx(void)
> > if (!device_active(current))
> > return -EINVAL;
> >
> > -   return eth_get_ops(current)->recv(current);
> > +   /* Process up to 32 packets at one time */
> > +   for (i = 0; i < 32; i++) {
> > +   ret = eth_get_ops(current)->recv(current, &packet);
> > +   if (ret > 0)
> > +   net_process_received_packet(packet, ret);
> > +   else
> > +   break;
> > +   }
> > +   return ret;
> >  }
> >
> >  static int eth_write_hwaddr(struct udevice *dev)
> > --
> > 1.7.11.5
> >
>
> Regards,
> Simon
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 27/27] net: Improve error handling

[Joe Hershberger]

On Wed, Mar 4, 2015 at 12:35 PM, Simon Glass  wrote:
>
> Hi Joe,
>
> On 3 March 2015 at 19:41, Joe Hershberger  wrote:
> > Take a pass at plumbing errors through to the users of the network stack
> >
> > Currently only the start() function errors will be returned from
> > NetLoop(). recv() tends not to have errors, so that is likely not worth
> > adding. send() certainly can return errors, but this patch does not
> > attempt to plumb them yet. halt() is not expected to error.
> >
> > Signed-off-by: Joe Hershberger 
>
> Nice patch!
>
> Reviewed-by: Simon Glass 
>
> >
> > ---
> >
> > Changes in v5:
> > -New to v5
> >
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> >  include/net.h |  3 ++-
> >  net/eth.c | 56

> >  net/net.c | 26 ++
> >  test/dm/eth.c |  4 ++--
> >  4 files changed, 70 insertions(+), 19 deletions(-)
> >

[snip]

> > diff --git a/net/net.c b/net/net.c
> > index afec443..69f38f7 100644
> > --- a/net/net.c
> > +++ b/net/net.c
> > @@ -84,6 +84,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #if defined(CONFIG_STATUS_LED)
> >  #include 
> > @@ -333,7 +334,7 @@ void net_init(void)
> >
> >  int NetLoop(enum proto_t protocol)
> >  {
> > -   int ret = -1;
> > +   int ret = -EINVAL;
> >
> > NetRestarted = 0;
> > NetDevExists = 0;
> > @@ -345,9 +346,10 @@ int NetLoop(enum proto_t protocol)
> > if (eth_is_on_demand_init() || protocol != NETCONS) {
> > eth_halt();
> > eth_set_current();
> > -   if (eth_init() < 0) {
> > +   ret = eth_init();
> > +   if (ret < 0) {
> > eth_halt();
> > -   return -1;
> > +   return ret;
> > }
> > } else
> > eth_init_state_only();
> > @@ -370,7 +372,7 @@ restart:
> > case 1:
> > /* network not configured */
> > eth_halt();
> > -   return -1;
> > +   return -ENODEV;
> >
> > case 2:
> > /* network device not configured */
> > @@ -484,6 +486,8 @@ restart:
> > /*
> >  *  Check the ethernet for a new packet.  The
ethernet
> >  *  receive routine will process it.
> > +*  Most drivers return the most recent packet
size, but not
> > +*  errors that may have happened.
> >  */
> > eth_rx();
> >
> > @@ -537,7 +541,7 @@ restart:
> > }
> >
> > if (net_state == NETLOOP_FAIL)
> > -   NetStartAgain();
> > +   ret = NetStartAgain();
>
> Where does this 'ret' get used?

This is part of the NetLoop() function, the top-most interface to the
network stack in net.c.

If the net_state remains "NETLOOP_FAIL" after calling NetStartAgain, then
the case structure following this if will "goto done".

At the end of done: is:

   return ret;

We need to pass the return value out of NetStartAgain, since it can
possibly call eth_ops->start() on a new device.

> >
> > switch (net_state) {
> >
> > @@ -597,11 +601,12 @@ startAgainTimeout(void)
> > net_set_state(NETLOOP_RESTART);
> >  }
> >
> > -void NetStartAgain(void)
> > +int NetStartAgain(void)
> >  {
> > char *nretry;
> > int retry_forever = 0;
> > unsigned long retrycnt = 0;
> > +   int ret;
> >
> > nretry = getenv("netretry");
> > if (nretry) {
> > @@ -621,7 +626,11 @@ void NetStartAgain(void)
> > if ((!retry_forever) && (NetTryCount >= retrycnt)) {
> > eth_halt();
> > net_set_state(NETLOOP_FAIL);
> > -   return;
> > +   /*
> > +* We don't provide a way for the protocol to return an
error,
> > +* but this is almost always the reason.
> > +*/
> > +   return -ETIMEDOUT;
> > }
> >
> > NetTryCount++;
> > @@ -630,7 +639,7 @@ void NetStartAgain(void)
> >  #if !defined(CONFIG_NET_DO_NOT_TRY_ANOTHER)
> > eth_try_another(!NetRestarted);
> >  #endif
> > -   eth_init();
> > +   ret = eth_init();
> > if (NetRestartWrap) {
> > NetRestartWrap = 0;
> > if (NetDevExists) {
> > @@ -642,6 +651,7 @@ void NetStartAgain(void)
> > } else {
> > net_set_state(NETLOOP_RESTART);
> > }
> > +   return ret;
> >  }
> >
> >
 /**/

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

Re: [U-Boot] Please pull u-boot-tegra.git/master

[Tom Warren]

Albert – are you getting these emails? I know they’re bouncing from the list 
(need to find a mailer that doesn’t use MIME64), but I haven’t heard back from 
you for the last 2 PRs.

Should I send these to Tom Rini instead?  Please let me know.

Tom

From: Tom Warren [mailto:tomcwarren3...@gmail.com]
Sent: Thursday, March 05, 2015 4:27 PM
To: Albert ARIBAUD
Cc: u-boot@lists.denx.de; Marcel Ziswiler; Stephen Warren; Tom Warren
Subject: Please pull u-boot-tegra.git/master

Albert,
Please pull u-boot-tegra.git/master into ARM master.   ./MAKEALL -s tegra is 
clean. Stephen confirmed that Jetson-TK1 looks OK.
NOTE: This PR includes some of Stephen's patches from a previous PR that never 
went in AFAICT (Sent Feb 3rd).  I'm sending this from my Gmail account since my 
work Outlook always bounces from the list due to base64 MIME errors.

The following changes since commit 02251eefc95c477f4ff6aa7568dfd4be7c69c31f:

  ARM: HYP/non-sec: relocation before enable secondary cores (2015-03-01 
16:33:21 +0100)

are available in the git repository at:

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

for you to fetch changes up to d5338c693e6a35a7108c184839d688a7377d117c:

  apalis/colibri_t30: add misc cmds increase buf sizes and max args (2015-03-04 
10:09:02 -0700)


Marcel Ziswiler (4):
  dm: tegra: dts: add aliases for spi on apalis_t30
  apalis/colibri_t30: fix MMC/SD card detect GPIOs
  apalis_t30: enable gigabit ethernet via pcie
  apalis/colibri_t30: add misc cmds increase buf sizes and max args

Stephen Warren (16):
  common: board: support systems with where RAM ends beyond 4GB
  ARM: tegra: fix variable naming in query_sdram_size()
  ARM: tegra: support large RAM sizes
  ARM: tegra: move common config defines centrally
  ARM: tegra: support running in non-secure mode
  ARM: tegra: add function to clear pinmux CLAMPING bit
  ARM: tegra: import latest Jetson TK1 pinmux
  ARM: tegra: pinmux: add note re: drive group field defines
  ARM: tegra: pinmux: simplify some defines
  ARM: tegra: pinmux: handle feature removal on newer SoCs
  ARM: tegra: pinmux: move some type definitions
  ARM: tegra: pinmux: partially handle varying register layouts
  ARM: tegra: pinmux: support hsm/schmitt on pins
  ARM: tegra: pinmux: account for different drivegroup base registers
  ARM: tegra: pinmux: support Tegra210's e_io_hv pin option
  ARM: tegra: pinmux: add Tegra210 support

 README |   7 +
 arch/arm/cpu/tegra210-common/pinmux.c  | 195 ++
 arch/arm/dts/tegra30-apalis.dts|  13 +-
 arch/arm/dts/tegra30-colibri.dts   |   4 +-
 arch/arm/include/asm/arch-tegra/ap.h   |   4 +
 arch/arm/include/asm/arch-tegra/pinmux.h   | 110 --
 arch/arm/include/asm/arch-tegra114/pinmux.h|  14 +-
 arch/arm/include/asm/arch-tegra124/pinmux.h|  14 +-
 arch/arm/include/asm/arch-tegra20/pinmux.h |   1 +
 arch/arm/include/asm/arch-tegra210/pinmux.h| 416 +
 arch/arm/include/asm/arch-tegra30/pinmux.h |  11 +-
 arch/arm/mach-tegra/board.c|  56 ++-
 arch/arm/mach-tegra/clock.c|   6 +-
 arch/arm/mach-tegra/pinmux-common.c| 223 +--
 board/nvidia/common/board.c|   9 +
 board/nvidia/jetson-tk1/jetson-tk1.c   |   2 +-
 board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h | 303 +++
 common/board_f.c   |  12 +
 include/configs/apalis_t30.h   |  31 +-
 include/configs/beaver.h   |   2 -
 include/configs/cardhu.h   |   2 -
 include/configs/colibri_t20_iris.h |   2 -
 include/configs/colibri_t30.h  |  26 +-
 include/configs/dalmore.h  |   2 -
 include/configs/harmony.h  |   3 -
 include/configs/jetson-tk1.h   |   2 -
 include/configs/medcom-wide.h  |   3 -
 include/configs/nyan-big.h |   2 -
 include/configs/paz00.h|   3 -
 include/configs/plutux.h   |   3 -
 include/configs/seaboard.h |   3 -
 include/configs/tec-ng.h   |   2 -
 include/configs/tec.h  |   3 -
 include/configs/tegra-common.h |   2 +
 include/configs/trimslice.h|   2 -
 include/configs/venice2.h  |   2 -
 include/configs/ventana.h  |   3 -
 include/configs/whistler.h |   2 -
 38 files changed, 1197 insertions(+), 303 deletions(-)
 create mode 100644

[U-Boot] [PATCH] config_distro_bootcmd.h: add note on error handling

[Stephen Warren]

From: Stephen Warren 

This should make it more clear why there appear to be C pre-processor
symbols in the file that contain mixed case. They're really error
messages.

Suggested-by: Simon Glass 
Signed-off-by: Stephen Warren 
---
 include/config_distro_bootcmd.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 07a0b3b23472..73f093f9eaf5 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -10,6 +10,22 @@
 #ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
 #define _CONFIG_CMD_DISTRO_BOOTCMD_H
 
+/*
+ * A note on error handling: It is possible for BOOT_TARGET_DEVICES to
+ * reference a device that is not enabled in the U-Boot configuration, e.g.
+ * it may include MMC in the list without CONFIG_CMD_MMC being enabled. Given
+ * that BOOT_TARGET_DEVICES is a macro that's expanded by the C pre-processor
+ * at compile time, it's not  possible to detect and report such problems via
+ * a simple #ifdef/#error combination. Still, the code needs to report errors.
+ * The best way I've found to do this is to make BOOT_TARGET_DEVICES expand to
+ * reference a non-existent symbol, and have the name of that symbol encode
+ * the error message. Consequently, this file contains references to e.g.
+ * BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC. Given the
+ * prevalence of capitals here, this looks like a pre-processor macro and
+ * hence seems like it should be all capitals, but it's really an error
+ * message that includes some other pre-processor symbols in the text.
+ */
+
 /* We need the part command */
 #define CONFIG_PARTITION_UUIDS
 #define CONFIG_CMD_PART
-- 
1.9.1

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

Re: [U-Boot] MLO & u-boot.img built from stream - not booting j6 evm.

[Tom Rini]

On Tue, Mar 10, 2015 at 07:20:04PM +, Korupol, Naveen (EXT) wrote:

> Hi
> 
> I have downloaded "u-boot-arm-02251ee.tar.gz" and built locally.
> 
> The resulting MLO and U-Boot cannot boot my TI J6 EVM.
> 
> I had a U-Boot SPL 2013.04 (Sep 24 2014 - 00:00:28) - U-boot/MLO pair working 
> with a device tree on the same EVM.
> 
> Any clues are appreciated. - thanks

Please contact wherever that U-Boot is from as that's not a mainline
tree.  Mainline should work reasonably well on the J6 EVM.

-- 
Tom


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

[U-Boot] MLO & u-boot.img built from stream - not booting j6 evm.

[Korupol, Naveen (EXT)]

Hi

I have downloaded "u-boot-arm-02251ee.tar.gz" and built locally.

The resulting MLO and U-Boot cannot boot my TI J6 EVM.

I had a U-Boot SPL 2013.04 (Sep 24 2014 - 00:00:28) - U-boot/MLO pair working 
with a device tree on the same EVM.

Any clues are appreciated. - thanks

Regards
Naveen
Please note my new email address naveen.koru...@ext.us.panasonic.com. The old 
address will be available until September 15, 2015.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] MLO & u-boot.img built from stream - not booting j6 evm.

[Korupol, Naveen (EXT)]

Hi

I have downloaded "u-boot-arm-02251ee.tar.gz" and built locally.

The resulting MLO and U-Boot cannot boot my TI J6 EVM.

I had a U-Boot SPL 2013.04 (Sep 24 2014 - 00:00:28) - U-boot/MLO pair working 
with a device tree on the same EVM.

Any clues are appreciated. - thanks

Regards
Naveen
Please note my new email address naveen.koru...@ext.us.panasonic.com. The old 
address will be available until September 15, 2015.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/8] lpc32xx: mtd: nand: add MLC NAND controller

[Albert ARIBAUD]

Bonjour Scott,

Le Tue, 10 Mar 2015 13:49:46 -0500, Scott Wood
 a écrit :

> On Tue, 2015-03-10 at 13:54 +0100, Albert ARIBAUD wrote:
> > Hi Scott,
> > 
> > Le Mon, 9 Mar 2015 18:51:03 -0500, Scott Wood 
> > a écrit :
> > 
> > > On Thu, 2015-03-05 at 07:46 +0100, Albert ARIBAUD (3ADEV) wrote:
> > > > +   while (left) {
> > > > +   if (read_single_page(dst, page) >= 0) {
> > > > +   dst += LARGE_PAGE_SIZE;
> > > > +   page++;
> > > > +   left--;
> > > > +   }
> > > > +   }
> > > 
> > > No bad block skipping?
> > 
> > Hmm... actually the 'left--' should be just after the 'if' block,
> > otherwise not only will the code not skip a bad block, it will actually
> > loop infinitely trying to read it. Will fix in v4. Thanks for pointing
> > this out!
> 
> What causes read_single_page() to fail when there's a bad block marker?
> Especially if the marker is on a different page of the block.  I'm not
> talking about ECC failures (which should not silently be skipped).

Oh gods, I see, sorry. I was indeed mixing up ECC errors and bad block
markers. Show I'm really not good at NAND. :/

I'll look up how other drivers do it and add bad block skipping there.

> -Scott

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

Re: [U-Boot] [PATCH v3 2/8] lpc32xx: mtd: nand: add MLC NAND controller

[Scott Wood]

On Tue, 2015-03-10 at 13:54 +0100, Albert ARIBAUD wrote:
> Hi Scott,
> 
> Le Mon, 9 Mar 2015 18:51:03 -0500, Scott Wood 
> a écrit :
> 
> > On Thu, 2015-03-05 at 07:46 +0100, Albert ARIBAUD (3ADEV) wrote:
> > > + while (left) {
> > > + if (read_single_page(dst, page) >= 0) {
> > > + dst += LARGE_PAGE_SIZE;
> > > + page++;
> > > + left--;
> > > + }
> > > + }
> > 
> > No bad block skipping?
> 
> Hmm... actually the 'left--' should be just after the 'if' block,
> otherwise not only will the code not skip a bad block, it will actually
> loop infinitely trying to read it. Will fix in v4. Thanks for pointing
> this out!

What causes read_single_page() to fail when there's a bad block marker?
Especially if the marker is on a different page of the block.  I'm not
talking about ECC failures (which should not silently be skipped).

-Scott


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

Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

[Scott Wood]

On Tue, 2015-03-10 at 13:27 -0500, Bansal Aneesh-B39320 wrote:
> 
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, March 10, 2015 11:29 PM
> > To: Bansal Aneesh-B39320
> > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431;
> > Kushwaha Prabhakar-B32579
> > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > secure boot target for P3041
> > 
> > On Tue, 2015-03-10 at 12:52 -0500, Bansal Aneesh-B39320 wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, March 10, 2015 10:34 PM
> > > > To: Bansal Aneesh-B39320
> > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431;
> > > > Kushwaha Prabhakar-B32579
> > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > > > secure boot target for P3041
> > > >
> > > > On Tue, 2015-03-10 at 03:50 -0500, Bansal Aneesh-B39320 wrote:
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Thursday, March 05, 2015 10:38 PM
> > > > > > To: Bansal Aneesh-B39320
> > > > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT-
> > > > > > NAND secure boot target for P3041
> > > > > >
> > > > > > On Thu, 2015-03-05 at 01:26 -0600, Bansal Aneesh-B39320 wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Thursday, March 05, 2015 2:41 AM
> > > > > > > > To: Bansal Aneesh-B39320
> > > > > > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta
> > > > > > > > Ruchika-R66431
> > > > > > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT-
> > > > > > > > NAND secure boot target for P3041
> > > > > > > >
> > > > > > > > Where does the 3.5G limitation come from?  Even if the
> > > > > > > > physical address needs to be elsewhere due to bootrom
> > > > > > > > constraints, we should be able to map it wherever we want in
> > > > > > > > the TLB once U-Boot takes
> > > > > > control.
> > > > > > > >
> > > > > > > The 3.5G limitation comes from BootROM in case of secure Boot.
> > > > > > > Initially U-Boot has to run from CPC configured as SRAM with
> > > > > > > address Within 3.5G. Once U-boot has relocated to DDR, we have
> > > > > > > removed the Corresponding TLB entry.
> > > > > >
> > > > > > Again, you could relocate the virtual address of L3 much earlier.
> > > > > >
> > > > > > -Scott
> > > > > >
> > > > > Are you suggesting the following:
> > > > > 1.  PBI Commands to configure CPC as SRAM with address 0xBFF0_.
> > > > > 2.  Compile U-boot with TEXT BASE as 0xFFF4.
> > > > > 3.  Copy the U-boot from NAND via PBI commands to CPC (SRAM) on
> > > > > address 0xBFF4_ 4.  The BootROM will validate the U-boot and
> > > > > transfer
> > > > the control to 0xBFFF_FFFC.
> > > > > 5.  When U-boot is executing, then in the last 4K code, when
> > > > > shifting from
> > > > AS=0 to AS=1,
> > > > >   we change the address of SRAM from 0xBFF0_ to 0xFFF0_.
> > > > > (Similar to what is done for NOR Boot)
> > > >
> > > > Something like that, except in step 5 it would only be changing the
> > > > virtual address, not the physical address (unless you can do a
> > > > similar trick as NOR does, to have the L3 cache repeat and cover both
> > addresses at once).
> > > >
> > > > -Scott
> > > >
> > > The problems that I see here are:
> > > 1.  Can SRAM address be changed without disabling and re-configuring CPC
> > as SRAM ?
> > 
> > Again, I'm only talking about changing the virtual address.
> > 
> If we just change the virtual address to 0xFFF0_, how will it work?
> The SRAM address configured in CPC controller is 0xBFF0_.
> So, won't the CPC controller reject fetches with address 0xFFFx_.

It's a virtual address.  The CPC will never see it.

> > Why is there a race condition?  You can have two virtual addresses pointing 
> > at
> > the same physical address.
> >
> We can have two virtual addresses pointing to same physical address but we 
> can't have
> two addresses for SRAM in CPC controller.

And you don't need to.

-Scott


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

Re: [U-Boot] [PATCH 1/1] beagle_x15: increase phy autoneg timeout

[Tom Rini]

On Tue, Mar 10, 2015 at 04:00:09PM +0530, Sekhar Nori wrote:

> When Beagle X15 is connected to Gigabit switch, it takes
> more time to finish auto-negotiation than on a 10/100 switch.
> 
> The default 4 second limit times-out more often than not. This is
> observed when testing with a D-Link DGS-1008A desktop switch.
> 
> Increase the auto-negotiation time-out for Beagle-X15 to handle
> this case.
> 
> Signed-off-by: Sekhar Nori 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

[aneesh.ban...@freescale.com]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, March 10, 2015 11:29 PM
> To: Bansal Aneesh-B39320
> Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431;
> Kushwaha Prabhakar-B32579
> Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> secure boot target for P3041
> 
> On Tue, 2015-03-10 at 12:52 -0500, Bansal Aneesh-B39320 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, March 10, 2015 10:34 PM
> > > To: Bansal Aneesh-B39320
> > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431;
> > > Kushwaha Prabhakar-B32579
> > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > > secure boot target for P3041
> > >
> > > On Tue, 2015-03-10 at 03:50 -0500, Bansal Aneesh-B39320 wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, March 05, 2015 10:38 PM
> > > > > To: Bansal Aneesh-B39320
> > > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT-
> > > > > NAND secure boot target for P3041
> > > > >
> > > > > On Thu, 2015-03-05 at 01:26 -0600, Bansal Aneesh-B39320 wrote:
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Thursday, March 05, 2015 2:41 AM
> > > > > > > To: Bansal Aneesh-B39320
> > > > > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta
> > > > > > > Ruchika-R66431
> > > > > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT-
> > > > > > > NAND secure boot target for P3041
> > > > > > >
> > > > > > > Where does the 3.5G limitation come from?  Even if the
> > > > > > > physical address needs to be elsewhere due to bootrom
> > > > > > > constraints, we should be able to map it wherever we want in
> > > > > > > the TLB once U-Boot takes
> > > > > control.
> > > > > > >
> > > > > > The 3.5G limitation comes from BootROM in case of secure Boot.
> > > > > > Initially U-Boot has to run from CPC configured as SRAM with
> > > > > > address Within 3.5G. Once U-boot has relocated to DDR, we have
> > > > > > removed the Corresponding TLB entry.
> > > > >
> > > > > Again, you could relocate the virtual address of L3 much earlier.
> > > > >
> > > > > -Scott
> > > > >
> > > > Are you suggesting the following:
> > > > 1.  PBI Commands to configure CPC as SRAM with address 0xBFF0_.
> > > > 2.  Compile U-boot with TEXT BASE as 0xFFF4.
> > > > 3.  Copy the U-boot from NAND via PBI commands to CPC (SRAM) on
> > > > address 0xBFF4_ 4.  The BootROM will validate the U-boot and
> > > > transfer
> > > the control to 0xBFFF_FFFC.
> > > > 5.  When U-boot is executing, then in the last 4K code, when
> > > > shifting from
> > > AS=0 to AS=1,
> > > >   we change the address of SRAM from 0xBFF0_ to 0xFFF0_.
> > > > (Similar to what is done for NOR Boot)
> > >
> > > Something like that, except in step 5 it would only be changing the
> > > virtual address, not the physical address (unless you can do a
> > > similar trick as NOR does, to have the L3 cache repeat and cover both
> addresses at once).
> > >
> > > -Scott
> > >
> > The problems that I see here are:
> > 1.  Can SRAM address be changed without disabling and re-configuring CPC
> as SRAM ?
> 
> Again, I'm only talking about changing the virtual address.
> 
If we just change the virtual address to 0xFFF0_, how will it work?
The SRAM address configured in CPC controller is 0xBFF0_.
So, won't the CPC controller reject fetches with address 0xFFFx_.

> > 2.  Assuming that above is possible,
> >
> > We are executing from CPC configured as SRAM with address as
> > 0xBFF0_. (Because of 3.5 G Limitation) We create a LAW for
> > 0xFFF0_ to map to CPC and change the address of SRAM in CPC
> > controller from BFF0_ to 0xFFF0_. (If it is possible... need to 
> > check
> this) But now the Code which was executing is executing from 0xBFFx_.
> So the CPC controller will reject this since configured address for SRAM is
> different.
> > NOR can have two addresses as IFC controller ignores the upper bit but this
> is not possible with CPC.
> 
> ...and this is why.
> 
> > To avoid this, even if we create a TLB Entry to map the virtual address
> 0xBFFx_ to 0xFFFx_, then we have a race condition. Which step to
> do first?
> 
> Why is there a race condition?  You can have two virtual addresses pointing at
> the same physical address.
>
We can have two virtual addresses pointing to same physical address but we 
can't have
two addresses for SRAM in CPC controller. CPC controller will accept fetches 
with only one address
0xBFFx_ or 0xFFFx_.
This is not a problem with NOR because IFC controller neglects the upper bits 
in address and hence
having  two virtual address was not an issue.
 
The code is currently executing from PC 0xBFFx_ and CPC is configured with 
SRAM address 0xBFFx_.
If SRAM addr

Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

[Scott Wood]

On Tue, 2015-03-10 at 12:52 -0500, Bansal Aneesh-B39320 wrote:
> 
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, March 10, 2015 10:34 PM
> > To: Bansal Aneesh-B39320
> > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431;
> > Kushwaha Prabhakar-B32579
> > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > secure boot target for P3041
> > 
> > On Tue, 2015-03-10 at 03:50 -0500, Bansal Aneesh-B39320 wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, March 05, 2015 10:38 PM
> > > > To: Bansal Aneesh-B39320
> > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > > > secure boot target for P3041
> > > >
> > > > On Thu, 2015-03-05 at 01:26 -0600, Bansal Aneesh-B39320 wrote:
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Thursday, March 05, 2015 2:41 AM
> > > > > > To: Bansal Aneesh-B39320
> > > > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT-
> > > > > > NAND secure boot target for P3041
> > > > > >
> > > > > > Where does the 3.5G limitation come from?  Even if the physical
> > > > > > address needs to be elsewhere due to bootrom constraints, we
> > > > > > should be able to map it wherever we want in the TLB once U-Boot
> > > > > > takes
> > > > control.
> > > > > >
> > > > > The 3.5G limitation comes from BootROM in case of secure Boot.
> > > > > Initially U-Boot has to run from CPC configured as SRAM with
> > > > > address Within 3.5G. Once U-boot has relocated to DDR, we have
> > > > > removed the Corresponding TLB entry.
> > > >
> > > > Again, you could relocate the virtual address of L3 much earlier.
> > > >
> > > > -Scott
> > > >
> > > Are you suggesting the following:
> > > 1.  PBI Commands to configure CPC as SRAM with address 0xBFF0_.
> > > 2.  Compile U-boot with TEXT BASE as 0xFFF4.
> > > 3.  Copy the U-boot from NAND via PBI commands to CPC (SRAM) on
> > > address 0xBFF4_ 4.  The BootROM will validate the U-boot and transfer
> > the control to 0xBFFF_FFFC.
> > > 5.  When U-boot is executing, then in the last 4K code, when shifting from
> > AS=0 to AS=1,
> > >   we change the address of SRAM from 0xBFF0_ to 0xFFF0_.
> > > (Similar to what is done for NOR Boot)
> > 
> > Something like that, except in step 5 it would only be changing the virtual
> > address, not the physical address (unless you can do a similar trick as NOR
> > does, to have the L3 cache repeat and cover both addresses at once).
> > 
> > -Scott
> > 
> The problems that I see here are:
> 1.  Can SRAM address be changed without disabling and re-configuring CPC as 
> SRAM ?

Again, I'm only talking about changing the virtual address.

> 2.  Assuming that above is possible,
> 
> We are executing from CPC configured as SRAM with address as 0xBFF0_. 
> (Because of 3.5 G Limitation)
> We create a LAW for 0xFFF0_ to map to CPC and 
> change the address of SRAM in CPC controller from BFF0_ to 0xFFF0_. 
> (If it is possible... need to check this)
> But now the Code which was executing is executing from 0xBFFx_. So the 
> CPC controller will reject this since configured address for SRAM is 
> different.
> NOR can have two addresses as IFC controller ignores the upper bit but this 
> is not possible with CPC.

...and this is why.

> To avoid this, even if we create a TLB Entry to map the virtual address 
> 0xBFFx_ to 0xFFFx_, then we have a race condition. Which step to do 
> first?

Why is there a race condition?  You can have two virtual addresses
pointing at the same physical address.

-Scott


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

Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

[aneesh.ban...@freescale.com]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, March 10, 2015 10:34 PM
> To: Bansal Aneesh-B39320
> Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431;
> Kushwaha Prabhakar-B32579
> Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> secure boot target for P3041
> 
> On Tue, 2015-03-10 at 03:50 -0500, Bansal Aneesh-B39320 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, March 05, 2015 10:38 PM
> > > To: Bansal Aneesh-B39320
> > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > > secure boot target for P3041
> > >
> > > On Thu, 2015-03-05 at 01:26 -0600, Bansal Aneesh-B39320 wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, March 05, 2015 2:41 AM
> > > > > To: Bansal Aneesh-B39320
> > > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT-
> > > > > NAND secure boot target for P3041
> > > > >
> > > > > Where does the 3.5G limitation come from?  Even if the physical
> > > > > address needs to be elsewhere due to bootrom constraints, we
> > > > > should be able to map it wherever we want in the TLB once U-Boot
> > > > > takes
> > > control.
> > > > >
> > > > The 3.5G limitation comes from BootROM in case of secure Boot.
> > > > Initially U-Boot has to run from CPC configured as SRAM with
> > > > address Within 3.5G. Once U-boot has relocated to DDR, we have
> > > > removed the Corresponding TLB entry.
> > >
> > > Again, you could relocate the virtual address of L3 much earlier.
> > >
> > > -Scott
> > >
> > Are you suggesting the following:
> > 1.  PBI Commands to configure CPC as SRAM with address 0xBFF0_.
> > 2.  Compile U-boot with TEXT BASE as 0xFFF4.
> > 3.  Copy the U-boot from NAND via PBI commands to CPC (SRAM) on
> > address 0xBFF4_ 4.  The BootROM will validate the U-boot and transfer
> the control to 0xBFFF_FFFC.
> > 5.  When U-boot is executing, then in the last 4K code, when shifting from
> AS=0 to AS=1,
> >   we change the address of SRAM from 0xBFF0_ to 0xFFF0_.
> > (Similar to what is done for NOR Boot)
> 
> Something like that, except in step 5 it would only be changing the virtual
> address, not the physical address (unless you can do a similar trick as NOR
> does, to have the L3 cache repeat and cover both addresses at once).
> 
> -Scott
> 
The problems that I see here are:
1.  Can SRAM address be changed without disabling and re-configuring CPC as 
SRAM ?
2.  Assuming that above is possible,

We are executing from CPC configured as SRAM with address as 0xBFF0_. 
(Because of 3.5 G Limitation)
We create a LAW for 0xFFF0_ to map to CPC and 
change the address of SRAM in CPC controller from BFF0_ to 0xFFF0_. (If 
it is possible... need to check this)
But now the Code which was executing is executing from 0xBFFx_. So the CPC 
controller will reject this since configured address for SRAM is different.
NOR can have two addresses as IFC controller ignores the upper bit but this is 
not possible with CPC.

To avoid this, even if we create a TLB Entry to map the virtual address 
0xBFFx_ to 0xFFFx_, then we have a race condition. Which step to do 
first?
Creation of TLB entry or changing the address of SRAM in CPC controller.
Because the current execution PC is 0xBFFx_ (CPC as SRAM)

-Aneesh

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

Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

[Scott Wood]

On Tue, 2015-03-10 at 03:50 -0500, Bansal Aneesh-B39320 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Thursday, March 05, 2015 10:38 PM
> > To: Bansal Aneesh-B39320
> > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > secure boot target for P3041
> > 
> > On Thu, 2015-03-05 at 01:26 -0600, Bansal Aneesh-B39320 wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, March 05, 2015 2:41 AM
> > > > To: Bansal Aneesh-B39320
> > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > > > secure boot target for P3041
> > > >
> > > > Where does the 3.5G limitation come from?  Even if the physical
> > > > address needs to be elsewhere due to bootrom constraints, we should
> > > > be able to map it wherever we want in the TLB once U-Boot takes
> > control.
> > > >
> > > The 3.5G limitation comes from BootROM in case of secure Boot.
> > > Initially U-Boot has to run from CPC configured as SRAM with address
> > > Within 3.5G. Once U-boot has relocated to DDR, we have removed the
> > > Corresponding TLB entry.
> > 
> > Again, you could relocate the virtual address of L3 much earlier.
> > 
> > -Scott
> > 
> Are you suggesting the following:
> 1.  PBI Commands to configure CPC as SRAM with address 0xBFF0_.
> 2.  Compile U-boot with TEXT BASE as 0xFFF4.
> 3.  Copy the U-boot from NAND via PBI commands to CPC (SRAM) on address 
> 0xBFF4_
> 4.  The BootROM will validate the U-boot and transfer the control to 
> 0xBFFF_FFFC.
> 5.  When U-boot is executing, then in the last 4K code, when shifting from 
> AS=0 to AS=1, 
>   we change the address of SRAM from 0xBFF0_ to 0xFFF0_. (Similar 
> to what is done for NOR Boot)

Something like that, except in step 5 it would only be changing the
virtual address, not the physical address (unless you can do a similar
trick as NOR does, to have the L3 cache repeat and cover both addresses
at once).

-Scott


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

Re: [U-Boot] [PATCH] Add bootscript support to esbc_validate.

[York Sun]

On 03/10/2015 09:25 AM, Gupta Ruchika-R66431 wrote:
> Hi York,
> 
>> -Original Message-
>> From: Sun York-R58495
>> Sent: Tuesday, March 10, 2015 9:45 PM
>> To: Rana Gaurav-B46163; u-boot@lists.denx.de
>> Cc: Wood Scott-B07421; Gupta Ruchika-R66431; Bansal Aneesh-B39320
>> Subject: Re: [PATCH] Add bootscript support to esbc_validate.
>>
>>
>>
>> On 03/10/2015 01:38 AM, Gaurav Rana wrote:
>>> 1. Default environment will be used for secure boot flow  which can't
>>> be edited or saved.
>>> 2. Command for secure boot is predefined in the default  environment
>>> which will run on autoboot (and autoboot is  the only option allowed
>>> in case of secure boot) and it  looks like this:
>>>  #define CONFIG_SECBOOT \
>>>  "setenv bs_hdraddr 0xe8e0;" \
>>>  "esbc_validate $bs_hdraddr;"\
>>>  "source $img_addr;" \
>>>  "esbc_halt;"
>>>  #endif
>>> 3. Boot Script can contain esbc_validate commands and bootm command.
>>>  Uboot source command used in default secure boot command will  run
>>> the bootscript.
>>> 4. Command esbc_halt added to ensure either bootm executes  after
>>> validation of images or core should just spin.
>>>
>> What's the purpose of "esbc_halt"? Once it enters the spin, how to get it
>> out?
> The purpose of bootscript is to validate the next level images and then pass 
> control to it, so bootscript must contain a bootm command. We don't expect 
> control to return back to u-boot. Hence a command esbc_halt is introduced 
> which would make the core spin and not provide uboot prompt in case 
> bootscript doesn't pass control to next level image. 
> For secure chain of trust, only validated bootscript should be allowed to 
> execute and be responsible for passing control to next level image.
> 

Ruchika,

Do you expect secure boot to run automatically once u-boot reaches the prompt
and the "source $img_addr" to actually boot the OS? You put "esbc_halt" as a
fall-back to catch failure above? It doesn't sounds very secure to me.

I am hoping other reviewers can chime in and give comments.

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

Re: [U-Boot] [PATCH] Add bootscript support to esbc_validate.

[Ruchika Gupta]

Hi York,

> -Original Message-
> From: Sun York-R58495
> Sent: Tuesday, March 10, 2015 9:45 PM
> To: Rana Gaurav-B46163; u-boot@lists.denx.de
> Cc: Wood Scott-B07421; Gupta Ruchika-R66431; Bansal Aneesh-B39320
> Subject: Re: [PATCH] Add bootscript support to esbc_validate.
> 
> 
> 
> On 03/10/2015 01:38 AM, Gaurav Rana wrote:
> > 1. Default environment will be used for secure boot flow  which can't
> > be edited or saved.
> > 2. Command for secure boot is predefined in the default  environment
> > which will run on autoboot (and autoboot is  the only option allowed
> > in case of secure boot) and it  looks like this:
> >  #define CONFIG_SECBOOT \
> >  "setenv bs_hdraddr 0xe8e0;" \
> >  "esbc_validate $bs_hdraddr;"\
> >  "source $img_addr;" \
> >  "esbc_halt;"
> >  #endif
> > 3. Boot Script can contain esbc_validate commands and bootm command.
> >  Uboot source command used in default secure boot command will  run
> > the bootscript.
> > 4. Command esbc_halt added to ensure either bootm executes  after
> > validation of images or core should just spin.
> >
> What's the purpose of "esbc_halt"? Once it enters the spin, how to get it
> out?
The purpose of bootscript is to validate the next level images and then pass 
control to it, so bootscript must contain a bootm command. We don't expect 
control to return back to u-boot. Hence a command esbc_halt is introduced which 
would make the core spin and not provide uboot prompt in case bootscript 
doesn't pass control to next level image. 
For secure chain of trust, only validated bootscript should be allowed to 
execute and be responsible for passing control to next level image.

Ruchika
> 
> York

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

Re: [U-Boot] [PATCH] Add bootscript support to esbc_validate.

[York Sun]

On 03/10/2015 01:38 AM, Gaurav Rana wrote:
> 1. Default environment will be used for secure boot flow
>  which can't be edited or saved.
> 2. Command for secure boot is predefined in the default
>  environment which will run on autoboot (and autoboot is
>  the only option allowed in case of secure boot) and it
>  looks like this:
>  #define CONFIG_SECBOOT \
>  "setenv bs_hdraddr 0xe8e0;" \
>  "esbc_validate $bs_hdraddr;"\
>  "source $img_addr;" \
>  "esbc_halt;"
>  #endif
> 3. Boot Script can contain esbc_validate commands and bootm command.
>  Uboot source command used in default secure boot command will
>  run the bootscript.
> 4. Command esbc_halt added to ensure either bootm executes
>  after validation of images or core should just spin.
>
What's the purpose of "esbc_halt"? Once it enters the spin, how to get it out?

York

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

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

[Tom Rini]

On Tue, Mar 10, 2015 at 04:00:54PM +0100, Hans de Goede wrote:

> 

No worries, mutt still hightlights the old one :)

> Hi Tom,
> 
> We've build-up a small collection of fixes for sunxi.
> Please pull u-boot-sunxi/master into master, highlights:
> 
> 1) 2 bug fixes
> 2) 1 regression fix
> 3) Add support for a couple of new boards
> 
> The following changes since commit 44c8fd3abaded5bf18a48947c6d1286927cbdf2b:
> 
>   common: cmd_elf: Add support to disable start of application (2015-03-09 
> 11:13:29 -0400)
> 
> are available in the git repository at:
> 
>   http://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to 1fc42018a0fe833a4332f8f32d6aeb675f3dcd1d:
> 
>   sunxi: video: Fix VIDEO_LCD_PANEL_I2C being enabled by default (2015-03-10 
> 15:20:25 +0100)
> 

Tested on my A20 OLinuXino Lime2 and applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot PATCH 1/3] gpio: pcf8575: Add pcf8575 driver to control gpio lines

[Tom Rini]

On Tue, Mar 10, 2015 at 08:41:21PM +0530, Vignesh R wrote:

> TI's pcf8575 is a 16-bit I2C based GPIO expander.The device features a
> 16-bit quasi-bidirectional I/O ports. Each quasi-bidirectional I/O can
> be used as an input or output without the use of a data-direction
> control signal. The I/Os should be high before being used as inputs.
> 
> This driver is based on pcf857x driver available in Linux 4.0 kernel.
> It supports basic reading and writing of gpio pins.

For attribution of stuff ported from the kernel please see
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign

[snip]
> diff --git a/drivers/gpio/pcf8575.c b/drivers/gpio/pcf8575.c
> new file mode 100644
> index ..1ee92a29760a
> --- /dev/null
> +++ b/drivers/gpio/pcf8575.c
> @@ -0,0 +1,248 @@
> +/*
> + * PCF8575 I2C GPIO EXPANDER DRIVER
> + *
> + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */

Please use SPDX tags for new files, thanks.

And right up front, this driver isn't using device model, please re-work
and update to use that framework, thanks!

> +/* NOTE:  these chips have strange "quasi-bidirectional" I/O pins.
/*
 * NOTE: ...

> +cmd_tbl_t cmd_pcf8575[] = {
> + U_BOOT_CMD_MKENT(device, 3, 0, (void *)PCF8575_CMD_DEVICE, "", ""),
> + U_BOOT_CMD_MKENT(output, 4, 0, (void *)PCF8575_CMD_OUTPUT, "", ""),
> + U_BOOT_CMD_MKENT(input, 3, 0, (void *)PCF8575_CMD_INPUT, "", ""),
> + U_BOOT_CMD_MKENT(info, 2, 0, (void *)PCF8575_CMD_INFO, "", ""),
> +};

Why isn't that just done with the normal gpio command?

-- 
Tom


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

Re: [U-Boot] [U-Boot PATCH 2/3] ARM: dra7xx_evm: Enable pcf driver

[Tom Rini]

On Tue, Mar 10, 2015 at 08:41:22PM +0530, Vignesh R wrote:

> Enable pcf driver to control the pcf chip present
> at address 0x21 on i2c1.
> 
> Signed-off-by: Vignesh R 
> ---
>  include/configs/dra7xx_evm.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
> index dee2b11056e7..0714f920efe6 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -229,4 +229,8 @@
>  #endif
>  #endif  /* NOR support */
>  
> +/* pcf support */
> +#define CONFIG_PCF8575
> +#define CONFIG_SYS_I2C_PCF8575_CHIP { {0x21, 0xeaf7} }

As part of switching to DM this will also be done differently (via
device tree).

-- 
Tom


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

[U-Boot] [U-Boot PATCH 0/3] Add support for pcf8575

[Vignesh R]

Hi,

This adds driver for pcf8575 in uboot. The driver supports basic
read and write operations on pcf gpio pins.

The first patch adds the driver, second patch and third patch
switches cpsw to use slave0 on DRA72 EVM.

Tested pcf driver on DRA72 EVM by probing pcf lines and cpsw by 
runnning tftp.


Vignesh R (3):
  gpio: pcf8575: Add pcf8575 driver to control gpio lines
  ARM: dra7xx_evm: Enable pcf driver
  ARM: DRA7-EVM: switch cpsw to use slave0

 board/ti/dra7xx/evm.c|  13 ++-
 drivers/gpio/Makefile|   1 +
 drivers/gpio/pcf8575.c   | 248 +++
 include/configs/dra7xx_evm.h |   4 +
 include/pcf8575.h|  25 +
 5 files changed, 289 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpio/pcf8575.c
 create mode 100644 include/pcf8575.h

-- 
1.9.1

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

[U-Boot] [U-Boot PATCH 1/3] gpio: pcf8575: Add pcf8575 driver to control gpio lines

[Vignesh R]

TI's pcf8575 is a 16-bit I2C based GPIO expander.The device features a
16-bit quasi-bidirectional I/O ports. Each quasi-bidirectional I/O can
be used as an input or output without the use of a data-direction
control signal. The I/Os should be high before being used as inputs.

This driver is based on pcf857x driver available in Linux 4.0 kernel.
It supports basic reading and writing of gpio pins.

Signed-off-by: Vignesh R 
---
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/pcf8575.c | 248 +
 include/pcf8575.h  |  25 +
 3 files changed, 274 insertions(+)
 create mode 100644 drivers/gpio/pcf8575.c
 create mode 100644 include/pcf8575.h

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index aa11f15423a4..1e0e521b4d95 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -9,6 +9,7 @@ ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_DM_GPIO)  += gpio-uclass.o
 endif
 
+obj-$(CONFIG_PCF8575)  += pcf8575.o
 obj-$(CONFIG_AT91_GPIO)+= at91_gpio.o
 obj-$(CONFIG_INTEL_ICH6_GPIO)  += intel_ich6_gpio.o
 obj-$(CONFIG_KIRKWOOD_GPIO)+= kw_gpio.o
diff --git a/drivers/gpio/pcf8575.c b/drivers/gpio/pcf8575.c
new file mode 100644
index ..1ee92a29760a
--- /dev/null
+++ b/drivers/gpio/pcf8575.c
@@ -0,0 +1,248 @@
+/*
+ * PCF8575 I2C GPIO EXPANDER DRIVER
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Driver for TI pcf-8575 16 bit I2C gpio expander. Based on
+ * gpio-pcf857x Linux 4.0 kernel driver and pca953x driver in u-boot
+ */
+
+#include 
+#include 
+#include 
+
+enum {
+   PCF8575_CMD_INFO,
+   PCF8575_CMD_DEVICE,
+   PCF8575_CMD_OUTPUT,
+   PCF8575_CMD_INPUT,
+};
+
+struct pcf8575_chip {
+   uint8_t addr;
+/* current direction of the pcf lines */
+   unsigned int out;
+};
+
+
+/* NOTE:  these chips have strange "quasi-bidirectional" I/O pins.
+ * We can't actually know whether a pin is configured (a) as output
+ * and driving the signal low, or (b) as input and reporting a low
+ * value ... without knowing the last value written since the chip
+ * came out of reset (if any).  We can't read the latched output.
+ * In short, the only reliable solution for setting up pin direction
+ * is to do it explicitly.
+ *
+ * Using "out" avoids that trouble. It flags the status of the pins at
+ * boot.
+ *
+ * Each struct stores address of an instance of pcf
+ * and state(direction) of each gpio line for that instance.
+ */
+static struct pcf8575_chip pcf8575_chips[] =
+   CONFIG_SYS_I2C_PCF8575_CHIP;
+
+static struct pcf8575_chip *pcf8575_chip_get(uint8_t addr)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(pcf8575_chips); i++)
+   if (pcf8575_chips[i].addr == addr)
+   return &pcf8575_chips[i];
+
+   return 0;
+}
+
+
+/* Read/Write to 16-bit I/O expander */
+
+static int pcf8575_i2c_write(uint8_t addr, unsigned word)
+{
+   unsigned word_be = ((word & 0xff) << 8) |
+  ((word & 0xff00) >> 8);
+   uint8_t buf = 0;
+   int status;
+
+   status = i2c_write(addr, word_be, 2, &buf, 1);
+
+   return (status < 0) ? status : 0;
+}
+
+static int pcf8575_i2c_read(uint8_t addr)
+{
+   u8 buf[2];
+   int status;
+
+   status = i2c_read(addr, 0, 1, buf, 2);
+   if (status < 0)
+   return status;
+
+   return (buf[1] << 8) | buf[0];
+}
+
+int pcf8575_input(uint8_t addr, unsigned offset)
+{
+   struct pcf8575_chip *chip = pcf8575_chip_get(addr);
+   int status;
+
+   chip->out |= (1 << offset);
+   status = pcf8575_i2c_write(addr, chip->out);
+
+   return status;
+}
+
+int pcf8575_get_val(uint8_t addr, unsigned offset)
+{
+   int value;
+
+   value = pcf8575_i2c_read(addr);
+   return (value < 0) ? 0 : (value & (1 << offset));
+}
+
+int pcf8575_output(uint8_t addr, unsigned offset, int value)
+{
+   struct pcf8575_chip *chip = pcf8575_chip_get(addr);
+   unsignedbit = 1 << offset;
+   int status;
+
+   if (value)
+   chip->out |= bit;
+   else
+   chip->out &= ~bit;
+   status = pcf8575_i2c_write(addr, chip->out);
+
+   return status;
+}
+
+/*
+ * Display pcf8575 information
+ */
+int pcf8575_info(uint8_t addr)
+{
+   int i;
+   uint data;
+   struct pcf8575_chip *chip = pcf8575_chip_get(addr);
+   int nr_gpio = 16;
+   int msb = nr_gpio - 1;
+
+   printf("pcf8575@ 0x%x

[U-Boot] [U-Boot PATCH 2/3] ARM: dra7xx_evm: Enable pcf driver

[Vignesh R]

Enable pcf driver to control the pcf chip present
at address 0x21 on i2c1.

Signed-off-by: Vignesh R 
---
 include/configs/dra7xx_evm.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index dee2b11056e7..0714f920efe6 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -229,4 +229,8 @@
 #endif
 #endif  /* NOR support */
 
+/* pcf support */
+#define CONFIG_PCF8575
+#define CONFIG_SYS_I2C_PCF8575_CHIP { {0x21, 0xeaf7} }
+
 #endif /* __CONFIG_DRA7XX_EVM_H */
-- 
1.9.1

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

[U-Boot] [U-Boot PATCH 3/3] ARM: DRA7-EVM: switch cpsw to use slave0

[Vignesh R]

On DRA72 EVM cpsw slave1 is muxed with VIN, therefore switch cpsw to use
slave0 using pcf driver.
DRA72 has only one cpsw phy(phy#3). Hence, set phy_id to 3 for slave0,
in case of DRA72 EVM.

Signed-off-by: Vignesh R 
---
 board/ti/dra7xx/evm.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 65222419ebbd..cc391cb0a065 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux_data.h"
 
@@ -31,6 +32,10 @@ DECLARE_GLOBAL_DATA_PTR;
 /* GPIO 7_11 */
 #define GPIO_DDR_VTT_EN 203
 
+/* pcf chip address enet_mux_s0 */
+#define PCF_ENET_MUX_ADDR  0x21
+#define PCF_SEL_ENET_MUX_S04
+
 const struct omap_sysinfo sysinfo = {
"Board: DRA7xx\n"
 };
@@ -254,8 +259,12 @@ int board_eth_init(bd_t *bis)
ctrl_val |= 0x22;
writel(ctrl_val, (*ctrl)->control_core_control_io1);
 
-   if (*omap_si_rev == DRA722_ES1_0)
-   cpsw_data.active_slave = 1;
+   if (*omap_si_rev == DRA722_ES1_0) {
+   cpsw_data.active_slave = 0;
+   cpsw_data.slave_data[0].phy_addr = 3;
+   pcf8575_output(PCF_ENET_MUX_ADDR, PCF_SEL_ENET_MUX_S0,
+  PCF8575_OUT_LOW);
+   }
 
ret = cpsw_register(&cpsw_data);
if (ret < 0)
-- 
1.9.1

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

Re: [U-Boot] "Writing to MMC(%d)... failed"

[Przemyslaw Marczak]

Hi,

On 03/10/2015 02:14 PM, Nathan wrote:

Sure, I understand from seeing all of the patches you submit. I
thought I'd at least ask in case it was something easy.
I'll continue to look into it. Thanks for submitting those links.

>


I didn't try any other sdcard since the card does work fine with
Hardkernel's old pre-built binaries.


We are often using the SD cards for a number of Odroid boards, in our 
office, with no issues.


If you have other card, then I suggest to test it, the first one, could 
be tired :)




On Tue, Mar 10, 2015 at 8:07 AM, Przemyslaw Marczak
 wrote:

Hello Nathan,
Now, I don't have too much time for this, but the only one you need is the
documentation and a time to analyze the responds for commands.

Please check this site:
https://www.sdcard.org/downloads/pls/simplified_specs/index.html
you can also check some example spec from Jedec:
http://www.jedec.org/standards-documents/results/jesd84-a441

You will solve this problem with this.

By the way, did you tried another SD-Card?

Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com


Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Hans de Goede]

Hi Tom,

We've build-up a small collection of fixes for sunxi.
Please pull u-boot-sunxi/master into master, highlights:

1) 2 bug fixes
2) 1 regression fix
3) Add support for a couple of new boards

The following changes since commit 44c8fd3abaded5bf18a48947c6d1286927cbdf2b:

  common: cmd_elf: Add support to disable start of application (2015-03-09 
11:13:29 -0400)

are available in the git repository at:

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

for you to fetch changes up to 1fc42018a0fe833a4332f8f32d6aeb675f3dcd1d:

  sunxi: video: Fix VIDEO_LCD_PANEL_I2C being enabled by default (2015-03-10 
15:20:25 +0100)


Adam Sampson (1):
  sunxi: Make CONFIG_DRAM_TPR3 apply to sun[57]i

Aleksei Mamlin (1):
  sunxi: Add Wexler TAB7200 support

Chen-Yu Tsai (3):
  sunxi: axp221: Add VBUS detection support
  sunxi: musb: Support checking VBUS using AXP221 PMIC
  sunxi: Ippo_q8h defconfigs: Enable otg vbus detection using AXP223 PMIC

Gábor Nyers (1):
  sunxi: Add support for the Jesurun Q5 board

Hans de Goede (4):
  sun7i: Add support for the Wits Pro A20 DKT board
  sun7i: Add support for the Orange Pi board
  sun7i: Add support for the Orange Pi Mini board
  sunxi: video: Fix VIDEO_LCD_PANEL_I2C being enabled by default

Jens Lucius (1):
  sunxi: Add support for the Forfun Q88DB tablet

Marcus Cooper (2):
  sun7i: Add support for the MK808C board
  sun6i: Add support for the Mele I7 board

 board/sunxi/Kconfig|  2 +-
 board/sunxi/MAINTAINERS| 24 ++
 board/sunxi/dram_sun5i_auto.c  |  2 +-
 configs/Ippo_q8h_v1_2_defconfig|  1 +
 configs/Ippo_q8h_v5_defconfig  |  1 +
 configs/MK808C_defconfig   | 13 ++
 configs/Mele_I7_defconfig  | 26 +++
 configs/Orangepi_defconfig | 13 ++
 configs/Orangepi_mini_defconfig| 15 +++
 configs/Wexler_TAB7200_defconfig   | 13 ++
 configs/Wits_Pro_A20_DKT_defconfig | 15 +++
 configs/forfun_q88db_defconfig | 17 +
 configs/jesurun_q5_defconfig   | 20 +++
 drivers/power/axp221.c | 16 
 drivers/usb/musb-new/sunxi.c   | 52 --
 include/axp221.h   |  7 +
 include/configs/sunxi-common.h |  7 +++--
 17 files changed, 226 insertions(+), 18 deletions(-)
 create mode 100644 configs/MK808C_defconfig
 create mode 100644 configs/Mele_I7_defconfig
 create mode 100644 configs/Orangepi_defconfig
 create mode 100644 configs/Orangepi_mini_defconfig
 create mode 100644 configs/Wexler_TAB7200_defconfig
 create mode 100644 configs/Wits_Pro_A20_DKT_defconfig
 create mode 100644 configs/forfun_q88db_defconfig
 create mode 100644 configs/jesurun_q5_defconfig

Regards,

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

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

[Hans de Goede]

Hi Tom,

We've build-up a small collection of fixes for sunxi.
Please pull u-boot-sunxi/master into master, highlights:

1) 2 bug fixes
2) 1 regression fix
3) Add support for a couple of new boards

The following changes since commit 44c8fd3abaded5bf18a48947c6d1286927cbdf2b:

  common: cmd_elf: Add support to disable start of application (2015-03-09 
11:13:29 -0400)

are available in the git repository at:

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

for you to fetch changes up to 1fc42018a0fe833a4332f8f32d6aeb675f3dcd1d:

  sunxi: video: Fix VIDEO_LCD_PANEL_I2C being enabled by default (2015-03-10 
15:20:25 +0100)


Adam Sampson (1):
  sunxi: Make CONFIG_DRAM_TPR3 apply to sun[57]i

Aleksei Mamlin (1):
  sunxi: Add Wexler TAB7200 support

Chen-Yu Tsai (3):
  sunxi: axp221: Add VBUS detection support
  sunxi: musb: Support checking VBUS using AXP221 PMIC
  sunxi: Ippo_q8h defconfigs: Enable otg vbus detection using AXP223 PMIC

Gábor Nyers (1):
  sunxi: Add support for the Jesurun Q5 board

Hans de Goede (4):
  sun7i: Add support for the Wits Pro A20 DKT board
  sun7i: Add support for the Orange Pi board
  sun7i: Add support for the Orange Pi Mini board
  sunxi: video: Fix VIDEO_LCD_PANEL_I2C being enabled by default

Jens Lucius (1):
  sunxi: Add support for the Forfun Q88DB tablet

Marcus Cooper (2):
  sun7i: Add support for the MK808C board
  sun6i: Add support for the Mele I7 board

 board/sunxi/Kconfig|  2 +-
 board/sunxi/MAINTAINERS| 24 ++
 board/sunxi/dram_sun5i_auto.c  |  2 +-
 configs/Ippo_q8h_v1_2_defconfig|  1 +
 configs/Ippo_q8h_v5_defconfig  |  1 +
 configs/MK808C_defconfig   | 13 ++
 configs/Mele_I7_defconfig  | 26 +++
 configs/Orangepi_defconfig | 13 ++
 configs/Orangepi_mini_defconfig| 15 +++
 configs/Wexler_TAB7200_defconfig   | 13 ++
 configs/Wits_Pro_A20_DKT_defconfig | 15 +++
 configs/forfun_q88db_defconfig | 17 +
 configs/jesurun_q5_defconfig   | 20 +++
 drivers/power/axp221.c | 16 
 drivers/usb/musb-new/sunxi.c   | 52 --
 include/axp221.h   |  7 +
 include/configs/sunxi-common.h |  7 +++--
 17 files changed, 226 insertions(+), 18 deletions(-)
 create mode 100644 configs/MK808C_defconfig
 create mode 100644 configs/Mele_I7_defconfig
 create mode 100644 configs/Orangepi_defconfig
 create mode 100644 configs/Orangepi_mini_defconfig
 create mode 100644 configs/Wexler_TAB7200_defconfig
 create mode 100644 configs/Wits_Pro_A20_DKT_defconfig
 create mode 100644 configs/forfun_q88db_defconfig
 create mode 100644 configs/jesurun_q5_defconfig

Regards,

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

Re: [U-Boot] [PATCH v2] mmc: fsl_esdhc: Add support for DDR mode

[Stefan Roese]

Hi Fabio,

On 10.03.2015 14:29, Fabio Estevam wrote:

This patch breaks eMMC on my TQMa6S (i.MX6SOLO). With it I get this error
upon U-Boot update:

MMC write: dev # 0, block # 2, count 711 ... mmc write failed

With this patch reverted it looks just fine:

MMC write: dev # 0, block # 2, count 711 ... 711 blocks written: OK

Any ideas what might cause this breakage? If this issue can't be solved soon
I suggest to revert this patch for this release.


Does this fix from Peng help?
http://lists.denx.de/pipermail/u-boot/2015-March/207632.html


No, it does unfortunately not.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] mmc: fsl_esdhc fix register offset

[Marek Vasut]

On Tuesday, March 10, 2015 at 08:35:46 AM, Peng Fan wrote:
> Commit f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1 introduces
> error register offset.
> 
> Change the "char reserved3[59]" to "char reserved3[56]".
> 
> Signed-off-by: Peng Fan 

This should probably be applied to 2015.04 .

What are the symptoms of this bug please ?

Thanks for spotting this!

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

Re: [U-Boot] [PATCHv2 17/20] arm: socfpga: spl: Add SDRAM check

[Marek Vasut]

On Monday, March 09, 2015 at 10:59:34 PM, Dinh Nguyen wrote:
> On 3/4/15 7:21 AM, Marek Vasut wrote:
> > On Monday, March 02, 2015 at 05:28:05 PM, dingu...@opensource.altera.com 
wrote:
> >> From: Dinh Nguyen 
> >> 
> >> Signed-off-by: Dinh Nguyen 
> >> ---
> >> 
> >>  arch/arm/cpu/armv7/socfpga/spl.c | 8 
> >>  1 file changed, 8 insertions(+)
> >> 
> >> diff --git a/arch/arm/cpu/armv7/socfpga/spl.c
> >> b/arch/arm/cpu/armv7/socfpga/spl.c index ea4a1fb..31ac789 100644
> >> --- a/arch/arm/cpu/armv7/socfpga/spl.c
> >> +++ b/arch/arm/cpu/armv7/socfpga/spl.c
> >> @@ -191,4 +191,12 @@ void spl_board_init(void)
> >> 
> >>sdram_size = sdram_calculate_size();
> >>debug("SDRAM: %ld MiB\n", (sdram_size >> 20));
> >> 
> >> +
> >> +  /* Sanity check ensure correct SDRAM size specified */
> >> +  puts("SDRAM: Ensuring specified SDRAM size is correct ...");
> >> +  if (get_ram_size(0, sdram_size) != sdram_size) {
> >> +  puts("failed\n");
> > 
> > Hi!
> > 
> > Maybe just report a failure, the positive state is not interesting
> > to the user and just polutes the console with messages which noone
> > cares about (unless this would be a debug build maybe).
> > 
> > What do you think please ?
> 
> Yeah, I think that's fine.

Cool, thanks!

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

Re: [U-Boot] [PATCH v2] mmc: fsl_esdhc: Add support for DDR mode

[Fabio Estevam]

Hi Stefan,

On Fri, Mar 6, 2015 at 10:43 AM, Stefan Roese  wrote:

> This patch breaks eMMC on my TQMa6S (i.MX6SOLO). With it I get this error
> upon U-Boot update:
>
> MMC write: dev # 0, block # 2, count 711 ... mmc write failed
>
> With this patch reverted it looks just fine:
>
> MMC write: dev # 0, block # 2, count 711 ... 711 blocks written: OK
>
> Any ideas what might cause this breakage? If this issue can't be solved soon
> I suggest to revert this patch for this release.

Does this fix from Peng help?
http://lists.denx.de/pipermail/u-boot/2015-March/207632.html

Regards,

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

Re: [U-Boot] "Writing to MMC(%d)... failed"

[Nathan]

Sure, I understand from seeing all of the patches you submit. I
thought I'd at least ask in case it was something easy.
I'll continue to look into it. Thanks for submitting those links.

I didn't try any other sdcard since the card does work fine with
Hardkernel's old pre-built binaries.

On Tue, Mar 10, 2015 at 8:07 AM, Przemyslaw Marczak
 wrote:
> Hello Nathan,
> Now, I don't have too much time for this, but the only one you need is the
> documentation and a time to analyze the responds for commands.
>
> Please check this site:
> https://www.sdcard.org/downloads/pls/simplified_specs/index.html
> you can also check some example spec from Jedec:
> http://www.jedec.org/standards-documents/results/jesd84-a441
>
> You will solve this problem with this.
>
> By the way, did you tried another SD-Card?
>
> Best regards,
> --
> Przemyslaw Marczak
> Samsung R&D Institute Poland
> Samsung Electronics
> p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] "Writing to MMC(%d)... failed"

[Przemyslaw Marczak]

Hello Nathan,

On 03/10/2015 12:30 PM, Nathan wrote:

I hope my last message didn't get lost during that outage last month.

In the mean time, I had to finagle the HardKernel code to work with
GCC 5.0 which ended up being only 1 line change which I may end up
encountering in mainline if I ever get far enough.
After transferring the "CONFIG_MMC_TRACE" to the HardKernel mmc.c, I
have a comparable output for the U2 with the "Samsung" mainline.

So the output comparison can be made more readable, I created a Google
Drive Sheet, lining up the output when there were repeats,
highlighting the differing output sections and changing the text color
for the different values:
https://docs.google.com/spreadsheets/d/1Gu10bG8wGJClorJjKoIMiAt4HR0nS22ugrL8-F5_Nbg/edit?usp=sharing



Now, I don't have too much time for this, but the only one you need is 
the documentation and a time to analyze the responds for commands.


Please check this site:
https://www.sdcard.org/downloads/pls/simplified_specs/index.html
you can also check some example spec from Jedec:
http://www.jedec.org/standards-documents/results/jesd84-a441

You will solve this problem with this.

By the way, did you tried another SD-Card?

Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/8] lpc32xx: mtd: nand: add MLC NAND controller

[Albert ARIBAUD]

Hi Scott,

Le Mon, 9 Mar 2015 18:51:03 -0500, Scott Wood 
a écrit :

> On Thu, 2015-03-05 at 07:46 +0100, Albert ARIBAUD (3ADEV) wrote:
> > diff --git a/drivers/mtd/nand/lpc32xx_nand_mlc.c 
> > b/drivers/mtd/nand/lpc32xx_nand_mlc.c
> > new file mode 100644
> > index 000..cb23972
> > --- /dev/null
> > +++ b/drivers/mtd/nand/lpc32xx_nand_mlc.c
> > @@ -0,0 +1,589 @@
> > +/*
> > + * LPC32xx MLC NAND flash controller driver
> > + *
> > + * (C) Copyright 2014 3ADEV 
> > + * Written by Albert ARIBAUD 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + *
> > + * NOTE:
> > + *
> > + * The MLC NAND flash controller provides hardware Reed-Solomon ECC
> > + * covering in- and out-of-band data together. Therefore, in- and out-
> > + * of-band data must be written together in order to have a valid ECC.
> > + *
> > + * Consequently, pages with meaningful in-band data are written with
> > + * blank (all-ones) out-of-band data and a valid ECC, and any later
> > + * out-of-band data write will void the ECC.
> > + *
> > + * Therefore, code which reads such late-written out-of-band data
> > + * should not rely on the ECC validity.
> > + */
> 
> When are you expecting later out-of-band writes?

I am not actually expecting OOB writes to happen, but they might do
regardless of my expectations (bad block marking, for instance?);
However, I do know the once an OOB write happens, OOB as well as
in-band reads will fail ECC, so I am just warning whoever it might
happen to.

> > +static struct lpc32xx_nand_mlc_registers *lpc32xx_nand_mlc_registers
> > +   = (struct lpc32xx_nand_mlc_registers *)MLC_NAND_BASE;
> 
> __iomem
> 
> > +  unsigned int ctrl)
> > +{
> > +   if (cmd == NAND_CMD_NONE)
> > +   return;
> > +
> > +   if (ctrl & NAND_CLE)
> > +   writeb(cmd & 0Xff, &lpc32xx_nand_mlc_registers->cmd);
> > +   else if (ctrl & NAND_ALE)
> > +   writeb(cmd & 0Xff, &lpc32xx_nand_mlc_registers->addr);
> > +   else
> > +   return;
> > +}
> 
> That last return is superfluous.

Will fix in v4.

> > +/**
> > + * ECC layout -- this is needed whatever ECC mode we are using.
> > + * In a 2KB (4*512B) page, R/S codes occupy 40 (4*10) bytes.
> > + * To make U-Boot's life easier, we pack 'useable' OOB at the
> > + * front and R/S ECC at the back.
> > + */
> > +
> > +static struct nand_ecclayout lpc32xx_largepage_ecclayout = {
> > +   .eccbytes = 40,
> > +   .eccpos = {24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
> > +  34, 35, 36, 37, 38, 39, 40, 41, 42, 43,
> > +  44, 45, 46, 47, 48, 48, 50, 51, 52, 53,
> > +  54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
> > +  },
> > +   .oobfree = {
> > +   {
> > +   .offset = 0,
> > +   .length = 24
> > +   },
> > +   }
> > +};
> 
> Is offset zero really free?  Where does the bad block marker go?

My bad -- I had not realized that the ECC layout struct had to factor
out the bad block marker location. Since this is a large block NAND,
that should be...

.offset = 2,
.length = 22

... Right? Will fix in v4.

> > +   for (i = 0; i < 4; i++) {
> > +   /* start data input */
> > +   oob[6*i] = ((0xfe << i) & 0xff);
> > +   oob[6*i+5] = ((0x7f >> i) & 0xff);
> > +   chip->cmdfunc(mtd, NAND_CMD_SEQIN, 0x200+0x210*i, page);
> > +   /* copy 6 non-ECC out-of-band bytes directly into NAND */
> > +   memcpy(lpc32xx_nand_mlc_registers->data, oob+6*i, 6);
> 
> Lots of magic numbers...

Will turn these into symbols in v4.

> > +   /* wait for NAND to return to ready state */
> > +   while (!(readl(&lpc32xx_nand_mlc_registers->isr)
> > +   & ISR_NAND_READY))
> > +   ;
> 
> Timeout?

Will fix in v4.
 
> > +   }
> > +   return 0;
> > +}
> > +
> > +/**
> > + * lpc32xx_waitfunc - wait until a command is done
> > + * @mtd: MTD device structure
> > + * @chip: NAND chip structure
> > + *
> > + * Wait for controller and FLASH to both be ready.
> > + */
> > +
> > +static int lpc32xx_waitfunc(struct mtd_info *mtd, struct nand_chip *chip)
> > +{
> > +   /* FIXME: put a time-out here */
> > +   int status;
> > +   /* wait until both controller and NAND are ready */
> > +   do {
> > +   status = readl(&lpc32xx_nand_mlc_registers->isr);
> > +   } while ((status & (ISR_CONTROLLER_READY || ISR_NAND_READY))
> > +!= (ISR_CONTROLLER_READY || ISR_NAND_READY));
> 
> Timeout?  Etc.

Will fix in v4.
 
> > +/*
> > + * Initialize the controller
> > + */
> > +
> > +int board_nand_init(struct nand_chip *nand)
> > +{
> 
> It'd be nice if new NAND drivers used CONFIG_SYS_NAND_SELF_INIT.

Will use in v4.

> > +
> > +   /* BBT options: read from last two pages, don't write */
> > +   nand->bbt_options |= NAND_BBT_USE_FLASH | NAND_BBT_LASTBLOCK
> > +   | NAND_BBT_SCANLASTPAGE | NAND_BBT_SCAN2NDPAGE
> > +   

Re: [U-Boot] MinnowBoard Max uboot

[Beaman, Thomas]

Hi Simon, 

Do you know what will be the timeframe of when someone may be able to look at 
this in more detail. I will be able to help test any updates if needed

Thanks,
Tom

-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: Monday, March 09, 2015 11:49 AM
To: Beaman, Thomas
Cc: u-boot@lists.denx.de; Bin Meng; gabriel huau
Subject: Re: MinnowBoard Max uboot

+Bin and Gabriel

Hi Tom,

On 9 March 2015 at 08:08, Beaman, Thomas  wrote:
>
>
> Hi Simon,
>
>
>
> I see you have put support for the MinnowBoard Max in the u-boot mainline.
> Thanks this is a very useful addition.  I have been able to follow 
> your readme and build a working bare metal uboot. Using the built 
> uboot I can load and bring up a Linux Kernel.
>
>
>
> What I noticed from the running kernel is that only one of the two 
> cores on the E3825 is running. In the power PC uboots I usually see a 
> section for the multiple cores in the .dts file. My questions is how 
> do I get both CPUs running on this board. Is it a uboot .dts file 
> setup that will enable this, or is something in the kernel start up that does 
> this.
>
>
>
> As a test I boot the same kernel using the EFI BIOS on the minnow 
> board and both CPUs are running.
>
>
>
> Any suggestions or comments you have would be welcomed.
>
>

My guess is that the LAPIC CPU start-up is missing. It isn't 100% clear what 
the FSP does and does not do, but perhaps it does not do that.

I did make something of a start on this with ivybridge but it isn't complete, 
and it seems to be needed here.

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

Re: [U-Boot] [PATCH 1/4] sunxi: video: Fix VIDEO_LCD_PANEL_I2C being enabled by default

[Ian Campbell]

On Tue, 2015-03-10 at 12:38 +0100, Hans de Goede wrote:
> > Or at least #define it to some obviously bogus value (e.g. ~0UL).
> 
> That is a good idea, I've changed it to -1 in my personal tree.

With that:

Acked-by: Ian Campbell 


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

Re: [U-Boot] [PATCH v2 04/12] dm: pmic: add implementation of driver model regulator uclass

[Robert Baldyga]

Hi,

On 03/03/2015 05:24 PM, Przemyslaw Marczak wrote:
> This is the implementation of driver model regulator uclass api.
> To use it, the CONFIG_DM_PMIC is required with driver implementation,
> since it provides pmic devices basic I/O API.
> 
> The regulator framework is based on a 'struct dm_regulator_ops'.
> It provides a common function calls, for it's basic features:
> - regulator_get_cnt()- number of outputs each type
> - regulator_get_value_desc() - describe output value limits
> - regulator_get_mode_desc()  - describe output operation modes
> - regulator_get/set_value()  - output value (uV)
> - regulator_get/set_state()  - output on/off state
> - regulator_get/set_mode()   - output operation mode
> 
> To get the regulator device:
> - regulator_get() - by name only
> - regulator_i2c_get() - by i2c bus address (of pmic parent)
> - regulator_spi_get() - by spi bus address (of pmic parent)
> 
> An optional and useful regulator framework features are two descriptors:
> - struct regulator_desc - describes the regulator name and output value limits
>   should be defined by device driver for each regulator output.
> 
> - struct regulator_mode_desc - (array) describes a number of operation modes
>   supported by each regulator output.
> 
> The regulator framework features are described in file:
> - include/power/regulator.h
> 
> Main files:
> - drivers/power/regulator-uclass.c - provides regulator common functions api
> - include/power/regulator.h - define all structures required by the regulator
> 
> Changes:
> - new uclass-id: UCLASS_PMIC_REGULATOR
> - new config: CONFIG_DM_REGULATOR
> 
> Signed-off-by: Przemyslaw Marczak 
> ---
> Changes V2:
> - new operations for regulator uclass:
> -- get/set output state - for output on/off setting
> --- add enum: REGULATOR_OFF, REGULATOR_ON
> 
> - regulator uclass code rework and cleanup:
> -- change name of:
> --- enum 'regulator_desc_type' to 'regulator_type'
> --- add type DVS
> --- struct 'regulator_desc' to 'regulator_value_desc'
> 
> -- regulator ops function calls:
> --- remove 'ldo/buck' from naming
> --- add new argument 'type' for define regulator type
> 
> -- regulator.h - update comments
> ---
>  drivers/power/Makefile   |   1 +
>  drivers/power/regulator-uclass.c | 227 
>  include/dm/uclass-id.h   |   1 +
>  include/power/regulator.h| 310 
> +++
>  4 files changed, 539 insertions(+)
>  create mode 100644 drivers/power/regulator-uclass.c
>  create mode 100644 include/power/regulator.h
> 
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 5c9a189..a6b7012 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -22,3 +22,4 @@ obj-$(CONFIG_POWER_FSL) += power_fsl.o
>  obj-$(CONFIG_POWER_I2C) += power_i2c.o
>  obj-$(CONFIG_POWER_SPI) += power_spi.o
>  obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
> +obj-$(CONFIG_DM_REGULATOR) += regulator-uclass.o
> diff --git a/drivers/power/regulator-uclass.c 
> b/drivers/power/regulator-uclass.c
> new file mode 100644
> index 000..6b5c678
> --- /dev/null
> +++ b/drivers/power/regulator-uclass.c
> @@ -0,0 +1,227 @@
> +/*
> + * Copyright (C) 2014-2015 Samsung Electronics
> + * Przemyslaw Marczak 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +int regulator_get_cnt(struct udevice *dev, int type, int *cnt)
> +{
> + const struct dm_regulator_ops *ops;
> +
> + ops = pmic_get_uclass_ops(dev, UCLASS_PMIC_REGULATOR);
> + if (!ops)
> + return -ENODEV;
> +
> + if (!ops->get_cnt)
> + return -EPERM;
> +
> + return ops->get_cnt(dev, type, cnt);
> +}
> +
> +int regulator_get_value_desc(struct udevice *dev, int type, int number,
> +  struct regulator_value_desc **desc)
> +{
> + const struct dm_regulator_ops *ops;
> +
> + ops = pmic_get_uclass_ops(dev, UCLASS_PMIC_REGULATOR);
> + if (!ops)
> + return -ENXIO;
> +
> + if (!ops->get_value_desc)
> + return -EPERM;
> +
> + return ops->get_value_desc(dev, type, number, desc);
> +}
> +
> +int regulator_get_mode_desc(struct udevice *dev, int type, int number,
> + int *mode_cnt, struct regulator_mode_desc **desc)
> +{
> + const struct dm_regulator_ops *ops;
> +
> + ops = pmic_get_uclass_ops(dev, UCLASS_PMIC_REGULATOR);
> + if (!ops)
> + return -ENXIO;
> +
> + if (!ops->get_mode_desc_array)
> + return -EPERM;
> +
> + return ops->get_mode_desc_array(dev, type, number, mode_cnt, desc);
> +}
> +
> +int regulator_get_value(struct udevice *dev, int type, int number, int 
> *value)
> +{
> + const struct dm_regulator_ops *ops;
> +
> + ops = pmic_get_uclass_ops(dev, UCLASS_PMIC_REGULATOR);
> + if (!o

Re: [U-Boot] [PATCH 0/3] sunxi: Ippo_q8h: Enable OTG VBUS detection using AXP223

[Chen-Yu Tsai]

Hi,

On Tue, Mar 10, 2015 at 7:08 PM, Hans de Goede  wrote:
> Hi,
>
> On 09-03-15 08:44, Chen-Yu Tsai wrote:
>>
>> Hi Hans,
>>
>> This series fixes otg support on the A23 q8h tablets. It adds support
>> for the AXP's (AXP221/223 for now) VBUS detection function.
>>
>> I've tested this with a USB wireless keyboard dongle, which works fine.
>> More importantly, I'm using this and your mainline kernel musb work plus
>> a few A23 dts patches to get musb working on my q8h tablet in host mode.
>> I have an ethernet dongle plugged in, which works reasonably well.
>
>
> Thanks for working on this, I've merged this into u-boot-sunxi/next
> and I plan to send a pull-req for this to get it into v2015.4-rc# soon,
> as this fixes a regression which I (deliberately) introduced.
>
> It would be cool if you do similar patches for the mainline kernel, for
> the mainline kernel I would really like to see the status bit exported
> as part of the gpio-chip which we still need to add to the axp2xx code for
> the axp2xx gpio pins, this way the existing kernel musb code can just use
> it.

Not sure this is going to fly with the maintainers. It is pretty much
a part of the power supply, which would have it's own driver.

Now I wanted to do the GPIOs, but then I went and did all the new
SoC stuff. Also the regular GPIOs are muxed with the GPIO regulators,
which is a bit nasty considering we might not have the driver core to
handle them. I haven't figured that part out yet. I suppose we could
just do kind of a hack where the pin is claimed by the regulator and
the regulator driver is free to change the mux.

I'll probably tackle this after AXP221 is merged and RSB is figured
out, and if no other things pop up.

> I also believe that Ian was right when he said that we should probably
> also make these bits special gpio-s in u-boot rather then using custom
> API-s for them. But this is something which we can fix later, for now
> this fixes the regression and as such is good enough.

I must have missed his comment. I do think a cleanup of the AXP code
is needed.

>> Note that U-Boot never calls musb_shutdown() to do proper cleanup, like
>> disabling VBUS, so the current state carries on into Linux.
>
>
> Hmm true, I guess that is not necessarily a problem, but something which
> we do need to keep in mind.

It's a bit like having regulators kept on for ethernet or simplefb, a
nice to have side-effect. :)


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

Re: [U-Boot] [PATCH 1/4] sunxi: video: Fix VIDEO_LCD_PANEL_I2C being enabled by default

[Hans de Goede]

Hi,

On 08-03-15 10:04, Ian Campbell wrote:

On Sat, 2015-03-07 at 15:04 +0100, Hans de Goede wrote:

Fix a type in board/sunxi/Kconfig which caused VIDEO_LCD_PANEL_I2C to be


"typo"


Heh, so I made a typo in the word typo, fixed :)


+#define CONFIG_VIDEO_LCD_I2C_BUS   1 /* NA, but necessary to compile */


Hrm, should the usage sites not be either ifdef'd or excluded at the
Makefile level when VIDEO_LCD_PANEL_I2C is disabled?

The only use is in
 if (IS_ENABLED(CONFIG_VIDEO_LCD_TL059WV5C0)) {
 unsigned int orig_i2c_bus = i2c_get_bus_num();
 i2c_set_bus_num(CONFIG_VIDEO_LCD_I2C_BUS);
 i2c_reg_write(0x5c, 0x04, 0x42); /* Turn on the LCD */
 i2c_set_bus_num(orig_i2c_bus);
 }

Is the issue that the IS_ENABLED statically false but the compiler still
wants the contents to be valid?


Right.


How about a helper set_video_i2c_bus or some such which can be a nop if
CONFIG_VIDEO_LCD_I2C_BUS is not defined, which would keep the ifdef out
of this code?


Not a fan of that, the whole purpose of using IS_ENABLED is to have easier
to read code, I do not believe that adding a wrapper helps there.


Or at least #define it to some obviously bogus value (e.g. ~0UL).


That is a good idea, I've changed it to -1 in my personal tree.

Regards,

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

Re: [U-Boot] "Writing to MMC(%d)... failed"

[Nathan]

I hope my last message didn't get lost during that outage last month.

In the mean time, I had to finagle the HardKernel code to work with
GCC 5.0 which ended up being only 1 line change which I may end up
encountering in mainline if I ever get far enough.
After transferring the "CONFIG_MMC_TRACE" to the HardKernel mmc.c, I
have a comparable output for the U2 with the "Samsung" mainline.

So the output comparison can be made more readable, I created a Google
Drive Sheet, lining up the output when there were repeats,
highlighting the differing output sections and changing the text color
for the different values:
https://docs.google.com/spreadsheets/d/1Gu10bG8wGJClorJjKoIMiAt4HR0nS22ugrL8-F5_Nbg/edit?usp=sharing
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add Wexler TAB7200 support

[Hans de Goede]

Hi,

On 04-03-15 08:44, Aleksei Mamlin wrote:

This patch add support for Wexler TAB7200 tablet.

The Wexler TAB7200 is a A20 based tablet with 7 inch display(800x480),
capacitive touchscreen(5 fingers), 1G RAM, 4G NAND, micro SD card slot,
mini HDMI port, 3.5mm audio plug, 1 USB OTG port and 1 USB 2.0 port.

Signed-off-by: Aleksei Mamlin 


Thanks, I've queued this up in u-boot-sunxi/next for merging upstream.

Regards,

Hans


---
  board/sunxi/MAINTAINERS  |  5 +
  configs/Wexler_TAB7200_defconfig | 13 +
  2 files changed, 18 insertions(+)
  create mode 100644 configs/Wexler_TAB7200_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 3e6ce88..53a9fea 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -130,3 +130,8 @@ TZX-Q8-713B7 BOARD
  M:Paul Kocialkowski 
  S:Maintained
  F:configs/TZX-Q8-713B7_defconfig
+
+WEXLER-TAB7200 BOARD
+M: Aleksei Mamlin 
+S: Maintained
+F: configs/Wexler_TAB7200_defconfig
diff --git a/configs/Wexler_TAB7200_defconfig b/configs/Wexler_TAB7200_defconfig
new file mode 100644
index 000..6c15dc8
--- /dev/null
+++ b/configs/Wexler_TAB7200_defconfig
@@ -0,0 +1,13 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,USB_EHCI"
+CONFIG_FDTFILE="sun7i-a20-wexler-tab7200.dtb"
+CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:33000,le:45,ri:210,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0"
+CONFIG_VIDEO_LCD_POWER="PH8"
+CONFIG_VIDEO_LCD_BL_EN="PH7"
+CONFIG_VIDEO_LCD_BL_PWM="PB2"
++S:CONFIG_ARM=y
++S:CONFIG_ARCH_SUNXI=y
++S:CONFIG_MACH_SUN7I=y
++S:CONFIG_DRAM_CLK=384
++S:CONFIG_DRAM_ZQ=127
++S:CONFIG_DRAM_EMR1=4


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

[U-Boot] [PATCH] x86: quark: MRC codes clean up

[Bin Meng]

This patch cleans up the quark MRC codes coding style by:
- Remove BIT0/1../31 defines from mrc_util.h
- Create names for the documented BITs and use them
- For undocumented single BITs, use (1 << n) directly
- For undocumented ORed BITs, use the hex number directly
- Remove redundancy parenthesis all over the codes
- Replace to use lower case hex numbers

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/quark/hte.c  |   74 +--
 arch/x86/cpu/quark/hte.h  |4 +-
 arch/x86/cpu/quark/mrc.c  |   12 +-
 arch/x86/cpu/quark/mrc_util.c |  326 ++-
 arch/x86/cpu/quark/mrc_util.h |   34 --
 arch/x86/cpu/quark/smc.c  | 1205 ++---
 arch/x86/cpu/quark/smc.h  |  349 +++-
 7 files changed, 955 insertions(+), 1049 deletions(-)

diff --git a/arch/x86/cpu/quark/hte.c b/arch/x86/cpu/quark/hte.c
index 372815d..db601e4 100644
--- a/arch/x86/cpu/quark/hte.c
+++ b/arch/x86/cpu/quark/hte.c
@@ -20,9 +20,9 @@
  */
 static void hte_enable_all_errors(void)
 {
-   msg_port_write(HTE, 0x000200A2, 0x);
-   msg_port_write(HTE, 0x000200A3, 0x00FF);
-   msg_port_write(HTE, 0x000200A4, 0x);
+   msg_port_write(HTE, 0x000200a2, 0x);
+   msg_port_write(HTE, 0x000200a3, 0x00ff);
+   msg_port_write(HTE, 0x000200a4, 0x);
 }
 
 /**
@@ -32,7 +32,7 @@ static void hte_enable_all_errors(void)
  */
 static u32 hte_check_errors(void)
 {
-   return msg_port_read(HTE, 0x000200A7);
+   return msg_port_read(HTE, 0x000200a7);
 }
 
 /**
@@ -44,11 +44,11 @@ static void hte_wait_for_complete(void)
 
ENTERFN();
 
-   do {} while ((msg_port_read(HTE, 0x00020012) & BIT30) != 0);
+   do {} while ((msg_port_read(HTE, 0x00020012) & (1 << 30)) != 0);
 
tmp = msg_port_read(HTE, 0x00020011);
-   tmp |= BIT9;
-   tmp &= ~(BIT12 | BIT13);
+   tmp |= (1 << 9);
+   tmp &= ~((1 << 12) | (1 << 13));
msg_port_write(HTE, 0x00020011, tmp);
 
LEAVEFN();
@@ -65,9 +65,9 @@ static void hte_clear_error_regs(void)
 * Clear all HTE errors and enable error checking
 * for burst and chunk.
 */
-   tmp = msg_port_read(HTE, 0x000200A1);
-   tmp |= BIT8;
-   msg_port_write(HTE, 0x000200A1, tmp);
+   tmp = msg_port_read(HTE, 0x000200a1);
+   tmp |= (1 << 8);
+   msg_port_write(HTE, 0x000200a1, tmp);
 }
 
 /**
@@ -91,25 +91,25 @@ static u16 hte_basic_data_cmp(struct mrc_params 
*mrc_params, u32 addr,
u32 offset;
 
if (first_run) {
-   msg_port_write(HTE, 0x00020020, 0x01B10021);
+   msg_port_write(HTE, 0x00020020, 0x01b10021);
msg_port_write(HTE, 0x00020021, 0x0600);
msg_port_write(HTE, 0x00020022, addr >> 6);
msg_port_write(HTE, 0x00020062, 0x00800015);
-   msg_port_write(HTE, 0x00020063, 0x);
-   msg_port_write(HTE, 0x00020064, 0x);
-   msg_port_write(HTE, 0x00020065, 0xF0F0F0F0);
+   msg_port_write(HTE, 0x00020063, 0x);
+   msg_port_write(HTE, 0x00020064, 0x);
+   msg_port_write(HTE, 0x00020065, 0xf0f0f0f0);
msg_port_write(HTE, 0x00020061, 0x00030008);
 
if (mode == WRITE_TRAIN)
-   pattern = 0xC33C;
+   pattern = 0xc33c;
else /* READ_TRAIN */
-   pattern = 0xAAAA;
+   pattern = 0xaaaa;
 
-   for (offset = 0x80; offset <= 0x8F; offset++)
+   for (offset = 0x80; offset <= 0x8f; offset++)
msg_port_write(HTE, offset, pattern);
}
 
-   msg_port_write(HTE, 0x000200A1, 0x1000);
+   msg_port_write(HTE, 0x000200a1, 0x1000);
msg_port_write(HTE, 0x00020011, 0x00011000);
msg_port_write(HTE, 0x00020011, 0x00011100);
 
@@ -119,7 +119,7 @@ static u16 hte_basic_data_cmp(struct mrc_params 
*mrc_params, u32 addr,
 * Return bits 15:8 of HTE_CH0_ERR_XSTAT to check for
 * any bytelane errors.
 */
-   return (hte_check_errors() >> 8) & 0xFF;
+   return (hte_check_errors() >> 8) & 0xff;
 }
 
 /**
@@ -153,7 +153,7 @@ static u16 hte_rw_data_cmp(struct mrc_params *mrc_params, 
u32 addr,
msg_port_write(HTE, 0x00020024, 0x0607);
msg_port_write(HTE, 0x00020022, addr >> 6);
msg_port_write(HTE, 0x00020025, addr >> 6);
-   msg_port_write(HTE, 0x00020062, 0x002A);
+   msg_port_write(HTE, 0x00020062, 0x002a);
msg_port_write(HTE, 0x00020063, seed_victim);
msg_port_write(HTE, 0x00020064, seed_aggressor);
msg_port_write(HTE, 0x00020065, seed_victim);
@@ -163,21 +163,21 @@ static u16 hte_rw_data_cmp(struct mrc_params *mrc_params, 
u32 addr,
 *
 * Start with bit0
   

Re: [U-Boot] [PATCH 0/3] sunxi: Ippo_q8h: Enable OTG VBUS detection using AXP223

[Hans de Goede]

Hi,

On 09-03-15 08:44, Chen-Yu Tsai wrote:

Hi Hans,

This series fixes otg support on the A23 q8h tablets. It adds support
for the AXP's (AXP221/223 for now) VBUS detection function.

I've tested this with a USB wireless keyboard dongle, which works fine.
More importantly, I'm using this and your mainline kernel musb work plus
a few A23 dts patches to get musb working on my q8h tablet in host mode.
I have an ethernet dongle plugged in, which works reasonably well.


Thanks for working on this, I've merged this into u-boot-sunxi/next
and I plan to send a pull-req for this to get it into v2015.4-rc# soon,
as this fixes a regression which I (deliberately) introduced.

It would be cool if you do similar patches for the mainline kernel, for
the mainline kernel I would really like to see the status bit exported
as part of the gpio-chip which we still need to add to the axp2xx code for
the axp2xx gpio pins, this way the existing kernel musb code can just use
it.

I also believe that Ian was right when he said that we should probably
also make these bits special gpio-s in u-boot rather then using custom
API-s for them. But this is something which we can fix later, for now
this fixes the regression and as such is good enough.


Note that U-Boot never calls musb_shutdown() to do proper cleanup, like
disabling VBUS, so the current state carries on into Linux.


Hmm true, I guess that is not necessarily a problem, but something which
we do need to keep in mind.

Regards,

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

Re: [U-Boot] [PATCH] odroid: defconfig: fix build break caused by missing dts

[Lukasz Majewski]

Hi Przemyslaw,

> The build break was caused by one of my previous commit:
> 'odroid: defconfig: disable memset at malloc init'
> 
> It removes the dts from odroid defconfig - rebase mistake.
> 
> Signed-off-by: Przemyslaw Marczak 
> Cc: Minkyu Kang 
> ---
>  configs/odroid_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
> index cfb29e0..d32b5b5 100644
> --- a/configs/odroid_defconfig
> +++ b/configs/odroid_defconfig
> @@ -2,6 +2,7 @@ CONFIG_ARM=y
>  CONFIG_ARCH_EXYNOS=y
>  CONFIG_TARGET_ODROID=y
>  CONFIG_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="exynos4412-odroid"
>  CONFIG_DM_I2C=y
>  CONFIG_DM_I2C_COMPAT=y
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set

Acked-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

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

[U-Boot] [PATCH 3/3] Kconfig: i2c: add entry for driver-model software i2c

[Przemyslaw Marczak]

Signed-off-by: Przemyslaw Marczak 
Cc: Masahiro Yamada 
Cc: Mike Frysinger 
Cc: Simon Glass 
Cc: Heiko Schocher 
---
 drivers/i2c/Kconfig | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 0a52ed9..dd7eb3c 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -13,6 +13,49 @@ config DM_I2C_COMPAT
  to convert all code for a board in a single commit. It should not
  be enabled for any board in an official release.
 
+config DM_I2C_SOFT
+   bool "Enable Driver Model for Software I2C Driver"
+   depends on DM_I2C
+   help
+ Enable the i2c bus driver emulation by using GPIO.
+ The bus configuration is given by the device-tree, like below.
+
+ /* First, define the alias number to have continuous bus numbering */
+ aliases {
+   [...]
+   i2c5 = "/i2c@1350";
+   i2c6 = "/soft-i2c@1";
+   [...]
+ }
+
+ /* And next define the basic bus attributes */
+ soft-i2c@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "soft-i2c";
+   clock-frequency = <5>;
+   /* Define the proper GPIO pins */
+   clock-pin = <&gpa0 0 GPIO_ACTIVE_HIGH>;
+   data-pin = <&gpa0 1 GPIO_ACTIVE_HIGH>;
+
+   /* Optionally, define some driver node (bus child) */
+   somedev@0x44 {
+   compatible = "somedev";
+   reg = <0x44>;
+   [...]
+   };
+ }
+
+ The device can be accessed by the i2c command:
+ # i2c dev 8   (bus number set by alias)
+ # i2c probe <0x44>(address is optionally)
+ # i2c md 0x44 0x0 (dump dev registers at address 0x0)
+ # Valid chip addresses: 0x44  (success!)
+ ...
+
+ Driving the bus lines is done by dm gpio calls in the preprocessor
+ macros. Each, can be redefined by the user.
+
 config SYS_I2C_UNIPHIER
bool "UniPhier I2C driver"
depends on ARCH_UNIPHIER && DM_I2C
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] dm: i2c soft: enable driver model for software i2c driver

[Przemyslaw Marczak]

This change adds driver model support to software emulated
i2c bus driver. To bind the driver, proper device-tree node
must be defined, with the following attributes:
- alias: to keep proper bus order
- compatible: 'soft-i2c'
- clock-frequency [Hz]
- clock-pin, data-pin: gpio phandles

/* Define the alias number to keep bus numbering order */
aliases {
[...]
i2c5 = "/i2c@1350";
i2c6 = "/soft-i2c@1";
[...]
};

/* Define the basic bus attributes */
soft-i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "soft-i2c";
clock-frequency = <5>;

/* Define the proper GPIO pins */
clock-pin = <&gpa0 0 GPIO_ACTIVE_HIGH>;
data-pin = <&gpa0 1 GPIO_ACTIVE_HIGH>;

/* Optionally, define some driver node (bus child) */
somedev@0x44 {
compatible = "somedev";
reg = <0x44>;
[...]
};
};

The device can be accessed by the i2c command:
 i2c dev 8   (bus number set by alias)
 i2c probe <0x44>(address is optionally)
 i2c md 0x44 0x0 (dump dev registers at address 0x0)
 Valid chip addresses: 0x44  (success!)
 ...

The previous driver functionality stays unchanged. Driving the bus lines
is done by dm gpio calls in the preprocessor macros. Each, can be redefined
by the user as previous.

Tested on Trats2 and Odroid U3.

Signed-off-by: Przemyslaw Marczak 
Cc: Masahiro Yamada 
Cc: Mike Frysinger 
Cc: Simon Glass 
Cc: Heiko Schocher 
---
 drivers/i2c/Makefile   |   1 +
 drivers/i2c/soft_i2c.c | 410 +++--
 2 files changed, 400 insertions(+), 11 deletions(-)

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 774bc94..7039b6d 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -6,6 +6,7 @@
 #
 obj-$(CONFIG_DM_I2C) += i2c-uclass.o
 obj-$(CONFIG_DM_I2C_COMPAT) += i2c-uclass-compat.o
+obj-$(CONFIG_DM_I2C_SOFT) += soft_i2c.o
 
 obj-$(CONFIG_SYS_I2C_ADI) += adi_i2c.o
 obj-$(CONFIG_I2C_MV) += mv_i2c.o
diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index db9b402..7afae0b 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -1,4 +1,7 @@
 /*
+ * (C) Copyright 2015, Samsung Electronics
+ * Przemyslaw Marczak 
+ *
  * (C) Copyright 2009
  * Heiko Schocher, DENX Software Engineering, h...@denx.de.
  * Changes for multibus/multiadapter I2C support.
@@ -14,6 +17,11 @@
  */
 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #ifdef CONFIG_MPC8260  /* only valid for MPC8260 */
 #include 
 #include 
@@ -32,11 +40,9 @@
 #if defined(CONFIG_MPC852T) || defined(CONFIG_MPC866)
 #include 
 #endif
-#include 
 
+#if defined(CONFIG_SYS_I2C)
 #if defined(CONFIG_SOFT_I2C_GPIO_SCL)
-# include 
-
 # ifndef I2C_GPIO_SYNC
 #  define I2C_GPIO_SYNC
 # endif
@@ -85,6 +91,7 @@
 # endif
 
 #endif
+#endif
 
 /* #define DEBUG_I2C   */
 
@@ -109,6 +116,65 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CONFIG_SYS_I2C_SOFT_SLAVE CONFIG_SYS_I2C_SLAVE
 #endif
 
+/* DM SOFT I2C */
+#ifdef CONFIG_DM_I2C_SOFT
+# ifndef I2C_GPIO_SYNC
+#  define I2C_GPIO_SYNC(gpio)
+# endif
+
+# ifndef I2C_INIT
+#  define I2C_INIT(scl, sda)  \
+   do { } while (0)
+# endif
+
+# ifndef I2C_ACTIVE
+#  define I2C_ACTIVE(sda) \
+   do { } while (0)
+# endif
+
+# ifndef I2C_TRISTATE
+#  define I2C_TRISTATE(sda) \
+   do { } while (0)
+# endif
+
+# ifndef I2C_READ
+#  define I2C_READ(sda) dm_gpio_get_value(sda);
+# endif
+
+# ifndef I2C_SDA
+#  define I2C_SDA(sda, bit) \
+   do { \
+   if (bit) { \
+   sda->flags &= ~GPIOD_IS_OUT; \
+   sda->flags |= GPIOD_IS_IN; \
+   dm_gpio_set_dir(sda); \
+   } else { \
+   sda->flags &= ~GPIOD_IS_IN; \
+   sda->flags |= GPIOD_IS_OUT; \
+   dm_gpio_set_dir(sda); \
+   dm_gpio_set_value(sda, 0); \
+   } \
+   I2C_GPIO_SYNC(sda); \
+   } while (0)
+# endif
+
+# ifndef I2C_SCL
+#  define I2C_SCL(scl, bit) \
+   do { \
+   scl->flags &= ~GPIOD_IS_IN; \
+   scl->flags |= GPIOD_IS_OUT; \
+   dm_gpio_set_dir(scl); \
+   dm_gpio_set_value(scl, bit); \
+   I2C_GPIO_SYNC(scl); \
+   } while (0)
+# endif
+
+# ifndef I2C_DELAY
+#  define I2C_DELAY(us) udelay(us) /* 1/4 I2C clock duration */
+# endif
+
+#endif /* CONFIG_DM_I2C_SOFT */
+
 /*---
  * Definitions
  */
@@ -117,7 +183,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define I2C_ACK0   /* PD_SDA level to ack a byte */
 #define I2C_NOACK  1   /* PD_SDA level to noack a byte */
 
-
 #ifdef DEBUG_I2C
 #define PRINTD(fmt,args...)do {\
printf (fmt ,##args);   \
@@ -129,21 +194,30 @@ DECLARE_GLOBAL_DA

[U-Boot] [PATCH 0/3] dm: i2c: enable driver model for software i2c

[Przemyslaw Marczak]

This patchset enables driver model support for software i2c bus driver.
It was tested on Trats2 and Odroid U3 devices.

It can be tested on any other device by just modifying the dts file,
first by disabling the hardware i2c bus and then, as it is described
in the Kconfig help entry, setup soft-i2c node.

The drivers, which are using the old api are not converted with this patchset.
I hope that maintainers will do this if required.

Probably the software i2c is used for PMIC devices not only for Trats2,
or Universal C210, so I suggest to wait with moving the drivers until
the pmic is done - this will prevent adding temporary code.

Przemyslaw Marczak (3):
  dm: i2c soft: enable driver model for software i2c driver
  Kconfig: i2c: remove wrong help message related to dm i2c
  Kconfig: i2c: add entry for driver-model software i2c

 drivers/i2c/Kconfig|  54 +--
 drivers/i2c/Makefile   |   1 +
 drivers/i2c/soft_i2c.c | 410 +++--
 3 files changed, 444 insertions(+), 21 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH 2/3] Kconfig: i2c: remove wrong help message related to dm i2c

[Przemyslaw Marczak]

Signed-off-by: Przemyslaw Marczak 
Cc: Masahiro Yamada 
Cc: Mike Frysinger 
Cc: Simon Glass 
Cc: Heiko Schocher 
---
 drivers/i2c/Kconfig | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 692810d..0a52ed9 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -2,16 +2,7 @@ config DM_I2C
bool "Enable Driver Model for I2C drivers"
depends on DM
help
- Enable driver model for I2C. This SPI flash interface
- (spi_flash_probe(), spi_flash_write(), etc.) is then
- implemented by the SPI flash uclass. There is one standard
- SPI flash driver which knows how to probe most chips
- supported by U-Boot. The uclass interface is defined in
- include/spi_flash.h, but is currently fully compatible
- with the old interface to avoid confusion and duplication
- during the transition parent. SPI and SPI flash must be
- enabled together (it is not possible to use driver model
- for one and not the other).
+ Enable driver model for I2C.
 
 config DM_I2C_COMPAT
bool "Enable I2C compatibility layer"
-- 
1.9.1

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

[U-Boot] [PATCH 1/1] beagle_x15: increase phy autoneg timeout

[Sekhar Nori]

When Beagle X15 is connected to Gigabit switch, it takes
more time to finish auto-negotiation than on a 10/100 switch.

The default 4 second limit times-out more often than not. This is
observed when testing with a D-Link DGS-1008A desktop switch.

Increase the auto-negotiation time-out for Beagle-X15 to handle
this case.

Signed-off-by: Sekhar Nori 
---
 include/configs/beagle_x15.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/beagle_x15.h b/include/configs/beagle_x15.h
index c7719f389a64..4aa855092110 100644
--- a/include/configs/beagle_x15.h
+++ b/include/configs/beagle_x15.h
@@ -59,6 +59,7 @@
 #define CONFIG_MII /* Required in net/eth.c */
 #define CONFIG_PHY_GIGE/* per-board part of CPSW */
 #define CONFIG_PHYLIB
+#define PHY_ANEG_TIMEOUT   8000/* PHY needs longer aneg time at 1G */
 
 #define CONFIG_SUPPORT_EMMC_BOOT
 
-- 
1.7.10.1

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

Re: [U-Boot] [PATCH] Vexpress64: Fix the compiling error when CONFIG_ARMV8_MULTIENTRY defined

[Linus Walleij]

On Tue, Mar 10, 2015 at 3:08 AM,   wrote:

> From: David Feng 
>
> CPU_RELEASE_ADDR should be defined when CONFIG_ARMV8_MULTIENTRY is used.
>
> Signed-off-by: David Feng 

As asked earlier: how can I test this with FVP or the base model?

I'm very interested in doing this as I guess it involves starting U-Boot
at EL3 on bare metal and I really want to try this.

> +/* SMP Spin Table Definitions */
> +#ifdef CONFIG_BASE_FVP
> +#define CPU_RELEASE_ADDR   (CONFIG_SYS_SDRAM_BASE + 0x03f0)
> +#else
> +#define CPU_RELEASE_ADDR   (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
> +#endif

Where are these address defines coming from?

Do these spin tables exist in a standard ARM FVP or base model?

I get the impression that a secondary operating system is being booted
on the secondary CPU at one of these addresses, but why is it running
at these addresses specifically, and is that something coming with these
simulators, or is it some image that is loaded on the side, that the
community does not have access to?

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

[U-Boot] [PATCH] T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue

[Zhao Qiang]

T2080QDS PEX1/Slot#1 will down-train from x4 to x2,
with SRDS_PRTCL_S1 = 0x66 and SRDS_PRTCL_S2 = 0x15.
Soft reset PCIe can fix this issue, this is a workaround.

Signed-off-by: Zhao Qiang 
---
 drivers/pci/fsl_pci_init.c | 17 +
 include/configs/T208xQDS.h |  1 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 231b075..327fa7d 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -481,6 +481,23 @@ void fsl_pci_init(struct pci_controller *hose, struct 
fsl_pci_info *pci_info)
 #endif
}
 
+#ifdef CONFIG_FSL_PCIE_T2080QDS_RESET
+   int i;
+   /* assert PCIe reset */
+   setbits_be32(&pci->pdb_stat, 0x0800);
+   (void) in_be32(&pci->pdb_stat);
+   udelay(1000);
+   /* clear PCIe reset */
+   clrbits_be32(&pci->pdb_stat, 0x0800);
+   asm("sync;isync");
+   for (i = 0; i < 100 && ltssm < PCI_LTSSM_L0; i++) {
+   pci_hose_read_config_word(hose, dev, PCI_LTSSM,
+ 

[U-Boot] [PATCH] odroid: defconfig: fix build break caused by missing dts

[Przemyslaw Marczak]

The build break was caused by one of my previous commit:
'odroid: defconfig: disable memset at malloc init'

It removes the dts from odroid defconfig - rebase mistake.

Signed-off-by: Przemyslaw Marczak 
Cc: Minkyu Kang 
---
 configs/odroid_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
index cfb29e0..d32b5b5 100644
--- a/configs/odroid_defconfig
+++ b/configs/odroid_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_EXYNOS=y
 CONFIG_TARGET_ODROID=y
 CONFIG_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="exynos4412-odroid"
 CONFIG_DM_I2C=y
 CONFIG_DM_I2C_COMPAT=y
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-- 
1.9.1

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

Re: [U-Boot] [PATCH] Exynos: Clock: Fix exynos5_get_periph_rate for I2C.

[Guillaume Gardet]

Le 28/02/2015 08:59, Minkyu Kang a écrit :

Joonyoung,

On 26/02/15 00:22, Guillaume GARDET wrote:

Commit 2e82e9252695a612ab0cbf40fa0c7368515f6506 'Exynos: Clock: Cleanup
soc_get_periph_rate' introduced a bug in I2C config. This patch makes cros_ec
keyboard working again on Samsung Chromebook (snow).

Signed-off-by: Guillaume GARDET 
Cc: Akshay Saraswat 
Cc: Minkyu Kang 
Cc: Joonyoung Shim 

---
  arch/arm/cpu/armv7/exynos/clock.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index c6455c2..7f47d4d 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -423,8 +423,8 @@ static unsigned long exynos5_get_periph_rate(int peripheral)
case PERIPH_ID_I2C6:
case PERIPH_ID_I2C7:
src = EXYNOS_SRC_MPLL;
-   div = readl(&clk->div_top0);
-   sub_div = readl(&clk->div_top1);
+   sub_div = readl(&clk->div_top0);
+   div = readl(&clk->div_top1);
break;
default:
debug("%s: invalid peripheral %d", __func__, peripheral);


Could you please check this patch?


Ping.

This patch must be applied before the release, otherwise, keyboard on Samsung 
Chromebook will no work at all.


Guillaume



Thanks,
Minkyu Kang.



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

Re: [U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

[aneesh.ban...@freescale.com]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, March 05, 2015 10:38 PM
> To: Bansal Aneesh-B39320
> Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> secure boot target for P3041
> 
> On Thu, 2015-03-05 at 01:26 -0600, Bansal Aneesh-B39320 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, March 05, 2015 2:41 AM
> > > To: Bansal Aneesh-B39320
> > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431
> > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND
> > > secure boot target for P3041
> > >
> > > Where does the 3.5G limitation come from?  Even if the physical
> > > address needs to be elsewhere due to bootrom constraints, we should
> > > be able to map it wherever we want in the TLB once U-Boot takes
> control.
> > >
> > The 3.5G limitation comes from BootROM in case of secure Boot.
> > Initially U-Boot has to run from CPC configured as SRAM with address
> > Within 3.5G. Once U-boot has relocated to DDR, we have removed the
> > Corresponding TLB entry.
> 
> Again, you could relocate the virtual address of L3 much earlier.
> 
> -Scott
> 
Are you suggesting the following:
1.  PBI Commands to configure CPC as SRAM with address 0xBFF0_.
2.  Compile U-boot with TEXT BASE as 0xFFF4.
3.  Copy the U-boot from NAND via PBI commands to CPC (SRAM) on address 
0xBFF4_
4.  The BootROM will validate the U-boot and transfer the control to 
0xBFFF_FFFC.
5.  When U-boot is executing, then in the last 4K code, when shifting from AS=0 
to AS=1, 
  we change the address of SRAM from 0xBFF0_ to 0xFFF0_. (Similar 
to what is done for NOR Boot)

- Aneesh

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

[U-Boot] [PATCH] board/t208xrdb: VID support

[ying.zhang]

From: Ying Zhang 

The fuse status register provides the values from on-chip
voltage ID efuses programmed at the factory.
These values define the voltage requirements for
the chip. u-boot reads FUSESR and translates the values
into the appropriate commands to set the voltage output
value of an external voltage regulator.

Signed-off-by: Ying Zhang 
---
 board/freescale/t208xrdb/t208xrdb.c |  7 +++
 include/configs/T208xRDB.h  | 11 +++
 2 files changed, 18 insertions(+)

diff --git a/board/freescale/t208xrdb/t208xrdb.c 
b/board/freescale/t208xrdb/t208xrdb.c
index 341453b..ad393df 100644
--- a/board/freescale/t208xrdb/t208xrdb.c
+++ b/board/freescale/t208xrdb/t208xrdb.c
@@ -19,6 +19,7 @@
 #include 
 #include "t208xrdb.h"
 #include "cpld.h"
+#include "../common/vid.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -85,6 +86,12 @@ int board_early_init_r(void)
setup_portals();
 #endif
 
+   /*
+* Adjust core voltage according to voltage ID
+* This function changes I2C mux to channel 2.
+*/
+   if (adjust_vdd(0))
+   printf("Warning: Adjusting core voltage failed.\n");
return 0;
 }
 
diff --git a/include/configs/T208xRDB.h b/include/configs/T208xRDB.h
index db6b42e..2e48fc8 100644
--- a/include/configs/T208xRDB.h
+++ b/include/configs/T208xRDB.h
@@ -449,6 +449,17 @@ unsigned long get_board_ddr_clk(void);
 #define I2C_MUX_PCA_ADDR_SEC2  0x76 /* I2C bus multiplexer,secondary 2 */
 #define I2C_MUX_CH_DEFAULT 0x8
 
+#define I2C_MUX_CH_VOL_MONITOR 0xa
+
+#define CONFIG_VID_FLS_ENV "t208xrdb_vdd_mv"
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_VID
+#endif
+#define CONFIG_VOL_MONITOR_IR36021_SET
+#define CONFIG_VOL_MONITOR_IR36021_READ
+/* The lowest and highest voltage allowed for T208xRDB */
+#define VDD_MV_MIN 819
+#define VDD_MV_MAX 1212
 
 /*
  * RapidIO
-- 
1.8.4.1

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

[U-Boot] [PATCH] Add bootscript support to esbc_validate.

[Gaurav Rana]

1. Default environment will be used for secure boot flow
 which can't be edited or saved.
2. Command for secure boot is predefined in the default
 environment which will run on autoboot (and autoboot is
 the only option allowed in case of secure boot) and it
 looks like this:
 #define CONFIG_SECBOOT \
 "setenv bs_hdraddr 0xe8e0;" \
 "esbc_validate $bs_hdraddr;"\
 "source $img_addr;" \
 "esbc_halt;"
 #endif
3. Boot Script can contain esbc_validate commands and bootm command.
 Uboot source command used in default secure boot command will
 run the bootscript.
4. Command esbc_halt added to ensure either bootm executes
 after validation of images or core should just spin.

Signed-off-by: Ruchika Gupta 
Signed-off-by: Gaurav Rana 
---
 arch/arm/include/asm/fsl_secure_boot.h | 25 +
 arch/powerpc/include/asm/fsl_secure_boot.h | 19 +++
 board/freescale/common/cmd_esbc_validate.c | 16 ++
 include/config_fsl_secboot.h   | 89 ++
 include/configs/ls1021aqds.h   |  1 +
 5 files changed, 150 insertions(+)
 create mode 100644 arch/arm/include/asm/fsl_secure_boot.h
 create mode 100644 include/config_fsl_secboot.h

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
new file mode 100644
index 000..f097c81
--- /dev/null
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __FSL_SECURE_BOOT_H
+#define __FSL_SECURE_BOOT_H
+
+#ifdef CONFIG_SECURE_BOOT
+#ifndef CONFIG_FIT_SIGNATURE
+
+#define CONFIG_EXTRA_ENV \
+   "setenv fdt_high 0xcfff;"   \
+   "setenv initrd_high 0xcfff;"\
+   "setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
+
+/* The address needs to be modified according to NOR memory map */
+#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x600a
+
+#include 
+#endif
+#endif
+
+#endif
diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h 
b/arch/powerpc/include/asm/fsl_secure_boot.h
index 49f6814..8f794ef 100644
--- a/arch/powerpc/include/asm/fsl_secure_boot.h
+++ b/arch/powerpc/include/asm/fsl_secure_boot.h
@@ -67,5 +67,24 @@
 #define CONFIG_FSL_ISBC_KEY_EXT
 #endif
 
+#ifndef CONFIG_FIT_SIGNATURE
+/* The bootscript header address is different for B4860 because the NOR
+ * mapping is different on B4 due to reduced NOR size.
+ */
+#if defined(CONFIG_B4860QDS)
+#define CONFIG_BOOTSCRIPT_HDR_ADDR 0xecc0
+#elif defined(CONFIG_FSL_CORENET)
+#define CONFIG_BOOTSCRIPT_HDR_ADDR 0xe8e0
+#elif defined(CONFIG_BSC9132QDS)
+#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x8802
+#elif defined(CONFIG_C29XPCIE)
+#define CONFIG_BOOTSCRIPT_HDR_ADDR 0xec02
+#else
+#define CONFIG_BOOTSCRIPT_HDR_ADDR 0xee02
+#endif
+
+#include 
+#endif
+
 #endif
 #endif
diff --git a/board/freescale/common/cmd_esbc_validate.c 
b/board/freescale/common/cmd_esbc_validate.c
index 8500ba5..8bbe85b 100644
--- a/board/freescale/common/cmd_esbc_validate.c
+++ b/board/freescale/common/cmd_esbc_validate.c
@@ -8,6 +8,16 @@
 #include 
 #include 
 
+static int do_esbc_halt(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[])
+{
+   printf("Core is entering spin loop.\n");
+loop:
+   goto loop;
+
+   return 0;
+}
+
 static int do_esbc_validate(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
@@ -32,3 +42,9 @@ U_BOOT_CMD(
"Validates signature on a given image using RSA verification",
esbc_validate_help_text
 );
+
+U_BOOT_CMD(
+   esbc_halt,  1,  0,  do_esbc_halt,
+   "Put the core in spin loop ",
+   ""
+);
diff --git a/include/config_fsl_secboot.h b/include/config_fsl_secboot.h
new file mode 100644
index 000..050b157
--- /dev/null
+++ b/include/config_fsl_secboot.h
@@ -0,0 +1,89 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_FSL_SECBOOT_H
+#define __CONFIG_FSL_SECBOOT_H
+
+#ifdef CONFIG_SECURE_BOOT
+
+#ifndef CONFIG_CMD_ESBC_VALIDATE
+#define CONFIG_CMD_ESBC_VALIDATE
+#endif
+
+#ifndef CONFIG_EXTRA_ENV
+#define CONFIG_EXTRA_ENV   ""
+#endif
+
+/*
+ * Control should not reach back to uboot after validation of images
+ * for secure boot flow and therefore bootscript should have
+ * the bootm command. If control reaches back to uboot anyhow
+ * after validating images, core should just spin.
+ */
+
+/*
+ * Define the key hash for boot script here if public/private key pair used to
+ * sign bootscript are different from the SRK hash put in the fuse
+ * Example of defining KEY_HASH is
+ * #define CONFIG_BOOTSCRIPT_KEY_HASH \
+ *  "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
+ */
+
+#ifdef CONFIG_BOOTSCRIPT_KEY_HASH
+#define CONFIG_SECBOOT \
+   "setenv bs_hdrad

[U-Boot] [PATCH] mmc: fsl_esdhc fix register offset

[Peng Fan]

Commit f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1 introduces
error register offset.

Change the "char reserved3[59]" to "char reserved3[56]".

Signed-off-by: Peng Fan 
---
 drivers/mmc/fsl_esdhc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index c5e270d..db4d251 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -56,7 +56,7 @@ struct fsl_esdhc {
uintadsaddr;/* ADMA system address register */
charreserved2[100]; /* reserved */
uintvendorspec; /* Vendor Specific register */
-   charreserved3[59];  /* reserved */
+   charreserved3[56];  /* reserved */
uinthostver;/* Host controller version register */
charreserved4[4];   /* reserved */
uintdmaerraddr; /* DMA error address register */
-- 
1.8.4


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

[U-Boot] [PATCH 2/2] imx:mx6slevk support reading temperature

[Peng Fan]

This patch is to support reading temperature for mx6slevk board.

Signed-off-by: Peng Fan 
---
 configs/mx6slevk_defconfig| 4 
 configs/mx6slevk_spinor_defconfig | 4 
 include/configs/mx6slevk.h| 7 +++
 3 files changed, 15 insertions(+)

diff --git a/configs/mx6slevk_defconfig b/configs/mx6slevk_defconfig
index fb8c4de..c6b3108 100644
--- a/configs/mx6slevk_defconfig
+++ b/configs/mx6slevk_defconfig
@@ -1,3 +1,7 @@
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL"
 CONFIG_ARM=y
 CONFIG_TARGET_MX6SLEVK=y
+CONFIG_SYS_MALLOC_F=y
+CONFIG_SYS_MALLOC_F_LEN=0x400
+CONFIG_DM=y
+CONFIG_DM_THERMAL=y
diff --git a/configs/mx6slevk_spinor_defconfig 
b/configs/mx6slevk_spinor_defconfig
index 93efe73..454cb40 100644
--- a/configs/mx6slevk_spinor_defconfig
+++ b/configs/mx6slevk_spinor_defconfig
@@ -1,3 +1,7 @@
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL,SYS_BOOT_SPINOR"
 CONFIG_ARM=y
 CONFIG_TARGET_MX6SLEVK=y
+CONFIG_SYS_MALLOC_F=y
+CONFIG_SYS_MALLOC_F_LEN=0x400
+CONFIG_DM=y
+CONFIG_DM_THERMAL=y
diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
index 1221418..0a2fa27 100644
--- a/include/configs/mx6slevk.h
+++ b/include/configs/mx6slevk.h
@@ -251,4 +251,11 @@
 #define CONFIG_SYS_MMC_ENV_DEV 1   /* SDHC2*/
 #endif
 
+#define CONFIG_IMX6_THERMAL
+
+#define CONFIG_CMD_FUSE
+#if defined(CONFIG_CMD_FUSE) || defined(CONFIG_IMX6_THERMAL)
+#define CONFIG_MXC_OCOTP
+#endif
+
 #endif /* __CONFIG_H */
-- 
1.8.4


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

[U-Boot] [PATCH 1/2] imx:mx6dlsabresd fix error detecting thermal

[Peng Fan]

Before add CONFIG_SYS_MALLOC_F and CONFIG_SYS_MALLOC_F_LEN,
uboot will complains "CPU:   Temperature: Can't find sensor device".
This is because DM and DM_THERMAL are enabled, but SYS_MALLOC_F
is not configured.

After applying this patch, uboot can correctly detect the temperature.
"
U-Boot 2015.04-rc2-00146-g48b6e30-dirty (Mar 09 2015 - 13:04:36)

CPU:   Freescale i.MX6DL rev1.1 at 792 MHz
CPU:   Temperature 44 C
"

Signed-off-by: Peng Fan 
---
 configs/mx6dlsabresd_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/mx6dlsabresd_defconfig b/configs/mx6dlsabresd_defconfig
index 6adfd55..cde0d70 100644
--- a/configs/mx6dlsabresd_defconfig
+++ b/configs/mx6dlsabresd_defconfig
@@ -1,5 +1,7 @@
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6sabresd/mx6dlsabresd.cfg,MX6DL"
 CONFIG_ARM=y
 CONFIG_TARGET_MX6SABRESD=y
+CONFIG_SYS_MALLOC_F=y
+CONFIG_SYS_MALLOC_F_LEN=0x400
 CONFIG_DM=y
 CONFIG_DM_THERMAL=y
-- 
1.8.4


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

[U-Boot] [PATCH v2] common/board_f.c: Enable IMX watchdog in init_func_watchdog_init()

[Stefan Roese]

Without this patch, the IMX watchdog will not be initialized. And therefor
not active. This patch fixes this by calling hw_watchdog_init() also when
CONFIG_IMX_WATCHDOG is defined.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Fabio Estevam  
Cc: Stefano Babic 
Cc: Heiko Schocher 
---
v2:
- Move closing parenthesis to include all "||" parts

 common/board_f.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 4d8b8a6..89ce795 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -111,7 +111,8 @@ static int init_func_watchdog_init(void)
 {
 # if defined(CONFIG_HW_WATCHDOG) && (defined(CONFIG_BLACKFIN) || \
defined(CONFIG_M68K) || defined(CONFIG_MICROBLAZE) || \
-   defined(CONFIG_SH) || defined(CONFIG_AT91SAM9_WATCHDOG))
+   defined(CONFIG_SH) || defined(CONFIG_AT91SAM9_WATCHDOG) || \
+   defined(CONFIG_IMX_WATCHDOG))
hw_watchdog_init();
 # endif
puts("   Watchdog enabled\n");
-- 
2.3.2

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