Re: [U-Boot] [PATCH] zynq: spi: Honour the activation / deactivation delay

2016-12-14 Thread Michal Simek
On 14.12.2016 20:13, Moritz Fischer wrote:
> Whoops,
> 
> On Thu, Dec 8, 2016 at 12:11 PM, Moritz Fischer
>  wrote:
>> This is not currently implemented. Add support for this so that the
>> Chrome OS EC can be used reliably.
>>
>> Signed-off-by: Moritz Fischer 
>> Cc: Jagan Teki 
>> Cc: Simon Glass 
>> Cc: u-boot@lists.denx.de
> Cc: Michal Simek 

Jagan is the guy who should apply this.
Anyway are you running chrome OS on Zynq or ZynqMP?

Thanks,
Michal

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


Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

2016-12-14 Thread Michal Simek
On 14.12.2016 16:00, Mike Looijmans wrote:
> 
>> I am not marketing guy to say how often there are designs with only
>> different DDR size like Mike's example but in fpga world you are not
>> buying this chip to have only static part but you want to use fpga part
>> and for that you need to use design tools. Because every design is
>> unique you can generate device tree description directly from design
>> tools which covers your target and this is what I believe people use.
> 
> Well, I can't speak for everyone...
> 
> Most people don't want to write (or even compile) a new bootloader for
> each and every project. For our Miami SOMs, there are already more
> full-custom carrier boards than evaluation boards. If we had to build a
> bootloader for each such design, there'd be dozens of them.
> 
> What we try to do is just use the generic bootloader to get the SOM up
> and running, and then provide all the project hardware details in the
> kernel's final devicetree. That includes changing pinmuxing and clocks
> and stuff, which is easy to do.

That's nothing against what I have said. Having as much flexibility you
need is great. We should support several method how to setup stuff and
it is up to user if this method is suitable for you or not and doing
these selection via Kconfig is the way we need to go.
For all these autodetection algorithms you have to be sure that it is
working fine on your platform based on testing.

Thanks,
Michal


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


Re: [U-Boot] [PATCH v2] miniarm-rk3288: set isp/vop qos priority level

2016-12-14 Thread Nickey.Yang

Hi Kever & Simon,


在 2016年12月14日 15:07, Kever Yang 写道:

Hi Simon,

On 12/12/2016 04:27 AM, Simon Glass wrote:

Hi Nickey,

On 8 December 2016 at 21:39, Nickey Yang  
wrote:

isp-camera image will be broken when enter dual screen display mode.
We set isp qos high to solve this problem.

Signed-off-by: Nickey Yang 
---
  arch/arm/include/asm/arch-rockchip/qos_rk3288.h | 21 
+
  board/rockchip/miniarm_rk3288/miniarm-rk3288.c  | 21 
+

  2 files changed, 42 insertions(+)
  create mode 100644 arch/arm/include/asm/arch-rockchip/qos_rk3288.h

diff --git a/arch/arm/include/asm/arch-rockchip/qos_rk3288.h 
b/arch/arm/include/asm/arch-rockchip/qos_rk3288.h

new file mode 100644
index 000..d3d6c3e
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/qos_rk3288.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2016 Rockchip Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#ifndef _ASM_ARCH_QOS_RK3288_H
+#define _ASM_ARCH_QOS_RK3288_H
+
+/* cpu axi qos priority */
+#define CPU_AXI_QOS_PRIORITY_LEVEL(h, l) \
+   h) & 3) << 2) | ((l) & 3))

Can you instead define

XXX_SHIFT   2
XXX_MASK  (3 << XXX_SHIFT)

and then use these in the .c code?


+
+#define CPU_AXI_QOS_PRIORITY0x08
+
+#define VIO0_VOP_QOS0xffad0400
+#define VIO1_VOP_QOS0xffad
+#define VIO1_ISP_R_QOS  0xffad0900
+#define VIO1_ISP_W0_QOS 0xffad0100
+#define VIO1_ISP_W1_QOS 0xffad0180
+
+#endif
diff --git a/board/rockchip/miniarm_rk3288/miniarm-rk3288.c 
b/board/rockchip/miniarm_rk3288/miniarm-rk3288.c

index 79541a3..ba0f3a3 100644
--- a/board/rockchip/miniarm_rk3288/miniarm-rk3288.c
+++ b/board/rockchip/miniarm_rk3288/miniarm-rk3288.c
@@ -5,3 +5,24 @@
   */

  #include 
+#include 
+#include 
+
+int rk_board_late_init(void)
+{
+   /* set isp qos to higher priority */
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_R_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_W0_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_ISP_W1_QOS + CPU_AXI_QOS_PRIORITY);
+
+   /* set vop qos to higher priority */
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO0_VOP_QOS + CPU_AXI_QOS_PRIORITY);
+   writel(CPU_AXI_QOS_PRIORITY_LEVEL(2, 2),
+  VIO1_VOP_QOS + CPU_AXI_QOS_PRIORITY);
Can you add a register struct for this in 
arch/arm/include/asm/arch-rockchip/ ?


Also I think it would be best to put this code somewhere in
arch/arm/mach-rockchip and call it from your late init routine.


I understand people don't like source cod in hardcode(or nearly) and 
out of

any framwork, but there do have some different one time init program for
different SoC or board, I think it's OK to add then in soc_init() or 
board_init()

with appropriate comment.

Back to the case here, setting the ISP NOC niu to higher priority is 
only needed
for the miniarm board for the use case in that board. It might have 
other requirement
for other board for different use cases, so it's OK to add the code in 
board file.
I think you would like to have some API function for this setting then 
different board can use it

instead of do SoC setting in board file, right?
Before other board need this blob of code, would it be more clear to 
put the code in board file?



or in arch/arm/mach-rockchip/rk3288-board.c
+__weak int rk_qos_init(void)
+{
+/* do  set  vop  qos level  */
+   }

int board_late_init(void)
 {
setup_boot_mode();
+   rk_qos_init();

}

in board/rockchip/miniarm_rk3288/miniarm-rk3288.c
+int rk_qos_init(void)
+{
+/* do  set vop  qos level  */
+/* do  set isp qos level  */
+}

Whether this is  a better way?

@Nickey, I'm sure the patch V3 is not what we need. Simon's suggestion 
could be detail in this:

- add a rk3288_qos_init() in arch/arm/mach-rockchip/rk3288-board.c
- call the rk3288_qos_init() in rk_board_late_init() of 
board/rockchip/miniarm_rk3288/miniarm-rk3288.c


Thanks,
- Kever



+
+   return 0;
+}
--
1.9.1



Regards,
Simon











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


[U-Boot] [PATCH 2/2] ARMv8/fsl-layerscape: Enable data coherency between cores in cluster

2016-12-14 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Signed-off-by: Hou Zhiqiang 
---
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 6772584..28d474b 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -1,5 +1,6 @@
 config ARCH_LS1012A
bool
+   select ARMV8_SET_SMPEN
select FSL_LSCH2
select SYS_FSL_DDR_BE
select SYS_FSL_MMDC
@@ -7,6 +8,7 @@ config ARCH_LS1012A
 
 config ARCH_LS1043A
bool
+   select ARMV8_SET_SMPEN
select FSL_LSCH2
select SYS_FSL_DDR_BE
select SYS_FSL_DDR_VER_50
@@ -15,6 +17,7 @@ config ARCH_LS1043A
 
 config ARCH_LS1046A
bool
+   select ARMV8_SET_SMPEN
select FSL_LSCH2
select SYS_FSL_DDR_BE
select SYS_FSL_DDR4
@@ -24,6 +27,7 @@ config ARCH_LS1046A
 
 config ARCH_LS2080A
bool
+   select ARMV8_SET_SMPEN
select FSL_LSCH3
select SYS_FSL_DDR4
select SYS_FSL_DDR_LE
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 1/2] armv8: Enable CPUECTLR.SMPEN for coherency

2016-12-14 Thread Zhiqiang Hou
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 
Signed-off-by: Mateusz Kulikowski 
Signed-off-by: Hou Zhiqiang 
---
 arch/arm/cpu/armv8/Kconfig | 12 
 arch/arm/cpu/armv8/start.S | 11 +++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 965a8d1..ce749f2 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -3,6 +3,18 @@ if ARM64
 config ARMV8_MULTIENTRY
 bool "Enable multiple CPUs to enter into U-Boot"
 
+config ARMV8_SET_SMPEN
+bool "Enable data coherency with other cores in cluster"
+help
+  Cortex A53/57/72 cores require CPUECTLR_EL1.SMPEN set even
+  for single core systems. Unfortunately write access to this
+  register may be controlled by EL3/EL2 firmware. To be more
+  precise, by default (if there is EL2/EL3 firmware running)
+  this register is RO for NS EL1.
+  This switch can be used to avoid writing to CPUECTLR_EL1,
+  it can be safely enabled when El2/EL3 initialized SMPEN bit
+  or when CPU implementation doesn't include that register.
+
 config ARMV8_SPIN_TABLE
bool "Support spin-table enable method"
depends on ARMV8_MULTIENTRY && OF_LIBFDT
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 4f5f6d8..5308702 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -86,6 +86,17 @@ save_boot_params_ret:
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.
+*/
+#ifdef CONFIG_ARMV8_SET_SMPEN
+   mrs x0, S3_1_c15_c2_1   /* cpuactlr_el1 */
+   orr x0, x0, #0x40
+   msr S3_1_c15_c2_1, x0
+#endif
+
/* 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] [PATCH] usb: dwc2_udc_otg: remove the driver_desc as unused variable

2016-12-14 Thread Jaehoon Chung
On 12/15/2016 11:12 AM, Marek Vasut wrote:
> On 12/15/2016 03:02 AM, Jaehoon Chung wrote:
>> This patch fixes for the below warning.
>>
>> drivers/usb/gadget/dwc2_udc_otg.c:72:19: warning: 'driver_desc' defined but 
>> not used [-Wunused-const-variable=]
>>  static const char driver_desc[] = DRIVER_DESC;
>>
>> Signed-off-by: Jaehoon Chung 
> 
> Masahiro already sent such patch, thanks though.

Oh, i didn't know that. Thanks for noticing it. 

Best Regards,
Jaehoon Chung

> 
>> ---
>>  drivers/usb/gadget/dwc2_udc_otg.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
>> b/drivers/usb/gadget/dwc2_udc_otg.c
>> index d72bfdf..cb44374 100644
>> --- a/drivers/usb/gadget/dwc2_udc_otg.c
>> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
>> @@ -63,13 +63,11 @@ static char *state_names[] = {
>>  "WAIT_FOR_NULL_COMPLETE",
>>  };
>>  
>> -#define DRIVER_DESC "DWC2 HS USB OTG Device Driver, (c) Samsung Electronics"
>>  #define DRIVER_VERSION "15 March 2009"
>>  
>>  struct dwc2_udc *the_controller;
>>  
>>  static const char driver_name[] = "dwc2-udc";
>> -static const char driver_desc[] = DRIVER_DESC;
>>  static const char ep0name[] = "ep0-control";
>>  
>>  /* Max packet size*/
>>
> 
> 

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


[U-Boot] Many unused variable warnings

2016-12-14 Thread Masahiro Yamada
Hi.

The recent GCC versions catch unused variables.

This makes build testing noisy.

Of course, we could use old GCC when running Buildman,
but it would be nicer to eliminate the root causes.

I got the following when I recently ran Buildman with arm/aarch64 GCC 6.1.


drivers/usb/gadget/dwc2_udc_otg.c was fixed lately,
but there are still many warnings to be fixed.

Board maintainers, please check your own boards.
Or, somebody who volunteers to fix them?  Thanks!




w+../arch/arm/cpu/arm926ejs/mxs/spl_boot.c:44:26: warning:
'iomux_boot' defined but not used [-Wunused-const-variable=]
w+../common/cli_readline.c:20:21: warning: 'tab_seq' defined but not
used [-Wunused-const-variable=]
w+../common/cli_readline.c:19:19: warning: 'erase_seq' defined but not
used [-Wunused-const-variable=]
w+../drivers/usb/gadget/dwc2_udc_otg.c:72:19: warning: 'driver_desc'
defined but not used [-Wunused-const-variable=]
w+../arch/arm/mach-omap2/omap4/hw_data.c:136:3: warning:
'abe_dpll_params_sysclk_196608khz' defined but not used
[-Wunused-const-variable=]
w+../drivers/clk/rockchip/clk_rk3288.c:135:29: warning:
'cpll_init_cfg' defined but not used [-Wunused-const-variable=]
w+../drivers/clk/rockchip/clk_rk3288.c:134:29: warning:
'gpll_init_cfg' defined but not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:226:33: warning: 'dual_0S' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:213:33: warning: 'dual_S0' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:196:33: warning: 'dual_0D' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:179:33: warning: 'dual_D0' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:162:33: warning: 'dual_SS' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:140:33: warning: 'dual_SD' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:119:33: warning: 'dual_DS' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:92:33: warning: 'dual_DD' defined but
not used [-Wunused-const-variable=]
w+../drivers/usb/gadget/ether.c:501:17: warning: 'mdlm_detail_desc'
defined but not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:80:33: warning: 'single_S' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:63:33: warning: 'single_D' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:36:33: warning: 'single_Q' defined but
not used [-Wunused-const-variable=]
w+../board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c:228:29:
warning: 'usdhc1_pads' defined but not used [-Wunused-const-variable=]
w+../drivers/net/eepro100.c:210:19: warning: 'i82557_config_cmd'
defined but not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:456:33: warning: 'dual_0S' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:443:33: warning: 'dual_S0' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:426:33: warning: 'dual_0D' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:409:33: warning: 'dual_D0' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:392:33: warning: 'dual_SS' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:370:33: warning: 'dual_SD' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:349:33: warning: 'dual_DS' defined but
not used [-Wunused-const-variable=]
w+../drivers/ddr/fsl/options.c:322:33: warning: 'dual_DD' defined but
not used [-Wunused-const-variable=]
w+../arch/arm/mach-omap2/omap5/hw_data.c:204:33: warning:
'abe_dpll_params_32k_196608khz' defined but not used
[-Wunused-const-variable=]
w+../arch/arm/mach-omap2/omap5/hw_data.c:131:4: warning:
'core_dpll_params_2128mhz_ddr266_es2' defined but not used
[-Wunused-const-variable=]
w+../arch/arm/mach-omap2/omap5/hw_data.c:120:4: warning:
'core_dpll_params_2128mhz_ddr266' defined but not used
[-Wunused-const-variable=]
w+../arch/arm/mach-omap2/omap5/hw_data.c:65:33: warning:
'mpu_dpll_params_499mhz' defined but not used
[-Wunused-const-variable=]
w+../arch/arm/mach-omap2/omap5/hw_data.c:54:33: warning:
'mpu_dpll_params_400mhz' defined but not used
[-Wunused-const-variable=]
w+../arch/arm/mach-omap2/omap5/hw_data.c:32:33: warning:
'mpu_dpll_params_1_5ghz' defined but not used
[-Wunused-const-variable=]
w+../board/phytec/pcm058/pcm058.c:136:29: warning: 'gpios_pads'
defined but not used [-Wunused-const-variable=]
w+../board/phytec/pcm058/pcm058.c:171:29: warning: 'usdhc4_pads'
defined but not used [-Wunused-const-variable=]
w+../board/phytec/pcm058/pcm058.c:112:29: warning: 'nfc_pads' defined
but not used [-Wunused-const-variable=]
w+../board/bachmann/ot1200/ot1200.c:276:29: warning: 'pwm_pad' defined
but not used [-Wunused-const-variable=]
w+../arch/arm/mach-omap2/omap5/hw_data.c:193:3: warning:

[U-Boot] [PATCH 29/29] blackfin: Enable driver-model on bf537-stamp

2016-12-14 Thread Simon Glass
Enable driver model and device tree on this board. Set it to use the new
driver-model serial driver.

Signed-off-by: Simon Glass 
---

 configs/bf537-stamp_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/bf537-stamp_defconfig b/configs/bf537-stamp_defconfig
index 599a4a0..667f5cf 100644
--- a/configs/bf537-stamp_defconfig
+++ b/configs/bf537-stamp_defconfig
@@ -19,6 +19,7 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
 CONFIG_SPI_FLASH_EON=y
@@ -27,3 +28,8 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_DM_SERIAL=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_BLACKFIN=y
+CONFIG_DEBUG_UART_BASE=0xffc00400
+CONFIG_DEBUG_UART_CLOCK=0
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 27/29] dm: blackfin: Add a driver-model serial driver

2016-12-14 Thread Simon Glass
Add a serial driver that supports driver model. So far it only works with
the v1 serial port.

Signed-off-by: Simon Glass 
---

 arch/blackfin/include/asm/serial1.h |   2 +
 drivers/serial/Kconfig  |   8 ++
 drivers/serial/serial_bfin.c| 192 
 3 files changed, 202 insertions(+)

diff --git a/arch/blackfin/include/asm/serial1.h 
b/arch/blackfin/include/asm/serial1.h
index 467d381..be5a7a9 100644
--- a/arch/blackfin/include/asm/serial1.h
+++ b/arch/blackfin/include/asm/serial1.h
@@ -231,6 +231,7 @@ static inline void serial_early_do_portmux(void)
SSYNC();
 }
 
+#ifndef CONFIG_DM_SERIAL
 __attribute__((always_inline))
 static inline int uart_init(uint32_t uart_base)
 {
@@ -262,6 +263,7 @@ static inline int serial_early_uninit(uint32_t uart_base)
 
return 0;
 }
+#endif /* !CONFIG_DM_SERIAL */
 
 __attribute__((always_inline))
 static inline void serial_set_divisor(uint32_t uart_base, uint16_t divisor)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 620dd82..3b16c40 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -161,6 +161,14 @@ config DEBUG_MVEBU_A3700_UART
  will need to provide parameters to make this work. The driver will
  be available until the real driver-model serial is running.
 
+config DEBUG_UART_BLACKFIN
+   bool "Blackfin"
+   help
+ Select this to enable a debug UART using the serial_bfin driver. You
+ will need to provide parameters to make this work. The driver will
+ be available until the real driver-model serial is running. This
+ only supports the v1 UART at present.
+
 config DEBUG_UART_ZYNQ
bool "Xilinx Zynq"
help
diff --git a/drivers/serial/serial_bfin.c b/drivers/serial/serial_bfin.c
index 1d5be2a..8d80b05 100644
--- a/drivers/serial/serial_bfin.c
+++ b/drivers/serial/serial_bfin.c
@@ -38,6 +38,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -47,6 +49,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifndef CONFIG_DM_SERIAL
+
 #ifdef CONFIG_UART_CONSOLE
 
 #ifdef CONFIG_DEBUG_SERIAL
@@ -409,3 +413,191 @@ void bfin_serial_initialize(void)
serial_register(_serial_mem_device);
 }
 #endif /* CONFIG_UART_MEM */
+
+#endif /* CONFIG_DM_SERIAL */
+
+
+#ifdef CONFIG_DM_SERIAL
+struct bfin_serial_priv {
+   struct bfin_mmr_serial *regs;
+};
+
+static void dm_serial_set_divisor(struct bfin_mmr_serial *regs,
+ uint16_t divisor)
+{
+   /* Set DLAB in LCR to Access DLL and DLH */
+   bfin_write_or(>lcr, DLAB);
+   SSYNC();
+
+   /* Program the divisor to get the baud rate we want */
+   bfin_write(>dll, LOB(divisor));
+   bfin_write(>dlh, HIB(divisor));
+   SSYNC();
+
+   /* Clear DLAB in LCR to Access THR RBR IER */
+   bfin_write_and(>lcr, ~DLAB);
+   SSYNC();
+}
+
+static void __serial_set_baud(struct bfin_mmr_serial *regs, unsigned baud)
+{
+   uint16_t divisor = (get_uart_clk() + (baud * 8)) / (baud * 16)
+   - ANOMALY_05000230;
+
+   dm_serial_set_divisor(regs, divisor);
+}
+
+static inline int uart_init(struct bfin_mmr_serial *regs)
+{
+   /* always enable UART -- avoids anomalies 05000309 and 05000350 */
+   bfin_write(>gctl, UCEN);
+
+   /* Set LCR to Word Lengh 8-bit word select */
+   bfin_write(>lcr, WLS_8);
+
+   SSYNC();
+
+   return 0;
+}
+
+static int uart_tstc(struct bfin_mmr_serial *regs)
+{
+   WATCHDOG_RESET();
+   return (_lsr_read(regs) & DR) ? 1 : 0;
+}
+
+#if defined(CONFIG_DEBUG_UART_BLACKFIN)
+
+#include 
+
+static inline int serial_early_init(struct bfin_mmr_serial *regs)
+{
+   /* handle portmux crap on different Blackfins */
+   serial_early_do_portmux();
+
+   uart_init(regs);
+   serial_early_set_baud((ulong)regs, CONFIG_BAUDRATE);
+
+   return 0;
+}
+
+static void _debug_uart_init(void)
+{
+   struct bfin_mmr_serial *regs =
+   (struct bfin_mmr_serial *)CONFIG_DEBUG_UART_BASE;
+
+   serial_early_init(regs);
+}
+
+static inline void _debug_uart_putc(int ch)
+{
+   struct bfin_mmr_serial *regs =
+   (struct bfin_mmr_serial *)CONFIG_DEBUG_UART_BASE;
+
+   /* wait for the hardware fifo to clear up */
+   while (!(_lsr_read(regs) & THRE))
+   continue;
+
+   /* queue the character for transmission */
+   bfin_write(>thr, ch);
+   SSYNC();
+}
+
+DEBUG_UART_FUNCS
+
+#endif /* CONFIG_DEBUG_UART_BLACKFIN */
+
+static int bfin_serial_probe(struct udevice *dev)
+{
+   struct bfin_serial_priv *priv = dev_get_priv(dev);
+   const unsigned short pins[] = { _P_UART(0, RX), _P_UART(0, TX), 0, };
+   struct bfin_mmr_serial *regs;
+
+   peripheral_request_list(pins, "bfin-uart");
+   regs = (struct bfin_mmr_serial *)MMR_UART(0);
+   priv->regs = regs;
+
+   return 0;
+}
+

[U-Boot] [PATCH 26/29] dm: serial: Update the serial README

2016-12-14 Thread Simon Glass
Since all drivers are now converted, we can update the README to cover
this.

Signed-off-by: Simon Glass 
---

 doc/driver-model/serial-howto.txt | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/doc/driver-model/serial-howto.txt 
b/doc/driver-model/serial-howto.txt
index 67d0983..3241cfd 100644
--- a/doc/driver-model/serial-howto.txt
+++ b/doc/driver-model/serial-howto.txt
@@ -1,13 +1,9 @@
 How to port a serial driver to driver model
 ===
 
-Almost all of the serial drivers have been converted as at January 2016. These
-ones remain:
-
-   serial_bfin.c
-
-The deadline for this work was the end of January 2016. If no one steps
-forward to convert these, at some point there may come a patch to remove them!
+All of the serial drivers have been converted as at December 2016. The
+information in this file may be of interest to those using downstream boards.
+It will be removed in 2017.
 
 Here is a suggested approach for converting your serial driver over to driver
 model. Please feel free to update this file with your ideas and suggestions.
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 28/29] blackfin: Set up the debug UART if enabled

2016-12-14 Thread Simon Glass
The debug_uart function is useful for debugging early init problems. While
blackfin has its own means of doing this, it would be better to support
the standard approach. Add a call to init the debug UART early in
start-up.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index d039c4f..d3f8762 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -297,6 +298,10 @@ void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
memcpy(&_sdata_l1, &_data_l1_lma, (unsigned long)_data_l1_len);
}
 
+#ifdef CONFIG_DEBUG_UART
+   debug_uart_init();
+#endif
+
/*
 * Blackfin uses the BSS section before relcation. This is where the
 * device tree is located, so we must relocate it before any BSS
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 23/29] blackfin: bf537-stamp: Enable CONFIG_OF_CONTROL

2016-12-14 Thread Simon Glass
Enable device-tree control for this board, as an example for others. This
pushes the size of U-Boot over the 256KB limit, so extend this limit to
512KB.

Signed-off-by: Simon Glass 
---

 arch/blackfin/dts/Makefile| 18 ++
 arch/blackfin/dts/bf537-stamp.dts | 11 +++
 configs/bf537-stamp_defconfig |  2 ++
 include/configs/bf537-stamp.h |  1 +
 4 files changed, 32 insertions(+)
 create mode 100644 arch/blackfin/dts/Makefile
 create mode 100644 arch/blackfin/dts/bf537-stamp.dts

diff --git a/arch/blackfin/dts/Makefile b/arch/blackfin/dts/Makefile
new file mode 100644
index 000..757b1b0
--- /dev/null
+++ b/arch/blackfin/dts/Makefile
@@ -0,0 +1,18 @@
+#
+# Copyright (C) 2016 Google, Inc
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+dtb-$(CONFIG_BLACKFIN) += bf537-stamp.dtb
+
+targets += $(dtb-y)
+
+# Add any required device tree compiler flags here
+DTC_FLAGS +=
+
+PHONY += dtbs
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+   @:
+
+clean-files := *.dtb
diff --git a/arch/blackfin/dts/bf537-stamp.dts 
b/arch/blackfin/dts/bf537-stamp.dts
new file mode 100644
index 000..84fb1ef
--- /dev/null
+++ b/arch/blackfin/dts/bf537-stamp.dts
@@ -0,0 +1,11 @@
+/dts-v1/;
+
+/ {
+   chosen {
+   stdout-path = 
+   };
+
+   uart0: uart0 {
+   compatible = "adi,uart-v1";
+   };
+};
diff --git a/configs/bf537-stamp_defconfig b/configs/bf537-stamp_defconfig
index b691702..599a4a0 100644
--- a/configs/bf537-stamp_defconfig
+++ b/configs/bf537-stamp_defconfig
@@ -1,5 +1,6 @@
 CONFIG_BLACKFIN=y
 CONFIG_TARGET_BF537_STAMP=y
+CONFIG_DEFAULT_DEVICE_TREE="bf537-stamp"
 CONFIG_BOOTDELAY=5
 CONFIG_SILENT_CONSOLE=y
 CONFIG_CMD_MMC=y
@@ -16,6 +17,7 @@ CONFIG_CMD_DNS=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
diff --git a/include/configs/bf537-stamp.h b/include/configs/bf537-stamp.h
index 4f861aa..f8639d8 100644
--- a/include/configs/bf537-stamp.h
+++ b/include/configs/bf537-stamp.h
@@ -238,6 +238,7 @@
 /*
  * Misc Settings
  */
+#define CONFIG_BOARD_SIZE_LIMIT $$(( 512 * 1024 ))
 #define CONFIG_MISC_INIT_R
 #define CONFIG_RTC_BFIN
 #define CONFIG_UART_CONSOLE0
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 25/29] dm: serial: pxa: Drop pxa from the serial README

2016-12-14 Thread Simon Glass
This driver has been converted, so drop it from the hit list.

Signed-off-by: Simon Glass 
---

 doc/driver-model/serial-howto.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/driver-model/serial-howto.txt 
b/doc/driver-model/serial-howto.txt
index a0df9a7..67d0983 100644
--- a/doc/driver-model/serial-howto.txt
+++ b/doc/driver-model/serial-howto.txt
@@ -5,7 +5,6 @@ Almost all of the serial drivers have been converted as at 
January 2016. These
 ones remain:
 
serial_bfin.c
-   serial_pxa.c
 
 The deadline for this work was the end of January 2016. If no one steps
 forward to convert these, at some point there may come a patch to remove them!
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 22/29] blackfin: Allow use of CONFIG_OF_CONTROL

2016-12-14 Thread Simon Glass
Update blackfin to support device-tree control.

Signed-off-by: Simon Glass 
---

 arch/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index ffc7b45..722889d 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -25,6 +25,7 @@ config AVR32
 
 config BLACKFIN
bool "Blackfin architecture"
+   select SUPPORT_OF_CONTROL
 
 config M68K
bool "M68000 architecture"
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 24/29] dm: serial: Reset the watchdog when outputting characters

2016-12-14 Thread Simon Glass
In some cases it can take a enough time to output serial characters that
the watchdog triggers. Add a reset call to avoid this. This mirrors a
similar call on input.

Signed-off-by: Simon Glass 
---

 drivers/serial/serial-uclass.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 43c028e..489bbcc 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -134,6 +134,8 @@ static void _serial_putc(struct udevice *dev, char ch)
 
do {
err = ops->putc(dev, ch);
+   if (err == -EAGAIN)
+   WATCHDOG_RESET();
} while (err == -EAGAIN);
 }
 
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 21/29] blackfin: Copy the device tree out of BSS

2016-12-14 Thread Simon Glass
Blackfin currently uses BSS variables before location. The device tree
overlaps with the BSS region, meaning that it gets overwritten by any BSS
variable accesses. To work around this, copy it out of the way early in
boot.

The correct fix would be to adjust blackfin to avoid using BSS so early,
but this is a large amount of work and involves testing on many boards.
This solution is much more prudent for now.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index a8aaee4..d039c4f 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -296,6 +297,20 @@ void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
memcpy(&_sdata_l1, &_data_l1_lma, (unsigned long)_data_l1_len);
}
 
+   /*
+* Blackfin uses the BSS section before relcation. This is where the
+* device tree is located, so we must relocate it before any BSS
+* variables are used (e.g. bfin_poweron_retx, below). Copy it to
+* the end of BSS.
+*/
+   if (IS_ENABLED(CONFIG_OF_CONTROL)) {
+   const void *blob = &_image_binary_end;
+   int fdt_size = fdt_totalsize(blob);
+
+   memcpy(__bss_stop, blob, fdt_size);
+   gd->fdt_blob = __bss_stop;
+   }
+
memset(__bss_start, '\0', __bss_stop - __bss_start);
 
/*
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 18/29] blackfin: Don't set global_data again

2016-12-14 Thread Simon Glass
We have already set up gd in the standard board_init_f_init_reserve()
function. Drop the duplicate setup.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index d46e251..25c97b5 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -67,22 +67,12 @@ static inline void serial_early_puts(const char *s)
 
 static int global_board_data_init(void)
 {
-#ifndef CONFIG_SYS_GBL_DATA_ADDR
-# define CONFIG_SYS_GBL_DATA_ADDR 0
-#endif
 #ifndef CONFIG_SYS_BD_INFO_ADDR
 # define CONFIG_SYS_BD_INFO_ADDR 0
 #endif
 
bd_t *bd;
 
-   if (CONFIG_SYS_GBL_DATA_ADDR) {
-   gd = (gd_t *)(CONFIG_SYS_GBL_DATA_ADDR);
-   memset((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
-   } else {
-   static gd_t _bfin_gd;
-   gd = &_bfin_gd;
-   }
if (CONFIG_SYS_BD_INFO_ADDR) {
bd = (bd_t *)(CONFIG_SYS_BD_INFO_ADDR);
memset(bd, 0, GENERATED_BD_INFO_SIZE);
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 19/29] blackfin: Set the RAM size separately from bd_info

2016-12-14 Thread Simon Glass
Move the setting of the RAM size out of the function which now only deals
with bd_info. This will allow us to rename it.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index 25c97b5..afb2b0a 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -92,8 +92,6 @@ static int global_board_data_init(void)
bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
bd->bi_memsize = CONFIG_SYS_MAX_RAM_SIZE;
 
-   gd->ram_size = CONFIG_SYS_MAX_RAM_SIZE;
-
return 0;
 }
 
@@ -348,6 +346,7 @@ void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
 #endif
 
serial_early_puts("Init global data\n");
+   gd->ram_size = CONFIG_SYS_MAX_RAM_SIZE;
global_board_data_init();
 }
 
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 16/29] Drop CONFIG_SYS_MALLOC_END

2016-12-14 Thread Simon Glass
This is not used in U-Boot. Drop it from the whitelist.

Signed-off-by: Simon Glass 
---

 scripts/config_whitelist.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index ea1350d..8f65c0f 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -6259,7 +6259,6 @@ CONFIG_SYS_MACB2_BASE
 CONFIG_SYS_MACB3_BASE
 CONFIG_SYS_MAIN_PWR_ON
 CONFIG_SYS_MALLOC_CLEAR_ON_INIT
-CONFIG_SYS_MALLOC_END
 CONFIG_SYS_MALLOC_LEN
 CONFIG_SYS_MALLOC_SIMPLE
 CONFIG_SYS_MAMR
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 20/29] blackfin: Set up bd_info later

2016-12-14 Thread Simon Glass
At present bd_info is set up very early in boot, before board_init_f() is
called. But the board info is supposed to be allocated in board_init_f(),
with a call to reserve_board().

To fix this, drop the current static variable for board info and set up
the information at the end of the board_init_f() init sequence, just
before relocating.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index afb2b0a..a8aaee4 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -65,24 +65,8 @@ static inline void serial_early_puts(const char *s)
 #endif
 }
 
-static int global_board_data_init(void)
+static int board_data_init(bd_t *bd)
 {
-#ifndef CONFIG_SYS_BD_INFO_ADDR
-# define CONFIG_SYS_BD_INFO_ADDR 0
-#endif
-
-   bd_t *bd;
-
-   if (CONFIG_SYS_BD_INFO_ADDR) {
-   bd = (bd_t *)(CONFIG_SYS_BD_INFO_ADDR);
-   memset(bd, 0, GENERATED_BD_INFO_SIZE);
-   } else {
-   static bd_t _bfin_bd;
-   bd = &_bfin_bd;
-   }
-
-   gd->bd = bd;
-
bd->bi_r_version = version_string;
bd->bi_cpu = __stringify(CONFIG_BFIN_CPU);
bd->bi_board_name = CONFIG_SYS_BOARD;
@@ -347,11 +331,13 @@ void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
 
serial_early_puts("Init global data\n");
gd->ram_size = CONFIG_SYS_MAX_RAM_SIZE;
-   global_board_data_init();
 }
 
 void relocate_code(ulong sp, gd_t *new_gd, ulong relocaddr)
 {
+   /* Set up the board data now, since we have a valid bd pointer */
+   board_data_init(new_gd->bd);
+
/* Jump to board_init_r() with a new stack */
asm_relocate_code(sp, new_gd);
 }
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 17/29] blackfin: Call C code to relocate

2016-12-14 Thread Simon Glass
Rather than jumping directly to the assembler relocation code, call a C
function first. This will allow us to add board-specific adjustments.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c| 7 +++
 arch/blackfin/cpu/start.S  | 6 +++---
 arch/blackfin/include/asm/u-boot.h | 5 +
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index 0ae5ac6..d46e251 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -360,6 +361,12 @@ void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
global_board_data_init();
 }
 
+void relocate_code(ulong sp, gd_t *new_gd, ulong relocaddr)
+{
+   /* Jump to board_init_r() with a new stack */
+   asm_relocate_code(sp, new_gd);
+}
+
 int arch_cpu_init(void)
 {
serial_early_puts("Init CPLB tables\n");
diff --git a/arch/blackfin/cpu/start.S b/arch/blackfin/cpu/start.S
index 404e710..a5fd76c 100644
--- a/arch/blackfin/cpu/start.S
+++ b/arch/blackfin/cpu/start.S
@@ -245,12 +245,12 @@ LENTRY(_get_pc)
rts;
 ENDPROC(_get_pc)
 
-ENTRY(_relocate_code)
+ENTRY(_asm_relocate_code)
/* Fake relocate code. Setup the new stack only */
sp = r0;
fp = sp;
-   r0 = p3;
+   r0 = r1
r1.h = 0x2000;
r1.l = 0x10;
jump.l _board_init_r
-ENDPROC(_relocate_code)
+ENDPROC(_asm_relocate_code)
diff --git a/arch/blackfin/include/asm/u-boot.h 
b/arch/blackfin/include/asm/u-boot.h
index 1ada44e..ae035f7 100644
--- a/arch/blackfin/include/asm/u-boot.h
+++ b/arch/blackfin/include/asm/u-boot.h
@@ -33,4 +33,9 @@ typedef struct bd_info {
 
 intarch_misc_init(void);
 
+struct global_data;
+void asm_relocate_code(ulong sp, struct global_data *new_gd)
+   __attribute__ ((noreturn));
+
+
 #endif /* _U_BOOT_H_ */
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 12/29] blackfin: Drop CONFIG_STACKBASE

2016-12-14 Thread Simon Glass
This is not needed now that we calculate the stack base at run time. Drop
it.

Signed-off-by: Simon Glass 
---

 arch/blackfin/include/asm/config.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/blackfin/include/asm/config.h 
b/arch/blackfin/include/asm/config.h
index 27e8f3d..ea30ff8 100644
--- a/arch/blackfin/include/asm/config.h
+++ b/arch/blackfin/include/asm/config.h
@@ -109,9 +109,6 @@
 #ifndef CONFIG_SYS_MALLOC_BASE
 # define CONFIG_SYS_MALLOC_BASE (CONFIG_SYS_MONITOR_BASE - 
CONFIG_SYS_MALLOC_LEN)
 #endif
-#ifndef CONFIG_STACKBASE
-# define CONFIG_STACKBASE (CONFIG_SYS_MALLOC_BASE - 4)
-#endif
 #ifndef CONFIG_SYS_POST_WORD_ADDR
 # define CONFIG_SYS_POST_WORD_ADDR (L1_DATA_B_SRAM + L1_DATA_B_SRAM_SIZE - 4)
 #endif
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 15/29] blackfin: Drop CONFIG_SYS_MALLOC_BASE

2016-12-14 Thread Simon Glass
This is not used in U-Boot, so drop it from the config. Since this is the
last user, drop it from the whitelist also.

Signed-off-by: Simon Glass 
---

 arch/blackfin/include/asm/config.h | 3 ---
 scripts/config_whitelist.txt   | 1 -
 2 files changed, 4 deletions(-)

diff --git a/arch/blackfin/include/asm/config.h 
b/arch/blackfin/include/asm/config.h
index ea30ff8..bfcd703 100644
--- a/arch/blackfin/include/asm/config.h
+++ b/arch/blackfin/include/asm/config.h
@@ -106,9 +106,6 @@
 #  define CONFIG_SYS_MONITOR_BASE 0
 # endif
 #endif
-#ifndef CONFIG_SYS_MALLOC_BASE
-# define CONFIG_SYS_MALLOC_BASE (CONFIG_SYS_MONITOR_BASE - 
CONFIG_SYS_MALLOC_LEN)
-#endif
 #ifndef CONFIG_SYS_POST_WORD_ADDR
 # define CONFIG_SYS_POST_WORD_ADDR (L1_DATA_B_SRAM + L1_DATA_B_SRAM_SIZE - 4)
 #endif
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index e79486d..ea1350d 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -6258,7 +6258,6 @@ CONFIG_SYS_MACB1_BASE
 CONFIG_SYS_MACB2_BASE
 CONFIG_SYS_MACB3_BASE
 CONFIG_SYS_MAIN_PWR_ON
-CONFIG_SYS_MALLOC_BASE
 CONFIG_SYS_MALLOC_CLEAR_ON_INIT
 CONFIG_SYS_MALLOC_END
 CONFIG_SYS_MALLOC_LEN
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 13/29] tegra: Drop CONFIG_STACKBASE in favour of TEGRA_STACKBASE

2016-12-14 Thread Simon Glass
This should not really be a CONFIG option since it is only used as a way
of controlling another option. Rename it and remove it from the whitelist.

Signed-off-by: Simon Glass 
---

 include/configs/tegra-common.h| 2 +-
 include/configs/tegra114-common.h | 2 +-
 include/configs/tegra124-common.h | 2 +-
 include/configs/tegra186-common.h | 2 +-
 include/configs/tegra20-common.h  | 2 +-
 include/configs/tegra210-common.h | 2 +-
 include/configs/tegra30-common.h  | 2 +-
 scripts/config_whitelist.txt  | 1 -
 8 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index 63b711b..91d7e57 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -94,7 +94,7 @@
 
 #define CONFIG_SYS_BOOTMAPSZ   (256 << 20) /* 256M */
 
-#define CONFIG_SYS_INIT_RAM_ADDR   CONFIG_STACKBASE
+#define CONFIG_SYS_INIT_RAM_ADDR   TEGRA_STACKBASE
 #define CONFIG_SYS_INIT_RAM_SIZE   CONFIG_SYS_MALLOC_LEN
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \
CONFIG_SYS_INIT_RAM_SIZE - \
diff --git a/include/configs/tegra114-common.h 
b/include/configs/tegra114-common.h
index 107a0f8..89f954f 100644
--- a/include/configs/tegra114-common.h
+++ b/include/configs/tegra114-common.h
@@ -16,7 +16,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
+#define TEGRA_STACKBASE0x8280  /* 40MB */
 
 /*---
  * Physical Memory Map
diff --git a/include/configs/tegra124-common.h 
b/include/configs/tegra124-common.h
index 8cf9bac..0e6d281 100644
--- a/include/configs/tegra124-common.h
+++ b/include/configs/tegra124-common.h
@@ -18,7 +18,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
+#define TEGRA_STACKBASE0x8280  /* 40MB */
 
 /*---
  * Physical Memory Map
diff --git a/include/configs/tegra186-common.h 
b/include/configs/tegra186-common.h
index 98e4fc2..fba88b1 100644
--- a/include/configs/tegra186-common.h
+++ b/include/configs/tegra186-common.h
@@ -17,7 +17,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
+#define TEGRA_STACKBASE0x8280  /* 40MB */
 
 /*---
  * Physical Memory Map
diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h
index 793310f..d1f10c9 100644
--- a/include/configs/tegra20-common.h
+++ b/include/configs/tegra20-common.h
@@ -24,7 +24,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_STACKBASE   0x0280  /* 40MB */
+#define TEGRA_STACKBASE0x0280  /* 40MB */
 
 /*---
  * Physical Memory Map
diff --git a/include/configs/tegra210-common.h 
b/include/configs/tegra210-common.h
index 874fe34d..6d493bd 100644
--- a/include/configs/tegra210-common.h
+++ b/include/configs/tegra210-common.h
@@ -18,7 +18,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
+#define TEGRA_STACKBASE0x8280  /* 40MB */
 
 /*---
  * Physical Memory Map
diff --git a/include/configs/tegra30-common.h b/include/configs/tegra30-common.h
index baf3d00..655a863 100644
--- a/include/configs/tegra30-common.h
+++ b/include/configs/tegra30-common.h
@@ -23,7 +23,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
+#define TEGRA_STACKBASE0x8280  /* 40MB */
 
 /*---
  * Physical Memory Map
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 8814841..e79486d 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4242,7 +4242,6 @@ CONFIG_SSI2_FREQ
 CONFIG_SSP1_BASE
 CONFIG_SSP2_BASE
 CONFIG_SSP3_BASE
-CONFIG_STACKBASE
 CONFIG_STACKSIZE
 CONFIG_STACKSIZE_FIQ
 CONFIG_STACKSIZE_IRQ
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 11/29] blackfin: Allow cpu_init_f() to return

2016-12-14 Thread Simon Glass
Adjust the call sequence a little so that it follows ARM: board_init_f()
is called from assembly code.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c   | 6 --
 arch/blackfin/cpu/start.S | 3 ++-
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index 13f083f..0ae5ac6 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -301,7 +301,6 @@ int irq_init(void)
return 0;
 }
 
-__attribute__ ((__noreturn__))
 void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
 {
 #ifndef CONFIG_BFIN_BOOTROM_USES_EVT1
@@ -359,11 +358,6 @@ void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
 
serial_early_puts("Init global data\n");
global_board_data_init();
-
-   board_init_f(0);
-
-   /* should not be reached */
-   while (1);
 }
 
 int arch_cpu_init(void)
diff --git a/arch/blackfin/cpu/start.S b/arch/blackfin/cpu/start.S
index 0bba86b..404e710 100644
--- a/arch/blackfin/cpu/start.S
+++ b/arch/blackfin/cpu/start.S
@@ -228,7 +228,8 @@ ENTRY(_start)
 .Lenable_nested:
cli r7;
[--sp] = reti;
-   jump.l _cpu_init_f;
+   call _cpu_init_f;
+   call _board_init_f
 
 .LWAIT_HERE:
jump .LWAIT_HERE;
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 14/29] sparc: Drop CONFIG_SYS_MALLOC_BASE

2016-12-14 Thread Simon Glass
This is not used in U-Boot with generic board so there is no sense in
defining it. It just adds confusion.

Drop it from the config files.

Signed-off-by: Simon Glass 
---

 cmd/bdinfo.c   | 2 --
 include/configs/gr_cpci_ax2000.h   | 5 +
 include/configs/gr_ep2s60.h| 5 +
 include/configs/gr_xc3s_1500.h | 5 +
 include/configs/grsim.h| 5 +
 include/configs/grsim_leon2.h  | 5 +
 include/configs/openrisc-generic.h | 3 ---
 include/configs/s32v234evb.h   | 4 
 8 files changed, 5 insertions(+), 29 deletions(-)

diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index ae3027a..c8041fa 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -293,8 +293,6 @@ int do_bdinfo(cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])
print_num("CONFIG_ENV_ADDR   ", CONFIG_ENV_ADDR);
printf("CONFIG_SYS_RELOC_MONITOR_BASE = 0x%x (%d)\n", 
CONFIG_SYS_RELOC_MONITOR_BASE,
   CONFIG_SYS_MONITOR_LEN);
-   printf("CONFIG_SYS_MALLOC_BASE= 0x%x (%d)\n", 
CONFIG_SYS_MALLOC_BASE,
-  CONFIG_SYS_MALLOC_LEN);
printf("CONFIG_SYS_INIT_SP_OFFSET = 0x%x (%d)\n", 
CONFIG_SYS_INIT_SP_OFFSET,
   CONFIG_SYS_STACK_SIZE);
printf("CONFIG_SYS_PROM_OFFSET= 0x%x (%d)\n", 
CONFIG_SYS_PROM_OFFSET,
diff --git a/include/configs/gr_cpci_ax2000.h b/include/configs/gr_cpci_ax2000.h
index 211dc38..3c46d54 100644
--- a/include/configs/gr_cpci_ax2000.h
+++ b/include/configs/gr_cpci_ax2000.h
@@ -252,11 +252,8 @@
 #define CONFIG_SYS_MALLOC_LEN  (128 << 10) /* Reserve 128 kB for 
malloc()  */
 #define CONFIG_SYS_BOOTMAPSZ   (8 << 20)   /* Initial Memory map 
for Linux */
 
-#define CONFIG_SYS_MALLOC_END  
(CONFIG_SYS_INIT_SP_OFFSET-CONFIG_SYS_STACK_SIZE)
-#define CONFIG_SYS_MALLOC_BASE 
(CONFIG_SYS_MALLOC_END-CONFIG_SYS_MALLOC_LEN)
-
 /* relocated monitor area */
-#define CONFIG_SYS_RELOC_MONITOR_MAX_END   CONFIG_SYS_MALLOC_BASE
+#define CONFIG_SYS_RELOC_MONITOR_MAX_END  
(CONFIG_SYS_INIT_SP_OFFSET-CONFIG_SYS_STACK_SIZE)
 #define CONFIG_SYS_RELOC_MONITOR_BASE 
(CONFIG_SYS_RELOC_MONITOR_MAX_END-CONFIG_SYS_MONITOR_LEN)
 
 /* make un relocated address from relocated address */
diff --git a/include/configs/gr_ep2s60.h b/include/configs/gr_ep2s60.h
index ad0c126..d79de54 100644
--- a/include/configs/gr_ep2s60.h
+++ b/include/configs/gr_ep2s60.h
@@ -215,11 +215,8 @@
 #define CONFIG_SYS_MALLOC_LEN  (128 << 10) /* Reserve 128 kB for 
malloc()  */
 #define CONFIG_SYS_BOOTMAPSZ   (8 << 20)   /* Initial Memory map 
for Linux */
 
-#define CONFIG_SYS_MALLOC_END  
(CONFIG_SYS_INIT_SP_OFFSET-CONFIG_SYS_STACK_SIZE)
-#define CONFIG_SYS_MALLOC_BASE 
(CONFIG_SYS_MALLOC_END-CONFIG_SYS_MALLOC_LEN)
-
 /* relocated monitor area */
-#define CONFIG_SYS_RELOC_MONITOR_MAX_END   CONFIG_SYS_MALLOC_BASE
+#define CONFIG_SYS_RELOC_MONITOR_MAX_END  
(CONFIG_SYS_INIT_SP_OFFSET-CONFIG_SYS_STACK_SIZE)
 #define CONFIG_SYS_RELOC_MONITOR_BASE 
(CONFIG_SYS_RELOC_MONITOR_MAX_END-CONFIG_SYS_MONITOR_LEN)
 
 /* make un relocated address from relocated address */
diff --git a/include/configs/gr_xc3s_1500.h b/include/configs/gr_xc3s_1500.h
index b0e9001..164cb26 100644
--- a/include/configs/gr_xc3s_1500.h
+++ b/include/configs/gr_xc3s_1500.h
@@ -197,11 +197,8 @@
 #define CONFIG_SYS_MALLOC_LEN  (128 << 10) /* Reserve 128 kB for 
malloc()  */
 #define CONFIG_SYS_BOOTMAPSZ   (8 << 20)   /* Initial Memory map 
for Linux */
 
-#define CONFIG_SYS_MALLOC_END  
(CONFIG_SYS_INIT_SP_OFFSET-CONFIG_SYS_STACK_SIZE)
-#define CONFIG_SYS_MALLOC_BASE 
(CONFIG_SYS_MALLOC_END-CONFIG_SYS_MALLOC_LEN)
-
 /* relocated monitor area */
-#define CONFIG_SYS_RELOC_MONITOR_MAX_END   CONFIG_SYS_MALLOC_BASE
+#define CONFIG_SYS_RELOC_MONITOR_MAX_END  
(CONFIG_SYS_INIT_SP_OFFSET-CONFIG_SYS_STACK_SIZE)
 #define CONFIG_SYS_RELOC_MONITOR_BASE 
(CONFIG_SYS_RELOC_MONITOR_MAX_END-CONFIG_SYS_MONITOR_LEN)
 
 /* make un relocated address from relocated address */
diff --git a/include/configs/grsim.h b/include/configs/grsim.h
index 17cac5a..5bb4c74 100644
--- a/include/configs/grsim.h
+++ b/include/configs/grsim.h
@@ -212,11 +212,8 @@
 #define CONFIG_SYS_MALLOC_LEN  (128 << 10) /* Reserve 128 kB for 
malloc()  */
 #define CONFIG_SYS_BOOTMAPSZ   (8 << 20)   /* Initial Memory map 
for Linux */
 
-#define CONFIG_SYS_MALLOC_END  
(CONFIG_SYS_INIT_SP_OFFSET-CONFIG_SYS_STACK_SIZE)
-#define CONFIG_SYS_MALLOC_BASE 
(CONFIG_SYS_MALLOC_END-CONFIG_SYS_MALLOC_LEN)
-
 /* relocated monitor area */
-#define CONFIG_SYS_RELOC_MONITOR_MAX_END   CONFIG_SYS_MALLOC_BASE
+#define CONFIG_SYS_RELOC_MONITOR_MAX_END  
(CONFIG_SYS_INIT_SP_OFFSET-CONFIG_SYS_STACK_SIZE)
 #define CONFIG_SYS_RELOC_MONITOR_BASE 
(CONFIG_SYS_RELOC_MONITOR_MAX_END-CONFIG_SYS_MONITOR_LEN)
 
 /* make un relocated address from relocated address */

[U-Boot] [PATCH 08/29] blackfin: Use generic board to set the stack address

2016-12-14 Thread Simon Glass
Rather than using a hard-coded stack address, call
board_init_f_alloc_reserve() and board_init_f_init_reserve() and use the
stack address thus obtained. This makes blackfin more like other archs.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/start.S | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/blackfin/cpu/start.S b/arch/blackfin/cpu/start.S
index 01985ea..5e19ad2 100644
--- a/arch/blackfin/cpu/start.S
+++ b/arch/blackfin/cpu/start.S
@@ -191,11 +191,16 @@ ENTRY(_start)
 #endif
 
 .Lnorelocate:
+   r0.l = LO(CONFIG_SYS_EARLY_SP_TOP)
+   r0.h = HI(CONFIG_SYS_EARLY_SP_TOP)
+   call _board_init_f_alloc_reserve
+
/* Setup the actual stack in external memory */
-   sp.h = HI(CONFIG_STACKBASE);
-   sp.l = LO(CONFIG_STACKBASE);
+   sp = r0
fp = sp;
 
+   call _board_init_f_init_reserve
+
/* Now lower ourselves from the highest interrupt level to
 * the lowest.  We do this by masking all interrupts but 15,
 * setting the 15 handler to ".Lenable_nested", raising the 15
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 09/29] blackfin: Avoid using bd_info in print_cpuinfo()

2016-12-14 Thread Simon Glass
We should not be setting up board info so early. With generic board the
gd->bd pointer is not valid until reserve_board() is called, much later in
the init sequence.

As a first step, adjust print_cpuinfo() to use the CONFIG instead of the
board info.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index ef362d4..13f083f 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -242,7 +242,7 @@ int print_cpuinfo(void)
char buf[32];
 
printf("CPU:   ADSP %s (Detected Rev: 0.%d) (%s boot)\n",
-  gd->bd->bi_cpu,
+  __stringify(CONFIG_BFIN_CPU),
   bfin_revid(),
   get_bfin_boot_mode(CONFIG_BFIN_BOOT_MODE));
 
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 06/29] blackfin: Clear the BSS in C code

2016-12-14 Thread Simon Glass
We don't need to clear BSS in assembler. Move it to C to reduce the amount
of assembly code needed.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/cpu.c   |  3 +++
 arch/blackfin/cpu/start.S | 13 -
 2 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index 529322a..ef362d4 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -323,6 +324,8 @@ void cpu_init_f(ulong bootflag, ulong loaded_from_ldr)
memcpy(&_sdata_l1, &_data_l1_lma, (unsigned long)_data_l1_len);
}
 
+   memset(__bss_start, '\0', __bss_stop - __bss_start);
+
/*
 * Make sure our async settings are committed.  Some bootroms
 * (like the BF537) will reset some registers on us after it
diff --git a/arch/blackfin/cpu/start.S b/arch/blackfin/cpu/start.S
index 6265a51..01985ea 100644
--- a/arch/blackfin/cpu/start.S
+++ b/arch/blackfin/cpu/start.S
@@ -191,19 +191,6 @@ ENTRY(_start)
 #endif
 
 .Lnorelocate:
-   /* Initialize BSS section ... we know that memset() does not
-* use the BSS, so it is safe to call here.  The bootrom LDR
-* takes care of clearing things for us.
-*/
-   serial_early_puts("Zero BSS");
-   r0.l = ___bss_start;
-   r0.h = ___bss_start;
-   r1 = 0 (x);
-   r2.l = __bss_len;
-   r2.h = __bss_len;
-   call _memset;
-
-
/* Setup the actual stack in external memory */
sp.h = HI(CONFIG_STACKBASE);
sp.l = LO(CONFIG_STACKBASE);
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 10/29] blackfin: Avoiding using P3 in early init

2016-12-14 Thread Simon Glass
The P3 register is used to hold the global_data pointer. At present this
is not set up until cpu_init_f() is called, but we want to instead set it
up using the standard board_init_f_init_reserve() function. To avoid it
being overwritten use P2 instead of P3 in early init.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/start.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/blackfin/cpu/start.S b/arch/blackfin/cpu/start.S
index 5e19ad2..0bba86b 100644
--- a/arch/blackfin/cpu/start.S
+++ b/arch/blackfin/cpu/start.S
@@ -219,9 +219,9 @@ ENTRY(_start)
r7 = EVT_IVG15 (z);
sti r7;
raise 15;
-   p3.l = .LWAIT_HERE;
-   p3.h = .LWAIT_HERE;
-   reti = p3;
+   p2.l = .LWAIT_HERE;
+   p2.h = .LWAIT_HERE;
+   reti = p2;
rti;
 
/* Enable nested interrupts before continuing with cpu init */
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 07/29] blackfin: Add a memory region for pre-relocation data

2016-12-14 Thread Simon Glass
With generic board, U-Boot expects to have a regions of memory to use
before relocation for the stack and early malloc(). Blackfin works around
this and 'accurately guesses' the final location of several regions very
early during boot. It also uses BSS space to hold global_data.

It would be better if Blackfin followed other boards and uses the existing
early allocation functions. Since RAM is set up quite early, we can put
things in RAM instead of the small scratch space.

As a first step, define the top of the early memory region:
CONFIG_SYS_EARLY_SP_TOP.

Signed-off-by: Simon Glass 
---

 arch/blackfin/Kconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index 0a2fb4d..934e089 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -4,6 +4,15 @@ menu "Blackfin architecture"
 config SYS_ARCH
default "blackfin"
 
+config SYS_EARLY_SP_TOP
+   hex "Top of early memory region"
+   default 0x10
+   help
+ Before relocation U-Boot needs some space for the stack and the
+ early malloc() implementation. This is an arbitrary location but
+ since U-Boot relocates to the top of RAM it should be fairly
+ low to avoid conflict.
+
 choice
prompt "Target select"
optional
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 05/29] blackfin: Use compiler-generated symbols for BSS

2016-12-14 Thread Simon Glass
Adjust the code to work as on ARM, where the compiler generates the BSS
symbols. This makes it easier to move the BSS memset() to C code.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/start.S|  4 ++--
 arch/blackfin/cpu/u-boot.lds | 18 --
 arch/blackfin/lib/sections.c |  2 +-
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/arch/blackfin/cpu/start.S b/arch/blackfin/cpu/start.S
index 823a1df..6265a51 100644
--- a/arch/blackfin/cpu/start.S
+++ b/arch/blackfin/cpu/start.S
@@ -196,8 +196,8 @@ ENTRY(_start)
 * takes care of clearing things for us.
 */
serial_early_puts("Zero BSS");
-   r0.l = __bss_start;
-   r0.h = __bss_start;
+   r0.l = ___bss_start;
+   r0.h = ___bss_start;
r1 = 0 (x);
r2.l = __bss_len;
r2.h = __bss_len;
diff --git a/arch/blackfin/cpu/u-boot.lds b/arch/blackfin/cpu/u-boot.lds
index 1c0df25..ba95bf3 100644
--- a/arch/blackfin/cpu/u-boot.lds
+++ b/arch/blackfin/cpu/u-boot.lds
@@ -130,6 +130,16 @@ SECTIONS
__end = __data_l1_lma;
__image_binary_end = __data_l1_lma;
 
+   /*
+* Compiler-generated __bss_start and __bss_stop:
+* see arch/blackfin/lib/sections.c
+   */
+   .bss_start (NOLOAD) :
+   {
+   . = ALIGN(4);
+   KEEP(*(.__bss_start));
+   } >ram_data
+
.bss :
{
. = ALIGN(4);
@@ -139,8 +149,12 @@ SECTIONS
*(COMMON)
. = ALIGN(4);
} >ram_data
-   __bss_end = .;
-   __bss_start = ADDR(.bss);
+
+   .bss_stop (NOLOAD):
+   {
+   KEEP(*(.__bss_stop));
+   } >ram_data
+
__bss_len = SIZEOF(.bss);
__init_end = .;
 }
diff --git a/arch/blackfin/lib/sections.c b/arch/blackfin/lib/sections.c
index 86fc4df..a67530b 100644
--- a/arch/blackfin/lib/sections.c
+++ b/arch/blackfin/lib/sections.c
@@ -7,5 +7,5 @@
  */
 
 char __bss_start[0] __attribute__((section(".__bss_start")));
-char __bss_end[0] __attribute__((section(".__bss_end")));
+char __bss_stop[0] __attribute__((section(".__bss_stop")));
 char __init_end[0] __attribute__((section(".__init_end")));
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 02/29] fdt: Allow the device tree to be set up by board init code

2016-12-14 Thread Simon Glass
On blackfin we need to relocate the device tree early on during boot
because it breaks the rules of not accessing BSS before relocation. To
accommodate this, add a check to see if the device tree pointer is already
set up. If it is, leave it alone.

Signed-off-by: Simon Glass 
---

 lib/fdtdec.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4e619c4..c484950 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1177,26 +1177,31 @@ int fdtdec_decode_display_timing(const void *blob, int 
parent, int index,
 int fdtdec_setup(void)
 {
 #if CONFIG_IS_ENABLED(OF_CONTROL)
+   if (!gd->fdt_blob) {
 # ifdef CONFIG_OF_EMBED
-   /* Get a pointer to the FDT */
-   gd->fdt_blob = __dtb_dt_begin;
+   /* Get a pointer to the FDT */
+   gd->fdt_blob = __dtb_dt_begin;
 # elif defined CONFIG_OF_SEPARATE
 #  ifdef CONFIG_SPL_BUILD
-   /* FDT is at end of BSS unless it is in a different memory region */
-   if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
-   gd->fdt_blob = (ulong *)&_image_binary_end;
-   else
-   gd->fdt_blob = (ulong *)&__bss_end;
+   /*
+* FDT is at end of BSS unless it is in a different memory
+* region
+*/
+   if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
+   gd->fdt_blob = (ulong *)&_image_binary_end;
+   else
+   gd->fdt_blob = (ulong *)&__bss_end;
 #  else
-   /* FDT is at end of image */
-   gd->fdt_blob = (ulong *)&_end;
+   /* FDT is at end of image */
+   gd->fdt_blob = (ulong *)&_end;
 #  endif
 # elif defined(CONFIG_OF_HOSTFILE)
-   if (sandbox_read_fdt_from_file()) {
-   puts("Failed to read control FDT\n");
-   return -1;
-   }
+   if (sandbox_read_fdt_from_file()) {
+   puts("Failed to read control FDT\n");
+   return -1;
+   }
 # endif
+   }
 # ifndef CONFIG_SPL_BUILD
/* Allow the early environment to override the fdt address */
gd->fdt_blob = (void *)getenv_ulong("fdtcontroladdr", 16,
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 04/29] blackfin: Drop the extra blank line in the link script

2016-12-14 Thread Simon Glass
There is an extra blank line in this script. Drop it.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/u-boot.lds | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/blackfin/cpu/u-boot.lds b/arch/blackfin/cpu/u-boot.lds
index 30964ad..1c0df25 100644
--- a/arch/blackfin/cpu/u-boot.lds
+++ b/arch/blackfin/cpu/u-boot.lds
@@ -99,7 +99,6 @@ SECTIONS
CONSTRUCTORS
} >ram_data
 
-
.u_boot_list : {
KEEP(*(SORT(.u_boot_list*)));
} >ram_data
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 03/29] blackfin: Add a few useful linker symbols

2016-12-14 Thread Simon Glass
Add _image_copy_start, __end and __image_binary_end so we can use the
standard mechanism for locating the device tree. This only works if data
follow text, so use an #ifdef to ensure that for now.

Signed-off-by: Simon Glass 
---

 arch/blackfin/cpu/u-boot.lds | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/blackfin/cpu/u-boot.lds b/arch/blackfin/cpu/u-boot.lds
index f407fb2..30964ad 100644
--- a/arch/blackfin/cpu/u-boot.lds
+++ b/arch/blackfin/cpu/u-boot.lds
@@ -61,6 +61,9 @@ SECTIONS
 {
.text.pre :
{
+#ifndef CONFIG_MEM_SIZE
+   _image_copy_start = .;
+#endif
arch/blackfin/cpu/start.o (.text .text.*)
 
LDS_BOARD_TEXT
@@ -125,6 +128,8 @@ SECTIONS
__data_l1_lma = LOADADDR(.data_l1);
__data_l1_len = SIZEOF(.data_l1);
ASSERT (__data_l1_len <= L1_DATA_B_SRAM_SIZE, "L1 data overflow!")
+   __end = __data_l1_lma;
+   __image_binary_end = __data_l1_lma;
 
.bss :
{
-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 00/29] blackfin: Add driver-model and device tree suport

2016-12-14 Thread Simon Glass
At present the only serial driver that is not converted to driver mode is
blackfin. As I recently obtained a suitable board from a kind donor I have
decided to convert the driver over, as the unpalatable alternative would
be to remove blackfin support from U-Boot.

Blackfin's init sequence is someone non-standard. This series adjusts this
to fit more with how things are now done, adds device-tree support, a
serial driver and enables driver model on bf537-stamp.

A few CONFIG options are dropped in this series also, as these were
noticed along the way.

Future work could enhance the serial driver to support v4 hardware and
convert all boards to driver model.


Simon Glass (29):
  blackfin: Drop CONFIG_SYS_MEMTEST_START/END
  fdt: Allow the device tree to be set up by board init code
  blackfin: Add a few useful linker symbols
  blackfin: Drop the extra blank line in the link script
  blackfin: Use compiler-generated symbols for BSS
  blackfin: Clear the BSS in C code
  blackfin: Add a memory region for pre-relocation data
  blackfin: Use generic board to set the stack address
  blackfin: Avoid using bd_info in print_cpuinfo()
  blackfin: Avoiding using P3 in early init
  blackfin: Allow cpu_init_f() to return
  blackfin: Drop CONFIG_STACKBASE
  tegra: Drop CONFIG_STACKBASE in favour of TEGRA_STACKBASE
  sparc: Drop CONFIG_SYS_MALLOC_BASE
  blackfin: Drop CONFIG_SYS_MALLOC_BASE
  Drop CONFIG_SYS_MALLOC_END
  blackfin: Call C code to relocate
  blackfin: Don't set global_data again
  blackfin: Set the RAM size separately from bd_info
  blackfin: Set up bd_info later
  blackfin: Copy the device tree out of BSS
  blackfin: Allow use of CONFIG_OF_CONTROL
  blackfin: bf537-stamp: Enable CONFIG_OF_CONTROL
  dm: serial: Reset the watchdog when outputting characters
  dm: serial: pxa: Drop pxa from the serial README
  dm: serial: Update the serial README
  dm: blackfin: Add a driver-model serial driver
  blackfin: Set up the debug UART if enabled
  blackfin: Enable driver-model on bf537-stamp

 arch/Kconfig|   1 +
 arch/blackfin/Kconfig   |   9 ++
 arch/blackfin/cpu/cpu.c |  69 +++--
 arch/blackfin/cpu/start.S   |  35 +++
 arch/blackfin/cpu/u-boot.lds|  24 -
 arch/blackfin/dts/Makefile  |  18 
 arch/blackfin/dts/bf537-stamp.dts   |  11 +++
 arch/blackfin/include/asm/config.h  |  12 ---
 arch/blackfin/include/asm/serial1.h |   2 +
 arch/blackfin/include/asm/u-boot.h  |   5 +
 arch/blackfin/lib/sections.c|   2 +-
 cmd/bdinfo.c|   2 -
 configs/bf537-stamp_defconfig   |   8 ++
 doc/driver-model/serial-howto.txt   |  11 +--
 drivers/serial/Kconfig  |   8 ++
 drivers/serial/serial-uclass.c  |   2 +
 drivers/serial/serial_bfin.c| 192 
 include/configs/bf537-stamp.h   |   1 +
 include/configs/bf609-ezkit.h   |   1 -
 include/configs/gr_cpci_ax2000.h|   5 +-
 include/configs/gr_ep2s60.h |   5 +-
 include/configs/gr_xc3s_1500.h  |   5 +-
 include/configs/grsim.h |   5 +-
 include/configs/grsim_leon2.h   |   5 +-
 include/configs/openrisc-generic.h  |   3 -
 include/configs/s32v234evb.h|   4 -
 include/configs/tegra-common.h  |   2 +-
 include/configs/tegra114-common.h   |   2 +-
 include/configs/tegra124-common.h   |   2 +-
 include/configs/tegra186-common.h   |   2 +-
 include/configs/tegra20-common.h|   2 +-
 include/configs/tegra210-common.h   |   2 +-
 include/configs/tegra30-common.h|   2 +-
 lib/fdtdec.c|  31 +++---
 scripts/config_whitelist.txt|   3 -
 35 files changed, 360 insertions(+), 133 deletions(-)
 create mode 100644 arch/blackfin/dts/Makefile
 create mode 100644 arch/blackfin/dts/bf537-stamp.dts

-- 
2.8.0.rc3.226.g39d4020

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


[U-Boot] [PATCH 01/29] blackfin: Drop CONFIG_SYS_MEMTEST_START/END

2016-12-14 Thread Simon Glass
These are not used since the 'mtest' command is not enabled on blackfin.
They are also a pain since they pre-suppose the memory layout. Drop them.

Signed-off-by: Simon Glass 
---

 arch/blackfin/include/asm/config.h | 6 --
 include/configs/bf609-ezkit.h  | 1 -
 2 files changed, 7 deletions(-)

diff --git a/arch/blackfin/include/asm/config.h 
b/arch/blackfin/include/asm/config.h
index de3c979..27e8f3d 100644
--- a/arch/blackfin/include/asm/config.h
+++ b/arch/blackfin/include/asm/config.h
@@ -112,12 +112,6 @@
 #ifndef CONFIG_STACKBASE
 # define CONFIG_STACKBASE (CONFIG_SYS_MALLOC_BASE - 4)
 #endif
-#ifndef CONFIG_SYS_MEMTEST_START
-# define CONFIG_SYS_MEMTEST_START 0
-#endif
-#ifndef CONFIG_SYS_MEMTEST_END
-# define CONFIG_SYS_MEMTEST_END (CONFIG_STACKBASE - 8192 + 4)
-#endif
 #ifndef CONFIG_SYS_POST_WORD_ADDR
 # define CONFIG_SYS_POST_WORD_ADDR (L1_DATA_B_SRAM + L1_DATA_B_SRAM_SIZE - 4)
 #endif
diff --git a/include/configs/bf609-ezkit.h b/include/configs/bf609-ezkit.h
index 4deb2d2..76bb485 100644
--- a/include/configs/bf609-ezkit.h
+++ b/include/configs/bf609-ezkit.h
@@ -138,7 +138,6 @@
 
 #define CONFIG_CMD_SOFTSWITCH
 
-#define CONFIG_SYS_MEMTEST_END (CONFIG_STACKBASE - 20*1024*1024 + 4)
 #define CONFIG_BFIN_SOFT_SWITCH
 
 #define CONFIG_ADI_GPIO2
-- 
2.8.0.rc3.226.g39d4020

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


Re: [U-Boot] [PATCH] usb: dwc2_udc_otg: remove the driver_desc as unused variable

2016-12-14 Thread Marek Vasut
On 12/15/2016 03:02 AM, Jaehoon Chung wrote:
> This patch fixes for the below warning.
> 
> drivers/usb/gadget/dwc2_udc_otg.c:72:19: warning: 'driver_desc' defined but 
> not used [-Wunused-const-variable=]
>  static const char driver_desc[] = DRIVER_DESC;
> 
> Signed-off-by: Jaehoon Chung 

Masahiro already sent such patch, thanks though.

> ---
>  drivers/usb/gadget/dwc2_udc_otg.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
> b/drivers/usb/gadget/dwc2_udc_otg.c
> index d72bfdf..cb44374 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
> @@ -63,13 +63,11 @@ static char *state_names[] = {
>   "WAIT_FOR_NULL_COMPLETE",
>  };
>  
> -#define DRIVER_DESC "DWC2 HS USB OTG Device Driver, (c) Samsung Electronics"
>  #define DRIVER_VERSION "15 March 2009"
>  
>  struct dwc2_udc  *the_controller;
>  
>  static const char driver_name[] = "dwc2-udc";
> -static const char driver_desc[] = DRIVER_DESC;
>  static const char ep0name[] = "ep0-control";
>  
>  /* Max packet size*/
> 


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


[U-Boot] [PATCH] usb: dwc2_udc_otg: remove the driver_desc as unused variable

2016-12-14 Thread Jaehoon Chung
This patch fixes for the below warning.

drivers/usb/gadget/dwc2_udc_otg.c:72:19: warning: 'driver_desc' defined but not 
used [-Wunused-const-variable=]
 static const char driver_desc[] = DRIVER_DESC;

Signed-off-by: Jaehoon Chung 
---
 drivers/usb/gadget/dwc2_udc_otg.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index d72bfdf..cb44374 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -63,13 +63,11 @@ static char *state_names[] = {
"WAIT_FOR_NULL_COMPLETE",
 };
 
-#define DRIVER_DESC "DWC2 HS USB OTG Device Driver, (c) Samsung Electronics"
 #define DRIVER_VERSION "15 March 2009"
 
 struct dwc2_udc*the_controller;
 
 static const char driver_name[] = "dwc2-udc";
-static const char driver_desc[] = DRIVER_DESC;
 static const char ep0name[] = "ep0-control";
 
 /* Max packet size*/
-- 
2.10.2

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


Re: [U-Boot] Pull request: u-boot-spi/master

2016-12-14 Thread Tom Rini
On Wed, Dec 14, 2016 at 04:36:58PM +0100, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> thanks!
> Jagan.
> 
> The following changes since commit 136179bec19f4bc84227cba138214ea392a723ea:
> 
>   colibri_pxa270: transition to driver model for serial (2016-11-23 13:53:20 
> +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 6c11b3a89fe9cd5ef8070b2a13103f6f466860f1:
> 
>   sf: Do not force the DT memory map size to exactly match the device 
> (2016-12-14 16:30:04 +0100)
> 

NAK:
https://travis-ci.org/trini/u-boot/jobs/184036802

Please fix, thanks!

-- 
Tom


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


Re: [U-Boot] [RFC PATCH 2/3] sunxi: video: Add video driver for H3 SoC

2016-12-14 Thread Jernej Škrabec
Hi,

On Wed, Dec 14, 2016 at 11:28:43 CET, Maxime Ripard wrote:
> Hi,
> 
> On Tue, Dec 13, 2016 at 09:13:11PM +0100, Jernej Škrabec wrote:
> > Hi,
> > 
> > On Tue, Dec 13, 2016 at 16:40:55 CET, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Tue, Dec 13, 2016 at 01:36:29AM +0100, Jernej Skrabec wrote:
> > > > This patch adds support for hdmi output. It is designed in the same
> > > > way as video driver for older Allwinner SoCs.
> > > > 
> > > > First it checks if monitor is attached. If it is, recommended
> > > > timings are read from EDID. After that, DE2, TCON and HDMI are
> > > > configured according to this timings.
> > > > 
> > > > 32MB of RAM is used for framebuffer. This is just enough to support
> > > > 4K resolution.
> > > > 
> > > > SimpleFB is also supported by this driver.
> > > > 
> > > > Signed-off-by: Jernej Skrabec 
> > > 
> > > From the linux discussion, I recall that you said that the TCON was
> > > still the same, and the HDMI was something that could be shared with
> > > the Rockchip implementation. Did you look into sharing the TCON code
> > > (for example using a small "library" to share the functions) and to
> > > reuse Rockchip's HDMI code?
> > 
> > For now, I only reused one TCON function and some defines. I tought that
> > split would be better done a bit later, when the driver will get support
> > for LCD screens (A64, for example). At that time TCON code would also be
> > refactored to be more generic and properly tested that it can be used
> > with both drivers. Unfortunatelly, I don't have any board with older SoC
> > for testing.
> We can definitely do that. I think I have access to at least of board
> of each generation, so I can totally test whatever you come up with on
> those boards, and help you debugging whatever issue that might show up.
> 
> > While I took Rockchip HDMI code for reference, it can't be easily reused.
> > First of, it uses DT nodes. I guess I could write DT binding or modify
> > existing driver to work without it.
> 
> Like we discussed in the other part of the thread, I think the latter
> would be easier to deal with.

I forgot to mention that it also uses driver model. The way I would go with 
this is to split out common code to dwc_hdmi.c and have platform dependant 
drivers for Rockchip, Allwinner, etc. Basically the same way as it is done in 
Linux.

> 
> > Second issue here is same as in Linux, PHY code is tightly coupled
> > with controller code, so it needs to be decoupled first.
> 
> But it would be easier to deal with than Linux I guess. Can't you just
> create a new weak function to initialise the phy? And then, every
> platform can just overwrite it.

PHY functions are relatively self contained (~3 of them). If I develop my idea 
with shared code further, I could make phy_init() function weak and other two 
functions just public. Rockchip driver will use them, H3 won't. They will come 
handy for A83T and A80 HDMI driver, which uses DWC HDMI PHY. Well, phy_init() 
function needs to be further generalized (mpll table used in phy_init() is SoC 
specific), but I guess we will worry about that later.

> 
> > Thirdly, and in my opinion most annoying, Rockchip driver uses 32
> > bit aligned registers, but H3 does not. This also means a lot of
> > work to make it more generic.
> 
> How does Linux deal with that? Would just using some kind of accessors
> that would abstract that away from the driver help, or is it more
> complicated?

Yes, Linux driver checks "reg-io-width" property and selects accessors 
accordingly. I suppose I could do similar, save function pointer in a driver 
private data. I suppose it is ok that platform specific code initializes this 
private data?

> 
> > Actually, H3 is more similar to i.MX6 HDMI in this regard, but
> > driver's code is scattered throughout multiple files (search for
> > mxc_hdmi.h inclusion). It is certainly doable, but it will take much
> > more time.  Basically, U-Boot already has two drivers for DWC HDMI
> > and with this patch it will get third. Merging all three
> > implementations into one would be very tedious, but very desirable
> > goal. I must state that I didn't really try to understand i.MX6 HDMI
> > code at all, so I don't now how hard it would be to pull it out.
> 
> I'm not sure that merging a third and saying that it would be up to
> the fourth to do the work is reasonable. It's just hiding an issue
> under the carpet, but I don't see how it will be easier for the next
> person to work on that. Quite the opposite actually.

True. I wonder if Renesas already prepared U-Boot DWC HDMI driver...

Do you think it makes sense to put all files related to Allwinner video drivers 
to sunxi subfolder? There will be at least 4 .c files according to my plan and 
even more in the future (at least for TV out driver).

Best regards,
Jernej Škrabec

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



Re: [U-Boot] [PATCH] zynq: spi: Honour the activation / deactivation delay

2016-12-14 Thread Moritz Fischer
Whoops,

On Thu, Dec 8, 2016 at 12:11 PM, Moritz Fischer
 wrote:
> This is not currently implemented. Add support for this so that the
> Chrome OS EC can be used reliably.
>
> Signed-off-by: Moritz Fischer 
> Cc: Jagan Teki 
> Cc: Simon Glass 
> Cc: u-boot@lists.denx.de
Cc: Michal Simek 

> ---
>  drivers/spi/zynq_spi.c | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/drivers/spi/zynq_spi.c b/drivers/spi/zynq_spi.c
> index 15ca271..5e7954c 100644
> --- a/drivers/spi/zynq_spi.c
> +++ b/drivers/spi/zynq_spi.c
> @@ -56,6 +56,8 @@ struct zynq_spi_platdata {
> struct zynq_spi_regs *regs;
> u32 frequency;  /* input frequency */
> u32 speed_hz;
> +   uint deactivate_delay_us;   /* Delay to wait after deactivate */
> +   uint activate_delay_us; /* Delay to wait after activate */
>  };
>
>  /* zynq spi priv */
> @@ -63,6 +65,7 @@ struct zynq_spi_priv {
> struct zynq_spi_regs *regs;
> u8 cs;
> u8 mode;
> +   ulong last_transaction_us;  /* Time of last transaction end */
> u8 fifo_depth;
> u32 freq;   /* required frequency */
>  };
> @@ -78,6 +81,10 @@ static int zynq_spi_ofdata_to_platdata(struct udevice *bus)
> /* FIXME: Use 250MHz as a suitable default */
> plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency",
> 25000);
> +   plat->deactivate_delay_us = fdtdec_get_int(blob, node,
> +   "spi-deactivate-delay", 0);
> +   plat->activate_delay_us = fdtdec_get_int(blob, node,
> +"spi-activate-delay", 0);
> plat->speed_hz = plat->frequency / 2;
>
> debug("%s: regs=%p max-frequency=%d\n", __func__,
> @@ -133,10 +140,19 @@ static int zynq_spi_probe(struct udevice *bus)
>  static void spi_cs_activate(struct udevice *dev)
>  {
> struct udevice *bus = dev->parent;
> +   struct zynq_spi_platdata *plat = bus->platdata;
> struct zynq_spi_priv *priv = dev_get_priv(bus);
> struct zynq_spi_regs *regs = priv->regs;
> u32 cr;
>
> +   /* If it's too soon to do another transaction, wait */
> +   if (plat->deactivate_delay_us && priv->last_transaction_us) {
> +   ulong delay_us; /* The delay completed so far */
> +   delay_us = timer_get_us() - priv->last_transaction_us;
> +   if (delay_us < plat->deactivate_delay_us)
> +   udelay(plat->deactivate_delay_us - delay_us);
> +   }
> +
> clrbits_le32(>cr, ZYNQ_SPI_CR_CS_MASK);
> cr = readl(>cr);
> /*
> @@ -147,15 +163,23 @@ static void spi_cs_activate(struct udevice *dev)
>  */
> cr |= (~(1 << priv->cs) << ZYNQ_SPI_CR_SS_SHIFT) & 
> ZYNQ_SPI_CR_CS_MASK;
> writel(cr, >cr);
> +
> +   if (plat->activate_delay_us)
> +   udelay(plat->activate_delay_us);
>  }
>
>  static void spi_cs_deactivate(struct udevice *dev)
>  {
> struct udevice *bus = dev->parent;
> +   struct zynq_spi_platdata *plat = bus->platdata;
> struct zynq_spi_priv *priv = dev_get_priv(bus);
> struct zynq_spi_regs *regs = priv->regs;
>
> setbits_le32(>cr, ZYNQ_SPI_CR_CS_MASK);
> +
> +   /* Remember time of this transaction so we can honour the bus delay */
> +   if (plat->deactivate_delay_us)
> +   priv->last_transaction_us = timer_get_us();
>  }
>
>  static int zynq_spi_claim_bus(struct udevice *dev)
> --
> 2.7.4
>

Thanks,

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


Re: [U-Boot] [PATCHv5 02/17] dm: pci: return the real controller in pci_bus_to_hose()

2016-12-14 Thread Z.Q. Hou
Hi Bin,

Thanks for your review!

B.R
Zhiqiang

> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: 2016年12月13日 15:48
> To: Z.Q. Hou 
> Cc: U-Boot Mailing List ; Albert ARIBAUD
> ; Prabhakar Kushwaha
> ; Alison Wang ;
> Sumit Garg ; Ruchika Gupta ;
> york sun ; M.H. Lian ; Simon
> Glass ; Mingkai Hu 
> Subject: Re: [PATCHv5 02/17] dm: pci: return the real controller in
> pci_bus_to_hose()
> 
> On Tue, Dec 13, 2016 at 2:54 PM, Zhiqiang Hou 
> wrote:
> > From: Minghuan Lian 
> >
> > for the legacy PCI driver, the function pci_bus_to_hose() returns the
> > real PCIe controller. To keep consistency, this function is changed to
> > return the PCIe controller pointer of the root bus instead of the
> > current PCIe bus.
> >
> > Signed-off-by: Minghuan Lian 
> > Signed-off-by: Hou Zhiqiang 
> > Reviewed-by: Simon Glass 
> > ---
> > V5:
> >  - No change
> >
> >  drivers/pci/pci_compat.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> 
> Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Intel e1000 PHY HW reset timeout reasons?

2016-12-14 Thread Kostya Porotchkin
Hello,

I am currently working on u-boot mainline code supporting Marvell
Armada armv8 platforms (80x0, 70x0, 37x0).
During this coding and testing cycles I found a very strange issue
related to u-boot e1000 network driver.
The PCIe e1000 NIC is tested on 2 platforms based on the same SoC (8040).
On one of these platforms the e1000 card is properly detected on PCIe
bus, but fails to activate the HW due to HW PHY reset timeout.
If I bypass the timeout error, the e1000 card continues to work without
any problem and I am able to run a full Linux system with root on NFS
using this network card.
Below is the (ugly) change that solves me the PHY reset timeout problem:

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 3332ad9..a40b009 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -4361,7 +4361,7 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
if (!timeout) {
DEBUGOUT("MNG configuration cycle has not "
"completed.\n");
-   return -E1000_ERR_RESET;
+// return -E1000_ERR_RESET;
}
break;

I have found that the similar issue has already been discussed in this 
email list, but the driver code was not changed and the timeout seems
to happen in some test cases.
http://lists.denx.de/pipermail/u-boot/2014-September/188544.html

I would be glad to get an idea about such timeout reasons and ways to
solve this issue on my development platform.

Both my platforms are based on Marvell Armada 8040 SoC.

1. Platform-1: PCIe x1, card reset connected to system reset wire
   No driver WA required.

2. Platform-2: PCIe x4, card reset connected to GPIO,
   reset released upon PCIe bus probe.
   e1000 driver WA required for a normal operation.

==
E1000 debug log on Platform-2:
==

=> pci enum
PCIE-0: Link up (Gen1-x1, Bus0)
=> pci 1
Scanning PCI devices on bus 1
BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
_
01.00.00   0x8086 0x107d Network controller  0x00

=> ping 192.168.100.200
e1000: e1000#0: DEBUG: iobase 0xf600
e1000_set_mac_type
e1000_set_media_type
copper interface
e1000_reset_hw
Masking off all interrupts
Issuing a global reset to MAC
Masking off all interrupts
e1000_init_eeprom_params
e1000_read_mac_addr
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000: 68:05:ca:12:4d:dc
   
Warning: e1000#0 MAC addresses don't match:
Address in SROM is 68:05:ca:12:4d:dc
Address in environment is  00:00:00:00:51:81
e1000_reset_hw
Masking off all interrupts
Issuing a global reset to MAC
Masking off all interrupts
e1000_init_hw
e1000_set_media_type
Initializing the IEEE VLAN
e1000_init_rx_addrs
Programming MAC Address into RAR[0]
Clearing RAR[1-15]
Zeroing the MTA
e1000_setup_link
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
After fix-ups FlowControl is now = 3
e1000_setup_copper_link
e1000_copper_link_preconfig
e1000_detect_gig_phy
Phy ID = 2a80380
e1000_set_phy_mode
e1000_copper_link_igp_setup
e1000_phy_reset
e1000_phy_hw_reset
Resetting Phy...
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_get_phy_cfg_done
MNG configuration cycle has not completed.
Error Resetting the PHY
e1000: e1000#0: ERROR: Hardware Initialization Failed
ping failed; host 192.168.100.200 is not alive
==

Thank you beforehand for your help.

Best Regards

Re: [U-Boot] [PATCH] sunxi: enable H3 EMAC for the nanopi neo

2016-12-14 Thread Jagan Teki
On Tue, Dec 6, 2016 at 5:07 PM, Maxime Ripard
 wrote:
> On Mon, Dec 05, 2016 at 07:47:21PM +0100, Jelle van der Waa wrote:
>> The nanopi already had the CONFIG_SUN8I_EMAC=y enabled in it's defconfig
>> file, but was missing the  the device tree entry.
>>
>> Signed-off-by: Jelle van der Waa 
>
> Acked-by: Maxime Ripard 

Applied to u-boot-sunxi/master

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


Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

2016-12-14 Thread Mike Looijmans



I am not marketing guy to say how often there are designs with only
different DDR size like Mike's example but in fpga world you are not
buying this chip to have only static part but you want to use fpga part
and for that you need to use design tools. Because every design is
unique you can generate device tree description directly from design
tools which covers your target and this is what I believe people use.


Well, I can't speak for everyone...

Most people don't want to write (or even compile) a new bootloader for each 
and every project. For our Miami SOMs, there are already more full-custom 
carrier boards than evaluation boards. If we had to build a bootloader for 
each such design, there'd be dozens of them.


What we try to do is just use the generic bootloader to get the SOM up and 
running, and then provide all the project hardware details in the kernel's 
final devicetree. That includes changing pinmuxing and clocks and stuff, which 
is easy to do.





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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


[U-Boot] Pull request: u-boot-spi/master

2016-12-14 Thread Jagan Teki
Hi Tom,

Please pull this PR.

thanks!
Jagan.

The following changes since commit 136179bec19f4bc84227cba138214ea392a723ea:

  colibri_pxa270: transition to driver model for serial (2016-11-23 13:53:20 
+0100)

are available in the git repository at:

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

for you to fetch changes up to 6c11b3a89fe9cd5ef8070b2a13103f6f466860f1:

  sf: Do not force the DT memory map size to exactly match the device 
(2016-12-14 16:30:04 +0100)


Fabien Parent (1):
  mtd: spi: don't return -1 when scan succeed

Jagan Teki (1):
  spi: Zap mpc52xx_spi.c and config

Phil Edworthy (10):
  spi: cadence_qspi: Fix clearing of pol/pha bits
  spi: cadence_qspi: Fix baud rate calculation
  spi: cadence_qspi: Better debug information on the SPI clock rate
  spi: cadence_qspi: Use #define for bits instead of bit shifts
  spi: cadence_qspi: Clean up the #define names
  spi: cadence_qspi: Use spi mode at the point it is needed
  spi: cadence_qspi: Remove returns from end of void functions
  spi: cadence_qspi: Fix CS timings
  spi: cadence_qspi: Move DT prop code to match layout
  sf: Do not force the DT memory map size to exactly match the device

Simon Glass (1):
  spi: Add error checking for invalid bus widths

Vignesh R (1):
  ARM: dts: am437x-idk: Fix QSPI compatible string

 arch/arm/dts/am437x-idk-evm.dts  |   2 +-
 board/intercontrol/digsy_mtc/digsy_mtc.c |   9 --
 configs/digsy_mtc_RAMBOOT_defconfig  |   1 -
 configs/digsy_mtc_defconfig  |   1 -
 configs/digsy_mtc_rev5_RAMBOOT_defconfig |   1 -
 configs/digsy_mtc_rev5_defconfig |   1 -
 drivers/mtd/spi/spi_flash.c  |   6 +-
 drivers/spi/Makefile |   1 -
 drivers/spi/cadence_qspi.c   |   6 +-
 drivers/spi/cadence_qspi.h   |   3 +-
 drivers/spi/cadence_qspi_apb.c   | 185 ++-
 drivers/spi/mpc52xx_spi.c|  90 ---
 drivers/spi/spi-uclass.c |   4 +-
 include/configs/digsy_mtc.h  |   6 -
 scripts/config_whitelist.txt |   1 -
 15 files changed, 93 insertions(+), 224 deletions(-)
 delete mode 100644 drivers/spi/mpc52xx_spi.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sf: Do not force the DT memory map size to exactly match the device

2016-12-14 Thread Jagan Teki
On Fri, Dec 9, 2016 at 4:03 PM, Phil Edworthy  wrote:
> As long as the memory mapped size specifeid in the DT is the same or
> bigger than the device size, it will work. So do not force the sizes
> to be identical.
>
> Signed-off-by: Phil Edworthy 

Applied to u-boot-spi/master

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


Re: [U-Boot] [PATCH v4 2/2] splash: add support for loading splash from a FIT image

2016-12-14 Thread Tomas Melin
Hi Simon, Igor,

On 12/14/2016 02:53 PM, Igor Grinberg wrote:
> On 12/13/16 22:29, Simon Glass wrote:
>
> I think two above debug() are very legitimate - no need to shout if no 
> FIT image
> or no splash in it...
>
>> + res = fit_image_get_data_offset(fit_header, node_offset,
>> + _offset);
>> + if (res < 0) {
>> + debug("Could not find 'data-offset' property in FIT\n");
>> + return res;
>> + }
>> +
>> + res = fit_image_get_data_size(fit_header, node_offset, 
>> _size);
>> + if (res < 0) {
>> + debug("Could not find 'data-size' property in FIT\n");
>> + return res;
>> + }
>
> Now regarding these two, I'm not sure.
> Since we have found a valid FIT and also a node with a correct splash 
> name,
> probably the intent is that we show the splash, right?
> But in the two above checks, we find inconsistencies that do not allow us 
> to
> show the splash - meaning the FIT is not actually good (am I right here?).
> So may be we should report it to the 'user' and allow correcting the FIT?
> Otherwise, it is impossible to debug the image w/o a debug version of 
> U-Boot...
> Do I make sense, or do I miss something?

 Yes that makes some sense, but the problem is that then you are
 including error messages always which would never happen in a working
 system (i.e. it just bloats the code).
>>>
>>> Unless, there a kind of corruption or a user mistake and then that same
>>> user can't even understand what happened because we do not help him with
>>> an error message.
>>> You cannot know that these error messages will never happen...
>>> This is a generic code which can be used by a wide variety of platforms -
>>> I don't think you can foresee all the possible use cases.
>>>
>>> We are talking about several tens of bytes vs. usability.
>>> If there is an error, it should be stated as such. It should not just
>>> exit silently...
>>
>> I agree with that, there should definitely be an error printed. It
>> should say something like 'Failed to load splash screen (err=-4)' or
>> something like that. The error number should provide some clues and
>> people can dig in.
> 
> Great idea!

splash_load_fit() currently fails silently but still reports the error in
the return value. And this function is used so that board.c calls 
splash_source_load()->splash_load_fit().
The board function call will get notified of the error value as provided
by the return value for splash_load_fit(). In our board implementation that is 
actually exactly how it is done, the board function call checks the return
value and prints ("Failed to load splash screen image, error: %d\n", ret)
in case there was and error.

IMHO this is quite good behaviour as is, leaving it up to the implementation
in the board.c if there should be a error message or not (and if it should 
bloat the code with another printf or not).


 So long as the error is reported (even if it is not a very specific
 error), people can add DEBUG and track it down.
>>>
>>> That depends who 'people' are? Devs? Users?
>>
>> Well in this case the user will never see the problem, unless someone
>> has screwed up the splash screen image. Mostly I'm talking about devs.
>>
>> Better would be to have an expanded debug() system which lets you turn
>> debugging on globally when hunting for a problem. That would be a nice
>> project for someone...
> 
> Yes, indeed that sounds like a nice project.
> It would be great to be able to specify the debug verbosity on per build
> basis (e.g. Kconfig).
> 

Indeed, that would be a great feature.

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


[U-Boot] [PATCH v2 3/3] drivers: usb: gadget: ether/rndis: convert driver to adopt device driver model

2016-12-14 Thread Mugunthan V N
Adopt usb ether gadget and rndis driver to adopt driver model

Signed-off-by: Mugunthan V N 
---
 drivers/usb/gadget/ether.c | 152 ++---
 drivers/usb/gadget/rndis.c |  13 +++-
 drivers/usb/gadget/rndis.h |  19 --
 include/net.h  |   8 +++
 4 files changed, 177 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index e8d9e4a9c9..c5eb552129 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -25,11 +25,22 @@
 #include "rndis.h"
 
 #include 
+#include 
 #include 
 #include 
 
 #define USB_NET_NAME "usb_ether"
 
+/*
+ * This driver support only the following combinations.
+ * DM_ETH + DM_USB
+ * !DM_ETH + DM_USB
+ * !DM_ETH + !DM_USB
+ */
+#if defined(CONFIG_DM_ETH) && !defined(CONFIG_DM_USB)
+#error "This driver doesn't support the combination of DM_ETH and !DM_USB"
+#endif
+
 #define atomic_read
 extern struct platform_data brd;
 
@@ -116,7 +127,11 @@ struct eth_dev {
 
struct usb_request  *tx_req, *rx_req;
 
+#ifdef CONFIG_DM_ETH
+   struct udevice  *net;
+#else
struct eth_device   *net;
+#endif
struct net_device_stats stats;
unsigned inttx_qlen;
 
@@ -143,7 +158,11 @@ struct eth_dev {
 /*-*/
 struct ether_priv {
struct eth_dev ethdev;
+#ifdef CONFIG_DM_ETH
+   struct udevice *netdev;
+#else
struct eth_device netdev;
+#endif
struct usb_gadget_driver eth_driver;
 };
 
@@ -1851,7 +1870,11 @@ static void rndis_control_ack_complete(struct usb_ep *ep,
 
 static char rndis_resp_buf[8] __attribute__((aligned(sizeof(__le32;
 
+#ifdef CONFIG_DM_ETH
+static int rndis_control_ack(struct udevice *net)
+#else
 static int rndis_control_ack(struct eth_device *net)
+#endif
 {
struct ether_priv   *priv = (struct ether_priv *)net->priv;
struct eth_dev  *dev = >ethdev;
@@ -2000,6 +2023,9 @@ static int eth_bind(struct usb_gadget *gadget)
struct usb_ep   *in_ep, *out_ep, *status_ep = NULL;
int status = -ENOMEM;
int gcnum;
+#ifdef CONFIG_DM_ETH
+   struct eth_pdata*pdata = dev_get_platdata(l_priv->netdev);
+#endif
 
/* these flags are only ever cleared; compiler take note */
 #ifndefCONFIG_USB_ETH_CDC
@@ -2187,7 +2213,11 @@ autoconf_fail:
 
 
/* network device setup */
+#ifdef CONFIG_DM_ETH
+   dev->net = l_priv->netdev;
+#else
dev->net = _priv->netdev;
+#endif
 
dev->cdc = cdc;
dev->zlp = zlp;
@@ -2203,7 +2233,13 @@ autoconf_fail:
 * host side code for the SAFE thing cares -- its original BLAN
 * thing didn't, Sharp never assigned those addresses on Zaurii.
 */
-   get_ether_addr(dev_addr, dev->net->enetaddr);
+#ifdef CONFIG_DM_ETH
+   if (is_eth_addr_valid(dev_addr))
+   get_ether_addr(dev_addr, pdata->enetaddr);
+#else
+   if (is_eth_addr_valid(dev_addr))
+   get_ether_addr(dev_addr, dev->net->enetaddr);
+#endif
 
get_ether_addr(host_addr, dev->host_mac);
 
@@ -2264,10 +2300,11 @@ autoconf_fail:
status_ep ? " STATUS " : "",
status_ep ? status_ep->name : ""
);
-   printf("MAC %02x:%02x:%02x:%02x:%02x:%02x\n",
-   dev->net->enetaddr[0], dev->net->enetaddr[1],
-   dev->net->enetaddr[2], dev->net->enetaddr[3],
-   dev->net->enetaddr[4], dev->net->enetaddr[5]);
+#ifdef CONFIG_DM_ETH
+   printf("MAC %pM\n", pdata->enetaddr);
+#else
+   printf("MAC %pM\n", dev->net->enetaddr);
+#endif
 
if (cdc || rndis)
printf("HOST MAC %02x:%02x:%02x:%02x:%02x:%02x\n",
@@ -2364,10 +2401,6 @@ static int _usb_eth_init(struct ether_priv *priv)
strlcpy(host_addr, getenv("usbnet_hostaddr"),
sizeof(host_addr));
 
-   if (!is_eth_addr_valid(dev_addr)) {
-   error("Need valid 'usbnet_devaddr' to be set");
-   goto fail;
-   }
if (!is_eth_addr_valid(host_addr)) {
error("Need valid 'usbnet_hostaddr' to be set");
goto fail;
@@ -2527,6 +2560,7 @@ void _usb_eth_halt(struct ether_priv *priv)
 #endif
 }
 
+#ifndef CONFIG_DM_ETH
 static int usb_eth_init(struct eth_device *netdev, bd_t *bd)
 {
struct ether_priv *priv = (struct ether_priv *)netdev->priv;
@@ -2593,3 +2627,103 @@ int usb_eth_initialize(bd_t *bi)
eth_register(netdev);
return 0;
 }
+#else
+static int usb_eth_start(struct udevice *dev)
+{
+   struct ether_priv *priv = dev_get_priv(dev);
+
+   return _usb_eth_init(priv);
+}
+
+static int usb_eth_send(struct udevice *dev, void *packet, int length)
+{
+   struct ether_priv *priv = dev_get_priv(dev);
+
+   return _usb_eth_send(priv, packet, length);

[U-Boot] [PATCH v2 0/3] DM conversion of usb ether gadget

2016-12-14 Thread Mugunthan V N
This patch series adopts driver model for usb ether gadget
driver. This series is tested with MUSB driver model conversion
on AM335x GP evm and AM335x BBB (logs [1]).

Also pushed a branch for testing [2]

Changes from v3:
* Removed the patches already applied.
* Changed to possitive approach for #ifndef CONFIG_DM_USB
* Removed hardcoding of usb device mac id from Kconfig over
  enviroment. Now it is like use enviroment mac or use
  random mac generated by dm-eth framework.
* Added a build error when DM_ETH is defined and DM_USB
  not defined as the driver doesn't support this combination
* Added two new patches which removed tmp variable which is
  initialized and never been used and another to fix a crash
  when DM_USB and DM_ETH are defined.

Changes from v2:
* Moved USB ether address from driver hard code to Kconfig entry
* Optimized if check in patch 5/6 as mentioned by Marek Vasut.

Changes from initial version:
* Separated out the usb gadget driver patches from earlier musb
  series [3] for testing and submitting of dwc3 dm musb patches.

[1] - http://pastebin.ubuntu.com/23628667/
[2] - git://git.ti.com/~mugunthanvnm/ti-u-boot/mugunth-ti-u-boot.git 
usb-ether-v4
[3] - http://lists.denx.de/pipermail/u-boot/2016-February/246827.html

Mugunthan V N (3):
  drivers: usb: gadget: ether: do not register usb when DM_USB and
DM_ETH defined
  drivers: usb: gadget: ether: remove unused variable tmp
  drivers: usb: gadget: ether/rndis: convert driver to adopt device
driver model

 drivers/usb/gadget/ether.c | 164 -
 drivers/usb/gadget/rndis.c |  13 +++-
 drivers/usb/gadget/rndis.h |  19 --
 include/net.h  |   8 +++
 4 files changed, 183 insertions(+), 21 deletions(-)

-- 
2.11.0

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


[U-Boot] [PATCH v2 1/3] drivers: usb: gadget: ether: do not register usb when DM_USB and DM_ETH defined

2016-12-14 Thread Mugunthan V N
when both DM_USB and DM_ETH are defined which denoted that
usb_ether has been registered from a usb device. So registering a
USB device doesn't do any thing and de-register leads to crash as
it try to remove its own parent. Sample dm-tree output below.

 eth [ + ]|-- ethernet@4a10
 misc[ + ]`-- usb@4740
 usb_dev_gen [ + ]|-- usb@47401000
 eth [ + ]|   `-- usb_ether
 usb [   ]`-- usb@47401800

Signed-off-by: Mugunthan V N 
---
 drivers/usb/gadget/ether.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 046ad8ca2b..bcc8be86a5 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -105,7 +105,7 @@ struct eth_dev {
struct usb_gadget   *gadget;
struct usb_request  *req;   /* for control responses */
struct usb_request  *stat_req;  /* for cdc & rndis status */
-#ifdef CONFIG_DM_USB
+#if defined(CONFIG_DM_USB) && !defined(CONFIG_DM_ETH)
struct udevice  *usb_udev;
 #endif
 
@@ -2316,7 +2316,7 @@ fail:
 
 /*-*/
 
-#ifdef CONFIG_DM_USB
+#if defined(CONFIG_DM_USB) && !defined(CONFIG_DM_ETH)
 int dm_usb_init(struct eth_dev *e_dev)
 {
struct udevice *dev = NULL;
@@ -2342,10 +2342,12 @@ static int _usb_eth_init(struct ether_priv *priv)
unsigned long timeout = USB_CONNECT_TIMEOUT;
 
 #ifdef CONFIG_DM_USB
+#ifndef CONFIG_DM_ETH
if (dm_usb_init(dev)) {
error("USB ether not found\n");
return -ENODEV;
}
+#endif
 #else
board_usb_init(0, USB_INIT_DEVICE);
 #endif
@@ -2521,7 +2523,9 @@ void _usb_eth_halt(struct ether_priv *priv)
 
usb_gadget_unregister_driver(>eth_driver);
 #ifdef CONFIG_DM_USB
+#ifndef CONFIG_DM_ETH
device_remove(dev->usb_udev);
+#endif
 #else
board_usb_cleanup(0, USB_INIT_DEVICE);
 #endif
-- 
2.11.0

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


[U-Boot] [PATCH v2 2/3] drivers: usb: gadget: ether: remove unused variable tmp

2016-12-14 Thread Mugunthan V N
tmp variable in eth_bind() is never used any where, so remove it.

Signed-off-by: Mugunthan V N 
---
 drivers/usb/gadget/ether.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index bcc8be86a5..e8d9e4a9c9 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2000,7 +2000,6 @@ static int eth_bind(struct usb_gadget *gadget)
struct usb_ep   *in_ep, *out_ep, *status_ep = NULL;
int status = -ENOMEM;
int gcnum;
-   u8  tmp[7];
 
/* these flags are only ever cleared; compiler take note */
 #ifndefCONFIG_USB_ETH_CDC
@@ -2206,9 +2205,6 @@ autoconf_fail:
 */
get_ether_addr(dev_addr, dev->net->enetaddr);
 
-   memset(tmp, 0, sizeof(tmp));
-   memcpy(tmp, dev->net->enetaddr, sizeof(dev->net->enetaddr));
-
get_ether_addr(host_addr, dev->host_mac);
 
sprintf(ethaddr, "%02X%02X%02X%02X%02X%02X",
-- 
2.11.0

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


[U-Boot] [PATCH] arm64: mvebu: Fix A8K memory mapping and add documentation

2016-12-14 Thread kostap
From: Konstantin Porotchkin 

Fix the MMU mapping for A8K device family:
 - Separate CP110 master and slave memory regions
 - Fix memory regions by including IO mapping for all
   3 PCIe interfaces existing on each connected CP110 controller
This patch fixes the "Synchronous Abort" exception triggered
by RW access to PCI0 or PCI1 memory regions.
Add A8K memory mapping documentation with all regions
configured by Marvell ATF.

Signed-off-by: Konstantin Porotchkin 
Reviewed-by: Stefan Roese 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
 arch/arm/mach-mvebu/armada8k/cpu.c | 17 +---
 doc/mvebu/armada-8k-memory.txt | 56 ++
 2 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 doc/mvebu/armada-8k-memory.txt

diff --git a/arch/arm/mach-mvebu/armada8k/cpu.c 
b/arch/arm/mach-mvebu/armada8k/cpu.c
index 2719d68..7515e45 100644
--- a/arch/arm/mach-mvebu/armada8k/cpu.c
+++ b/arch/arm/mach-mvebu/armada8k/cpu.c
@@ -21,6 +21,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define RFU_GLOBAL_SW_RST  (MVEBU_RFU_BASE + 0x84)
 #define RFU_SW_RESET_OFFSET0
 
+/* For a detailed memory map, please see doc/mvebu/armada-8k-memory.txt */
 static struct mm_region mvebu_mem_map[] = {
{
/* RAM */
@@ -55,10 +56,18 @@ static struct mm_region mvebu_mem_map[] = {
 PTE_BLOCK_NON_SHARE
},
{
-   /* PCI regions */
-   .phys = 0xf800UL,
-   .virt = 0xf800UL,
-   .size = 0x0800UL,   /* 128MiB PCI space (master & slave) */
+   /* PCI CP0 regions */
+   .phys = 0xf600UL,
+   .virt = 0xf600UL,
+   .size = 0x0400UL,   /* 64MiB CP110 master PCI space */
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE
+   },
+   {
+   /* PCI CP1 regions */
+   .phys = 0xfa00UL,
+   .virt = 0xfa00UL,
+   .size = 0x0400UL,   /* 64MiB CP110 slave PCI space */
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE
},
diff --git a/doc/mvebu/armada-8k-memory.txt b/doc/mvebu/armada-8k-memory.txt
new file mode 100644
index 000..064518e
--- /dev/null
+++ b/doc/mvebu/armada-8k-memory.txt
@@ -0,0 +1,56 @@
+Memory Layout on Armada-8k SoC's
+
+
+The below desribes the physical memory layout for Marvell's Armada-8k SoC's.
+
+This assumes that the SoC includes Dual CP configuration, in case the flavor 
is using
+a single CP configuration, then all secondary-CP mappings are invalid.
+
+All "Reserved" areas below, are kept for future usage.
+
+Start  End Use
+--
+0x 0xEFFF  DRAM
+
+0xF000 0xF0FF  AP Internal registers space
+
+0xF100 0xF1FF  Reserved.
+
+0xF200 0xF3FF  CP-0 Internal (configuration) registers
+   space.
+
+0xF400 0xF5FF  CP-1 Internal (configuration) registers
+   space.
+
+0xF600 0xF6FF  CP-0 / PCIe#0 Memory space.
+
+0xF700 0xF7FF  CP-0 / PCIe#1 Memory space.
+
+0xF800 0xF8FF  CP-0 / PCIe#2 Memory space.
+
+0xF900 0xF900  CP-0 / PCIe#0 IO space.
+
+0xF901 0xF901  CP-0 / PCIe#1 IO space.
+
+0xF902 0xF902  CP-0 / PCIe#2 IO space.
+
+0xF903 0xF9FF  Reserved.
+
+0xFA00 0xFAFF  CP-1 / PCIe#0 Memory space.
+
+0xFB00 0xFBFF  CP-1 / PCIe#1 Memory space.
+
+0xFC00 0xFCFF  CP-1 / PCIe#2 Memory space.
+
+0xFD00 0xFD00  CP-1 / PCIe#0 IO space.
+
+0xFD01 0xFD01  CP-1 / PCIe#1 IO space.
+
+0xFD02 0xFD02  CP-1 / PCIe#2 IO space.
+
+0xFD03 0xFFEF  Reserved.
+
+0xFFF0 0x  Bootrom
+
+0x1-1   DRAM
+
-- 
2.7.4

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


Re: [U-Boot] [PATCH v4 2/2] splash: add support for loading splash from a FIT image

2016-12-14 Thread Igor Grinberg
On 12/13/16 22:29, Simon Glass wrote:
> Hi Igor,
> 
> On 12 December 2016 at 01:37, Igor Grinberg  wrote:
>> On 12/11/16 22:27, Simon Glass wrote:
>>> Hi Igor,
>>>
>>> On 11 December 2016 at 10:37, Igor Grinberg  wrote:
 Hi Tomas, Simon,

 Sorry, to break in that late...
 I have a quick question below.

 On 12/05/16 09:36, Tomas Melin wrote:
> Enable support for loading a splash image from within a FIT image.
> The image is assumed to be generated with mkimage -E flag to hold
> the data external to the FIT.
>
> Signed-off-by: Tomas Melin 

 [...]

> diff --git a/common/splash_source.c b/common/splash_source.c
> index 70d724f..94b46d3 100644
> --- a/common/splash_source.c
> +++ b/common/splash_source.c

 [...]

> +#ifdef CONFIG_FIT
> +static int splash_load_fit(struct splash_location *location, u32 
> bmp_load_addr)
> +{
> + int res;
> + int node_offset;
> + int splash_offset;
> + int splash_size;
> + struct image_header *img_header;
> + const u32 *fit_header;
> + u32 fit_size;
> + const size_t header_size = sizeof(struct image_header);
> +
> + /* Read in image header */
> + res = splash_storage_read_raw(location, bmp_load_addr, header_size);
> + if (res < 0)
> + return res;
> +
> + img_header = (struct image_header *)bmp_load_addr;
> + fit_size = fdt_totalsize(img_header);
> +
> + /* Read in entire FIT */
> + fit_header = (const u32 *)(bmp_load_addr + header_size);
> + res = splash_storage_read_raw(location, (u32)fit_header, fit_size);
> + if (res < 0)
> + return res;
> +
> + res = fit_check_format(fit_header);
> + if (!res) {
> + debug("Could not find valid FIT image\n");
> + return -EINVAL;
> + }
> +
> + node_offset = fit_image_get_node(fit_header, location->name);
> + if (node_offset < 0) {
> + debug("Could not find splash image '%s' in FIT\n",
> +   location->name);
> + return -ENOENT;
> + }
> +

 I think two above debug() are very legitimate - no need to shout if no FIT 
 image
 or no splash in it...

> + res = fit_image_get_data_offset(fit_header, node_offset,
> + _offset);
> + if (res < 0) {
> + debug("Could not find 'data-offset' property in FIT\n");
> + return res;
> + }
> +
> + res = fit_image_get_data_size(fit_header, node_offset, 
> _size);
> + if (res < 0) {
> + debug("Could not find 'data-size' property in FIT\n");
> + return res;
> + }

 Now regarding these two, I'm not sure.
 Since we have found a valid FIT and also a node with a correct splash name,
 probably the intent is that we show the splash, right?
 But in the two above checks, we find inconsistencies that do not allow us 
 to
 show the splash - meaning the FIT is not actually good (am I right here?).
 So may be we should report it to the 'user' and allow correcting the FIT?
 Otherwise, it is impossible to debug the image w/o a debug version of 
 U-Boot...
 Do I make sense, or do I miss something?
>>>
>>> Yes that makes some sense, but the problem is that then you are
>>> including error messages always which would never happen in a working
>>> system (i.e. it just bloats the code).
>>
>> Unless, there a kind of corruption or a user mistake and then that same
>> user can't even understand what happened because we do not help him with
>> an error message.
>> You cannot know that these error messages will never happen...
>> This is a generic code which can be used by a wide variety of platforms -
>> I don't think you can foresee all the possible use cases.
>>
>> We are talking about several tens of bytes vs. usability.
>> If there is an error, it should be stated as such. It should not just
>> exit silently...
> 
> I agree with that, there should definitely be an error printed. It
> should say something like 'Failed to load splash screen (err=-4)' or
> something like that. The error number should provide some clues and
> people can dig in.

Great idea!

> 
> This patch would add around 200 bytes if debug() was changed to
> printf(). Multiply that by several hundred if we did that sort of
> thing throughout U-Boot.

Well, I thought about using printk only on a half of the above messages
and that gives about ~90 bytes, while it also can be optimized by using
the same parameterized string and thus add only ~50 bytes...

> 
>>
>> I think that debug() is a good thing to use, but we shouldn't be obsessed
>> with it.
> 
> Fair 

Re: [U-Boot] [PATCH] usb: dwc2-otg: remove unused variable

2016-12-14 Thread Marek Vasut
On 12/14/2016 06:30 AM, Masahiro Yamada wrote:
> GCC 6.1 complains about this.
> 
> drivers/usb/gadget/dwc2_udc_otg.c:72:19: warning: 'driver_desc'
> defined but not used [-Wunused-const-variable=]
>  static const char driver_desc[] = DRIVER_DESC;
>^~~
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Marek Vasut 

Applied too, thanks.

> ---
> 
>  drivers/usb/gadget/dwc2_udc_otg.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
> b/drivers/usb/gadget/dwc2_udc_otg.c
> index d72bfdf..cb44374 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
> @@ -63,13 +63,11 @@ static char *state_names[] = {
>   "WAIT_FOR_NULL_COMPLETE",
>  };
>  
> -#define DRIVER_DESC "DWC2 HS USB OTG Device Driver, (c) Samsung Electronics"
>  #define DRIVER_VERSION "15 March 2009"
>  
>  struct dwc2_udc  *the_controller;
>  
>  static const char driver_name[] = "dwc2-udc";
> -static const char driver_desc[] = DRIVER_DESC;
>  static const char ep0name[] = "ep0-control";
>  
>  /* Max packet size*/
> 


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


Re: [U-Boot] [RFC PATCH 2/3] sunxi: video: Add video driver for H3 SoC

2016-12-14 Thread Maxime Ripard
Hi,

On Tue, Dec 13, 2016 at 09:13:11PM +0100, Jernej Škrabec wrote:
> Hi,
> 
> On Tue, Dec 13, 2016 at 16:40:55 CET, Maxime Ripard wrote:
> > Hi,
> > 
> > On Tue, Dec 13, 2016 at 01:36:29AM +0100, Jernej Skrabec wrote:
> > > This patch adds support for hdmi output. It is designed in the same
> > > way as video driver for older Allwinner SoCs.
> > > 
> > > First it checks if monitor is attached. If it is, recommended
> > > timings are read from EDID. After that, DE2, TCON and HDMI are
> > > configured according to this timings.
> > > 
> > > 32MB of RAM is used for framebuffer. This is just enough to support
> > > 4K resolution.
> > > 
> > > SimpleFB is also supported by this driver.
> > > 
> > > Signed-off-by: Jernej Skrabec 
> > 
> > From the linux discussion, I recall that you said that the TCON was
> > still the same, and the HDMI was something that could be shared with
> > the Rockchip implementation. Did you look into sharing the TCON code
> > (for example using a small "library" to share the functions) and to
> > reuse Rockchip's HDMI code?
> 
> For now, I only reused one TCON function and some defines. I tought that 
> split 
> would be better done a bit later, when the driver will get support for LCD 
> screens (A64, for example). At that time TCON code would also be refactored 
> to 
> be more generic and properly tested that it can be used with both drivers. 
> Unfortunatelly, I don't have any board with older SoC for testing.

We can definitely do that. I think I have access to at least of board
of each generation, so I can totally test whatever you come up with on
those boards, and help you debugging whatever issue that might show up.

> While I took Rockchip HDMI code for reference, it can't be easily reused. 
> First of, it uses DT nodes. I guess I could write DT binding or modify 
> existing driver to work without it.

Like we discussed in the other part of the thread, I think the latter
would be easier to deal with.

> Second issue here is same as in Linux, PHY code is tightly coupled
> with controller code, so it needs to be decoupled first.

But it would be easier to deal with than Linux I guess. Can't you just
create a new weak function to initialise the phy? And then, every
platform can just overwrite it.

> Thirdly, and in my opinion most annoying, Rockchip driver uses 32
> bit aligned registers, but H3 does not. This also means a lot of
> work to make it more generic.

How does Linux deal with that? Would just using some kind of accessors
that would abstract that away from the driver help, or is it more
complicated?

> Actually, H3 is more similar to i.MX6 HDMI in this regard, but
> driver's code is scattered throughout multiple files (search for
> mxc_hdmi.h inclusion). It is certainly doable, but it will take much
> more time.  Basically, U-Boot already has two drivers for DWC HDMI
> and with this patch it will get third. Merging all three
> implementations into one would be very tedious, but very desirable
> goal. I must state that I didn't really try to understand i.MX6 HDMI
> code at all, so I don't now how hard it would be to pull it out.

I'm not sure that merging a third and saying that it would be up to
the fourth to do the work is reasonable. It's just hiding an issue
under the carpet, but I don't see how it will be easier for the next
person to work on that. Quite the opposite actually.

Maxime

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


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


Re: [U-Boot] [linux-sunxi] Re: [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

2016-12-14 Thread Emmanuel Vadot
On Wed, 14 Dec 2016 11:37:38 +0200
Alexander Graf  wrote:

> 
> 
> > Am 14.12.2016 um 11:25 schrieb Maxime Ripard 
> > :
> > 
> >> On Wed, Dec 14, 2016 at 11:02:33AM +0800, Chen-Yu Tsai wrote:
> >>> On Wed, Dec 14, 2016 at 5:16 AM, Icenowy Zheng  wrote:
> >>> 
> >>> 
> >>> 14.12.2016, 04:29, "Simon Glass" :
>  Hi,
>  
> > On 12 December 2016 at 19:36, Jernej Skrabec  
> > wrote:
> > This patch series add support for HDMI output. Support for other,
> > newer, SoCs, which also uses DE2 and same or similar HDMI controller
> > and PHY can be easily added later (A83T/A64/H5/R40). Current driver
> > can also be easily extended with TV out support, just like video
> > driver for older Allwinner SoCs.
> > 
> > While driver works, I would like to get few opinions first.
> > - From what I understand, drivers which supports DT are preferred.
> >   Would it be better to rewrite this driver to support device tree?
>  
>  Yes I think so, and in fact it should use driver model also.
>  
>  The rockchip driver provides a reasonable example of how to split the
>  driver up as you suggest below. The VIDEO driver provides the
>  top-level video interface, DISPLAY drivers provide display output for
>  the video, and you have PANEL as well for receiving the display
>  output. VIDCONSOLE works automatically to display text.
>  
>  I actually took a bit of a look at this a few weeks ago so am happy to
>  help with review or discussions.
> >>> 
> >>> Yes, I think go to Driver Model is also valuable, as Allwinner's display 
> >>> parts
> >>> are really in reusable components.
> >>> 
> >>> In addition, Driver Model provides the possibility to use EFI GOP, which 
> >>> can
> >>> be a more standardized replacement of SimpleFB, especially for OSes other
> >>> than Linux. (For example, Windows, if we can really get it running ;-) )
> >> 
> >> We're going to use EFI now? Doesn't EFI mean we have to leave another bit
> >> of firmware in memory running under the OS? What about PSCI and ATF on
> >> ARMv8?
> > 
> > Until EFI on A64 on U-boot is a real thing, I don't really care to be
> > honest.
> 
> How is it not a real thing today?
> 
> Alex

 We are using it on FreeBSD for Pine64 so it seems pretty real for me.

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


Re: [U-Boot] [linux-sunxi] Re: [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

2016-12-14 Thread Alexander Graf


> Am 14.12.2016 um 11:25 schrieb Maxime Ripard 
> :
> 
>> On Wed, Dec 14, 2016 at 11:02:33AM +0800, Chen-Yu Tsai wrote:
>>> On Wed, Dec 14, 2016 at 5:16 AM, Icenowy Zheng  wrote:
>>> 
>>> 
>>> 14.12.2016, 04:29, "Simon Glass" :
 Hi,
 
> On 12 December 2016 at 19:36, Jernej Skrabec  
> wrote:
> This patch series add support for HDMI output. Support for other,
> newer, SoCs, which also uses DE2 and same or similar HDMI controller
> and PHY can be easily added later (A83T/A64/H5/R40). Current driver
> can also be easily extended with TV out support, just like video
> driver for older Allwinner SoCs.
> 
> While driver works, I would like to get few opinions first.
> - From what I understand, drivers which supports DT are preferred.
>   Would it be better to rewrite this driver to support device tree?
 
 Yes I think so, and in fact it should use driver model also.
 
 The rockchip driver provides a reasonable example of how to split the
 driver up as you suggest below. The VIDEO driver provides the
 top-level video interface, DISPLAY drivers provide display output for
 the video, and you have PANEL as well for receiving the display
 output. VIDCONSOLE works automatically to display text.
 
 I actually took a bit of a look at this a few weeks ago so am happy to
 help with review or discussions.
>>> 
>>> Yes, I think go to Driver Model is also valuable, as Allwinner's display 
>>> parts
>>> are really in reusable components.
>>> 
>>> In addition, Driver Model provides the possibility to use EFI GOP, which can
>>> be a more standardized replacement of SimpleFB, especially for OSes other
>>> than Linux. (For example, Windows, if we can really get it running ;-) )
>> 
>> We're going to use EFI now? Doesn't EFI mean we have to leave another bit
>> of firmware in memory running under the OS? What about PSCI and ATF on
>> ARMv8?
> 
> Until EFI on A64 on U-boot is a real thing, I don't really care to be
> honest.

How is it not a real thing today?

Alex


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


Re: [U-Boot] [linux-sunxi] Re: [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

2016-12-14 Thread Maxime Ripard
On Wed, Dec 14, 2016 at 11:02:33AM +0800, Chen-Yu Tsai wrote:
> On Wed, Dec 14, 2016 at 5:16 AM, Icenowy Zheng  wrote:
> >
> >
> > 14.12.2016, 04:29, "Simon Glass" :
> >> Hi,
> >>
> >> On 12 December 2016 at 19:36, Jernej Skrabec  
> >> wrote:
> >>>  This patch series add support for HDMI output. Support for other,
> >>>  newer, SoCs, which also uses DE2 and same or similar HDMI controller
> >>>  and PHY can be easily added later (A83T/A64/H5/R40). Current driver
> >>>  can also be easily extended with TV out support, just like video
> >>>  driver for older Allwinner SoCs.
> >>>
> >>>  While driver works, I would like to get few opinions first.
> >>>  - From what I understand, drivers which supports DT are preferred.
> >>>Would it be better to rewrite this driver to support device tree?
> >>
> >> Yes I think so, and in fact it should use driver model also.
> >>
> >> The rockchip driver provides a reasonable example of how to split the
> >> driver up as you suggest below. The VIDEO driver provides the
> >> top-level video interface, DISPLAY drivers provide display output for
> >> the video, and you have PANEL as well for receiving the display
> >> output. VIDCONSOLE works automatically to display text.
> >>
> >> I actually took a bit of a look at this a few weeks ago so am happy to
> >> help with review or discussions.
> >
> > Yes, I think go to Driver Model is also valuable, as Allwinner's display 
> > parts
> > are really in reusable components.
> >
> > In addition, Driver Model provides the possibility to use EFI GOP, which can
> > be a more standardized replacement of SimpleFB, especially for OSes other
> > than Linux. (For example, Windows, if we can really get it running ;-) )
> 
> We're going to use EFI now? Doesn't EFI mean we have to leave another bit
> of firmware in memory running under the OS? What about PSCI and ATF on
> ARMv8?

Until EFI on A64 on U-boot is a real thing, I don't really care to be
honest.

Maxime

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


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


Re: [U-Boot] [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

2016-12-14 Thread Maxime Ripard
On Wed, Dec 14, 2016 at 09:37:58AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 13-12-16 21:28, Simon Glass wrote:
> > Hi,
> > 
> > On 12 December 2016 at 19:36, Jernej Skrabec  
> > wrote:
> > > This patch series add support for HDMI output. Support for other,
> > > newer, SoCs, which also uses DE2 and same or similar HDMI controller
> > > and PHY can be easily added later (A83T/A64/H5/R40). Current driver
> > > can also be easily extended with TV out support, just like video
> > > driver for older Allwinner SoCs.
> > > 
> > > While driver works, I would like to get few opinions first.
> > > - From what I understand, drivers which supports DT are preferred.
> > >   Would it be better to rewrite this driver to support device tree?
> > 
> > Yes I think so, and in fact it should use driver model also.
> > 
> > The rockchip driver provides a reasonable example of how to split the
> > driver up as you suggest below. The VIDEO driver provides the
> > top-level video interface, DISPLAY drivers provide display output for
> > the video, and you have PANEL as well for receiving the display
> > output. VIDCONSOLE works automatically to display text.
> > 
> > I actually took a bit of a look at this a few weeks ago so am happy to
> > help with review or discussions.
> 
> I'm all in favor of moving to the driver-model, but I believe that
> we first need proper support for the DE2 and new HMDI encoder in
> the kernel, so that the dt bindings are clear.

I agree, and I would even say that we shouldn't wait for that to
happen either. I don't have any objection merging it without the
driver model given how much time it took last time to have a driver
merged in the kernel for that block (with its bindings), and then
convert to the device model / DT once and when we have that.

Maxime

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


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


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

2016-12-14 Thread Z.Q. Hou
Hi York,

Thanks a lot for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年12月14日 0:59
> To: Z.Q. Hou ; u-boot@lists.denx.de; Prabhakar
> Kushwaha ; Mingkai Hu
> ; Pratiyush Srivastava 
> Subject: Re: [PATCH] armv8/fsl_lsch2: Add the OCRAM initialization
> 
> On 12/13/2016 01:45 AM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Clear the content to zero and the ECC error bit of OCRAM1/2.
> >
> > The OCRAM must be initialized to ZERO by the unit of 8-Byte before
> > accessing it, or else it will generate ECC error. And the IBR has
> > accessed the OCRAM before this initialization, so the ECC error status
> > bit should to be cleared.
> >
> > Signed-off-by: Hou Zhiqiang 
> > Signed-off-by: Pratiyush Srivastava 
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S  | 37
> +++
> >  arch/arm/include/asm/arch-fsl-layerscape/config.h |  3 ++
> >  2 files changed, 40 insertions(+)
> >
> 
> Zhiqiang,
> 
> This looks like an updated version of previous patch "armv8/ls1043a: Add the
> OCRAM initialization". Was there any effort to include LSCH3?

Yes, I wrote that patch for ls1043a bringup, and re-write it for LSCH2.
I don't know if LSCH3 need this operation, is there any update about verifying 
this issue on LSCH3?

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


[U-Boot] [PATCH] travis-ci: Add zynq_zc702 target support

2016-12-14 Thread Michal Simek
It depends on qemu v2.8.0-rc3 which includes device loader property.

Signed-off-by: Michal Simek 
---

It requires this change
https://github.com/swarren/uboot-test-hooks/pull/12

---
 .travis.yml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 4b328209e227..df6206ce3590 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -306,5 +306,11 @@ matrix:
   BUILDMAN="^qemu-x86$"
   TOOLCHAIN="x86_64"
   BUILD_ROM="yes"
+- env:
+- TEST_PY_BD="zynq_zc702"
+  TEST_PY_TEST_SPEC="not sleep"
+  QEMU_TARGET="arm-softmmu"
+  TEST_PY_ID="--id qemu"
+  BUILDMAN="^zynq_zc702$"
 
 # TODO make it perfect ;-r
-- 
1.9.1

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


Re: [U-Boot] [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

2016-12-14 Thread Hans de Goede

Hi,

On 13-12-16 21:28, Simon Glass wrote:

Hi,

On 12 December 2016 at 19:36, Jernej Skrabec  wrote:

This patch series add support for HDMI output. Support for other,
newer, SoCs, which also uses DE2 and same or similar HDMI controller
and PHY can be easily added later (A83T/A64/H5/R40). Current driver
can also be easily extended with TV out support, just like video
driver for older Allwinner SoCs.

While driver works, I would like to get few opinions first.
- From what I understand, drivers which supports DT are preferred.
  Would it be better to rewrite this driver to support device tree?


Yes I think so, and in fact it should use driver model also.

The rockchip driver provides a reasonable example of how to split the
driver up as you suggest below. The VIDEO driver provides the
top-level video interface, DISPLAY drivers provide display output for
the video, and you have PANEL as well for receiving the display
output. VIDCONSOLE works automatically to display text.

I actually took a bit of a look at this a few weeks ago so am happy to
help with review or discussions.


I'm all in favor of moving to the driver-model, but I believe that
we first need proper support for the DE2 and new HMDI encoder in
the kernel, so that the dt bindings are clear.

Once that is in place it would be good to look into converting the
u-boot code to the driver-model. Since that likely is going to
take a while I think it would be good to move ahead with this
patch set as is (with review comments addressed) and later replace
it with a driver-model based implementation. But that is no longer
my call :)

Regards,

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