Re: [U-Boot] [PATCH] armv8/ls1043a: Add MTD partition scheme

[Wenbin Song]

Hi: York

Please see my inline comments.

Best Regards
Wenbin Song

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Thursday, April 07, 2016 1:18 AM
> To: Wenbin Song ; Mingkai Hu
> ; u-boot@lists.denx.de
> Cc: Qianyu Gong ; Shaohui Xie
> ; Zhiqiang Hou 
> Subject: Re: [PATCH] armv8/ls1043a: Add MTD partition scheme
> 
> On 04/06/2016 12:11 AM, Wenbin Song wrote:
> > Hi: York
> >
> > I set bootargs  as the following steps:
> >
> > => env default mtdparts
> > => printenv mtdparts
> >
> mtdparts=mtdparts=6000.nor:1m(nor_bank0_rcw),1m(nor_bank0_uboot)
> ,1
> >
> m(nor_bank0_uboot_env),1m(nor_bank0_fman_uconde),40m(nor_bank0_fit
> ),1m
> >
> (nor_bank4_rcw),1m(nor_bank4_uboot),1m(nor_bank4_uboot_env),1m(nor_
> ban
> >
> k4_fman_ucode),40m(nor_bank4_fit);7e80.flash:1m(nand_uboot),1m(na
> n
> > d_uboot_env),20m(nand_fit);spi0.0:1m(uboot),5m(kernel),1m(dtb),9m(file
> > _system)
> > => env default bootargs
> > => printenv bootargs
> > bootargs=console=ttyS0,115200 root=/dev/ram0
> > earlycon=uart8250,mmio,0x21c0500 ${mtdparts}
> >
> >
> > The macro  CONFIG_BOOTARGS  only be extern as an char-string, and it will
> be spliced into default_environment array .
> >
> >  const uchar default_environment[] = { #ifdef  CONFIG_BOOTARGS
> >   "bootargs=" CONFIG_BOOTARGS "\0"
> >  #endif
> >
> > The variable we use to have $consoledev, $othbootargs  was used in the
> following cases:
> >
> > 858  #define CONFIG_BOOTCOMMAND \
> > 859 "setenv bootargs root=/dev/ram rw " \
> > 860 "console=$consoledev,$baudrate $othbootargs;"   \
> > 861 "setenv ramdiskaddr 0x0200;"\
> > 862 "setenv fdtaddr 0x00c0;"\
> > 863 "setenv loadaddr 0x100;"\
> > 864 "bootm $loadaddr $ramdiskaddr $fdtaddr"
> >
> > Because the "setenv"  will be executed  , So the variable could be extended.
> 
> I see what you mean. I am trying to reduce the environmental variables.
> Do you need the variable "mtdparts"?

[wenbin] 

I export this variable in order to make easier  to modify the bootargs under 
uboot command-line.

For example:
=>setenv bootargs  "console=ttyS0,115200  root=/dev/ram0  $mtdparts"
=>setenv bootargs  "console=ttyLP0,115200  root=/dev/ram0  $mtdparts"

Use the $mtdparts to instead of a long string.


> Would it be a better idea to set bootargs using the bootcmd?
[wenbin]

 yes, It is a good idea.
 But we need all kinds of  ways to boot kernel  with this  "bootargs".  The 
bootcmd only can specify one boot-way.
IOW,  only the way specified by this "bootcmd"  can  execute " setenv  
bootargs".
So I want to supply the default bootargs  by the CONFIG_BOOTARGS .


> 
> While you are on it, I suggest you take a look at other variables.
> "console=ttyAMA0,38400n8" is wrong here.
> 
> We don't have to copy kernel image from NOR flash to DDR if the ramdisk load
> address is set properly in its file. So you can remove the copying from 
> bootcmd.
> 
[wenbin]

Ok, thanks for your advices,  I will modify them on the later patch. 

> York

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

Re: [U-Boot] [PATCH v4] armv8: LS2080A: Consolidate LS2080A and LS2085A

[York Sun]

On 04/04/2016 11:41 AM, York Sun wrote:
> LS2080A is the primary SoC, and LS2085A is a personality with AIOP
> and DPAA DDR. The RDB and QDS boards support both personality. By
> detecting the SVR at runtime, a single image per board can support
> both SoCs. It gives users flexibility to swtich SoC without the need
> to reprogram the board.
> 
> Signed-off-by: York Sun 
> CC: Prabhakar Kushwaha 
> 
> ---
> 
> Changes in v4:
> Rebase to latest master, add changes to secure boot
> Remove ls2085a related defconfig
> Add weak function for soc_has_aiop
> Compile tested on selected arm and powerpc targets
> 
> Changes in v3:
> Fix checking AIOP. Tested on LS2080ARDB.
> 
> Changes in v2:
> Add checking for SVR before starting AIOP
> Drop RFC from subject
> 
>  arch/arm/cpu/armv8/fsl-layerscape/Makefile |4 ---
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|9 ---
>  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |6 -
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |2 +-
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c|   26 ++-
>  arch/arm/cpu/armv8/fsl-layerscape/spl.c|4 +--
>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |9 ++-
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |2 +-
>  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |2 +-
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h |3 +++
>  arch/arm/include/asm/fsl_secure_boot.h |   12 -
>  board/freescale/ls2080a/MAINTAINERS|2 --
>  board/freescale/ls2080a/ddr.c  |   27 
> +++-
>  board/freescale/ls2080a/ls2080a.c  |2 +-
>  board/freescale/ls2080aqds/MAINTAINERS |3 ---
>  board/freescale/ls2080aqds/ddr.c   |   27 
> +++-
>  board/freescale/ls2080aqds/ls2080aqds.c|2 +-
>  board/freescale/ls2080ardb/MAINTAINERS |3 ---
>  board/freescale/ls2080ardb/ddr.c   |   27 
> +++-
>  board/freescale/ls2080ardb/ls2080ardb.c|2 +-
>  configs/ls2085a_emu_defconfig  |   20 ---
>  configs/ls2085a_simu_defconfig |   21 ---
>  configs/ls2085aqds_SECURE_BOOT_defconfig   |   20 ---
>  configs/ls2085aqds_defconfig   |   19 --
>  configs/ls2085aqds_nand_defconfig  |   14 --
>  configs/ls2085ardb_SECURE_BOOT_defconfig   |   20 ---
>  configs/ls2085ardb_defconfig   |   19 --
>  configs/ls2085ardb_nand_defconfig  |   14 --
>  doc/device-tree-bindings/serial/8250.txt   |2 +-
>  drivers/crypto/fsl/jr.c|6 ++---
>  drivers/net/fsl-mc/mc.c|   10 
>  drivers/net/ldpaa_eth/Makefile |1 -
>  include/configs/ls2080a_common.h   |7 +
>  include/configs/ls2080a_emu.h  |7 -
>  include/configs/ls2080a_simu.h |7 -
>  include/linux/usb/xhci-fsl.h   |2 +-
>  36 files changed, 115 insertions(+), 248 deletions(-)
>  delete mode 100644 configs/ls2085a_emu_defconfig
>  delete mode 100644 configs/ls2085a_simu_defconfig
>  delete mode 100644 configs/ls2085aqds_SECURE_BOOT_defconfig
>  delete mode 100644 configs/ls2085aqds_defconfig
>  delete mode 100644 configs/ls2085aqds_nand_defconfig
>  delete mode 100644 configs/ls2085ardb_SECURE_BOOT_defconfig
>  delete mode 100644 configs/ls2085ardb_defconfig
>  delete mode 100644 configs/ls2085ardb_nand_defconfig
> 

Reviewed-by: Prabhakar Kushwaha 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

York

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

[U-Boot] [PATCH] am57x: Move CONS_INDEX to Kconfig

[Daniel Allred]

- Move the CONS_INDEX selection out of CONFIG_SYS_EXTRA_OPTIONS and
  into Kconfig proper.
- Edit the relevant am57x configs to remove the now unneeded
  CONFIG_SYS_EXTRA_OPTIONS.

Signed-off-by: Daniel Allred 
---
 board/ti/am57xx/Kconfig   | 9 +
 configs/am57xx_evm_defconfig  | 1 -
 configs/am57xx_evm_nodt_defconfig | 1 -
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/board/ti/am57xx/Kconfig b/board/ti/am57xx/Kconfig
index 17745ff..87654f9 100644
--- a/board/ti/am57xx/Kconfig
+++ b/board/ti/am57xx/Kconfig
@@ -9,6 +9,15 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "am57xx_evm"
 
+config CONS_INDEX
+int "UART used for console"
+range 1 6
+default 3
+help
+  The AM57x (and DRA7xx) SoC has a total of 6 UARTs available to it.
+  Depending on your specific board you may want something other than 
UART3
+  here.
+
 source "board/ti/common/Kconfig"
 
 endif
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index 1090287..e40c24a 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -7,7 +7,6 @@ CONFIG_SPL_STACK_R_ADDR=0x8200
 CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15"
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
-CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=3"
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
diff --git a/configs/am57xx_evm_nodt_defconfig 
b/configs/am57xx_evm_nodt_defconfig
index 7641db5..cb91719 100644
--- a/configs/am57xx_evm_nodt_defconfig
+++ b/configs/am57xx_evm_nodt_defconfig
@@ -2,7 +2,6 @@ CONFIG_ARM=y
 CONFIG_OMAP54XX=y
 CONFIG_TARGET_BEAGLE_X15=y
 CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=3"
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
-- 
1.9.1

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

Re: [U-Boot] [PATCH 0/8] usb: Move DWC3 and some gadget options to Kconfig

[Lukasz Majewski]

Hi Michal,

> On 6.4.2016 15:59, Lukasz Majewski wrote:
> > Hi Semen,
> > 
> >>
> >> Hi All,
> >>
> >> This patch series move next options to Kconfigs/defconfigs:
> >>  - CONFIG_USB_DWC3*
> >>  - CONFIG_USB_GADGET_VBUS_DRAW
> >>  - CONFIG_USB_GADGET_DUALSPEED (partially, only for DWC3 platforms
> >> for now)
> >>  - CONFIG_USB_GADGET_DOWNLOAD
> >>  - CONFIG_G_DNL_*
> >>
> >> All defconfig files were post-processed via "make savedefconfig"
> >> rule to keep correct order of options in defconfigs.
> >>
> >> The whole series was tested using buildman tool for all arm boards.
> >>
> > 
> > I've reviewed your work and I don't have any objections.
> > 
> > Now, I'm trying to setup python test environment (DFU, UMS), so I
> > cannot thoroughly test it.
> 
> test/py?

Yes, indeed.

I've some problems with stdin/stdout operation via u-boot-test-console
script with using cu on my Odroid XU3.

I do perform soft reset on my board (by sending "reset") and thereafter
it seems like no output from u-boot console is examined by pexpect.

I've asked Stephen for sharing his u-boot-test-console file, so he
pointed me towards his github:

https://github.com/swarren/uboot-test-hooks/blob/master/bin/u-boot-test-console

I hope I will solve this problem today :-).

> 
> Thanks,
> Michal
> 



-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [u-boot] [PATCH] arm: sleep: Get the entry point of kernel from SPARE4 register

[Scott Wood]

On 04/05/2016 09:16 PM, Huan Wang wrote:
> Hi, York and Scott,
> 
>> On 04/05/2016 05:11 AM, Alison Wang wrote:
>>> For LS1021A Secure Boot, SPARE2 register is used and modified by the
>>> IBR. To avoid the conflict, SPARE4 is used instead of SPARE2 to store
>>> the entry point of kernel. This patch is to get the entry point of
>>> kernel from SPARE4 instead of SPARE2.
>>>
>>> Signed-off-by: Alison Wang 
>>> ---
>>>  board/freescale/common/arm_sleep.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/board/freescale/common/arm_sleep.c
>>> b/board/freescale/common/arm_sleep.c
>>> index 71ed15e..6d967f0 100644
>>> --- a/board/freescale/common/arm_sleep.c
>>> +++ b/board/freescale/common/arm_sleep.c
>>> @@ -88,7 +88,7 @@ int fsl_dp_resume(void)
>>> dp_resume_prepare();
>>>
>>> /* Get the entry address and jump to kernel */
>>> -   start_addr = in_le32(&scfg->sparecr[1]);
>>> +   start_addr = in_le32(&scfg->sparecr[3]);
>>> debug("Entry address is 0x%08x\n", start_addr);
>>> kernel_resume = (void (*)(void))start_addr;
>>> secure_ram_addr(_do_nonsec_entry)(kernel_resume, 0, 0, 0);
>>>
>> Alison,
>>
>> Does this change need to be in sync with Kernel change?
>>
>> York
>>
>> Where does this get written?
>>
>> -Scott
> [Alison Wang] Thanks for your replies. Your concerns are right.
> SPARE4 register needs to be written in kernel.
> 
> This is an issue about deep sleep in LS1021A Secure Boot. It is found
> in SDK2.0. The corresponding patch for kernel is sent in SDK2.0. 
> 
> Well, deep sleep uses an old way in SDK2.0. For upstream, deep sleep
> patches haven't been sent out as it will use PSCI and there are some
> issues about PSCI. So the corresponding patch for kernel can't be sent
> out now.

It's not about when the patch is sent.  It's about managing
compatibility.  There needs to be some way to communicate what the
expectations are between Linux and U-Boot, or to limit the change to
chips where this feature has never worked before.  We can't introduce
regressions when the kernel is updated but not U-Boot, and regressions
when U-Boot is updated but not the kernel are almost as bad.

-Scott

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

Re: [U-Boot] Using U-Boot to load RTOS

[Niti Gupta]

On 6 April 2016 at 18:43, Peng Fan  wrote:

> On Wed, Apr 06, 2016 at 03:32:01PM +0530, Niti Gupta wrote:
> >
> >On 6 April 2016 at 14:33, Peng Fan  wrote:
> >
> >Hi Niti,
> >
> >On Wed, Apr 06, 2016 at 01:39:31PM +0800, Bin Meng wrote:
> >>On Wed, Apr 6, 2016 at 1:21 PM, Niti Gupta 
> wrote:
> >>> Hello Bin,
> >>>
> >>> I am trying to load Segger's embOS.
> >>>
> >>
> >>Please avoid top-posting.
> >>
> >>I don't know this OS, but you can try 'bootelf' command if embOS
> image
> >>is an ELF image. If there is anything special, you need write your
> own
> >>boot command for the OS.
> >
> >Besids bootelf, you can directly using command "go", if your image is
> >a bin file.
> >
> >Share my way to boot rtems on i.MX6UL.
> >
> >first load you os bin file to a dram address, saying 0x80008000,
> >then
> >dcache off
> >icache off
> >dcache flush
> >icache flush
> >go 0x80008000
> >
> >Regards,
> >Peng
> >
> >
> >Hello Peng,
> >I tried following commands in order to load os bin file
> >
> >"loadb 0x80008000
> >## Ready for binary (kermit) download to 0x80008000 at 115200 bps...
> >## Total Size  = 0x00018fac = 102316 Bytes
> >## Start Addr  = 0x80008000
> >=> dcache off
> >=> icache off
> >=> dcache flush
> >=> icache flush
> >=> go 0x8000800"
>
> why change 0x80008000 to 0x8000800 when go command?
>
> 0x80008000 is just an example in my side. You should know the entry
> address of your embedded os if using bin file.
>
> Regards,
> Peng.
>

Hello Peng
Thanks for reply. I am building my image using IAR and the sample project
containing BSP for i.MUX6UL provided by embOS. It is a simple application
to check CPU performance. After building this application Start_imxUL.bin
is generated. I am trying to boot this image from sd card. I don't know how
to check or detect entry point of this image. Kindly help me  to figure
this out. It will be a great help for me.

Thanks,
Niti

>
> >
> >but it is showing following errors
> >
> >undefined instruction
> >pc : [<00912a5c>]  lr : [<9ff5882c>]
> >reloc pc : []lr : [<8780582c>]
> >sp : 9ef50d58  ip : e59ff018 fp : 9ef568b0
> >r10: 0002  r9 : 9ef50eb8 r8 : 9ffa1d04
> >r7 : 9efd73a8  r6 : 6a0191a8 r5 : 0002  r4 : 9efd73ac
> >r3 : 80008abd  r2 : 9efd73ac r1 : 9efd73ac  r0 : 0001
> >Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> >Resetting CPU ...
> >
> >resetting ...
> >
> >I am using default u-boot for i.MUX6UL  which is
> "u-boot-imx6ulevk_sd.imx". Do
> >I need to rebuild u-boot after some rework?
> >Kindly help, I am completely stuck over here, failed to find appropriate
> way to
> >load RTOS from SD Card.
> >
> >Thanks,
> >Niti Gupta
> >
> >
> >>
> >>> Thanks,
> >>> Niti Gupta
> >>>
> >>> On 6 April 2016 at 07:18, Bin Meng  wrote:
> >>>>
> >>>> On Wed, Apr 6, 2016 at 3:07 AM, Niti Gupta <
> gupta.nit...@gmail.com>
> >wrote:
> >>>> > Hello,
> >>>> >
> >>>> >
> >>>> > I am working on embedded systems. I want to use u-boot to load
> rtos
> >on
> >>>> > freescale i.MUX6UL board but failed to find appropriate way to
> do
> >>>> > this. Kindly help me to find out steps to load rtos from u-boot.
> >>>> >
> >>>>
> >>>> What RTOS are you trying to load?
> >>
> >>Regards,
> >>Bin
> >>___
> >>U-Boot mailing list
> >>U-Boot@lists.denx.de
> >>http://lists.denx.de/mailman/listinfo/u-boot
> >
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/8] usb: Move DWC3 and some gadget options to Kconfig

[Michal Simek]

On 6.4.2016 15:59, Lukasz Majewski wrote:
> Hi Semen,
> 
>>
>> Hi All,
>>
>> This patch series move next options to Kconfigs/defconfigs:
>>  - CONFIG_USB_DWC3*
>>  - CONFIG_USB_GADGET_VBUS_DRAW
>>  - CONFIG_USB_GADGET_DUALSPEED (partially, only for DWC3 platforms
>> for now)
>>  - CONFIG_USB_GADGET_DOWNLOAD
>>  - CONFIG_G_DNL_*
>>
>> All defconfig files were post-processed via "make savedefconfig" rule
>> to keep correct order of options in defconfigs.
>>
>> The whole series was tested using buildman tool for all arm boards.
>>
> 
> I've reviewed your work and I don't have any objections.
> 
> Now, I'm trying to setup python test environment (DFU, UMS), so I cannot
> thoroughly test it.

test/py?

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

Re: [U-Boot] [PATCH v2 1/2] kconfig: Move CONFIG_OF_LIBFDT to Kconfig

[Michal Simek]

Hi,

On 6.4.2016 22:34, Ricardo Ribalda Delgado wrote:
> Hi Michal
> 
> xilinx-ppc405-generic and xilinx-ppc440-generic also depend on
> xilinx-ppc.h So I think this is missing.
> 
> Shall I send this as a separated patch? or you want to include it in yours?

I was checking that and LIBFDT is enabled by default that's why there
was not defconfig update. Definitely feel free to check it and test if
this patch breaks something.

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

Re: [U-Boot] [PATCH v3 1/1] mpc85xx: Enable pre-relocation malloc for MPC85xx

[Mario Six]

Quoting York Sun :


On 04/05/2016 06:06 AM, Mario Six wrote:

To enable DM on MPC85xx, we need pre-relocation malloc, which is
implemented in this patch.

We also make sure that the IVORs are always 4-aligned on e500 to prevent
alignment exceptions caused by code changes in start.S.

Signed-off-by: Mario Six 
Cc: York Sun 
Cc: Simon Glass 
---

v3:
 - Add comment regarding gd zeroing
 - Unconditionally zero out initial RAM during startup

v2:
 - Correct IVOR alignment and remove nop hack
 - Add sanity check for length of malloc area


 arch/powerpc/cpu/mpc85xx/cpu_init_early.c |  8 +---
 arch/powerpc/cpu/mpc85xx/start.S  | 30  
++

 include/ppc_asm.tmpl  |  3 +++
 3 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c  
b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c

index 235a635..85b4112 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
@@ -82,7 +82,6 @@ void setup_ifc(void)
 void cpu_init_early_f(void *fdt)
 {
u32 mas0, mas1, mas2, mas3, mas7;
-   int i;


This causes a problem. Variable "i" is still used at line 158.
I can fix it unless you want to respin the patch.

York


Just fix it; no need to go through the whole procedure again for  
something like

that :-)

Thanks for all the help and best regards,

Mario

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

[U-Boot] [PATCH] gpio: mvebu_gpio: Add missing out value set to gpio_direction_output()

[Stefan Roese]

This patch adds the missing configuration of the output value to the
gpio_direction_output() function. Without this, calling
gpio_direction_output() does not set the out-value at all and only
configures the gpio as output.

Signed-off-by: Stefan Roese 
Cc: Kevin Smith 
---
 drivers/gpio/mvebu_gpio.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/mvebu_gpio.c b/drivers/gpio/mvebu_gpio.c
index 9564ce2..75dc73e 100644
--- a/drivers/gpio/mvebu_gpio.c
+++ b/drivers/gpio/mvebu_gpio.c
@@ -43,6 +43,10 @@ static int mvebu_gpio_direction_output(struct udevice *dev, 
unsigned gpio,
struct mvebu_gpio_priv *priv = dev_get_priv(dev);
struct mvebu_gpio_regs *regs = priv->regs;
 
+   if (value)
+   setbits_le32(®s->data_out, BIT(gpio));
+   else
+   clrbits_le32(®s->data_out, BIT(gpio));
clrbits_le32(®s->io_conf, BIT(gpio));
 
return 0;
-- 
2.8.1

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

Re: [U-Boot] [PATCH] board: ge: bx50v3: Update display setup

[Akshay Bhat]

On Wed, Apr 6, 2016 at 11:22 AM, Fabio Estevam  wrote:

> On Wed, Apr 6, 2016 at 12:18 PM, Stefano Babic  wrote:
>
> > I frankly ask you if you think that this function can be factorized and
> > moved from board code to common code. What do you think ? Is there
> > something that let the implementation bound to the board (I have not
> > seen it) ?
>
> Agreed. This should be in common code so that other boards can use it.
>

Appreciate the feedback. I will break up the commits and resubmit the
patch, moving the function to common code.

Fabio, does the errata apply to all i.MX6 based processors? If not, which
ones should use the errata?

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

Re: [U-Boot] [PATCH] imx: mx6var_som: Add support for Variscite mx6 boards

[Stefano Babic]

Hi Eran,

On 31/03/2016 15:53, Eran Matityahu wrote:
> Add support for Variscite VAR-SOM-MX6 / DART-MX6 / VAR-SOM-SOLO/DUAL boards 
> with features:
> PMIC, NAND flash, SD/MMC, USB, Ethernet, I2C, LVDS, HDMI.
> 
> Signed-off-by: Eran Matityahu 
> ---
>  arch/arm/cpu/armv7/mx6/Kconfig|7 +
>  board/variscite/mx6var_som/Kconfig|   12 +
>  board/variscite/mx6var_som/MAINTAINERS|8 +
>  board/variscite/mx6var_som/Makefile   |9 +
>  board/variscite/mx6var_som/addresses.inc  |   38 +
>  board/variscite/mx6var_som/imximage.cfg   |   13 +
>  board/variscite/mx6var_som/mx6var_eeprom.c|  320 +
>  board/variscite/mx6var_som/mx6var_eeprom.h|   88 ++
>  board/variscite/mx6var_som/mx6var_eeprom_v2.c |  231 
>  board/variscite/mx6var_som/mx6var_eeprom_v2.h |   55 +
>  board/variscite/mx6var_som/mx6var_som.c   | 1587 
> +
>  board/variscite/mx6var_som/u-boot-spl.lds |   59 +
>  board/variscite/mx6var_som/values.inc |   39 +
>  configs/mx6var_som_nand_defconfig |7 +
>  configs/mx6var_som_sd_defconfig   |7 +
>  include/configs/mx6var_som.h  |  419 +++
>  include/configs/mx6var_spl.h  |   81 ++
>  tools/logos/variscite.bmp |  Bin 0 -> 15414 bytes

This is a very big patch, just not easy to review. Is there any
possibility to split it ? I have my difficulties to review such a
monstruous patch.

It is so big that my answer was blocked by the ML due to the size (it
exceeds 100K). I have to drop some parts to avoid the block.

Some general notes:

- SPL is automatically set. Which is the reason to have an own
imximage.cfg ? All boards use the same. You do not need to set "booting
from nand" or BOOT FROM SD", because they share the same start offset in
the storage.

- can you better explain the reason under the ddr configuration in EEPROM ?

> +endif
> diff --git a/board/variscite/mx6var_som/MAINTAINERS 
> b/board/variscite/mx6var_som/MAINTAINERS
> new file mode 100644
> index 000..f3f81dd
> --- /dev/null
> +++ b/board/variscite/mx6var_som/MAINTAINERS
> @@ -0,0 +1,8 @@
> +MX6VAR_SOM BOARD
> +M:   Eran Matityahu 
> +S:   Maintained
> +F:   board/variscite/mx6var_som/
> +F:   include/configs/mx6var_som.h
> +F:   include/configs/mx6var_spl.h
> +F:   configs/mx6var_som_nand_defconfig
> +F:   configs/mx6var_som_sd_defconfig

The list must match the files you want must be added to the projects.
Just a few of them are listed here.

> diff --git a/board/variscite/mx6var_som/Makefile 
> b/board/variscite/mx6var_som/Makefile
> new file mode 100644
> index 000..efa90e2
> --- /dev/null
> +++ b/board/variscite/mx6var_som/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Copyright (C) 2007, Guennadi Liakhovetski 
> +#
> +# (C) Copyright 2011 Freescale Semiconductor, Inc.
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +obj-y  := mx6var_som.o mx6var_eeprom.o mx6var_eeprom_v2.o
> diff --git a/board/variscite/mx6var_som/addresses.inc 
> b/board/variscite/mx6var_som/addresses.inc
> new file mode 100644
> index 000..3aaea54
> --- /dev/null
> +++ b/board/variscite/mx6var_som/addresses.inc
> @@ -0,0 +1,38 @@
> +0x, 0x020C4068, 0x020C406C, 0x020C4070,

> +0x021B4818, 0x021B481C, 0x021B4820, 0x021B4824,
> +0x021B4828, 0x021B482C, 0x021B4830, 0x021B4834,
> +0x021B4838, 0x021B483C, 0x021B4840, 0x021B4848,
> +0x021B4850, 0x021B485C, 0x021B4890, 0x021B48B8,
> +0x021B48BC, 0x021B48C0

I miss why it shhoul be necessary this. Indeed, they are addresses that
are saved as structures into imx6-regs.h. Why do you need your custom way ?

> diff --git a/board/variscite/mx6var_som/imximage.cfg 
> b/board/variscite/mx6var_som/imximage.cfg
> new file mode 100644
> index 000..54dc449
> --- /dev/null
> +++ b/board/variscite/mx6var_som/imximage.cfg
> @@ -0,0 +1,13 @@
> +/*
> + * Copyright (C) 2016 Variscite Ltd. All Rights Reserved.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +IMAGE_VERSION2
> +
> +#ifdef CONFIG_SYS_BOOT_NAND
> +BOOT_FROM   nand
> +#else
> +BOOT_FROM   sd
> +#endif

I think the file is not needed at all and you can use the general
rch/arm/imx-common/spl_sd.cfg.

> diff --git a/board/variscite/mx6var_som/mx6var_eeprom.c 
> b/board/variscite/mx6var_som/mx6var_eeprom.c
> new file mode 100644
> index 000..02fedd0
> --- /dev/null
> +++ b/board/variscite/mx6var_som/mx6var_eeprom.c
> @@ -0,0 +1,320 @@
> +/*
> + * Copyright (C) 2016 Variscite Ltd. All Rights Reserved.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +

I start telling you that I do not understand the meaning for
mx6var_eeprom.c and mx6var_eepromV2.c

> +#include 
> +#include 
> +#include 
> +#include "mx6var_eeprom.h"
> +#ifdef CONFIG_SPL_BUILD
> +#include 
> +
> +#ifdef EEPROM_DEBUG
> +#define eeprom_debug(M, ...) printf("EEPROM DEBUG: " M, ##__VA_ARGS__)
> +#else
> +#define eeprom_debug(M, ...)
> +#endif
> +
> +bool var_eeprom_is_valid(st

Re: [U-Boot] [uboot][PATCH v3 1/2] net: phy: dp83867: Add device tree bindings and documentation

[Mugunthan V N]

On Wednesday 06 April 2016 05:07 PM, Dan Murphy wrote:
> Add the device tree bindings and the accompanying documentation
> for the TI DP83867 Giga bit ethernet phy driver.
> 
> The original document was from:
> [commit 2a10154abcb75ad0d7b6bfea6210ac743ec60897 from the Linux kernel]
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> v3 - Modify the binding to the kernel changed int -> internal for the delay - 
> https://patchwork.ozlabs.org/patch/606595/
> 
>  doc/device-tree-bindings/net/ti,dp83867.txt | 29 
>  include/dt-bindings/net/ti-dp83867.h| 35 
> +
>  2 files changed, 64 insertions(+)
>  create mode 100644 doc/device-tree-bindings/net/ti,dp83867.txt
>  create mode 100644 include/dt-bindings/net/ti-dp83867.h
> 
> diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt 
> b/doc/device-tree-bindings/net/ti,dp83867.txt
> new file mode 100644
> index 000..0ec009c
> --- /dev/null
> +++ b/doc/device-tree-bindings/net/ti,dp83867.txt
> @@ -0,0 +1,29 @@
> +* Texas Instruments - dp83867 Giga bit ethernet phy
> +
> +Required properties:
> + - ti,rx-internal-delay - RGMII Recieve Clock Delay - see 
> dt-bindings/net/ti-dp83867.h
> + for applicable values
> + - ti,tx-internal-delay - RGMII Transmit Clock Delay - see 
> dt-bindings/net/ti-dp83867.h
> + for applicable values
> + - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
> + for applicable values
> +
> +Default child nodes are standard Ethernet PHY device
> +nodes as described in doc/devicetree/bindings/net/ethernet.txt
> +
> +Example:
> +
> +&mac {
> + pinctrl-0 = <&davinci_mdio_default>;
> + pinctrl-1 = <&davinci_mdio_sleep>;
> + status = "okay";
> +
> + ti,rx_internal_delay = ;
> + ti,tx_internal_delay = ;
> + ti,fifo_depth = ;
> +
> +};

This example should in phy node and not in mac node as per the linux
commmit mentioned above?

Regards
Mugunthan V N

> +
> +
> +Datasheet can be found:
> +http://www.ti.com/product/DP83867IR/datasheet
> diff --git a/include/dt-bindings/net/ti-dp83867.h 
> b/include/dt-bindings/net/ti-dp83867.h
> new file mode 100644
> index 000..5c592fb
> --- /dev/null
> +++ b/include/dt-bindings/net/ti-dp83867.h
> @@ -0,0 +1,35 @@
> +/*
> + * TI DP83867 PHY drivers
> + *
> + * SPDX-License-Identifier:  GPL-2.0
> + *
> + */
> +
> +#ifndef _DT_BINDINGS_TI_DP83867_H
> +#define _DT_BINDINGS_TI_DP83867_H
> +
> +/* PHY CTRL bits */
> +#define DP83867_PHYCR_FIFO_DEPTH_3_B_NIB 0x00
> +#define DP83867_PHYCR_FIFO_DEPTH_4_B_NIB 0x01
> +#define DP83867_PHYCR_FIFO_DEPTH_6_B_NIB 0x02
> +#define DP83867_PHYCR_FIFO_DEPTH_8_B_NIB 0x03
> +
> +/* RGMIIDCTL internal delay for rx and tx */
> +#define  DP83867_RGMIIDCTL_250_PS0x0
> +#define  DP83867_RGMIIDCTL_500_PS0x1
> +#define  DP83867_RGMIIDCTL_750_PS0x2
> +#define  DP83867_RGMIIDCTL_1_NS  0x3
> +#define  DP83867_RGMIIDCTL_1_25_NS   0x4
> +#define  DP83867_RGMIIDCTL_1_50_NS   0x5
> +#define  DP83867_RGMIIDCTL_1_75_NS   0x6
> +#define  DP83867_RGMIIDCTL_2_00_NS   0x7
> +#define  DP83867_RGMIIDCTL_2_25_NS   0x8
> +#define  DP83867_RGMIIDCTL_2_50_NS   0x9
> +#define  DP83867_RGMIIDCTL_2_75_NS   0xa
> +#define  DP83867_RGMIIDCTL_3_00_NS   0xb
> +#define  DP83867_RGMIIDCTL_3_25_NS   0xc
> +#define  DP83867_RGMIIDCTL_3_50_NS   0xd
> +#define  DP83867_RGMIIDCTL_3_75_NS   0xe
> +#define  DP83867_RGMIIDCTL_4_00_NS   0xf
> +
> +#endif
> 

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

Re: [U-Boot] [PATCH 0/2] ARM: AT91: add AT91 PIO4 pinctrl driver

[Yang, Wenyou]

Hi Andreas,

> -Original Message-
> From: Andreas Bießmann [mailto:andr...@biessmann.de]
> Sent: 2016年4月7日 12:21
> To: Yang, Wenyou 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 0/2] ARM: AT91: add AT91 PIO4 pinctrl driver
> 
> Hi Wenyou,
> 
> Really cool to see the first dm based driver for atmel devices! I'll dive 
> into this
> weekend.

Thank you for your encouragement.

We have a plan that more dm based drivers for atmel devices will be sent in 
next few months, :)

> 
> Best regards
> 
> Andreas
> 
> > Am 07.04.2016 um 04:15 schrieb Wenyou Yang :
> >
> > AT91 PIO4 controller is a combined gpio-controller, pin-mux and
> > pin-config module. This patch is to add the pinctrl driver with driver
> > model and device tree support.
> >
> >
> > Wenyou Yang (2):
> >  pinctrl: at91-pio4: add pinctrl driver
> >  atmel: bring in at91 pio4 device tree file and bindings
> >
> > arch/arm/dts/sama5d2-pinfunc.h | 880 
> > +
> > arch/arm/mach-at91/include/mach/atmel_pio4.h   |  35 +
> > .../pinctrl/atmel,at91-pio4-pinctrl.txt|  65 ++
> > drivers/pinctrl/Kconfig|   7 +
> > drivers/pinctrl/Makefile   |   1 +
> > drivers/pinctrl/pinctrl-at91-pio4.c| 164 
> > 6 files changed, 1152 insertions(+)
> > create mode 100644 arch/arm/dts/sama5d2-pinfunc.h create mode 100644
> > doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
> > create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c
> >
> > --
> > 2.7.4
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot

Best Regards,
Wenyou Yang

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

Re: [U-Boot] [PATCH] mmc:fsl_esdhc: fix invalidate dcache scope

[Shengzhou Liu]

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Wednesday, April 06, 2016 11:26 PM
> To: Shengzhou Liu ; u-boot@lists.denx.de
> Subject: Re: [PATCH] mmc:fsl_esdhc: fix invalidate dcache scope
> >
> 
> Shenghzou,
> 
> This is not a correct fix. This issue is related to
> 
> http://lists.denx.de/pipermail/u-boot/2015-December/236272.html
> http://lists.denx.de/pipermail/u-boot/2016-March/249377.html
> 
> In short, the invalidate_dcache_range function was added for
> 512x/5xxx/83xx/85xx. Although it shouldn't do any harm, it actually does. I
> haven't got a chance to investigate. Please look into it if you can.
> 
> York

York,   
This patch is just a quick hack, I thought root cause is needed to be dug, this 
issue didn't occur on ARM, just happened on PPC(e.g. T1/T2/T4 platforms). I 
have no time on this(occupied on ONL), suggest MMC owner continue to 
investigate it.
Shengzhou
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] ARM: AT91: add AT91 PIO4 pinctrl driver

[Andreas Bießmann]

Hi Wenyou,

Really cool to see the first dm based driver for atmel devices! I'll dive into 
this weekend.

Best regards

Andreas

> Am 07.04.2016 um 04:15 schrieb Wenyou Yang :
> 
> AT91 PIO4 controller is a combined gpio-controller, pin-mux and
> pin-config module. This patch is to add the pinctrl driver with
> driver model and device tree support.
> 
> 
> Wenyou Yang (2):
>  pinctrl: at91-pio4: add pinctrl driver
>  atmel: bring in at91 pio4 device tree file and bindings
> 
> arch/arm/dts/sama5d2-pinfunc.h | 880 +
> arch/arm/mach-at91/include/mach/atmel_pio4.h   |  35 +
> .../pinctrl/atmel,at91-pio4-pinctrl.txt|  65 ++
> drivers/pinctrl/Kconfig|   7 +
> drivers/pinctrl/Makefile   |   1 +
> drivers/pinctrl/pinctrl-at91-pio4.c| 164 
> 6 files changed, 1152 insertions(+)
> create mode 100644 arch/arm/dts/sama5d2-pinfunc.h
> create mode 100644 
> doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
> create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c
> 
> -- 
> 2.7.4
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[U-Boot] [PATCH 2/2] atmel: bring in at91 pio4 device tree file and bindings

[Wenyou Yang]

Bring in required device tree files from Linux.

Signed-off-by: Wenyou Yang 
---

 arch/arm/dts/sama5d2-pinfunc.h | 880 +
 .../pinctrl/atmel,at91-pio4-pinctrl.txt|  65 ++
 2 files changed, 945 insertions(+)
 create mode 100644 arch/arm/dts/sama5d2-pinfunc.h
 create mode 100644 doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt

diff --git a/arch/arm/dts/sama5d2-pinfunc.h b/arch/arm/dts/sama5d2-pinfunc.h
new file mode 100644
index 000..b0c912f
--- /dev/null
+++ b/arch/arm/dts/sama5d2-pinfunc.h
@@ -0,0 +1,880 @@
+#define PINMUX_PIN(no, func, ioset) \
+(((no) & 0x) | (((func) & 0xf) << 16) | (((ioset) & 0xff) << 20))
+
+#define PIN_PA00
+#define PIN_PA0__GPIO  PINMUX_PIN(PIN_PA0, 0, 0)
+#define PIN_PA0__SDMMC0_CK PINMUX_PIN(PIN_PA0, 1, 1)
+#define PIN_PA0__QSPI0_SCK PINMUX_PIN(PIN_PA0, 2, 1)
+#define PIN_PA0__D0PINMUX_PIN(PIN_PA0, 6, 2)
+#define PIN_PA11
+#define PIN_PA1__GPIO  PINMUX_PIN(PIN_PA1, 0, 0)
+#define PIN_PA1__SDMMC0_CMDPINMUX_PIN(PIN_PA1, 1, 1)
+#define PIN_PA1__QSPI0_CS  PINMUX_PIN(PIN_PA1, 2, 1)
+#define PIN_PA1__D1PINMUX_PIN(PIN_PA1, 6, 2)
+#define PIN_PA22
+#define PIN_PA2__GPIO  PINMUX_PIN(PIN_PA2, 0, 0)
+#define PIN_PA2__SDMMC0_DAT0   PINMUX_PIN(PIN_PA2, 1, 1)
+#define PIN_PA2__QSPI0_IO0 PINMUX_PIN(PIN_PA2, 2, 1)
+#define PIN_PA2__D2PINMUX_PIN(PIN_PA2, 6, 2)
+#define PIN_PA33
+#define PIN_PA3__GPIO  PINMUX_PIN(PIN_PA3, 0, 0)
+#define PIN_PA3__SDMMC0_DAT1   PINMUX_PIN(PIN_PA3, 1, 1)
+#define PIN_PA3__QSPI0_IO1 PINMUX_PIN(PIN_PA3, 2, 1)
+#define PIN_PA3__D3PINMUX_PIN(PIN_PA3, 6, 2)
+#define PIN_PA44
+#define PIN_PA4__GPIO  PINMUX_PIN(PIN_PA4, 0, 0)
+#define PIN_PA4__SDMMC0_DAT2   PINMUX_PIN(PIN_PA4, 1, 1)
+#define PIN_PA4__QSPI0_IO2 PINMUX_PIN(PIN_PA4, 2, 1)
+#define PIN_PA4__D4PINMUX_PIN(PIN_PA4, 6, 2)
+#define PIN_PA55
+#define PIN_PA5__GPIO  PINMUX_PIN(PIN_PA5, 0, 0)
+#define PIN_PA5__SDMMC0_DAT3   PINMUX_PIN(PIN_PA5, 1, 1)
+#define PIN_PA5__QSPI0_IO3 PINMUX_PIN(PIN_PA5, 2, 1)
+#define PIN_PA5__D5PINMUX_PIN(PIN_PA5, 6, 2)
+#define PIN_PA66
+#define PIN_PA6__GPIO  PINMUX_PIN(PIN_PA6, 0, 0)
+#define PIN_PA6__SDMMC0_DAT4   PINMUX_PIN(PIN_PA6, 1, 1)
+#define PIN_PA6__QSPI1_SCK PINMUX_PIN(PIN_PA6, 2, 1)
+#define PIN_PA6__TIOA5 PINMUX_PIN(PIN_PA6, 4, 1)
+#define PIN_PA6__FLEXCOM2_IO0  PINMUX_PIN(PIN_PA6, 5, 1)
+#define PIN_PA6__D6PINMUX_PIN(PIN_PA6, 6, 2)
+#define PIN_PA77
+#define PIN_PA7__GPIO  PINMUX_PIN(PIN_PA7, 0, 0)
+#define PIN_PA7__SDMMC0_DAT5   PINMUX_PIN(PIN_PA7, 1, 1)
+#define PIN_PA7__QSPI1_IO0 PINMUX_PIN(PIN_PA7, 2, 1)
+#define PIN_PA7__TIOB5 PINMUX_PIN(PIN_PA7, 4, 1)
+#define PIN_PA7__FLEXCOM2_IO1  PINMUX_PIN(PIN_PA7, 5, 1)
+#define PIN_PA7__D7PINMUX_PIN(PIN_PA7, 6, 2)
+#define PIN_PA88
+#define PIN_PA8__GPIO  PINMUX_PIN(PIN_PA8, 0, 0)
+#define PIN_PA8__SDMMC0_DAT6   PINMUX_PIN(PIN_PA8, 1, 1)
+#define PIN_PA8__QSPI1_IO1 PINMUX_PIN(PIN_PA8, 2, 1)
+#define PIN_PA8__TCLK5 PINMUX_PIN(PIN_PA8, 4, 1)
+#define PIN_PA8__FLEXCOM2_IO2  PINMUX_PIN(PIN_PA8, 5, 1)
+#define PIN_PA8__NWE_NANDWEPINMUX_PIN(PIN_PA8, 6, 2)
+#define PIN_PA99
+#define PIN_PA9__GPIO  PINMUX_PIN(PIN_PA9, 0, 0)
+#define PIN_PA9__SDMMC0_DAT7   PINMUX_PIN(PIN_PA9, 1, 1)
+#define PIN_PA9__QSPI1_IO2 PINMUX_PIN(PIN_PA9, 2, 1)
+#define PIN_PA9__TIOA4 PINMUX_PIN(PIN_PA9, 4, 1)
+#define PIN_PA9__FLEXCOM2_IO3  PINMUX_PIN(PIN_PA9, 5, 1)
+#define PIN_PA9__NCS3  PINMUX_PIN(PIN_PA9, 6, 2)
+#define PIN_PA10   10
+#define PIN_PA10__GPIO PINMUX_PIN(PIN_PA10, 0, 0)
+#define PIN_PA10__SDMMC0_RSTN  PINMUX_PIN(PIN_PA10, 1, 1)
+#define PIN_PA10__QSPI1_IO3PINMUX_PIN(PIN_PA10, 2, 1)
+#define PIN_PA10__TIOB4PINMUX_PIN(PIN_PA10, 4, 1)
+#define PIN_PA10__FLEXCOM2_IO4 PINMUX_PIN(PIN_PA10, 5, 1)
+#define PIN_PA10__A21_NANDALE  PINMUX_PIN(PIN_PA10, 6, 2)
+#define PIN_PA11   11
+#define PIN_PA11__GPIO PINMUX_PIN(PIN_PA11, 0, 0)
+#define PIN_PA11__SDMMC0_VDDSELPINMUX_PIN(PIN_PA11, 1, 1)

[U-Boot] [PATCH 1/2] pinctrl: at91-pio4: add pinctrl driver

[Wenyou Yang]

AT91 PIO4 controller is a combined gpio-controller, pin-mux and
pin-config module. The peripherals are assigned pins through per-pin
based muxing logic. And the pin configuration are performed on
specific registers which are shared along with the gpio controller.

Signed-off-by: Wenyou Yang 
---

 arch/arm/mach-at91/include/mach/atmel_pio4.h |  35 ++
 drivers/pinctrl/Kconfig  |   7 ++
 drivers/pinctrl/Makefile |   1 +
 drivers/pinctrl/pinctrl-at91-pio4.c  | 164 +++
 4 files changed, 207 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c

diff --git a/arch/arm/mach-at91/include/mach/atmel_pio4.h 
b/arch/arm/mach-at91/include/mach/atmel_pio4.h
index 8bb4b12..6760bec 100644
--- a/arch/arm/mach-at91/include/mach/atmel_pio4.h
+++ b/arch/arm/mach-at91/include/mach/atmel_pio4.h
@@ -29,6 +29,41 @@ struct atmel_pio4_port {
 
 #endif
 
+/*
+ * PIO Configuration Register Fields
+ */
+#define ATMEL_PIO_CFGR_FUNC_MASK   GENMASK(2, 0)
+#define ATMEL_PIO_CFGR_FUNC_GPIO   (0x0 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_A   (0x1 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_B   (0x2 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_C   (0x3 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_D   (0x4 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_E   (0x5 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_F   (0x6 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_G   (0x7 << 0)
+#define ATMEL_PIO_DIR_MASK BIT(8)
+#define ATMEL_PIO_PUEN_MASKBIT(9)
+#define ATMEL_PIO_PDEN_MASKBIT(10)
+#define ATMEL_PIO_IFEN_MASKBIT(12)
+#define ATMEL_PIO_IFSCEN_MASK  BIT(13)
+#define ATMEL_PIO_OPD_MASK BIT(14)
+#define ATMEL_PIO_SCHMITT_MASK BIT(15)
+#define ATMEL_PIO_CFGR_EVTSEL_MASK GENMASK(26, 24)
+#define ATMEL_PIO_CFGR_EVTSEL_FALLING  (0 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_RISING   (1 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_BOTH (2 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_LOW  (3 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_HIGH (4 << 24)
+
+#define ATMEL_PIO_NPINS_PER_BANK   32
+#define ATMEL_PIO_BANK(pin_id) (pin_id / ATMEL_PIO_NPINS_PER_BANK)
+#define ATMEL_PIO_LINE(pin_id) (pin_id % ATMEL_PIO_NPINS_PER_BANK)
+#define ATMEL_PIO_BANK_OFFSET  0x40
+
+#define ATMEL_GET_PIN_NO(pinfunc)  ((pinfunc) & 0xff)
+#define ATMEL_GET_PIN_FUNC(pinfunc)((pinfunc >> 16) & 0xf)
+#define ATMEL_GET_PIN_IOSET(pinfunc)   ((pinfunc >> 20) & 0xf)
+
 #define AT91_PIO_PORTA 0x0
 #define AT91_PIO_PORTB 0x1
 #define AT91_PIO_PORTC 0x2
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 2a69bab..e71f298 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -105,6 +105,13 @@ config SPL_PINCONF
 
 if PINCTRL || SPL_PINCTRL
 
+config PINCTRL_AT91PIO4
+   bool "AT91 PIO4 pinctrl driver"
+   depends on DM
+   help
+ This option is to enable the AT91 pinctrl driver for AT91 PIO4
+ controller which is available on SAMA5D2 SoC.
+
 config ROCKCHIP_PINCTRL
bool "Rockchip pin control driver"
depends on DM
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 37dc904..bd0dea2 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -5,6 +5,7 @@
 obj-y  += pinctrl-uclass.o
 obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC)   += pinctrl-generic.o
 
+obj-$(CONFIG_PINCTRL_AT91PIO4) += pinctrl-at91-pio4.o
 obj-y  += nxp/
 obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
 obj-$(CONFIG_PINCTRL_SANDBOX)  += pinctrl-sandbox.o
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
new file mode 100644
index 000..e4ca5dc
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -0,0 +1,164 @@
+/*
+ * Atmel PIO4 pinctrl driver
+ *
+ * Copyright (C) 2016 Atmel Corporation
+ *   Wenyou.Yang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Warning:
+ * In order to not introduce confusion between Atmel PIO groups and pinctrl
+ * framework groups, Atmel PIO groups will be called banks, line is kept to
+ * designed the pin id into this bank.
+ */
+
+struct atmel_pio4_platdata {
+   struct atmel_pio4_port *reg_base;
+};
+
+static const struct pinconf_param conf_params[] = {
+   { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
+   { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
+   { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
+   { "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
+   { "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
+   { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
+   { "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
+};
+
+static u32 atmel_pinctrl_get_pinconf(const void *blob, int node)
+{

[U-Boot] [PATCH 0/2] ARM: AT91: add AT91 PIO4 pinctrl driver

[Wenyou Yang]

AT91 PIO4 controller is a combined gpio-controller, pin-mux and
pin-config module. This patch is to add the pinctrl driver with
driver model and device tree support.


Wenyou Yang (2):
  pinctrl: at91-pio4: add pinctrl driver
  atmel: bring in at91 pio4 device tree file and bindings

 arch/arm/dts/sama5d2-pinfunc.h | 880 +
 arch/arm/mach-at91/include/mach/atmel_pio4.h   |  35 +
 .../pinctrl/atmel,at91-pio4-pinctrl.txt|  65 ++
 drivers/pinctrl/Kconfig|   7 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinctrl-at91-pio4.c| 164 
 6 files changed, 1152 insertions(+)
 create mode 100644 arch/arm/dts/sama5d2-pinfunc.h
 create mode 100644 doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c

-- 
2.7.4

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/07/2016 03:42 AM, George Broz wrote:

Hi,

>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
>>> drivers/ddr/altera/sequencer.c: Calibration complete
>>> Trying to boot from MMC1
>>>
>>> First time that an SPL built from a recent version has run successfully
>>> on that board.
>>>
>>> Will try it out on de0 tomorrow morning...
>>
>> This is great news, thanks!
> 
> This patch also fixes the intermittent SDRAM calibration failures on my
> de0_nano_soc board. Thanks so much!

Great

> Now with up-to-date versions of SPL and image... I have some
> USB questions/news/observations:
> 
> When using an OTG cable between USB port and mass storage
> device, the de0_nano_soc board is able to detect and access some USB
> sticks. The detection with these is almost immediate from when 'usb start'
> is entered. If the same (working) USB stick is used with a non-OTG cable,
> I get the timeout messages from before:
> 
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> 
> and this is true even if I add 'dr_mode = "host" '

I don't think the driver supports the dr_mode property yet. Patch is
welcome.

> to the dts for usb1
> of the de0
> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
> What is the correct "expected" behavior here?? Is an OTG cable required or
> not?

The DWC2 driver tests the value of the OTG ID pin, so if you don't use
OTG cable with correct ID pin setup, the host won't work.

> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
> I have a Kingston stick and the sequence goes like this:
> 
> => usb reset
> resetting USB...
> USB0:   Core Release: 2.93a
> scanning bus 0 for devices...
> 
> <<< 1 minute, 41 seconds pass before >>>
> ... Device NOT ready
>Request Sense returned 00 00 00
> 
>  <<< then another  24 seconds pass before >>>
> 
> 2 USB Device(s) found
> 
> It was able to read some information about the stick:
> 
> => usb info
> :
> 2: Mass Storage,  USB Revision 2.0
> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
> - Class: (from Interface) Mass Storage
> - PacketSize: 64  Configurations: 1
> - Vendor: 0x0930  Product 0x6545 Version 1.0
>Configuration: 1
>- Interfaces: 1 Bus Powered 200mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 2
>  - Class Mass Storage, Transp. SCSI, Bulk only
>  - Endpoint 1 In Bulk MaxPacket 512
>  - Endpoint 2 Out Bulk MaxPacket 512
> 
> BUT, the stick cannot be accessed otherwise, for example:
> 
> => usb part 0
> ## Unknown partition table type 0
> 
> 
> Is there any feature of the USB stick that would indicate
> whether or not it is "compatible" with u-boot?

Can you do "dcache off" before you do "usb reset" and see if that fixes
the problem ?

> Thanks again for the calibration fix! Let me
> know if there is something else I can test!

Yeah, I CCed you on the DDR patches, so you can reply with your
Tested-By for SoCkit and Nano-SoC. Thanks

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

[U-Boot] [PATCH 10/10] ddr: altera: Repair DQ window centering code

[Marek Vasut]

The code uses a lot of signed numbers, which ended up in variables
of unsigned type, which resulted in all sorts of underflows. This
in turn caused incorrect calibration on certain boards. Moreover,
repair the readout of the DQ delay, which was being pulled from
wrong register.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index 5ea53ad..6c6bd90 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -2316,15 +2316,15 @@ static void center_dq_windows(const int write, int 
*left_edge, int *right_edge,
  const int min_index, const int test_bgn,
  int *dq_margin, int *dqs_margin)
 {
-   const u32 delay_max = write ? iocfg->io_out1_delay_max :
+   const s32 delay_max = write ? iocfg->io_out1_delay_max :
  iocfg->io_in_delay_max;
-   const u32 per_dqs = write ? rwcfg->mem_dq_per_write_dqs :
+   const s32 per_dqs = write ? rwcfg->mem_dq_per_write_dqs :
rwcfg->mem_dq_per_read_dqs;
-   const u32 delay_off = write ? SCC_MGR_IO_OUT1_DELAY_OFFSET :
+   const s32 delay_off = write ? SCC_MGR_IO_OUT1_DELAY_OFFSET :
  SCC_MGR_IO_IN_DELAY_OFFSET;
-   const u32 addr = SDR_PHYGRP_SCCGRP_ADDRESS | delay_off;
+   const s32 addr = SDR_PHYGRP_SCCGRP_ADDRESS | delay_off;
 
-   u32 temp_dq_io_delay1, temp_dq_io_delay2;
+   s32 temp_dq_io_delay1;
int shift_dq, i, p;
 
/* Initialize data for export structures */
@@ -2342,11 +2342,10 @@ static void center_dq_windows(const int write, int 
*left_edge, int *right_edge,
   "vfifo_center: before: shift_dq[%u]=%d\n",
   i, shift_dq);
 
-   temp_dq_io_delay1 = readl(addr + (p << 2));
-   temp_dq_io_delay2 = readl(addr + (i << 2));
+   temp_dq_io_delay1 = readl(addr + (i << 2));
 
if (shift_dq + temp_dq_io_delay1 > delay_max)
-   shift_dq = delay_max - temp_dq_io_delay2;
+   shift_dq = delay_max - temp_dq_io_delay1;
else if (shift_dq + temp_dq_io_delay1 < 0)
shift_dq = -temp_dq_io_delay1;
 
-- 
2.7.0

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

[U-Boot] [PATCH 05/10] ddr: altera: Remove unnecessary update of the SCC

[Marek Vasut]

Every invocation of the scc_mgr_set_dqs_en_delay_all_ranks() is
followed by SCC manager update. Moreover, only this function
triggers the SCC manager update internally. Thus, remove the
internal invocation to avoid triggering the update twice.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index 3859e66..6bf75ba 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -424,7 +424,6 @@ static void scc_mgr_set_dqs_en_delay_all_ranks(u32 
read_group,
 */
scc_mgr_set_all_ranks(SCC_MGR_DQS_EN_DELAY_OFFSET,
  read_group, delay, 1);
-   writel(0, &sdr_scc_mgr->update);
 }
 
 /**
-- 
2.7.0

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

[U-Boot] [PATCH 07/10] ddr: altera: Zero DM IN delay in scc_mgr_zero_group()

[Marek Vasut]

This one last set of delay configuration registers was not properly
zeroed out originally, fix it and zero them out.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index 254b130..0321e3b 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -303,15 +303,22 @@ static void scc_mgr_set_dqs_en_delay(u32 read_group, u32 
delay)
scc_mgr_set(SCC_MGR_DQS_EN_DELAY_OFFSET, read_group, delay);
 }
 
+static void scc_mgr_set_dq_in_delay(u32 dq_in_group, u32 delay)
+{
+   scc_mgr_set(SCC_MGR_IO_IN_DELAY_OFFSET, dq_in_group, delay);
+}
+
 static void scc_mgr_set_dqs_io_in_delay(u32 delay)
 {
scc_mgr_set(SCC_MGR_IO_IN_DELAY_OFFSET, rwcfg->mem_dq_per_write_dqs,
delay);
 }
 
-static void scc_mgr_set_dq_in_delay(u32 dq_in_group, u32 delay)
+static void scc_mgr_set_dm_in_delay(u32 dm, u32 delay)
 {
-   scc_mgr_set(SCC_MGR_IO_IN_DELAY_OFFSET, dq_in_group, delay);
+   scc_mgr_set(SCC_MGR_IO_IN_DELAY_OFFSET,
+   rwcfg->mem_dq_per_write_dqs + 1 + dm,
+   delay);
 }
 
 static void scc_mgr_set_dq_out1_delay(u32 dq_in_group, u32 delay)
@@ -584,8 +591,11 @@ static void scc_mgr_zero_group(const u32 write_group, 
const int out_only)
writel(0xff, &sdr_scc_mgr->dq_ena);
 
/* Zero all DM config settings. */
-   for (i = 0; i < RW_MGR_NUM_DM_PER_WRITE_GROUP; i++)
+   for (i = 0; i < RW_MGR_NUM_DM_PER_WRITE_GROUP; i++) {
+   if (!out_only)
+   scc_mgr_set_dm_in_delay(i, 0);
scc_mgr_set_dm_out1_delay(i, 0);
+   }
 
/* Multicast to all DM enables. */
writel(0xff, &sdr_scc_mgr->dm_ena);
-- 
2.7.0

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

[U-Boot] [PATCH 09/10] ddr: altera: Staticize global variables

[Marek Vasut]

Just staticize global variables in sequencer, since there is no
point in having these symbols available outside of the DDR code.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index c41555f..5ea53ad 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -57,7 +57,7 @@ const struct socfpga_sdram_misc_config *misccfg;
STATIC_SKIP_DELAY_LOOPS)
 
 /* calibration steps requested by the rtl */
-u16 dyn_calib_steps;
+static u16 dyn_calib_steps;
 
 /*
  * To make CALIB_SKIP_DELAY_LOOPS a dynamic conditional option
@@ -68,13 +68,13 @@ u16 dyn_calib_steps;
  * zero when skipping
  */
 
-u16 skip_delay_mask;   /* mask off bits when skipping/not-skipping */
+static u16 skip_delay_mask;/* mask off bits when skipping/not-skipping */
 
 #define SKIP_DELAY_LOOP_VALUE_OR_ZERO(non_skip_value) \
((non_skip_value) & skip_delay_mask)
 
-struct gbl_type *gbl;
-struct param_type *param;
+static struct gbl_type *gbl;
+static struct param_type *param;
 
 static void set_failing_group_stage(u32 group, u32 stage,
u32 substage)
-- 
2.7.0

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

[U-Boot] [PATCH 06/10] ddr: altera: Remove unnecessary ODT mode config

[Marek Vasut]

There is no point in resetting the ODT setting if the write test
failed, since the code will always retry the calibration and thus
reconfigure the ODT anyway OR the code will fail calibration and
halt.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index 6bf75ba..254b130 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -1207,7 +1207,6 @@ rw_mgr_mem_calibrate_write_test(const u32 rank_bgn, const 
u32 write_group,
   *bit_chk == param->write_correct_mask);
return *bit_chk == param->write_correct_mask;
} else {
-   set_rank_and_odt_mask(0, RW_MGR_ODT_MODE_OFF);
debug_cond(DLEVEL == 2,
   "write_test(%u,%u,ONE) : %u != %i => %i\n",
   write_group, use_dm, *bit_chk, 0, *bit_chk != 0);
-- 
2.7.0

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

[U-Boot] [PATCH 02/10] ddr: altera: Tweak DQS tracking enable handling

[Marek Vasut]

In the most unlikely case the DQS tracking was to be disabled,
make sure we do not errornously re-enable it. Note that DQS
tracking is enabled on all systems observed thus far.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index 34b1aa7..bf74b4e 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -3479,6 +3479,7 @@ grp_failed:   /* A group failed, increment 
the counter. */
 static int run_mem_calibrate(void)
 {
int pass;
+   u32 ctrl_cfg;
 
debug("%s:%d\n", __func__, __LINE__);
 
@@ -3486,7 +3487,9 @@ static int run_mem_calibrate(void)
writel(PHY_MGR_CAL_RESET, &phy_mgr_cfg->cal_status);
 
/* Stop tracking manager. */
-   clrbits_le32(&sdr_ctrl->ctrl_cfg, SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK);
+   ctrl_cfg = readl(&sdr_ctrl->ctrl_cfg);
+   writel(ctrl_cfg & ~SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK,
+  &sdr_ctrl->ctrl_cfg);
 
phy_mgr_initialize();
rw_mgr_mem_initialize();
@@ -3507,7 +3510,7 @@ static int run_mem_calibrate(void)
writel(0x2, &phy_mgr_cfg->mux_sel);
 
/* Start tracking manager. */
-   setbits_le32(&sdr_ctrl->ctrl_cfg, SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK);
+   writel(ctrl_cfg, &sdr_ctrl->ctrl_cfg);
 
return pass;
 }
-- 
2.7.0

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

[U-Boot] [PATCH 03/10] ddr: altera: Fix scc_mgr_set() argument order

[Marek Vasut]

The code should be setting registers to zero, not one register to value.
Swap the order of arguments to correct the behavior. The behavior is now
in-line with code generated by Quartus 15.1 .

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index bf74b4e..3859e66 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -279,7 +279,7 @@ static void scc_mgr_initialize(void)
for (i = 0; i < 16; i++) {
debug_cond(DLEVEL == 1, "%s:%d: Clearing SCC RFILE index %u\n",
   __func__, __LINE__, i);
-   scc_mgr_set(SCC_MGR_HHP_RFILE_OFFSET, 0, i);
+   scc_mgr_set(SCC_MGR_HHP_RFILE_OFFSET, i, 0);
}
 }
 
-- 
2.7.0

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

[U-Boot] [PATCH 08/10] ddr: altera: Make DLEVEL behavior inclusive

[Marek Vasut]

Originally, the DLEVEL selects the debug level within the sequencer code,
but only displays the messages on that particular debug level. Tweak the
handling such that for particular debug level, debug messages on that
level and lower are displayed. This allows better regulation of debug
message verbosity.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 132 -
 1 file changed, 66 insertions(+), 66 deletions(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index 0321e3b..c41555f 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -277,7 +277,7 @@ static void scc_mgr_initialize(void)
int i;
 
for (i = 0; i < 16; i++) {
-   debug_cond(DLEVEL == 1, "%s:%d: Clearing SCC RFILE index %u\n",
+   debug_cond(DLEVEL >= 1, "%s:%d: Clearing SCC RFILE index %u\n",
   __func__, __LINE__, i);
scc_mgr_set(SCC_MGR_HHP_RFILE_OFFSET, i, 0);
}
@@ -479,10 +479,10 @@ static void scc_mgr_set_hhp_extras(void)
 SCC_MGR_HHP_GLOBALS_OFFSET |
 SCC_MGR_HHP_EXTRAS_OFFSET;
 
-   debug_cond(DLEVEL == 1, "%s:%d Setting HHP Extras\n",
+   debug_cond(DLEVEL >= 1, "%s:%d Setting HHP Extras\n",
   __func__, __LINE__);
writel(value, addr);
-   debug_cond(DLEVEL == 1, "%s:%d Done Setting HHP Extras\n",
+   debug_cond(DLEVEL >= 1, "%s:%d Done Setting HHP Extras\n",
   __func__, __LINE__);
 }
 
@@ -693,7 +693,7 @@ static void scc_mgr_apply_group_all_out_delay_add(const u32 
write_group,
/* DQS shift */
new_delay = READ_SCC_DQS_IO_OUT2_DELAY + delay;
if (new_delay > iocfg->io_out2_delay_max) {
-   debug_cond(DLEVEL == 1,
+   debug_cond(DLEVEL >= 1,
   "%s:%d (%u, %u) DQS: %u > %d; adding %u to OUT1\n",
   __func__, __LINE__, write_group, delay, new_delay,
   iocfg->io_out2_delay_max,
@@ -707,7 +707,7 @@ static void scc_mgr_apply_group_all_out_delay_add(const u32 
write_group,
/* OCT shift */
new_delay = READ_SCC_OCT_OUT2_DELAY + delay;
if (new_delay > iocfg->io_out2_delay_max) {
-   debug_cond(DLEVEL == 1,
+   debug_cond(DLEVEL >= 1,
   "%s:%d (%u, %u) DQS: %u > %d; adding %u to OUT1\n",
   __func__, __LINE__, write_group, delay,
   new_delay, iocfg->io_out2_delay_max,
@@ -1210,14 +1210,14 @@ rw_mgr_mem_calibrate_write_test(const u32 rank_bgn, 
const u32 write_group,
 
set_rank_and_odt_mask(0, RW_MGR_ODT_MODE_OFF);
if (all_correct) {
-   debug_cond(DLEVEL == 2,
+   debug_cond(DLEVEL >= 2,
   "write_test(%u,%u,ALL) : %u == %u => %i\n",
   write_group, use_dm, *bit_chk,
   param->write_correct_mask,
   *bit_chk == param->write_correct_mask);
return *bit_chk == param->write_correct_mask;
} else {
-   debug_cond(DLEVEL == 2,
+   debug_cond(DLEVEL >= 2,
   "write_test(%u,%u,ONE) : %u != %i => %i\n",
   write_group, use_dm, *bit_chk, 0, *bit_chk != 0);
return *bit_chk != 0x00;
@@ -1292,7 +1292,7 @@ rw_mgr_mem_calibrate_read_test_patterns(const u32 
rank_bgn, const u32 group,
if (bit_chk != param->read_correct_mask)
ret = -EIO;
 
-   debug_cond(DLEVEL == 1,
+   debug_cond(DLEVEL >= 1,
   "%s:%d test_load_patterns(%u,ALL) => (%u == %u) => %i\n",
   __func__, __LINE__, group, bit_chk,
   param->read_correct_mask, ret);
@@ -1453,13 +1453,13 @@ rw_mgr_mem_calibrate_read_test(const u32 rank_bgn, 
const u32 group,
 
if (all_correct) {
ret = (*bit_chk == param->read_correct_mask);
-   debug_cond(DLEVEL == 2,
+   debug_cond(DLEVEL >= 2,
   "%s:%d read_test(%u,ALL,%u) => (%u == %u) => %i\n",
   __func__, __LINE__, group, all_groups, *bit_chk,
   param->read_correct_mask, ret);
} else  {
ret = (*bit_chk != 0x00);
-   debug_cond(DLEVEL == 2,
+   debug_cond(DLEVEL >= 2,
   "%s:%d read_test(%u,ONE,%u) => (%u != %u) => %i\n",
   __func__, __LINE__, group, all_groups, *bit_chk,
   0, ret);
@@ -1523,7 +1523,7 @@ static int find_vfifo_failing_read(const u32 grp)
u32 v, ret, fail_cnt = 0;
 
for (v = 0; v < misccfg->read_valid_fifo_size; v++) {
-   debug_cond(DLEVEL == 2, "%s:%d: vfifo %u\n",
+   deb

[U-Boot] [PATCH 04/10] ddr: altera: Fix DRAM end value in protection rule

[Marek Vasut]

The hi address bitfield in the protection rule must be set to
the last address in the region which the rule represents. The
behavior is now in-line with code generated by Quartus 15.1 .

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sdram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/altera/sdram.c b/drivers/ddr/altera/sdram.c
index 2996942..7e4606d 100644
--- a/drivers/ddr/altera/sdram.c
+++ b/drivers/ddr/altera/sdram.c
@@ -118,7 +118,7 @@ static void sdram_set_rule(struct sdram_prot_rule *prule)
 
/* Obtain the address bits */
lo_addr_bits = prule->sdram_start >> 20ULL;
-   hi_addr_bits = prule->sdram_end >> 20ULL;
+   hi_addr_bits = (prule->sdram_end - 1) >> 20ULL;
 
debug("sdram set rule start %x, %d\n", lo_addr_bits,
  prule->sdram_start);
-- 
2.7.0

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

[U-Boot] [PATCH 01/10] ddr: altera: Replace ad-hoc constant with macro

[Marek Vasut]

The bit 22 is in fact DQS tracking enable bit (dqstrken) and there
is a macro for this bit already, so use it.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
---
 drivers/ddr/altera/sequencer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index 79c265f..34b1aa7 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -3486,7 +3486,7 @@ static int run_mem_calibrate(void)
writel(PHY_MGR_CAL_RESET, &phy_mgr_cfg->cal_status);
 
/* Stop tracking manager. */
-   clrbits_le32(&sdr_ctrl->ctrl_cfg, 1 << 22);
+   clrbits_le32(&sdr_ctrl->ctrl_cfg, SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK);
 
phy_mgr_initialize();
rw_mgr_mem_initialize();
@@ -3507,7 +3507,7 @@ static int run_mem_calibrate(void)
writel(0x2, &phy_mgr_cfg->mux_sel);
 
/* Start tracking manager. */
-   setbits_le32(&sdr_ctrl->ctrl_cfg, 1 << 22);
+   setbits_le32(&sdr_ctrl->ctrl_cfg, SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK);
 
return pass;
 }
-- 
2.7.0

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 6 April 2016 at 03:43, Marek Vasut  wrote:
> On 04/06/2016 03:17 AM, George Broz wrote:
>> On 5 April 2016 at 17:45, Marek Vasut  wrote:
>>> On 04/06/2016 02:31 AM, George Broz wrote:
 On 5 April 2016 at 15:03, Marek Vasut  wrote:
> On 04/05/2016 10:33 AM, Phil Reid wrote:
>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:


 On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>
>> Sorry, I know that doesn't help. So let's walk through my workflow.
>> I am
>> not using any Altera tools when I build.
>>
>> $make socfpga_de0_nano_soc_defconfig
>> $make u-boot-with-spl.sfp
>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>
>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 
>> 4.7.3
>>
>> Has the board ever worked for you at all? Can you try this image:
>>
>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>
>>
>> Dinh
>
> I just ported U-Boot to another customer board. I noticed QSPI has
> problems and USB can be flaky. That's the standard cache issue we
> have, disabling dcache fixed that.
>
> I am starting to wonder whether we're hitting some corner case here.
> Maybe we should eventually try and trace all the register reads and
> writes generated by the DDR calibration code both in old and new SPL
> and make a diff to see if something really did change.
>
> Dinh, can you share the marking on the SoC and the DRAMs on your 
> board?
>

 My SoC is:

 5CSEMA4U23C6N
 CACAU1525A

 DRAMs are:

 ISSI 1510
 IS43TR16256A
 15HBL K080
 P4482100QER2 TWN
>>>
>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>> desk because this is creepy.
>>>
>>>
>> FYI
>>
>> I've just spend some time trying to update the spl / uboot / kernel &
>> rootfs image on our
>> Altera socdk to use for some software testing / development.
>> Unfortunately it fails in the mem calibration process with the latest
>> uboot most of the time.
>> And when it does boot somtimes fails loading uboot fomr the mmc.
>
> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>
> [1]
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr

 I downloaded a "snapshot" from the above link producing,
 u-boot-socfpga-1931be2.tar.gz

 When I try to build for sockit or de0_nano_soc I get:

  CC  drivers/mmc/mmc-uclass.o
   CC  drivers/mmc/dw_mmc.o
   CC  drivers/mmc/mmc.o
   CC  drivers/mmc/socfpga_dw_mmc.o
 drivers/mmc/socfpga_dw_mmc.c:9:28: fatal error: asm/arch/dwmmc.h: No
 such file or directory
  #include 
 ^
 compilation terminated.
 make[1]: *** [drivers/mmc/socfpga_dw_mmc.o] Error 1
 make: *** [drivers/mmc] Error 2
>>>
>>> Thanks for spotting this. Did you try the most basic of basic approaches:
>>>
>>> diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
>>> index 43a7e7e..097db81 100644
>>> --- a/drivers/mmc/socfpga_dw_mmc.c
>>> +++ b/drivers/mmc/socfpga_dw_mmc.c
>>> @@ -6,7 +6,6 @@
>>>
>>>  #include 
>>>  #include 
>>> -#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>
>>> The git tree is updated now.
>>
>> It compiles and it works!
>>
>> On sockit:
>>
>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
>> drivers/ddr/altera/sequencer.c: Calibration complete
>> Trying to boot from MMC1
>>
>> First time that an SPL built from a recent version has run successfully
>> on that board.
>>
>> Will try it out on de0 tomorrow morning...
>
> This is great news, thanks!

This patch also fixes the intermittent SDRAM calibration failures on my
de0_nano_soc board. Thanks so much!


Now with up-to-date versions of SPL and image... I have some
USB questions/news/observations:

When using an OTG cable between USB port and mass storage
device, the de0_nano_soc board is able to detect and access some USB
sticks. The detection with these is almost immediate from when 'usb start'
is entered. If the same (working) USB stick is used with a non-OTG cable,
I get the timeout messages from before:

dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!

and this is true even if I add 'dr_mode = "host" ' to the dts for usb1
of the de0
(and rebuild/reload). The older SPL/image that ships from the Terasic factory
detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
What is the correct "expected" behavior here?? Is a

Re: [U-Boot] [PATCH] fdt: implement dev_get_addr_name()

[Simon Glass]

On 6 April 2016 at 12:49, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This function parses the reg property based on an index found in the
> reg-names property. This is required for bindings that are written
> using reg-names rather than hard-coding indices in reg.
>
> Signed-off-by: Stephen Warren 
> ---
>  drivers/core/device.c | 16 
>  include/dm/device.h   | 12 
>  2 files changed, 28 insertions(+)

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

Re: [U-Boot] [PATCH 00/10] driver model bring-up of dwc3 usb peripheral

[Simon Glass]

Hi,

On 31 March 2016 at 09:24, Marek Vasut  wrote:
> On 03/31/2016 05:11 PM, Tom Rini wrote:
>> On Thu, Mar 31, 2016 at 04:10:49PM +0200, Michal Simek wrote:
>>> Hi Tom,
>>>
>>> On 15.3.2016 13:14, Mugunthan V N wrote:
 This patch series enables dwc3 usb driver to adopt driver model.
 This has been tested on AM437x evm sk (logs [1]) by loading
 kernel through usb ether

 Also pushed a branch for testing [2]

 [1] - http://pastebin.ubuntu.com/15391169/
 [2] - git://git.ti.com/~mugunthanvnm/ti-u-boot/mugunth-ti-u-boot.git 
 dm-dwc3

 Kishon Vijay Abraham I (1):
   configs: am43xx: Add am43xx_evm_usbspl_defconfig

 Mugunthan V N (8):
   drivers: usb: dwc3: remove devm_zalloc from linux_compact
   drivers: usb: dwc3-omap: move usb_gadget_handle_interrupts from board
 files to drivers
   am437x: board: do not register usb devices when CONFIG_DM_USB is
 defined
   dra7xx: board: do not register usb devices when CONFIG_DM_USB is
 defined
   drivers: usb: dwc3: add ti dwc3 misc driver for wrapper
   drivers: usb: common: add support to get maximum speed from dt
   drivers: usb: dwc3: add ti dwc3 peripheral driver with driver model
 support
   defconfig: am437x_sk_evm: enable usb driver model

 Tom Rini (1):
   am43xx: Add USB device boot support to SPL

  board/ti/am43xx/MAINTAINERS |   1 +
  board/ti/am43xx/board.c |  52 +---
  board/ti/am57xx/board.c |  11 --
  board/ti/dra7xx/evm.c   |  13 +-
  configs/am437x_sk_evm_defconfig |   4 +
  configs/am43xx_evm_usbspl_defconfig |   9 ++
  drivers/Makefile|   2 +
  drivers/usb/common/common.c |  29 +
  drivers/usb/dwc3/core.c |  64 +-
  drivers/usb/dwc3/core.h |   6 +
  drivers/usb/dwc3/dwc3-omap.c| 230 
 +++-
  drivers/usb/dwc3/gadget.c   |   2 +-
  drivers/usb/dwc3/linux-compat.h |   5 -
  drivers/usb/dwc3/ti_usb_phy.c   |   1 +
  drivers/usb/gadget/gadget_chips.h   |   2 +
  include/configs/am43xx_evm.h|  13 ++
  include/linux/usb/otg.h |   9 ++
  17 files changed, 406 insertions(+), 47 deletions(-)
  create mode 100644 configs/am43xx_evm_usbspl_defconfig

>>>
>>> Are you going to take this directly or this should go via USB tree?
>>
>> Marek, do you want this?  Or want me to?
>>
> That is Lukasz.

This series has ended up in my patchwork queue, but there seem to be
quite a few unapplied, dependent patches. Tom please let me know what
you'd like me to do here.

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

Re: [U-Boot] [PATCH v2] fastboot: OUT transaction length must be aligned to wMaxPacketSize

[Marek Vasut]

On 04/06/2016 10:45 PM, Steve Rae wrote:
> Thanks for the reply, Marek
> 
> On Wed, Apr 6, 2016 at 12:53 PM, Marek Vasut  > wrote:
> 
> On 04/06/2016 07:18 PM, Steve Rae wrote:
> > No -- I do not believe that this issue is caused by different fastboot
> > (client) versions (the executable that runs on the host computer -
> > Linux, Windows, Mac, etc.)
> > I have personally attempted three (3) different versions, and the
> > results are consistent.
> 
> OK
> 
> > And no I don't think that I "am the only hope at fixing this proper"
> > -- as you will see below,
> > this" issue" seems to be unique to the "TI platforms" (... nobody else
> > has stated they have an issue either way -- but I don't think many use
> > this feature )
> > So maybe someone with "TI platforms" could investigate this more 
> thoroughly...
> 
> TI platforms use musb USB/OTG controller, could the issue them be
> specific to MUSB ?
> 
> 
> maybe -- I do not know

Anyone with MUSB in Gadget mode who can test this ? I think some sunxi
had MUSB.

> > HISTORY:
> >
> > The U-Boot code, up to Feb 25, worked properly on my Broadcom boards
> > -- this code contains:
> >req->length = rx_bytes_expected();
> > if (req->length < ep->maxpacket)
> > req->length = ep->maxpacket;
> > which aligned the remaining "rx_bytes_expected" to be aligned to the
> > "ep->maxpacket" size.
> >
> > On Feb 25, there was a patch applied from  >
> > which forces the remaining "rx_bytes_expected" to be aligned to the
> > "wMaxPacketSize" size -- this patch broke all Broadcom boards:
> > +   if (rx_remain < maxpacket) {
> > +   rx_remain = maxpacket;
> > +   } else if (rx_remain % maxpacket != 0) {
> > +   rem = rx_remain % maxpacket;
> > +   rx_remain = rx_remain + (maxpacket - rem);
> > +   }
> >
> > After attempting to unsuccessfully contact Dileep, I requested that
> > this patch be reverted -- because it broke my boards! (see the other
> > email thread).
> >
> > Sam Protsenko  > has stated that this Feb 25
> > change is required to make "fastboot work on TI platforms".
> >
> > Thus,
> > - Broadcom boards require alignment to "ep->maxpacket" size
> > - TI platforms require alignment to "wMaxPacketSize" size
> > And we seem to be at a stale-mate.
> > Unfortunately, I do not know enough about the USB internals to
> > understand why this change breaks the Broadcom boards; or why it _is_
> > required on the TI platforms
> > ( Is there any debugging that can be turned on to validate what is
> > happening at the lower levels? )
> > ( Can anyone explain why "wMaxPacketSize" size would be required? --
> > my limited understanding of endpoints makes me think that
> > "ep->maxpacket" size is actually the correct value! )
> 
> 
> USB experts (Lukasz?): any ideas here 

I think Lukasz only uses UMS and Thor.

> >
> > I asked Sam to submit a patch which conditionally applied the
> > alignment to "wMaxPacketSize" size change -- he stated that he was too
> > busy right now -- so I submitted this patch on his behalf (although he
> > still needs to add the Kconfig for the TI platforms in order to make
> > his boards work)
> 
> OK, so, either way this is broken for some platforms and noone is
> interested enough to cooperate and fix this properly, yes ?
> 
> 
> yes -- that is my impression .

Bad.

> > I suppose I could also propose a patch where the condition _removes_
> > this feature (and define it on the Broadcom boards)  -- do we
> > generally like "negated" conditionals?
> > +#ifndef 
> CONFIG_USB_GADGET_FASTBOOT_DOWNLOAD_DISABLE_ALIGNMENT_WITH_WMAXPACKETSIZE
> > Please advise!
> 
> Definitely not, I will not have a new macro added just to paper over
> some problem which noone bothered to research and fix properly, sorry.
> 
> 
> OK -- I am fine with that
>  
> 
> > Further, how does the U-Boot community respond to a change which
> > breaks something which is already working? Doesn't the "author" of
> > that change bear any responsibility on assisting to get "their" change
> > working properly with "all" the existing boards? I'm getting the
> > impression that "because the current code works for me", that I am not
> > getting any assistance in resolving this issue -- which is why I
> > suggested "reverting" this change back to the original code; that way,
> > it would (politely?) force someone interested in "TI platforms" to
> > step up and look into this
> 
> I will pass this question onto Tom ;-)
> 
> 
> Tom -- thanks in advance!
>  
> 

Re: [U-Boot] [PATCH v3 1/1] mpc85xx: Enable pre-relocation malloc for MPC85xx

[York Sun]

On 04/05/2016 06:06 AM, Mario Six wrote:
> To enable DM on MPC85xx, we need pre-relocation malloc, which is
> implemented in this patch.
> 
> We also make sure that the IVORs are always 4-aligned on e500 to prevent
> alignment exceptions caused by code changes in start.S.
> 
> Signed-off-by: Mario Six 
> Cc: York Sun 
> Cc: Simon Glass 
> ---
> 
> v3:
>  - Add comment regarding gd zeroing
>  - Unconditionally zero out initial RAM during startup
> 
> v2:
>  - Correct IVOR alignment and remove nop hack
>  - Add sanity check for length of malloc area
> 
> 
>  arch/powerpc/cpu/mpc85xx/cpu_init_early.c |  8 +---
>  arch/powerpc/cpu/mpc85xx/start.S  | 30 ++
>  include/ppc_asm.tmpl  |  3 +++
>  3 files changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c 
> b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> index 235a635..85b4112 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> @@ -82,7 +82,6 @@ void setup_ifc(void)
>  void cpu_init_early_f(void *fdt)
>  {
>   u32 mas0, mas1, mas2, mas3, mas7;
> - int i;

This causes a problem. Variable "i" is still used at line 158.
I can fix it unless you want to respin the patch.

York

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/06/2016 05:04 PM, Phil Reid wrote:
> On 6/04/2016 7:51 PM, Marek Vasut wrote:
>> On 04/06/2016 09:00 AM, Phil Reid wrote:
>>> On 6/04/2016 6:03 AM, Marek Vasut wrote:
 On 04/05/2016 10:33 AM, Phil Reid wrote:
> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>
> Sorry, I know that doesn't help. So let's walk through my
> workflow.
> I am
> not using any Altera tools when I build.
>
> $make socfpga_de0_nano_soc_defconfig
> $make u-boot-with-spl.sfp
> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>
> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1)
> 4.7.3
>
> Has the board ever worked for you at all? Can you try this image:
>
> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>
>
>
>
> Dinh

 I just ported U-Boot to another customer board. I noticed QSPI has
 problems and USB can be flaky. That's the standard cache issue we
 have, disabling dcache fixed that.

 I am starting to wonder whether we're hitting some corner case
 here.
 Maybe we should eventually try and trace all the register reads and
 writes generated by the DDR calibration code both in old and new
 SPL
 and make a diff to see if something really did change.

 Dinh, can you share the marking on the SoC and the DRAMs on your
 board?

>>>
>>> My SoC is:
>>>
>>> 5CSEMA4U23C6N
>>> CACAU1525A
>>>
>>> DRAMs are:
>>>
>>> ISSI 1510
>>> IS43TR16256A
>>> 15HBL K080
>>> P4482100QER2 TWN
>>
>> Thanks, that's indeed rev. C . About time I bang my head against the
>> desk because this is creepy.
>>
>>
> FYI
>
> I've just spend some time trying to update the spl / uboot / kernel &
> rootfs image on our
> Altera socdk to use for some software testing / development.
> Unfortunately it fails in the mem calibration process with the latest
> uboot most of the time.
> And when it does boot somtimes fails loading uboot fomr the mmc.

 Try this u-boot-socfpga/ddr branch [1] , see if it works for you.

 [1]
 http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr



>>>
>>> Spent a bit of time on it and things are very weird. So far no luck
>>> booting with the ddr branch.
>>> I got the memory calibration to pass but then had problems with loading
>>> uboot. Using the mmc.
>>> Say no device found for the mmc. error -19.
>>
>> Which board is this ? How wide is the MMC data bus ?
>>
>>> When I try to add some extra debug in things fall over.
>>> Sometimes just hangs in the Memory cal (and not changing anything
>>> there).
>>> Then sometimes I get missing DTB.
>>> I found the uboot-with-spl.sfp file generated by the latest uboot tree
>>> and tried burning that with
>>> same results.
>>>
>>> Reverted back to the image available on rocketboards and wrote that to
>>> the card.
>>> Thinking something strange with the card (thou I tried several) and that
>>> works fine.
>>> Sourced from
>>> https://rocketboards.org/foswiki/view/Documentation/AlteraSoCDevelopmentBoard
>>>
>>
>> Are you actually using the SoCDK or some custom board ?
>>
> I've got two boards here.
> The Altera Cyclone V SoC FPGA Development Kit Board RevC
> which is the SocDK right?

Yes, that's the SoCDK.

Can you confirm to me whether or not the SoCDK boots reliably in the
default configuration provided with u-boot-socfpga/ddr branch, with DRAM
calibration always passing?

If the MMC fails, can you show me how do you test the MMC ?

I will try the SOCDK later, once I have some time. Boot/output log would
really help too.

> And our own board design.
>
> Our design works fine with new uboot's.
> Just can't get things to work with the dek kit.
> It's fairly similar to the SocDK
> 
> I'm building two different version of uboot.
> Using the two different qts generated files.
> I've setup a separate defconfig / dts and board config for our board.
> 
> I'd really like to find the quartus project that was used to generate
> the qts files committed into the uboot tree. All the ones I've used so
> far have different ddr timing and pin configs!

It's most likely generated from GHRD 15.0 or 15.1 , the result should be
the same either way.

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

[U-Boot] [PATCH] powerpc: Replace CONFIG_SYS_INIT_RAM_END with CONFIG_SYS_INIT_RAM_SIZE

[York Sun]

CONFIG_SYS_INIT_RAM_SIZE may be used out of the board header file.
Some boards use CONFIG_SYS_INIT_RAM_END for the same purpose. To
unify the macros, use CONFIG_SYS_INIT_RAM_SIZE for all.

Signed-off-by: York Sun 
CC: Mario Six 

---

 include/configs/BSC9131RDB.h   |4 ++--
 include/configs/BSC9132QDS.h   |4 ++--
 include/configs/C29XPCIE.h |4 ++--
 include/configs/P1010RDB.h |4 ++--
 include/configs/a3m071.h   |4 ++--
 include/configs/ac14xx.h   |4 ++--
 include/configs/dlvision-10g.h |4 ++--
 include/configs/io.h   |4 ++--
 include/configs/iocon.h|4 ++--
 include/configs/o2dnt-common.h |6 +++---
 10 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/include/configs/BSC9131RDB.h b/include/configs/BSC9131RDB.h
index 9c32a01..e870ffe 100644
--- a/include/configs/BSC9131RDB.h
+++ b/include/configs/BSC9131RDB.h
@@ -215,9 +215,9 @@ extern unsigned long get_sdram_size(void);
 
 #define CONFIG_SYS_INIT_RAM_LOCK
 #define CONFIG_SYS_INIT_RAM_ADDR   0xffd0  /* stack in RAM */
-#define CONFIG_SYS_INIT_RAM_END0x4000/* End of used area 
in RAM */
+#define CONFIG_SYS_INIT_RAM_SIZE   0x4000/* End of used area in RAM */
 
-#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END \
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE \
- GENERATED_GBL_DATA_SIZE)
 #define CONFIG_SYS_INIT_SP_OFFSET  CONFIG_SYS_GBL_DATA_OFFSET
 
diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h
index 9f7ceb8..108e924 100644
--- a/include/configs/BSC9132QDS.h
+++ b/include/configs/BSC9132QDS.h
@@ -396,9 +396,9 @@ combinations. this should be removed later
 
 #define CONFIG_SYS_INIT_RAM_LOCK
 #define CONFIG_SYS_INIT_RAM_ADDR   0xffd0  /* stack in RAM */
-#define CONFIG_SYS_INIT_RAM_END0x4000 /* End of used area 
in RAM */
+#define CONFIG_SYS_INIT_RAM_SIZE   0x4000 /* End of used area in RAM */
 
-#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END \
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE \
- GENERATED_GBL_DATA_SIZE)
 #define CONFIG_SYS_INIT_SP_OFFSET  CONFIG_SYS_GBL_DATA_OFFSET
 
diff --git a/include/configs/C29XPCIE.h b/include/configs/C29XPCIE.h
index 4cbc9ad..a7a5e8e 100644
--- a/include/configs/C29XPCIE.h
+++ b/include/configs/C29XPCIE.h
@@ -329,9 +329,9 @@
 
 #define CONFIG_SYS_INIT_RAM_LOCK
 #define CONFIG_SYS_INIT_RAM_ADDR   0xffd0
-#define CONFIG_SYS_INIT_RAM_END0x4000
+#define CONFIG_SYS_INIT_RAM_SIZE   0x4000
 
-#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END \
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE \
- GENERATED_GBL_DATA_SIZE)
 #define CONFIG_SYS_INIT_SP_OFFSET  CONFIG_SYS_GBL_DATA_OFFSET
 
diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index 81af871..249e11b 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -555,9 +555,9 @@ extern unsigned long get_sdram_size(void);
 
 #define CONFIG_SYS_INIT_RAM_LOCK
 #define CONFIG_SYS_INIT_RAM_ADDR   0xffd0 /* stack in RAM */
-#define CONFIG_SYS_INIT_RAM_END0x4000 /* End of used area 
in RAM */
+#define CONFIG_SYS_INIT_RAM_SIZE   0x4000 /* End of used area in RAM */
 
-#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END \
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE \
- GENERATED_GBL_DATA_SIZE)
 #define CONFIG_SYS_INIT_SP_OFFSET  CONFIG_SYS_GBL_DATA_OFFSET
 
diff --git a/include/configs/a3m071.h b/include/configs/a3m071.h
index cf931a6..31348da 100644
--- a/include/configs/a3m071.h
+++ b/include/configs/a3m071.h
@@ -141,9 +141,9 @@
 
 /* Use SRAM until RAM will be available */
 #define CONFIG_SYS_INIT_RAM_ADDR   MPC5XXX_SRAM
-#define CONFIG_SYS_INIT_RAM_ENDMPC5XXX_SRAM_SIZE
+#define CONFIG_SYS_INIT_RAM_SIZE   MPC5XXX_SRAM_SIZE
 
-#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END - \
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - \
 GENERATED_GBL_DATA_SIZE)
 #define CONFIG_SYS_INIT_SP_OFFSET  CONFIG_SYS_GBL_DATA_OFFSET
 
diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index 750d8ff..57421c6 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -289,9 +289,9 @@
 
 /* Use SRAM for initial stack */
 #define CONFIG_SYS_INIT_RAM_ADDR   CONFIG_SYS_SRAM_BASE
-#define CONFIG_SYS_INIT_RAM_ENDCONFIG_SYS_SRAM_SIZE
+#define CONFIG_SYS_INIT_RAM_SIZE   CONFIG_SYS_SRAM_SIZE
 
-#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END - \
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - \
  

Re: [U-Boot] [PATCH v2] fastboot: OUT transaction length must be aligned to wMaxPacketSize

[Steve Rae]

Thanks for the reply, Marek

On Wed, Apr 6, 2016 at 12:53 PM, Marek Vasut  wrote:

> On 04/06/2016 07:18 PM, Steve Rae wrote:
> > No -- I do not believe that this issue is caused by different fastboot
> > (client) versions (the executable that runs on the host computer -
> > Linux, Windows, Mac, etc.)
> > I have personally attempted three (3) different versions, and the
> > results are consistent.
>
> OK
>
> > And no I don't think that I "am the only hope at fixing this proper"
> > -- as you will see below,
> > this" issue" seems to be unique to the "TI platforms" (... nobody else
> > has stated they have an issue either way -- but I don't think many use
> > this feature )
> > So maybe someone with "TI platforms" could investigate this more
> thoroughly...
>
> TI platforms use musb USB/OTG controller, could the issue them be
> specific to MUSB ?
>

maybe -- I do not know


>
> > HISTORY:
> >
> > The U-Boot code, up to Feb 25, worked properly on my Broadcom boards
> > -- this code contains:
> >req->length = rx_bytes_expected();
> > if (req->length < ep->maxpacket)
> > req->length = ep->maxpacket;
> > which aligned the remaining "rx_bytes_expected" to be aligned to the
> > "ep->maxpacket" size.
> >
> > On Feb 25, there was a patch applied from 
> > which forces the remaining "rx_bytes_expected" to be aligned to the
> > "wMaxPacketSize" size -- this patch broke all Broadcom boards:
> > +   if (rx_remain < maxpacket) {
> > +   rx_remain = maxpacket;
> > +   } else if (rx_remain % maxpacket != 0) {
> > +   rem = rx_remain % maxpacket;
> > +   rx_remain = rx_remain + (maxpacket - rem);
> > +   }
> >
> > After attempting to unsuccessfully contact Dileep, I requested that
> > this patch be reverted -- because it broke my boards! (see the other
> > email thread).
> >
> > Sam Protsenko  has stated that this Feb 25
> > change is required to make "fastboot work on TI platforms".
> >
> > Thus,
> > - Broadcom boards require alignment to "ep->maxpacket" size
> > - TI platforms require alignment to "wMaxPacketSize" size
> > And we seem to be at a stale-mate.
> > Unfortunately, I do not know enough about the USB internals to
> > understand why this change breaks the Broadcom boards; or why it _is_
> > required on the TI platforms
> > ( Is there any debugging that can be turned on to validate what is
> > happening at the lower levels? )
> > ( Can anyone explain why "wMaxPacketSize" size would be required? --
> > my limited understanding of endpoints makes me think that
> > "ep->maxpacket" size is actually the correct value! )
>

USB experts (Lukasz?): any ideas here

>
> > I asked Sam to submit a patch which conditionally applied the
> > alignment to "wMaxPacketSize" size change -- he stated that he was too
> > busy right now -- so I submitted this patch on his behalf (although he
> > still needs to add the Kconfig for the TI platforms in order to make
> > his boards work)
>
> OK, so, either way this is broken for some platforms and noone is
> interested enough to cooperate and fix this properly, yes ?
>

yes -- that is my impression .


>
> > I suppose I could also propose a patch where the condition _removes_
> > this feature (and define it on the Broadcom boards)  -- do we
> > generally like "negated" conditionals?
> > +#ifndef
> CONFIG_USB_GADGET_FASTBOOT_DOWNLOAD_DISABLE_ALIGNMENT_WITH_WMAXPACKETSIZE
> > Please advise!
>
> Definitely not, I will not have a new macro added just to paper over
> some problem which noone bothered to research and fix properly, sorry.
>
>
OK -- I am fine with that


> > Further, how does the U-Boot community respond to a change which
> > breaks something which is already working? Doesn't the "author" of
> > that change bear any responsibility on assisting to get "their" change
> > working properly with "all" the existing boards? I'm getting the
> > impression that "because the current code works for me", that I am not
> > getting any assistance in resolving this issue -- which is why I
> > suggested "reverting" this change back to the original code; that way,
> > it would (politely?) force someone interested in "TI platforms" to
> > step up and look into this
>
> I will pass this question onto Tom ;-)
>

Tom -- thanks in advance!


>
> > Sorry for asking so many questions in one email -- but I'd appreciate
> > answers
> > ( I also apologize in advance for the "attitude" which is leaking into
> > this email... )
> > Please tell me what I can do! I had working boards; now they are all
> > broken -- and I don't how how to get them working again
>
> Kick the TI person into the backside until he comes up with a proper
> solution. Be annoying. Or, if that leads nowhere, I will just apply
> the revert and break it for TI and expect them to fix it proper.
>
> btw. note that ELC is going on this week, so replies might be delayed.
>

OK -- I am happy to be

Re: [U-Boot] [PATCH v3 1/1] mpc85xx: Enable pre-relocation malloc for MPC85xx

[York Sun]

On 04/05/2016 06:06 AM, Mario Six wrote:
> To enable DM on MPC85xx, we need pre-relocation malloc, which is
> implemented in this patch.
> 
> We also make sure that the IVORs are always 4-aligned on e500 to prevent
> alignment exceptions caused by code changes in start.S.
> 
> Signed-off-by: Mario Six 
> Cc: York Sun 
> Cc: Simon Glass 
> ---
> 
> v3:
>  - Add comment regarding gd zeroing
>  - Unconditionally zero out initial RAM during startup
> 
> v2:
>  - Correct IVOR alignment and remove nop hack
>  - Add sanity check for length of malloc area
> 
> 
>  arch/powerpc/cpu/mpc85xx/cpu_init_early.c |  8 +---
>  arch/powerpc/cpu/mpc85xx/start.S  | 30 ++
>  include/ppc_asm.tmpl  |  3 +++
>  3 files changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c 
> b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> index 235a635..85b4112 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> @@ -82,7 +82,6 @@ void setup_ifc(void)
>  void cpu_init_early_f(void *fdt)
>  {
>   u32 mas0, mas1, mas2, mas3, mas7;
> - int i;
>  #ifdef CONFIG_SYS_FSL_ERRATUM_P1010_A003549
>   ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
>  #endif
> @@ -95,12 +94,7 @@ void cpu_init_early_f(void *fdt)
>   /* Pointer is writable since we allocated a register for it */
>   gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
> 
> - /*
> -  * Clear initial global data
> -  *   we don't use memset so we can share this code with NAND_SPL
> -  */
> - for (i = 0; i < sizeof(gd_t); i++)
> - ((char *)gd)[i] = 0;
> + /* gd area was zeroed during startup */
> 
>  #ifdef CONFIG_QEMU_E500
>   /*
> diff --git a/arch/powerpc/cpu/mpc85xx/start.S 
> b/arch/powerpc/cpu/mpc85xx/start.S
> index d867e2a..82a151a 100644
> --- a/arch/powerpc/cpu/mpc85xx/start.S
> +++ b/arch/powerpc/cpu/mpc85xx/start.S
> @@ -1152,6 +1152,36 @@ _start_cont:
>   /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
>   lis r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>   ori r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
> +
> +#ifdef CONFIG_SYS_MALLOC_F_LEN
> +
> +#if CONFIG_SYS_MALLOC_F_LEN + GENERATED_GBL_DATA_SIZE > 
> CONFIG_SYS_INIT_RAM_SIZE
> +#error "CONFIG_SYS_MALLOC_F_LEN too large to fit into initial RAM."
> +#endif
> +
> + /* Leave 16+ byte for back chain termination and NULL return address */
> + subir3,r3,((CONFIG_SYS_MALLOC_F_LEN+16+15)&~0xf)
> +#endif
> +
> + /* End of RAM */
> + lis r4,(CONFIG_SYS_INIT_RAM_ADDR)@h
> + ori r4,r4,(CONFIG_SYS_INIT_RAM_SIZE)@l
> +

CONFIG_SYS_INIT_RAM_SIZE is not defined for some platforms, for example
P1010RDB, C29XPCIE, BSC9132QDS. I will send out a patch to fix.

York


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

Re: [U-Boot] [PATCH v2 1/2] kconfig: Move CONFIG_OF_LIBFDT to Kconfig

[Ricardo Ribalda Delgado]

Hi Michal

xilinx-ppc405-generic and xilinx-ppc440-generic also depend on
xilinx-ppc.h So I think this is missing.

Shall I send this as a separated patch? or you want to include it in yours?


Regards


ricardo@pilix:~/curro/u-boot$ git diff
diff --git a/configs/xilinx-ppc405-generic_defconfig
b/configs/xilinx-ppc405-generic_defconfig
index 2008a8d79394..381b668bb9e4 100644
--- a/configs/xilinx-ppc405-generic_defconfig
+++ b/configs/xilinx-ppc405-generic_defconfig
@@ -13,3 +13,5 @@ CONFIG_SYS_PROMPT="xlx-ppc405:/# "
 CONFIG_OF_EMBED=y
 CONFIG_SYS_NS16550=y
 CONFIG_XILINX_UARTLITE=y
+CONFIG_OF_LIBFDT=y
+# CONFIG_EFI_LOADER is not set
diff --git a/configs/xilinx-ppc440-generic_defconfig
b/configs/xilinx-ppc440-generic_defconfig
index 8df33d3270d1..9fe518a83dc3 100644
--- a/configs/xilinx-ppc440-generic_defconfig
+++ b/configs/xilinx-ppc440-generic_defconfig
@@ -13,3 +13,5 @@ CONFIG_OF_EMBED=y
 CONFIG_NETCONSOLE=y
 CONFIG_SYS_NS16550=y
 CONFIG_XILINX_UARTLITE=y
+CONFIG_OF_LIBFDT=y
+# CONFIG_EFI_LOADER is not set

On Wed, Apr 6, 2016 at 8:28 PM, Michal Simek  wrote:
> This patch follows work done by:
> "Move CONFIG_OF_LIBFDT to Kconfig"
> (sha1: 69e173eb57d1f4848f070c83456096ba5d2ba1b4)
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v2:
> - new patch in series. Masahiro asked for it.
>
>  configs/legoev3_defconfig | 2 ++
>  configs/ma5d4evk_defconfig| 2 ++
>  configs/stm32f746-disco_defconfig | 2 ++
>  configs/zipitz2_defconfig | 4 +++-
>  include/configs/legoev3.h | 1 -
>  include/configs/ma5d4evk.h| 1 -
>  include/configs/pic32mzdask.h | 5 -
>  include/configs/stm32f746-disco.h | 1 -
>  include/configs/xilinx-ppc.h  | 1 -
>  include/configs/zipitz2.h | 1 -
>  10 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/configs/legoev3_defconfig b/configs/legoev3_defconfig
> index d838baa32cbb..22fd0578ef72 100644
> --- a/configs/legoev3_defconfig
> +++ b/configs/legoev3_defconfig
> @@ -10,3 +10,5 @@ CONFIG_AUTOBOOT_STOP_STR="l"
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_SYS_NS16550=y
> +CONFIG_OF_LIBFDT=y
> +# CONFIG_EFI_LOADER is not set
> diff --git a/configs/ma5d4evk_defconfig b/configs/ma5d4evk_defconfig
> index 39ce550ff44f..144851426937 100644
> --- a/configs/ma5d4evk_defconfig
> +++ b/configs/ma5d4evk_defconfig
> @@ -12,3 +12,5 @@ CONFIG_SYS_EXTRA_OPTIONS="SAMA5D4"
>  CONFIG_SPI_FLASH=y
>  CONFIG_USB=y
>  CONFIG_USB_GADGET=y
> +CONFIG_OF_LIBFDT=y
> +# CONFIG_EFI_LOADER is not set
> diff --git a/configs/stm32f746-disco_defconfig 
> b/configs/stm32f746-disco_defconfig
> index 7cfed4a514bf..07aa874760c2 100644
> --- a/configs/stm32f746-disco_defconfig
> +++ b/configs/stm32f746-disco_defconfig
> @@ -7,3 +7,5 @@ CONFIG_AUTOBOOT_KEYED=y
>  CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n"
>  CONFIG_AUTOBOOT_STOP_STR=" "
>  # CONFIG_CMD_SETEXPR is not set
> +CONFIG_OF_LIBFDT=y
> +# CONFIG_EFI_LOADER is not set
> diff --git a/configs/zipitz2_defconfig b/configs/zipitz2_defconfig
> index 2977ccc8ddee..d2fa63d15f08 100644
> --- a/configs/zipitz2_defconfig
> +++ b/configs/zipitz2_defconfig
> @@ -1,7 +1,9 @@
>  CONFIG_ARM=y
>  CONFIG_TARGET_ZIPITZ2=y
> +CONFIG_SYS_PROMPT="$ "
>  # CONFIG_CMD_IMLS is not set
>  # CONFIG_CMD_SETEXPR is not set
>  # CONFIG_CMD_NET is not set
>  # CONFIG_CMD_NFS is not set
> -CONFIG_SYS_PROMPT="$ "
> +CONFIG_OF_LIBFDT=y
> +# CONFIG_EFI_LOADER is not set
> diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
> index 79fa3c476ad1..0bc9d2dc18b4 100644
> --- a/include/configs/legoev3.h
> +++ b/include/configs/legoev3.h
> @@ -160,7 +160,6 @@
>  #define CONFIG_SYS_LONGHELP
>  #define CONFIG_CRC32_VERIFY
>  #define CONFIG_MX_CYCLIC
> -#define CONFIG_OF_LIBFDT
>
>  /*
>   * Linux Information
> diff --git a/include/configs/ma5d4evk.h b/include/configs/ma5d4evk.h
> index e061a101aee6..8a80b954a68d 100644
> --- a/include/configs/ma5d4evk.h
> +++ b/include/configs/ma5d4evk.h
> @@ -150,7 +150,6 @@
>  #define CONFIG_LOADADDR0x2080
>  #define CONFIG_BOOTCOMMAND "run mmc_mmc"
>  #define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
> -#define CONFIG_OF_LIBFDT
>
>  /*
>   * Extra Environments
> diff --git a/include/configs/pic32mzdask.h b/include/configs/pic32mzdask.h
> index 3ea11946b8ab..fd874c42a2bc 100644
> --- a/include/configs/pic32mzdask.h
> +++ b/include/configs/pic32mzdask.h
> @@ -92,11 +92,6 @@
>  #define CONFIG_BOOTP_GATEWAY
>  #define CONFIG_BOOTP_HOSTNAME
>
> -/*
> - * Handover flattened device tree (dtb file) to Linux kernel
> - */
> -#define CONFIG_OF_LIBFDT   1
> -
>  /*---
>   * SDHC Configuration
>   */
> diff --git a/include/configs/stm32f746-disco.h 
> b/include/configs/stm32f746-disco.h
> index 807ab6574eb5..e94812bf5a78 100644
> --- a/include/configs/stm32f746-disco.h
> +++ b/include/configs/stm32f746-disco.h
> @@ -11,7 +11,6 @@
>  #define CONFIG_SYS_THUMB_BUILD
>  /

Re: [U-Boot] FPGA detection failure on Cyclone V soc development kit

[Marek Vasut]

On 04/06/2016 07:16 PM, Måns Rullgård wrote:
> Marek Vasut  writes:
> 
>> On 04/06/2016 05:29 PM, Dinh Nguyen wrote:
>>> On Wed, Apr 6, 2016 at 10:07 AM, Marek Vasut  wrote:

 I pushed some DDR fixes into u-boot-socfpga/ddr branch [1], which fixed
 DDR calibration issue on a board I have in here. Can you try them ? Thanks

 [1]
 http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr

>>>
>>> I'll do it first thing when I get back from ELC.
>>
>> Cool. I will do proper submission by then. I think Mans had a CV SoCDK
>> which didn't boot with the mainline SPL, so it'd be cool if he could try.
> 
> I will when I get back from ELC.
> 
Thanks

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

Re: [U-Boot] [PATCH v2] fastboot: OUT transaction length must be aligned to wMaxPacketSize

[Marek Vasut]

On 04/06/2016 07:18 PM, Steve Rae wrote:
> No -- I do not believe that this issue is caused by different fastboot
> (client) versions (the executable that runs on the host computer -
> Linux, Windows, Mac, etc.)
> I have personally attempted three (3) different versions, and the
> results are consistent.

OK

> And no I don't think that I "am the only hope at fixing this proper"
> -- as you will see below,
> this" issue" seems to be unique to the "TI platforms" (... nobody else
> has stated they have an issue either way -- but I don't think many use
> this feature )
> So maybe someone with "TI platforms" could investigate this more thoroughly...

TI platforms use musb USB/OTG controller, could the issue them be
specific to MUSB ?

> HISTORY:
> 
> The U-Boot code, up to Feb 25, worked properly on my Broadcom boards
> -- this code contains:
>req->length = rx_bytes_expected();
> if (req->length < ep->maxpacket)
> req->length = ep->maxpacket;
> which aligned the remaining "rx_bytes_expected" to be aligned to the
> "ep->maxpacket" size.
> 
> On Feb 25, there was a patch applied from 
> which forces the remaining "rx_bytes_expected" to be aligned to the
> "wMaxPacketSize" size -- this patch broke all Broadcom boards:
> +   if (rx_remain < maxpacket) {
> +   rx_remain = maxpacket;
> +   } else if (rx_remain % maxpacket != 0) {
> +   rem = rx_remain % maxpacket;
> +   rx_remain = rx_remain + (maxpacket - rem);
> +   }
> 
> After attempting to unsuccessfully contact Dileep, I requested that
> this patch be reverted -- because it broke my boards! (see the other
> email thread).
> 
> Sam Protsenko  has stated that this Feb 25
> change is required to make "fastboot work on TI platforms".
> 
> Thus,
> - Broadcom boards require alignment to "ep->maxpacket" size
> - TI platforms require alignment to "wMaxPacketSize" size
> And we seem to be at a stale-mate.
> Unfortunately, I do not know enough about the USB internals to
> understand why this change breaks the Broadcom boards; or why it _is_
> required on the TI platforms
> ( Is there any debugging that can be turned on to validate what is
> happening at the lower levels? )
> ( Can anyone explain why "wMaxPacketSize" size would be required? --
> my limited understanding of endpoints makes me think that
> "ep->maxpacket" size is actually the correct value! )
> 
> I asked Sam to submit a patch which conditionally applied the
> alignment to "wMaxPacketSize" size change -- he stated that he was too
> busy right now -- so I submitted this patch on his behalf (although he
> still needs to add the Kconfig for the TI platforms in order to make
> his boards work)

OK, so, either way this is broken for some platforms and noone is
interested enough to cooperate and fix this properly, yes ?

> I suppose I could also propose a patch where the condition _removes_
> this feature (and define it on the Broadcom boards)  -- do we
> generally like "negated" conditionals?
> +#ifndef 
> CONFIG_USB_GADGET_FASTBOOT_DOWNLOAD_DISABLE_ALIGNMENT_WITH_WMAXPACKETSIZE
> Please advise!

Definitely not, I will not have a new macro added just to paper over
some problem which noone bothered to research and fix properly, sorry.

> Further, how does the U-Boot community respond to a change which
> breaks something which is already working? Doesn't the "author" of
> that change bear any responsibility on assisting to get "their" change
> working properly with "all" the existing boards? I'm getting the
> impression that "because the current code works for me", that I am not
> getting any assistance in resolving this issue -- which is why I
> suggested "reverting" this change back to the original code; that way,
> it would (politely?) force someone interested in "TI platforms" to
> step up and look into this

I will pass this question onto Tom ;-)

> Sorry for asking so many questions in one email -- but I'd appreciate
> answers
> ( I also apologize in advance for the "attitude" which is leaking into
> this email... )
> Please tell me what I can do! I had working boards; now they are all
> broken -- and I don't how how to get them working again

Kick the TI person into the backside until he comes up with a proper
solution. Be annoying. Or, if that leads nowhere, I will just apply
the revert and break it for TI and expect them to fix it proper.

btw. note that ELC is going on this week, so replies might be delayed.

> Thanks, Steve
> 
> On Wed, Apr 6, 2016 at 4:01 AM, Marek Vasut  wrote:
>> On 04/06/2016 07:35 AM, Steve Rae wrote:
>>>
>>> On Apr 5, 2016 3:07 PM, "Marek Vasut" >> > wrote:

 On 04/05/2016 08:31 PM, Steve Rae wrote:
> commit 9e4b510 fastboot: OUT transaction length must be aligned to
>>> wMaxPacketSize
> breaks some boards...
>
> Therefore add a conditional Kconfig to optionally enable this feature.

 Did you drill in

[U-Boot] [PATCH] fdt: implement dev_get_addr_name()

[Stephen Warren]

From: Stephen Warren 

This function parses the reg property based on an index found in the
reg-names property. This is required for bindings that are written
using reg-names rather than hard-coding indices in reg.

Signed-off-by: Stephen Warren 
---
 drivers/core/device.c | 16 
 include/dm/device.h   | 12 
 2 files changed, 28 insertions(+)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index cb24a617ceef..87755f514ba4 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -649,6 +649,22 @@ fdt_addr_t dev_get_addr_index(struct udevice *dev, int 
index)
 #endif
 }
 
+fdt_addr_t dev_get_addr_name(struct udevice *dev, const char *name)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+   int index;
+
+   index = fdt_find_string(gd->fdt_blob, dev->parent->of_offset,
+   "reg-names", name);
+   if (index < 0)
+   return index;
+
+   return dev_get_addr_index(dev, index);
+#else
+   return FDT_ADDR_T_NONE;
+#endif
+}
+
 fdt_addr_t dev_get_addr(struct udevice *dev)
 {
return dev_get_addr_index(dev, 0);
diff --git a/include/dm/device.h b/include/dm/device.h
index 1cf81501ed92..dad7591dfacb 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -465,6 +465,18 @@ fdt_addr_t dev_get_addr(struct udevice *dev);
 fdt_addr_t dev_get_addr_index(struct udevice *dev, int index);
 
 /**
+ * dev_get_addr_name() - Get the reg property of a device, indexed by name
+ *
+ * @dev: Pointer to a device
+ * @name: the 'reg' property can hold a list of  pairs, with the
+ *   'reg-names' property providing named-based identification. @index
+ *   indicates the value to search for in 'reg-names'.
+ *
+ * @return addr
+ */
+fdt_addr_t dev_get_addr_name(struct udevice *dev, const char *name);
+
+/**
  * device_has_children() - check if a device has any children
  *
  * @dev:   Device to check
-- 
2.8.1

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

Re: [U-Boot] EFI Stub compilation errors

[Simon Glass]

Hi Nicolae,

On 5 April 2016 at 02:02, Nicolae Rosia  wrote:
>
> Hello,
>
> I'm trying to build U-Boot as an UEFI Payload, head
> 4ed6ed3c27a069a00c8a557d606a05276cc4653e, branch master.
> I did the following:
> make qemu-x86_defconfig
> make menuconfig
> Enable the following:
> CONFIG_EFI=y
> EFI_STUB=y
> EFI_STUB_64BIT=y

I assume you mean:

CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_EFI_STUB_64BIT=y

> make

>
> I gets lots of warnings ([0]) and the following error:
> /home/user/workspace/u-boot/lib/efi/efi_stub.c:357: undefined
> reference to `_binary_u_boot_dtb_bin_start'
> /home/user/workspace/u-boot/lib/efi/efi_stub.c:357: undefined
> reference to `_binary_u_boot_dtb_bin_end'
>
> Any idea what I'm doing wrong?

There are a few problems - I've sent a patch to show how to correct it
in general, but it needs a bit of work.

The error is simply that u-boot-dtb.bin is now called u-boot.bin - a
recent change.

But the warnings are due to BITS_PER_LONG being 64-bit. This value of
this define should be 32 for U-Boot, and 64 for the payload files
only:

./lib/efi/efi.c
./lib/efi/efi_stub.c

If you fix this, it would be good to add a new qemu-x86-efi target to
avoid this breaking in the future.

>
> Best regards,
> Nicolae
>
> [0] make log http://pastebin.com/geb5RqTW
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] [PATCH] WIP: Example changes to build EFI stub for x86

[Simon Glass]

Hi Nicolae,

On 6 April 2016 at 09:50, Nicolae Rosia  wrote:
> Hi,
>
> On Wed, Apr 6, 2016 at 6:06 PM, Simon Glass  wrote:
>> Currently it is not possible to build the 64-bit EFI stub due to changes in
>> the build. To prevent future bit rot, we should add  target for building
>> qemu-x86 as an EFI stub (with U-Boot as a 32-bit payload).
>>
>> This patch provides some hints.
>>
>> Reported-by: Nicolae Rosia 
>> Signed-off-by: Simon Glass 
>> ---
>>
>>  arch/x86/include/asm/types.h | 12 
>>  configs/qemu-x86_defconfig   |  3 +++
>>  include/efi.h|  2 +-
>>  lib/efi/efi_stub.c   |  6 +++---
>>  4 files changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/types.h b/arch/x86/include/asm/types.h
>> index 766617f..998d70a 100644
>> --- a/arch/x86/include/asm/types.h
>> +++ b/arch/x86/include/asm/types.h
>> @@ -44,11 +44,15 @@ typedef __INT64_TYPE__ s64;
>>  typedef __UINT64_TYPE__ u64;
>>  #endif
>>
>> -#ifdef CONFIG_EFI_STUB_64BIT
>> -#define BITS_PER_LONG 64
>> -#else
>> +/*
>> + * This should be defined only when compiling the stub - see the
>> + * ecmd_u-boot_payload build rule
>> + */
> Are you saying that I should take a look at cmd_u-boot_payload in Makefile?
> I've looked over it and I don't figure out what I should see.

Just the list of files that it builds there (efi.c and efi_stub.c).

>
>> +// #ifdef CONFIG_EFI_STUB_64BIT
>> +// #define BITS_PER_LONG 64
>> +// #else
>>  #define BITS_PER_LONG 32
>> -#endif
>> +// #endif
> This fixes the compilation warnings

Right, but a correct patch will obey the comment immediately above.

>
>>  /* Dma addresses are 32-bits wide.  */
>>
>>  typedef u32 dma_addr_t;
>> diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
>> index bb9c6cd..2a7087f 100644
>> --- a/configs/qemu-x86_defconfig
>> +++ b/configs/qemu-x86_defconfig
>> @@ -32,3 +32,6 @@ CONFIG_VIDEO_VESA=y
>>  CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
>>  CONFIG_FRAMEBUFFER_VESA_MODE_111=y
>>  CONFIG_USE_PRIVATE_LIBGCC=y
>> +CONFIG_EFI=y
>> +CONFIG_EFI_STUB=y
>> +CONFIG_EFI_STUB_64BIT=y
> Should we create an example defconfig for efi stub and not modify the
> qemu defconfig?

I suggest a new board config called qemu-x86-efi. It can copy qemu,
with the addition of the above three options.

>
>> diff --git a/include/efi.h b/include/efi.h
>> index 1dbc3b7..21921f1 100644
>> --- a/include/efi.h
>> +++ b/include/efi.h
>> @@ -278,7 +278,7 @@ struct efi_priv {
>>  extern char image_base[];
>>
>>  /* Start and end of U-Boot image (for payload) */
>> -extern char _binary_u_boot_dtb_bin_start[], _binary_u_boot_dtb_bin_end[];
>> +extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
>>
>>  /**
>>   * efi_get_sys_table() - Get access to the main EFI system table
>> diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
>> index 8b4bb4e..1814960 100644
>> --- a/lib/efi/efi_stub.c
>> +++ b/lib/efi/efi_stub.c
>> @@ -354,9 +354,9 @@ efi_status_t efi_main(efi_handle_t image, struct 
>> efi_system_table *sys_table)
>> /* The EFI UART won't work now, switch to a debug one */
>> use_uart = true;
>>
>> -   memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_dtb_bin_start,
>> -  (ulong)_binary_u_boot_dtb_bin_end -
>> -  (ulong)_binary_u_boot_dtb_bin_start);
>> +   memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_bin_start,
>> +  (ulong)_binary_u_boot_bin_end -
>> +  (ulong)_binary_u_boot_bin_start);
>>
> Thanks, these fixes the compilation errors.
>
>>  #ifdef DEBUG
>> puts("EFI table at ");
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>
> I'll try to boot test.

OK, but it is still broken without the fix mentioned above.

>
> Best regards,
> Nicolae

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

Re: [U-Boot] [PATCH] cmd: fdt: Use separate CMD_FDT Kconfig entry instead of OF_LIBFDT

[Michal Simek]

On 6.4.2016 03:28, Masahiro Yamada wrote:
> Hi.
> 
> 
> 2016-04-06 4:09 GMT+09:00 Simon Glass :
>> Hi Michal,
>>
>> On 5 April 2016 at 04:15, Michal Simek  wrote:
>>> Hi Simon,
>>>
>>> On 5.4.2016 02:03, Simon Glass wrote:
 Hi Michal,

 On 4 April 2016 at 11:50, Michal Simek  wrote:
> Create CMD_FDT Kconfig entry to have an option to disable fdt command
> which is not required for small configuration which requires libfdt
> only.
> Enable it by default for all targets which enables OF_LIBFDT.
>
> Signed-off-by: Michal Simek 
> ---
>
>  cmd/Kconfig  | 7 +++
>  cmd/Makefile | 2 +-
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index fe8b4f0510da..8703cdb4a9be 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -173,6 +173,13 @@ config CMD_ELF
> help
>   Boot an ELF/vxWorks image from the memory.
>
> +config CMD_FDT
> +   bool "Flattened Device Tree utility commands"
> +   default y

 Should that be:

 default y if OF_LIBFDT

 ?

> +   depends on OF_LIBFDT
> +   help
> + Do FDT related setup before booting into the Operating System.
> +
>>>
>>>
>>> In recent commits to this file both formats are used.
>>>
>>> +config CMD_BLOCK_CACHE
>>> + bool "blkcache - control and stats for block cache"
>>> + depends on BLOCK_CACHE
>>> + default y if BLOCK_CACHE
>>>
>>> even looks non standard.
>>>
>>> +config CMD_BOOTEFI
>>> + bool "bootefi"
>>> + depends on EFI_LOADER
>>> + default y
>>>
>>> I am happy to change whatever style you prefer but I think it should be
>>> synchronized. The efi one was Reviewed by you. :-)
>>
>> I think Masahiro knows most about this. If it works it's fine with me.
>> The way you have it is more intuitive and I prefer it. But he did
>> point at a problem at some point.
> 
> 
> I think "depends on OF_LIBFDT"
> is correct in this case.
> 
> 
> do_fdt() calls fdt_fixup_memory(), which is defined in common/fdt_support.c,
> which is enabled by CONFIG_OF_LIBFDT.
> 
> So, CMD_FDT should depend on OF_LIBFDT.
> Otherwise, "make menuconfig" would allow users
> to enable CMD_FDT without OF_LIBFDT,
> which would cause link error.
> 
> 
>> One other question - won't this disable the 'fdt' command for many boards?
> 
> 
> config CMD_FDT
> bool "Flattened Device Tree utility commands"
> default y
> depends on OF_LIBFDT
> 
> 
> "default y" cares about it.
> So, if CONFIG_OF_LIBFDT is enabled in the defconfig,
> CONFIG_CMD_FDT should be enabled as well.
> 
> 
> 
> But the following 6 boards opt out of Kconfig.
> They define CONFIG_OF_LIBFDT in their config headers,
> so this patch would disable "fdt" command for them.
> 
> include/configs/legoev3.h
> include/configs/ma5d4evk.h
> include/configs/pic32mzdask.h
> include/configs/stm32f746-disco.h
> include/configs/xilinx-ppc.h
> include/configs/zipitz2.h
> 
> 
> 
> Could you move them to defconfigs?
> 

I have sent v2 to address these. I have used buildman and there is up to
2k difference when symbol is in Kconfig. Not sure why but it shouldn't
be big deal.

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

[U-Boot] [PATCH v2 2/2] cmd: fdt: Use separate CMD_FDT Kconfig entry instead of OF_LIBFDT

[Michal Simek]

Create CMD_FDT Kconfig entry to have an option to disable fdt command
which is not required for small configuration which requires libfdt
only.
Enable it by default for all targets which enables OF_LIBFDT.

Signed-off-by: Michal Simek 
---

Changes in v2: None

 cmd/Kconfig  | 7 +++
 cmd/Makefile | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index fe8b4f0510da..8703cdb4a9be 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -173,6 +173,13 @@ config CMD_ELF
help
  Boot an ELF/vxWorks image from the memory.
 
+config CMD_FDT
+   bool "Flattened Device Tree utility commands"
+   default y
+   depends on OF_LIBFDT
+   help
+ Do FDT related setup before booting into the Operating System.
+
 config CMD_GO
bool "go"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index ba041973079c..f95759e67044 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -54,7 +54,7 @@ obj-$(CONFIG_CMD_EXT4) += ext4.o
 obj-$(CONFIG_CMD_EXT2) += ext2.o
 obj-$(CONFIG_CMD_FAT) += fat.o
 obj-$(CONFIG_CMD_FDC) += fdc.o
-obj-$(CONFIG_OF_LIBFDT) += fdt.o
+obj-$(CONFIG_CMD_FDT) += fdt.o
 obj-$(CONFIG_CMD_FITUPD) += fitupd.o
 obj-$(CONFIG_CMD_FLASH) += flash.o
 ifdef CONFIG_FPGA
-- 
1.9.1

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

[U-Boot] [PATCH v2 1/2] kconfig: Move CONFIG_OF_LIBFDT to Kconfig

[Michal Simek]

This patch follows work done by:
"Move CONFIG_OF_LIBFDT to Kconfig"
(sha1: 69e173eb57d1f4848f070c83456096ba5d2ba1b4)

Signed-off-by: Michal Simek 
---

Changes in v2:
- new patch in series. Masahiro asked for it.

 configs/legoev3_defconfig | 2 ++
 configs/ma5d4evk_defconfig| 2 ++
 configs/stm32f746-disco_defconfig | 2 ++
 configs/zipitz2_defconfig | 4 +++-
 include/configs/legoev3.h | 1 -
 include/configs/ma5d4evk.h| 1 -
 include/configs/pic32mzdask.h | 5 -
 include/configs/stm32f746-disco.h | 1 -
 include/configs/xilinx-ppc.h  | 1 -
 include/configs/zipitz2.h | 1 -
 10 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/configs/legoev3_defconfig b/configs/legoev3_defconfig
index d838baa32cbb..22fd0578ef72 100644
--- a/configs/legoev3_defconfig
+++ b/configs/legoev3_defconfig
@@ -10,3 +10,5 @@ CONFIG_AUTOBOOT_STOP_STR="l"
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SYS_NS16550=y
+CONFIG_OF_LIBFDT=y
+# CONFIG_EFI_LOADER is not set
diff --git a/configs/ma5d4evk_defconfig b/configs/ma5d4evk_defconfig
index 39ce550ff44f..144851426937 100644
--- a/configs/ma5d4evk_defconfig
+++ b/configs/ma5d4evk_defconfig
@@ -12,3 +12,5 @@ CONFIG_SYS_EXTRA_OPTIONS="SAMA5D4"
 CONFIG_SPI_FLASH=y
 CONFIG_USB=y
 CONFIG_USB_GADGET=y
+CONFIG_OF_LIBFDT=y
+# CONFIG_EFI_LOADER is not set
diff --git a/configs/stm32f746-disco_defconfig 
b/configs/stm32f746-disco_defconfig
index 7cfed4a514bf..07aa874760c2 100644
--- a/configs/stm32f746-disco_defconfig
+++ b/configs/stm32f746-disco_defconfig
@@ -7,3 +7,5 @@ CONFIG_AUTOBOOT_KEYED=y
 CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n"
 CONFIG_AUTOBOOT_STOP_STR=" "
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_LIBFDT=y
+# CONFIG_EFI_LOADER is not set
diff --git a/configs/zipitz2_defconfig b/configs/zipitz2_defconfig
index 2977ccc8ddee..d2fa63d15f08 100644
--- a/configs/zipitz2_defconfig
+++ b/configs/zipitz2_defconfig
@@ -1,7 +1,9 @@
 CONFIG_ARM=y
 CONFIG_TARGET_ZIPITZ2=y
+CONFIG_SYS_PROMPT="$ "
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
-CONFIG_SYS_PROMPT="$ "
+CONFIG_OF_LIBFDT=y
+# CONFIG_EFI_LOADER is not set
diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
index 79fa3c476ad1..0bc9d2dc18b4 100644
--- a/include/configs/legoev3.h
+++ b/include/configs/legoev3.h
@@ -160,7 +160,6 @@
 #define CONFIG_SYS_LONGHELP
 #define CONFIG_CRC32_VERIFY
 #define CONFIG_MX_CYCLIC
-#define CONFIG_OF_LIBFDT
 
 /*
  * Linux Information
diff --git a/include/configs/ma5d4evk.h b/include/configs/ma5d4evk.h
index e061a101aee6..8a80b954a68d 100644
--- a/include/configs/ma5d4evk.h
+++ b/include/configs/ma5d4evk.h
@@ -150,7 +150,6 @@
 #define CONFIG_LOADADDR0x2080
 #define CONFIG_BOOTCOMMAND "run mmc_mmc"
 #define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
-#define CONFIG_OF_LIBFDT
 
 /*
  * Extra Environments
diff --git a/include/configs/pic32mzdask.h b/include/configs/pic32mzdask.h
index 3ea11946b8ab..fd874c42a2bc 100644
--- a/include/configs/pic32mzdask.h
+++ b/include/configs/pic32mzdask.h
@@ -92,11 +92,6 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
-/*
- * Handover flattened device tree (dtb file) to Linux kernel
- */
-#define CONFIG_OF_LIBFDT   1
-
 /*---
  * SDHC Configuration
  */
diff --git a/include/configs/stm32f746-disco.h 
b/include/configs/stm32f746-disco.h
index 807ab6574eb5..e94812bf5a78 100644
--- a/include/configs/stm32f746-disco.h
+++ b/include/configs/stm32f746-disco.h
@@ -11,7 +11,6 @@
 #define CONFIG_SYS_THUMB_BUILD
 /*#define CONFIG_SYS_NO_FLASH*/
 
-#define CONFIG_OF_LIBFDT
 #define CONFIG_BOARD_EARLY_INIT_F
 
 #define CONFIG_SYS_FLASH_BASE  0x0800
diff --git a/include/configs/xilinx-ppc.h b/include/configs/xilinx-ppc.h
index d01d88b33f4d..831b9401d1df 100644
--- a/include/configs/xilinx-ppc.h
+++ b/include/configs/xilinx-ppc.h
@@ -101,7 +101,6 @@
 #define CONFIG_SYS_NO_FLASH
 #endif
 
-#define CONFIG_OF_LIBFDT   1
 #define CONFIG_BAUDRATE115200
 /* The following table includes the supported baudrates */
 # define CONFIG_SYS_BAUDRATE_TABLE \
diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h
index 5200e0219168..46836d578c0a 100644
--- a/include/configs/zipitz2.h
+++ b/include/configs/zipitz2.h
@@ -45,7 +45,6 @@
 #defineCONFIG_SETUP_MEMORY_TAGS
 #defineCONFIG_SYS_TEXT_BASE0x0
 #defineCONFIG_LZMA /* LZMA compression support */
-#defineCONFIG_OF_LIBFDT
 
 /*
  * Serial Console Configuration
-- 
1.9.1

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

[U-Boot] [PATCH] test/py: README: link to example hook scripts

[Stephen Warren]

From: Stephen Warren 

When implementing test/py hook scripts, it's helpful to read some working
examples. Provide a link to some. The link was mentioned in the commit
message which first added test/py, but not in any documentation file.

Suggested-by: Lukasz Majewski 
Signed-off-by: Stephen Warren 
---
 test/py/README.md | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/test/py/README.md b/test/py/README.md
index ba1674cb1de6..829c7efbb2d7 100644
--- a/test/py/README.md
+++ b/test/py/README.md
@@ -246,6 +246,12 @@ to download the U-Boot binary directly into RAM and 
execute it. This would
 avoid the need for `u-boot-test-flash` to actually write U-Boot to flash, thus
 saving wear on the flash chip(s).
 
+ Examples
+
+https://github.com/swarren/uboot-test-hooks contains some working example hook
+scripts, and may be useful as a reference when implementing hook scripts for
+your platform. These scripts are not considered part of U-Boot itself.
+
 ### Board-type-specific configuration
 
 Each board has a different configuration and behaviour. Many of these
-- 
2.8.1

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

[U-Boot] Please pull u-boot-fsl-qoriq master

[York Sun]

Tom,

The following changes since commit 4ed6ed3c27a069a00c8a557d606a05276cc4653e:

  Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2016-04-04
14:34:09 -0400)

are available in the git repository at:


  git://git.denx.de/u-boot-fsl-qoriq.git master

for you to fetch changes up to 3c1d218a1d3048fb576677c47eab43049d0b7778:

  armv8: LS2080A: Consolidate LS2080A and LS2085A (2016-04-06 10:26:46 -0700)


Codrin Ciubotariu (2):
  drivers: net: vsc9953: Do not configure disabled ports
  drivers: net: vsc9953: Fix bug when PVID is shown for disabled ports only

Ed Swarthout (1):
  armv8: LSCH2 early and final mmu needs matching NS attribute

Peng Fan (2):
  fsl: esdhc: support driver model
  fsl: esdhc: consolidate fsl_esdhc_cfg structure

Qianyu Gong (2):
  armv8: ls1043a: load Fman ucode from NAND flash under NAND boot
  armv8: ls1043a: load Fman ucode from SD/MMC under SD boot

Shaohui Xie (1):
  armv8: ls1043aqds: make sure fixed-link property is big endian

Vincent Siles (1):
  arm: ls102xa: Fix order of CSU indexes in ns_access.h

Wenbin Song (1):
  armv8/ls1043aqds: modify CONFIG_SYS_MAX_FLASH_BANKS to 1

York Sun (1):
  armv8: LS2080A: Consolidate LS2080A and LS2085A

 arch/arm/cpu/armv8/fsl-layerscape/Makefile |4 -
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|9 +-
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |6 +-
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |2 +-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   26 +-
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|4 +-
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |9 +-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   14 +-
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |2 +-
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |3 +
 arch/arm/include/asm/arch-ls102xa/ns_access.h  |6 +-
 arch/arm/include/asm/fsl_secure_boot.h |   12 +-
 board/freescale/ls1043aqds/eth.c   |   12 +-
 board/freescale/ls2080a/MAINTAINERS|2 -
 board/freescale/ls2080a/ddr.c  |   27 ++-
 board/freescale/ls2080a/ls2080a.c  |2 +-
 board/freescale/ls2080aqds/MAINTAINERS |3 -
 board/freescale/ls2080aqds/ddr.c   |   27 ++-
 board/freescale/ls2080aqds/ls2080aqds.c|2 +-
 board/freescale/ls2080ardb/MAINTAINERS |3 -
 board/freescale/ls2080ardb/ddr.c   |   27 ++-
 board/freescale/ls2080ardb/ls2080ardb.c|2 +-
 configs/ls2085a_emu_defconfig  |   20 --
 configs/ls2085a_simu_defconfig |   21 --
 configs/ls2085aqds_SECURE_BOOT_defconfig   |   20 --
 configs/ls2085aqds_defconfig   |   19 --
 configs/ls2085aqds_nand_defconfig  |   14 --
 configs/ls2085ardb_SECURE_BOOT_defconfig   |   20 --
 configs/ls2085ardb_defconfig   |   19 --
 configs/ls2085ardb_nand_defconfig  |   14 --
 doc/device-tree-bindings/serial/8250.txt   |2 +-
 drivers/crypto/fsl/jr.c|6 +-
 drivers/mmc/fsl_esdhc.c|  253 
 drivers/net/fsl-mc/mc.c|   10 +
 drivers/net/ldpaa_eth/Makefile |1 -
 drivers/net/vsc9953.c  |   14 +-
 include/configs/ls1043a_common.h   |   14 +-
 include/configs/ls1043aqds.h   |2 +-
 include/configs/ls2080a_common.h   |7 +-
 include/configs/ls2080a_emu.h  |7 -
 include/configs/ls2080a_simu.h |7 -
 include/fsl_esdhc.h|6 +-
 include/linux/usb/xhci-fsl.h   |2 +-
 43 files changed, 369 insertions(+), 313 deletions(-)
 delete mode 100644 configs/ls2085a_emu_defconfig
 delete mode 100644 configs/ls2085a_simu_defconfig
 delete mode 100644 configs/ls2085aqds_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls2085aqds_defconfig
 delete mode 100644 configs/ls2085aqds_nand_defconfig
 delete mode 100644 configs/ls2085ardb_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls2085ardb_defconfig
 delete mode 100644 configs/ls2085ardb_nand_defconfig

Thanks.

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

Re: [U-Boot] [PATCH 2/2] armv8: ls1043a: load Fman ucode from SD/MMC under SD boot

[York Sun]

On 04/01/2016 03:02 AM, Gong Qianyu wrote:
> Signed-off-by: Gong Qianyu 
> ---
>  include/configs/ls1043a_common.h | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH] armv8/ls1043aqds modify CONFIG_SYS_MAX_FLASH_BANKS to 1

[York Sun]

On 04/01/2016 02:37 AM, Wenbin Song wrote:
> There is only one flash bank for ls1043aqds.
> Signed-off-by: Wenbin Song 
> ---
>  include/configs/ls1043aqds.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Add ":" sign in subject to separate tag from subject.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH 1/2] armv8: ls1043a: load Fman ucode from NAND flash under NAND boot

[York Sun]

On 04/01/2016 03:02 AM, Gong Qianyu wrote:
> Signed-off-by: Gong Qianyu 
> ---
>  include/configs/ls1043a_common.h | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH] arm: Fix order of CSU indexes in ns_access.h

[York Sun]

On 03/29/2016 12:41 AM, Vincent Siles wrote:
> This patch aims to fix the order of CSU slave index for the LS1021a
> board.
> 
> Signed-off-by: Vincent Siles 
> 
> ---
> 
>  arch/arm/include/asm/arch-ls102xa/ns_access.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

Revised tag in subject.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH RESEND] armv8: LSCH2 early and final mmu needs matching NS attribute

[York Sun]

On 03/28/2016 02:16 PM, Ed Swarthout wrote:
> When switching between the early and final mmu tables, the stack will
> get corrupted if the Non-Secure attribute is different.  For ls1043a,
> this issue is currently masked because flush_dcache_all is called
> before the switch when CONFIG_SYS_DPAA_FMAN is defined.
> 
> Signed-off-by: Ed Swarthout 
> ---
> 
> Resend to fix diff format.
> 
> denx/master with CONFIG_SYS_DPAA_FMAN undefined:
> Fixes:
> 
> U-Boot 2016.03-00530-g1fee6de (Mar 28 2016 - 13:46:36 -0500)
> SoC:  LS1043E (0x87920010)
> ...
> Detected UDIMM 18ASF1G72AZ-2G1A1 
> 4 GiB (DDR4, 32-bit, CL=11, ECC on)
>DDR Chip-Select Interleaving Mode: CS0+CS1
> "Synchronous Abort" handler, esr 0x8a00
> ELR: deadbeefdeadbeef
> LR:  deadbeefdeadbeef
> x0 : 00ff440c0400 x1 : 00022518
> x2 : 0040 x3 : 003f
> x4 : 0004 x5 : 0001
> x6 : 0009 x7 : 0020
> x8 : 0015 x9 : 000c
> x10: 0401 x11: 0008ffe06000
> x12: 01ff x13: 4000
> x14: 0020 x15: 0001
> x16:  x17: 0002
> x18: ffdd8d78 x19: deadbeefdeadbeef
> x20: deadbeefdeadbeef x21: deadbeefdeadbeef
> x22: deadbeefdeadbeef x23: deadbeefdeadbeef
> x24: deadbeefdeadbeef x25: deadbeefdeadbeef
> x26: deadbeefdeadbeef x27: 
> x28: fff6ca90 x29: deadbeefdeadbeef
> 
> 
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH] armv8: ls1043aqds: make sure fixed-link property is big endian

[York Sun]

On 03/24/2016 08:46 PM, shh@gmail.com wrote:
> From: Shaohui Xie 
> 
> When setting fixed-link property to DTS, the values should be converted
> with using cpu_to_fdt32 so that to have correct value on little endian
> Soc.
> 
> Signed-off-by: Shaohui Xie 
> ---
>  board/freescale/ls1043aqds/eth.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] FPGA detection failure on Cyclone V soc development kit

[Måns Rullgård]

Marek Vasut  writes:

> On 04/06/2016 05:29 PM, Dinh Nguyen wrote:
>> On Wed, Apr 6, 2016 at 10:07 AM, Marek Vasut  wrote:
>>>
>>> I pushed some DDR fixes into u-boot-socfpga/ddr branch [1], which fixed
>>> DDR calibration issue on a board I have in here. Can you try them ? Thanks
>>>
>>> [1]
>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>>
>> 
>> I'll do it first thing when I get back from ELC.
>
> Cool. I will do proper submission by then. I think Mans had a CV SoCDK
> which didn't boot with the mainline SPL, so it'd be cool if he could try.

I will when I get back from ELC.

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

Re: [U-Boot] [PATCH] drivers: net: vsc9953: Fix bug when PVID is shown for disabled ports only

[York Sun]

On 03/14/2016 04:47 AM, Codrin Ciubotariu wrote:
> Signed-off-by: Codrin Ciubotariu 
> ---
>  drivers/net/vsc9953.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH] drivers: net: vsc9953: Do not configure disabled ports

[York Sun]

On 03/14/2016 04:47 AM, Codrin Ciubotariu wrote:
> Some SerDes protocols might not enable all l2switch ports. In this case,
> these ports should not be configured to perform Rx/Tx operations.
> This also fixes an issue when flooded frames were also switched to
> disabled ports and frames start to accumulate, consuming memory
> and eventually causing head-of-line blocking for other frames.
> 
> Signed-off-by: Codrin Ciubotariu 
> ---
>  drivers/net/vsc9953.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH V2] fsl: esdhc: consolidate fsl_esdhc_cfg structure

[York Sun]

On 03/15/2016 03:14 AM, Peng Fan wrote:
> We can use phys_addr_to for esdhc_base to discard
> the #ifdef.
> 
> Signed-off-by: Peng Fan 
> Cc: York Sun 
> Cc: Yangbo Lu 
> Cc: Eric Nelson 
> Cc: Fabio Estevam 
> Cc: Pantelis Antoniou 
> Cc: Tom Rini 
> ---
> 
> V2:
>  Split this patch from the V1 patch set.
> 
>  include/fsl_esdhc.h | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH V3] fsl: esdhc: support driver model

[York Sun]

On 03/24/2016 11:26 PM, Peng Fan wrote:
> Support Driver Model for fsl esdhc driver.
> 
> 1. Introduce a new structure struct fsl_esdhc_priv
> 2. Refactor fsl_esdhc_initialize which is originally used by board code.
>- Introduce fsl_esdhc_init to be common usage for DM and non-DM
>- Introduce fsl_esdhc_cfg_to_priv to build the bridge for non-DM part.
>- The original API for board code is still there, but we use
>  'fsl_esdhc_cfg_to_priv' and 'fsl_esdhc_init' to serve it.
> 3. All the functions are changed to use 'struct fsl_esdhc_priv', except
>fsl_esdhc_initialize.
> 4. Since clk driver is not implemented, use mxc_get_clock to geth
>the clk and fill 'priv->sdhc_clk'.
> 
> Has been tested on i.MX6UL 14X14 EVK board:
> "
> =>dm tree
> 
>  simple_bus  [ + ]|   `-- aips-bus@0210
>   mmc[ + ]|   |-- usdhc@0219
>   mmc[ + ]|   |-- usdhc@02194000
> 
> => mmc list
> FSL_SDHC: 0 (SD)
> FSL_SDHC: 1 (SD)
> "
> 
> Signed-off-by: Peng Fan 
> Cc: York Sun 
> Cc: Yangbo Lu 
> Cc: Hector Palacios 
> Cc: Eric Nelson 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> ---
> 
> V3:
>  Fix build error reported by York for PPC.
> 
> V2:
>  restructure the V1 patch.
>  Introduce fsl_esdhc_priv structure.
>  Introduce code to handle cd-gpios and non-removable.
> 
>  drivers/mmc/fsl_esdhc.c | 253 
> 
>  1 file changed, 213 insertions(+), 40 deletions(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.
Thanks.

York


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

Re: [U-Boot] [PATCH v2] fastboot: OUT transaction length must be aligned to wMaxPacketSize

[Steve Rae]

No -- I do not believe that this issue is caused by different fastboot
(client) versions (the executable that runs on the host computer -
Linux, Windows, Mac, etc.)
I have personally attempted three (3) different versions, and the
results are consistent.

And no I don't think that I "am the only hope at fixing this proper"
-- as you will see below,
this" issue" seems to be unique to the "TI platforms" (... nobody else
has stated they have an issue either way -- but I don't think many use
this feature )
So maybe someone with "TI platforms" could investigate this more thoroughly...

HISTORY:

The U-Boot code, up to Feb 25, worked properly on my Broadcom boards
-- this code contains:
   req->length = rx_bytes_expected();
if (req->length < ep->maxpacket)
req->length = ep->maxpacket;
which aligned the remaining "rx_bytes_expected" to be aligned to the
"ep->maxpacket" size.

On Feb 25, there was a patch applied from 
which forces the remaining "rx_bytes_expected" to be aligned to the
"wMaxPacketSize" size -- this patch broke all Broadcom boards:
+   if (rx_remain < maxpacket) {
+   rx_remain = maxpacket;
+   } else if (rx_remain % maxpacket != 0) {
+   rem = rx_remain % maxpacket;
+   rx_remain = rx_remain + (maxpacket - rem);
+   }

After attempting to unsuccessfully contact Dileep, I requested that
this patch be reverted -- because it broke my boards! (see the other
email thread).

Sam Protsenko  has stated that this Feb 25
change is required to make "fastboot work on TI platforms".

Thus,
- Broadcom boards require alignment to "ep->maxpacket" size
- TI platforms require alignment to "wMaxPacketSize" size
And we seem to be at a stale-mate.
Unfortunately, I do not know enough about the USB internals to
understand why this change breaks the Broadcom boards; or why it _is_
required on the TI platforms
( Is there any debugging that can be turned on to validate what is
happening at the lower levels? )
( Can anyone explain why "wMaxPacketSize" size would be required? --
my limited understanding of endpoints makes me think that
"ep->maxpacket" size is actually the correct value! )

I asked Sam to submit a patch which conditionally applied the
alignment to "wMaxPacketSize" size change -- he stated that he was too
busy right now -- so I submitted this patch on his behalf (although he
still needs to add the Kconfig for the TI platforms in order to make
his boards work)

I suppose I could also propose a patch where the condition _removes_
this feature (and define it on the Broadcom boards)  -- do we
generally like "negated" conditionals?
+#ifndef 
CONFIG_USB_GADGET_FASTBOOT_DOWNLOAD_DISABLE_ALIGNMENT_WITH_WMAXPACKETSIZE
Please advise!

Further, how does the U-Boot community respond to a change which
breaks something which is already working? Doesn't the "author" of
that change bear any responsibility on assisting to get "their" change
working properly with "all" the existing boards? I'm getting the
impression that "because the current code works for me", that I am not
getting any assistance in resolving this issue -- which is why I
suggested "reverting" this change back to the original code; that way,
it would (politely?) force someone interested in "TI platforms" to
step up and look into this

Sorry for asking so many questions in one email -- but I'd appreciate
answers
( I also apologize in advance for the "attitude" which is leaking into
this email... )
Please tell me what I can do! I had working boards; now they are all
broken -- and I don't how how to get them working again
Thanks, Steve

On Wed, Apr 6, 2016 at 4:01 AM, Marek Vasut  wrote:
> On 04/06/2016 07:35 AM, Steve Rae wrote:
>>
>> On Apr 5, 2016 3:07 PM, "Marek Vasut" > > wrote:
>>>
>>> On 04/05/2016 08:31 PM, Steve Rae wrote:
>>> > commit 9e4b510 fastboot: OUT transaction length must be aligned to
>> wMaxPacketSize
>>> > breaks some boards...
>>> >
>>> > Therefore add a conditional Kconfig to optionally enable this feature.
>>>
>>> Did you drill into it to figure out why this is needed ?
>>>
>>
>> Marek,
>> Let me clarify
>> All my boards work with the original code (before the commit which
>> aligned  the size to the wMaxPacketSize) Since that commit, all my
>> boards are broken.
>> And you will notice in this patch, that none of my boards define this
>> CONFIG_ ...
>>
>> So I think you are asking the wrong person to drill down into this issue
>> Sorry, Steve
>
> Well who else can I ask ? You're our only hope at fixing this proper.
>
> Anyway, see my other reply, maybe we should just add an arg to fastboot
> command to select one more of operation or the other and default to the
> one which works.
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8/ls1043a: Add MTD partition scheme

[York Sun]

On 04/06/2016 12:11 AM, Wenbin Song wrote:
> Hi: York
> 
> I set bootargs  as the following steps:
> 
> => env default mtdparts
> => printenv mtdparts
> mtdparts=mtdparts=6000.nor:1m(nor_bank0_rcw),1m(nor_bank0_uboot),1m(nor_bank0_uboot_env),1m(nor_bank0_fman_uconde),40m(nor_bank0_fit),1m(nor_bank4_rcw),1m(nor_bank4_uboot),1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode),40m(nor_bank4_fit);7e80.flash:1m(nand_uboot),1m(nand_uboot_env),20m(nand_fit);spi0.0:1m(uboot),5m(kernel),1m(dtb),9m(file_system)
> => env default bootargs
> => printenv bootargs
> bootargs=console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 
> ${mtdparts}
> 
> 
> The macro  CONFIG_BOOTARGS  only be extern as an char-string, and it will be 
> spliced into default_environment array . 
> 
>  const uchar default_environment[] = {
> #ifdef  CONFIG_BOOTARGS
>   "bootargs=" CONFIG_BOOTARGS "\0"
>  #endif
>  
> The variable we use to have $consoledev, $othbootargs  was used in the 
> following cases:
> 
> 858  #define CONFIG_BOOTCOMMAND \
> 859 "setenv bootargs root=/dev/ram rw " \
> 860 "console=$consoledev,$baudrate $othbootargs;"   \
> 861 "setenv ramdiskaddr 0x0200;"\
> 862 "setenv fdtaddr 0x00c0;"\
> 863 "setenv loadaddr 0x100;"\
> 864 "bootm $loadaddr $ramdiskaddr $fdtaddr"
> 
> Because the "setenv"  will be executed  , So the variable could be extended.

I see what you mean. I am trying to reduce the environmental variables.
Do you need the variable "mtdparts"?
Would it be a better idea to set bootargs using the bootcmd?

While you are on it, I suggest you take a look at other variables.
"console=ttyAMA0,38400n8" is wrong here.

We don't have to copy kernel image from NOR flash to DDR if the ramdisk load
address is set properly in its file. So you can remove the copying from bootcmd.

York

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

Re: [U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On Wed, Apr 6, 2016 at 11:46 AM, Marek Vasut  wrote:
> If this is about disabling PL310 (L2 cache controller), then I already
> tried that. It did not help :(
>

Yes, it is...I'll continue to troll around some more.

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

Re: [U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/06/2016 06:35 PM, Dinh Nguyen wrote:
> On Wed, Mar 23, 2016 at 10:37 AM, Stefan Roese  wrote:
>>
>> I can't really comment on the USB problem, as I've only seen this
>> d-cache / S-bit problem with SPI NOR flash. This is because I've never
>> really used USB on this platform intensively. But I'm nearly 100%
>> sure, that all changes that add some delays (or debug printfs)
>> resulting in a "working solution", either in the USB case or the SPI
>> NOR case, are just papering over the real problem.
>>
> 
> After a quick chat with Mark Rutland here at ELC, he alluded that there
> could be a problem with the PL310 interfering with the L1 DCACHE. I won't
> be able to try it until I get back, but perhaps somebody can test turning
> off the PL310?
> 
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -78,7 +78,6 @@
>   * Cache
>   */
>  #define CONFIG_SYS_CACHELINE_SIZE 32
> -#define CONFIG_SYS_L2_PL310
>  #define CONFIG_SYS_PL310_BASE  SOCFPGA_MPUL2_ADDRESS
> 
>  Dinh
> 
If this is about disabling PL310 (L2 cache controller), then I already
tried that. It did not help :(

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

Re: [U-Boot] FPGA detection failure on Cyclone V soc development kit

[Marek Vasut]

On 04/06/2016 05:29 PM, Dinh Nguyen wrote:
> On Wed, Apr 6, 2016 at 10:07 AM, Marek Vasut  wrote:
>>
>> I pushed some DDR fixes into u-boot-socfpga/ddr branch [1], which fixed
>> DDR calibration issue on a board I have in here. Can you try them ? Thanks
>>
>> [1]
>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>
> 
> I'll do it first thing when I get back from ELC.

Cool. I will do proper submission by then. I think Mans had a CV SoCDK
which didn't boot with the mainline SPL, so it'd be cool if he could try.

btw. I regret not being able to go to ELC quite a lot :'-(

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

Re: [U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On Wed, Mar 23, 2016 at 10:37 AM, Stefan Roese  wrote:
>
> I can't really comment on the USB problem, as I've only seen this
> d-cache / S-bit problem with SPI NOR flash. This is because I've never
> really used USB on this platform intensively. But I'm nearly 100%
> sure, that all changes that add some delays (or debug printfs)
> resulting in a "working solution", either in the USB case or the SPI
> NOR case, are just papering over the real problem.
>

After a quick chat with Mark Rutland here at ELC, he alluded that there
could be a problem with the PL310 interfering with the L1 DCACHE. I won't
be able to try it until I get back, but perhaps somebody can test turning
off the PL310?

--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -78,7 +78,6 @@
  * Cache
  */
 #define CONFIG_SYS_CACHELINE_SIZE 32
-#define CONFIG_SYS_L2_PL310
 #define CONFIG_SYS_PL310_BASE  SOCFPGA_MPUL2_ADDRESS

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

Re: [U-Boot] FPGA detection failure on Cyclone V soc development kit

[Phil Reid]

On 6/04/2016 11:07 PM, Marek Vasut wrote:

On 01/27/2016 03:18 PM, Måns Rullgård wrote:

Chin Liang See  writes:


On Wed, 2016-01-27 at 13:46 +, Måns Rullgård wrote:

Chin Liang See  writes:


On Fri, 2016-01-22 at 10:35 -0600, Dinh Nguyen wrote:

On 01/21/2016 10:31 AM, Marek Vasut wrote:

On Thursday, January 21, 2016 at 05:20:33 PM, Måns Rullgård
wrote:

Tom Rini  writes:

On Wed, Jan 20, 2016 at 08:31:30PM +, Måns Rullgård
wrote:

I'm having a problem with u-boot 2016.01 failing to
detect the FPGA on my Altera Cyclone V SoC Development
Kit.  On startup, it simply prints "FPGA: Not Altera chip
ID" (the ID having been read as all -zero).  No amount of
messing with jumpers or switches makes a difference.  The
software on the SD card included in the box appears to
work, so on a whim I took the SPL pre-loader from this
card and combined it with the main 2016.01 u-boot.  This
makes the detection succeed, despite Marek baulking at
this idea.  The "good" SPL identifies as "U-Boot SPL
2013.01.01 (Dec 04 2014 - 08:59:41)" which is a different
build date than the main u-boot on the same SD card, so
which source code version it was built from is anyone's
guess.

What's interesting is that Marek's board works with u
-boot 2016.01 while mine fails even with the very same
binary.  The boards are different revisions (his
100-0321003-C1, mine -E1), and the main Cyclone V chips
are also different (his 5CSXFC6D6F31C8NES, mine
5CSXFC6D6F31C6N).

Any suggestions for what to try next?

  v2016.01 release or to of tree?  If top of tree, try
http://patchwork.ozlabs.org/patch/570009/

  Tried release, top of tree, and top of tree with that patch.
Nothing works.


Both part number is different in speed grade. This is first time I
heard about this issue. A quick suspect might due to clock. Can you
try to copy pll_config.h that is passing (from 2013.01.01) and
replace
the one in 2016?


That doesn't work at all.  Now it fails to detect the FPGA, then
hangs after printing the amount of DRAM.


This is sorta similar to what I see with my SocDK occasionally.
Sometimes rints ram and then hangs, other timmes fails to find mmc.
As I mentioned in other email.



Can you share with me the pll_config for 2013.01.01 that is working for
you?


I don't know that it is.  The only thing I've found to work is the
unidentified SPL on the SD card that came with the dev kit.


I pushed some DDR fixes into u-boot-socfpga/ddr branch [1], which fixed
DDR calibration issue on a board I have in here. Can you try them ? Thanks

[1]
http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr




--
Regards
Phil Reid

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

Re: [U-Boot] [PATCH] WIP: Example changes to build EFI stub for x86

[Nicolae Rosia]

Hi,

On Wed, Apr 6, 2016 at 6:06 PM, Simon Glass  wrote:
> Currently it is not possible to build the 64-bit EFI stub due to changes in
> the build. To prevent future bit rot, we should add  target for building
> qemu-x86 as an EFI stub (with U-Boot as a 32-bit payload).
>
> This patch provides some hints.
>
> Reported-by: Nicolae Rosia 
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/types.h | 12 
>  configs/qemu-x86_defconfig   |  3 +++
>  include/efi.h|  2 +-
>  lib/efi/efi_stub.c   |  6 +++---
>  4 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/include/asm/types.h b/arch/x86/include/asm/types.h
> index 766617f..998d70a 100644
> --- a/arch/x86/include/asm/types.h
> +++ b/arch/x86/include/asm/types.h
> @@ -44,11 +44,15 @@ typedef __INT64_TYPE__ s64;
>  typedef __UINT64_TYPE__ u64;
>  #endif
>
> -#ifdef CONFIG_EFI_STUB_64BIT
> -#define BITS_PER_LONG 64
> -#else
> +/*
> + * This should be defined only when compiling the stub - see the
> + * ecmd_u-boot_payload build rule
> + */
Are you saying that I should take a look at cmd_u-boot_payload in Makefile?
I've looked over it and I don't figure out what I should see.

> +// #ifdef CONFIG_EFI_STUB_64BIT
> +// #define BITS_PER_LONG 64
> +// #else
>  #define BITS_PER_LONG 32
> -#endif
> +// #endif
This fixes the compilation warnings

>  /* Dma addresses are 32-bits wide.  */
>
>  typedef u32 dma_addr_t;
> diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
> index bb9c6cd..2a7087f 100644
> --- a/configs/qemu-x86_defconfig
> +++ b/configs/qemu-x86_defconfig
> @@ -32,3 +32,6 @@ CONFIG_VIDEO_VESA=y
>  CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
>  CONFIG_FRAMEBUFFER_VESA_MODE_111=y
>  CONFIG_USE_PRIVATE_LIBGCC=y
> +CONFIG_EFI=y
> +CONFIG_EFI_STUB=y
> +CONFIG_EFI_STUB_64BIT=y
Should we create an example defconfig for efi stub and not modify the
qemu defconfig?

> diff --git a/include/efi.h b/include/efi.h
> index 1dbc3b7..21921f1 100644
> --- a/include/efi.h
> +++ b/include/efi.h
> @@ -278,7 +278,7 @@ struct efi_priv {
>  extern char image_base[];
>
>  /* Start and end of U-Boot image (for payload) */
> -extern char _binary_u_boot_dtb_bin_start[], _binary_u_boot_dtb_bin_end[];
> +extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
>
>  /**
>   * efi_get_sys_table() - Get access to the main EFI system table
> diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
> index 8b4bb4e..1814960 100644
> --- a/lib/efi/efi_stub.c
> +++ b/lib/efi/efi_stub.c
> @@ -354,9 +354,9 @@ efi_status_t efi_main(efi_handle_t image, struct 
> efi_system_table *sys_table)
> /* The EFI UART won't work now, switch to a debug one */
> use_uart = true;
>
> -   memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_dtb_bin_start,
> -  (ulong)_binary_u_boot_dtb_bin_end -
> -  (ulong)_binary_u_boot_dtb_bin_start);
> +   memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_bin_start,
> +  (ulong)_binary_u_boot_bin_end -
> +  (ulong)_binary_u_boot_bin_start);
>
Thanks, these fixes the compilation errors.

>  #ifdef DEBUG
> puts("EFI table at ");
> --
> 2.8.0.rc3.226.g39d4020
>

I'll try to boot test.

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

Re: [U-Boot] Fwd: Marvell Armada XP u-boot from uart

[PA Nilsson]

On 2016-04-06 16:46, Stefan Roese wrote:

On 06.04.2016 12:20, pani wrote:

I have a Armada A388 board that I have the same problem with.
(Using u-boot git master branch from today)

After downloading the kwb-file, the output is as below.
This is the same with the BOOT_FROM untouched or set to uart.

Did you have any luck finding out what the problem was?

Sending boot message. Please reboot the target...-
Sending boot image...
   0 %
[..]
   1 %
[..]
   3 %
[..]
   5 %
[..]
   6 %
[..]
   8 %
[..]
  10 %
[..]
  12 %
[..]
  13 %
[..]
  15 %
[..]
  17 %
[..]
  18 %
[..]
  20 %
[..]
  22 %
[..]
  24 %
[..]
  25 %
[..]
  27 %
[..]
  29 %
[..]
  30 % [...
U-Boot SPL 2016.03-00668-g4ed6ed3-dirty (Apr 06 2016 - 11:00:55)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
  | Lane #  | Speed |  Type   |
  
  |   0|  3   |  SATA0 |
  |   1|  0   |  SGMII1 |
  |   2|  5   |  PCIe1 |
  |   3|  5   |  USB3 HOST1 |
  |   4|  5   |  PCIe2 |
  |   5|  0   |  SGMII2 |
  
PCIe, Idx 1: detected no link
PCIe, Idx 2: detected no link
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.29.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
Trying to boot from unknown boot device
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
+xmodem: Protocol error


Which board is this? Is it a custom Armada 38x board? Or an
already in mainline U-Boot supported board?

The message above is pretty clear:

> SPL: Unsupported Boot Device!

What is the boot device that you are using? And how are you
initiating the UART boot? Via a software reset (JTAG)? Or
via a power-on reset?

Note:
In general the UART boot does work pretty good. I've not had
problems with it in the last months (AFAIR).

Thanks,
Stefan
This is a Solidrun Clearfog Pro board, but the module has eMMC on it so 
the sd-card is not available.
In the example print above the dip-switches are set to "uart boot" and 
it is done from a power on reset.


Regards,
PA

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

Re: [U-Boot] FPGA detection failure on Cyclone V soc development kit

[Dinh Nguyen]

On Wed, Apr 6, 2016 at 10:07 AM, Marek Vasut  wrote:
>
> I pushed some DDR fixes into u-boot-socfpga/ddr branch [1], which fixed
> DDR calibration issue on a board I have in here. Can you try them ? Thanks
>
> [1]
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>

I'll do it first thing when I get back from ELC.

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

Re: [U-Boot] [PATCH] mmc:fsl_esdhc: fix invalidate dcache scope

[York Sun]

On 04/06/2016 03:22 AM, Shengzhou Liu wrote:
> commit 4683b220655 "mmc:fsl_esdhc invalidate dcache before read"
> intended for ARM, which broke on PowerPC(caused memory allocation
> failure under SD boot), so add condition CONFIG_ARM.
> 
> Signed-off-by: Shengzhou Liu 
> ---
>  drivers/mmc/fsl_esdhc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 7cc61a0..7812e6c 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -348,8 +348,10 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
> struct mmc_data *data)
>   if(err)
>   return err;
>  
> +#ifdef CONFIG_ARM
>   if (data->flags & MMC_DATA_READ)
>   check_and_invalidate_dcache_range(cmd, data);
> +#endif
>   }
>  
>   /* Figure out the transfer arguments */
> 

Shenghzou,

This is not a correct fix. This issue is related to

http://lists.denx.de/pipermail/u-boot/2015-December/236272.html
http://lists.denx.de/pipermail/u-boot/2016-March/249377.html

In short, the invalidate_dcache_range function was added for
512x/5xxx/83xx/85xx. Although it shouldn't do any harm, it actually does. I
haven't got a chance to investigate. Please look into it if you can.

York

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

Re: [U-Boot] [PATCH 1/2] arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) with asm code

[Tom Rini]

On Wed, Apr 06, 2016 at 05:22:25PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 06-04-16 16:51, Tom Rini wrote:
> >On Mon, Apr 04, 2016 at 08:31:48PM +0200, Hans de Goede wrote:
> >
> >>v7_maint_dcache_all() does not work reliable when build with gcc6,
> >>see: https://bugzilla.redhat.com/show_bug.cgi?id=1318788
> >>
> >>While debugging this I learned that v7_maint_dcache_all() is unreliable
> >>when build with gcc5 too when it is marked as noinline.
> >>
> >>This commit fixes the reliability issues by replacing the C-code with
> >>the ready to use asm implementation from the kernel.
> >>
> >>Given that this code when written as C-code clearly is quite fragile
> >>(also see the existing comments about the C-code being the way it is
> >>  to get optimal assembly) and that we have a proven asm alternative,
> >>I believe that this is the best solution.
> >>
> >>Note that we actually already have a copy of the kernel's
> >>v7_flush_dcache_all() in arch/arm/mach-uniphier/arm32/lowlevel_init.S.
> >>
> >>We should replace that implementation with a call to this one, but I'm
> >>leaving this up to people with access to actual unifier hw. With this
> >>replacement in mind I've kept the original function as is, only renamed
> >>it to __v7_flush_dcache_all and v7_flush_dcache_all is a wrapper
> >>saving the registered clobbered by the core __v7_flush_dcache_all code
> >>
> >>Signed-off-by: Hans de Goede 
> >
> >So I was able to talk with a few people and this is the right approach.
> >The cache routines we're doing here in C must not in fact be done in C.
> >That things work today with some compilers is not by design.  This is at
> >least a minimally correct thing to do and a more correct thing to do
> >would be to leverage more of the code from the kernel for cache
> >functions (and not just for v7).
> 
> Thanks! I guess that means that we can consider this issue resolved?
> Which is good news as this was a nasty bug to track down.

Yes it was, good job btw.

> So are you planning on merging this patch / these 2 patches to
> master then ?
> 
> Note that in my testing only the first patch is necessary to fix
> various sunxi boards no longer booting.

We need at least a v2 to fix the build issue Masahiro pointed out.  But
yes, I'll tkae these two and put the rest on my TODO list.  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] Ethernet via USB on Sinlinx SinA33

[Hans de Goede]

Hi,

On 29-03-16 08:38, Quentin Schulz wrote:

Hi,

On 28/03/2016 14:56, Hans de Goede wrote:

Hi,

On 25-03-16 18:14, Quentin Schulz wrote:

Hi,

I am trying to get Ethernet to work through the USB port of the Sinlinx
SinA33 on U-Boot to use TFTP to get the kernel and dtb files.

However, I am getting 'data abort' when using dhcp or tftp after adding:
#define CONFIG_USB_HOST_ETHER
#define CONFIG_USB_ETHER_ASIX

to include/configs/sunxi-common.h and checking CONFIG_USB_EHCI_HCD as
told in the documentation [1]

I tested this configuration with the C.H.I.P. and it is working well.


Are you perhaps building u-boot with gcc6 ? There are some known issues
when building u-boot with gcc-6, which look pretty much like this.


No, I'm building with gcc-5:
$ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu 5.2.1-22ubuntu1) 5.2.1 20151010


Is the ethernet adapter connected to a regular usb host port, or to
the otg port ?


The Ethernet adapter is connected to the regular USB host port.


So I've been debugging some armv7 cache issues lately and I've come
up with the following fix:

https://patchwork.ozlabs.org/patch/605967/

This might very will fix your issue too. If not we're likely missing
some cache flushing / invalidation in the usb driver for your usb
host controller.

Regards,

Hans




Regards,

Quentin



Steps to reproduce:

1) Add the following lines to include/configs/sunxi-common.h:

#define CONFIG_USB_HOST_ETHER
#define CONFIG_USB_ETHER_ASIX

2) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
Sinlinx_SinA33_defconfig
3) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
4) Check CONFIG_USB_EHCI_HC and save configuration
5) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)
6) Prepare SDCard:
sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8
7) Boot the board and run dhcp or tftp
8) Get 'data abort' and board gets reset (ethact is also not defined)

The log file is attached.

Thank you,

Quentin

[1] https://github.com/lentinj/u-boot/blob/master/doc/README.usb#L132


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

Re: [U-Boot] [PATCH 1/2] arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) with asm code

[Hans de Goede]

Hi,

On 06-04-16 16:51, Tom Rini wrote:

On Mon, Apr 04, 2016 at 08:31:48PM +0200, Hans de Goede wrote:


v7_maint_dcache_all() does not work reliable when build with gcc6,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1318788

While debugging this I learned that v7_maint_dcache_all() is unreliable
when build with gcc5 too when it is marked as noinline.

This commit fixes the reliability issues by replacing the C-code with
the ready to use asm implementation from the kernel.

Given that this code when written as C-code clearly is quite fragile
(also see the existing comments about the C-code being the way it is
  to get optimal assembly) and that we have a proven asm alternative,
I believe that this is the best solution.

Note that we actually already have a copy of the kernel's
v7_flush_dcache_all() in arch/arm/mach-uniphier/arm32/lowlevel_init.S.

We should replace that implementation with a call to this one, but I'm
leaving this up to people with access to actual unifier hw. With this
replacement in mind I've kept the original function as is, only renamed
it to __v7_flush_dcache_all and v7_flush_dcache_all is a wrapper
saving the registered clobbered by the core __v7_flush_dcache_all code

Signed-off-by: Hans de Goede 


So I was able to talk with a few people and this is the right approach.
The cache routines we're doing here in C must not in fact be done in C.
That things work today with some compilers is not by design.  This is at
least a minimally correct thing to do and a more correct thing to do
would be to leverage more of the code from the kernel for cache
functions (and not just for v7).


Thanks! I guess that means that we can consider this issue resolved?
Which is good news as this was a nasty bug to track down.

So are you planning on merging this patch / these 2 patches to
master then ?

Note that in my testing only the first patch is necessary to fix
various sunxi boards no longer booting.

Regards,

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

Re: [U-Boot] [PATCH] board: ge: bx50v3: Update display setup

[Fabio Estevam]

On Wed, Apr 6, 2016 at 12:18 PM, Stefano Babic  wrote:

> I frankly ask you if you think that this function can be factorized and
> moved from board code to common code. What do you think ? Is there
> something that let the implementation bound to the board (I have not
> seen it) ?

Agreed. This should be in common code so that other boards can use it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board: ge: bx50v3: Update display setup

[Stefano Babic]

Hi Akshay,

On 15/03/2016 19:10, Akshay Bhat wrote:
> Implements the below changes:
> - Disable LVDS1 on B450v3/B650v3 boards since the final boards no longer
> have connectors for the same. Only LVDS0 hardware connectors are present.
> - Implement imx6 EB821 or ERR009219 errata for LVDS clock switch.
> This patch was ported from Freescale 3.10.17_1.0.0_ga kernel to u-boot.
> - Split the display setup into 2 different functions. One for B850v3 that
> does a setup of LVDS and HDMI with clock source for LVDS/IPU_DI set to
> video PLL. The other for B450v3/B650v3 that does a setup of LVDS only with
> clock source for LVDS/IPU_DI set to USB PLL. This helps us generate
> accurate pixel clock required for display connected to LVDS.

I propose you split your patch exactly as you describe in the commit
message into 3 patches.

Generally, a patch/patchset should address a single issue. This lets to
better understand the workarounf with MMDC handshake, and let use it on
other boards too.

> 
> Signed-off-by: Akshay Bhat 
> Cc: Stefano Babic 
> ---
>  board/ge/bx50v3/bx50v3.c | 240 
> ++-
>  1 file changed, 198 insertions(+), 42 deletions(-)
> 
> diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
> index 70c298d..cf2cd1a 100644
> --- a/board/ge/bx50v3/bx50v3.c
> +++ b/board/ge/bx50v3/bx50v3.c
> @@ -390,55 +390,208 @@ struct display_info_t const displays[] = {{
>  } } };
>  size_t display_count = ARRAY_SIZE(displays);
>  
> -static void setup_display(void)
> +static void enable_videopll(void)
> +{
> + struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> + s32 timeout = 10;
> +
> + setbits_le32(&ccm->analog_pll_video, BM_ANADIG_PLL_VIDEO_POWERDOWN);
> +
> + /* set video pll to 910MHz (24MHz * (37+11/12))
> +  * video pll post div to 910/4 = 227.5MHz
> +  */
> + clrsetbits_le32(&ccm->analog_pll_video,
> + BM_ANADIG_PLL_VIDEO_DIV_SELECT |
> + BM_ANADIG_PLL_VIDEO_POST_DIV_SELECT,
> + BF_ANADIG_PLL_VIDEO_DIV_SELECT(37) |
> + BF_ANADIG_PLL_VIDEO_POST_DIV_SELECT(0));
> +
> + writel(BF_ANADIG_PLL_VIDEO_NUM_A(11), &ccm->analog_pll_video_num);
> + writel(BF_ANADIG_PLL_VIDEO_DENOM_B(12), &ccm->analog_pll_video_denom);
> +
> + clrbits_le32(&ccm->analog_pll_video, BM_ANADIG_PLL_VIDEO_POWERDOWN);
> +
> + while (timeout--)
> + if (readl(&ccm->analog_pll_video) & BM_ANADIG_PLL_VIDEO_LOCK)
> + break;
> + if (timeout < 0)
> + printf("Warning: video pll lock timeout!\n");
> +
> + clrsetbits_le32(&ccm->analog_pll_video,
> + BM_ANADIG_PLL_VIDEO_BYPASS,
> + BM_ANADIG_PLL_VIDEO_ENABLE);
> +}
> +
> +static void set_ldb_clock_source(u8 source)
>  {
>   struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> - struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR;
>   int reg;
> + /*
> +  * Need to follow a strict procedure when changing the LDB
> +  * clock, else we can introduce a glitch. Things to keep in
> +  * mind:
> +  * 1. The current and new parent clocks must be disabled.
> +  * 2. The default clock for ldb_dio_clk is mmdc_ch1 which has
> +  * no CG bit.
> +  * 3. In the RTL implementation of the LDB_DI_CLK_SEL mux
> +  * the top four options are in one mux and the PLL3 option along
> +  * with another option is in the second mux. There is third mux
> +  * used to decide between the first and second mux.
> +  * The code below switches the parent to the bottom mux first
> +  * and then manipulates the top mux. This ensures that no glitch
> +  * will enter the divider.
> +  *
> +  * Need to disable MMDC_CH1 clock manually as there is no CG bit
> +  * for this clock. The only way to disable this clock is to move
> +  * it to pll3_sw_clk and then to disable pll3_sw_clk
> +  * Make sure periph2_clk2_sel is set to pll3_sw_clk
> +  */
> + /* Set MMDC_CH1 mask bit */
> + reg = readl(&mxc_ccm->ccdr);
> + reg |= MXC_CCM_CCDR_MMDC_CH1_HS_MASK;
> + writel(reg, &mxc_ccm->ccdr);
> +
> + /* Set periph2_clk2_sel to be sourced from PLL3_sw_clk */
> + reg = readl(&mxc_ccm->cbcmr);
> + reg &= ~MXC_CCM_CBCMR_PERIPH2_CLK2_SEL;
> + writel(reg, &mxc_ccm->cbcmr);
> +
> + /*
> +  * Set the periph2_clk_sel to the top mux so that
> +  * mmdc_ch1 is from pll3_sw_clk.
> +  */
> + reg = readl(&mxc_ccm->cbcdr);
> + reg |= MXC_CCM_CBCDR_PERIPH2_CLK_SEL;
> + writel(reg, &mxc_ccm->cbcdr);
> +
> + /* Wait for the clock switch */
> + while (readl(&mxc_ccm->cdhipr))
> + ;
> + /* Disable pll3_sw_clk by selecting bypass clock source */
> + reg = readl(&mxc_ccm->ccsr);
> + reg |= MXC_CCM_CCSR_PLL3_SW_CLK_SEL;
> + writel(reg, &mxc_ccm->ccsr);
> +
> + /* Set the ldb_di0_clk and ldb_di1_

Re: [U-Boot] FPGA detection failure on Cyclone V soc development kit

[Marek Vasut]

On 01/27/2016 03:18 PM, Måns Rullgård wrote:
> Chin Liang See  writes:
> 
>> On Wed, 2016-01-27 at 13:46 +, Måns Rullgård wrote:
>>> Chin Liang See  writes:
>>>
 On Fri, 2016-01-22 at 10:35 -0600, Dinh Nguyen wrote:
> On 01/21/2016 10:31 AM, Marek Vasut wrote:
>> On Thursday, January 21, 2016 at 05:20:33 PM, Måns Rullgård
>> wrote:
>>> Tom Rini  writes:
 On Wed, Jan 20, 2016 at 08:31:30PM +, Måns Rullgård
 wrote:
> I'm having a problem with u-boot 2016.01 failing to
> detect the FPGA on my Altera Cyclone V SoC Development
> Kit.  On startup, it simply prints "FPGA: Not Altera chip
> ID" (the ID having been read as all -zero).  No amount of
> messing with jumpers or switches makes a difference.  The
> software on the SD card included in the box appears to
> work, so on a whim I took the SPL pre-loader from this
> card and combined it with the main 2016.01 u-boot.  This
> makes the detection succeed, despite Marek baulking at
> this idea.  The "good" SPL identifies as "U-Boot SPL
> 2013.01.01 (Dec 04 2014 - 08:59:41)" which is a different
> build date than the main u-boot on the same SD card, so
> which source code version it was built from is anyone's
> guess.
>
> What's interesting is that Marek's board works with u
> -boot 2016.01 while mine fails even with the very same
> binary.  The boards are different revisions (his
> 100-0321003-C1, mine -E1), and the main Cyclone V chips
> are also different (his 5CSXFC6D6F31C8NES, mine
> 5CSXFC6D6F31C6N).
>
> Any suggestions for what to try next?
  v2016.01 release or to of tree?  If top of tree, try
 http://patchwork.ozlabs.org/patch/570009/
>>>  Tried release, top of tree, and top of tree with that patch.
>>> Nothing works.

 Both part number is different in speed grade. This is first time I
 heard about this issue. A quick suspect might due to clock. Can you
 try to copy pll_config.h that is passing (from 2013.01.01) and
 replace
 the one in 2016?
>>>
>>> That doesn't work at all.  Now it fails to detect the FPGA, then
>>> hangs after printing the amount of DRAM.
>>
>> Can you share with me the pll_config for 2013.01.01 that is working for
>> you?
> 
> I don't know that it is.  The only thing I've found to work is the
> unidentified SPL on the SD card that came with the dev kit.

I pushed some DDR fixes into u-boot-socfpga/ddr branch [1], which fixed
DDR calibration issue on a board I have in here. Can you try them ? Thanks

[1]
http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr

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

[U-Boot] [PATCH] WIP: Example changes to build EFI stub for x86

[Simon Glass]

Currently it is not possible to build the 64-bit EFI stub due to changes in
the build. To prevent future bit rot, we should add  target for building
qemu-x86 as an EFI stub (with U-Boot as a 32-bit payload).

This patch provides some hints.

Reported-by: Nicolae Rosia 
Signed-off-by: Simon Glass 
---

 arch/x86/include/asm/types.h | 12 
 configs/qemu-x86_defconfig   |  3 +++
 include/efi.h|  2 +-
 lib/efi/efi_stub.c   |  6 +++---
 4 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/types.h b/arch/x86/include/asm/types.h
index 766617f..998d70a 100644
--- a/arch/x86/include/asm/types.h
+++ b/arch/x86/include/asm/types.h
@@ -44,11 +44,15 @@ typedef __INT64_TYPE__ s64;
 typedef __UINT64_TYPE__ u64;
 #endif
 
-#ifdef CONFIG_EFI_STUB_64BIT
-#define BITS_PER_LONG 64
-#else
+/*
+ * This should be defined only when compiling the stub - see the
+ * ecmd_u-boot_payload build rule
+ */
+// #ifdef CONFIG_EFI_STUB_64BIT
+// #define BITS_PER_LONG 64
+// #else
 #define BITS_PER_LONG 32
-#endif
+// #endif
 /* Dma addresses are 32-bits wide.  */
 
 typedef u32 dma_addr_t;
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index bb9c6cd..2a7087f 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -32,3 +32,6 @@ CONFIG_VIDEO_VESA=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_111=y
 CONFIG_USE_PRIVATE_LIBGCC=y
+CONFIG_EFI=y
+CONFIG_EFI_STUB=y
+CONFIG_EFI_STUB_64BIT=y
diff --git a/include/efi.h b/include/efi.h
index 1dbc3b7..21921f1 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -278,7 +278,7 @@ struct efi_priv {
 extern char image_base[];
 
 /* Start and end of U-Boot image (for payload) */
-extern char _binary_u_boot_dtb_bin_start[], _binary_u_boot_dtb_bin_end[];
+extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
 
 /**
  * efi_get_sys_table() - Get access to the main EFI system table
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index 8b4bb4e..1814960 100644
--- a/lib/efi/efi_stub.c
+++ b/lib/efi/efi_stub.c
@@ -354,9 +354,9 @@ efi_status_t efi_main(efi_handle_t image, struct 
efi_system_table *sys_table)
/* The EFI UART won't work now, switch to a debug one */
use_uart = true;
 
-   memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_dtb_bin_start,
-  (ulong)_binary_u_boot_dtb_bin_end -
-  (ulong)_binary_u_boot_dtb_bin_start);
+   memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_bin_start,
+  (ulong)_binary_u_boot_bin_end -
+  (ulong)_binary_u_boot_bin_start);
 
 #ifdef DEBUG
puts("EFI table at ");
-- 
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] board: ge: bx50v3: Use pwm for display backlight

[Stefano Babic]

Hi Akshay,

On 06/04/2016 16:39, Akshay Bhat wrote:
> 
> On Tue, Mar 15, 2016 at 2:24 PM, Akshay Bhat  > wrote:
> 
> Setup the LCD backlight brightness control pin to use PWM
> 
> Signed-off-by: Akshay Bhat  >
> Cc: Stefano Babic mailto:sba...@denx.de>>
> ---
> 
> 
> Hi Stefano,
> 
> Can this be applied if there are no review comments?
> 

This is straightforward and can be applied - but I am afraid you need
this just if "Update display setup" is applied.

I have some minor changes to ask for that, I am sending my review.

Best regards,
Stefano

> Thanks,
> Akshay
>  
> 
>  board/ge/bx50v3/bx50v3.c| 11 +++
>  include/configs/ge_bx50v3.h |  3 +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
> index cf2cd1a..8e55acf 100644
> --- a/board/ge/bx50v3/bx50v3.c
> +++ b/board/ge/bx50v3/bx50v3.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  DECLARE_GLOBAL_DATA_PTR;
> 
>  #define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
> @@ -324,6 +325,8 @@ static iomux_v3_cfg_t const backlight_pads[] = {
> /* Backlight enable for LVDS display */
> MX6_PAD_GPIO_0__GPIO1_IO00 | MUX_PAD_CTRL(NO_PAD_CTRL),
>  #define LVDS_BACKLIGHT_GP IMX_GPIO_NR(1, 0)
> +   /* backlight PWM brightness control */
> +   MX6_PAD_SD1_DAT3__PWM1_OUT | MUX_PAD_CTRL(NO_PAD_CTRL),
>  };
> 
>  static void do_enable_hdmi(struct display_info_t const *dev)
> @@ -676,9 +679,17 @@ int board_late_init(void)
>  * as per specifications from CHI MEI */
> mdelay(250);
> 
> +   /* enable backlight PWM 1 */
> +   pwm_init(0, 0, 0);
> +
> +   /* duty cycle 500ns, period: 500ns */
> +   pwm_config(0, 500, 500);
> +
> /* Backlight Power */
> gpio_direction_output(LVDS_BACKLIGHT_GP, 1);
> 
> +   pwm_enable(0);
> +
> return 0;
>  }
> 
> diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
> index 6fa4a9a..e37cd33 100644
> --- a/include/configs/ge_bx50v3.h
> +++ b/include/configs/ge_bx50v3.h
> @@ -327,6 +327,9 @@
>  #define CONFIG_IMX_HDMI
>  #define CONFIG_IMX_VIDEO_SKIP
> 
> +#define CONFIG_PWM_IMX
> +#define CONFIG_IMX6_PWM_PER_CLK6600
> +
>  #undef CONFIG_CMD_PCI
>  #ifdef CONFIG_CMD_PCI
>  #define CONFIG_PCI
> --
> 2.7.3
> 
> 


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

On 6/04/2016 7:51 PM, Marek Vasut wrote:

On 04/06/2016 09:00 AM, Phil Reid wrote:

On 6/04/2016 6:03 AM, Marek Vasut wrote:

On 04/05/2016 10:33 AM, Phil Reid wrote:

On 27/03/2016 4:52 AM, Marek Vasut wrote:

On 03/22/2016 06:06 PM, Dinh Nguyen wrote:



On 03/20/2016 11:42 AM, Marek Vasut wrote:


Sorry, I know that doesn't help. So let's walk through my workflow.
I am
not using any Altera tools when I build.

$make socfpga_de0_nano_soc_defconfig
$make u-boot-with-spl.sfp
$dd if=u-boot-with-spl.sfp of=/dev/sdb3

My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1)
4.7.3

Has the board ever worked for you at all? Can you try this image:

https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage



Dinh


I just ported U-Boot to another customer board. I noticed QSPI has
problems and USB can be flaky. That's the standard cache issue we
have, disabling dcache fixed that.

I am starting to wonder whether we're hitting some corner case here.
Maybe we should eventually try and trace all the register reads and
writes generated by the DDR calibration code both in old and new SPL
and make a diff to see if something really did change.

Dinh, can you share the marking on the SoC and the DRAMs on your
board?



My SoC is:

5CSEMA4U23C6N
CACAU1525A

DRAMs are:

ISSI 1510
IS43TR16256A
15HBL K080
P4482100QER2 TWN


Thanks, that's indeed rev. C . About time I bang my head against the
desk because this is creepy.



FYI

I've just spend some time trying to update the spl / uboot / kernel &
rootfs image on our
Altera socdk to use for some software testing / development.
Unfortunately it fails in the mem calibration process with the latest
uboot most of the time.
And when it does boot somtimes fails loading uboot fomr the mmc.


Try this u-boot-socfpga/ddr branch [1] , see if it works for you.

[1]
http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr




Spent a bit of time on it and things are very weird. So far no luck
booting with the ddr branch.
I got the memory calibration to pass but then had problems with loading
uboot. Using the mmc.
Say no device found for the mmc. error -19.


Which board is this ? How wide is the MMC data bus ?


When I try to add some extra debug in things fall over.
Sometimes just hangs in the Memory cal (and not changing anything there).
Then sometimes I get missing DTB.
I found the uboot-with-spl.sfp file generated by the latest uboot tree
and tried burning that with
same results.

Reverted back to the image available on rocketboards and wrote that to
the card.
Thinking something strange with the card (thou I tried several) and that
works fine.
Sourced from
https://rocketboards.org/foswiki/view/Documentation/AlteraSoCDevelopmentBoard


Are you actually using the SoCDK or some custom board ?


I've got two boards here.
The Altera Cyclone V SoC FPGA Development Kit Board RevC
which is the SocDK right?
And our own board design.

Our design works fine with new uboot's.
Just can't get things to work with the dek kit.
It's fairly similar to the SocDK

I'm building two different version of uboot.
Using the two different qts generated files.
I've setup a separate defconfig / dts and board config for our board.

I'd really like to find the quartus project that was used to generate
the qts files committed into the uboot tree. All the ones I've used so
far have different ddr timing and pin configs!

--
Regards
Phil Reid

ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au

3 The Avenue, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 7100
Email: pr...@electromag.com.au
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) with asm code

[Tom Rini]

On Mon, Apr 04, 2016 at 08:31:48PM +0200, Hans de Goede wrote:

> v7_maint_dcache_all() does not work reliable when build with gcc6,
> see: https://bugzilla.redhat.com/show_bug.cgi?id=1318788
> 
> While debugging this I learned that v7_maint_dcache_all() is unreliable
> when build with gcc5 too when it is marked as noinline.
> 
> This commit fixes the reliability issues by replacing the C-code with
> the ready to use asm implementation from the kernel.
> 
> Given that this code when written as C-code clearly is quite fragile
> (also see the existing comments about the C-code being the way it is
>  to get optimal assembly) and that we have a proven asm alternative,
> I believe that this is the best solution.
> 
> Note that we actually already have a copy of the kernel's
> v7_flush_dcache_all() in arch/arm/mach-uniphier/arm32/lowlevel_init.S.
> 
> We should replace that implementation with a call to this one, but I'm
> leaving this up to people with access to actual unifier hw. With this
> replacement in mind I've kept the original function as is, only renamed
> it to __v7_flush_dcache_all and v7_flush_dcache_all is a wrapper
> saving the registered clobbered by the core __v7_flush_dcache_all code
> 
> Signed-off-by: Hans de Goede 

So I was able to talk with a few people and this is the right approach.
The cache routines we're doing here in C must not in fact be done in C.
That things work today with some compilers is not by design.  This is at
least a minimally correct thing to do and a more correct thing to do
would be to leverage more of the code from the kernel for cache
functions (and not just for v7).

-- 
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] Fwd: Marvell Armada XP u-boot from uart

[Stefan Roese]

On 06.04.2016 12:20, pani wrote:

I have a Armada A388 board that I have the same problem with.
(Using u-boot git master branch from today)

After downloading the kwb-file, the output is as below.
This is the same with the BOOT_FROM untouched or set to uart.

Did you have any luck finding out what the problem was?

Sending boot message. Please reboot the target...-
Sending boot image...
   0 %
[..]
   1 %
[..]
   3 %
[..]
   5 %
[..]
   6 %
[..]
   8 %
[..]
  10 %
[..]
  12 %
[..]
  13 %
[..]
  15 %
[..]
  17 %
[..]
  18 %
[..]
  20 %
[..]
  22 %
[..]
  24 %
[..]
  25 %
[..]
  27 %
[..]
  29 %
[..]
  30 % [...
U-Boot SPL 2016.03-00668-g4ed6ed3-dirty (Apr 06 2016 - 11:00:55)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
  | Lane #  | Speed |  Type   |
  
  |   0|  3   |  SATA0 |
  |   1|  0   |  SGMII1 |
  |   2|  5   |  PCIe1 |
  |   3|  5   |  USB3 HOST1 |
  |   4|  5   |  PCIe2 |
  |   5|  0   |  SGMII2 |
  
PCIe, Idx 1: detected no link
PCIe, Idx 2: detected no link
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.29.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
Trying to boot from unknown boot device
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
+xmodem: Protocol error


Which board is this? Is it a custom Armada 38x board? Or an
already in mainline U-Boot supported board?

The message above is pretty clear:

> SPL: Unsupported Boot Device!

What is the boot device that you are using? And how are you
initiating the UART boot? Via a software reset (JTAG)? Or
via a power-on reset?

Note:
In general the UART boot does work pretty good. I've not had
problems with it in the last months (AFAIR).

Thanks,
Stefan

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

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

[Tom Rini]

On Wed, Apr 06, 2016 at 03:47:07PM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull those 2 Marvell related patches.
> 
> Thanks,
> Stefan
> 
> The following changes since commit 4ed6ed3c27a069a00c8a557d606a05276cc4653e:
> 
>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze 
> (2016-04-04 14:34:09 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-marvell.git 
> 
> for you to fetch changes up to 46a16bd895144617575c788d9c2554aeef76ac44:
> 
>   kirkwood_nand: claim MPP pins on the fly (2016-04-06 15:40:33 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] imx: mx6var_som: Add support for Variscite mx6 boards

[Stefano Babic]

Hi Eran,

On 31/03/2016 15:53, Eran Matityahu wrote:
> Add support for Variscite VAR-SOM-MX6 / DART-MX6 / VAR-SOM-SOLO/DUAL boards 
> with features:
> PMIC, NAND flash, SD/MMC, USB, Ethernet, I2C, LVDS, HDMI.
> 
> Signed-off-by: Eran Matityahu 
> ---
>  arch/arm/cpu/armv7/mx6/Kconfig|7 +
>  board/variscite/mx6var_som/Kconfig|   12 +
>  board/variscite/mx6var_som/MAINTAINERS|8 +
>  board/variscite/mx6var_som/Makefile   |9 +
>  board/variscite/mx6var_som/addresses.inc  |   38 +
>  board/variscite/mx6var_som/imximage.cfg   |   13 +
>  board/variscite/mx6var_som/mx6var_eeprom.c|  320 +
>  board/variscite/mx6var_som/mx6var_eeprom.h|   88 ++
>  board/variscite/mx6var_som/mx6var_eeprom_v2.c |  231 
>  board/variscite/mx6var_som/mx6var_eeprom_v2.h |   55 +
>  board/variscite/mx6var_som/mx6var_som.c   | 1587 
> +
>  board/variscite/mx6var_som/u-boot-spl.lds |   59 +
>  board/variscite/mx6var_som/values.inc |   39 +
>  configs/mx6var_som_nand_defconfig |7 +
>  configs/mx6var_som_sd_defconfig   |7 +
>  include/configs/mx6var_som.h  |  419 +++
>  include/configs/mx6var_spl.h  |   81 ++
>  tools/logos/variscite.bmp |  Bin 0 -> 15414 bytes

This is a very big patch, just not easy to review. Is there any
possibility to split it ? I have my difficulties to review such a
monstruous patch.

Some general notes:

- SPL is automatically set. Which is the reason to have an own
imximage.cfg ? All boards use the same. You do not need to set "booting
from nand" or BOOT FROM SD", because they share the same start offset in
the storage.

- can you better explain the reason under the ddr configuration in EEPROM ?

>  18 files changed, 2980 insertions(+)
>  create mode 100644 board/variscite/mx6var_som/Kconfig
>  create mode 100644 board/variscite/mx6var_som/MAINTAINERS
>  create mode 100644 board/variscite/mx6var_som/Makefile
>  create mode 100644 board/variscite/mx6var_som/addresses.inc
>  create mode 100644 board/variscite/mx6var_som/imximage.cfg
>  create mode 100644 board/variscite/mx6var_som/mx6var_eeprom.c
>  create mode 100644 board/variscite/mx6var_som/mx6var_eeprom.h
>  create mode 100644 board/variscite/mx6var_som/mx6var_eeprom_v2.c
>  create mode 100644 board/variscite/mx6var_som/mx6var_eeprom_v2.h
>  create mode 100644 board/variscite/mx6var_som/mx6var_som.c
>  create mode 100644 board/variscite/mx6var_som/u-boot-spl.lds
>  create mode 100644 board/variscite/mx6var_som/values.inc
>  create mode 100644 configs/mx6var_som_nand_defconfig
>  create mode 100644 configs/mx6var_som_sd_defconfig
>  create mode 100644 include/configs/mx6var_som.h
>  create mode 100644 include/configs/mx6var_spl.h
>  create mode 100644 tools/logos/variscite.bmp
> 
> diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
> index c72a150..146c152 100644
> --- a/arch/arm/cpu/armv7/mx6/Kconfig
> +++ b/arch/arm/cpu/armv7/mx6/Kconfig
> @@ -115,6 +115,12 @@ config TARGET_MX6UL_14X14_EVK
>   select DM_THERMAL
>   select SUPPORT_SPL
>  
> +config TARGET_MX6VAR_SOM
> + bool "mx6var_som"
> + select SUPPORT_SPL
> + select DM
> + select DM_THERMAL
> +
>  config TARGET_NITROGEN6X
>   bool "nitrogen6x"
>  
> @@ -180,6 +186,7 @@ source "board/solidrun/mx6cuboxi/Kconfig"
>  source "board/tbs/tbs2910/Kconfig"
>  source "board/tqc/tqma6/Kconfig"
>  source "board/udoo/Kconfig"
> +source "board/variscite/mx6var_som/Kconfig"
>  source "board/wandboard/Kconfig"
>  source "board/warp/Kconfig"
>  
> diff --git a/board/variscite/mx6var_som/Kconfig 
> b/board/variscite/mx6var_som/Kconfig
> new file mode 100644
> index 000..0b82df7
> --- /dev/null
> +++ b/board/variscite/mx6var_som/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_MX6VAR_SOM
> +
> +config SYS_BOARD
> + default "mx6var_som"
> +
> +config SYS_VENDOR
> + default "variscite"
> +
> +config SYS_CONFIG_NAME
> + default "mx6var_som"
> +
> +endif
> diff --git a/board/variscite/mx6var_som/MAINTAINERS 
> b/board/variscite/mx6var_som/MAINTAINERS
> new file mode 100644
> index 000..f3f81dd
> --- /dev/null
> +++ b/board/variscite/mx6var_som/MAINTAINERS
> @@ -0,0 +1,8 @@
> +MX6VAR_SOM BOARD
> +M:   Eran Matityahu 
> +S:   Maintained
> +F:   board/variscite/mx6var_som/
> +F:   include/configs/mx6var_som.h
> +F:   include/configs/mx6var_spl.h
> +F:   configs/mx6var_som_nand_defconfig
> +F:   configs/mx6var_som_sd_defconfig

The list must match the files you want must be added to the projects.
Just a few of them are listed here.

> diff --git a/board/variscite/mx6var_som/Makefile 
> b/board/variscite/mx6var_som/Makefile
> new file mode 100644
> index 000..efa90e2
> --- /dev/null
> +++ b/board/variscite/mx6var_som/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Copyright (C) 2007, Guennadi Liakhovetski 
> +#
> +# (C) Copyright 2011 Freescale Semiconductor, Inc.
> +#
> +# 

Re: [U-Boot] [PATCH] board: ge: bx50v3: Use pwm for display backlight

[Akshay Bhat]

On Tue, Mar 15, 2016 at 2:24 PM, Akshay Bhat 
wrote:

> Setup the LCD backlight brightness control pin to use PWM
>
> Signed-off-by: Akshay Bhat 
> Cc: Stefano Babic 
> ---
>

Hi Stefano,

Can this be applied if there are no review comments?

Thanks,
Akshay


>  board/ge/bx50v3/bx50v3.c| 11 +++
>  include/configs/ge_bx50v3.h |  3 +++
>  2 files changed, 14 insertions(+)
>
> diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
> index cf2cd1a..8e55acf 100644
> --- a/board/ge/bx50v3/bx50v3.c
> +++ b/board/ge/bx50v3/bx50v3.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  DECLARE_GLOBAL_DATA_PTR;
>
>  #define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP |  \
> @@ -324,6 +325,8 @@ static iomux_v3_cfg_t const backlight_pads[] = {
> /* Backlight enable for LVDS display */
> MX6_PAD_GPIO_0__GPIO1_IO00 | MUX_PAD_CTRL(NO_PAD_CTRL),
>  #define LVDS_BACKLIGHT_GP IMX_GPIO_NR(1, 0)
> +   /* backlight PWM brightness control */
> +   MX6_PAD_SD1_DAT3__PWM1_OUT | MUX_PAD_CTRL(NO_PAD_CTRL),
>  };
>
>  static void do_enable_hdmi(struct display_info_t const *dev)
> @@ -676,9 +679,17 @@ int board_late_init(void)
>  * as per specifications from CHI MEI */
> mdelay(250);
>
> +   /* enable backlight PWM 1 */
> +   pwm_init(0, 0, 0);
> +
> +   /* duty cycle 500ns, period: 500ns */
> +   pwm_config(0, 500, 500);
> +
> /* Backlight Power */
> gpio_direction_output(LVDS_BACKLIGHT_GP, 1);
>
> +   pwm_enable(0);
> +
> return 0;
>  }
>
> diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
> index 6fa4a9a..e37cd33 100644
> --- a/include/configs/ge_bx50v3.h
> +++ b/include/configs/ge_bx50v3.h
> @@ -327,6 +327,9 @@
>  #define CONFIG_IMX_HDMI
>  #define CONFIG_IMX_VIDEO_SKIP
>
> +#define CONFIG_PWM_IMX
> +#define CONFIG_IMX6_PWM_PER_CLK6600
> +
>  #undef CONFIG_CMD_PCI
>  #ifdef CONFIG_CMD_PCI
>  #define CONFIG_PCI
> --
> 2.7.3
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/8] usb: Move DWC3 and some gadget options to Kconfig

[Lukasz Majewski]

Hi Semen,

> 
> Hi All,
> 
> This patch series move next options to Kconfigs/defconfigs:
>  - CONFIG_USB_DWC3*
>  - CONFIG_USB_GADGET_VBUS_DRAW
>  - CONFIG_USB_GADGET_DUALSPEED (partially, only for DWC3 platforms
> for now)
>  - CONFIG_USB_GADGET_DOWNLOAD
>  - CONFIG_G_DNL_*
> 
> All defconfig files were post-processed via "make savedefconfig" rule
> to keep correct order of options in defconfigs.
> 
> The whole series was tested using buildman tool for all arm boards.
> 

I've reviewed your work and I don't have any objections.

Now, I'm trying to setup python test environment (DFU, UMS), so I cannot
thoroughly test it.

However, I do tested this patch series with Odroid XU3 with UMS gadget
and it seems to work.

Acked-by: Lukasz Majewski 
Tested-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] Using U-Boot to load RTOS

[Niti Gupta]

On 6 April 2016 at 14:33, Peng Fan  wrote:

> Hi Niti,
>
> On Wed, Apr 06, 2016 at 01:39:31PM +0800, Bin Meng wrote:
> >On Wed, Apr 6, 2016 at 1:21 PM, Niti Gupta 
> wrote:
> >> Hello Bin,
> >>
> >> I am trying to load Segger's embOS.
> >>
> >
> >Please avoid top-posting.
> >
> >I don't know this OS, but you can try 'bootelf' command if embOS image
> >is an ELF image. If there is anything special, you need write your own
> >boot command for the OS.
>
> Besids bootelf, you can directly using command "go", if your image is
> a bin file.
>
> Share my way to boot rtems on i.MX6UL.
>
> first load you os bin file to a dram address, saying 0x80008000,
> then
> dcache off
> icache off
> dcache flush
> icache flush
> go 0x80008000
>
> Regards,
> Peng


Hello Peng,
I tried following commands in order to load os bin file

"loadb 0x80008000
## Ready for binary (kermit) download to 0x80008000 at 115200 bps...
## Total Size  = 0x00018fac = 102316 Bytes
## Start Addr  = 0x80008000
=> dcache off
=> icache off
=> dcache flush
=> icache flush
=> go 0x8000800"

but it is showing following errors

undefined instruction
pc : [<00912a5c>]  lr : [<9ff5882c>]
reloc pc : []lr : [<8780582c>]
sp : 9ef50d58  ip : e59ff018 fp : 9ef568b0
r10: 0002  r9 : 9ef50eb8 r8 : 9ffa1d04
r7 : 9efd73a8  r6 : 6a0191a8 r5 : 0002  r4 : 9efd73ac
r3 : 80008abd  r2 : 9efd73ac r1 : 9efd73ac  r0 : 0001
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

I am using default u-boot for i.MUX6UL  which is "u-boot-imx6ulevk_sd.imx".
Do I need to rebuild u-boot after some rework?
Kindly help, I am completely stuck over here, failed to find appropriate
way to load RTOS from SD Card.

Thanks,
Niti Gupta

>
> >> Thanks,
> >> Niti Gupta
> >>
> >> On 6 April 2016 at 07:18, Bin Meng  wrote:
> >>>
> >>> On Wed, Apr 6, 2016 at 3:07 AM, Niti Gupta 
> wrote:
> >>> > Hello,
> >>> >
> >>> >
> >>> > I am working on embedded systems. I want to use u-boot to load rtos
> on
> >>> > freescale i.MUX6UL board but failed to find appropriate way to do
> >>> > this. Kindly help me to find out steps to load rtos from u-boot.
> >>> >
> >>>
> >>> What RTOS are you trying to load?
> >
> >Regards,
> >Bin
> >___
> >U-Boot mailing list
> >U-Boot@lists.denx.de
> >http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Fwd: Marvell Armada XP u-boot from uart

[pani]

I have a Armada A388 board that I have the same problem with.
(Using u-boot git master branch from today)

After downloading the kwb-file, the output is as below.
This is the same with the BOOT_FROM untouched or set to uart.

Did you have any luck finding out what the problem was?

Sending boot message. Please reboot the target...-
Sending boot image...
  0 %
[..]
  1 %
[..]
  3 %
[..]
  5 %
[..]
  6 %
[..]
  8 %
[..]
 10 %
[..]
 12 %
[..]
 13 %
[..]
 15 %
[..]
 17 %
[..]
 18 %
[..]
 20 %
[..]
 22 %
[..]
 24 %
[..]
 25 %
[..]
 27 %
[..]
 29 %
[..]
 30 % [...
U-Boot SPL 2016.03-00668-g4ed6ed3-dirty (Apr 06 2016 - 11:00:55)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
 | Lane #  | Speed |  Type   |
 
 |   0|  3   |  SATA0 |
 |   1|  0   |  SGMII1 |
 |   2|  5   |  PCIe1 |
 |   3|  5   |  USB3 HOST1 |
 |   4|  5   |  PCIe2 |
 |   5|  0   |  SGMII2 |
 
PCIe, Idx 1: detected no link
PCIe, Idx 2: detected no link
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.29.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
Trying to boot from unknown boot device
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
+xmodem: Protocol error 



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/Marvell-Armada-XP-u-boot-from-uart-tp215431p251080.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Using U-Boot to load RTOS

[Niti Gupta]

On 6 April 2016 at 11:09, Bin Meng  wrote:

> On Wed, Apr 6, 2016 at 1:21 PM, Niti Gupta  wrote:
> > Hello Bin,
> >
> > I am trying to load Segger's embOS.
> >
>
> Please avoid top-posting.
>
> I don't know this OS, but you can try 'bootelf' command if embOS image
> is an ELF image. If there is anything special, you need write your own
> boot command for the OS.
>
> > Thanks,
> > Niti Gupta
> >
> > On 6 April 2016 at 07:18, Bin Meng  wrote:
> >>
> >> On Wed, Apr 6, 2016 at 3:07 AM, Niti Gupta 
> wrote:
> >> > Hello,
> >> >
> >> >
> >> > I am working on embedded systems. I want to use u-boot to load rtos on
> >> > freescale i.MUX6UL board but failed to find appropriate way to do
> >> > this. Kindly help me to find out steps to load rtos from u-boot.
> >> >
> >>
> >> What RTOS are you trying to load?
>
> Regards,
> Bin
>
Thanks for reply.
embOS image is .out image. I think it is similar to .elf image. I will try
bootelf command to load this.
Thanks,
Niti
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8/ls1043a: Add MTD partition scheme

[Wenbin Song]

Hi: York

I set bootargs  as the following steps:

=> env default mtdparts
=> printenv mtdparts
mtdparts=mtdparts=6000.nor:1m(nor_bank0_rcw),1m(nor_bank0_uboot),1m(nor_bank0_uboot_env),1m(nor_bank0_fman_uconde),40m(nor_bank0_fit),1m(nor_bank4_rcw),1m(nor_bank4_uboot),1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode),40m(nor_bank4_fit);7e80.flash:1m(nand_uboot),1m(nand_uboot_env),20m(nand_fit);spi0.0:1m(uboot),5m(kernel),1m(dtb),9m(file_system)
=> env default bootargs
=> printenv bootargs
bootargs=console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 
${mtdparts}


The macro  CONFIG_BOOTARGS  only be extern as an char-string, and it will be 
spliced into default_environment array . 

 const uchar default_environment[] = {
#ifdef  CONFIG_BOOTARGS
  "bootargs=" CONFIG_BOOTARGS "\0"
 #endif
 
The variable we use to have $consoledev, $othbootargs  was used in the 
following cases:

858  #define CONFIG_BOOTCOMMAND \
859 "setenv bootargs root=/dev/ram rw " \
860 "console=$consoledev,$baudrate $othbootargs;"   \
861 "setenv ramdiskaddr 0x0200;"\
862 "setenv fdtaddr 0x00c0;"\
863 "setenv loadaddr 0x100;"\
864 "bootm $loadaddr $ramdiskaddr $fdtaddr"

Because the "setenv"  will be executed  , So the variable could be extended.

What do you suggest?

Best Regards
Wenbin Song


> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Wednesday, April 06, 2016 12:39 PM
> To: Wenbin Song ; Mingkai Hu
> ; u-boot@lists.denx.de
> Cc: Qianyu Gong ; Shaohui Xie
> ; Zhiqiang Hou 
> Subject: Re: [PATCH] armv8/ls1043a: Add MTD partition scheme
> 
> On 04/05/2016 09:20 PM, Wenbin Song wrote:
> > Hi: York
> >
> > Do you mean that I should use $mtdpart to instead of
> "MTDPARTS_DEFAULT" ?
> >
> > As follows:
> >#define CONFIG_BOOTARGS "console=ttyS0,115200
> root=/dev/ram0 " \
> >  
> > "earlycon=uart8250,mmio,0x21c0500 " \
> >"$mtdparts"
> >
> > If so, the variable $mtdparts can't  be extend ,like that:
> >
> > root@ls1043aqds:~# cat /proc/cmdline
> > console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500
> > ${mtdparts}
> >
> 
> What do you see "print bootargs" under U-Boot?
> I thought the variable can be extended when U-Boot runs the command. Like
> we used to have $consoledev, $othbootargs, etc.
> 
> York

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

Re: [U-Boot] Using U-Boot to load RTOS

[Niti Gupta]

Hello Bin,

I am trying to load Segger's embOS.

Thanks,
Niti Gupta

On 6 April 2016 at 07:18, Bin Meng  wrote:

> On Wed, Apr 6, 2016 at 3:07 AM, Niti Gupta  wrote:
> > Hello,
> >
> >
> > I am working on embedded systems. I want to use u-boot to load rtos on
> > freescale i.MUX6UL board but failed to find appropriate way to do
> > this. Kindly help me to find out steps to load rtos from u-boot.
> >
>
> What RTOS are you trying to load?
>
> Regards,
> Bin
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] armv8: LS2080A: Consolidate LS2080A and LS2085A

[Prabhakar Kushwaha]

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Tuesday, April 05, 2016 12:11 AM
> To: U-Boot Mailing List 
> Cc: Stuart Yoder ; Scott Wood ;
> Huan Wang ; york sun ;
> Prabhakar Kushwaha ; Saksham Jain
> ; Ramneek Mehresh
> ; Pratiyush Mohan Srivastava
> ; Stuart Yoder
> ; Alex Porosanu
> ; Li Yang ; Hou
> Zhiqiang ; Shaohui Xie
> ; Aneesh Bansal ;
> Jaiprakash Singh ; Ruchika Gupta
> ; Mingkai Hu ;
> Haiying Wang ; Albert Aribaud
> ; horia.gea...@freescale.com; Minghuan Lian
> ; Alexander Graf ; Lijun
> Pan ; Scott Wood ;
> Gong Qianyu ; Itai Katz ;
> Joe Hershberger ; Prabhakar Kushwaha
> ; J. German Rivera
> ; Simon Glass ;
> Shengzhou Liu ; Bin Meng
> ; Stephen Warren ;
> Bhupesh Sharma ; Qianyu Gong
> ; Thomas Chou ; Tang
> Yuantian ; Alison Wang
> 
> Subject: [PATCH v4] armv8: LS2080A: Consolidate LS2080A and LS2085A
> 
> LS2080A is the primary SoC, and LS2085A is a personality with AIOP and DPAA
> DDR. The RDB and QDS boards support both personality. By detecting the
> SVR at runtime, a single image per board can support both SoCs. It gives
> users flexibility to swtich SoC without the need to reprogram the board.
> 
> Signed-off-by: York Sun 
> CC: Prabhakar Kushwaha 
> 
> ---
> 
> Changes in v4:
> Rebase to latest master, add changes to secure boot Remove ls2085a related
> defconfig Add weak function for soc_has_aiop Compile tested on selected
> arm and powerpc targets
> 
> Changes in v3:
> Fix checking AIOP. Tested on LS2080ARDB.
> 
> Changes in v2:
> Add checking for SVR before starting AIOP Drop RFC from subject
> 
>  arch/arm/cpu/armv8/fsl-layerscape/Makefile |4 ---
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|9 ---
>  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c |6 -
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |2 +-
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c|   26
> ++-
>  arch/arm/cpu/armv8/fsl-layerscape/spl.c|4 +--
>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |9 ++-
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |2 +-
>  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |2 +-
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h |3 +++
>  arch/arm/include/asm/fsl_secure_boot.h |   12 -
>  board/freescale/ls2080a/MAINTAINERS|2 --
>  board/freescale/ls2080a/ddr.c  |   27 
> +++-
>  board/freescale/ls2080a/ls2080a.c  |2 +-
>  board/freescale/ls2080aqds/MAINTAINERS |3 ---
>  board/freescale/ls2080aqds/ddr.c   |   27 
> +++-
>  board/freescale/ls2080aqds/ls2080aqds.c|2 +-
>  board/freescale/ls2080ardb/MAINTAINERS |3 ---
>  board/freescale/ls2080ardb/ddr.c   |   27 
> +++-
>  board/freescale/ls2080ardb/ls2080ardb.c|2 +-
>  configs/ls2085a_emu_defconfig  |   20 ---
>  configs/ls2085a_simu_defconfig |   21 ---
>  configs/ls2085aqds_SECURE_BOOT_defconfig   |   20 ---
>  configs/ls2085aqds_defconfig   |   19 --
>  configs/ls2085aqds_nand_defconfig  |   14 --
>  configs/ls2085ardb_SECURE_BOOT_defconfig   |   20 ---
>  configs/ls2085ardb_defconfig   |   19 --
>  configs/ls2085ardb_nand_defconfig  |   14 --
>  doc/device-tree-bindings/serial/8250.txt   |2 +-
>  drivers/crypto/fsl/jr.c|6 ++---
>  drivers/net/fsl-mc/mc.c|   10 
>  drivers/net/ldpaa_eth/Makefile |1 -
>  include/configs/ls2080a_common.h   |7 +
>  include/configs/ls2080a_emu.h  |7 -
>  include/configs/ls2080a_simu.h |7 -
>  include/linux/usb/xhci-fsl.h   |2 +-
>  36 files changed, 115 insertions(+), 248 deletions(-)  delete mode 100644
> configs/ls2085a_emu_defconfig  delete mode 100644
> configs/ls2085a_simu_defconfig  delete mode 100644
> configs/ls2085aqds_SECURE_BOOT_defconfig
>  delete mode 100644 configs/ls2085aqds_defconfig  delete mode 100644
> configs/ls2085aqds_nand_defconfig  delete mode 100644
> configs/ls2085ardb_SECURE_BOOT_defconfig
>  delete mode 100644 configs/ls2085ardb_defconfig  delete mode 100644
> configs/ls2085ardb_nand_defconfig
> 

Patch looks good to me. 

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

Re: [U-Boot] [PATCH] armv8/ls1043a: Add MTD partition scheme

[Wenbin Song]

Hi: York

1, There is an issue for sdk2.0 kernel that the nor-flash can't be probed . we 
can fix it as follow:

$make menuconfig

  x -> Device Drivers   


  x-> Memory Technology Device (MTD) support 
  x  -> RAM/ROM/Flash chip drivers  
  
  x-> Flash chip driver advanced configuration options 
  x-> Flash cmd/query data swapping 

   x x  ( ) NO   
   x x  (X) BIG_ENDIAN_BYTE 
   x x  ( ) LITTLE_ENDIAN_BYTE   

Enable BIG_ENDIAN_BYTE .

2,  The  spi-nor flash can working on  ls1043aqds , and I use the sdk2.0 kernel 
(ce5a3841f3).
  [1.598954] m25p80 spi0.0: n25q128a11 (16384 Kbytes)
[1.603923] 4 cmdlinepart partitions found on MTD device spi0.0
[1.609842] Creating 4 MTD partitions on "spi0.0":
[1.614624] 0x-0x0010 : "uboot"
[1.624205] ftl_cs: FTL header not found.
[1.628421] 0x0010-0x0060 : "kernel"
[1.638086] ftl_cs: FTL header not found.
[1.642316] 0x0060-0x0070 : "dtb"
[1.651702] ftl_cs: FTL header not found.
[1.655932] 0x0070-0x0100 : "file_system"
[1.666028] ftl_cs: FTL header not found.

Best Regards
Wenbin Song


> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Wednesday, April 06, 2016 5:02 AM
> To: Wenbin Song ; Mingkai Hu
> ; u-boot@lists.denx.de
> Cc: Qianyu Gong ; Shaohui Xie
> ; Zhiqiang Hou 
> Subject: Re: [PATCH] armv8/ls1043a: Add MTD partition scheme
> 
> On 04/05/2016 01:32 PM, York Sun wrote:
> > On 04/01/2016 02:37 AM, Wenbin Song wrote:
> >> Add and share the the MTD partition scheme with kernel by defualt
> bootargs.
> >> And add the "mtdparts" env.
> >>
> >> Signed-off-by: Wenbin Song 
> >> ---
> >>  include/configs/ls1043a_common.h | 22 --
> >>  1 file changed, 20 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/configs/ls1043a_common.h
> >> b/include/configs/ls1043a_common.h
> >> index fd243b1..6964873 100644
> >> --- a/include/configs/ls1043a_common.h
> >> +++ b/include/configs/ls1043a_common.h
> >> @@ -236,6 +236,21 @@
> >>  #define CONFIG_HWCONFIG
> >>  #define HWCONFIG_BUFFER_SIZE  128
> >>
> >> +#if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
> >> +#define MTDPARTS_DEFAULT "mtdparts=spi0.0:1m(uboot)," \
> >> +  "5m(kernel),1m(dtb),9m(file_system)"
> >> +#else
> >> +#define MTDPARTS_DEFAULT
> "mtdparts=6000.nor:1m(nor_bank0_rcw)," \
> >> +  "1m(nor_bank0_uboot),1m(nor_bank0_uboot_env),"
> \
> >> +  "1m(nor_bank0_fman_uconde),40m(nor_bank0_fit),"
> \
> >> +  "1m(nor_bank4_rcw),1m(nor_bank4_uboot)," \
> >> +
>   "1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode)," \
> >> +  "40m(nor_bank4_fit);7e80.flash:" \
> >> +  "1m(nand_uboot),1m(nand_uboot_env)," \
> >> +  "20m(nand_fit);spi0.0:1m(uboot)," \
> >> +  "5m(kernel),1m(dtb),9m(file_system)"
> >> +#endif
> >> +
> >>  /* Initial environment variables */
> >>  #define CONFIG_EXTRA_ENV_SETTINGS \
> >>"hwconfig=fsl_ddr:bank_intlv=auto\0"\
> >> @@ -248,10 +263,13 @@
> >>"kernel_start=0x6110\0" \
> >>"kernel_load=0xa000\0"  \
> >>"kernel_size=0x280\0"   \
> >> -  "console=ttyAMA0,38400n8\0"
> >> +  "console=ttyAMA0,38400n8\0" \
> >> +  "mtdparts=" MTDPARTS_DEFAULT "\0"
> >>
> >>  #define CONFIG_BOOTARGS   "console=ttyS0,115200
> root=/dev/ram0 " \
> >> -  "earlycon=uart8250,mmio,0x21c0500"
> >> +  "earlycon=uart8250,mmio,0x21c0500 " \
> >> +  MTDPARTS_DEFAULT
> >
> > You could use $mtdparts here so your bootcmd doesn't get too long.
> >
> 
> Wenbin,
> 
> A related question regarding MTD, how do you make NOR MTD device working
> on these boards (ls1043aqds and ls1043ardb)? This is a common file for both
> RDB and QDS. I presume you have verified on both. I have nand working on
> both, spi-nor working on rdb only. I don't have NOR working on either of them.
> It may be not a U-Boot issue though.
> 
> York
> 

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

[U-Boot] [PATCH 0/2] pinctrl: add support for exynos7420 pinctrl driver

[Thomas Abraham]

This patch series adds initial support for Exynos7420 pinctrl driver. The
portions of the code that are reusable on other Exynos SoCs has been
factored out into a different file. The pin state configurations are
looked up from the device tree and the bindings are similar to the
bindings used in the linux kernel.

This patch series adds just the Exynos7420 pinctrl driver support. The
rest of the Exynos7420 SoC support will be posted later.

Thomas Abraham (2):
  pinctrl: add the DM_UC_FLAG_SEQ_ALIAS flag for numbering the devices
  pinctrl: Add pinctrl driver support for Exynos7420 SoC

 drivers/pinctrl/Kconfig |1 +
 drivers/pinctrl/Makefile|1 +
 drivers/pinctrl/exynos/Kconfig  |   10 ++
 drivers/pinctrl/exynos/Makefile |9 ++
 drivers/pinctrl/exynos/pinctrl-exynos.c |  141 +++
 drivers/pinctrl/exynos/pinctrl-exynos.h |   77 +++
 drivers/pinctrl/exynos/pinctrl-exynos7420.c |  121 +++
 drivers/pinctrl/pinctrl-uclass.c|1 +
 8 files changed, 361 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/exynos/Kconfig
 create mode 100644 drivers/pinctrl/exynos/Makefile
 create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos.c
 create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos.h
 create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos7420.c


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

Re: [U-Boot] [PATCH] armv8/ls1043a: Add MTD partition scheme

[Wenbin Song]

Hi: York

Do you mean that I should use $mtdpart to instead of "MTDPARTS_DEFAULT" ?
 
As follows: 
   #define CONFIG_BOOTARGS "console=ttyS0,115200 
root=/dev/ram0 " \
 
"earlycon=uart8250,mmio,0x21c0500 " \
   "$mtdparts"

If so, the variable $mtdparts can't  be extend ,like that:

root@ls1043aqds:~# cat /proc/cmdline
console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 ${mtdparts}


Best Regards
Wenbin Song


> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Wednesday, April 06, 2016 4:33 AM
> To: Wenbin Song ; Mingkai Hu
> ; u-boot@lists.denx.de
> Cc: Qianyu Gong ; Shaohui Xie
> ; Zhiqiang Hou 
> Subject: Re: [PATCH] armv8/ls1043a: Add MTD partition scheme
> 
> On 04/01/2016 02:37 AM, Wenbin Song wrote:
> > Add and share the the MTD partition scheme with kernel by defualt bootargs.
> > And add the "mtdparts" env.
> >
> > Signed-off-by: Wenbin Song 
> > ---
> >  include/configs/ls1043a_common.h | 22 --
> >  1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/configs/ls1043a_common.h
> > b/include/configs/ls1043a_common.h
> > index fd243b1..6964873 100644
> > --- a/include/configs/ls1043a_common.h
> > +++ b/include/configs/ls1043a_common.h
> > @@ -236,6 +236,21 @@
> >  #define CONFIG_HWCONFIG
> >  #define HWCONFIG_BUFFER_SIZE   128
> >
> > +#if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
> #define
> > +MTDPARTS_DEFAULT "mtdparts=spi0.0:1m(uboot)," \
> > +   "5m(kernel),1m(dtb),9m(file_system)"
> > +#else
> > +#define MTDPARTS_DEFAULT
> "mtdparts=6000.nor:1m(nor_bank0_rcw)," \
> > +   "1m(nor_bank0_uboot),1m(nor_bank0_uboot_env),"
> \
> > +   "1m(nor_bank0_fman_uconde),40m(nor_bank0_fit),"
> \
> > +   "1m(nor_bank4_rcw),1m(nor_bank4_uboot)," \
> > +
>   "1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode)," \
> > +   "40m(nor_bank4_fit);7e80.flash:" \
> > +   "1m(nand_uboot),1m(nand_uboot_env)," \
> > +   "20m(nand_fit);spi0.0:1m(uboot)," \
> > +   "5m(kernel),1m(dtb),9m(file_system)"
> > +#endif
> > +
> >  /* Initial environment variables */
> >  #define CONFIG_EXTRA_ENV_SETTINGS  \
> > "hwconfig=fsl_ddr:bank_intlv=auto\0"\
> > @@ -248,10 +263,13 @@
> > "kernel_start=0x6110\0" \
> > "kernel_load=0xa000\0"  \
> > "kernel_size=0x280\0"   \
> > -   "console=ttyAMA0,38400n8\0"
> > +   "console=ttyAMA0,38400n8\0" \
> > +   "mtdparts=" MTDPARTS_DEFAULT "\0"
> >
> >  #define CONFIG_BOOTARGS"console=ttyS0,115200
> root=/dev/ram0 " \
> > -   "earlycon=uart8250,mmio,0x21c0500"
> > +   "earlycon=uart8250,mmio,0x21c0500 " \
> > +   MTDPARTS_DEFAULT
> 
> You could use $mtdparts here so your bootcmd doesn't get too long.
> 
> York

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

[U-Boot] [PATCH 2/2] pinctrl: Add pinctrl driver support for Exynos7420 SoC

[Thomas Abraham]

Add pinctrl driver support for Samsung's Exynos7420 SoC. The changes
have been split into Exynos7420 specific and common Exynos specific
portions so that this implementation is reusable on other Exynos
SoCs as well.

The Exynos pinctrl driver supports only device tree based pin
configuration. The bindings used are similar to the ones used in the
linux kernel.

Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Minkyu Kang 
Signed-off-by: Thomas Abraham 
---
 drivers/pinctrl/Kconfig |1 +
 drivers/pinctrl/Makefile|1 +
 drivers/pinctrl/exynos/Kconfig  |   10 ++
 drivers/pinctrl/exynos/Makefile |9 ++
 drivers/pinctrl/exynos/pinctrl-exynos.c |  141 +++
 drivers/pinctrl/exynos/pinctrl-exynos.h |   77 +++
 drivers/pinctrl/exynos/pinctrl-exynos7420.c |  121 +++
 7 files changed, 360 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/exynos/Kconfig
 create mode 100644 drivers/pinctrl/exynos/Makefile
 create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos.c
 create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos.h
 create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos7420.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 2a69bab..bdf8931 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -145,5 +145,6 @@ endif
 
 source "drivers/pinctrl/nxp/Kconfig"
 source "drivers/pinctrl/uniphier/Kconfig"
+source "drivers/pinctrl/exynos/Kconfig"
 
 endmenu
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 37dc904..19beb04 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PINCTRL_SANDBOX) += pinctrl-sandbox.o
 
 obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/
 obj-$(CONFIG_PIC32_PINCTRL)+= pinctrl_pic32.o
+obj-$(CONFIG_PINCTRL_EXYNOS)   += exynos/
diff --git a/drivers/pinctrl/exynos/Kconfig b/drivers/pinctrl/exynos/Kconfig
new file mode 100644
index 000..84b6aaa
--- /dev/null
+++ b/drivers/pinctrl/exynos/Kconfig
@@ -0,0 +1,10 @@
+config PINCTRL_EXYNOS
+   bool
+
+config PINCTRL_EXYNOS7420
+   bool "Samsung Exynos7420 pinctrl driver"
+   depends on ARCH_EXYNOS && PINCTRL_FULL
+   select PINCTRL_EXYNOS
+   help
+ Support pin multiplexing and pin configuration control on
+ Samsung's Exynos7420 SoC.
diff --git a/drivers/pinctrl/exynos/Makefile b/drivers/pinctrl/exynos/Makefile
new file mode 100644
index 000..d9b941a
--- /dev/null
+++ b/drivers/pinctrl/exynos/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2016 Samsung Electronics
+# Thomas Abraham 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_PINCTRL_EXYNOS)   += pinctrl-exynos.o
+obj-$(CONFIG_PINCTRL_EXYNOS7420)   += pinctrl-exynos7420.o
diff --git a/drivers/pinctrl/exynos/pinctrl-exynos.c 
b/drivers/pinctrl/exynos/pinctrl-exynos.c
new file mode 100644
index 000..a28405f
--- /dev/null
+++ b/drivers/pinctrl/exynos/pinctrl-exynos.c
@@ -0,0 +1,141 @@
+/*
+ * Exynos pinctrl driver common code.
+ * Copyright (C) 2016 Samsung Electronics
+ * Thomas Abraham 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "pinctrl-exynos.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/**
+ * exynos_pinctrl_setup_peri: setup pinctrl for a peripheral.
+ * conf: soc specific pin configuration data array
+ * num_conf: number of configurations in the conf array.
+ * base: base address of the pin controller.
+ */
+void exynos_pinctrl_setup_peri(struct exynos_pinctrl_config_data *conf,
+   unsigned int num_conf, unsigned long base)
+{
+   unsigned int idx, val;
+
+   for (idx = 0; idx < num_conf; idx++) {
+   val = readl(base + conf[idx].offset);
+   val &= ~(conf[idx].mask);
+   val |= conf[idx].value;
+   writel(val, base + conf[idx].offset);
+   }
+}
+
+/* given a pin-name, return the address of pin config registers */
+static unsigned long pin_to_bank_base(struct udevice *dev, const char 
*pin_name,
+   u32 *pin)
+{
+   struct exynos_pinctrl_priv *priv = dev_get_priv(dev);
+   const struct samsung_pin_ctrl *pin_ctrl = priv->pin_ctrl;
+   const struct samsung_pin_bank_data *bank_data = pin_ctrl->pin_banks;
+   u32 nr_banks = pin_ctrl->nr_banks, idx = 0;
+   char bank[10];
+
+   /*
+* The format of the pin name is -.
+* Example: gpa0-4 (gpa0 is the bank name and 4 is the pin number.
+*/
+   while (pin_name[idx] != '-') {
+   bank[idx] = pin_name[idx];
+   idx++;
+   }
+   bank[idx] = '\0';
+   *pin = pin_name[++idx] - '0';
+
+   /* lookup the pin bank data using the pin bank name */
+   for (idx = 0; idx < nr_banks; idx++)
+   if (!strcmp(bank, bank_data[idx].name))
+   break;
+
+   return p

[U-Boot] [PATCH 1/2] pinctrl: add the DM_UC_FLAG_SEQ_ALIAS flag for numbering the devices

[Thomas Abraham]

It is possible to have multiple pin controllers in the system. Use the
DM_UC_FLAG_SEQ_ALIAS flag so that the pinctrl instances are assigned
a sequence number.

Cc: Masahiro Yamada 
Cc: Simon Glass 
Signed-off-by: Thomas Abraham 
---
 drivers/pinctrl/pinctrl-uclass.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index ccc5d30..fd04b26 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -287,5 +287,6 @@ static int pinctrl_post_bind(struct udevice *dev)
 UCLASS_DRIVER(pinctrl) = {
.id = UCLASS_PINCTRL,
.post_bind = pinctrl_post_bind,
+   .flags = DM_UC_FLAG_SEQ_ALIAS,
.name = "pinctrl",
 };
-- 
1.6.6.rc2

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

Re: [U-Boot] [PATCH 0/5] tools/env: pass arguments as parameters not global structure

[Stefano Babic]

Hi Andreas,

On 05/04/2016 23:13, Andreas Fenkart wrote:
> u-boot tools can be built as a library (ibubootenv.a). Passing arguments
> to the library using global structures is not a good interface.
> 
> Andreas Fenkart (5):
>   tools/env: make env_aes_cbc_crypt re-entrant
>   tools/env: remove 'extern' from function prototype in fw_env.h
>   tools/env: fw_printenv pass value_only as argument
>   tools/env: compute size of usable area only once
>   tools/env: no global variable sharing between application and library
> 
>  tools/env/fw_env.c  | 95 
> ++---
>  tools/env/fw_env.h  | 31 ++--
>  tools/env/fw_env_main.c | 28 +--
>  3 files changed, 78 insertions(+), 76 deletions(-)
> 

I can confirm that series fixes building an external program using the
env tools as environment. Thanks for fixing it !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-marvell/master

[Stefan Roese]

Hi Tom,

please pull those 2 Marvell related patches.

Thanks,
Stefan

The following changes since commit 4ed6ed3c27a069a00c8a557d606a05276cc4653e:

  Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2016-04-04 
14:34:09 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-marvell.git 

for you to fetch changes up to 46a16bd895144617575c788d9c2554aeef76ac44:

  kirkwood_nand: claim MPP pins on the fly (2016-04-06 15:40:33 +0200)


Chris Packham (1):
  kirkwood_nand: claim MPP pins on the fly

Stefan Roese (1):
  spi: kirkwood_spi: Add support for multiple chip-selects on MVEBU

 arch/arm/include/asm/arch-mvebu/spi.h | 17 -
 drivers/mtd/nand/kirkwood_nand.c  | 19 +++
 drivers/spi/kirkwood_spi.c| 14 ++
 3 files changed, 45 insertions(+), 5 deletions(-)

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