[U-Boot] [Patch v2] armv8: Enable CPUECTLR.SMPEN for coherency

[Gong Qianyu]

From: Mingkai Hu 

For A53, data coherency is enabled only when the CPUECTLR.SMPEN bit is
set. The SMPEN bit should be set before enabling the data cache.
If not enabled, the cache is not coherent with other cores and
data corruption could occur.

For A57/A72, SMPEN bit enables the processor to receive instruction
cache and TLB maintenance operations broadcast from other processors
in the cluster. This bit should be set before enabling the caches and
MMU, or performing any cache and TLB maintenance operations.

Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
Reviewed-by: Masahiro Yamada 
---
v2:
 - Revise commit message, add for A57/A72 part.
 - Add comments above the code.

 arch/arm/cpu/armv8/start.S | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 670e323..dfce469 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -81,6 +81,14 @@ reset:
msr cpacr_el1, x0   /* Enable FP/SIMD */
 0:
 
+   /* Enalbe SMPEN bit for coherency.
+* This register is not architectural but at the moment
+* this bit should be set for A53/A57/A72.
+*/
+   mrs x0, S3_1_c15_c2_1   /* cpuactlr_el1 */
+   orr x0, x0, #0x40
+   msr S3_1_c15_c2_1, x0
+
/* Apply ARM core specific erratas */
bl  apply_core_errata
 
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] build error

[Chen-Yu Tsai]

Hi,

On Wed, Jul 6, 2016 at 2:42 PM, Chen-Yu Tsai  wrote:
> Hi,
>
> On Wed, Jul 6, 2016 at 8:22 AM, Richard Snow  wrote:
>> Building current source for 4 boards (4 threads, 2 jobs per thread)
>>arm:  +   q8_a33_tablet_800x480
>> +{standard input}: Assembler messages:
>> +{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
>> {r0,r1,r2,r3,r4,r9,ip,pc}^'
>> +make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
>> +make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
>> +make[1]: *** [arch/arm/cpu/armv7] Error 2
>> +make: *** [sub-make] Error 2
>>arm:  +   q8_a23_tablet_800x480
>> +{standard input}: Assembler messages:
>> +{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
>> {r0,r1,r2,r3,r4,r9,ip,pc}^'
>> +make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
>> +make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
>> +make[1]: *** [arch/arm/cpu/armv7] Error 2
>> +make: *** [sub-make] Error 2
>>arm:  +   q8_a33_tablet_1024x600
>> +{standard input}: Assembler messages:
>> +{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
>> {r0,r1,r2,r3,r4,r9,ip,pc}^'
>> +make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
>> +make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
>> +make[1]: *** [arch/arm/cpu/armv7] Error 2
>> +make: *** [sub-make] Error 2
>> 103 /4  q8_a13_tablet
>> richard@ubuntu:~/u-boot$
>
> This is a known and fixed GCC bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
> https://bugzilla.redhat.com/show_bug.cgi?id=1344717

I referenced the wrong upstream bug. It's this one:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70830

ChenYu

>
> You should update your toolchain.
>
> ChenYu
>
>>
>> My tablet is labeled AllDayMall model a88x bsf1.  The firmware that came
>> with it is defective the wifi does not work, i am trying to
>> set up to boot linux gentoo or other linux from sd card.
>>
>> --
>> h ttp://richardsnow.info
>> My Google Plus profile 
>> ___
>> 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 2/2] dm: mmc: dwmmc: use the callback functions as static

[Minkyu Kang]

Hi,

On 01/07/16 04:53, Simon Glass wrote:
> Hi Jaehoon,
> 
> On 28 June 2016 at 20:47, Jaehoon Chung  wrote:
>> Hi Simon,
>>
>> On 06/29/2016 12:28 PM, Simon Glass wrote:
>>> Hi Jaehoon,
>>>
>>> On 27 June 2016 at 23:52, Jaehoon Chung  wrote:
 There are no places to call these functions.
 It should be used the callback function.
 Then it can be used as static functions.

 Signed-off-by: Jaehoon Chung 
 ---
  drivers/mmc/dw_mmc.c | 4 ++--
  include/dwmmc.h  | 3 ---
  2 files changed, 2 insertions(+), 5 deletions(-)

 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 3411f95..f83a6bc 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -182,7 +182,7 @@ static int dwmci_set_transfer_mode(struct dwmci_host 
 *host,
  }

  #ifdef CONFIG_DM_MMC_OPS
 -int dwmci_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
>>>
>>> >From what I can see this is already static. Which commit are you basing 
>>> >off?
>>
>> I'm checking with your 'blk-working' branch. I'm not sure what's correct.
>>
>> commit dee390a1250c17a4e71e359d6e461319a7cdea54
>> Author: Simon Glass 
>> Date:   Sat Jun 11 19:01:49 2016 -0600
>>
>> dm: blk: Enable CONFIG_BLK if DM_MMC is enabled
>>
>> If i need to work with other branch, let me know,plz.
>> I have tested the DM with dw_mmc_exynos.c. (It's working fine.)
>>
>> I will send the patch-set for exynos dwmmc and sdhci controller.
>> So i need to know which repository and branch are correct. :)
>>
>> Then it's helpful to me for working dm. I think that i can help you for 
>> checking on mmc side with DM.
> 
> OK I see, thanks.
> 
> Reviewed-by: Simon Glass 
> 

This patch has been delegated to me, but cannot apply to u-boot-samsung.
should go to dm tree?

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

Re: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys

[Ziyuan Xu]

On 2016年07月06日 21:42, Heiko Stuebner wrote:

Am Mittwoch, 6. Juli 2016, 14:48:57 schrieb Heiko Stuebner:

Am Mittwoch, 6. Juli 2016, 18:20:04 schrieb Ziyuan Xu:

Hi heiko,

On 2016年07月06日 17:34, Ziyuan Xu wrote:

From: Xu Ziyuan 

So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and
Innosilicon. This patch applys dwc2 usb driver framework to implement
phy_init and phy_off for Synopsys phy on Rockchip platform.

Signed-off-by: Ziyuan Xu 

---

Changes in v3:
- Make UOC_CON registers to be unfixed which should be got from DT

Changes in v2:
- Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
- Rework the behaviour in otg_phy_init() and otg_phy_off()

   drivers/usb/phy/Makefile|  1 +
   drivers/usb/phy/rockchip_usb_syno_phy.c | 47
   + 2 files changed, 48 insertions(+)
   create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c

diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 93d147e..8002a18 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -7,3 +7,4 @@

   obj-$(CONFIG_TWL4030_USB) += twl4030.o
   obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o

+obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o
diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c
b/drivers/usb/phy/rockchip_usb_syno_phy.c new file mode 100644
index 000..ab049e1
--- /dev/null
+++ b/drivers/usb/phy/rockchip_usb_syno_phy.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+#include "../gadget/dwc2_udc_otg_priv.h"
+
+#define UOC_CON(x) ((x) * 0x4)

As you know, dwc2 usb driver didn't apply devicetree model. It's hard to
implement a compatible driver for Rockchip SoCs which use a same udc.

Yeah, it is pretty strange that the dwc2 host part in uboot uses the
devicetree while the gadget part does not - but I maybe someone else can
answer this, as my contact with uboot was limited until now.
The dwc2 host driver works just fine on my rk3036 kylin board.


For example,
SOFT_CTRL bit is  UOC_CON2[2] on RK3288
I can't assure it's also UOC_CON[2] on other socs.
Do you have any good ideas?

Operating under the current constraints, I guess you could simply do
something similar to what socfpga does in its board file.
socfpga? Could you please indicate which project and file? I can't find 
out it.

Aka get the usb controller node, read the phy phandle and get the phy
compatible string from the dts. The usbphys each have per-soc compatible
values "rockchip,rk3288-usbphy" etc, so you can determine the needed bits
over that.
In patchset [v3.3/4](http://patchwork.ozlabs.org/patch/645188/), I had 
get usb-phy offset from grf.
If I understand it correctly, you mean that implement a struct in driver 
to match compatible and platdata. Then define any properties in 
platdata, contains of some bits which will be used.  Something similar 
to https://patchwork.kernel.org/patch/9190287/?

forgot to add, with this same mechanism you could also resolve the fifo
length from the devicetree into the platdata struct instead of hard-coding
it with an ARCH_ROCKCHIP define.

Good idea, I will do it.


Heiko






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

[U-Boot] [Patch v2] powerpc: mpc85xx: kmp204x: Fix compiling error for usb errata

[York Sun]

Commit 9262367 moves USB errata workaround into a C file. This
causes compiling error for kmcoge4 and kmlion1. To enable the
errata workaround, define CONFIG_USB_EHCI_FSL in common header.

Signed-off-by: York Sun 
Cc: Marek Vasut 
Cc: Ed Swarthout 
Cc: Sriram Dash 
Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and ARM")
---
Change log
  v2: Rebase to u-boot-usb/master.
  Drop SPL fix.

 include/configs/km/kmp204x-common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/km/kmp204x-common.h 
b/include/configs/km/kmp204x-common.h
index 028623d..5bdda22 100644
--- a/include/configs/km/kmp204x-common.h
+++ b/include/configs/km/kmp204x-common.h
@@ -406,6 +406,7 @@ int get_scl(void);
 #endif
 
 #define __USB_PHY_TYPE utmi
+#define CONFIG_USB_EHCI_FSL
 
 /*
  * Environment Configuration
-- 
2.7.4

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

[U-Boot] [PATCH] powerpc: mpc85xx: Fix compiling error for usb errata

[York Sun]

Commit 9262367 moves USB errata workaround into a C file. This
causes compiling error for SPL targets, as well as kmcoge4 and
kmlion1. The errata command is useless in SPL, so don't build
it. For kmcoge4 and kmlion1, define CONFIG_USB_EHCI_FSL in the
common header file to build the errata file.

Signed-off-by: York Sun 
Cc: Marek Vasut 
Cc: Ed Swarthout 
Cc: Sriram Dash 
Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and ARM")
---

 arch/powerpc/cpu/mpc85xx/Makefile   | 2 ++
 include/configs/km/kmp204x-common.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/Makefile 
b/arch/powerpc/cpu/mpc85xx/Makefile
index 65c26c0..f4c4fe2 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -26,7 +26,9 @@ else
 
 obj-$(CONFIG_MP)   += release.o
 
+ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_CMD_ERRATA) += cmd_errata.o
+endif
 obj-$(CONFIG_CPM2) += commproc.o
 
 obj-$(CONFIG_CPM2) += ether_fcc.o
diff --git a/include/configs/km/kmp204x-common.h 
b/include/configs/km/kmp204x-common.h
index 028623d..5bdda22 100644
--- a/include/configs/km/kmp204x-common.h
+++ b/include/configs/km/kmp204x-common.h
@@ -406,6 +406,7 @@ int get_scl(void);
 #endif
 
 #define __USB_PHY_TYPE utmi
+#define CONFIG_USB_EHCI_FSL
 
 /*
  * Environment Configuration
-- 
2.7.4

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

Re: [U-Boot] [PATCH] powerpc: mpc85xx: Fix compiling error for usb errata

[Marek Vasut]

On 07/07/2016 01:18 AM, York Sun wrote:

Commit 9262367 moves USB errata workaround into a C file. This
causes compiling error for SPL targets, as well as kmcoge4 and
kmlion1. The errata command is useless in SPL, so don't build
it. For kmcoge4 and kmlion1, define CONFIG_USB_EHCI_FSL in the
common header file to build the errata file.

Signed-off-by: York Sun 
Cc: Marek Vasut 
Cc: Ed Swarthout 
Cc: Sriram Dash 
Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and ARM")


Please send me a patch which applies on top of u-boot-usb/master .


---

 arch/powerpc/cpu/mpc85xx/Makefile   | 2 ++
 include/configs/km/kmp204x-common.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/Makefile 
b/arch/powerpc/cpu/mpc85xx/Makefile
index 65c26c0..f4c4fe2 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -26,7 +26,9 @@ else

 obj-$(CONFIG_MP)   += release.o

+ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_CMD_ERRATA) += cmd_errata.o
+endif
 obj-$(CONFIG_CPM2) += commproc.o

 obj-$(CONFIG_CPM2) += ether_fcc.o
diff --git a/include/configs/km/kmp204x-common.h 
b/include/configs/km/kmp204x-common.h
index 028623d..5bdda22 100644
--- a/include/configs/km/kmp204x-common.h
+++ b/include/configs/km/kmp204x-common.h
@@ -406,6 +406,7 @@ int get_scl(void);
 #endif

 #define __USB_PHY_TYPE utmi
+#define CONFIG_USB_EHCI_FSL

 /*
  * Environment Configuration




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

Re: [U-Boot] mkimage can't read .tmp

[Simon Glass]

Hi Tom,

On 30 June 2016 at 09:46, Simon Glass  wrote:
>
> Hi Tom,
>
> On 27 June 2016 at 23:50, Tom Van Deun  wrote:
> > Hello all
> >
> > I have been trying to create a FIT image using mkimage using the command:
> >
> > mkimage -D "-I dts -O dtb -p 2000" -f name.its name.fit
> >
> > The output is:
> >
> > DTC: dts->dtb  on file "name.its"
> > mkimage: Can't read name.fit.tmp: Invalid argument
> > mkimage Can't add hashes to FIT blob
> >
> > No matter what I try, which arguments I add or remove or which 
> > modifications I make to the its file, I keep getting this output. 
> > Unfortunately I can't find much on Google for this exact issue. I found 
> > someone who solved the issue by installing DTC, but that is not the issue 
> > in my case.
> >
> > Uboot development tools, DTC and mkimage are all at the latest version.
> >
> > Does anyone have any idea what other issues might be causing this behavior?
>
> Not exactly, but I think this is failing on the mmap() call, probably
> in mmap_fdt(). Is there anything special about your filesystem?

I copied you on a patch that might help.

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

Re: [U-Boot] [RESEND PATCH v5 01/12] dm: core: implement dev_map_phsymem()

[Simon Glass]

Hi,

On 5 July 2016 at 22:28, Vignesh R  wrote:
> This API helps to map physical register addresss pace of device to
> virtual address space easily. Its just a wrapper around map_physmem()
> with MAP_NOCACHE flag.
>

nit: dev_map_physmem() in the subject

> Signed-off-by: Vignesh R 
> Suggested-by: Simon Glass 
> Reviewed-by: Jagan Teki 
> Reviewed-by: Simon Glass 
> ---
>  drivers/core/device.c | 11 +++
>  include/dm/device.h   | 13 +
>  2 files changed, 24 insertions(+)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index eb75b1734f9b..f7fb0cc0fa7c 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -10,6 +10,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -697,6 +698,16 @@ void *dev_get_addr_ptr(struct udevice *dev)
> return (void *)(uintptr_t)dev_get_addr_index(dev, 0);
>  }
>
> +void *dev_map_physmem(struct udevice *dev, unsigned long size)
> +{
> +   fdt_addr_t addr = dev_get_addr(dev);
> +
> +   if (addr == FDT_ADDR_T_NONE)
> +   return NULL;
> +
> +   return map_physmem(addr, size, MAP_NOCACHE);
> +}
> +
>  bool device_has_children(struct udevice *dev)
>  {
> return !list_empty(>child_head);
> diff --git a/include/dm/device.h b/include/dm/device.h
> index f03bcd3b49ee..1bfcf3bcbc01 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -467,6 +467,19 @@ fdt_addr_t dev_get_addr(struct udevice *dev);
>  void *dev_get_addr_ptr(struct udevice *dev);
>
>  /**
> + * dev_map_physmem() - Read device address from reg property of the
> + * device node and map the address into CPU address
> + * space.
> + *
> + * @dev: Pointer to device
> + * @size: size of the memory to map
> + *
> + * @return  mapped address, or NULL if the device does not have reg
> + *  property.
> + */
> +void *dev_map_physmem(struct udevice *dev, unsigned long size);
> +
> +/**
>   * dev_get_addr_index() - Get the indexed reg property of a device
>   *
>   * @dev: Pointer to a device
> --
> 2.9.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc: mpc85xx: Do not build errata command in SPL

[york sun]

On 07/06/2016 03:26 PM, Marek Vasut wrote:
> On 07/06/2016 08:49 PM, york sun wrote:
>> On 07/06/2016 10:05 AM, Marek Vasut wrote:
>>> On 07/06/2016 06:33 PM, york sun wrote:
 On 07/05/2016 11:38 AM, Marek Vasut wrote:
> On 07/05/2016 08:37 PM, Marek Vasut wrote:
>> The errata command is useless in SPL, so don't build it. This fixes
>> multiple build failures on PowerPC.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: York Sun 
>> Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and 
>> ARM")
>
> Since 2016.07 is very close and I don't see any other real solution,
> applied.

 Thank you Marek to take care of this. We will revisit this if Sriram
 comes up with a better solution.
>>>
>>> Great. I am _really_ unhappy about the patch quality and lack of testing.
>>>
>>
>> Marek,
>>
>> Even with your patch, we still have a compiling error for kmcoge4 and
>> kmlion1.
>
> Can you do a patch ?
>

Sure. Let me work on it.

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

Re: [U-Boot] [PATCH] powerpc: mpc85xx: Do not build errata command in SPL

[Marek Vasut]

On 07/07/2016 12:28 AM, york sun wrote:

On 07/06/2016 03:26 PM, Marek Vasut wrote:

On 07/06/2016 08:49 PM, york sun wrote:

On 07/06/2016 10:05 AM, Marek Vasut wrote:

On 07/06/2016 06:33 PM, york sun wrote:

On 07/05/2016 11:38 AM, Marek Vasut wrote:

On 07/05/2016 08:37 PM, Marek Vasut wrote:

The errata command is useless in SPL, so don't build it. This fixes
multiple build failures on PowerPC.

Signed-off-by: Marek Vasut 
Cc: York Sun 
Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and ARM")


Since 2016.07 is very close and I don't see any other real solution,
applied.


Thank you Marek to take care of this. We will revisit this if Sriram
comes up with a better solution.


Great. I am _really_ unhappy about the patch quality and lack of testing.



Marek,

Even with your patch, we still have a compiling error for kmcoge4 and
kmlion1.


Can you do a patch ?



Sure. Let me work on it.


Great, thanks. Deadline is 11th (2016.07 release), so please make it quick.


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

[U-Boot] [PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:

  Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)

are available in the git repository at:

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

for you to fetch changes up to 12c67d7522d77c5aa5ee1e5ec4147b569ccb7666:

  powerpc: mpc85xx: Do not build errata command in SPL (2016-07-05 
17:40:28 +0200)



Hans de Goede (2):
  usb: dm: Add a usb_for_each_root_dev() helper function
  usb: dm: Make "usb info" use usb_for_each_root_dev()

Marek Vasut (1):
  powerpc: mpc85xx: Do not build errata command in SPL

 arch/powerpc/cpu/mpc85xx/Makefile |  2 ++
 cmd/usb.c | 46 
++

 2 files changed, 20 insertions(+), 28 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc: mpc85xx: Do not build errata command in SPL

[Marek Vasut]

On 07/06/2016 08:49 PM, york sun wrote:

On 07/06/2016 10:05 AM, Marek Vasut wrote:

On 07/06/2016 06:33 PM, york sun wrote:

On 07/05/2016 11:38 AM, Marek Vasut wrote:

On 07/05/2016 08:37 PM, Marek Vasut wrote:

The errata command is useless in SPL, so don't build it. This fixes
multiple build failures on PowerPC.

Signed-off-by: Marek Vasut 
Cc: York Sun 
Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and ARM")


Since 2016.07 is very close and I don't see any other real solution,
applied.


Thank you Marek to take care of this. We will revisit this if Sriram
comes up with a better solution.


Great. I am _really_ unhappy about the patch quality and lack of testing.



Marek,

Even with your patch, we still have a compiling error for kmcoge4 and
kmlion1.


Can you do a patch ?

--
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] powerpc: mpc85xx: Do not build errata command in SPL

[york sun]

On 07/06/2016 10:05 AM, Marek Vasut wrote:
> On 07/06/2016 06:33 PM, york sun wrote:
>> On 07/05/2016 11:38 AM, Marek Vasut wrote:
>>> On 07/05/2016 08:37 PM, Marek Vasut wrote:
 The errata command is useless in SPL, so don't build it. This fixes
 multiple build failures on PowerPC.

 Signed-off-by: Marek Vasut 
 Cc: York Sun 
 Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and 
 ARM")
>>>
>>> Since 2016.07 is very close and I don't see any other real solution,
>>> applied.
>>
>> Thank you Marek to take care of this. We will revisit this if Sriram
>> comes up with a better solution.
>
> Great. I am _really_ unhappy about the patch quality and lack of testing.
>

Marek,

Even with your patch, we still have a compiling error for kmcoge4 and 
kmlion1.

York

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

[U-Boot] Pull request, u-boot-tegra/master

[Tom Warren]

Tom,

Please pull u-boot-tegra/master into U-Boot/master. Thanks!

All Tegra builds are OK, and Stephen's automated test system reports that
all tests pass.

The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:

  Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)

are available in the git repository at:


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

for you to fetch changes up to 703aaf76c2c06109fc36266767b2d1dcfce6f3ba:

  fdt: Drop some unused compatible strings (2016-07-05 13:23:04 -0700)


Simon Glass (6):
  errno: Add copyright header and header guard
  errno: Allow errno_str() to be used without CONFIG_ERRNO_STR
  tegra: dts: Sync tegra20 device tree files with Linux
  video: tegra: Move to using simple-panel and pwm-backlight
  tegra: video: Always use write-through cache on LCD
  fdt: Drop some unused compatible strings

Stephen Warren (2):
  pci: tegra: correctly program PADS_REFCLK registers
  pci: tegra: actually program REFCLK_CFG* on recent SoCs

 arch/arm/dts/tegra20-harmony.dts  | 751 --
 arch/arm/dts/tegra20-seaboard.dts | 934
++
 arch/arm/dts/tegra20-ventana.dts  | 685 ++--
 configs/colibri_t20_defconfig |   3 +
 configs/harmony_defconfig |   3 +
 configs/medcom-wide_defconfig |   3 +
 configs/paz00_defconfig   |   3 +
 configs/seaboard_defconfig|   3 +
 configs/tec_defconfig |   3 +
 configs/ventana_defconfig |   3 +
 drivers/pci/pci_tegra.c   |  37 +-
 drivers/video/tegra.c | 333 +++---
 include/errno.h   |  12 +
 include/fdtdec.h  |   4 -
 lib/fdtdec.c  |   4 -
 15 files changed, 2329 insertions(+), 452 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] driver: fsl_qspi: disable AHB buffer prefetch

[york sun]

On 07/03/2016 08:27 PM, Yunhui Cui wrote:
> From: Yunhui Cui 
>
> A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
> Affects: QuadSPI
> Description: With AHB buffer prefetch enabled, the QuadSPI may return
> incorrect data on the AHB interface. The buffer pre-fetch is enabled
> if the fetch size as configured either in the LUT or in the BUFxCR register
> is greater than 8 bytes.
> Impact: Only 64 bit read allowed.
> Workaround: Keep the read data size to 64 bits (8 Bytes), which disables
> the prefetch on the AHB buffer,
> and prevents this issue from occurring.
>
> Signed-off-by: Yunhui Cui 
> ---
>   drivers/spi/fsl_qspi.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> index 75cbab2..e0a002d 100644
> --- a/drivers/spi/fsl_qspi.c
> +++ b/drivers/spi/fsl_qspi.c
> @@ -444,7 +444,7 @@ static void qspi_init_ahb_read(struct fsl_qspi_priv *priv)
>   qspi_write32(priv->flags, >buf1cr, QSPI_BUFXCR_INVALID_MSTRID);
>   qspi_write32(priv->flags, >buf2cr, QSPI_BUFXCR_INVALID_MSTRID);
>   qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
> -  (0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
> +  (0x1 << QSPI_BUF3CR_ADATSZ_SHIFT));
>
>   /* We only use the buffer3 */
>   qspi_write32(priv->flags, >buf0ind, 0);
>

Yunhui,

We handle erratum workaround using macros in case the workaround has 
impact on other SoCs. We also put the erratum information either in a 
README file, or inline comment. It will be easier to read the code 
later. You don't have to put the whole erratum description in the commit 
message, as long as it explains what this patch does and refer the 
erratum number somewhere in the message so we can search the git log.

York

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

Re: [U-Boot] [PATCH] powerpc/mpc85xx: Fix SPL_BUILD compilation by adding CONFIG_USB_EHCI_FSL flag

[york sun]

On 07/04/2016 08:38 PM, Sriram Dash wrote:
>> From: Marek Vasut [mailto:ma...@denx.de]
>> On 07/04/2016 01:11 PM, Sriram Dash wrote:
>>> Commit 9262367 moved USB errata workaround to a C file but didn't
>>> build it for SPL targets. The EHCI errata should be applied/checked
>>> only when EHCI is defined.
>>>
>>> Signed-off-by: Rajesh Bhagat 
>>> Signed-off-by: Sriram Dash 
>>> ---
>>>   arch/powerpc/include/asm/config_mpc85xx.h | 32
>>> +--
>>
>> So why don't you fix arch/powerpc/cpu/mpc85xx/cmd_errata.c instead of adding
>> zillion ifdefs into the config_mpc85xx.h ?
>>
>
> Hello Marek,
>
> The phy errata is applied at cpu init time for some boards. Due to this, the 
> code
> has been added in the file arch/powerpc/cpu/mpc85xx/cpu_init.c also. Now, this
> file is also required for SPL build. Hence, rather than fixing in every file 
> currently
> and the future implementations, I am thinking of fixing this at a common 
> place.
>

Let's think from another angle. What causes this issue? Some functions 
are called for SPL build. Do we need those functions? Earlier I thought 
we need some USB workaround for SPL. But that is not the case. The 
normal version of U-Boot can implement those workaround so we don't have 
to have them for SPL. So is the cmd_errata. Now I think Ed's simple fix 
makes more sense. It's getting close to 2016.07 release. Let's test more 
with the new fix proposed by Ed. Please don't hesitate to send a new 
patch if you have other ideas.

York


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

Re: [U-Boot] [PATCH] powerpc: mpc85xx: Do not build errata command in SPL

[Marek Vasut]

On 07/06/2016 06:33 PM, york sun wrote:

On 07/05/2016 11:38 AM, Marek Vasut wrote:

On 07/05/2016 08:37 PM, Marek Vasut wrote:

The errata command is useless in SPL, so don't build it. This fixes
multiple build failures on PowerPC.

Signed-off-by: Marek Vasut 
Cc: York Sun 
Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and ARM")


Since 2016.07 is very close and I don't see any other real solution,
applied.


Thank you Marek to take care of this. We will revisit this if Sriram
comes up with a better solution.


Great. I am _really_ unhappy about the patch quality and lack of testing.

--
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 v4 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 07/03/2016 08:39 PM, Huan Wang wrote:
>> On 30.06.16 09:16, Huan Wang wrote:
>>> Hi, Alex,
>>>
> Am 15.06.2016 um 05:04 schrieb Huan Wang :
>
> Hi, Alex,
>
>>> On 06/08/2016 07:14 AM, Alison Wang wrote:
>>> To support loading a 32-bit OS, the execution state will change
>>> from
>>> AArch64 to AArch32 when jumping to kernel.
>>>
>>> The architecture information will be got through checking FIT
>>> image, then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>>
>>> Signed-off-by: Ebony Zhu 
>>> Signed-off-by: Alison Wang 
>>> Signed-off-by: Chenhui Zhao 
>>> ---
>>> Changes in v4:
>>> - Correct config ARM64_SUPPORT_AARCH32.
>>> - Omit arch and ftaddr arguments.
>>> - Rename "xreg5" to "tmp".
>>> - Use xxx_RES1 to combine all RES1 fields in xxx register.
>>> - Use an immediate cmp directly.
>>> - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.
>>>
>>> Changes in v3:
>>> - Comments the functions and the arguments.
>>> - Rename the real parameters.
>>> - Use the macros instead of the magic values.
>>> - Remove the redundant codes.
>>> - Clean up all of the mess in boot_jump_linux().
>>> - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system
>> doesn't support AArch32 state.
>>>
>>> Changes in v2:
>>> - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m
>>> is
>> used
>>>to switch to AArch64 EL2 or AArch32 Hyp.
>>> - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m
>>> is
>> used
>>>to switch to AArch64 EL1 or AArch32 SVC.
>>>
>>>   arch/arm/Kconfig|   6 ++
>>>   arch/arm/cpu/armv8/start.S  |   1 +
>>>   arch/arm/cpu/armv8/transition.S |   8 +-
>>>   arch/arm/include/asm/macro.h| 172
>> ++--
>>>   arch/arm/include/asm/system.h   | 111 +-
>>>   arch/arm/lib/bootm.c|  19 -
>>>   common/image-fit.c  |  19 -
>>>   7 files changed, 284 insertions(+), 52 deletions(-)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
>>> 77eab66..9cf4acd 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -91,6 +91,12 @@ config SYS_L2CACHE_OFF
>>> If SoC does not support L2CACHE or one do not want to
>> enable
>>> L2CACHE, choose this option.
>>>
>>> +config ARM64_SUPPORT_AARCH32
>>> +bool "ARM64 system support AArch32 execution state"
>>> +default y if ARM64 && !TARGET_THUNDERX_88XX
>>> +help
>>> +  This ARM64 system supports AArch32 execution state.
>>> +
>>>   choice
>>>   prompt "Target select"
>>>   default TARGET_HIKEY
>>> diff --git a/arch/arm/cpu/armv8/start.S
>>> b/arch/arm/cpu/armv8/start.S index e933021..dd69501 100644
>>> --- a/arch/arm/cpu/armv8/start.S
>>> +++ b/arch/arm/cpu/armv8/start.S
>>> @@ -234,6 +234,7 @@ WEAK(lowlevel_init)
>>>   /*
>>>* All slaves will enter EL2 and optionally EL1.
>>>*/
>>> +ldrx3, =ES_TO_AARCH64
>>>   blarmv8_switch_to_el2
>>>   #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
>>>   blarmv8_switch_to_el1
>>> diff --git a/arch/arm/cpu/armv8/transition.S
>> b/arch/arm/cpu/armv8/transition.S
>>> index 253a39b..e61b6ae 100644
>>> --- a/arch/arm/cpu/armv8/transition.S
>>> +++ b/arch/arm/cpu/armv8/transition.S
>>> @@ -11,13 +11,13 @@
>>>   #include 
>>>
>>>   ENTRY(armv8_switch_to_el2)
>>> -switch_el x0, 1f, 0f, 0f
>>> +switch_el x4, 1f, 0f, 0f
>>>   0:ret
>>> -1:armv8_switch_to_el2_m x0
>>> +1:armv8_switch_to_el2_m x0, x3, x4
>>>   ENDPROC(armv8_switch_to_el2)
>>>
>>>   ENTRY(armv8_switch_to_el1)
>>> -switch_el x0, 0f, 1f, 0f
>>> +switch_el x4, 0f, 1f, 0f
>>>   0:ret
>>> -1:armv8_switch_to_el1_m x0, x1
>>> +1:armv8_switch_to_el1_m x0, x3, x4
>>>   ENDPROC(armv8_switch_to_el1)
>>> diff --git a/arch/arm/include/asm/macro.h
>> b/arch/arm/include/asm/macro.h
>>> index 9bb0efa..109724f 100644
>>> --- a/arch/arm/include/asm/macro.h
>>> +++ b/arch/arm/include/asm/macro.h
>>> @@ -8,6 +8,9 @@
>>>
>>>   #ifndef __ASM_ARM_MACRO_H__
>>>   #define __ASM_ARM_MACRO_H__
>>> +
>>> +#include 
>>> +
>>>   #ifdef __ASSEMBLY__
>>>
>>>   /*
>>> @@ -135,13 +138,20 @@ lr.reqx30
>>>   #endif
>>>   .endm
>>>
>>> -.macro armv8_switch_to_el2_m, xreg1
>>> -/* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure
 EL0/EL1
>> */
>>> -mov\xreg1, #0x5b1
>>> -msrscr_el3, \xreg1
>>> +/*
>>> + * Switch 

Re: [U-Boot] [PATCH] powerpc: mpc85xx: Do not build errata command in SPL

[york sun]

On 07/05/2016 11:38 AM, Marek Vasut wrote:
> On 07/05/2016 08:37 PM, Marek Vasut wrote:
>> The errata command is useless in SPL, so don't build it. This fixes
>> multiple build failures on PowerPC.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: York Sun 
>> Fixes: 92623672f9d3 ("fsl: usb: make errata function common for PPC and ARM")
>
> Since 2016.07 is very close and I don't see any other real solution,
> applied.

Thank you Marek to take care of this. We will revisit this if Sriram 
comes up with a better solution.

York

>
>> ---
>>   arch/powerpc/cpu/mpc85xx/Makefile | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/powerpc/cpu/mpc85xx/Makefile 
>> b/arch/powerpc/cpu/mpc85xx/Makefile
>> index 65c26c0..f4c4fe2 100644
>> --- a/arch/powerpc/cpu/mpc85xx/Makefile
>> +++ b/arch/powerpc/cpu/mpc85xx/Makefile
>> @@ -26,7 +26,9 @@ else
>>
>>   obj-$(CONFIG_MP)   += release.o
>>
>> +ifndef CONFIG_SPL_BUILD
>>   obj-$(CONFIG_CMD_ERRATA) += cmd_errata.o
>> +endif
>>   obj-$(CONFIG_CPM2) += commproc.o
>>
>>   obj-$(CONFIG_CPM2) += ether_fcc.o
>>
>
>

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

[U-Boot] [PATCH] test/py: strip VT100 codes from match buffer

[Stephen Warren]

From: Stephen Warren 

Prior to this patch, any VT100 codes emitted by U-Boot are considered part
of a command's output, which often causes tests to fail. For example,
test_env_echo_exists executes printenv, and then considers any text on a
line before an = sign as a valid U-Boot environment variable name. This
includes any VT100 codes emitted. When the test later attempts to use that
variable, the name would be invalid since it includes the VT100 codes.
Solve this by stripping VT100 codes from the match buffer, so they are
never seen by higher level test code.

The codes are still logged unmodified, so that users can expect U-Boot's
exact output without interference. This does clutter the log file a bit.
However, it allows users to see exactly what U-Boot emitted rather than a
modified version, which hopefully is better for debugging. It's also much
simpler to implement, since logging happens as soon as text is received,
and so stripping the VT100 codes from the log would require handling
reception and stripping of partial VT100 codes.

Signed-off-by: Stephen Warren 
---
 test/py/u_boot_spawn.py | 9 +
 1 file changed, 9 insertions(+)

diff --git a/test/py/u_boot_spawn.py b/test/py/u_boot_spawn.py
index a5f4a8e91bae..d15517389e51 100644
--- a/test/py/u_boot_spawn.py
+++ b/test/py/u_boot_spawn.py
@@ -38,6 +38,11 @@ class Spawn(object):
 self.before = ''
 self.after = ''
 self.timeout = None
+# 
http://stackoverflow.com/questions/7857352/python-regex-to-match-vt100-escape-sequences
+# Note that re.I doesn't seem to work with this regex (or perhaps the
+# version of Python in Ubuntu 14.04), hence the inclusion of a-z inside
+# [] instead.
+self.re_vt100 = 
re.compile('(\x1b\[|\x9b)[^@-_a-z]*[@-_a-z]|\x1b[@-_a-z]')
 
 (self.pid, self.fd) = pty.fork()
 if self.pid == 0:
@@ -168,6 +173,10 @@ class Spawn(object):
 if self.logfile_read:
 self.logfile_read.write(c)
 self.buf += c
+# count=0 is supposed to be the default, which indicates
+# unlimited substitutions, but in practice the version of
+# Python in Ubuntu 14.04 appears to default to count=2!
+self.buf = self.re_vt100.sub('', self.buf, count=100)
 finally:
 if self.logfile_read:
 self.logfile_read.flush()
-- 
2.9.0

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

[U-Boot] Pull request: u-boot-net.git master

[Joe Hershberger]

Hi Tom,

A few small last minute compile fixes and a phy support addition.

The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:

  Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)

are available in the git repository at:


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

for you to fetch changes up to 4c64c4db3b87818318ed8b4cd6907c508aaf04ce:

  net: rtl8169: Fix return value for rtl_send_common (2016-07-06 10:45:11 -0500)


Alexey Brodkin (1):
  net: designware: Make driver independent from DM_GPIO again

Joe Hershberger (1):
  common: Always include errno.h in common.h

Mingkai Hu (1):
  driver: net: phylib: add support for aquantia AQR106/107 PHY

Oleksandr Tymoshenko (1):
  net: rtl8169: Fix return value for rtl_send_common

Ralf Hubert (1):
  net: Fix incorrect RPC packets on 64-bit systems

 drivers/net/designware.c   | 10 --
 drivers/net/designware.h   |  7 ++-
 drivers/net/phy/aquantia.c | 28 
 drivers/net/rtl8169.c  |  4 ++--
 include/common.h   |  1 +
 net/nfs.c  | 12 ++--
 6 files changed, 51 insertions(+), 11 deletions(-)

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

Re: [U-Boot] [PATCH] net: designware: Make driver independent from DM_GPIO again

[Joe Hershberger]

On Mon, Jun 27, 2016 at 5:17 AM, Alexey Brodkin
 wrote:
> Commit 90b7fc924adf "net: designware: support phy reset device-tree
> bindings" made DW GMAC driver dependent on DM_GPIO by unconditional
> usage of purely DM_GPIO stuff like:
>  * dm_gpio_XXX()
>  * gpio_request_by_name()
>
> But since that driver as of today might be easily used without
> DM_GPIO (that's the case for Synopsys AXS10x boards) we're
> shielding all DM_GPIO things by ifdefs.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Simon Glass 
> Cc: Beniamino Galvani 
> Cc: Joe Hershberger 
> Cc: Sjoerd Simons 
> Cc: Sonic Zhang 
> Cc: Bin Meng 
> Cc: Marek Vasut 

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

Re: [U-Boot] [PATCH] net: smsc95xx: Use correct get_unaligned functions

[Joe Hershberger]

Hi Mark,

On Mon, Jun 13, 2016 at 3:59 PM, Chris Packham  wrote:
> On Mon, Jun 13, 2016 at 8:01 PM, Chris Packham  
> wrote:
>> Hi Mark,
>>
>> On Mon, Jun 13, 2016 at 5:00 PM, Mark Tomlinson
>>  wrote:
>>> The __get_unaligned_le* functions may not be declared on all platforms.
>>> Instead, get_unaligned_le* should be used. On many platforms both of
>>> these are the same function.
>>>
>>> Change-Id: If28222615e85a6f34f3fde42eb21c6f56a2cb988
>>
>> We shouldn't let these leak out of $work. This doesn't really mean
>> anything to anyone without access to our internal review system.
>>
>>> Reviewed-by: Chris Packham 
>>
>> For what it's worth - this is me I usually post with my gmail account
>> because it's better for managing high volume mailing lists.
>
> Also your signed-off line is missing.

Can I expect a v2?

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

Re: [U-Boot] [PATCH] net: rtl8169: Fix return value for rtl_send_common

[Joe Hershberger]

On Fri, Jul 1, 2016 at 3:22 PM, Oleksandr Tymoshenko  wrote:
> Return value of rtl_send_common propogates unmodified all the way
> up to eth_send and further to API consumer if CONFIG_API is enabled.
> Previously rtl_send_common returned number of bytes sent on success
> which was erroneouly detected as error condition by API consumers
> that checked for operation success by comparing return value with 0.
>
> Switch rtl_send_common to use common convention: return 0 on success
> and negative value for failure.
>
> Cc: Stephen Warren 
> Cc: Joe Hershberger 
> Signed-off-by: Oleksandr Tymoshenko 

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

Re: [U-Boot] [PATCH] driver/net/fec: support fixed speed connection

[Joe Hershberger]

On Wed, Jun 22, 2016 at 5:07 AM, Hannes Schmelzer  wrote:
> If MAC is directly connected to another MAC (like a switch for example)
> we don't need to probe for a phy, autoneogation and so on. We simply
> have to setup speed.
>
> Signed-off-by: Hannes Schmelzer 

You may want to add it to Kconfig, but that's up to Stefano.

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

Re: [U-Boot] [PATCH] net: Fix incorrect RPC packets on 64-bit systems

[Joe Hershberger]

On Fri, Jul 1, 2016 at 6:19 AM, Ralf Hubert  wrote:
> This patch fixes incorrect RPC packet layout caused by
> 'long' type size difference on 64 and 32-bit architectures.
>
> Signed-off-by: Ralf Hubert 

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

Re: [U-Boot] [Patch v2] driver: net: phylib: add support for aquantia AQR106/107 PHY

[Joe Hershberger]

On Fri, Jul 1, 2016 at 6:03 AM, Gong Qianyu  wrote:
> From: Mingkai Hu 
>
> This patch adds support for aquantia AQR106/107 PHY.
>
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Gong Qianyu 

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

Re: [U-Boot] [PATCH 02/14] mkimage: Explain the auto-fit imagefile special case

[Joe Hershberger]

On Thu, Jun 30, 2016 at 11:52 AM, Simon Glass  wrote:
> There is a special case in the code when auto-fit is used. Add a comment to
> make it easier to understand why this is needed.
>
> Signed-off-by: Simon Glass 

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

[U-Boot] [PATCH] test/py: fix CONFIG_ tests

[Stephen Warren]

From: Stephen Warren 

Some CONFIG_ variables were recently renamed, but test/py wasn't updated
to match. This causes some tests to be skipped. Fix test/py so the tests
are run.

Fixes: 11636258981a ("Rename reset to sysreset")
Fixes: f1f9d4fac527 ("hush: complete renaming CONFIG_SYS_HUSH_PARSER to 
CONFIG_HUSH_PARSER")
Cc: Masahiro Yamada 
Signed-off-by: Stephen Warren 
---
 test/py/tests/test_hush_if_test.py | 8 
 test/py/tests/test_sandbox_exit.py | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/test/py/tests/test_hush_if_test.py 
b/test/py/tests/test_hush_if_test.py
index 1eeaa5b0471a..b572538528e1 100644
--- a/test/py/tests/test_hush_if_test.py
+++ b/test/py/tests/test_hush_if_test.py
@@ -109,27 +109,27 @@ def exec_hush_if(u_boot_console, expr, result):
 response = u_boot_console.run_command(cmd)
 assert response.strip() == str(result).lower()
 
-@pytest.mark.buildconfigspec('sys_hush_parser')
+@pytest.mark.buildconfigspec('hush_parser')
 def test_hush_if_test_setup(u_boot_console):
 """Set up environment variables used during the "if" tests."""
 
 u_boot_console.run_command('setenv ut_var_nonexistent')
 u_boot_console.run_command('setenv ut_var_exists 1')
 
-@pytest.mark.buildconfigspec('sys_hush_parser')
+@pytest.mark.buildconfigspec('hush_parser')
 @pytest.mark.parametrize('expr,result', subtests)
 def test_hush_if_test(u_boot_console, expr, result):
 """Test a single "if test" condition."""
 
 exec_hush_if(u_boot_console, expr, result)
 
-@pytest.mark.buildconfigspec('sys_hush_parser')
+@pytest.mark.buildconfigspec('hush_parser')
 def test_hush_if_test_teardown(u_boot_console):
 """Clean up environment variables used during the "if" tests."""
 
 u_boot_console.run_command('setenv ut_var_exists')
 
-@pytest.mark.buildconfigspec('sys_hush_parser')
+@pytest.mark.buildconfigspec('hush_parser')
 # We might test this on real filesystems via UMS, DFU, 'save', etc.
 # Of those, only UMS currently allows file removal though.
 @pytest.mark.boardspec('sandbox')
diff --git a/test/py/tests/test_sandbox_exit.py 
b/test/py/tests/test_sandbox_exit.py
index d1aa3083f458..4e333ecedbf8 100644
--- a/test/py/tests/test_sandbox_exit.py
+++ b/test/py/tests/test_sandbox_exit.py
@@ -7,7 +7,7 @@ import pytest
 import signal
 
 @pytest.mark.boardspec('sandbox')
-@pytest.mark.buildconfigspec('reset')
+@pytest.mark.buildconfigspec('sysreset')
 def test_reset(u_boot_console):
 """Test that the "reset" command exits sandbox process."""
 
-- 
2.9.0

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

Re: [U-Boot] [PATCH] test/py: support 'memstart =' in u_boot_utils.find_ram_base()

[Daniel Schwierzeck]

Am 06.07.2016 um 16:37 schrieb Stephen Warren:
> On 07/06/2016 04:44 AM, Daniel Schwierzeck wrote:
>> Some archs like MIPS or PPC have a different 'bdinfo' output
>> than ARM regarding the memory configuration. Also support
>> 'memstart = 0x*' in u_boot_utils.find_ram_base() to make
>> all tests requiring the RAM base working on those archs.
> 
> Acked-by: Stephen Warren 
> 
> ... although wouldn't it be better to fix the bdinfo command so that it
> printed the same thing on all architectures?

yes, but bdinfo isn't the only one affected. Currently we have two variants in 
"struct bd_info" of how to store the memory configuration:

- bi_memstart and bi_memsize
- struct bi_dram[CONFIG_NR_DRAM_BANKS] if a board or arch defines 
CONFIG_NR_DRAM_BANKS

Maybe we could unify this one day. But this requires changes to other commands 
and generic board init. Until then test/py should support both variants.

-- 
- Daniel



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

Re: [U-Boot] [PATCH] test/py: support 'memstart =' in u_boot_utils.find_ram_base()

[Stephen Warren]

On 07/06/2016 04:44 AM, Daniel Schwierzeck wrote:

Some archs like MIPS or PPC have a different 'bdinfo' output
than ARM regarding the memory configuration. Also support
'memstart = 0x*' in u_boot_utils.find_ram_base() to make
all tests requiring the RAM base working on those archs.


Acked-by: Stephen Warren 

... although wouldn't it be better to fix the bdinfo command so that it 
printed the same thing on all architectures?

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

Re: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys

[Heiko Stuebner]

Am Mittwoch, 6. Juli 2016, 14:48:57 schrieb Heiko Stuebner:
> Am Mittwoch, 6. Juli 2016, 18:20:04 schrieb Ziyuan Xu:
> > Hi heiko,
> > 
> > On 2016年07月06日 17:34, Ziyuan Xu wrote:
> > > From: Xu Ziyuan 
> > > 
> > > So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and
> > > Innosilicon. This patch applys dwc2 usb driver framework to implement
> > > phy_init and phy_off for Synopsys phy on Rockchip platform.
> > > 
> > > Signed-off-by: Ziyuan Xu 
> > > 
> > > ---
> > > 
> > > Changes in v3:
> > > - Make UOC_CON registers to be unfixed which should be got from DT
> > > 
> > > Changes in v2:
> > > - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
> > > - Rework the behaviour in otg_phy_init() and otg_phy_off()
> > > 
> > >   drivers/usb/phy/Makefile|  1 +
> > >   drivers/usb/phy/rockchip_usb_syno_phy.c | 47
> > >   + 2 files changed, 48 insertions(+)
> > >   create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c
> > > 
> > > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> > > index 93d147e..8002a18 100644
> > > --- a/drivers/usb/phy/Makefile
> > > +++ b/drivers/usb/phy/Makefile
> > > @@ -7,3 +7,4 @@
> > > 
> > >   obj-$(CONFIG_TWL4030_USB) += twl4030.o
> > >   obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o
> > > 
> > > +obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o
> > > diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c
> > > b/drivers/usb/phy/rockchip_usb_syno_phy.c new file mode 100644
> > > index 000..ab049e1
> > > --- /dev/null
> > > +++ b/drivers/usb/phy/rockchip_usb_syno_phy.c
> > > @@ -0,0 +1,47 @@
> > > +/*
> > > + * Copyright 2016 Rockchip Electronics Co., Ltd
> > > + *
> > > + * SPDX-License-Identifier:GPL-2.0+
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#include "../gadget/dwc2_udc_otg_priv.h"
> > > +
> > > +#define UOC_CON(x)   ((x) * 0x4)
> > 
> > As you know, dwc2 usb driver didn't apply devicetree model. It's hard to
> > implement a compatible driver for Rockchip SoCs which use a same udc.
> 
> Yeah, it is pretty strange that the dwc2 host part in uboot uses the
> devicetree while the gadget part does not - but I maybe someone else can
> answer this, as my contact with uboot was limited until now.
> The dwc2 host driver works just fine on my rk3036 kylin board.
> 
> > For example,
> > SOFT_CTRL bit is  UOC_CON2[2] on RK3288
> > I can't assure it's also UOC_CON[2] on other socs.
> > Do you have any good ideas?
> 
> Operating under the current constraints, I guess you could simply do
> something similar to what socfpga does in its board file.
> 
> Aka get the usb controller node, read the phy phandle and get the phy
> compatible string from the dts. The usbphys each have per-soc compatible
> values "rockchip,rk3288-usbphy" etc, so you can determine the needed bits
> over that.

forgot to add, with this same mechanism you could also resolve the fifo 
length from the devicetree into the platdata struct instead of hard-coding 
it with an ARCH_ROCKCHIP define.


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

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Wolfgang Denk]

Dear Robert,

In message  you 
wrote:
> 
>   is there a way to tell whether you're getting the current
> environment from the persistent copy or from the default environment?
> i'm not sure i have a pressing need for that, i'm just curious.

Programmatically? No.

>From the console output it is trivial - you will see 

Warning: Bad CRC, using default environment


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
For every problem there is one solution which is  simple,  neat,  and
wrong.- H. L. Mencken
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys

[Heiko Stuebner]

Am Mittwoch, 6. Juli 2016, 18:20:04 schrieb Ziyuan Xu:
> Hi heiko,
> 
> On 2016年07月06日 17:34, Ziyuan Xu wrote:
> > From: Xu Ziyuan 
> > 
> > So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and
> > Innosilicon. This patch applys dwc2 usb driver framework to implement
> > phy_init and phy_off for Synopsys phy on Rockchip platform.
> > 
> > Signed-off-by: Ziyuan Xu 
> > 
> > ---
> > 
> > Changes in v3:
> > - Make UOC_CON registers to be unfixed which should be got from DT
> > 
> > Changes in v2:
> > - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
> > - Rework the behaviour in otg_phy_init() and otg_phy_off()
> > 
> >   drivers/usb/phy/Makefile|  1 +
> >   drivers/usb/phy/rockchip_usb_syno_phy.c | 47
> >   + 2 files changed, 48 insertions(+)
> >   create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c
> > 
> > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> > index 93d147e..8002a18 100644
> > --- a/drivers/usb/phy/Makefile
> > +++ b/drivers/usb/phy/Makefile
> > @@ -7,3 +7,4 @@
> > 
> >   obj-$(CONFIG_TWL4030_USB) += twl4030.o
> >   obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o
> > 
> > +obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o
> > diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c
> > b/drivers/usb/phy/rockchip_usb_syno_phy.c new file mode 100644
> > index 000..ab049e1
> > --- /dev/null
> > +++ b/drivers/usb/phy/rockchip_usb_syno_phy.c
> > @@ -0,0 +1,47 @@
> > +/*
> > + * Copyright 2016 Rockchip Electronics Co., Ltd
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include "../gadget/dwc2_udc_otg_priv.h"
> > +
> > +#define UOC_CON(x) ((x) * 0x4)
> 
> As you know, dwc2 usb driver didn't apply devicetree model. It's hard to
> implement a compatible driver for Rockchip SoCs which use a same udc.

Yeah, it is pretty strange that the dwc2 host part in uboot uses the 
devicetree while the gadget part does not - but I maybe someone else can 
answer this, as my contact with uboot was limited until now.
The dwc2 host driver works just fine on my rk3036 kylin board.


> For example,
> SOFT_CTRL bit is  UOC_CON2[2] on RK3288
> I can't assure it's also UOC_CON[2] on other socs.
> Do you have any good ideas?

Operating under the current constraints, I guess you could simply do 
something similar to what socfpga does in its board file.

Aka get the usb controller node, read the phy phandle and get the phy 
compatible string from the dts. The usbphys each have per-soc compatible 
values "rockchip,rk3288-usbphy" etc, so you can determine the needed bits 
over that.


Heiko

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

[U-Boot] [U-BOOT][PATCH v2] net:Add EMAC driver for H3/A83T/A64 SoCs.

[Amit Singh Tomar]

This patch add EMAC driver support for H3/A83T/A64 SoCs.
Tested on Pine64(A64-External PHY) and Orangepipc(H3-Internal PHY).

BIG Thanks to Andre for providing some of the DT code.

Signed-off-by: Amit Singh Tomar 
---
Changes since v1:
* Addressed LABBE's comments.
* Made it compatible with External PHY.
---
 arch/arm/dts/sun50i-a64-pine64-plus.dts   |   13 +
 arch/arm/dts/sun50i-a64.dtsi  |   33 ++
 arch/arm/dts/sun8i-h3-orangepi-2.dts  |   13 +
 arch/arm/dts/sun8i-h3-orangepi-pc.dts |   12 +
 arch/arm/dts/sun8i-h3.dtsi|   25 +
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h |4 +-
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |3 +-
 configs/orangepi_pc_defconfig |1 +
 configs/pine64_plus_defconfig |1 +
 drivers/net/Kconfig   |9 +
 drivers/net/Makefile  |1 +
 drivers/net/sun8i_emac.c  |  789 +
 12 files changed, 902 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/sun8i_emac.c

diff --git a/arch/arm/dts/sun50i-a64-pine64-plus.dts 
b/arch/arm/dts/sun50i-a64-pine64-plus.dts
index 549dc15..389c609 100644
--- a/arch/arm/dts/sun50i-a64-pine64-plus.dts
+++ b/arch/arm/dts/sun50i-a64-pine64-plus.dts
@@ -57,3 +57,16 @@
reg = <0x4000 0x4000>;
};
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   phy-mode = "rgmii";
+   phy = <>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
diff --git a/arch/arm/dts/sun50i-a64.dtsi b/arch/arm/dts/sun50i-a64.dtsi
index 1bd436f..7d0dc76 100644
--- a/arch/arm/dts/sun50i-a64.dtsi
+++ b/arch/arm/dts/sun50i-a64.dtsi
@@ -506,6 +506,25 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   rmii_pins: rmii_pins {
+   allwinner,pins = "PD10", "PD11", "PD13", "PD14",
+"PD17", "PD18", "PD19", "PD20",
+"PD22", "PD23";
+   allwinner,function = "emac";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   rgmii_pins: rgmii_pins {
+   allwinner,pins = "PD8", "PD9", "PD10", "PD11",
+"PD12", "PD13", "PD15",
+"PD16", "PD17", "PD18", "PD19",
+"PD20", "PD21", "PD22", "PD23";
+   allwinner,function = "emac";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};
 
ahb_rst: reset@1c202c0 {
@@ -620,5 +639,19 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+   emac: ethernet@01c3 {
+   compatible = "allwinner,sun50i-a64-emac";
+   reg = <0x01c3 0x2000>, <0x01c00030 0x4>;
+   reg-names = "emac", "syscon";
+   interrupts = ;
+   resets = <_rst 17>;
+   reset-names = "ahb";
+   clocks = <_gates 17>;
+   clock-names = "ahb";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 };
diff --git a/arch/arm/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/dts/sun8i-h3-orangepi-2.dts
index f93f5d1..d3f8f55 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-2.dts
@@ -184,3 +184,16 @@
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   phy-mode = "rgmii";
+   phy = <>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
diff --git a/arch/arm/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/dts/sun8i-h3-orangepi-pc.dts
index 30ccca0..0a74a91 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-pc.dts
@@ -173,3 +173,15 @@
/* USB VBUS is always on */
status = "okay";
 };
+
+ {
+   phy = <>;
+   phy-mode = "mii";
+   allwinner,use-internal-phy;
+   allwinner,leds-active-low;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
diff --git a/arch/arm/dts/sun8i-h3.dtsi b/arch/arm/dts/sun8i-h3.dtsi
index c2f63c5..6ca5e34 100644
--- a/arch/arm/dts/sun8i-h3.dtsi
+++ 

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Robert P. J. Day]

On Wed, 6 Jul 2016, Wolfgang Denk wrote:

> Dear Robert,
>
> In message  you 
> wrote:
> >
> >   not to be overly pedantic (too late!), but is there a preferred
> > expression for the environment stored at CONFIG_ENV_ADDR? is it
> > "permanent environment" or "saved environment" or what?
>
> I tend to call it the "persistent copy" of the environment (resp.
> copies in case of redundant environment), in contrast to the in
> memory copy of it.  Upon start, the memory copy gets initialized
> from the persistent one, unless this turns out to be corrupt (or
> uninitialized, the effect is the same), in which case the builtin
> default environment is used to initialize the in memory copy.

  is there a way to tell whether you're getting the current
environment from the persistent copy or from the default environment?
i'm not sure i have a pressing need for that, i'm just curious.

rday

-- 


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

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


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

[U-Boot] "(ulong)_environment[0]" vs "(ulong)default_environment"?

[Robert P. J. Day]

  more pedantry ... as i was crawling through the env code, i noticed
the common usage of "(ulong)_environment[0]" rather than what
i thought was the more standard expression
"(ulong)default_environment" to find the address of that array, so i
did a quick grep:

$ grep -r "gd->env_addr.*default_environment" *
board/freescale/ls1043ardb/ls1043ardb.c:gd->env_addr = 
(ulong)_environment[0];
board/freescale/ls2080ardb/ls2080ardb.c:gd->env_addr = 
(ulong)_environment[0];
board/freescale/ls2080a/ls2080a.c:  gd->env_addr = 
(ulong)_environment[0];
board/freescale/ls1043aqds/ls1043aqds.c:gd->env_addr = 
(ulong)_environment[0];
board/freescale/ls2080aqds/ls2080aqds.c:gd->env_addr = 
(ulong)_environment[0];
common/env_onenand.c:   gd->env_addr = (ulong)_environment[0];
common/env_sf.c:gd->env_addr = (ulong)_environment[0];
common/env_dataflash.c: gd->env_addr = (ulong)_environment[0];
common/env_nowhere.c:   gd->env_addr= (ulong)_environment[0];
common/env_nvram.c: gd->env_addr= 
(ulong)_environment[0];
common/env_fat.c:   gd->env_addr = (ulong)_environment[0];
common/env_mmc.c:   gd->env_addr= (ulong)_environment[0];
common/env_flash.c: gd->env_addr= (ulong)_environment[0];
common/env_remote.c:gd->env_addr = (ulong)default_environment;
<-
common/env_eeprom.c:gd->env_addr = (ulong)_environment[0];
common/env_nand.c:  gd->env_addr= (ulong)_environment[0];
common/env_ubi.c:   gd->env_addr = (ulong)_environment[0];
$

  so everyone seems to be using one form of that calculation, except
for that lonely expression in common/env_remote.c. :-( it all works,
of course, it's just inconsistent.

rday

-- 


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

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


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

[U-Boot] in Kbuild, what is the difference between "extra-" and "obj-"?

[Robert P. J. Day]

  admittedly, this is more a kernel Kbuild question, but in
common/Makefile, i see the snippet:

extra-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
obj-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o
extra-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o

what is the functional difference between using "extra-" and "obj-" in
the above? those three lines look ... inconsistent?

  anyway, what is going on there? thanks.

rday

-- 


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

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


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

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Robert P. J. Day]

On Wed, 6 Jul 2016, Wolfgang Denk wrote:

> Dear Robert,
>
> In message  you 
> wrote:
> >
> >   not to be overly pedantic (too late!), but is there a preferred
> > expression for the environment stored at CONFIG_ENV_ADDR? is it
> > "permanent environment" or "saved environment" or what?
>
> I tend to call it the "persistent copy" of the environment (resp.
> copies in case of redundant environment), in contrast to the in
> memory copy of it.  Upon start, the memory copy gets initialized
> from the persistent one, unless this turns out to be corrupt (or
> uninitialized, the effect is the same), in which case the builtin
> default environment is used to initialize the in memory copy.

  ok, i'm good with that, thanks.

rday

-- 


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

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


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

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Wolfgang Denk]

Dear Robert,

In message  you 
wrote:
> 
>   not to be overly pedantic (too late!), but is there a preferred
> expression for the environment stored at CONFIG_ENV_ADDR? is it
> "permanent environment" or "saved environment" or what?

I tend to call it the "persistent copy" of the environment (resp.
copies in case of redundant environment), in contrast to the in memory
copy of it.  Upon start, the memory copy gets initialized from the
persistent one, unless this turns out to be corrupt (or uninitialized,
the effect is the same), in which case the builtin default environment
is used to initialize the in memory copy.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Sex is like air.  It's only a big deal if you can't get any.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] test/py: support 'memstart =' in u_boot_utils.find_ram_base()

[Daniel Schwierzeck]

Some archs like MIPS or PPC have a different 'bdinfo' output
than ARM regarding the memory configuration. Also support
'memstart = 0x*' in u_boot_utils.find_ram_base() to make
all tests requiring the RAM base working on those archs.

Signed-off-by: Daniel Schwierzeck 

---

 test/py/u_boot_utils.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/py/u_boot_utils.py b/test/py/u_boot_utils.py
index 6a6b2ec..e4765e3 100644
--- a/test/py/u_boot_utils.py
+++ b/test/py/u_boot_utils.py
@@ -201,7 +201,7 @@ def find_ram_base(u_boot_console):
 with u_boot_console.log.section('find_ram_base'):
 response = u_boot_console.run_command('bdinfo')
 for l in response.split('\n'):
-if '-> start' in l:
+if '-> start' in l or 'memstart=' in l:
 ram_base = int(l.split('=')[1].strip(), 16)
 break
 if ram_base is None:
-- 
2.9.0

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

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Robert P. J. Day]

On Wed, 6 Jul 2016, Måns Rullgård wrote:

> "Robert P. J. Day"  writes:
>
> > On Wed, 6 Jul 2016, Måns Rullgård wrote:
> >
> >> "Robert P. J. Day"  writes:
> >
> >> > p.s. how does the default environment get to the
> >> > CONFIG_ENV_ADDR defined in the board header file? is that done
> >> > automatically when u-boot starts to run and notices that there
> >> > is no valid environment info at that address, and therefore
> >> > copies it for you?
> >>
> >> If the stored environment is invalid (e.g. uninitialised), the
> >> built-in default is used.  Nothing is written until you issue a
> >> saveenv command. This saves a copy of the live environment to the
> >> configured location.
> >
> >   ah, that's the final bit of the puzzle i was looking for ... the
> > first time a "saveenv" is done is when the configured location is
> > examined and, if uninitialized, the env is copied there and is
> > used from then on.
>
> saveenv always writes whatever is in memory to the permanent location,

  and by "permanent location", you mean CONFIG_ENV_ADDR as defined in
the board definition file, yes?

> overwriting anything that was previously there.  On startup, u-boot
> checks if the saved environment is valid and uses it if it is.  If

  and, again, by "saved environment", i assume you mean what is at
CONFIG_ENV_ADDR. it's all a matter of terminology -- switching back
and forth can make things confusing.

  not to be overly pedantic (too late!), but is there a preferred
expression for the environment stored at CONFIG_ENV_ADDR? is it
"permanent environment" or "saved environment" or what?

> not, the defaults (as configured for the board) are used.  Only the
> saveenv command writes anything to nonvolatile storage.

  ok, i think i have a handle on this now, thanks.

rday

-- 


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

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

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

[U-Boot] [PATCH] ARM: dts: uniphier: renumber serial aliases for Gentil/Vodka boards

[Masahiro Yamada]

On these two boards, the serial0 is used for inter-chip connection,
so cannot be used for login console.  The serial2 is used instead
for them, but it is tedious to use because upper level deployment
projects must switch login console per board.

[ Linux commit: 2a4a2aadbaad9dffdb564a2895348f3d8e825416 ]

Signed-off-by: Masahiro Yamada 
Signed-off-by: Olof Johansson 
---

 arch/arm/dts/uniphier-proxstream2-gentil.dts | 8 
 arch/arm/dts/uniphier-proxstream2-vodka.dts  | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/uniphier-proxstream2-gentil.dts 
b/arch/arm/dts/uniphier-proxstream2-gentil.dts
index 61f6164..1175703 100644
--- a/arch/arm/dts/uniphier-proxstream2-gentil.dts
+++ b/arch/arm/dts/uniphier-proxstream2-gentil.dts
@@ -19,13 +19,13 @@
};
 
chosen {
-   stdout-path = "serial2:115200n8";
+   stdout-path = "serial0:115200n8";
};
 
aliases {
-   serial0 = 
-   serial1 = 
-   serial2 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
i2c0 = 
i2c2 = 
i2c4 = 
diff --git a/arch/arm/dts/uniphier-proxstream2-vodka.dts 
b/arch/arm/dts/uniphier-proxstream2-vodka.dts
index 3d5b300..928a092 100644
--- a/arch/arm/dts/uniphier-proxstream2-vodka.dts
+++ b/arch/arm/dts/uniphier-proxstream2-vodka.dts
@@ -19,13 +19,13 @@
};
 
chosen {
-   stdout-path = "serial2:115200n8";
+   stdout-path = "serial0:115200n8";
};
 
aliases {
-   serial0 = 
-   serial1 = 
-   serial2 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
i2c0 = 
i2c4 = 
i2c5 = 
-- 
1.9.1

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

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Måns Rullgård]

"Robert P. J. Day"  writes:

> On Wed, 6 Jul 2016, Måns Rullgård wrote:
>
>> "Robert P. J. Day"  writes:
>
>> > p.s. how does the default environment get to the CONFIG_ENV_ADDR
>> > defined in the board header file? is that done automatically when
>> > u-boot starts to run and notices that there is no valid
>> > environment info at that address, and therefore copies it for you?
>>
>> If the stored environment is invalid (e.g. uninitialised), the
>> built-in default is used.  Nothing is written until you issue a
>> saveenv command. This saves a copy of the live environment to the
>> configured location.
>
>   ah, that's the final bit of the puzzle i was looking for ... the
> first time a "saveenv" is done is when the configured location is
> examined and, if uninitialized, the env is copied there and is used
> from then on.

saveenv always writes whatever is in memory to the permanent location,
overwriting anything that was previously there.  On startup, u-boot
checks if the saved environment is valid and uses it if it is.  If not,
the defaults (as configured for the board) are used.  Only the saveenv
command writes anything to nonvolatile storage.

-- 
Måns Rullgård
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys

[Ziyuan Xu]

Hi heiko,

On 2016年07月06日 17:34, Ziyuan Xu wrote:

From: Xu Ziyuan 

So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and
Innosilicon. This patch applys dwc2 usb driver framework to implement
phy_init and phy_off for Synopsys phy on Rockchip platform.

Signed-off-by: Ziyuan Xu 

---

Changes in v3:
- Make UOC_CON registers to be unfixed which should be got from DT

Changes in v2:
- Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
- Rework the behaviour in otg_phy_init() and otg_phy_off()

  drivers/usb/phy/Makefile|  1 +
  drivers/usb/phy/rockchip_usb_syno_phy.c | 47 +
  2 files changed, 48 insertions(+)
  create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c

diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 93d147e..8002a18 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -7,3 +7,4 @@
  
  obj-$(CONFIG_TWL4030_USB) += twl4030.o

  obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o
+obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o
diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c 
b/drivers/usb/phy/rockchip_usb_syno_phy.c
new file mode 100644
index 000..ab049e1
--- /dev/null
+++ b/drivers/usb/phy/rockchip_usb_syno_phy.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+#include "../gadget/dwc2_udc_otg_priv.h"
+
+#define UOC_CON(x) ((x) * 0x4)
As you know, dwc2 usb driver didn't apply devicetree model. It's hard to 
implement a compatible driver for Rockchip SoCs which use a same udc.

For example,
SOFT_CTRL bit is  UOC_CON2[2] on RK3288
I can't assure it's also UOC_CON[2] on other socs.
Do you have any good ideas?

+
+#define RESET_WRITE_ENABIT(28)
+#define PORT_RESET BIT(12)
+#define PORT_NORMAL(0 << 12)
+
+#define SOFT_CTRL_WRITE_ENABIT(18)
+#define SOFT_CTRL_ENABLE   BIT(2)
+
+#define SUSPEND_SETTING0x2A
+#define SUSPEND_WRITE_ENA  (0x3f << 16)
+
+
+void otg_phy_init(struct dwc2_udc *dev)
+{
+   /* disable software control */
+   writel(SOFT_CTRL_WRITE_ENA | (0 << 2),
+  dev->pdata->regs_phy + UOC_CON(2));
+   /* reset otg port */
+   writel(RESET_WRITE_ENA | PORT_RESET,
+  dev->pdata->regs_phy + UOC_CON(0));
+   mdelay(1);
+   writel(RESET_WRITE_ENA | PORT_NORMAL,
+  dev->pdata->regs_phy + UOC_CON(0));
+   udelay(1);
+}
+
+void otg_phy_off(struct dwc2_udc *dev)
+{
+   /* enable software control */
+   writel(SOFT_CTRL_WRITE_ENA | SOFT_CTRL_ENABLE,
+  dev->pdata->regs_phy + UOC_CON(2));
+   /* enter suspend */
+   writel(SUSPEND_WRITE_ENA | SUSPEND_SETTING,
+  dev->pdata->regs_phy + UOC_CON(3));
+}



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

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Måns Rullgård]

"Robert P. J. Day"  writes:

>   oh, wait, i think i just answered some of my questions based on this
> snippet from common/env_nvram.c:
>
> /*
>  * Initialize Environment use
>  *
>  * We are still running from ROM, so data use is limited
>  */
> int env_init(void)
> {
> #if defined(CONFIG_SYS_NVRAM_ACCESS_ROUTINE)
> ulong crc;
> uchar data[ENV_SIZE];
>
> nvram_read(, CONFIG_ENV_ADDR, sizeof(ulong));
> nvram_read(data, CONFIG_ENV_ADDR + sizeof(ulong), ENV_SIZE);
>
> if (crc32(0, data, ENV_SIZE) == crc) {
> gd->env_addr= (ulong)CONFIG_ENV_ADDR + sizeof(long);
> #else
> if (crc32(0, env_ptr->data, ENV_SIZE) == env_ptr->crc) {
> gd->env_addr= (ulong)_ptr->data;
> #endif
> gd->env_valid   = 1;
> } else {
> gd->env_addr= (ulong)_environment[0];
> gd->env_valid   = 0;
> }
>
> return 0;
> }
>
>   so if there is a valid environment at the address specified by the
> board header file, it's used, otherwise fall back to
> default_environment[]. i had suspected it was something like that, i
> just hadn't found the code yet.
>
>   is this written up somewhere?

Looks like you found your answer, at least in part.  The environment is
stored in one of many possible locations, see the various env_*.c files.
Which one is used is determined by the board configuration.

> p.s. how does the default environment get to the CONFIG_ENV_ADDR
> defined in the board header file? is that done automatically when
> u-boot starts to run and notices that there is no valid environment
> info at that address, and therefore copies it for you?

If the stored environment is invalid (e.g. uninitialised), the built-in
default is used.  Nothing is written until you issue a saveenv command.
This saves a copy of the live environment to the configured location.

-- 
Måns Rullgård
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Robert P. J. Day]

On Wed, 6 Jul 2016, Måns Rullgård wrote:

> "Robert P. J. Day"  writes:

> > p.s. how does the default environment get to the CONFIG_ENV_ADDR
> > defined in the board header file? is that done automatically when
> > u-boot starts to run and notices that there is no valid
> > environment info at that address, and therefore copies it for you?
>
> If the stored environment is invalid (e.g. uninitialised), the
> built-in default is used.  Nothing is written until you issue a
> saveenv command. This saves a copy of the live environment to the
> configured location.

  ah, that's the final bit of the puzzle i was looking for ... the
first time a "saveenv" is done is when the configured location is
examined and, if uninitialized, the env is copied there and is used
from then on.

  and it would appear that the location of the "current" environment
is stored in "gd->env_addr", does that sound about right?

  i'm still going to write this up somewhere for future reference.

rday

-- 


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

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

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

Re: [U-Boot] where *precisely* is u-boot's environment stored?

[Robert P. J. Day]

  oh, wait, i think i just answered some of my questions based on this
snippet from common/env_nvram.c:

/*
 * Initialize Environment use
 *
 * We are still running from ROM, so data use is limited
 */
int env_init(void)
{
#if defined(CONFIG_SYS_NVRAM_ACCESS_ROUTINE)
ulong crc;
uchar data[ENV_SIZE];

nvram_read(, CONFIG_ENV_ADDR, sizeof(ulong));
nvram_read(data, CONFIG_ENV_ADDR + sizeof(ulong), ENV_SIZE);

if (crc32(0, data, ENV_SIZE) == crc) {
gd->env_addr= (ulong)CONFIG_ENV_ADDR + sizeof(long);
#else
if (crc32(0, env_ptr->data, ENV_SIZE) == env_ptr->crc) {
gd->env_addr= (ulong)_ptr->data;
#endif
gd->env_valid   = 1;
} else {
gd->env_addr= (ulong)_environment[0];
gd->env_valid   = 0;
}

return 0;
}


  so if there is a valid environment at the address specified by the
board header file, it's used, otherwise fall back to
default_environment[]. i had suspected it was something like that, i
just hadn't found the code yet.

  is this written up somewhere?

rday

p.s. how does the default environment get to the CONFIG_ENV_ADDR
defined in the board header file? is that done automatically when
u-boot starts to run and notices that there is no valid environment
info at that address, and therefore copies it for you?

  i will keep reading the source.

-- 


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

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


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

[U-Boot] where *precisely* is u-boot's environment stored?

[Robert P. J. Day]

  kind of embarrassed that i don't know the answer to this but, short
form of question, when i build a u-boot.bin and copy it to NOR flash
on my target board, where is the environment stored such that user
space fw_printenv and fw_setenv utilities can get at them?

  longer form of question: i just used yocto project to build for my
MPC8315E-RDB target board, and one of the artifacts generated was
"u-boot.bin", apparently ready for copying to NOR flash on this board,
NOR flash being at 0xfe00. i poked around trying to figure out
where the environment was stored in that image, and i found the
following in include/env_default.h:

  ... snip ...
  const uchar default_environment[] = {
  #endif
  #ifdef  CONFIG_ENV_CALLBACK_LIST_DEFAULT
ENV_CALLBACK_VAR "=" CONFIG_ENV_CALLBACK_LIST_DEFAULT "\0"
  #endif
  #ifdef  CONFIG_ENV_FLAGS_LIST_DEFAULT
ENV_FLAGS_VAR "=" CONFIG_ENV_FLAGS_LIST_DEFAULT "\0"
  #endif
  #ifdef  CONFIG_BOOTARGS
"bootargs=" CONFIG_BOOTARGS "\0"
  #endif
  #ifdef  CONFIG_BOOTCOMMAND
"bootcmd="  CONFIG_BOOTCOMMAND  "\0"
  #endif
  ... etc etc ...

i then checked u-boot.sym and found:

  fe04c920 g O .text  0389 default_environment

and if i "hexdump -C" the "u-boot.bin" file, sure enough, there it is,
the apparent beginning of the default environment at 0x0004c920:

0004c900  8d ef 02 2d 25 2e 2a 73  00 00 00 00 25 73 25 64  |...-%.*s%s%d|
0004c910  2c 25 64 00 70 61 72 74  69 74 69 6f 6e 00 00 00  |,%d.partition...|
0004c920  62 6f 6f 74 63 6d 64 3d  73 65 74 65 6e 76 20 62  |bootcmd=setenv b|
0004c930  6f 6f 74 61 72 67 73 20  72 6f 6f 74 3d 2f 64 65  |ootargs root=/de|
0004c940  76 2f 6e 66 73 20 72 77  20 6e 66 73 72 6f 6f 74  |v/nfs rw nfsroot|
0004c950  3d 24 73 65 72 76 65 72  69 70 3a 24 72 6f 6f 74  |=$serverip:$root|
... and on and on ...

  so AFAICT, the default_environment[] ends up in the executable (and,
consequently, in flash) i'm assuming based on wherever the linker
places it based on the "u-boot.lds" file, correct?

  however, if i look at the defn file for this target board,
include/configs/MPC8315ERDB.h, i can see the various config settings
defining where the environment resides, things like
CONFIG_ENV_IS_IN_FLASH, CONFIG_ENV_ADDR and so on:

  #if !defined(CONFIG_SYS_RAMBOOT)
#define CONFIG_ENV_IS_IN_FLASH  1
#define CONFIG_ENV_ADDR \
(CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN)
#define CONFIG_ENV_SECT_SIZE0x1 /* 64K(one sector) for env */
#define CONFIG_ENV_SIZE 0x2000

and if i build the package u-boot-fw-utils to get the user space
utilities "fw_printenv" and "fw_setenv", that package needs to be told
where the environment is stored, and that's based on what it gets from
the board's header file, which in this case defines:

#define CONFIG_SYS_MONITOR_LEN  (384 * 1024) /* Reserve 384 kB for Mon */

which represents an env offset of 0x0006 into flash.

  so what is the correlation between those two addresses? there's the
actual address of default_environment[] based on where the linker puts
it (0xfe04c920), as opposed to where fw-utils will (apparently) look
for the environment (0xfe06). what's the connection here?

rday

-- 


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

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




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

[U-Boot] [PATCH v3 2/4] usb: dwc2-otg: re-define fifo-size for Rockchip SoCs

[Ziyuan Xu]

From: Xu Ziyuan 

The total FIFO size of dwc2 on Rockchip SoCs is shorter than the
existen, so re-define them to fit Rockchip SoCs.

Signed-off-by: Ziyuan Xu 

---

Changes in v3: None
Changes in v2:
- Update detailed commit message
- Modify the macro's values

 drivers/usb/gadget/dwc2_udc_otg_regs.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/gadget/dwc2_udc_otg_regs.h 
b/drivers/usb/gadget/dwc2_udc_otg_regs.h
index 78ec90e..6004a4b 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_regs.h
+++ b/drivers/usb/gadget/dwc2_udc_otg_regs.h
@@ -130,9 +130,15 @@ struct dwc2_usbotg_reg {
 #define HIGH_SPEED_CONTROL_PKT_SIZE64
 #define HIGH_SPEED_BULK_PKT_SIZE   512
 
+#ifdef CONFIG_ARCH_ROCKCHIP
+#define RX_FIFO_SIZE   (512*4)
+#define NPTX_FIFO_SIZE (16*4)
+#define PTX_FIFO_SIZE  (128*4)
+#else
 #define RX_FIFO_SIZE   (1024*4)
 #define NPTX_FIFO_SIZE (1024*4)
 #define PTX_FIFO_SIZE  (1536*1)
+#endif
 
 #define DEPCTL_TXFNUM_0(0x0<<22)
 #define DEPCTL_TXFNUM_1(0x1<<22)
-- 
1.9.1


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

[U-Boot] [PATCH v3 0/4] rockchip: rk3288: add fastboot support

[Ziyuan Xu]

This patchset add the fastboot support for rk3288, and I have tested on
firefly-rk3288 board.

Fix an issue which was mentioned in V1's cover-letter:
The DMA buffer was always zero after DMA transfer is complete, It takes
no effect that invalidate dcache after the DMA is complete and before
the CPU reads it. It's important to invalidate dcache before starting
DMA, ensure coherency and prevent from any dirty lines in the cache
which from the DMA buffer.

Summary of changes in this series:
- Achieve UOC_CON_OFFSET physical address from DT
- Make UOC_CON registers to be unfixed which should be got from DT
- Add new commit dd77b11fd44a84 (usb: dwc2: Invalidate dcache before
staring DMA)

Changes in v3:
- Make UOC_CON registers to be unfixed which should be got from DT
- Achieve UOC_CON_OFFSET physical address from DT
- New commit since v3 to fix the coherence issue between memory and
cache

Changes in v2:
- Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
- Rework the behaviour in otg_phy_init() and otg_phy_off()
- Update detailed commit message
- Modify the macro's values
- Achieve the regs_phy from DT
- Update comments a little

Xu Ziyuan (4):
  usb: rockchip-phy: implement USB2.0 phy control for Synopsys
  usb: dwc2-otg: re-define fifo-size for Rockchip SoCs
  rockchip: rk3288: add fastboot support
  usb: dwc2: invalidate dcache before starting DMA

 arch/arm/dts/rk3288.dtsi   |  1 +
 arch/arm/mach-rockchip/board.c | 60 ++
 drivers/usb/gadget/dwc2_udc_otg_regs.h |  6 +++
 drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c |  3 ++
 drivers/usb/phy/Makefile   |  1 +
 drivers/usb/phy/rockchip_usb_syno_phy.c| 47 +++
 include/configs/rk3288_common.h| 26 +
 7 files changed, 144 insertions(+)
 create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c

-- 
1.9.1


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

[U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA

[Ziyuan Xu]

From: Xu Ziyuan 

Invalidate dcache before starting the DMA to ensure coherency. In case
there are any dirty lines from the DMA buffer in the cache, subsequent
cache-line replacements may corrupt the buffer in memory while the DMA
is still going on. Cache-line replacement can happen if the CPU tries to
bring some other memory locations into the cache while the DMA is going
on.

Signed-off-by: Ziyuan Xu 
---

Changes in v3:
- New commit since v3 to fix the coherence issue between memory and
cache

Changes in v2: None

 drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c 
b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
index 12f5c85..0d6d2fb 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
@@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct 
dwc2_request *req)
 
ctrl =  readl(>out_endp[ep_num].doepctl);
 
+   invalidate_dcache_range((unsigned long) ep->dma_buf,
+   (unsigned long) ep->dma_buf + ep->len);
+
writel((unsigned int) ep->dma_buf, >out_endp[ep_num].doepdma);
writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
   >out_endp[ep_num].doeptsiz);
-- 
1.9.1


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

[U-Boot] [PATCH v3 3/4] rockchip: rk3288: add fastboot support

[Ziyuan Xu]

From: Xu Ziyuan 

Enable fastboot feature on rk3288.

This path doesn't support the fastboot flash function command entirely.
We will hit "cannot find partition" assertion without specified
partition environment. Define gpt partition layout in specified board
such as firefly-rk3288, then enjoy it!

Signed-off-by: Ziyuan Xu 

---

Changes in v3:
- Achieve UOC_CON_OFFSET physical address from DT

Changes in v2:
- Achieve the regs_phy from DT
- Update comments a little

 arch/arm/dts/rk3288.dtsi|  1 +
 arch/arm/mach-rockchip/board.c  | 60 +
 include/configs/rk3288_common.h | 26 ++
 3 files changed, 87 insertions(+)

diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi
index 3dab0fc..bcf051a 100644
--- a/arch/arm/dts/rk3288.dtsi
+++ b/arch/arm/dts/rk3288.dtsi
@@ -454,6 +454,7 @@
interrupts = ;
clocks = < HCLK_OTG0>;
clock-names = "otg";
+   dr_mode = "otg";
phys = <>;
phy-names = "usb2-phy";
status = "disabled";
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 816540e..56e3c31 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -52,6 +52,66 @@ void lowlevel_init(void)
 {
 }
 
+#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)
+#include 
+#include 
+
+static struct dwc2_plat_otg_data rk3288_otg_data;
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+   int offset;
+   const char *mode;
+   bool matched = false;
+   const void *blob = gd->fdt_blob;
+   u32 grf_phy_offset;
+
+   /* find the usb_otg node */
+   offset = fdt_node_offset_by_compatible(blob, -1,
+   "rockchip,rk3288-usb");
+
+   while (offset > 0) {
+   mode = fdt_getprop(blob, offset, "dr_mode", NULL);
+   if (mode && strcmp(mode, "otg") == 0) {
+   matched = true;
+   break;
+   }
+
+   offset = fdt_node_offset_by_compatible(blob, offset,
+   "rockchip,rk3288-usb");
+   }
+   if (!matched) {
+   debug("Not found usb_otg device\n");
+   return -ENODEV;
+   }
+   rk3288_otg_data.regs_otg = fdtdec_get_addr(blob, offset, "reg");
+
+   offset = fdtdec_lookup_phandle(blob, offset, "phys");
+   if (offset <= 0) {
+   debug("Not found usb phy device\n");
+   return -ENODEV;
+   }
+   grf_phy_offset = fdtdec_get_addr(blob, offset, "reg");
+
+   /* find the grf node */
+   offset = fdt_node_offset_by_compatible(blob, -1,
+   "rockchip,rk3288-grf");
+   if (offset <= 0) {
+   debug("Not found grf device\n");
+   return -ENODEV;
+   }
+   rk3288_otg_data.regs_phy = grf_phy_offset +
+   fdtdec_get_addr(blob, offset, "reg");
+
+   return dwc2_udc_probe(_otg_data);
+}
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+   return 0;
+}
+#endif
+
 static int do_clock(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[])
 {
diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index 9d50d83..94fd13f 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -80,6 +80,32 @@
 #define CONFIG_SPI
 #define CONFIG_SF_DEFAULT_SPEED 2000
 
+/* usb otg */
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_DWC2_OTG
+#define CONFIG_ROCKCHIP_USB_SYNO_PHY
+#define CONFIG_USB_GADGET_VBUS_DRAW0
+
+/* fastboot  */
+#define CONFIG_CMD_FASTBOOT
+#define CONFIG_USB_FUNCTION_FASTBOOT
+#define CONFIG_FASTBOOT_FLASH
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV  1   /* eMMC */
+/* stroe safely fastboot buffer data to the middle of bank */
+#define CONFIG_FASTBOOT_BUF_ADDR   (CONFIG_SYS_SDRAM_BASE \
+   + SDRAM_BANK_SIZE / 2)
+#define CONFIG_FASTBOOT_BUF_SIZE   0x0800
+
+#define CONFIG_USB_GADGET_DOWNLOAD
+#define CONFIG_G_DNL_MANUFACTURER  "Rockchip"
+#define CONFIG_G_DNL_VENDOR_NUM0x2207
+#define CONFIG_G_DNL_PRODUCT_NUM   0x320a
+
+/* Enable gpt partition table */
+#define CONFIG_CMD_GPT
+#define CONFIG_EFI_PARTITION
+
 #ifndef CONFIG_SPL_BUILD
 #include 
 
-- 
1.9.1


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

[U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys

[Ziyuan Xu]

From: Xu Ziyuan 

So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and
Innosilicon. This patch applys dwc2 usb driver framework to implement
phy_init and phy_off for Synopsys phy on Rockchip platform.

Signed-off-by: Ziyuan Xu 

---

Changes in v3:
- Make UOC_CON registers to be unfixed which should be got from DT

Changes in v2:
- Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
- Rework the behaviour in otg_phy_init() and otg_phy_off()

 drivers/usb/phy/Makefile|  1 +
 drivers/usb/phy/rockchip_usb_syno_phy.c | 47 +
 2 files changed, 48 insertions(+)
 create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c

diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 93d147e..8002a18 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -7,3 +7,4 @@
 
 obj-$(CONFIG_TWL4030_USB) += twl4030.o
 obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o
+obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o
diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c 
b/drivers/usb/phy/rockchip_usb_syno_phy.c
new file mode 100644
index 000..ab049e1
--- /dev/null
+++ b/drivers/usb/phy/rockchip_usb_syno_phy.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+#include "../gadget/dwc2_udc_otg_priv.h"
+
+#define UOC_CON(x) ((x) * 0x4)
+
+#define RESET_WRITE_ENABIT(28)
+#define PORT_RESET BIT(12)
+#define PORT_NORMAL(0 << 12)
+
+#define SOFT_CTRL_WRITE_ENABIT(18)
+#define SOFT_CTRL_ENABLE   BIT(2)
+
+#define SUSPEND_SETTING0x2A
+#define SUSPEND_WRITE_ENA  (0x3f << 16)
+
+
+void otg_phy_init(struct dwc2_udc *dev)
+{
+   /* disable software control */
+   writel(SOFT_CTRL_WRITE_ENA | (0 << 2),
+  dev->pdata->regs_phy + UOC_CON(2));
+   /* reset otg port */
+   writel(RESET_WRITE_ENA | PORT_RESET,
+  dev->pdata->regs_phy + UOC_CON(0));
+   mdelay(1);
+   writel(RESET_WRITE_ENA | PORT_NORMAL,
+  dev->pdata->regs_phy + UOC_CON(0));
+   udelay(1);
+}
+
+void otg_phy_off(struct dwc2_udc *dev)
+{
+   /* enable software control */
+   writel(SOFT_CTRL_WRITE_ENA | SOFT_CTRL_ENABLE,
+  dev->pdata->regs_phy + UOC_CON(2));
+   /* enter suspend */
+   writel(SUSPEND_WRITE_ENA | SUSPEND_SETTING,
+  dev->pdata->regs_phy + UOC_CON(3));
+}
-- 
1.9.1


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

Re: [U-Boot] [RESEND PATCH v4] dm: spi: Read default speed and mode values from DT

[Jagan Teki]

On 6 July 2016 at 10:04, Vignesh R  wrote:
> In case of DT boot, don't read default speed and mode for SPI from
> CONFIG_*, instead read from DT node. This will make sure that boards
> with multiple SPI/QSPI controllers can be probed at different
> bus frequencies and SPI modes.
>
> Signed-off-by: Vignesh R 
> Reviewed-by: Simon Glass 
> Reviewed-by: Mugunthan V N 

Reviewed-by: Jagan Teki 

Applied to u-boot-spi/master

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

Re: [U-Boot] [RESEND PATCH] ARM: dts: dra7x: Support QSPI MODE-0 operation at 64MHz

[Jagan Teki]

On 6 July 2016 at 11:27, Mugunthan V N  wrote:
> On Wednesday 06 July 2016 10:26 AM, Vignesh R wrote:
>> According to Data Manual(SPRS915P) of AM57x, TI QSPI controller on
>> DRA74(rev 1.1+)/DRA72 EVM can support up to 64MHz in MODE-0, whereas
>> MODE-3 is limited to 48MHz. Hence, switch to MODE-0 for better
>> throughput.
>>
>> Signed-off-by: Vignesh R 
>> Reviewed-by: Tom Rini 
>
> Reviewed-by: Mugunthan V N 

Reviewed-by: Jagan Teki 

Applied to u-boot-spi/master

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

Re: [U-Boot] [RESEND PATCH 0/4] U-Boot: Add support for Cadence QSPI on K2G

[Jagan Teki]

On 6 July 2016 at 10:20, Vignesh R  wrote:
>
> This series adds support for Cadence QSPI controller present on K2G SoC.
>
> The first patch extends AHB address to 32 bit as K2G has 32 bit AHB
> address. Second patch to enable QUAD mode based on DT data instead of
> relying on config option. And last to patches add DT node and add
> configs to enable the driver.
>
> Depends on [1] to enable SPI driver model support on K2G and [2] to
> support different bus frequencies for two different SPI controllers
> present on K2G EVM.
>
> [1]https://www.mail-archive.com/u-boot@lists.denx.de/msg217952.html
> [2]https://www.mail-archive.com/u-boot@lists.denx.de/msg217964.html
>
> Rebased on top of v2016.07-rc3

Applied to u-boot-spi/master

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

Re: [U-Boot] [RESEND PATCH v3 00/12] Convert davinci_spi to DM

[Jagan Teki]

On 6 July 2016 at 09:58, Vignesh R  wrote:
>
> This series converts davinci_spi driver to adapt to driver model
> framework. And enables the driver on k2l, k2e, k2hk evms. Also,
> added support for davinci_spi on k2g evm.
>
> Tested on k2l, k2e, k2hk and k2g evms.
>
> Resend:
> Rebased on top of v2016.07-rc3

Applied to u-boot-spi/master

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

Re: [U-Boot] [RESEND PATCH v3 12/12] defconfig: k2g_evm_defconfig: enable SPI driver model

[Jagan Teki]

On 6 July 2016 at 09:59, Vignesh R  wrote:
> Enable SPI and SPI Flash driver model as K2G SPI controller driver
> supports driver model.
>
> Signed-off-by: Vignesh R 
> Reviewed-by: Tom Rini 

Reviewed-by: Jagan Teki 

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

Re: [U-Boot] [PATCH v2 08/13] dm: mmc: zynq: Convert zynq to use driver model for MMC

[Jaehoon Chung]

Hi Simon,

On 07/06/2016 08:10 AM, Simon Glass wrote:
> Move zynq to the latest driver model support by enabling CONFIG_DM_MMC,
> CONFIG_DM_MMC_OPS and CONFIG_BLK.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/Kconfig |  5 +
>  drivers/mmc/zynq_sdhci.c | 39 ++-
>  2 files changed, 39 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9d6cdc7..f45fd37 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -657,11 +657,13 @@ config ARCH_ZYNQ
>   select DM_GPIO
>   select SPL_DM if SPL
>   select DM_MMC
> + select DM_MMC_OPS
>   select DM_SPI
>   select DM_SERIAL
>   select DM_SPI_FLASH
>   select SPL_SEPARATE_BSS if SPL
>   select DM_USB if USB
> + select BLK

If my understanding is right, your patch[12~13/13] are enabled with 
CONFIG_DM_MMC.
Does it need to select at here?

>  
>  config ARCH_ZYNQMP
>   bool "Support Xilinx ZynqMP Platform"
> @@ -671,6 +673,9 @@ config ARCH_ZYNQMP
>   select DM_SERIAL
>   select SUPPORT_SPL
>   select DM_USB if USB
> + select DM_MMC
> + select DM_MMC_OPS
> + select BLK

Ditto.

>  
>  config TEGRA
>   bool "NVIDIA Tegra"
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index d405929..bcd154a 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -17,10 +17,18 @@
>  # define CONFIG_ZYNQ_SDHCI_MIN_FREQ  0
>  #endif
>  
> +struct arasan_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};

Almost all drivers are using the similar *_plat structure.
Then it can be used the one structure instead of *_plat..
So i think it should be located "struct mmc_plat" into mmc.h

struct mmc_plat {
struct mmc_config cfg;
struct mmc mmc;
};

Then we can remove the all other similar plat structures.
if you are ok, I will clean everything.
how about?

Best Regards,
Jaehoon Chung

> +
>  static int arasan_sdhci_probe(struct udevice *dev)
>  {
> + struct arasan_sdhci_plat *plat = dev_get_platdata(dev);
>   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
>   struct sdhci_host *host = dev_get_priv(dev);
> + u32 caps;
> + int ret;
>  
>   host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD |
>  SDHCI_QUIRK_BROKEN_R1B;
> @@ -31,13 +39,19 @@ static int arasan_sdhci_probe(struct udevice *dev)
>  
>   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
>  
> - add_sdhci(host, CONFIG_ZYNQ_SDHCI_MAX_FREQ,
> -   CONFIG_ZYNQ_SDHCI_MIN_FREQ);
> -
> - upriv->mmc = host->mmc;
> + caps = sdhci_readl(host, SDHCI_CAPABILITIES);
> + ret = sdhci_setup_cfg(>cfg, dev->name, host->bus_width,
> +   caps, CONFIG_ZYNQ_SDHCI_MAX_FREQ,
> +   CONFIG_ZYNQ_SDHCI_MIN_FREQ, host->version,
> +   host->quirks, 0);
> + host->mmc = >mmc;
> + if (ret)
> + return ret;
> + host->mmc->priv = host;
>   host->mmc->dev = dev;
> + upriv->mmc = host->mmc;
>  
> - return 0;
> + return sdhci_probe(dev);
>  }
>  
>  static int arasan_sdhci_ofdata_to_platdata(struct udevice *dev)
> @@ -50,6 +64,18 @@ static int arasan_sdhci_ofdata_to_platdata(struct udevice 
> *dev)
>   return 0;
>  }
>  
> +static int arasan_sdhci_bind(struct udevice *dev)
> +{
> + struct arasan_sdhci_plat *plat = dev_get_platdata(dev);
> + int ret;
> +
> + ret = sdhci_bind(dev, >mmc, >cfg);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
>  static const struct udevice_id arasan_sdhci_ids[] = {
>   { .compatible = "arasan,sdhci-8.9a" },
>   { }
> @@ -60,6 +86,9 @@ U_BOOT_DRIVER(arasan_sdhci_drv) = {
>   .id = UCLASS_MMC,
>   .of_match   = arasan_sdhci_ids,
>   .ofdata_to_platdata = arasan_sdhci_ofdata_to_platdata,
> + .ops= _ops,
> + .bind   = arasan_sdhci_bind,
>   .probe  = arasan_sdhci_probe,
>   .priv_auto_alloc_size = sizeof(struct sdhci_host),
> + .platdata_auto_alloc_size = sizeof(struct arasan_sdhci_plat),
>  };
> 

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

Re: [U-Boot] build error

[Chen-Yu Tsai]

Hi,

On Wed, Jul 6, 2016 at 8:22 AM, Richard Snow  wrote:
> Building current source for 4 boards (4 threads, 2 jobs per thread)
>arm:  +   q8_a33_tablet_800x480
> +{standard input}: Assembler messages:
> +{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
> {r0,r1,r2,r3,r4,r9,ip,pc}^'
> +make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
> +make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
> +make[1]: *** [arch/arm/cpu/armv7] Error 2
> +make: *** [sub-make] Error 2
>arm:  +   q8_a23_tablet_800x480
> +{standard input}: Assembler messages:
> +{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
> {r0,r1,r2,r3,r4,r9,ip,pc}^'
> +make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
> +make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
> +make[1]: *** [arch/arm/cpu/armv7] Error 2
> +make: *** [sub-make] Error 2
>arm:  +   q8_a33_tablet_1024x600
> +{standard input}: Assembler messages:
> +{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
> {r0,r1,r2,r3,r4,r9,ip,pc}^'
> +make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
> +make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
> +make[1]: *** [arch/arm/cpu/armv7] Error 2
> +make: *** [sub-make] Error 2
> 103 /4  q8_a13_tablet
> richard@ubuntu:~/u-boot$

This is a known and fixed GCC bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
https://bugzilla.redhat.com/show_bug.cgi?id=1344717

You should update your toolchain.

ChenYu

>
> My tablet is labeled AllDayMall model a88x bsf1.  The firmware that came
> with it is defective the wifi does not work, i am trying to
> set up to boot linux gentoo or other linux from sd card.
>
> --
> h ttp://richardsnow.info
> My Google Plus profile 
> ___
> 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

[U-Boot] build error

[Richard Snow]

Building current source for 4 boards (4 threads, 2 jobs per thread)
   arm:  +   q8_a33_tablet_800x480
+{standard input}: Assembler messages:
+{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
{r0,r1,r2,r3,r4,r9,ip,pc}^'
+make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
+make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
+make[1]: *** [arch/arm/cpu/armv7] Error 2
+make: *** [sub-make] Error 2
   arm:  +   q8_a23_tablet_800x480
+{standard input}: Assembler messages:
+{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
{r0,r1,r2,r3,r4,r9,ip,pc}^'
+make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
+make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
+make[1]: *** [arch/arm/cpu/armv7] Error 2
+make: *** [sub-make] Error 2
   arm:  +   q8_a33_tablet_1024x600
+{standard input}: Assembler messages:
+{standard input}:299: Error: push/pop do not support {reglist}^ -- `pop
{r0,r1,r2,r3,r4,r9,ip,pc}^'
+make[3]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
+make[2]: *** [arch/arm/cpu/armv7/sunxi] Error 2
+make[1]: *** [arch/arm/cpu/armv7] Error 2
+make: *** [sub-make] Error 2
103 /4  q8_a13_tablet
richard@ubuntu:~/u-boot$


My tablet is labeled AllDayMall model a88x bsf1.  The firmware that came
with it is defective the wifi does not work, i am trying to
set up to boot linux gentoo or other linux from sd card.

-- 
h ttp://richardsnow.info
My Google Plus profile 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot