Re: [U-Boot] [PATCH 06/11] arm: socfpga: misc: Segregate the misc.c for Stratix 10

[Chin Liang See]

On Mon, 2016-09-05 at 18:01 +0200, Marek Vasut wrote:
> On 08/22/2016 05:02 PM, Chin Liang See wrote:
> > Segregate the misc.c to support both GEN5 SoC and Stratix 10 SoC.
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > ---
> >  arch/arm/mach-socfpga/misc.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach
> > -socfpga/misc.c
> > index 5cbd8a4..295121f 100644
> > --- a/arch/arm/mach-socfpga/misc.c
> > +++ b/arch/arm/mach-socfpga/misc.c
> > @@ -24,6 +24,8 @@
> >  
> >  DECLARE_GLOBAL_DATA_PTR;
> >  
> > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > +
> >  static struct pl310_regs *const pl310 =
> > (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
> >  static struct socfpga_system_manager *sysmgr_regs =
> > @@ -34,6 +36,7 @@ static struct nic301_registers *nic301_regs =
> > (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
> >  static struct scu_registers *scu_regs =
> > (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
> > +#endif
> >  
> >  int dram_init(void)
> >  {
> > @@ -41,6 +44,7 @@ int dram_init(void)
> > return 0;
> >  }
> >  
> > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> >  void enable_caches(void)
> >  {
> >  #ifndef CONFIG_SYS_ICACHE_OFF
> > @@ -246,6 +250,7 @@ static int socfpga_fpga_id(const bool print_id)
> >socfpga_fpga_model[i].name, version);
> > return i;
> >  }
> > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> >  
> >  /*
> >   * Print CPU information
> > @@ -253,14 +258,20 @@ static int socfpga_fpga_id(const bool
> > print_id)
> >  #if defined(CONFIG_DISPLAY_CPUINFO)
> >  int print_cpuinfo(void)
> >  {
> > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > const u32 bsel = readl(_regs->bootinfo) & 0x7;
> > puts("CPU:   Altera SoCFPGA Platform\n");
> > socfpga_fpga_id(1);
> > printf("BOOT:  %s\n", bsel_str[bsel].name);
> > +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > +   puts("CPU:   Altera SoCFPGA Platform\n");
> > +   puts("FPGA:  Altera Stratix 10\n");
> > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> 
> Can't you decode the boot mode and FPGA type instead ?

That is a good question. This is now not available in SOC Virtual
Platform. But will definitely enhance this in later stage with hardware
available.

Thanks
Chin Liang

> 
> > return 0;
> >  }
> >  #endif
> >  
> > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> >  #ifdef CONFIG_ARCH_MISC_INIT
> >  int arch_misc_init(void)
> >  {
> > @@ -469,3 +480,4 @@ U_BOOT_CMD(
> > "bridge disable - Enable HPS-to-FPGA, FPGA-to-HPS, LWHPS
> > -to-FPGA bridges\n"
> > ""
> >  );
> > +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
> > 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] eth: asix88179: Reset device during probe with DM_ETH enabled

[Alban Bedel]

On Mon, 5 Sep 2016 19:04:49 -0600
Simon Glass  wrote:

> Hi,
> 
> On 30 August 2016 at 08:01, Nikolaus Schulz
>  wrote:
> > With the ethernet driver model enabled, reset the device before reading
> > the MAC address, just like it's done for the non-device-model code path.
> > This avoids a timeout when the interface is first used.
> >
> > Signed-off-by: Nikolaus Schulz 
> > ---
> >  drivers/usb/eth/asix88179.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/usb/eth/asix88179.c b/drivers/usb/eth/asix88179.c
> > index 7548269..0725940 100644
> > --- a/drivers/usb/eth/asix88179.c
> > +++ b/drivers/usb/eth/asix88179.c
> > @@ -878,6 +878,10 @@ static int ax88179_eth_probe(struct udevice *dev)
> > usb_dev = priv->ueth.pusb_dev;
> > priv->maxpacketsize = usb_dev->epmaxpacketout[AX_ENDPOINT_OUT];
> >
> > +   ret = asix_basic_reset(>ueth, priv);
> > +   if (ret)
> > +   return ret;
> > +
> > /* Get the MAC address */
> > ret = asix_read_mac(>ueth, pdata->enetaddr);
> > if (ret)  
> 
> How come this doesn't happen in ax88179_eth_start()?

It happen in ax88179_eth_get_info() in the non DM case, that's why it
was overseen when adding DM support.

Alban


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

[U-Boot] [PATCH] ARMv8/sec-firmware: fix a compile error

[Zhiqiang Hou]

From: Hou Zhiqiang 

When enabled sec firmware framework, but lack of definition of
the marco SEC_FIRMWARE_FIT_IMAGE, SEC_FIRMEWARE_FIT_CNF_NAME
and SEC_FIRMWARE_TARGET_EL, there will be some build errors,
so give a default definition.

Signed-off-by: Hou Zhiqiang 
---
 arch/arm/cpu/armv8/sec_firmware.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv8/sec_firmware.c 
b/arch/arm/cpu/armv8/sec_firmware.c
index e21e199..2ddd67e 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -19,12 +19,22 @@ extern void c_runtime_cpu_setup(void);
 #define SEC_FIRMWARE_LOADED0x1
 #define SEC_FIRMWARE_RUNNING   0x2
 #define SEC_FIRMWARE_ADDR_MASK (~0x3)
-   /*
-* Secure firmware load addr
-* Flags used: 0x1 secure firmware has been loaded to secure memory
-* 0x2 secure firmware is running
-*/
-   phys_addr_t sec_firmware_addr;
+/*
+ * Secure firmware load addr
+ * Flags used: 0x1 secure firmware has been loaded to secure memory
+ * 0x2 secure firmware is running
+ */
+phys_addr_t sec_firmware_addr;
+
+#ifndef SEC_FIRMWARE_FIT_IMAGE
+#define SEC_FIRMWARE_FIT_IMAGE "firmware"
+#endif
+#ifndef SEC_FIRMEWARE_FIT_CNF_NAME
+#define SEC_FIRMEWARE_FIT_CNF_NAME "config@1"
+#endif
+#ifndef SEC_FIRMWARE_TARGET_EL
+#define SEC_FIRMWARE_TARGET_EL 2
+#endif
 
 static int sec_firmware_get_data(const void *sec_firmware_img,
const void **data, size_t *size)
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH] net: write enetaddr down to hardware on env_callback

[Bin Meng]

Hi Hannes,

On Tue, Sep 6, 2016 at 12:33 PM, Hannes Schmelzer
 wrote:
> "U-Boot"  schrieb am 06.09.2016 03:54:52:
>
>> Von: Bin Meng 
>> An: Joe Hershberger ,
>> Kopie: u-boot , Hannes Schmelzer
> , Joe
>> Hershberger 
>> Datum: 06.09.2016 03:57
>> Betreff: Re: [U-Boot] [PATCH] net: write enetaddr down to hardware on
> env_callback
>> Gesendet von: "U-Boot" 
>>
>> Hi,
> Hi Bin,
>
>>
>> On Fri, Sep 2, 2016 at 9:00 PM, Joe Hershberger
>>  wrote:
>> > On Fri, Sep 2, 2016 at 7:48 AM, Hannes Schmelzer 
> wrote:
>> >> If mac-address is changed using "setenv ethaddr " command the new
>> >> mac-adress also must be written into the responsible ethernet driver.
>> >>
>> >> Signed-off-by: Hannes Schmelzer 
>> >
>> > Acked-by: Joe Hershberger 
>>
>> Why is this needed? The MAC address is supposed to be programmed in
>> the driver's probe routine.
>
> For example on my custom ZYNQ board.
> The Ethernetcontroller within the ZYNQ has no ROM to store his own
> MAC-Address, further no MAC is stored within environment.
> So Ethernet gets probed with a "random MAC-Address" if configured.
>
> Later somebody (like me) oder something (my bootscript) runs "setenv
> ethaddr " on the console.
> Result is (was before this patch), that all networking infrastructre is
> running this new mac, but hardware is running the old (random) one and
> networking is simple not functional.
>

This indicates that your ethernet driver does not program the latest
MAC address everyone when it gets probed. The driver should be fixed.

> ok?
>

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

Re: [U-Boot] [PATCH] net: write enetaddr down to hardware on env_callback

[Hannes Schmelzer]

Bin Meng  schrieb am 06.09.2016 09:07:39:

[...]
> >>
> >> Why is this needed? The MAC address is supposed to be programmed in
> >> the driver's probe routine.
> >
> > For example on my custom ZYNQ board.
> > The Ethernetcontroller within the ZYNQ has no ROM to store his own
> > MAC-Address, further no MAC is stored within environment.
> > So Ethernet gets probed with a "random MAC-Address" if configured.
> >
> > Later somebody (like me) oder something (my bootscript) runs "setenv
> > ethaddr " on the console.
> > Result is (was before this patch), that all networking infrastructre 
is
> > running this new mac, but hardware is running the old (random) one and
> > networking is simple not functional.
> >
> 
> This indicates that your ethernet driver does not program the latest
> MAC address everyone when it gets probed. The driver should be fixed.

The driver doesn't get probed again if mac-address is changed using 
"setenv ethaddr",
so it has no chance to program anything.

For program i understand, in this case with zynq, overtaking mac-address 
into his registers.
There is per default no ROM to store some mac.

> 
> Regards,
> Bin
cheers,
Hannes


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

Re: [U-Boot] [PATCH] net: write enetaddr down to hardware on env_callback

[Bin Meng]

Hi Hannes,

On Tue, Sep 6, 2016 at 3:23 PM, Hannes Schmelzer
 wrote:
> Bin Meng  schrieb am 06.09.2016 09:07:39:
>
> [...]
>> >>
>> >> Why is this needed? The MAC address is supposed to be programmed in
>> >> the driver's probe routine.
>> >
>> > For example on my custom ZYNQ board.
>> > The Ethernetcontroller within the ZYNQ has no ROM to store his own
>> > MAC-Address, further no MAC is stored within environment.
>> > So Ethernet gets probed with a "random MAC-Address" if configured.
>> >
>> > Later somebody (like me) oder something (my bootscript) runs "setenv
>> > ethaddr " on the console.
>> > Result is (was before this patch), that all networking infrastructre
> is
>> > running this new mac, but hardware is running the old (random) one and
>> > networking is simple not functional.
>> >
>>
>> This indicates that your ethernet driver does not program the latest
>> MAC address everyone when it gets probed. The driver should be fixed.
>
> The driver doesn't get probed again if mac-address is changed using
> "setenv ethaddr",
> so it has no chance to program anything.
>

Yes, driver is not probed when "setenv ethaddr", but next time when
you type any ethernet related command (like tftpboot), the driver will
be probed.

> For program i understand, in this case with zynq, overtaking mac-address
> into his registers.
> There is per default no ROM to store some mac.
>

I have feeling that for some ethernet controllers, simply calling
eth_write_hwaddr() may not change its MAC address correctly. It may
need some special programming sequence like firstly turn off, reset,
then program the MAC.

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

Re: [U-Boot] [PATCH 09/11] arm: socfpga: stratix10: Add board folder for Stratix 10 socdk

[Chin Liang See]

On Mon, 2016-09-05 at 18:03 +0200, Marek Vasut wrote:
> On 08/22/2016 05:02 PM, Chin Liang See wrote:
> > Add board folder for Stratix 10 SoC development kit
> 
> Directory, this is not Windows :-(

haha... used to the windows term :) Will change this

> 
> Oh, btw also use "separate", not "segregate", in the previous
> patches.

Yup, will fix

Thanks
Chin Liang

> 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > ---
> >  board/altera/stratix10-socdk/MAINTAINERS | 8 
> >  board/altera/stratix10-socdk/Makefile| 7 +++
> >  board/altera/stratix10-socdk/socfpga.c   | 7 +++
> >  3 files changed, 22 insertions(+)
> >  create mode 100755 board/altera/stratix10-socdk/MAINTAINERS
> >  create mode 100755 board/altera/stratix10-socdk/Makefile
> >  create mode 100755 board/altera/stratix10-socdk/socfpga.c
> > 
> > diff --git a/board/altera/stratix10-socdk/MAINTAINERS
> > b/board/altera/stratix10-socdk/MAINTAINERS
> > new file mode 100755
> > index 000..06f8989
> > --- /dev/null
> > +++ b/board/altera/stratix10-socdk/MAINTAINERS
> > @@ -0,0 +1,8 @@
> > +SOCFPGA BOARD
> > +M: Chin-Liang See 
> > +M: Dinh Nguyen 
> > +S: Maintained
> > +F: board/altera/stratix10-socdk/
> > +F: include/configs/socfpga_stratix10_socdk.h
> > +F: configs/socfpga_stratix10_defconfig
> > +
> > diff --git a/board/altera/stratix10-socdk/Makefile
> > b/board/altera/stratix10-socdk/Makefile
> > new file mode 100755
> > index 000..a0c8024
> > --- /dev/null
> > +++ b/board/altera/stratix10-socdk/Makefile
> > @@ -0,0 +1,7 @@
> > +#
> > +# Copyright (C) 2016, Intel Corporation
> > +#
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +
> > +obj-y  := socfpga.o
> > diff --git a/board/altera/stratix10-socdk/socfpga.c
> > b/board/altera/stratix10-socdk/socfpga.c
> > new file mode 100755
> > index 000..6778c04
> > --- /dev/null
> > +++ b/board/altera/stratix10-socdk/socfpga.c
> > @@ -0,0 +1,7 @@
> > +/*
> > + * Copyright (C) 2016, Intel Corporation
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +#include 
> > 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ZynqMP breakage

[Alexander Graf]

On 09/06/2016 03:05 AM, Simon Glass wrote:

Hi Alex,

On 5 September 2016 at 04:51, Alexander Graf  wrote:

On 08/19/2016 08:45 AM, Michal Simek wrote:

On 16.8.2016 20:39, Alexander Graf wrote:

Hi Michal,

I just tried to run the latest u-boot master + a few patches to implement
generic PSCI RTS support on zynqmp and got this:

e
U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200) Xilinx
ZynqMP ZCU102

I2C:   ready
DRAM:  4 GiB
EL Level:   EL2
MMC:   sdhci@ff17: 0
Using default environment

In:serial@ff00
Out:   serial@ff00
Err:   serial@ff00
Bootmode: SD_MODE1
SCSI:  SATA link 0 timeout.
Target spinup took 0 ms.
AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
scanning bus for devices...
"Synchronous Abort" handler, esr 0x9604
ELR: 7ff42d20
LR:  7ff3ff10
x0 :  x1 : 
x2 : 0001 x3 : 7df1aa80
x4 :  x5 : 0001
x6 : 0200 x7 : 0004
x8 : 7ff9f800 x9 : 0008
x10: 7ff9f8f0 x11: 
x12:  x13: 
x14: 7ff8242f x15: 7ff82435
x16: 7ff84388 x17: 7ff84388
x18: 7df1ade8 x19: 7df1aa80
x20: 7ff92cb8 x21: 7ff9f800
x22: 7ff9f000 x23: 0078
x24: 7ff9f8f0 x25: 
x26: 7ff9f800 x27: 7ff9f000
x28: 7ff9fb00 x29: 7df1aca0

Resetting CPU ...

resetting …

Is this a known problem?

Is this issue with usb?
I have usb off on zcu102 that's why if this usb issue
I am not aware about it.


After a bit of digging, turns out it's CONFIG_BLK. If I disable that things
work again (albeit without mmc access, since that one requires CONFIG_BLK
now).

I don't have a zynqmp device, so cannot test with that unfortunately.


Well, QEMU supports zcu102 emulation in the latest version, so you could 
use that to emulate the board:


  $ qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m 
2G -drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0


However, I don't see the data abort with the emulated device, only with 
actual hardware. Probably because real hardware is more upset about 
reading from address 0 ;). But I can provoke the oops even in QEMU if I 
unmap the first page from the memory map using the patch below.


The oops happens in blk_dread because block_dev->bdev is NULL.


Alex


diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c 
b/arch/arm/cpu/armv8/zynqmp/cpu.c

index b0f1295..0878025 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -18,9 +18,9 @@ DECLARE_GLOBAL_DATA_PTR;

 static struct mm_region zynqmp_mem_map[] = {
{
-   .virt = 0x0UL,
-   .phys = 0x0UL,
-   .size = 0x8000UL,
+   .virt = 0x1000UL,
+   .phys = 0x1000UL,
+   .size = 0x8000UL - 0x1000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {

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

Re: [U-Boot] [PATCH 11/11] arm: socfpga: Add support for Stratix 10 SoC dev kit

[Chin Liang See]

On Mon, 2016-09-05 at 18:06 +0200, Marek Vasut wrote:
> On 08/22/2016 05:02 PM, Chin Liang See wrote:
> > Add support for Stratix 10 SoC development kit
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ley Foon Tan 
> > ---
> >  arch/arm/Kconfig  |   7 +-
> >  arch/arm/mach-socfpga/Kconfig |  10 +++
> >  configs/socfpga_stratix10_defconfig   |  14 
> >  include/configs/socfpga_stratix10_socdk.h | 135
> > ++
> >  4 files changed, 163 insertions(+), 3 deletions(-)
> >  create mode 100755 configs/socfpga_stratix10_defconfig
> >  create mode 100644 include/configs/socfpga_stratix10_socdk.h
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index aef901c..c8e8767 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -600,10 +600,11 @@ config ARCH_SNAPDRAGON
> >  
> >  config ARCH_SOCFPGA
> > bool "Altera SOCFPGA family"
> > -   select CPU_V7
> > -   select SUPPORT_SPL
> > +   select CPU_V7 if !TARGET_SOCFPGA_STRATIX10
> > +   select ARM64 if TARGET_SOCFPGA_STRATIX10
> > +   select SUPPORT_SPL if !TARGET_SOCFPGA_STRATIX10
> > select OF_CONTROL
> > -   select SPL_OF_CONTROL
> > +   select SPL_OF_CONTROL if !TARGET_SOCFPGA_STRATIX10
> 
> Why is the SPL disabled ?

We will be having SPL for Stratix 10. It will added in later days as
SPL main function is for DDR setup. This is not needed for SOC Virtual
Platform now.

> 
> > select DM
> > select DM_SPI_FLASH
> > select DM_SPI
> > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach
> > -socfpga/Kconfig
> > index 1a43c7b..4e3b238 100644
> > --- a/arch/arm/mach-socfpga/Kconfig
> > +++ b/arch/arm/mach-socfpga/Kconfig
> > @@ -11,6 +11,9 @@ config TARGET_SOCFPGA_CYCLONE5
> >  config TARGET_SOCFPGA_GEN5
> > bool
> >  
> > +config TARGET_SOCFPGA_STRATIX10
> > +   bool
> > +
> >  choice
> > prompt "Altera SOCFPGA board select"
> > optional
> > @@ -51,6 +54,10 @@ config TARGET_SOCFPGA_TERASIC_SOCKIT
> > bool "Terasic SoCkit (Cyclone V)"
> > select TARGET_SOCFPGA_CYCLONE5
> >  
> > +config TARGET_SOCFPGA_STRATIX10_SOCDK
> > +   bool "Altera SOCFPGA SoCDK (Stratix 10)"
> > +   select TARGET_SOCFPGA_STRATIX10
> > +
> >  endchoice
> >  
> >  config SYS_BOARD
> > @@ -63,6 +70,7 @@ config SYS_BOARD
> > default "socrates" if TARGET_SOCFPGA_EBV_SOCRATES
> > default "sr1500" if TARGET_SOCFPGA_SR1500
> > default "vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
> > +   default "stratix10-socdk" if
> > TARGET_SOCFPGA_STRATIX10_SOCDK
> 
> Keep all the lists sorted .

Noted, will fix this.

> 
> >  config SYS_VENDOR
> > default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK
> > @@ -72,6 +80,7 @@ config SYS_VENDOR
> > default "samtec" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
> > default "terasic" if TARGET_SOCFPGA_TERASIC_DE0_NANO
> > default "terasic" if TARGET_SOCFPGA_TERASIC_SOCKIT
> > +   default "altera" if TARGET_SOCFPGA_STRATIX10_SOCDK
> >  
> >  config SYS_SOC
> > default "socfpga"
> > @@ -86,5 +95,6 @@ config SYS_CONFIG_NAME
> > default "socfpga_socrates" if TARGET_SOCFPGA_EBV_SOCRATES
> > default "socfpga_sr1500" if TARGET_SOCFPGA_SR1500
> > default "socfpga_vining_fpga" if
> > TARGET_SOCFPGA_SAMTEC_VINING_FPGA
> > +   default "socfpga_stratix10_socdk" if
> > TARGET_SOCFPGA_STRATIX10_SOCDK
> >  
> >  endif
> 
> [...]
> 
> btw. what about Arria 10 ? Will it ever land ?
> And will I ever get a kit ? :)

Since S10 is good, I will help out the A10 upstreaming once S10 is
intergrated. While for dev kit, let me work that out as we have A10 dev
kit with production silicon :)

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH 3/5] ARM: DRA7: Add secure emif setup calls

[Andrew F. Davis]

On 09/02/2016 12:40 AM, Daniel Allred wrote:
> After EMIF DRAM is configured, but before it is used,
> calls are made on secure devices to reserve any configured
> memory region needed by the secure world and then to lock the
> EMIF firewall configuration. If any other firewall
> configuration needs to be applied, it must happen before the
> lock call.
> 
> Signed-off-by: Daniel Allred 
> ---
>  arch/arm/cpu/armv7/omap-common/emif-common.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c 
> b/arch/arm/cpu/armv7/omap-common/emif-common.c
> index 2b79010..b26984e 100644
> --- a/arch/arm/cpu/armv7/omap-common/emif-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -1477,6 +1478,20 @@ void sdram_init(void)
>   debug("get_ram_size() successful");
>   }
>  
> +#if defined(CONFIG_TI_SECURE_DEVICE)
> + /*
> +  * On HS devices, do static EMIF firewall configuration
> +  * but only do it if not already running in SDRAM
> +  */
> + if (!in_sdram)

Should we hang in this case?

> + if (0 != secure_emif_reserve())

"0 != " could be removed here and below.

> + hang();
> +
> + /* On HS devices, ensure static EMIF firewall APIs are locked */
> + if (0 != secure_emif_firewall_lock())
> + hang();
> +#endif
> +
>   if (sdram_type == EMIF_SDRAM_TYPE_DDR3 &&
>   (!in_sdram && !warm_reset()) && (!is_dra7xx())) {
>   if (emif1_enabled)
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] UBI and UBIFS on ARM64

[Oleksy, Adam (Nokia - PL/Wroclaw)]

Dear U-Boot community,
I'm developing software for Xilinx ZynqMP platform, which is made in 64-bit 
architecture. I would like to store every artifact needed to boot up on the 
UBIFS partition. I faced problem, that u-boot does not want to compile with 
enabled UBI/UBIFS support, due to lack of some atomic operations on longs. So, 
I've written them (see http://pastebin.com/ibp0Zt99). Please note, that I've 
written only that functions, which are needed by UBI/UBIFS. Then UBIFS started 
work on the target. Almost... because I've found that large files (~20MiB) 
can't be read. I've enabled debug messages, but I don't know how to interpret 
them (please see http://pastebin.com/gByDcdvw). Maybe you are able to help me?
I've also checked how the UBIFS behaves in the Linux, and the result is that 
everything works as expected. It means that I can write large files to UBIFS, 
and read them back successfully.  
Should you need any further information, please do not hesitate to contact me.

.
 Best Regards,
 Adam Oleksy
  
 Nokia Solutions and Networks Sp. z o.o.
 

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

[U-Boot] Antwort: Re: Re: Re: [PATCH] net: write enetaddr down to hardware on env_callback

[Hannes Schmelzer]

Bin Meng  schrieb am 06.09.2016 09:28:13:

> Von: Bin Meng 
> An: Hannes Schmelzer , 
> Kopie: Joe Hershberger , Joe Hershberger 
> , Hannes Schmelzer , u-boot  b...@lists.denx.de>, U-Boot 
> Datum: 06.09.2016 09:28
> Betreff: Re: Re: Re: [U-Boot] [PATCH] net: write enetaddr down to 
hardware on 
> env_callback
> 
> Hi Hannes,
> 
> On Tue, Sep 6, 2016 at 3:23 PM, Hannes Schmelzer
>  wrote:
> > Bin Meng  schrieb am 06.09.2016 09:07:39:
> >
> > [...]
> >> >>
> >> >> Why is this needed? The MAC address is supposed to be programmed 
in
> >> >> the driver's probe routine.
> >> >
> >> > For example on my custom ZYNQ board.
> >> > The Ethernetcontroller within the ZYNQ has no ROM to store his own
> >> > MAC-Address, further no MAC is stored within environment.
> >> > So Ethernet gets probed with a "random MAC-Address" if configured.
> >> >
> >> > Later somebody (like me) oder something (my bootscript) runs 
"setenv
> >> > ethaddr " on the console.
> >> > Result is (was before this patch), that all networking 
infrastructre
> > is
> >> > running this new mac, but hardware is running the old (random) one 
and
> >> > networking is simple not functional.
> >> >
> >>
> >> This indicates that your ethernet driver does not program the latest
> >> MAC address everyone when it gets probed. The driver should be fixed.
> >
> > The driver doesn't get probed again if mac-address is changed using
> > "setenv ethaddr",
> > so it has no chance to program anything.
> >
> 
> Yes, driver is not probed when "setenv ethaddr", but next time when
> you type any ethernet related command (like tftpboot), the driver will
> be probed.
No. The ethernet driver isn't probed everytime a network transaction is 
coming.
What i can see, the probe is done one time.

> 
> > For program i understand, in this case with zynq, overtaking 
mac-address
> > into his registers.
> > There is per default no ROM to store some mac.
> >
> 
> I have feeling that for some ethernet controllers, simply calling
> eth_write_hwaddr() may not change its MAC address correctly. It may
> need some special programming sequence like firstly turn off, reset,
> then program the MAC.
That might be possible. Maybe this is the reason why not all drivers 
provide this function.

> 
> Regards,
> Bin


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

Re: [U-Boot] [PATCH 1/3] pico-imx6ul: Directly write to register LDOGCTL

[Stefano Babic]

On 17/08/2016 14:46, Fabio Estevam wrote:
> Register LDOGCTL contains only bit 0 as a valid bit, so there is no need
> to do a read-modify-write operation.
> 
> Simplify the code by writing directly to this register.
> 
> Signed-off-by: Fabio Estevam 
> ---


Applied to u-boot-imx, thanks !

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

Re: [U-Boot] [PATCH 2/3] mx7dsabresd: Directly write to register LDOGCTL

[Stefano Babic]

On 17/08/2016 14:46, Fabio Estevam wrote:
> Register LDOGCTL contains only bit 0 as a valid bit, so there is no need
> to do a read-modify-write operation.
> 
> Simplify the code by writing directly to this register.
> 
> Signed-off-by: Fabio Estevam 
> ---


Applied to u-boot-imx, thanks !

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

Re: [U-Boot] [PATCH 3/3] mx7dsabresd: Directly write to register LDOGCTL

[Stefano Babic]

On 17/08/2016 14:46, Fabio Estevam wrote:
> Register LDOGCTL contains only bit 0 as a valid bit, so there is no need
> to do a read-modify-write operation.
> 
> Simplify the code by writing directly to this register.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

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

Re: [U-Boot] [PATCH v4 2/4] mx6ul_14x14_evk: Pass refsel and refr fields to avoid hang

[Stefano Babic]

On 30/08/2016 01:37, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> When running a NXP 4.1 kernel with U-Boot mainline on a mx6ul-evk,
> we observe a hang when going into the lowest operational point of cpufreq.
> 
> This hang issue does not happen on the NXP U-Boot version.
> 
> After comparing the SPL DDR initialization against the DCD table
> from NXP U-Boot, the key difference that causes the hang is the
> MDREF register setting:
> 
> DATA 4 0x021B0020 0x0800
> 
> ,which means:
> 
> REF_SEL = 0 --> Periodic refresh cycle: 64kHz
> REFR = 1 ---> Refresh Rate - 2 refreshes
> 
> So adjust the MDREF initialization for mx6ul_evk accordingly
> to fix the kernel hang issue at low bus frequency.
> 
> Reported-by: Eric Nelson 
> Signed-off-by: Fabio Estevam 
> ---

Applied (all series as fix !) to u-boot-imx, thanks !

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

Re: [U-Boot] [PATCH v2 1/3] warp7: Add a secure mode target

[Stefano Babic]

On 26/08/2016 02:07, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> NXP kernel expects to boot in secure mode, so introduce
> warp7_secure_defconfig target which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

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

Re: [U-Boot] [PATCH v2 2/3] warp7: Use PARTUUID to specify the rootfs location

[Stefano Babic]

On 26/08/2016 02:07, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> warp7 can run different kernel versions, such as NXP 4.1 or mainline.
> 
> Currently the rootfs location is passed via mmcblk number and the
> problem with this approach is that the mmcblk number for the eMMC
> changes depending on the kernel version.
> 
> In order to avoid such issue, use UUID method to specify the rootfs
> location.
> 
> Succesfully tested booting a NXP 4.1 and also a mainline kernel.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

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

Re: [U-Boot] [PATCH] ARM: board: cm_fx6: fix mtd partition fixup

[Stefano Babic]

On 23/08/2016 16:08, christopher.spinr...@rwth-aachen.de wrote:
> From: Christopher Spinrath 
> 
> ft_board_setup may return early in the case that the board revision
> cannot be obtained. In that case it is assumed that no revision
> specific correction in the fdt is neccessary. But the mtd partitions
> will not be fixed up either altough they are not revision specific.
> 
> Move the call to fdt_fixup_mtdparts in front of the revision specific
> part to ensure that the partitions are fixed up even if the board
> revision cannot be obtained.
> 
> While on it, fix a spelling mistake in a comment introduced by the
> same commit.
> 
> Fixes: 62d6bac66038 ("ARM: board: cm_fx6: fixup mtd partitions in the fdt")
> Signed-off-by: Christopher Spinrath 
> ---


Applied to u-boot-imx, thanks !

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] [PULL] Please pull u-boot-imx

[Stefano Babic]

Hi Tom,

please pull from u-boot-imx, thanks !

The following changes since commit 46fe9eb08812cc27a0d5cd97d97373c14d578fe9:

  Merge branch 'master' of git://git.denx.de/u-boot-net (2016-08-23
07:20:36 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to 19c6e9ac4a43d7e261220e2de4bb1045165558c0:

  mx6ul_14x14_ev: Enable the CCGR clocks earlier (2016-09-06 10:35:02 +0200)


Akshay Bhat (1):
  arm: imx: Add support for Advantech DMS-BA16 board

Breno Lima (1):
  warp7: Modify fdt_file environment variable

Christopher Spinrath (1):
  ARM: board: cm_fx6: fix mtd partition fixup

Eric Nelson (1):
  mx6ul_14x14_evk: don't use array for SD2 card detect pad

Fabio Estevam (9):
  mx7dsabresd: Print secure/non-secure mode info
  warp: Fix RAM size runtime detection
  pico-imx6ul: Directly write to register LDOGCTL
  mx7dsabresd: Directly write to register LDOGCTL
  mx7dsabresd: Directly write to register LDOGCTL
  mx6: ddr: Allow changing REFSEL and REFR fields
  mx6ul_14x14_evk: Pass refsel and refr fields to avoid hang
  mx6ul_14x14_evk: Adjust SPL DDR3 settings
  mx6ul_14x14_ev: Enable the CCGR clocks earlier

Peng Fan (20):
  imx: mx6ull: add iomux header file
  imx: mx6ull: add mx6ull major cpu type
  imx-common: introduce is_mx6ull
  imx: ocotp: support i.MX6ULL
  imx: timer: update gpt driver for i.MX6ULL
  imx: mx6ull: skip setting ahb clock
  imx: mx6ul: using runtime check when configuring PMIC_STBY_REQ
  imx: mx6ull: misc soc update
  imx: mx6ull: adjust POR_B setting for i.MX6ULL
  imx: mx6ull: update clock settings and CCM register map
  imx: mx6ull: Update memory map address
  imx: mx6ull: Add AIPS3 initialization
  imx: imx6ull: adjust the ldo 1.2v bandgap voltage
  imx: iomux: fix snvs usage for i.MX6ULL
  pinctrl: imx6: support i.MX6ULL
  arm: dts: imx6ull: add pinctrl defines
  dt-bindings: add i.mx6ul clock header
  arm: dts: add device tree for i.MX6ULL
  dm: mmc: intialize dev when probe
  arm: imx: add i.MX6ULL 14x14 EVK board support

Soeren Moch (2):
  board: tbs2910: always enable usbkbd
  board: tbs2910: fix HDMI pre-console buffer

Stefan Agner (11):
  mtd: nand: mxs: fix cache alignment for cache lines >32
  dm: imx: serial: support device tree
  pinctrl: imx: do not announce driver initialization
  arm: dts: imx7: add pinctrl defines
  arm: dts: imx7: add basic i.MX 7/Colibri iMX7 device tree
  colibri_imx7: remove legancy I2C support
  colibri_imx7: remove legancy UART platform data
  power: pmic: add Ricoh RN5T567 PMIC support
  arm: dts: imx7: add Ricoh RN5T567 PMIC node
  colibri_imx7: use Ricoh RN5T567 to reboot the board
  configs: enable device tree for Colibri iMX7

Stefano Babic (2):
  Merge branch 'master' of git://git.denx.de/u-boot
  Merge branch 'master' of git://git.denx.de/u-boot

Tim Harvey (1):
  imx: ventana: enable splashscreen support

Vanessa Maegima (1):
  warp7: Add PMIC support

Ye Li (1):
  imx: mx6ull: add kconfig entry for MX6ULL
 arch/arm/cpu/armv7/mx6/Kconfig|   16 ++
 arch/arm/cpu/armv7/mx6/clock.c|   59 +++--
 arch/arm/cpu/armv7/mx6/ddr.c  |6 +-
 arch/arm/cpu/armv7/mx6/soc.c  |   32 ++-
 arch/arm/dts/Makefile |4 +
 arch/arm/dts/imx6ul-pinfunc.h |  938

 arch/arm/dts/imx6ull-14x14-evk.dts|  527
+
 arch/arm/dts/imx6ull-pinfunc-snvs.h   |   29 +++
 arch/arm/dts/imx6ull-pinfunc.h|   57 +
 arch/arm/dts/imx6ull.dtsi | 1161
++
 arch/arm/dts/imx7-colibri.dts |   97 
 arch/arm/dts/imx7.dtsi|  194 +++
 arch/arm/dts/imx7d-pinfunc.h  | 1151
+
 arch/arm/imx-common/cpu.c |2 +
 arch/arm/imx-common/init.c|2 +-
 arch/arm/imx-common/iomux-v3.c|   11 +-
 arch/arm/imx-common/timer.c   |7 +-
 arch/arm/include/asm/arch-imx/cpu.h   |3 +-
 arch/arm/include/asm/arch-mx6/crm_regs.h  |   60 -
 arch/arm/include/asm/arch-mx6/imx-regs.h  |   18 +-
 arch/arm/include/asm/arch-mx6/mx6-ddr.h   |2 +
 arch/arm/include/asm/arch-mx6/mx6-pins.h  |2 +
 arch/arm/include/asm/arch-mx6/mx6ull_pins.h   | 1065

[U-Boot] [PATCH v3 1/2] Txxx/RCW: Split unified RCW to RCWs for sd, spi and nand.

[Zhao Qiang]

T series boards use unified RCW for sd, api and nand boot.
Now split txxx_rcw.cfg to txxx_sd_rcw.cfg, txxx_spi_rcw.cfg
and txxx_nand_rcw.cfg for SPI/NAND/SD boot.
And modify RCW[PBI_SRC] for them,
PBI_SRC=5for SPI  24-bit addressing
PBI_SRC=6for SD boot
PBI_SRC=14   for IFC NAND boot

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- split to two patches
Changes for v3:
- modify commit msg, explain why modify the PBI_SRC.

 .../t102xqds/{t1024_rcw.cfg => t1024_nand_rcw.cfg} |  0
 .../t102xqds/{t1024_rcw.cfg => t1024_sd_rcw.cfg}   |  2 +-
 .../t102xqds/{t1024_rcw.cfg => t1024_spi_rcw.cfg}  |  2 +-
 .../t102xrdb/{t1023_rcw.cfg => t1023_nand_rcw.cfg} |  0
 .../t102xrdb/{t1023_rcw.cfg => t1023_sd_rcw.cfg}   |  2 +-
 .../t102xrdb/{t1023_rcw.cfg => t1023_spi_rcw.cfg}  |  2 +-
 .../t102xrdb/{t1024_rcw.cfg => t1024_nand_rcw.cfg} |  0
 .../t102xrdb/{t1024_rcw.cfg => t1024_sd_rcw.cfg}   |  2 +-
 .../t102xrdb/{t1024_rcw.cfg => t1024_spi_rcw.cfg}  |  2 +-
 .../t104xrdb/{t1040_rcw.cfg => t1040_nand_rcw.cfg} |  0
 .../t104xrdb/{t1040_rcw.cfg => t1040_sd_rcw.cfg}   |  2 +-
 .../t104xrdb/{t1040_rcw.cfg => t1040_spi_rcw.cfg}  |  2 +-
 .../{t1040d4_rcw.cfg => t1040d4_nand_rcw.cfg}  |  0
 .../{t1040d4_rcw.cfg => t1040d4_sd_rcw.cfg}|  2 +-
 .../{t1040d4_rcw.cfg => t1040d4_spi_rcw.cfg}   |  2 +-
 .../t104xrdb/{t1042_rcw.cfg => t1042_nand_rcw.cfg} |  0
 .../{t1042_pi_rcw.cfg => t1042_pi_nand_rcw.cfg}|  0
 .../{t1042_pi_rcw.cfg => t1042_pi_sd_rcw.cfg}  |  2 +-
 .../{t1042_pi_rcw.cfg => t1042_pi_spi_rcw.cfg} |  2 +-
 .../t104xrdb/{t1042_rcw.cfg => t1042_sd_rcw.cfg}   |  2 +-
 .../t104xrdb/{t1042_rcw.cfg => t1042_spi_rcw.cfg}  |  2 +-
 .../{t1042d4_rcw.cfg => t1042d4_nand_rcw.cfg}  |  0
 .../{t1042d4_rcw.cfg => t1042d4_sd_rcw.cfg}|  2 +-
 .../{t1042d4_rcw.cfg => t1042d4_spi_rcw.cfg}   |  2 +-
 .../t208xqds/{t2080_rcw.cfg => t2080_nand_rcw.cfg} |  0
 .../t208xqds/{t2080_rcw.cfg => t2080_sd_rcw.cfg}   |  2 +-
 .../t208xqds/{t2080_rcw.cfg => t2080_spi_rcw.cfg}  |  2 +-
 .../t208xqds/{t2081_rcw.cfg => t2081_nand_rcw.cfg} |  0
 .../t208xqds/{t2081_rcw.cfg => t2081_sd_rcw.cfg}   |  2 +-
 .../t208xqds/{t2081_rcw.cfg => t2081_spi_rcw.cfg}  |  2 +-
 .../t208xrdb/{t2080_rcw.cfg => t2080_nand_rcw.cfg} |  0
 .../t208xrdb/{t2080_rcw.cfg => t2080_sd_rcw.cfg}   |  2 +-
 .../t208xrdb/{t2080_rcw.cfg => t2080_spi_rcw.cfg}  |  2 +-
 .../t4qds/{t4_rcw.cfg => t4_nand_rcw.cfg}  |  2 +-
 .../{t4rdb/t4_rcw.cfg => t4qds/t4_sd_rcw.cfg}  |  6 +-
 include/configs/T102xQDS.h |  4 +-
 include/configs/T102xRDB.h | 20 --
 include/configs/T104xRDB.h | 78 +-
 include/configs/T208xQDS.h | 20 --
 include/configs/T208xRDB.h |  4 +-
 include/configs/T4240QDS.h |  3 +-
 include/configs/T4240RDB.h |  2 +-
 42 files changed, 125 insertions(+), 58 deletions(-)
 copy board/freescale/t102xqds/{t1024_rcw.cfg => t1024_nand_rcw.cfg} (100%)
 copy board/freescale/t102xqds/{t1024_rcw.cfg => t1024_sd_rcw.cfg} (89%)
 rename board/freescale/t102xqds/{t1024_rcw.cfg => t1024_spi_rcw.cfg} (89%)
 copy board/freescale/t102xrdb/{t1023_rcw.cfg => t1023_nand_rcw.cfg} (100%)
 copy board/freescale/t102xrdb/{t1023_rcw.cfg => t1023_sd_rcw.cfg} (87%)
 rename board/freescale/t102xrdb/{t1023_rcw.cfg => t1023_spi_rcw.cfg} (87%)
 copy board/freescale/t102xrdb/{t1024_rcw.cfg => t1024_nand_rcw.cfg} (100%)
 copy board/freescale/t102xrdb/{t1024_rcw.cfg => t1024_sd_rcw.cfg} (87%)
 rename board/freescale/t102xrdb/{t1024_rcw.cfg => t1024_spi_rcw.cfg} (87%)
 copy board/freescale/t104xrdb/{t1040_rcw.cfg => t1040_nand_rcw.cfg} (100%)
 copy board/freescale/t104xrdb/{t1040_rcw.cfg => t1040_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1040_rcw.cfg => t1040_spi_rcw.cfg} (83%)
 copy board/freescale/t104xrdb/{t1040d4_rcw.cfg => t1040d4_nand_rcw.cfg} (100%)
 copy board/freescale/t104xrdb/{t1040d4_rcw.cfg => t1040d4_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1040d4_rcw.cfg => t1040d4_spi_rcw.cfg} (83%)
 copy board/freescale/t104xrdb/{t1042_rcw.cfg => t1042_nand_rcw.cfg} (100%)
 copy board/freescale/t104xrdb/{t1042_pi_rcw.cfg => t1042_pi_nand_rcw.cfg} 
(100%)
 copy board/freescale/t104xrdb/{t1042_pi_rcw.cfg => t1042_pi_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1042_pi_rcw.cfg => t1042_pi_spi_rcw.cfg} 
(83%)
 copy board/freescale/t104xrdb/{t1042_rcw.cfg => t1042_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1042_rcw.cfg => t1042_spi_rcw.cfg} (83%)
 copy board/freescale/t104xrdb/{t1042d4_rcw.cfg => t1042d4_nand_rcw.cfg} (100%)
 copy board/freescale/t104xrdb/{t1042d4_rcw.cfg => t1042d4_sd_rcw.cfg} (83%)
 rename board/freescale/t104xrdb/{t1042d4_rcw.cfg => t1042d4_spi_rcw.cfg} (83%)
 copy board/freescale/t208xqds/{t2080_rcw.cfg => 

Re: [U-Boot] [PATCH v6 01/10] x86: Move table csum into separate file

[Bin Meng]

On Fri, Aug 19, 2016 at 7:23 AM, Alexander Graf  wrote:
> We need the checksum function without all the other table functionality
> soon, so let's split it out into its own C file.
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> v5 -> v6:
>
>   - Move to C file
> ---
>  arch/x86/include/asm/tables.h |  2 ++
>  arch/x86/lib/tables.c | 12 
>  include/tables_csum.h | 12 
>  lib/Makefile  |  1 +
>  lib/tables_csum.c | 20 
>  5 files changed, 35 insertions(+), 12 deletions(-)
>  create mode 100644 include/tables_csum.h
>  create mode 100644 lib/tables_csum.c
>

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

Re: [U-Boot] [PATCH v6 07/10] smbios: Generate type 4 on non-x86 systems

[Bin Meng]

On Fri, Aug 19, 2016 at 7:23 AM, Alexander Graf  wrote:
> The type 4 table generation code is very x86 centric today. Refactor things
> out into the device model cpu class to allow the tables to get generated for
> other architectures as well.
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> v3 -> v4:
>
>   - Use device model
>
> v4 -> v5:
>
>   - s/get_info/get_vendor/ typo
>   - s/smbios_write_type4_arch/smbios_write_type4_dm/
>
> v5 -> v6:
>
>   - Split cpu hunks into separate patches
> ---
>  include/smbios.h |  3 +++
>  lib/smbios.c | 51 ++-
>  2 files changed, 41 insertions(+), 13 deletions(-)
>

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

Re: [U-Boot] [PATCH v6 06/10] cpu: Add get_vendor callback

[Bin Meng]

On Fri, Aug 19, 2016 at 7:23 AM, Alexander Graf  wrote:
> The CPU udevice already has a few callbacks to retreive information
> about the currently running CPUs. This patch adds a new get_vendor()
> call that returns the vendor of the main CPUs.
>
> Signed-off-by: Alexander Graf 
> ---
>  arch/x86/cpu/baytrail/cpu.c  |  1 +
>  arch/x86/cpu/broadwell/cpu.c |  1 +
>  arch/x86/cpu/cpu_x86.c   | 13 +
>  arch/x86/cpu/ivybridge/model_206ax.c |  1 +
>  arch/x86/include/asm/cpu_x86.h   | 13 +
>  drivers/cpu/cpu-uclass.c | 10 ++
>  include/cpu.h| 20 
>  7 files changed, 59 insertions(+)
>

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

Re: [U-Boot] [PATCH v6 05/10] cpu: Add DMTF id and family fields

[Bin Meng]

On Fri, Aug 19, 2016 at 7:23 AM, Alexander Graf  wrote:
> For SMBIOS tables we need to know the CPU family as well as CPU IDs. This
> patches allocates some space for them in the cpu device and populates it
> on x86.
>
> Signed-off-by: Alexander Graf 
> ---
>  arch/x86/cpu/cpu_x86.c | 5 +
>  include/cpu.h  | 2 ++
>  2 files changed, 7 insertions(+)
>

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

Re: [U-Boot] [PATCH] fsl-ifc-nand : Corrected the programming of chip select

[Scott Wood]

On 09/06/2016 02:31 PM, Ronak Desai wrote:
> We don't need to update fsl_ifc_sram_init() as fsl_ifc_sram_init is
> called from the fsl_ifc_chip_init which configures the ifc_ctrl->cs_nand
> with correct value based on the chip-select under initialization. 
> 
> Best Regards,
> Ronak Desai

We don't *need* to but we should.  Chipselect is a property of the chip,
not the controller, so it doesn't belong in the controller struct
(unless it's going to be updated per-transaction like page, column, etc.
but we already have priv->bank so let's just use it).

-Scott

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

[U-Boot] [PATCH v3 2/2] pbl: use "wait" command instead of "flush" command

[Zhao Qiang]

FLUSH command is restricted to CCSR board. So use WAIT
command in case of non-CCSR board.

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- split to two patches
Changes for v3:
- modify commit msg

 board/freescale/t208xqds/t208x_pbi.cfg | 3 +--
 board/freescale/t208xrdb/t2080_pbi.cfg | 3 +--
 board/freescale/t4qds/t4_pbi.cfg   | 3 +--
 board/freescale/t4rdb/t4_pbi.cfg   | 3 +--
 tools/pblimage.c   | 2 +-
 5 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/board/freescale/t208xqds/t208x_pbi.cfg 
b/board/freescale/t208xqds/t208x_pbi.cfg
index e200d92..43be8a8 100644
--- a/board/freescale/t208xqds/t208x_pbi.cfg
+++ b/board/freescale/t208xqds/t208x_pbi.cfg
@@ -37,5 +37,4 @@
 0914 ff00
 0918 8100
 #Flush PBL data
-09138000 
-091380c0 
+091380c0 0010
diff --git a/board/freescale/t208xrdb/t2080_pbi.cfg 
b/board/freescale/t208xrdb/t2080_pbi.cfg
index e200d92..43be8a8 100644
--- a/board/freescale/t208xrdb/t2080_pbi.cfg
+++ b/board/freescale/t208xrdb/t2080_pbi.cfg
@@ -37,5 +37,4 @@
 0914 ff00
 0918 8100
 #Flush PBL data
-09138000 
-091380c0 
+091380c0 0010
diff --git a/board/freescale/t4qds/t4_pbi.cfg b/board/freescale/t4qds/t4_pbi.cfg
index 6126266..8d46003 100644
--- a/board/freescale/t4qds/t4_pbi.cfg
+++ b/board/freescale/t4qds/t4_pbi.cfg
@@ -18,5 +18,4 @@
 0914 ff00
 0918 8100
 #Flush PBL data
-09138000 
-091380c0 
+091380c0 0010
diff --git a/board/freescale/t4rdb/t4_pbi.cfg b/board/freescale/t4rdb/t4_pbi.cfg
index e7bb673..0b326fa 100644
--- a/board/freescale/t4rdb/t4_pbi.cfg
+++ b/board/freescale/t4rdb/t4_pbi.cfg
@@ -24,5 +24,4 @@
 0914 ff00
 0918 8100
 #Flush PBL data
-09138000 
-091380c0 
+091380c0 0010
diff --git a/tools/pblimage.c b/tools/pblimage.c
index d74fde9..16d94c98 100644
--- a/tools/pblimage.c
+++ b/tools/pblimage.c
@@ -297,7 +297,7 @@ int pblimage_check_params(struct image_tool_params *params)
pbi_crc_cmd1 = 0x13;
pbi_crc_cmd2 = 0x80;
pbl_cmd_initaddr = 0x8200;
-   pbl_end_cmd[0] = 0x09138000;
+   pbl_end_cmd[0] = 0x091380c0;
pbl_end_cmd[1] = 0x;
pbl_end_cmd[2] = 0x091380c0;
pbl_end_cmd[3] = 0x;
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -Original Message-
> From: york sun
> Sent: Tuesday, September 06, 2016 9:10 PM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
> 
> On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
> > IFC IP clock is always a constant divisor of platform clock
> > pre-defined per SoC. Clock Control register (CCR) used in
> > current implementation governs IFC IP output clock.
> >
> > So update IFC IP clock to be defined as per predefined clock
> > divisor of platform clock.
> >
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> >  README  |  3 +++
> >  arch/arm/cpu/armv7/ls102xa/clock.c  | 10 ++
> >  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++
> >  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++
> >  arch/arm/include/asm/arch-fsl-layerscape/config.h   |  3 +++
> >  arch/arm/include/asm/arch-ls102xa/config.h  |  1 +
> >  arch/powerpc/cpu/mpc85xx/speed.c| 10 ++
> >  arch/powerpc/include/asm/config_mpc85xx.h   |  9 +
> >  8 files changed, 24 insertions(+), 32 deletions(-)
> 
> Prabkahar,
> 
> Two concerns here
> 
> 1, it is not only IFC for powerpc. Older SoCs have local bus. That's why
> the variable is named freq_localbus..
> 

As per my understanding, Issue is valid for eLBC SoC also.
Just wanted to confirm from internal IP team before spinning patch to fix it. 

> 2, what's the reason for this change? Is it wrong to use ccr to
> calculate the clock? Or is it because recent Layerscape SoCs have
> platform PLL different from platform clock? If the latter, can we limit
> the fix to platform clock and not changing powerpc?
> 

CCR governs the IFC output clock. 
This clock is used for synchronous NOR, NAND flashes. It is nowhere govern IFC 
IP internal clock. 

It is true since conception of IFC. Unfortunately code written is wrong since 
P1010. 
It is confusing everyone.  

--prabhakar

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

[U-Boot] [Patch v5 6/9] armv8: ls1046a: Enable DDR erratum for ls1046a

[Gong Qianyu]

From: Shengzhou Liu 

Enable ERRATUM_A008511, ERRATUM_A009801, ERRATUM_A009803,
ERRATUM_A009942, ERRATUM_A010165

Signed-off-by: Shengzhou Liu 
Signed-off-by: Gong Qianyu 
---
v3-v5:
 - No change.
v2:
 - Add ERRATUM_A008511.

 arch/arm/include/asm/arch-fsl-layerscape/config.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 430c85b..329f08f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -236,6 +236,12 @@
 #define GICC_BASE  0x0142
 
 #define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  1
+
+#define CONFIG_SYS_FSL_ERRATUM_A008511
+#define CONFIG_SYS_FSL_ERRATUM_A009801
+#define CONFIG_SYS_FSL_ERRATUM_A009803
+#define CONFIG_SYS_FSL_ERRATUM_A009942
+#define CONFIG_SYS_FSL_ERRATUM_A010165
 #else
 #error SoC not defined
 #endif
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch v5 1/9] ddr: fsl: fix a compile issue

[Gong Qianyu]

From: Shaohui Xie 

When CONFIG_SYS_FSL_ERRATUM_A009801 is defined but
CONFIG_SYS_FSL_ERRATUM_A008511 not defined, there is compile error that
temp32 undeclared, this patch fixes it.

Signed-off-by: Shaohui Xie 
Signed-off-by: Gong Qianyu 
---
v2-v5:
 - No change.

 drivers/ddr/fsl/fsl_ddr_gen4.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/fsl/fsl_ddr_gen4.c b/drivers/ddr/fsl/fsl_ddr_gen4.c
index aaf7c02..042af09 100644
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -50,8 +50,13 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
u32 temp_sdram_cfg;
u32 total_gb_size_per_controller;
int timeout;
+#if defined(CONFIG_SYS_FSL_ERRATUM_A008511) || \
+   defined(CONFIG_SYS_FSL_ERRATUM_A009801)
+   u32 temp32;
+#endif
+
 #ifdef CONFIG_SYS_FSL_ERRATUM_A008511
-   u32 temp32, mr6;
+   u32 mr6;
u32 vref_seq1[3] = {0x80, 0x96, 0x16};  /* for range 1 */
u32 vref_seq2[3] = {0xc0, 0xf0, 0x70};  /* for range 2 */
u32 *vref_seq = vref_seq1;
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v2 1/3] warp7: Add a secure mode target

[Fabio Estevam]

Hi Stefano,

On Tue, Sep 6, 2016 at 5:09 AM, Stefano Babic  wrote:
> On 26/08/2016 02:07, Fabio Estevam wrote:
>> From: Fabio Estevam 
>>
>> NXP kernel expects to boot in secure mode, so introduce
>> warp7_secure_defconfig target which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT.
>>
>> Signed-off-by: Fabio Estevam 
>> ---
>
> Applied to u-boot-imx, thanks !

I don't see this series applied in
http://git.denx.de/?p=u-boot/u-boot-imx.git;a=shortlog

Are they missing?

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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

IFC IP clock is always a constant divisor of platform clock
pre-defined per SoC. Clock Control register (CCR) used in
current implementation governs IFC IP output clock.

So update IFC IP clock to be defined as per predefined clock
divisor of platform clock.

Signed-off-by: Prabhakar Kushwaha 
---
 README  |  3 +++
 arch/arm/cpu/armv7/ls102xa/clock.c  | 10 ++
 arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++
 arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++
 arch/arm/include/asm/arch-fsl-layerscape/config.h   |  3 +++
 arch/arm/include/asm/arch-ls102xa/config.h  |  1 +
 arch/powerpc/cpu/mpc85xx/speed.c| 10 ++
 arch/powerpc/include/asm/config_mpc85xx.h   |  9 +
 8 files changed, 24 insertions(+), 32 deletions(-)

diff --git a/README b/README
index 30d7ee3..873a24c 100644
--- a/README
+++ b/README
@@ -533,6 +533,9 @@ The following options need to be configured:
CONFIG_SYS_FSL_IFC_LE
Defines the IFC controller register space as Little Endian
 
+   CONFIG_SYS_FSL_IFC_CLK_DIV
+   Defines divider of platform clock(clock input to IFC 
controller).
+
CONFIG_SYS_FSL_PBL_PBI
It enables addition of RCW (Power on reset configuration) in 
built image.
Please refer doc/README.pblimage for more details
diff --git a/arch/arm/cpu/armv7/ls102xa/clock.c 
b/arch/arm/cpu/armv7/ls102xa/clock.c
index 7a337e1..5d0411f 100644
--- a/arch/arm/cpu/armv7/ls102xa/clock.c
+++ b/arch/arm/cpu/armv7/ls102xa/clock.c
@@ -19,10 +19,6 @@ DECLARE_GLOBAL_DATA_PTR;
 void get_sys_info(struct sys_info *sys_info)
 {
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
-#ifdef CONFIG_FSL_IFC
-   struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
-   u32 ccr;
-#endif
struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_LS1_CLK_ADDR);
unsigned int cpu;
const u8 core_cplx_pll[6] = {
@@ -74,10 +70,8 @@ void get_sys_info(struct sys_info *sys_info)
}
 
 #if defined(CONFIG_FSL_IFC)
-   ccr = in_be32(_regs.gregs->ifc_ccr);
-   ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1;
-
-   sys_info->freq_localbus = sys_info->freq_systembus / ccr;
+   sys_info->freq_localbus = sys_info->freq_systembus /
+   CONFIG_SYS_FSL_IFC_CLK_DIV;
 #endif
 }
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
index 8922197..dbc56af 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
@@ -22,10 +22,6 @@ DECLARE_GLOBAL_DATA_PTR;
 void get_sys_info(struct sys_info *sys_info)
 {
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
-#ifdef CONFIG_FSL_IFC
-   struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
-   u32 ccr;
-#endif
 #if (defined(CONFIG_FSL_ESDHC) &&\
defined(CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK)) ||\
defined(CONFIG_SYS_DPAA_FMAN)
@@ -153,10 +149,8 @@ void get_sys_info(struct sys_info *sys_info)
 #endif
 
 #if defined(CONFIG_FSL_IFC)
-   ccr = ifc_in32(_regs.gregs->ifc_ccr);
-   ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1;
-
-   sys_info->freq_localbus = sys_info->freq_systembus / ccr;
+   sys_info->freq_localbus = sys_info->freq_systembus /
+   CONFIG_SYS_FSL_IFC_CLK_DIV;
 #endif
 }
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
index a9b12a4..3b8389e 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
@@ -26,10 +26,6 @@ DECLARE_GLOBAL_DATA_PTR;
 void get_sys_info(struct sys_info *sys_info)
 {
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
-#ifdef CONFIG_FSL_IFC
-   struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
-   u32 ccr;
-#endif
struct ccsr_clk_cluster_group __iomem *clk_grp[2] = {
(void *)(CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR),
(void *)(CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR)
@@ -129,10 +125,8 @@ void get_sys_info(struct sys_info *sys_info)
}
 
 #if defined(CONFIG_FSL_IFC)
-   ccr = ifc_in32(_regs.gregs->ifc_ccr);
-   ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1;
-
-   sys_info->freq_localbus = sys_info->freq_systembus / ccr;
+   sys_info->freq_localbus = sys_info->freq_systembus /
+   CONFIG_SYS_FSL_IFC_CLK_DIV;
 #endif
 }
 
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 

Re: [U-Boot] [PATCH] Increase default of CONFIG_SYS_MALLOC_F_LEN for SPL_OF_CONTROL

[Simon Glass]

Hi Masahiro,

On 6 September 2016 at 06:24, Masahiro Yamada
 wrote:
>
> 2016-09-06 10:04 GMT+09:00 Simon Glass :
> > On 30 August 2016 at 03:56, Stefan Roese  wrote:
> >> On 30.08.2016 11:50, Masahiro Yamada wrote:
> >>>
> >>> If both SPL_DM and SPL_OF_CONTROL are enabled, SPL needs to bind
> >>> several devices, but CONFIG_SYS_MALLOC_F_LEN=0x400 is apparently
> >>> not enough.  Increase the default to 0x2000 for the case.  This
> >>> will be helpful for shorter defconfigs.
> >>>
> >>> Signed-off-by: Masahiro Yamada 
> >>
> >>
> >> Reviewed-by: Stefan Roese 
> >
> > Reviewed-by: Simon Glass 
> >
> > It would be worth checking why. I fixed a bug where simple-bus would
> > bring in all devices regardless of the u-boot,dm-pre-reloc flag.
> > Perhaps that was it?
>
> I do not think so.
>
> Recently I tested this.  In spite of "u-boot,dm-pre-reloc"
> in the SPL device tree, my board failed in SPL.
>
> I guess CONFIG_SYS_MALLOC_F_LEN=0x400 is not enough
> for binding/probing UART, pinctrl, MMC in SPL.
>
> I increased the malloc size and it worked fine.

You could turn on DEBUG in common/spl/spl.c and it will print out how
much memory is used. But by making it the default you are affecting a
lot of boards which don't use pinctrl, etc. 8KB is a lot for some
boards.

On the other hand we should make sure that it gives a sensible error
when running out of memory, perhaps something like this:

http://patchwork.ozlabs.org/patch/561551/

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

Re: [U-Boot] [PATCH] TI: Rework SRAM definitions and maximums

[Ladislav Michl]

On Sat, Aug 27, 2016 at 05:29:44PM +0530, Lokesh Vutla wrote:
> On Friday 26 August 2016 11:00 PM, Tom Rini wrote:
> > On all TI platforms the ROM defines a "downloaded image" area at or near
> > the start of SRAM which is followed by a reserved area.  As it is at
> > best bad form and at worst possibly harmful in corner cases to write in
> > this reserved area, we stop doing that by adding in the define
> > NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image
> > area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this.
> > At current we define the end of scratch space at 0x228 bytes past the
> > start of scratch space this this gives us a lot of room to grow.  As
> > these scratch uses are non-optional today, all targets are modified to
> > respect this boundary.
> > 
> > Tested on OMAP4 Pandaboard, OMAP3 Beagle xM
> 
> Verified on AM437x-GP EVM.
> 
> Tested-by: Lokesh Vutla 
> Acked-by: Lokesh Vutla 

Verified on IGEPv2.

Tested-by: Ladislav Michl 

Also note, that this patch and CONFIG_SPL_SYS_MALLOC_SIMPLE is needed
for sucessfull build (with gcc-5.4.0), otherwise compilation fails with:
arm-v7a-linux-gnueabi-ld.bfd: u-boot-spl section `.data' will not fit in region 
`.sram'
arm-v7a-linux-gnueabi-ld.bfd: region `.sram' overflowed by 264 bytes
Just enabling CONFIG_SPL_SYS_MALLOC_SIMPLE without this patch makes
malloc in fat loading code fail and thus causes boot failure.

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

[U-Boot] [Patch v5 0/9] Add LS1046ARDB board support

[Gong Qianyu]

Hi all,

This is version 5 patchset mainly to add support for both LS1046ARDB board.
It should be based on two DDR patches to work well on LS1046ARDB or LS1046AQDS.
The two patches are:
http://patchwork.ozlabs.org/patch/663534/
http://patchwork.ozlabs.org/patch/663535/

PCIe and USB are not supported yet due to lack of some driver patches
and I'll send them to upstream once they're ready.
Please help to review. Thanks very much!

Changes in v5:
 - Add a new patch to remove BSS clearing and board_init_r in spl.c. 
 - Fix SPL_PAD_TO size to block aligned value for NAND boot.
 - Adjust the SPL BSS and MALLOC address for future use.
Changes in v4:
 - Extend SPL max size and pad_to size for SD boot.
 - Add LS1046AQDS board support patch.
Changes in v3:
 - Remove redundant sd rcw .cfg files.
 - Adjust the format of memory map in readme.
 - Add emmc boot support.
Changes in v2:
 - Add ERRATUM_A008511.
 - Use values directly instead of macros for SATA ECC. 
 - Add >60 characters' paragraph for the board help.
 - Fix the memory map in readme.
 - Remove unused flash r/w functions.
 - Remove DDR3 defines.
 - Revise some commit messages.

Gong Qianyu (1):
  armv8: fsl-layerscape: spl: remove BSS clearing and board_init_r

Mingkai Hu (2):
  armv8: fsl-layerscape: Increase L2 Data RAM latency and L2 Tag RAM
latency
  armv8: ls1046ardb: Add LS1046ARDB board support

Shaohui Xie (5):
  ddr: fsl: fix a compile issue
  Export memset for standalone AQ FW load apps
  armv8: fsl-layerscape: add define CONFIG_STANDALONE_LOAD_ADDR for
standalone app
  armv8: ls1046a: disable SATA ECC in DCSR
  armv8: ls1046aqds: Add LS1046AQDS board support

Shengzhou Liu (1):
  armv8: ls1046a: Enable DDR erratum for ls1046a

 arch/arm/Kconfig   |  24 +
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |  15 +
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   4 +
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|   5 -
 arch/arm/dts/Makefile  |   3 +
 arch/arm/dts/fsl-ls1046a-qds-duart.dts |  16 +
 arch/arm/dts/fsl-ls1046a-qds-lpuart.dts|  16 +
 arch/arm/dts/fsl-ls1046a-qds.dtsi  |  81 
 arch/arm/dts/fsl-ls1046a-rdb.dts   |  44 ++
 arch/arm/dts/fsl-ls1046a.dtsi  | 220 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |   8 +
 board/freescale/common/vid.c   |   8 +-
 board/freescale/ls1046aqds/Kconfig |  15 +
 board/freescale/ls1046aqds/MAINTAINERS |  11 +
 board/freescale/ls1046aqds/Makefile|   9 +
 board/freescale/ls1046aqds/README  |  70 +++
 board/freescale/ls1046aqds/ddr.c   | 140 ++
 board/freescale/ls1046aqds/ddr.h   |  44 ++
 board/freescale/ls1046aqds/eth.c   | 415 +
 board/freescale/ls1046aqds/ls1046aqds.c| 313 +
 board/freescale/ls1046aqds/ls1046aqds_pbi.cfg  |  17 +
 board/freescale/ls1046aqds/ls1046aqds_qixis.h  |  39 ++
 board/freescale/ls1046aqds/ls1046aqds_rcw_nand.cfg |   7 +
 .../freescale/ls1046aqds/ls1046aqds_rcw_sd_ifc.cfg |   8 +
 .../ls1046aqds/ls1046aqds_rcw_sd_qspi.cfg  |   8 +
 board/freescale/ls1046ardb/Kconfig |  16 +
 board/freescale/ls1046ardb/MAINTAINERS |   9 +
 board/freescale/ls1046ardb/Makefile|  10 +
 board/freescale/ls1046ardb/README  |  76 
 board/freescale/ls1046ardb/cpld.c  | 158 +++
 board/freescale/ls1046ardb/cpld.h  |  49 ++
 board/freescale/ls1046ardb/ddr.c   | 140 ++
 board/freescale/ls1046ardb/ddr.h   |  44 ++
 board/freescale/ls1046ardb/eth.c   |  77 
 board/freescale/ls1046ardb/ls1046ardb.c| 136 ++
 board/freescale/ls1046ardb/ls1046ardb_pbi.cfg  |  22 +
 board/freescale/ls1046ardb/ls1046ardb_rcw_emmc.cfg |   7 +
 board/freescale/ls1046ardb/ls1046ardb_rcw_sd.cfg   |   7 +
 configs/ls1046aqds_defconfig   |  28 ++
 configs/ls1046aqds_lpuart_defconfig|  29 ++
 configs/ls1046aqds_nand_defconfig  |  30 ++
 configs/ls1046aqds_qspi_defconfig  |  30 ++
 configs/ls1046aqds_sdcard_ifc_defconfig|  30 ++
 configs/ls1046aqds_sdcard_qspi_defconfig   |  31 ++
 configs/ls1046ardb_emmc_defconfig  |  26 ++
 configs/ls1046ardb_qspi_defconfig  |  25 ++
 configs/ls1046ardb_sdcard_defconfig|  26 ++
 drivers/ddr/fsl/fsl_ddr_gen4.c |   7 +-
 include/_exports.h |   1 +
 include/configs/ls1046a_common.h   | 211 +
 include/configs/ls1046aqds.h   | 494 +
 include/configs/ls1046ardb.h   | 242 ++
 include/exports.h

Re: [U-Boot] [PATCH RFC 5/5] imx: mx6ul: Add initial board support for Engicam GEAM6UL

[Tom Rini]

On Sun, Sep 04, 2016 at 11:47:06AM -0300, Fabio Estevam wrote:
> On Sun, Sep 4, 2016 at 10:32 AM, Jagan Teki  wrote:
> 
> > Please do read the thread fully before commenting, I've mentioned the
> > state of hardware when I relied to Peng. And also this is an RFC patch
> > I'm looking for comments on function like changes whether the flow of
> > adding code to existing software is meaningful or not and not intended
> > to directly applying these onto ML.
> 
> I have already stated my opinion that you should put your board code
> into board/engicam.

Yes, this sounds right.

> > But I prefer to maintain the same on board/freescale/imx6ul. Becuase,
> > If the most of the code is common to all boards with specific SOC it's
> > better to have common code for reusability instead of adding different
> > board files with duplicate code. For example please see board/sunxi or
> > board/xilinx/zynq where microzed, zed or zynbo not directly
> > manufactured from xilinx but they maintained as common.
> 
> All the ifdefery inside board/sunxi/board.c is exactly what I would
> like to avoid here.

Now, in fairness to sunxi, that's more like what would happen if you
decided to support all of the imx6 and imx7 SoCs in a single board.c.

> mx6ul is a recent SoC and there is only mx6ul evk and pico mx6ul
> boards currently supported in U-Boot.
> 
> I don't think this can scale to support all upcoming boards into a
> single board/freescale/mx6ul/board.c.
> 
> Why is mx6ul special in this case compared to the other mx6 variants?
> 
> Will you be able to support all mx6q boards into
> board/freescale/mx6q/board.c as well?
> 
> I am sure this will be unmaintainable.

I suspect there's a certain amount of code that should be in
arch/arm/mach-imx/board.c like a __weak dram_init() and maybe some
${soc}.c files too for things that really aren't board specific but
rather SoC-required.  Of course I'm biased since this is how the TI
stuff evolved to.

But also, if the enigcam board is an example of "take the ref board, cut
it down a bit, ship" or even "take the ref board, tweak slightly", there
will still be some code duplication as they simply made the same board
decisions that NXP did in the reference platform.

-- 
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 6/7] dts: evb-rk3399: add init voltage node for vdd-center

[Kever Yang]

Hi Simon,

On 09/06/2016 09:04 AM, Simon Glass wrote:

Hi Kever,

On 29 August 2016 at 21:02, Kever Yang  wrote:

This patch add regulator-init-microvolt for pwm regulator
to get a init value when driver do probe init.

How about:

Add a regulator-init-microvolt value for the vd_center regulator so that  

(please complete the sentence - commits should explain why they are
needed if it isn't obvious)



OK, will update in next version patch.

Thanks,
- Kever

Signed-off-by: Kever Yang 
---

  arch/arm/dts/rk3399-evb.dts | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index bd7801b..fa60e19 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -23,6 +23,7 @@
 regulator-name = "vdd_center";
 regulator-min-microvolt = <80>;
 regulator-max-microvolt = <140>;
+   regulator-init-microvolt = <95>;
 regulator-always-on;
 regulator-boot-on;
 status = "okay";
--
1.9.1


Regards,
Simon






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

[U-Boot] [Patch v5 4/9] armv8: fsl-layerscape: add define CONFIG_STANDALONE_LOAD_ADDR for standalone app

[Gong Qianyu]

From: Shaohui Xie 

The CONFIG_STANDALONE_LOAD_ADDR is set to 0x8030 by default.

Signed-off-by: Shaohui Xie 
Signed-off-by: Gong Qianyu 
---
v2-v5:
 - No change.

 arch/arm/include/asm/arch-fsl-layerscape/config.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 5279981..430c85b 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -9,6 +9,8 @@
 
 #include 
 
+#define CONFIG_STANDALONE_LOAD_ADDR0x8030
+
 #ifdef CONFIG_SYS_FSL_DDR4
 #define CONFIG_SYS_FSL_DDRC_GEN4
 #else
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch v5 3/9] armv8: fsl-layerscape: Increase L2 Data RAM latency and L2 Tag RAM latency

[Gong Qianyu]

From: Mingkai Hu 

According to design specification, the L2 cache operates at the same
frequency as the A72 CPUs in the cluster with a 3-cycle latency, so
increase the L2 Data RAM and Tag RAM latency to 3 cycles, or else,
will run into different call trace issues.

Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
v3-v5:
 - No change.
v2:
 - Revise commit message.

 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 5af6b73..6451a36 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -179,6 +179,21 @@ ENTRY(lowlevel_init)
isb
dsb sy
 #endif
+
+#ifdef CONFIG_LS1046A
+   /* Initialize the L2 RAM latency */
+   mrs   x1, S3_1_c11_c0_2
+   mov   x0, #0x1C7
+   /* Clear L2 Tag RAM latency and L2 Data RAM latency */
+   bic   x1, x1, x0
+   /* Set L2 data ram latency bits [2:0] */
+   orr   x1, x1, #0x2
+   /* set L2 tag ram latency bits [8:6] */
+   orr   x1,  x1, #0x80
+   msr   S3_1_c11_c0_2, x1
+   isb
+#endif
+
mov lr, x29 /* Restore LR */
ret
 ENDPROC(lowlevel_init)
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH] efi_loader: Allow bouncing for network

[Alexander Graf]

So far bounce buffers were only used for disk I/O, but network I/O
may suffer from the same problem.

On platforms that have problems doing DMA on high addresses, let's
also bounce outgoing network packets. Incoming ones always already
get bounced.

This patch fixes EFI PXE boot on ZynqMP for me.

Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_net.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index dd3b485..6a8a0d7 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -152,7 +152,14 @@ static efi_status_t EFIAPI efi_net_transmit(struct 
efi_simple_network *this,
return EFI_EXIT(EFI_INVALID_PARAMETER);
}
 
+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+   /* Ethernet packets always fit, just bounce */
+   memcpy(efi_bounce_buffer, buffer, buffer_size);
+   net_send_packet(efi_bounce_buffer, buffer_size);
+#else
net_send_packet(buffer, buffer_size);
+#endif
+
new_tx_packet = buffer;
 
return EFI_EXIT(EFI_SUCCESS);
-- 
1.8.5.6

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

Re: [U-Boot] [PATCH 11/11] arm: socfpga: Add support for Stratix 10 SoC dev kit

[Marek Vasut]

On 09/06/2016 11:18 AM, Chin Liang See wrote:
> On Mon, 2016-09-05 at 18:06 +0200, Marek Vasut wrote:
>> On 08/22/2016 05:02 PM, Chin Liang See wrote:
>>> Add support for Stratix 10 SoC development kit
>>>
>>> Signed-off-by: Chin Liang See 
>>> Cc: Marek Vasut 
>>> Cc: Dinh Nguyen 
>>> Cc: Ley Foon Tan 
>>> ---
>>>  arch/arm/Kconfig  |   7 +-
>>>  arch/arm/mach-socfpga/Kconfig |  10 +++
>>>  configs/socfpga_stratix10_defconfig   |  14 
>>>  include/configs/socfpga_stratix10_socdk.h | 135
>>> ++
>>>  4 files changed, 163 insertions(+), 3 deletions(-)
>>>  create mode 100755 configs/socfpga_stratix10_defconfig
>>>  create mode 100644 include/configs/socfpga_stratix10_socdk.h
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index aef901c..c8e8767 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -600,10 +600,11 @@ config ARCH_SNAPDRAGON
>>>  
>>>  config ARCH_SOCFPGA
>>> bool "Altera SOCFPGA family"
>>> -   select CPU_V7
>>> -   select SUPPORT_SPL
>>> +   select CPU_V7 if !TARGET_SOCFPGA_STRATIX10
>>> +   select ARM64 if TARGET_SOCFPGA_STRATIX10
>>> +   select SUPPORT_SPL if !TARGET_SOCFPGA_STRATIX10
>>> select OF_CONTROL
>>> -   select SPL_OF_CONTROL
>>> +   select SPL_OF_CONTROL if !TARGET_SOCFPGA_STRATIX10
>>
>> Why is the SPL disabled ?
> 
> We will be having SPL for Stratix 10. It will added in later days as
> SPL main function is for DDR setup. This is not needed for SOC Virtual
> Platform now.

Please do things right from the start, add the SPL and skip the DRAM
init if it's not needed.

>>> select DM
>>> select DM_SPI_FLASH
>>> select DM_SPI
>>> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach
>>> -socfpga/Kconfig
>>> index 1a43c7b..4e3b238 100644
>>> --- a/arch/arm/mach-socfpga/Kconfig
>>> +++ b/arch/arm/mach-socfpga/Kconfig
>>> @@ -11,6 +11,9 @@ config TARGET_SOCFPGA_CYCLONE5
>>>  config TARGET_SOCFPGA_GEN5
>>> bool
>>>  
>>> +config TARGET_SOCFPGA_STRATIX10
>>> +   bool
>>> +
>>>  choice
>>> prompt "Altera SOCFPGA board select"
>>> optional
>>> @@ -51,6 +54,10 @@ config TARGET_SOCFPGA_TERASIC_SOCKIT
>>> bool "Terasic SoCkit (Cyclone V)"
>>> select TARGET_SOCFPGA_CYCLONE5
>>>  
>>> +config TARGET_SOCFPGA_STRATIX10_SOCDK
>>> +   bool "Altera SOCFPGA SoCDK (Stratix 10)"
>>> +   select TARGET_SOCFPGA_STRATIX10
>>> +
>>>  endchoice
>>>  
>>>  config SYS_BOARD
>>> @@ -63,6 +70,7 @@ config SYS_BOARD
>>> default "socrates" if TARGET_SOCFPGA_EBV_SOCRATES
>>> default "sr1500" if TARGET_SOCFPGA_SR1500
>>> default "vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
>>> +   default "stratix10-socdk" if
>>> TARGET_SOCFPGA_STRATIX10_SOCDK
>>
>> Keep all the lists sorted .
> 
> Noted, will fix this.
> 
>>
>>>  config SYS_VENDOR
>>> default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK
>>> @@ -72,6 +80,7 @@ config SYS_VENDOR
>>> default "samtec" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
>>> default "terasic" if TARGET_SOCFPGA_TERASIC_DE0_NANO
>>> default "terasic" if TARGET_SOCFPGA_TERASIC_SOCKIT
>>> +   default "altera" if TARGET_SOCFPGA_STRATIX10_SOCDK
>>>  
>>>  config SYS_SOC
>>> default "socfpga"
>>> @@ -86,5 +95,6 @@ config SYS_CONFIG_NAME
>>> default "socfpga_socrates" if TARGET_SOCFPGA_EBV_SOCRATES
>>> default "socfpga_sr1500" if TARGET_SOCFPGA_SR1500
>>> default "socfpga_vining_fpga" if
>>> TARGET_SOCFPGA_SAMTEC_VINING_FPGA
>>> +   default "socfpga_stratix10_socdk" if
>>> TARGET_SOCFPGA_STRATIX10_SOCDK
>>>  
>>>  endif
>>
>> [...]
>>
>> btw. what about Arria 10 ? Will it ever land ?
>> And will I ever get a kit ? :)
> 
> Since S10 is good, I will help out the A10 upstreaming once S10 is
> intergrated. While for dev kit, let me work that out as we have A10 dev
> kit with production silicon :)

The production silicon a10 is still not available ?

> Thanks
> Chin Liang
> 
>>


-- 
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 8/9] net: nfs: Use the tx buffer to construct rpc msgs

[Guillaume Gardet]

Hi Joe,

I tested 2016.09-rc2 on a beagleboard xM and NFS does not work anymore!
When I call the nfs command, I get a "data abort" error with a reboot of the 
board!

A git bisect point to this patch: "net: nfs: Use the tx buffer to construct rpc 
msgs"

Could you have a look and fix it for the release, please? At least revert it 
for now.


Guillaume



Le 15/08/2016 à 22:03, Joe Hershberger a écrit :

Instead of always allocating a huge temporary buffer on the stack and
then memcpy()ing the result into the transmit buffer, simply figure out
where in the transmit buffer the bytes will belong and write them there
directly as each message is built.

Signed-off-by: Joe Hershberger 
---

  net/nfs.c | 88 ---
  1 file changed, 45 insertions(+), 43 deletions(-)

diff --git a/net/nfs.c b/net/nfs.c
index 31047c2..3fb253b 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -183,41 +183,41 @@ static uint32_t *rpc_add_credentials(uint32_t *p)
  /**
  RPC_LOOKUP - Lookup RPC Port numbers
  **/
-static void rpc_req(int rpc_prog, int rpc_proc, uint32_t *data, int datalen)
+static struct rpc_t *rpc_req_prep(void)
+{
+   return (struct rpc_t *)(net_tx_packet + net_eth_hdr_size() +
+   IP_UDP_HDR_SIZE);
+}
+
+static void rpc_req(int rpc_prog, int rpc_proc, struct rpc_t *rpc_pkt,
+   int datalen)
  {
-   struct rpc_t rpc_pkt;
unsigned long id;
-   uint32_t *p;
int pktlen;
int sport;
  
  	id = ++rpc_id;

-   rpc_pkt.u.call.id = htonl(id);
-   rpc_pkt.u.call.type = htonl(MSG_CALL);
-   rpc_pkt.u.call.rpcvers = htonl(2);  /* use RPC version 2 */
-   rpc_pkt.u.call.prog = htonl(rpc_prog);
+   rpc_pkt->u.call.id = htonl(id);
+   rpc_pkt->u.call.type = htonl(MSG_CALL);
+   rpc_pkt->u.call.rpcvers = htonl(2);  /* use RPC version 2 */
+   rpc_pkt->u.call.prog = htonl(rpc_prog);
switch (rpc_prog) {
case PROG_NFS:
if (supported_nfs_versions & NFSV2_FLAG)
-   rpc_pkt.u.call.vers = htonl(2); /* NFS v2 */
+   rpc_pkt->u.call.vers = htonl(2); /* NFS v2 */
else /* NFSV3_FLAG */
-   rpc_pkt.u.call.vers = htonl(3); /* NFS v3 */
+   rpc_pkt->u.call.vers = htonl(3); /* NFS v3 */
break;
case PROG_PORTMAP:
case PROG_MOUNT:
default:
-   rpc_pkt.u.call.vers = htonl(2); /* portmapper is version 2 */
+   /* portmapper is version 2 */
+   rpc_pkt->u.call.vers = htonl(2);
}
-   rpc_pkt.u.call.proc = htonl(rpc_proc);
-   p = (uint32_t *)&(rpc_pkt.u.call.data);
-
-   if (datalen)
-   memcpy((char *)p, (char *)data, datalen*sizeof(uint32_t));
-
-   pktlen = (char *)p + datalen * sizeof(uint32_t) - (char *)_pkt;
+   rpc_pkt->u.call.proc = htonl(rpc_proc);
  
-	memcpy((char *)net_tx_packet + net_eth_hdr_size() + IP_UDP_HDR_SIZE,

-  _pkt.u.data[0], pktlen);
+   pktlen = ((char *)_pkt->u.call.data - (char *)_pkt) +
+   datalen * sizeof(uint32_t);
  
  	if (rpc_prog == PROG_PORTMAP)

sport = SUNRPC_PORT;
@@ -235,15 +235,17 @@ RPC_LOOKUP - Lookup RPC Port numbers
  **/
  static void rpc_lookup_req(int prog, int ver)
  {
-   uint32_t data[16];
+   uint32_t *data;
+   struct rpc_t *rpc_pkt = rpc_req_prep();
  
+	data = rpc_pkt->u.call.data;

data[0] = 0; data[1] = 0;   /* auth credential */
data[2] = 0; data[3] = 0;   /* auth verifier */
data[4] = htonl(prog);
data[5] = htonl(ver);
data[6] = htonl(17);/* IP_UDP */
data[7] = 0;
-   rpc_req(PROG_PORTMAP, PORTMAP_GETPORT, data, 8);
+   rpc_req(PROG_PORTMAP, PORTMAP_GETPORT, rpc_pkt, 8);
  }
  
  /**

@@ -251,14 +253,14 @@ NFS_MOUNT - Mount an NFS Filesystem
  **/
  static void nfs_mount_req(char *path)
  {
-   uint32_t data[1024];
uint32_t *p;
int len;
int pathlen;
+   struct rpc_t *rpc_pkt = rpc_req_prep();
  
  	pathlen = strlen(path);
  
-	p = &(data[0]);

+   p = rpc_pkt->u.call.data;
p = rpc_add_credentials(p);
  
  	*p++ = htonl(pathlen);

@@ -267,9 +269,9 @@ static void nfs_mount_req(char *path)
memcpy(p, path, pathlen);
p += (pathlen + 3) / 4;
  
-	len = (uint32_t *)p - (uint32_t *)&(data[0]);

+   len = (uint32_t *)p - (uint32_t *)&(rpc_pkt->u.call.data);
  
-	rpc_req(PROG_MOUNT, MOUNT_ADDENTRY, data, len);

+   

Re: [U-Boot] [PATCH v2 1/7] include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:36AM -0400, Madan Srinivas wrote:

> The function board_fit_image_post_process is defined only when the config
> CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not
> use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will
> be defined, which will result in an implicit declaration of function
> 'board_fit_image_post_process' warning while building u-boot. This
> patch fixes this warning.
> 
> Signed-off-by: Madan Srinivas 
> Acked-by: Andrew F. Davis 
> 
> Cc: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [Patch v5 5/9] armv8: fsl-layerscape: spl: remove BSS clearing and board_init_r

[Gong Qianyu]

As per the top level U-Boot README "Board Initialisation Flow"
section, board_init_f() should return without calling board_init_r()
directly.
Clearing BSS and calling board_init_r() will be done in crt0_64.S.

Signed-off-by: Gong Qianyu 
---
v5:
 - New Patch.

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

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c 
b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
index 19e34fa..b8e1d75 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
@@ -62,13 +62,8 @@ void board_init_f(ulong dummy)
i2c_init_all();
 #endif
dram_init();
-
-   /* Clear the BSS */
-   memset(__bss_start, 0, __bss_end - __bss_start);
-
 #ifdef CONFIG_LAYERSCAPE_NS_ACCESS
enable_layerscape_ns_access();
 #endif
-   board_init_r(NULL, 0);
 }
 #endif
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 3/7] power: regulator: add pwm regulator

[Simon Glass]

Hi Kever,

On 6 September 2016 at 04:03, Kever Yang  wrote:
> Hi Simon,
>
>
> On 09/06/2016 09:03 AM, Simon Glass wrote:
>>
>> Hi Kever,
>>
>> On 29 August 2016 at 21:02, Kever Yang  wrote:
>>>
>>> This driver add support for pwm regulator.
>>>
>>> Signed-off-by: Elaine Zhang 
>>> Signed-off-by: Kever Yang 
>>> ---
>>>
>>>   drivers/power/regulator/Kconfig |   9 ++
>>>   drivers/power/regulator/Makefile|   1 +
>>>   drivers/power/regulator/pwm_regulator.c | 157
>>> 
>>>   3 files changed, 167 insertions(+)
>>>   create mode 100644 drivers/power/regulator/pwm_regulator.c
>>>
>>> diff --git a/drivers/power/regulator/Kconfig
>>> b/drivers/power/regulator/Kconfig
>>> index 17f22dd..c2eaa84 100644
>>> --- a/drivers/power/regulator/Kconfig
>>> +++ b/drivers/power/regulator/Kconfig
>>> @@ -42,6 +42,15 @@ config DM_REGULATOR_PFUZE100
>>>  features for REGULATOR PFUZE100. The driver implements get/set
>>> api for:
>>>  value, enable and mode.
>>>
>>> +config REGULATOR_PWM
>>> +   bool "Enable driver for PWM regulators"
>>> +   depends on DM_REGULATOR
>>> +   ---help---
>>> +   Enable support for the regulator functions of the PWM. The
>>
>> Does a PWM have regulator functions? Do you mean a board that uses a
>> PWM to control a regulator?
>
>
> Yes, the PWM control the regulator, the voltage is depend on the PWM duty
> ratio.
> The PWM regulator is used in some of rockchip board.

OK please can you update the help a little?

>
>
>>
>>> +   driver implements get/set api for the various BUCKS.
>>> +   This driver is controlled by a device tree node
>>> +   which includes voltage limits.
>>> +
>>>   config DM_REGULATOR_MAX77686
>>>  bool "Enable Driver Model for REGULATOR MAX77686"
>>>  depends on DM_REGULATOR && DM_PMIC_MAX77686
>>> diff --git a/drivers/power/regulator/Makefile
>>> b/drivers/power/regulator/Makefile
>>> index 1590d85..ab461ec 100644
>>> --- a/drivers/power/regulator/Makefile
>>> +++ b/drivers/power/regulator/Makefile
>>> @@ -9,6 +9,7 @@ obj-$(CONFIG_$(SPL_)DM_REGULATOR) += regulator-uclass.o
>>>   obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
>>>   obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
>>>   obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
>>> +obj-$(CONFIG_REGULATOR_PWM) += pwm_regulator.o
>>>   obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
>>>   obj-$(CONFIG_REGULATOR_RK808) += rk808.o
>>>   obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
>>> diff --git a/drivers/power/regulator/pwm_regulator.c
>>> b/drivers/power/regulator/pwm_regulator.c
>>> new file mode 100644
>>> index 000..f75731b
>>> --- /dev/null
>>> +++ b/drivers/power/regulator/pwm_regulator.c
>>> @@ -0,0 +1,157 @@
>>> +/*
>>> + * Copyright (C) 2016 Rockchip Electronics Co., Ltd
>>> + *
>>> + * Based on kernel drivers/regulator/pwm-regulator.c
>>> + * Copyright (C) 2014 - STMicroelectronics Inc.
>>> + * Author: Lee Jones 
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +struct pwm_regulator_info {
>>> +   int pwm_id;
>>
>> Please add a comment for members
>
>
> OK,
>>
>>
>>> +   int period;
>>
>> period_ms is better, if this is milliseconds. Or period_us?
>
>
> Yes, period_ns will be fine, which is used in pwm driver.
>>
>>
>>> +   struct udevice *pwm;
>>> +   unsigned int init_voltage;
>>> +   unsigned int max_voltage;
>>> +   unsigned int min_voltage;
>>> +   unsigned int boot_on;
>>
>> bool?
>
>
> I think this could be removed in next version for it is not used right now.
>
>>
>>> +   unsigned int volt_uV;
>>> +};
>>> +
>>> +static int pwm_regulator_enable(struct udevice *dev, bool enable)
>>> +{
>>> +   struct pwm_regulator_info *priv = dev_get_priv(dev);
>>> +
>>> +   return pwm_set_enable(priv->pwm, priv->pwm_id, enable);
>>> +}
>>> +
>>> +static int pwm_voltage_to_duty_cycle_percentage(struct udevice *dev, int
>>> req_uV)
>>> +{
>>> +   struct pwm_regulator_info *priv = dev_get_priv(dev);
>>> +   int min_uV = priv->min_voltage;
>>> +   int max_uV = priv->max_voltage;
>>> +   int diff = max_uV - min_uV;
>>> +
>>> +   return 100 - (((req_uV * 100) - (min_uV * 100)) / diff);
>>> +}
>>> +
>>> +static int pwm_regulator_get_voltage(struct udevice *dev)
>>> +{
>>> +   struct pwm_regulator_info *priv = dev_get_priv(dev);
>>> +
>>> +   return priv->volt_uV;
>>> +}
>>> +
>>> +static int pwm_regulator_set_voltage(struct udevice *dev, int uvolt)
>>> +{
>>> +   struct pwm_regulator_info *priv = dev_get_priv(dev);
>>> +   int duty_cycle;
>>> +   int ret = 0;
>>> +
>>> +   duty_cycle = pwm_voltage_to_duty_cycle_percentage(dev, 

[U-Boot] [PATCH v3 7/8] arch, board: squash lines for immediate return

[Masahiro Yamada]

Remove unneeded variables and assignments.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - More fixes

 arch/arm/cpu/arm920t/imx/timer.c  |  6 +-
 arch/arm/cpu/armv7/am33xx/sys_info.c  |  4 +---
 arch/arm/cpu/sa1100/timer.c   |  5 +
 arch/arm/mach-zynq/cpu.c  |  8 ++--
 arch/blackfin/cpu/interrupts.c|  5 +
 arch/m68k/lib/time.c  |  4 +---
 arch/powerpc/cpu/mpc512x/cpu.c|  6 +-
 arch/powerpc/cpu/mpc83xx/cpu.c|  6 +-
 arch/xtensa/lib/time.c|  5 +
 board/amcc/bamboo/bamboo.c|  6 +-
 board/amcc/bubinga/bubinga.c  |  5 +
 board/amcc/canyonlands/canyonlands.c  |  6 +-
 board/corscience/tricorder/tricorder-eeprom.c | 20 +---
 board/freescale/common/zm7300.c   |  4 +---
 board/samsung/goni/goni.c |  8 +---
 board/ti/omap5_uevm/evm.c |  5 +
 16 files changed, 21 insertions(+), 82 deletions(-)

diff --git a/arch/arm/cpu/arm920t/imx/timer.c b/arch/arm/cpu/arm920t/imx/timer.c
index b62558f..178422a 100644
--- a/arch/arm/cpu/arm920t/imx/timer.c
+++ b/arch/arm/cpu/arm920t/imx/timer.c
@@ -78,11 +78,7 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk (void)
 {
-   ulong tbclk;
-
-   tbclk = CONFIG_SYS_HZ;
-
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }
 
 /*
diff --git a/arch/arm/cpu/armv7/am33xx/sys_info.c 
b/arch/arm/cpu/armv7/am33xx/sys_info.c
index 52a6824..f42eee1 100644
--- a/arch/arm/cpu/armv7/am33xx/sys_info.c
+++ b/arch/arm/cpu/armv7/am33xx/sys_info.c
@@ -65,9 +65,7 @@ u32 get_device_type(void)
  */
 u32 get_sysboot_value(void)
 {
-   int mode;
-   mode = readl(>statusreg) & (SYSBOOT_MASK);
-   return mode;
+   return readl(>statusreg) & SYSBOOT_MASK;
 }
 
 #ifdef CONFIG_DISPLAY_CPUINFO
diff --git a/arch/arm/cpu/sa1100/timer.c b/arch/arm/cpu/sa1100/timer.c
index 0a0006b..90e2128 100644
--- a/arch/arm/cpu/sa1100/timer.c
+++ b/arch/arm/cpu/sa1100/timer.c
@@ -66,8 +66,5 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk (void)
 {
-   ulong tbclk;
-
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }
diff --git a/arch/arm/mach-zynq/cpu.c b/arch/arm/mach-zynq/cpu.c
index 914b1fe..ba9171e 100644
--- a/arch/arm/mach-zynq/cpu.c
+++ b/arch/arm/mach-zynq/cpu.c
@@ -43,12 +43,8 @@ int arch_cpu_init(void)
 
 unsigned int zynq_get_silicon_version(void)
 {
-   unsigned int ver;
-
-   ver = (readl(_base->mctrl) &
-  ZYNQ_SILICON_VER_MASK) >> ZYNQ_SILICON_VER_SHIFT;
-
-   return ver;
+   return (readl(_base->mctrl) & ZYNQ_SILICON_VER_MASK)
+   >> ZYNQ_SILICON_VER_SHIFT;
 }
 
 void reset_cpu(ulong addr)
diff --git a/arch/blackfin/cpu/interrupts.c b/arch/blackfin/cpu/interrupts.c
index 45c92c3..abb7dc1 100644
--- a/arch/blackfin/cpu/interrupts.c
+++ b/arch/blackfin/cpu/interrupts.c
@@ -47,10 +47,7 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk(void)
 {
-   ulong tbclk;
-
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }
 
 void enable_interrupts(void)
diff --git a/arch/m68k/lib/time.c b/arch/m68k/lib/time.c
index 3163354..cb90c83 100644
--- a/arch/m68k/lib/time.c
+++ b/arch/m68k/lib/time.c
@@ -192,7 +192,5 @@ unsigned long usec2ticks(unsigned long usec)
  */
 ulong get_tbclk(void)
 {
-   ulong tbclk;
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }
diff --git a/arch/powerpc/cpu/mpc512x/cpu.c b/arch/powerpc/cpu/mpc512x/cpu.c
index 8508e8d..4ee91e1 100644
--- a/arch/powerpc/cpu/mpc512x/cpu.c
+++ b/arch/powerpc/cpu/mpc512x/cpu.c
@@ -95,11 +95,7 @@ do_reset (cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])
  */
 unsigned long get_tbclk (void)
 {
-   ulong tbclk;
-
-   tbclk = (gd->bus_clk + 3L) / 4L;
-
-   return tbclk;
+   return (gd->bus_clk + 3L) / 4L;
 }
 
 
diff --git a/arch/powerpc/cpu/mpc83xx/cpu.c b/arch/powerpc/cpu/mpc83xx/cpu.c
index 3809309..c87f0fd 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu.c
@@ -173,11 +173,7 @@ do_reset (cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])
 
 unsigned long get_tbclk(void)
 {
-   ulong tbclk;
-
-   tbclk = (gd->bus_clk + 3L) / 4L;
-
-   return tbclk;
+   return (gd->bus_clk + 3L) / 4L;
 }
 
 
diff --git a/arch/xtensa/lib/time.c b/arch/xtensa/lib/time.c
index 1332072..915eb51 100644
--- a/arch/xtensa/lib/time.c
+++ b/arch/xtensa/lib/time.c
@@ -104,10 +104,7 @@ unsigned long long get_ticks(void)
  */
 ulong get_tbclk(void)
 {
-   ulong tbclk;
-
-   tbclk = CONFIG_SYS_HZ;
-   return tbclk;
+   return CONFIG_SYS_HZ;
 }
 
 #if XCHAL_HAVE_CCOUNT
diff --git a/board/amcc/bamboo/bamboo.c 

[U-Boot] is it necessary to set "gd->env_valid = 0" in getenv_default()?

[Robert P. J. Day]

  still wandering through the bowels of u-boot environment
manipulation code, and i see this in common/env_common.c:

  /*
   * Look up the variable from the default environment
   */
  char *getenv_default(const char *name)
  {
char *ret_val;
unsigned long really_valid = gd->env_valid;
unsigned long real_gd_flags = gd->flags;

/* Pretend that the image is bad. */
gd->flags &= ~GD_FLG_ENV_READY;
gd->env_valid = 0;  <--- ?
ret_val = getenv(name);
gd->env_valid = really_valid;
gd->flags = real_gd_flags;
return ret_val;
  }

fair enough ... in order to read a variable explicitly from the
(default) environment, temporarily fake that there is nothing in the
hash table, so this statement makes sense:

gd->flags &= ~GD_FLG_ENV_READY;

but is this one immediately afterwards also necessary?

gd->env_valid = 0;

because once you get to getenv() as defined in cmd/nvedit.c:

  char *getenv(const char *name)
  {
if (gd->flags & GD_FLG_ENV_READY) { /* after import into hashtable */
ENTRY e, *ep;

WATCHDOG_RESET();

e.key   = name;
e.data  = NULL;
hsearch_r(e, FIND, , _htab, 0);

return ep ? ep->data : NULL;
}

/* restricted capabilities before import */
if (getenv_f(name, (char *)(gd->env_buf), sizeof(gd->env_buf)) > 0)
return (char *)(gd->env_buf);

return NULL;
  }

it seems that the only test is for GD_ENV_FLG_READY, so setting
gd->env_valid=0 seems unnecessary. but perhaps i'm not reading far
enough.

rday

p.s. just to be clear, the meanings of those two gd members is:

  gd->flags & GD_FLG_ENV_READY means the environment has been imported
into a hash table, and

  gd->env_valid means the CRC for the environment in persistent
storage is correct.

do i understand that correctly?

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

[U-Boot] [Patch v5 8/9] armv8: ls1046ardb: Add LS1046ARDB board support

[Gong Qianyu]

From: Mingkai Hu 

LS1046ARDB Specification:
-
Memory subsystem:
 * 8GByte DDR4 SDRAM (64bit bus)
 * 512 Mbyte NAND flash
 * Two 64 Mbyte high-speed SPI flash
 * SD connector to interface with the SD memory card
 * On-board 4G eMMC

Ethernet:
 * Two XFI 10G ports
 * Two SGMII ports
 * Two RGMII ports

PCIe:
 * PCIe1 (SerDes2 Lane0) to miniPCIe slot
 * PCIe2 (SerDes2 Lane1) to x2 PCIe slot
 * PCIe3 (SerDes2 Lane2) to x4 PCIe slot

SATA:
 * SerDes2 Lane3 to SATA port

USB 3.0: one super speed USB 3.0 type A port
 one Micro-AB port

UART: supports two UARTs up to 115200 bps for console

Signed-off-by: Mingkai Hu 
Signed-off-by: Shaohui Xie 
Signed-off-by: Gong Qianyu 
---
v5:
 - Adjust the SPL BSS and MALLOC address.
v4:
 - Extend SPL max size and pad_to size for SD boot.
v3:
 - Remove redundant sd rcw .cfg files.
 - Adjust the format of memory map.
 - Add emmc boot support.
v2:
 - Add >60 characters' paragraph for the board help.
 - Fix the memory map in readme.
 - Remove unused flash r/w functions.
 - Remove DDR3 defines.

 arch/arm/Kconfig   |  12 +
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/fsl-ls1046a-rdb.dts   |  44 
 arch/arm/dts/fsl-ls1046a.dtsi  | 220 +++
 board/freescale/ls1046ardb/Kconfig |  16 ++
 board/freescale/ls1046ardb/MAINTAINERS |   9 +
 board/freescale/ls1046ardb/Makefile|  10 +
 board/freescale/ls1046ardb/README  |  76 +++
 board/freescale/ls1046ardb/cpld.c  | 158 ++
 board/freescale/ls1046ardb/cpld.h  |  49 +
 board/freescale/ls1046ardb/ddr.c   | 140 
 board/freescale/ls1046ardb/ddr.h   |  44 
 board/freescale/ls1046ardb/eth.c   |  77 +++
 board/freescale/ls1046ardb/ls1046ardb.c| 136 
 board/freescale/ls1046ardb/ls1046ardb_pbi.cfg  |  22 ++
 board/freescale/ls1046ardb/ls1046ardb_rcw_emmc.cfg |   7 +
 board/freescale/ls1046ardb/ls1046ardb_rcw_sd.cfg   |   7 +
 configs/ls1046ardb_emmc_defconfig  |  26 +++
 configs/ls1046ardb_qspi_defconfig  |  25 +++
 configs/ls1046ardb_sdcard_defconfig|  26 +++
 include/configs/ls1046a_common.h   | 175 +++
 include/configs/ls1046ardb.h   | 242 +
 22 files changed, 1522 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c871eaf..2835a6d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -837,6 +837,17 @@ config TARGET_LS1043ARDB
help
  Support for Freescale LS1043ARDB platform.
 
+config TARGET_LS1046ARDB
+   bool "Support ls1046ardb"
+   select ARM64
+   select ARMV8_MULTIENTRY
+   select SUPPORT_SPL
+   help
+ Support for Freescale LS1046ARDB platform.
+ The LS1046A Reference Design Board (RDB) is a high-performance
+ development platform that supports the QorIQ LS1046A
+ Layerscape Architecture processor.
+
 config TARGET_H2200
bool "Support h2200"
select CPU_PXA
@@ -981,6 +992,7 @@ source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
 source "board/freescale/ls1043ardb/Kconfig"
+source "board/freescale/ls1046ardb/Kconfig"
 source "board/freescale/ls1012aqds/Kconfig"
 source "board/freescale/ls1012ardb/Kconfig"
 source "board/freescale/ls1012afrdm/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 756535b..b646aa0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -143,6 +143,7 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb \
+   fsl-ls1046a-rdb.dtb \
fsl-ls1012a-qds.dtb \
fsl-ls1012a-rdb.dtb \
fsl-ls1012a-frdm.dtb
diff --git a/arch/arm/dts/fsl-ls1046a-rdb.dts b/arch/arm/dts/fsl-ls1046a-rdb.dts
new file mode 100644
index 000..4902454
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1046a-rdb.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1046A family SoC.
+ *
+ * Copyright 2016, Freescale Semiconductor
+ *
+ * Mingkai Hu 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "fsl-ls1046a.dtsi"
+
+/ {
+   model = "LS1046A RDB Board";
+
+   aliases {
+   spi0 = 
+   };
+
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   qflash0: s25fs512s@0 {
+   #address-cells = 

[U-Boot] [Patch v5 9/9] armv8: ls1046aqds: Add LS1046AQDS board support

[Gong Qianyu]

From: Shaohui Xie 

LS1046AQDS Specification:
-
Memory subsystem:
 * 8GByte DDR4 SDRAM (64bit bus)
 * 128 Mbyte NOR flash single-chip memory
 * 512 Mbyte NAND flash
 * 64 Mbyte high-speed SPI flash
 * SD connector to interface with the SD memory card

Ethernet:
 * Two XFI 10G ports
 * Two SGMII ports
 * Two RGMII ports

PCIe: supports Gen 1 and Gen 2

SATA 3.0: one SATA 3.0 port

USB 3.0: two micro AB connector and one type A connector

UART: supports two UARTs up to 115200 bps for console

Signed-off-by: Shaohui Xie 
Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
v5:
 - Fix SPL_PAD_TO size to block aligned value.
 - Adjust the SPL BSS and MALLOC address.
v4:
 - New Patch.

 arch/arm/Kconfig   |  12 +
 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/fsl-ls1046a-qds-duart.dts |  16 +
 arch/arm/dts/fsl-ls1046a-qds-lpuart.dts|  16 +
 arch/arm/dts/fsl-ls1046a-qds.dtsi  |  81 
 board/freescale/common/vid.c   |   8 +-
 board/freescale/ls1046aqds/Kconfig |  15 +
 board/freescale/ls1046aqds/MAINTAINERS |  11 +
 board/freescale/ls1046aqds/Makefile|   9 +
 board/freescale/ls1046aqds/README  |  70 +++
 board/freescale/ls1046aqds/ddr.c   | 140 ++
 board/freescale/ls1046aqds/ddr.h   |  44 ++
 board/freescale/ls1046aqds/eth.c   | 415 +
 board/freescale/ls1046aqds/ls1046aqds.c| 313 +
 board/freescale/ls1046aqds/ls1046aqds_pbi.cfg  |  17 +
 board/freescale/ls1046aqds/ls1046aqds_qixis.h  |  39 ++
 board/freescale/ls1046aqds/ls1046aqds_rcw_nand.cfg |   7 +
 .../freescale/ls1046aqds/ls1046aqds_rcw_sd_ifc.cfg |   8 +
 .../ls1046aqds/ls1046aqds_rcw_sd_qspi.cfg  |   8 +
 configs/ls1046aqds_defconfig   |  28 ++
 configs/ls1046aqds_lpuart_defconfig|  29 ++
 configs/ls1046aqds_nand_defconfig  |  30 ++
 configs/ls1046aqds_qspi_defconfig  |  30 ++
 configs/ls1046aqds_sdcard_ifc_defconfig|  30 ++
 configs/ls1046aqds_sdcard_qspi_defconfig   |  31 ++
 include/configs/ls1046a_common.h   |  38 +-
 include/configs/ls1046aqds.h   | 494 +
 27 files changed, 1936 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2835a6d..810e922 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -837,6 +837,17 @@ config TARGET_LS1043ARDB
help
  Support for Freescale LS1043ARDB platform.
 
+config TARGET_LS1046AQDS
+   bool "Support ls1046aqds"
+   select ARM64
+   select ARMV8_MULTIENTRY
+   select SUPPORT_SPL
+   help
+ Support for Freescale LS1046AQDS platform.
+ The LS1046A Development System (QDS) is a high-performance
+ development platform that supports the QorIQ LS1046A
+ Layerscape Architecture processor.
+
 config TARGET_LS1046ARDB
bool "Support ls1046ardb"
select ARM64
@@ -991,6 +1002,7 @@ source "board/freescale/ls2080ardb/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
+source "board/freescale/ls1046aqds/Kconfig"
 source "board/freescale/ls1043ardb/Kconfig"
 source "board/freescale/ls1046ardb/Kconfig"
 source "board/freescale/ls1012aqds/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b646aa0..4918213 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -143,6 +143,8 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb \
+   fsl-ls1046a-qds-duart.dtb \
+   fsl-ls1046a-qds-lpuart.dtb \
fsl-ls1046a-rdb.dtb \
fsl-ls1012a-qds.dtb \
fsl-ls1012a-rdb.dtb \
diff --git a/arch/arm/dts/fsl-ls1046a-qds-duart.dts 
b/arch/arm/dts/fsl-ls1046a-qds-duart.dts
new file mode 100644
index 000..10a95ea
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1046a-qds-duart.dts
@@ -0,0 +1,16 @@
+/*
+ * Device Tree file for Freescale Layerscape-1046A family SoC.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include "fsl-ls1046a-qds.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   };
+};
diff --git a/arch/arm/dts/fsl-ls1046a-qds-lpuart.dts 
b/arch/arm/dts/fsl-ls1046a-qds-lpuart.dts
new file mode 100644
index 000..21243d0
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1046a-qds-lpuart.dts
@@ -0,0 +1,16 @@
+/*
+ * Device Tree file for Freescale Layerscape-1046A family SoC.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * 

[U-Boot] [Patch v5 7/9] armv8: ls1046a: disable SATA ECC in DCSR

[Gong Qianyu]

From: Shaohui Xie 

This is a workaround to fix SATA CRC error. Once the root cause
is found the ECC disabling will be removed.

Signed-off-by: Shaohui Xie 
Signed-off-by: Gong Qianyu 
---
v3-v5:
 - No change.
v2:
 - Use values directly instead of macros. 
 - Revise commit message.

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

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index f62b78d..a60c928 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -222,6 +222,10 @@ int sata_init(void)
 {
struct ccsr_ahci __iomem *ccsr_ahci = (void *)CONFIG_SYS_SATA;
 
+#ifdef CONFIG_LS1046A
+   /* Disable SATA ECC */
+   out_le32((void *)CONFIG_SYS_DCSR_DCFG_ADDR + 0x520, 0x8000);
+#endif
out_le32(_ahci->ppcfg, AHCI_PORT_PHY_1_CFG);
out_le32(_ahci->pp2c, AHCI_PORT_PHY_2_CFG);
out_le32(_ahci->pp3c, AHCI_PORT_PHY_3_CFG);
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 04/11] arm: socfpga: clkmgr: Segregate the Clock Manager for Stratix 10

[Marek Vasut]

On 09/06/2016 07:14 AM, Chin Liang See wrote:
> On Mon, 2016-09-05 at 17:58 +0200, Marek Vasut wrote:
>> On 08/22/2016 05:02 PM, Chin Liang See wrote:
>>> Segregate the Clock Manager to support both GEN5 SoC and
>>> Stratix 10 SoC.
>>>
>>> Signed-off-by: Chin Liang See 
>>> Cc: Marek Vasut 
>>> Cc: Dinh Nguyen 
>>> Cc: Ley Foon Tan 
>>> ---
>>>  arch/arm/mach-socfpga/clock_manager.c | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-socfpga/clock_manager.c b/arch/arm/mach
>>> -socfpga/clock_manager.c
>>> index aa71636..0d67b3c 100644
>>> --- a/arch/arm/mach-socfpga/clock_manager.c
>>> +++ b/arch/arm/mach-socfpga/clock_manager.c
>>> @@ -10,6 +10,7 @@
>>>  
>>>  DECLARE_GLOBAL_DATA_PTR;
>>>  
>>> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>>>  static const struct socfpga_clock_manager *clock_manager_base =
>>> (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
>>>  
>>> @@ -446,9 +447,11 @@ unsigned int cm_get_l4_sp_clk_hz(void)
>>>  
>>> return clock;
>>>  }
>>> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>>>  
>>>  unsigned int cm_get_mmc_controller_clk_hz(void)
>>>  {
>>> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>>> uint32_t reg, clock = 0;
>>>  
>>> /* identify the source of MMC clock */
>>> @@ -475,8 +478,12 @@ unsigned int
>>> cm_get_mmc_controller_clk_hz(void)
>>> /* further divide by 4 as we have fixed divider at wrapper
>>> */
>>> clock /= 4;
>>> return clock;
>>> +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
>>> +   return 2500;
>>> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>>>  }
>>>  
>>> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>>>  unsigned int cm_get_qspi_controller_clk_hz(void)
>>
>> Are you sure this won't cause build breakage ? I believe this is
>> still
>> used by the cadence qspi driver.
> 
> That is a good question. As for SOC Virtual Platform, we are not
> enabling the QSPI controller.

When stratix 10 ships, this will be left broken then ?


-- 
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 07/11] arm: socfpga: sysmgr: Fix casting warning when enabling ARM64

[Marek Vasut]

On 09/06/2016 11:41 AM, Chin Liang See wrote:
> On Mon, 2016-09-05 at 18:02 +0200, Marek Vasut wrote:
>> On 08/22/2016 05:02 PM, Chin Liang See wrote:
>>> Fix casting warning to pointer from integer of different size
>>> when enabling ARM64 support
>>
>> What sort of error did you observe ?
> 
> The warning is triggered as ARM64 has build flag -Wpointer-to-int-cast
> and similar. Here is the build error log
> 
> arch/arm/mach-socfpga/system_manager.c: In function sysmgr_pinmux_init:
>
>   arch/arm/mach-socfpga/system_manager.c:59:18: warning: cast
> from pointer to integer of different size [-Wpointer-to-int-cast]  
>   uint32_t regs = (uint32_t)_regs
> ->emacio[0];   
>   ^
>
>   In file
> included from arch/arm/mach-socfpga/system_manager.c:8:0:  
>
>   ./arch/arm/include/asm/io.h:78:29: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]  
> #define __arch_putl(v,a)  (*(volatile unsigned int
> *)(a) = (v))   

I see ... Except the code below does regs += sizeof(regs); , which in
the original case increments the address by 4 , but with your change,
the increment would be 16 . So this patch breaks things.

btw it's not worth reposting patches while there is still ongoing
discussion.

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

[U-Boot] [PATCH v3 6/8] libfdt: simplify fdt_del_mem_rsv()

[Masahiro Yamada]

The variable "err" is unneeded.

[ Device Tree Compiler commit: 36fd7331fb11276c09a6affc0d8cd4977f2fe100 ]

Signed-off-by: Masahiro Yamada 
Signed-off-by: David Gibson 
---

Changes in v3: None

 lib/libfdt/fdt_rw.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/lib/libfdt/fdt_rw.c b/lib/libfdt/fdt_rw.c
index e7321cc..47447b2 100644
--- a/lib/libfdt/fdt_rw.c
+++ b/lib/libfdt/fdt_rw.c
@@ -148,17 +148,13 @@ int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t 
size)
 int fdt_del_mem_rsv(void *fdt, int n)
 {
struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
-   int err;
 
FDT_RW_CHECK_HEADER(fdt);
 
if (n >= fdt_num_mem_rsv(fdt))
return -FDT_ERR_NOTFOUND;
 
-   err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
-   if (err)
-   return err;
-   return 0;
+   return _fdt_splice_mem_rsv(fdt, re, 1, 0);
 }
 
 static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
-- 
1.9.1

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

[U-Boot] [PATCH v3 2/8] video: squash lines for immediate return

[Masahiro Yamada]

For vidconsole_post_probe(), it is common coding style to let a
probe method return the value of a register function.

The others will become simple wrapper functions.

Signed-off-by: Masahiro Yamada 
Acked-by: Anatolij Gustschin 
---

Changes in v3:
  - Two more fixes
  - s/resister/register/

 drivers/video/bridge/ptn3460.c| 7 +--
 drivers/video/broadwell_igd.c | 5 +
 drivers/video/exynos/exynos_dp_lowlevel.c | 6 +-
 drivers/video/tegra124/display.c  | 8 +---
 drivers/video/vidconsole-uclass.c | 6 +-
 5 files changed, 5 insertions(+), 27 deletions(-)

diff --git a/drivers/video/bridge/ptn3460.c b/drivers/video/bridge/ptn3460.c
index 2e2ae7c..f9d3720 100644
--- a/drivers/video/bridge/ptn3460.c
+++ b/drivers/video/bridge/ptn3460.c
@@ -11,14 +11,9 @@
 
 static int ptn3460_attach(struct udevice *dev)
 {
-   int ret;
-
debug("%s: %s\n", __func__, dev->name);
-   ret = video_bridge_set_active(dev, true);
-   if (ret)
-   return ret;
 
-   return 0;
+   return video_bridge_set_active(dev, true);
 }
 
 struct video_bridge_ops ptn3460_ops = {
diff --git a/drivers/video/broadwell_igd.c b/drivers/video/broadwell_igd.c
index ce4f296..4286fd0 100644
--- a/drivers/video/broadwell_igd.c
+++ b/drivers/video/broadwell_igd.c
@@ -323,10 +323,7 @@ err:
 static unsigned long gtt_read(struct broadwell_igd_priv *priv,
  unsigned long reg)
 {
-   u32 val;
-
-   val = readl(priv->regs + reg);
-   return val;
+   return readl(priv->regs + reg);
 }
 
 static void gtt_write(struct broadwell_igd_priv *priv, unsigned long reg,
diff --git a/drivers/video/exynos/exynos_dp_lowlevel.c 
b/drivers/video/exynos/exynos_dp_lowlevel.c
index f978473..aae78a8 100644
--- a/drivers/video/exynos/exynos_dp_lowlevel.c
+++ b/drivers/video/exynos/exynos_dp_lowlevel.c
@@ -881,11 +881,7 @@ void exynos_dp_set_lane_count(struct exynos_dp *dp_regs, 
unsigned char count)
 
 unsigned int exynos_dp_get_lane_count(struct exynos_dp *dp_regs)
 {
-   unsigned int reg;
-
-   reg = readl(_regs->lane_count_set);
-
-   return reg;
+   return readl(_regs->lane_count_set);
 }
 
 unsigned char exynos_dp_get_lanex_pre_emphasis(struct exynos_dp *dp_regs,
diff --git a/drivers/video/tegra124/display.c b/drivers/video/tegra124/display.c
index 2f1f0df..d8999c3 100644
--- a/drivers/video/tegra124/display.c
+++ b/drivers/video/tegra124/display.c
@@ -326,13 +326,7 @@ static int display_update_config_from_edid(struct udevice 
*dp_dev,
   int *panel_bppp,
   struct display_timing *timing)
 {
-   int ret;
-
-   ret = display_read_timing(dp_dev, timing);
-   if (ret)
-   return ret;
-
-   return 0;
+   return display_read_timing(dp_dev, timing);
 }
 
 static int display_init(struct udevice *dev, void *lcdbase,
diff --git a/drivers/video/vidconsole-uclass.c 
b/drivers/video/vidconsole-uclass.c
index c8cc05e..e9a90b1 100644
--- a/drivers/video/vidconsole-uclass.c
+++ b/drivers/video/vidconsole-uclass.c
@@ -190,7 +190,6 @@ static int vidconsole_post_probe(struct udevice *dev)
 {
struct vidconsole_priv *priv = dev_get_uclass_priv(dev);
struct stdio_dev *sdev = >sdev;
-   int ret;
 
if (!priv->tab_width_frac)
priv->tab_width_frac = VID_TO_POS(priv->x_charsize) * 8;
@@ -206,11 +205,8 @@ static int vidconsole_post_probe(struct udevice *dev)
sdev->putc = vidconsole_putc;
sdev->puts = vidconsole_puts;
sdev->priv = dev;
-   ret = stdio_register(sdev);
-   if (ret)
-   return ret;
 
-   return 0;
+   return stdio_register(sdev);
 }
 
 UCLASS_DRIVER(vidconsole) = {
-- 
1.9.1

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

[U-Boot] [PATCH v3 4/8] usb: squash lines for immediate return

[Masahiro Yamada]

This makes functions much simpler.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 common/usb.c| 20 +++-
 common/usb_kbd.c|  5 +
 common/usb_storage.c|  9 +++--
 drivers/usb/host/xhci-fsl.c |  7 +--
 4 files changed, 12 insertions(+), 29 deletions(-)

diff --git a/common/usb.c b/common/usb.c
index b3ba487..15e1e4c 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -557,12 +557,10 @@ int usb_clear_halt(struct usb_device *dev, int pipe)
 static int usb_get_descriptor(struct usb_device *dev, unsigned char type,
unsigned char index, void *buf, int size)
 {
-   int res;
-   res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
-   USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
-   (type << 8) + index, 0,
-   buf, size, USB_CNTL_TIMEOUT);
-   return res;
+   return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
+  USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
+  (type << 8) + index, 0, buf, size,
+  USB_CNTL_TIMEOUT);
 }
 
 /**
@@ -612,14 +610,10 @@ int usb_get_configuration_no(struct usb_device *dev, int 
cfgno,
  */
 static int usb_set_address(struct usb_device *dev)
 {
-   int res;
-
debug("set address %d\n", dev->devnum);
-   res = usb_control_msg(dev, usb_snddefctrl(dev),
-   USB_REQ_SET_ADDRESS, 0,
-   (dev->devnum), 0,
-   NULL, 0, USB_CNTL_TIMEOUT);
-   return res;
+
+   return usb_control_msg(dev, usb_snddefctrl(dev), USB_REQ_SET_ADDRESS,
+  0, (dev->devnum), 0, NULL, 0, USB_CNTL_TIMEOUT);
 }
 
 /
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index 97f79f8..a9872a6 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -605,11 +605,8 @@ int usb_kbd_deregister(int force)
 static int usb_kbd_probe(struct udevice *dev)
 {
struct usb_device *udev = dev_get_parent_priv(dev);
-   int ret;
-
-   ret = probe_usb_keyboard(udev);
 
-   return ret;
+   return probe_usb_keyboard(udev);
 }
 
 static int usb_kbd_remove(struct udevice *dev)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index 7e6e52d..0345aa2 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -708,13 +708,10 @@ static int usb_stor_CBI_get_status(ccb *srb, struct 
us_data *us)
 /* clear a stall on an endpoint - special for BBB devices */
 static int usb_stor_BBB_clear_endpt_stall(struct us_data *us, __u8 endpt)
 {
-   int result;
-
/* ENDPOINT_HALT = 0, so set value to 0 */
-   result = usb_control_msg(us->pusb_dev, usb_sndctrlpipe(us->pusb_dev, 0),
-   USB_REQ_CLEAR_FEATURE, USB_RECIP_ENDPOINT,
-   0, endpt, NULL, 0, USB_CNTL_TIMEOUT * 5);
-   return result;
+   return usb_control_msg(us->pusb_dev, usb_sndctrlpipe(us->pusb_dev, 0),
+  USB_REQ_CLEAR_FEATURE, USB_RECIP_ENDPOINT, 0,
+  endpt, NULL, 0, USB_CNTL_TIMEOUT * 5);
 }
 
 static int usb_stor_BBB_transport(ccb *srb, struct us_data *us)
diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c
index bdcd4f1..6ff450c 100644
--- a/drivers/usb/host/xhci-fsl.c
+++ b/drivers/usb/host/xhci-fsl.c
@@ -129,15 +129,10 @@ static int xhci_fsl_probe(struct udevice *dev)
 static int xhci_fsl_remove(struct udevice *dev)
 {
struct xhci_fsl_priv *priv = dev_get_priv(dev);
-   int ret;
 
fsl_xhci_core_exit(>ctx);
 
-   ret = xhci_deregister(dev);
-   if (ret)
-   return ret;
-
-   return 0;
+   return xhci_deregister(dev);
 }
 
 static const struct udevice_id xhci_usb_ids[] = {
-- 
1.9.1

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

[U-Boot] [Patch v5 2/9] Export memset for standalone AQ FW load apps

[Gong Qianyu]

From: Shaohui Xie 

The 'commit 95279315076c ("board/ls2085rdb: Export functions for
standalone AQ FW load apps")' mentioned memset was exported but
it was not, this patch exports the memset.

Signed-off-by: Shaohui Xie 
Signed-off-by: Gong Qianyu 
---
v3-v5:
 - No change.
v2:
 - Revise commmit message.

 include/_exports.h | 1 +
 include/exports.h  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/_exports.h b/include/_exports.h
index 11beeb2..1584705 100644
--- a/include/_exports.h
+++ b/include/_exports.h
@@ -75,6 +75,7 @@
const char *, char **, unsigned int)
EXPORT_FUNC(strcpy, char *, strcpy, char *dest, const char *src)
EXPORT_FUNC(mdelay, void, mdelay, unsigned long msec)
+   EXPORT_FUNC(memset, void *, memset, void *, int, size_t)
 #ifdef CONFIG_PHY_AQUANTIA
EXPORT_FUNC(mdio_get_current_dev, struct mii_dev *,
mdio_get_current_dev, void)
diff --git a/include/exports.h b/include/exports.h
index deef8fb..1d81bc4 100644
--- a/include/exports.h
+++ b/include/exports.h
@@ -57,7 +57,7 @@ struct jt_funcs {
 };
 
 
-#define XF_VERSION 8
+#define XF_VERSION 9
 
 #if defined(CONFIG_X86)
 extern gd_t *global_data;
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH v3 1/8] mmc: squash lines for immediate return

[Masahiro Yamada]

These functions can be much simpler by squashing lines for immediate
return.

For *_bind() callbacks, they will be a simple wrapper function of an
upper-level bind API.

For mmc_set_{boot_bus_width,part_conf}, they will be a wrapper of
mmc_switch().

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/mmc/atmel_sdhci.c |  7 +--
 drivers/mmc/exynos_dw_mmc.c   |  7 +--
 drivers/mmc/mmc_boot.c| 28 
 drivers/mmc/msm_sdhci.c   |  7 +--
 drivers/mmc/rockchip_dw_mmc.c |  7 +--
 drivers/mmc/rockchip_sdhci.c  |  7 +--
 drivers/mmc/sandbox_mmc.c |  7 +--
 drivers/mmc/zynq_sdhci.c  |  7 +--
 8 files changed, 15 insertions(+), 62 deletions(-)

diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index dd6bd33..d8f8087 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -136,13 +136,8 @@ static int atmel_sdhci_probe(struct udevice *dev)
 static int atmel_sdhci_bind(struct udevice *dev)
 {
struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
-   int ret;
 
-   ret = sdhci_bind(dev, >mmc, >cfg);
-   if (ret)
-   return ret;
-
-   return 0;
+   return sdhci_bind(dev, >mmc, >cfg);
 }
 
 static const struct udevice_id atmel_sdhci_ids[] = {
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 57271f1..568fed7 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -284,13 +284,8 @@ static int exynos_dwmmc_probe(struct udevice *dev)
 static int exynos_dwmmc_bind(struct udevice *dev)
 {
struct exynos_mmc_plat *plat = dev_get_platdata(dev);
-   int ret;
 
-   ret = dwmci_bind(dev, >mmc, >cfg);
-   if (ret)
-   return ret;
-
-   return 0;
+   return dwmci_bind(dev, >mmc, >cfg);
 }
 
 static const struct udevice_id exynos_dwmmc_ids[] = {
diff --git a/drivers/mmc/mmc_boot.c b/drivers/mmc/mmc_boot.c
index 756a982..ac6f56f 100644
--- a/drivers/mmc/mmc_boot.c
+++ b/drivers/mmc/mmc_boot.c
@@ -85,16 +85,10 @@ int mmc_boot_partition_size_change(struct mmc *mmc, 
unsigned long bootsize,
  */
 int mmc_set_boot_bus_width(struct mmc *mmc, u8 width, u8 reset, u8 mode)
 {
-   int err;
-
-   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_BUS_WIDTH,
-EXT_CSD_BOOT_BUS_WIDTH_MODE(mode) |
-EXT_CSD_BOOT_BUS_WIDTH_RESET(reset) |
-EXT_CSD_BOOT_BUS_WIDTH_WIDTH(width));
-
-   if (err)
-   return err;
-   return 0;
+   return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_BUS_WIDTH,
+ EXT_CSD_BOOT_BUS_WIDTH_MODE(mode) |
+ EXT_CSD_BOOT_BUS_WIDTH_RESET(reset) |
+ EXT_CSD_BOOT_BUS_WIDTH_WIDTH(width));
 }
 
 /*
@@ -106,16 +100,10 @@ int mmc_set_boot_bus_width(struct mmc *mmc, u8 width, u8 
reset, u8 mode)
  */
 int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access)
 {
-   int err;
-
-   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
-EXT_CSD_BOOT_ACK(ack) |
-EXT_CSD_BOOT_PART_NUM(part_num) |
-EXT_CSD_PARTITION_ACCESS(access));
-
-   if (err)
-   return err;
-   return 0;
+   return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
+ EXT_CSD_BOOT_ACK(ack) |
+ EXT_CSD_BOOT_PART_NUM(part_num) |
+ EXT_CSD_PARTITION_ACCESS(access));
 }
 
 /*
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index 8d4399e..1b82991 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -190,13 +190,8 @@ static int msm_ofdata_to_platdata(struct udevice *dev)
 static int msm_sdc_bind(struct udevice *dev)
 {
struct msm_sdhc_plat *plat = dev_get_platdata(dev);
-   int ret;
 
-   ret = sdhci_bind(dev, >mmc, >cfg);
-   if (ret)
-   return ret;
-
-   return 0;
+   return sdhci_bind(dev, >mmc, >cfg);
 }
 
 static const struct udevice_id msm_mmc_ids[] = {
diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
index 020a59b..859760b 100644
--- a/drivers/mmc/rockchip_dw_mmc.c
+++ b/drivers/mmc/rockchip_dw_mmc.c
@@ -142,13 +142,8 @@ static int rockchip_dwmmc_probe(struct udevice *dev)
 static int rockchip_dwmmc_bind(struct udevice *dev)
 {
struct rockchip_mmc_plat *plat = dev_get_platdata(dev);
-   int ret;
 
-   ret = dwmci_bind(dev, >mmc, >cfg);
-   if (ret)
-   return ret;
-
-   return 0;
+   return dwmci_bind(dev, >mmc, >cfg);
 }
 
 static const struct udevice_id rockchip_dwmmc_ids[] = {
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index 624029b..c56e1a3 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -62,13 +62,8 

Re: [U-Boot] [PATCH v2 2/7] arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:37AM -0400, Madan Srinivas wrote:

> From: Vitaly Andrianov 
> 
> This commit implements the board_fit_image_post_process() function for
> the keystone architecture. Unlike OMAP class devices, security
> functions in keystone are not handled in the ROM.
> The interface to the secure functions is TI proprietary and depending
> on the keystone platform, the security functions like encryption,
> decryption and authentication might even be offloaded to other secure
> processing elements in the SoC.
> The boot monitor acts as the gateway to these secure functions and the
> boot monitor for secure devices is available as part of the SECDEV
> package for KS2. For more details refer doc/README.ti-secure
> 
> Signed-off-by: Vitaly Andrianov 
> Signed-off-by: Madan Srinivas 
> 
> Cc: Lokesh Vutla 
> Cc: Dan Murphy 

First, what is done to ensure that the magic blob we're offloading to
isn't malicious?  Second, this appears to be missing cache flushes
that're done in arch/arm/cpu/armv7/omap-common/sec-common.c and, well,
why can't we re-use the existing code?  Given how rarely IP blocks are
written from scratch rather than being an evolution of a previous block
I can't imagine that we can't make the code there be re-used nor that we
don't need / couldn't use the flushing and alignment checks nor status
messages.  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 v2 6/7] doc: Updates info on using keystone secure devices from TI

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:41AM -0400, Madan Srinivas wrote:

> Add a section describing the secure boot image used on
> keystone secure devices.
> 
> This patch applies on top of the patch
> doc: Update info on using AM33xx secure devices from TI
> submitted by Andrew Davis
> 
> Signed-off-by: Madan Srinivas 
> 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/3] warp7: Add a secure mode target

[Stefano Babic]

On 06/09/2016 12:58, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Tue, Sep 6, 2016 at 5:09 AM, Stefano Babic  wrote:
>> On 26/08/2016 02:07, Fabio Estevam wrote:
>>> From: Fabio Estevam 
>>>
>>> NXP kernel expects to boot in secure mode, so introduce
>>> warp7_secure_defconfig target which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT.
>>>
>>> Signed-off-by: Fabio Estevam 
>>> ---
>>
>> Applied to u-boot-imx, thanks !
> 
> I don't see this series applied in
> http://git.denx.de/?p=u-boot/u-boot-imx.git;a=shortlog
> 
> Are they missing?

You're right, strange, something went wrong. Now they are on the server.

Thanks for checking !

Stefano

-- 
=
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] [PATCH] eth: asix88179: Reset device during probe with DM_ETH enabled

[Simon Glass]

Hi,

On 6 September 2016 at 03:33, Nikolaus Schulz
 wrote:
> On Mon, Sep 05, 2016 at 07:04:49PM -0600, Simon Glass wrote:
>> On 30 August 2016 at 08:01, Nikolaus Schulz
>>  wrote:
>> > With the ethernet driver model enabled, reset the device before reading
>> > the MAC address, just like it's done for the non-device-model code path.
>> > This avoids a timeout when the interface is first used.
>> >
>> > Signed-off-by: Nikolaus Schulz 
>> > ---
>> >  drivers/usb/eth/asix88179.c | 4 
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/drivers/usb/eth/asix88179.c b/drivers/usb/eth/asix88179.c
>> > index 7548269..0725940 100644
>> > --- a/drivers/usb/eth/asix88179.c
>> > +++ b/drivers/usb/eth/asix88179.c
>> > @@ -878,6 +878,10 @@ static int ax88179_eth_probe(struct udevice *dev)
>> > usb_dev = priv->ueth.pusb_dev;
>> > priv->maxpacketsize = usb_dev->epmaxpacketout[AX_ENDPOINT_OUT];
>> >
>> > +   ret = asix_basic_reset(>ueth, priv);
>> > +   if (ret)
>> > +   return ret;
>> > +
>> > /* Get the MAC address */
>> > ret = asix_read_mac(>ueth, pdata->enetaddr);
>> > if (ret)
>>
>> How come this doesn't happen in ax88179_eth_start()?
>
> In fact I first had put it there, but that was basically killing the
> ethernet. And having it in the probe function matches the non-DM code
> path, which has it in ax88179_eth_get_info.

OK thanks.

Reviewed-by: Simon Glass 

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

[U-Boot] [PATCH v3 5/8] x86: squash lines for immediate return

[Masahiro Yamada]

arch_cpu_init() can be simpler by this refactoring.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Bin Meng 
Reviewed-by: Simon Glass 
---

Changes in v3: None

 arch/x86/cpu/baytrail/valleyview.c | 8 +---
 arch/x86/cpu/ivybridge/ivybridge.c | 8 +---
 arch/x86/cpu/qemu/qemu.c   | 8 +---
 arch/x86/cpu/queensbay/tnc.c   | 8 +---
 4 files changed, 4 insertions(+), 28 deletions(-)

diff --git a/arch/x86/cpu/baytrail/valleyview.c 
b/arch/x86/cpu/baytrail/valleyview.c
index b31f24e..b312d9f 100644
--- a/arch/x86/cpu/baytrail/valleyview.c
+++ b/arch/x86/cpu/baytrail/valleyview.c
@@ -25,15 +25,9 @@ int cpu_mmc_init(bd_t *bis)
 #ifndef CONFIG_EFI_APP
 int arch_cpu_init(void)
 {
-   int ret;
-
post_code(POST_CPU_INIT);
 
-   ret = x86_cpu_init_f();
-   if (ret)
-   return ret;
-
-   return 0;
+   return x86_cpu_init_f();
 }
 
 int arch_misc_init(void)
diff --git a/arch/x86/cpu/ivybridge/ivybridge.c 
b/arch/x86/cpu/ivybridge/ivybridge.c
index c770b53..e817eb9 100644
--- a/arch/x86/cpu/ivybridge/ivybridge.c
+++ b/arch/x86/cpu/ivybridge/ivybridge.c
@@ -10,13 +10,7 @@
 
 int arch_cpu_init(void)
 {
-   int ret;
-
post_code(POST_CPU_INIT);
 
-   ret = x86_cpu_init_f();
-   if (ret)
-   return ret;
-
-   return 0;
+   return x86_cpu_init_f();
 }
diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
index 680e558..c3092f2 100644
--- a/arch/x86/cpu/qemu/qemu.c
+++ b/arch/x86/cpu/qemu/qemu.c
@@ -139,15 +139,9 @@ static void qemu_chipset_init(void)
 
 int arch_cpu_init(void)
 {
-   int ret;
-
post_code(POST_CPU_INIT);
 
-   ret = x86_cpu_init_f();
-   if (ret)
-   return ret;
-
-   return 0;
+   return x86_cpu_init_f();
 }
 
 #ifndef CONFIG_EFI_STUB
diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
index b226e4c..f307c62 100644
--- a/arch/x86/cpu/queensbay/tnc.c
+++ b/arch/x86/cpu/queensbay/tnc.c
@@ -94,15 +94,9 @@ static int __maybe_unused disable_igd(void)
 
 int arch_cpu_init(void)
 {
-   int ret;
-
post_code(POST_CPU_INIT);
 
-   ret = x86_cpu_init_f();
-   if (ret)
-   return ret;
-
-   return 0;
+   return x86_cpu_init_f();
 }
 
 int arch_early_init_r(void)
-- 
1.9.1

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

[U-Boot] [PATCH v3 3/8] usb: replace ehci_*_remove() with usb_deregister()

[Masahiro Yamada]

The remove callbacks of EHCI drivers are often just a wrapper of
ehci_deregister.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - added

 drivers/usb/host/ehci-atmel.c   | 13 +
 drivers/usb/host/ehci-fsl.c | 13 +
 drivers/usb/host/ehci-generic.c |  7 +--
 drivers/usb/host/ehci-marvell.c | 13 +
 drivers/usb/host/ehci-mx6.c | 13 +
 drivers/usb/host/ehci-pci.c | 13 +
 drivers/usb/host/ehci-tegra.c   | 13 +
 drivers/usb/host/ehci-zynq.c| 13 +
 8 files changed, 8 insertions(+), 90 deletions(-)

diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index d65bbe9..2b138c5 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -128,17 +128,6 @@ static int ehci_atmel_probe(struct udevice *dev)
return ehci_register(dev, hccr, hcor, NULL, 0, USB_INIT_HOST);
 }
 
-static int ehci_atmel_remove(struct udevice *dev)
-{
-   int ret;
-
-   ret = ehci_deregister(dev);
-   if (ret)
-   return ret;
-
-   return 0;
-}
-
 static const struct udevice_id ehci_usb_ids[] = {
{ .compatible = "atmel,at91sam9g45-ehci", },
{ }
@@ -149,7 +138,7 @@ U_BOOT_DRIVER(ehci_atmel) = {
.id = UCLASS_USB,
.of_match   = ehci_usb_ids,
.probe  = ehci_atmel_probe,
-   .remove = ehci_atmel_remove,
+   .remove = ehci_deregister,
.ops= _usb_ops,
.platdata_auto_alloc_size = sizeof(struct usb_platdata),
.priv_auto_alloc_size = sizeof(struct ehci_atmel_priv),
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index f5e3ae7..9c32921 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -118,17 +118,6 @@ static int ehci_fsl_probe(struct udevice *dev)
return ehci_register(dev, hccr, hcor, _ehci_ops, 0, USB_INIT_HOST);
 }
 
-static int ehci_fsl_remove(struct udevice *dev)
-{
-   int ret;
-
-   ret = ehci_deregister(dev);
-   if (ret)
-   return ret;
-
-   return 0;
-}
-
 static const struct udevice_id ehci_usb_ids[] = {
{ .compatible = "fsl-usb2-mph", },
{ .compatible = "fsl-usb2-dr", },
@@ -141,7 +130,7 @@ U_BOOT_DRIVER(ehci_fsl) = {
.of_match = ehci_usb_ids,
.ofdata_to_platdata = ehci_fsl_ofdata_to_platdata,
.probe = ehci_fsl_probe,
-   .remove = ehci_fsl_remove,
+   .remove = ehci_deregister,
.ops= _usb_ops,
.platdata_auto_alloc_size = sizeof(struct usb_platdata),
.priv_auto_alloc_size = sizeof(struct ehci_fsl_priv),
diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index e0377ca..6291ed2 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -44,11 +44,6 @@ static int ehci_usb_probe(struct udevice *dev)
return ehci_register(dev, hccr, hcor, NULL, 0, USB_INIT_HOST);
 }
 
-static int ehci_usb_remove(struct udevice *dev)
-{
-   return ehci_deregister(dev);
-}
-
 static const struct udevice_id ehci_usb_ids[] = {
{ .compatible = "generic-ehci" },
{ }
@@ -59,7 +54,7 @@ U_BOOT_DRIVER(ehci_generic) = {
.id = UCLASS_USB,
.of_match = ehci_usb_ids,
.probe = ehci_usb_probe,
-   .remove = ehci_usb_remove,
+   .remove = ehci_deregister,
.ops= _usb_ops,
.priv_auto_alloc_size = sizeof(struct generic_ehci),
.flags  = DM_FLAG_ALLOC_PRIV_DMA,
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index 5b0f46a..253fcb3 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -94,17 +94,6 @@ static int ehci_mvebu_probe(struct udevice *dev)
return ehci_register(dev, hccr, hcor, NULL, 0, USB_INIT_HOST);
 }
 
-static int ehci_mvebu_remove(struct udevice *dev)
-{
-   int ret;
-
-   ret = ehci_deregister(dev);
-   if (ret)
-   return ret;
-
-   return 0;
-}
-
 static const struct udevice_id ehci_usb_ids[] = {
{ .compatible = "marvell,orion-ehci", },
{ }
@@ -115,7 +104,7 @@ U_BOOT_DRIVER(ehci_mvebu) = {
.id = UCLASS_USB,
.of_match = ehci_usb_ids,
.probe = ehci_mvebu_probe,
-   .remove = ehci_mvebu_remove,
+   .remove = ehci_deregister,
.ops= _usb_ops,
.platdata_auto_alloc_size = sizeof(struct usb_platdata),
.priv_auto_alloc_size = sizeof(struct ehci_mvebu_priv),
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 602fec5..48889c1 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -451,17 +451,6 @@ static int ehci_usb_probe(struct udevice *dev)
return ehci_register(dev, hccr, hcor, _ehci_ops, 0, 
priv->init_type);
 }
 
-static int ehci_usb_remove(struct udevice *dev)
-{
-   int ret;
-
-   ret = 

Re: [U-Boot] [PATCH] Increase default of CONFIG_SYS_MALLOC_F_LEN for SPL_OF_CONTROL

[Masahiro Yamada]

2016-09-06 10:04 GMT+09:00 Simon Glass :
> On 30 August 2016 at 03:56, Stefan Roese  wrote:
>> On 30.08.2016 11:50, Masahiro Yamada wrote:
>>>
>>> If both SPL_DM and SPL_OF_CONTROL are enabled, SPL needs to bind
>>> several devices, but CONFIG_SYS_MALLOC_F_LEN=0x400 is apparently
>>> not enough.  Increase the default to 0x2000 for the case.  This
>>> will be helpful for shorter defconfigs.
>>>
>>> Signed-off-by: Masahiro Yamada 
>>
>>
>> Reviewed-by: Stefan Roese 
>
> Reviewed-by: Simon Glass 
>
> It would be worth checking why. I fixed a bug where simple-bus would
> bring in all devices regardless of the u-boot,dm-pre-reloc flag.
> Perhaps that was it?

I do not think so.

Recently I tested this.  In spite of "u-boot,dm-pre-reloc"
in the SPL device tree, my board failed in SPL.

I guess CONFIG_SYS_MALLOC_F_LEN=0x400 is not enough
for binding/probing UART, pinctrl, MMC in SPL.

I increased the malloc size and it worked fine.




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

Re: [U-Boot] [PATCH 06/11] arm: socfpga: misc: Segregate the misc.c for Stratix 10

[Marek Vasut]

On 09/06/2016 08:19 AM, Chin Liang See wrote:
> On Mon, 2016-09-05 at 18:01 +0200, Marek Vasut wrote:
>> On 08/22/2016 05:02 PM, Chin Liang See wrote:
>>> Segregate the misc.c to support both GEN5 SoC and Stratix 10 SoC.
>>>
>>> Signed-off-by: Chin Liang See 
>>> Cc: Marek Vasut 
>>> Cc: Dinh Nguyen 
>>> Cc: Ley Foon Tan 
>>> ---
>>>  arch/arm/mach-socfpga/misc.c | 12 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach
>>> -socfpga/misc.c
>>> index 5cbd8a4..295121f 100644
>>> --- a/arch/arm/mach-socfpga/misc.c
>>> +++ b/arch/arm/mach-socfpga/misc.c
>>> @@ -24,6 +24,8 @@
>>>  
>>>  DECLARE_GLOBAL_DATA_PTR;
>>>  
>>> +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
>>> +
>>>  static struct pl310_regs *const pl310 =
>>> (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
>>>  static struct socfpga_system_manager *sysmgr_regs =
>>> @@ -34,6 +36,7 @@ static struct nic301_registers *nic301_regs =
>>> (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
>>>  static struct scu_registers *scu_regs =
>>> (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
>>> +#endif
>>>  
>>>  int dram_init(void)
>>>  {
>>> @@ -41,6 +44,7 @@ int dram_init(void)
>>> return 0;
>>>  }
>>>  
>>> +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
>>>  void enable_caches(void)
>>>  {
>>>  #ifndef CONFIG_SYS_ICACHE_OFF
>>> @@ -246,6 +250,7 @@ static int socfpga_fpga_id(const bool print_id)
>>>socfpga_fpga_model[i].name, version);
>>> return i;
>>>  }
>>> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>>>  
>>>  /*
>>>   * Print CPU information
>>> @@ -253,14 +258,20 @@ static int socfpga_fpga_id(const bool
>>> print_id)
>>>  #if defined(CONFIG_DISPLAY_CPUINFO)
>>>  int print_cpuinfo(void)
>>>  {
>>> +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
>>> const u32 bsel = readl(_regs->bootinfo) & 0x7;
>>> puts("CPU:   Altera SoCFPGA Platform\n");
>>> socfpga_fpga_id(1);
>>> printf("BOOT:  %s\n", bsel_str[bsel].name);
>>> +#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
>>> +   puts("CPU:   Altera SoCFPGA Platform\n");
>>> +   puts("FPGA:  Altera Stratix 10\n");
>>> +#endif /* CONFIG_TARGET_SOCFPGA_GEN5 */
>>
>> Can't you decode the boot mode and FPGA type instead ?
> 
> That is a good question. This is now not available in SOC Virtual
> Platform. But will definitely enhance this in later stage with hardware
> available.

What do you mean not available ? Does the VT not emulate the SoC precisely ?


-- 
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] Increase default of CONFIG_SYS_MALLOC_F_LEN for SPL_OF_CONTROL

[Marek Vasut]

On 09/06/2016 02:24 PM, Masahiro Yamada wrote:
> 2016-09-06 10:04 GMT+09:00 Simon Glass :
>> On 30 August 2016 at 03:56, Stefan Roese  wrote:
>>> On 30.08.2016 11:50, Masahiro Yamada wrote:

 If both SPL_DM and SPL_OF_CONTROL are enabled, SPL needs to bind
 several devices, but CONFIG_SYS_MALLOC_F_LEN=0x400 is apparently
 not enough.  Increase the default to 0x2000 for the case.  This
 will be helpful for shorter defconfigs.

 Signed-off-by: Masahiro Yamada 
>>>
>>>
>>> Reviewed-by: Stefan Roese 
>>
>> Reviewed-by: Simon Glass 
>>
>> It would be worth checking why. I fixed a bug where simple-bus would
>> bring in all devices regardless of the u-boot,dm-pre-reloc flag.
>> Perhaps that was it?
> 
> I do not think so.
> 
> Recently I tested this.  In spite of "u-boot,dm-pre-reloc"
> in the SPL device tree, my board failed in SPL.
> 
> I guess CONFIG_SYS_MALLOC_F_LEN=0x400 is not enough
> for binding/probing UART, pinctrl, MMC in SPL.
> 
> I increased the malloc size and it worked fine.

You can check this by tracking the allocations and the utilization of
the malloc space.

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

[U-Boot] [PATCH v3 8/8] drivers: squash lines for immediate return

[Masahiro Yamada]

Remove unneeded variables and assignments.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - more changes

 drivers/block/sym53c8xx.c|  5 ++---
 drivers/ddr/fsl/ddr1_dimm_params.c   | 12 ++--
 drivers/ddr/fsl/ddr2_dimm_params.c   | 12 ++--
 drivers/ddr/marvell/a38x/ddr3_a38x.c |  6 +-
 drivers/power/axp809.c   |  8 +---
 drivers/rtc/m48t35ax.c   |  4 +---
 6 files changed, 9 insertions(+), 38 deletions(-)

diff --git a/drivers/block/sym53c8xx.c b/drivers/block/sym53c8xx.c
index 5daede7..50043e6 100644
--- a/drivers/block/sym53c8xx.c
+++ b/drivers/block/sym53c8xx.c
@@ -284,9 +284,8 @@ void scsi_low_level_init(int busdevfunc)
  */
 unsigned long swap_script(unsigned long val)
 {
-   unsigned long tmp;
-   tmp = ((val>>24)&0xff) | ((val>>8)&0xff00) | ((val<<8)&0xff) | 
((val<<24)&0xff00);
-   return tmp;
+   return ((val >> 24) & 0xff) | ((val >> 8) & 0xff00) |
+   ((val << 8) & 0xff) | ((val << 24) & 0xff00);
 }
 
 
diff --git a/drivers/ddr/fsl/ddr1_dimm_params.c 
b/drivers/ddr/fsl/ddr1_dimm_params.c
index 00cdc22..369b325 100644
--- a/drivers/ddr/fsl/ddr1_dimm_params.c
+++ b/drivers/ddr/fsl/ddr1_dimm_params.c
@@ -108,22 +108,14 @@ static unsigned int byte40_table_ps[8] = {
 static unsigned int
 compute_trfc_ps_from_spd(unsigned char trctrfc_ext, unsigned char trfc)
 {
-   unsigned int trfc_ps;
-
-   trfc_ps = (((trctrfc_ext & 0x1) * 256) + trfc) * 1000
+   return ((trctrfc_ext & 0x1) * 256 + trfc) * 1000
+ byte40_table_ps[(trctrfc_ext >> 1) & 0x7];
-
-   return trfc_ps;
 }
 
 static unsigned int
 compute_trc_ps_from_spd(unsigned char trctrfc_ext, unsigned char trc)
 {
-   unsigned int trc_ps;
-
-   trc_ps = trc * 1000 + byte40_table_ps[(trctrfc_ext >> 4) & 0x7];
-
-   return trc_ps;
+   return trc * 1000 + byte40_table_ps[(trctrfc_ext >> 4) & 0x7];
 }
 
 /*
diff --git a/drivers/ddr/fsl/ddr2_dimm_params.c 
b/drivers/ddr/fsl/ddr2_dimm_params.c
index 59baf6b..af752cc 100644
--- a/drivers/ddr/fsl/ddr2_dimm_params.c
+++ b/drivers/ddr/fsl/ddr2_dimm_params.c
@@ -107,22 +107,14 @@ static unsigned int byte40_table_ps[8] = {
 static unsigned int
 compute_trfc_ps_from_spd(unsigned char trctrfc_ext, unsigned char trfc)
 {
-   unsigned int trfc_ps;
-
-   trfc_ps = (((trctrfc_ext & 0x1) * 256) + trfc) * 1000
+   return (((trctrfc_ext & 0x1) * 256) + trfc) * 1000
+ byte40_table_ps[(trctrfc_ext >> 1) & 0x7];
-
-   return trfc_ps;
 }
 
 static unsigned int
 compute_trc_ps_from_spd(unsigned char trctrfc_ext, unsigned char trc)
 {
-   unsigned int trc_ps;
-
-   trc_ps = trc * 1000 + byte40_table_ps[(trctrfc_ext >> 4) & 0x7];
-
-   return trc_ps;
+   return trc * 1000 + byte40_table_ps[(trctrfc_ext >> 4) & 0x7];
 }
 
 /*
diff --git a/drivers/ddr/marvell/a38x/ddr3_a38x.c 
b/drivers/ddr/marvell/a38x/ddr3_a38x.c
index f469907..c082122 100644
--- a/drivers/ddr/marvell/a38x/ddr3_a38x.c
+++ b/drivers/ddr/marvell/a38x/ddr3_a38x.c
@@ -706,11 +706,7 @@ int ddr3_tip_ext_write(u32 dev_num, u32 if_id, u32 
reg_addr,
 
 int ddr3_silicon_pre_init(void)
 {
-   int result;
-
-   result = ddr3_silicon_init();
-
-   return result;
+   return ddr3_silicon_init();
 }
 
 int ddr3_post_run_alg(void)
diff --git a/drivers/power/axp809.c b/drivers/power/axp809.c
index c8b76cf..c5b608d 100644
--- a/drivers/power/axp809.c
+++ b/drivers/power/axp809.c
@@ -217,13 +217,7 @@ int axp_set_sw(bool on)
 
 int axp_init(void)
 {
-   int ret;
-
-   ret = pmic_bus_init();
-   if (ret)
-   return ret;
-
-   return 0;
+   return pmic_bus_init();
 }
 
 int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
diff --git a/drivers/rtc/m48t35ax.c b/drivers/rtc/m48t35ax.c
index 021b91f..36011a5 100644
--- a/drivers/rtc/m48t35ax.c
+++ b/drivers/rtc/m48t35ax.c
@@ -127,10 +127,8 @@ void rtc_reset (void)
 
 static uchar rtc_read (uchar reg)
 {
-   uchar val;
-   val = *(unsigned char *)
+   return *(unsigned char *)
((CONFIG_SYS_NVRAM_BASE_ADDR + CONFIG_SYS_NVRAM_SIZE - 8) + 
reg);
-   return val;
 }
 
 static void rtc_write (uchar reg, uchar val)
-- 
1.9.1

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

Re: [U-Boot] ZynqMP breakage

[Simon Glass]

Hi Alex,

On 6 September 2016 at 03:09, Alexander Graf  wrote:
> On 09/06/2016 03:05 AM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 5 September 2016 at 04:51, Alexander Graf  wrote:
>>>
>>> On 08/19/2016 08:45 AM, Michal Simek wrote:

 On 16.8.2016 20:39, Alexander Graf wrote:
>
> Hi Michal,
>
> I just tried to run the latest u-boot master + a few patches to
> implement
> generic PSCI RTS support on zynqmp and got this:
>
> e
> U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200) Xilinx
> ZynqMP ZCU102
>
> I2C:   ready
> DRAM:  4 GiB
> EL Level:   EL2
> MMC:   sdhci@ff17: 0
> Using default environment
>
> In:serial@ff00
> Out:   serial@ff00
> Err:   serial@ff00
> Bootmode: SD_MODE1
> SCSI:  SATA link 0 timeout.
> Target spinup took 0 ms.
> AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
> scanning bus for devices...
> "Synchronous Abort" handler, esr 0x9604
> ELR: 7ff42d20
> LR:  7ff3ff10
> x0 :  x1 : 
> x2 : 0001 x3 : 7df1aa80
> x4 :  x5 : 0001
> x6 : 0200 x7 : 0004
> x8 : 7ff9f800 x9 : 0008
> x10: 7ff9f8f0 x11: 
> x12:  x13: 
> x14: 7ff8242f x15: 7ff82435
> x16: 7ff84388 x17: 7ff84388
> x18: 7df1ade8 x19: 7df1aa80
> x20: 7ff92cb8 x21: 7ff9f800
> x22: 7ff9f000 x23: 0078
> x24: 7ff9f8f0 x25: 
> x26: 7ff9f800 x27: 7ff9f000
> x28: 7ff9fb00 x29: 7df1aca0
>
> Resetting CPU ...
>
> resetting …
>
> Is this a known problem?

 Is this issue with usb?
 I have usb off on zcu102 that's why if this usb issue
 I am not aware about it.
>>>
>>>
>>> After a bit of digging, turns out it's CONFIG_BLK. If I disable that
>>> things
>>> work again (albeit without mmc access, since that one requires CONFIG_BLK
>>> now).
>>
>> I don't have a zynqmp device, so cannot test with that unfortunately.
>
>
> Well, QEMU supports zcu102 emulation in the latest version, so you could use
> that to emulate the board:
>
>   $ qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m 2G
> -drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0
>
> However, I don't see the data abort with the emulated device, only with
> actual hardware. Probably because real hardware is more upset about reading
> from address 0 ;). But I can provoke the oops even in QEMU if I unmap the
> first page from the memory map using the patch below.
>
> The oops happens in blk_dread because block_dev->bdev is NULL.

Yes, this field really should be removed. As the comment says it's a
hangover from pre-CONFIG_BLK where functions use a struct blk_dev * to
specify the block device instead of a struct udevice *. It came up
recently on a patch you sent also which is why I am so against using
it.

That said, I'm not sure why it is unset. The path should be:

sdhci_bind()
mmc_bind()
blk_create_devicef()
blk_create_device()
which sets:

desc->bdev = dev;

[snip]

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

[U-Boot] Please pull u-boot-sunxi master (v2016.09 fixes)

[Hans de Goede]

Hi Tom,

Here is a sunxi pull-req with some recent fixes
for v2016.09, note this is an updated pull-req
superseding my previous one.

The main reason for this pull-req is a couple of
fixes for the sun8i ethernet support (which is
new in v2016.0). Besides that this also adds 3
new boards which were pending in sunxi-next and
(new in the updated pullreq) a few A64 fixes.

The following changes since commit b615267633996a9410a88b54a55965d8b021f6f8:

  ARM: tegra: Add support for TK1-SOM board from Colorado Engineering 
(2016-09-01 09:24:30 -0700)

are available in the git repository at:

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

for you to fetch changes up to 5a74a3912970d4fa5625237f0117ca08c2878f29:

  sunxi: fix 64-bit compiler warning for SPL header parsing (2016-09-06 
13:35:52 +0200)


Andre Przywara (3):
  Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"
  sunxi: Kconfig: rename non-existent SUN50I_A64 config symbol
  sunxi: fix 64-bit compiler warning for SPL header parsing

Chen-Yu Tsai (1):
  sunxi: Fix H3 EMAC syscon register address

Hans de Goede (3):
  sunxi: Sync h3-orangepi dts files with kernel
  sunxi: Enable emac on H3 orangepi boards
  sunxi: Add defconfig and dts file for the Orange Pi Plus2E SBC

Icenowy Zheng (2):
  sunxi: add proper device tree for iNet D978 rev2 boards
  sunxi: Add iNet D978 rev2 defconfig

Stefan Mavrodiev (1):
  sunxi: Add support for A33-OLinuXino board

 arch/arm/dts/Makefile |   5 +-
 arch/arm/dts/sun8i-a33-inet-d978-rev2.dts |  88 
 arch/arm/dts/sun8i-a33-olinuxino.dts  | 226 ++
 arch/arm/dts/sun8i-h3-orangepi-2.dts  |  11 ++
 arch/arm/dts/sun8i-h3-orangepi-pc.dts |   1 +
 arch/arm/dts/sun8i-h3-orangepi-plus.dts   |  72 --
 arch/arm/dts/sun8i-h3-orangepi-plus2e.dts |  83 +++
 arch/arm/dts/sun8i-h3.dtsi|   5 +-
 board/sunxi/Kconfig   |   2 +-
 board/sunxi/MAINTAINERS   |  11 ++
 board/sunxi/board.c   |   2 +-
 configs/A33-OLinuXino_defconfig   |  43 ++
 configs/iNet_D978_rev2_defconfig  |  26 
 configs/orangepi_2_defconfig  |   1 +
 configs/orangepi_plus2e_defconfig |  19 +++
 configs/orangepi_plus_defconfig   |   3 +-
 include/configs/sunxi-common.h|   5 +-
 17 files changed, 547 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/dts/sun8i-a33-inet-d978-rev2.dts
 create mode 100644 arch/arm/dts/sun8i-a33-olinuxino.dts
 create mode 100644 arch/arm/dts/sun8i-h3-orangepi-plus2e.dts
 create mode 100644 configs/A33-OLinuXino_defconfig
 create mode 100644 configs/iNet_D978_rev2_defconfig
 create mode 100644 configs/orangepi_plus2e_defconfig

Regards,

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

Re: [U-Boot] [PATCH 1/7] rockchip: rk3399: update PPLL and pmu_pclk frequency

[Simon Glass]

Hi Kever,

On 6 September 2016 at 03:52, Kever Yang  wrote:
> Hi Simon,
>
> On 09/06/2016 09:03 AM, Simon Glass wrote:
>>
>> Hi Kever,
>>
>> On 29 August 2016 at 21:02, Kever Yang  wrote:
>>>
>>> This patch update PPLL to 676MHz and PMU_PCLK to 48MHz.
>>
>> Why?
>>
>
> 1. 48MHz can make sure the pwm can get exact 50% duty ratio, but 99MHz can
> not,
> 2. We think 48MHz is fast enough for pmu pclk and it is lower power cost
> than 99MHz,
> 3. PPLL 676 MHz and PMU_PCLK 48MHz are the clock rate we are using
> internally for kernel,
> it suppose not to change the bus clock like pmu_pclk in kernel, so we want
> to change it in uboot.

OK, thank you. Please can you add this info to the commit message in
v2? My point is that commits should explain why they are needed, if
not obvious.

>
> Thanks,
> - Kever
>
>>> Signed-off-by: Kever Yang 
>>> ---
>>>
>>>   arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
>>> b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
>>> index c919f47..6776e48 100644
>>> --- a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
>>> +++ b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
>>> @@ -64,9 +64,9 @@ check_member(rk3399_cru, sdio1_con[1], 0x594);
>>>   #define APLL_HZ(600*MHz)
>>>   #define GPLL_HZ(594*MHz)
>>>   #define CPLL_HZ(384*MHz)
>>> -#define PPLL_HZ(594*MHz)
>>> +#define PPLL_HZ(676*MHz)
>>>
>>> -#define PMU_PCLK_HZ(99*MHz)
>>> +#define PMU_PCLK_HZ(48*MHz)
>>>
>>>   #define ACLKM_CORE_HZ  (300*MHz)
>>>   #define ATCLK_CORE_HZ  (300*MHz)
>>> --
>>> 1.9.1
>>>
>> Regards,
>> Simon
>>
>>
>>
>
>

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

Re: [U-Boot] ZynqMP breakage

[Simon Glass]

Hi Alex,

On 6 September 2016 at 06:55, Alexander Graf  wrote:
> On 09/06/2016 02:52 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 6 September 2016 at 03:09, Alexander Graf  wrote:
>>>
>>> On 09/06/2016 03:05 AM, Simon Glass wrote:

 Hi Alex,

 On 5 September 2016 at 04:51, Alexander Graf  wrote:
>
> On 08/19/2016 08:45 AM, Michal Simek wrote:
>>
>> On 16.8.2016 20:39, Alexander Graf wrote:
>>>
>>> Hi Michal,
>>>
>>> I just tried to run the latest u-boot master + a few patches to
>>> implement
>>> generic PSCI RTS support on zynqmp and got this:
>>>
>>> e
>>> U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200)
>>> Xilinx
>>> ZynqMP ZCU102
>>>
>>> I2C:   ready
>>> DRAM:  4 GiB
>>> EL Level:   EL2
>>> MMC:   sdhci@ff17: 0
>>> Using default environment
>>>
>>> In:serial@ff00
>>> Out:   serial@ff00
>>> Err:   serial@ff00
>>> Bootmode: SD_MODE1
>>> SCSI:  SATA link 0 timeout.
>>> Target spinup took 0 ms.
>>> AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
>>> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
>>> scanning bus for devices...
>>> "Synchronous Abort" handler, esr 0x9604
>>> ELR: 7ff42d20
>>> LR:  7ff3ff10
>>> x0 :  x1 : 
>>> x2 : 0001 x3 : 7df1aa80
>>> x4 :  x5 : 0001
>>> x6 : 0200 x7 : 0004
>>> x8 : 7ff9f800 x9 : 0008
>>> x10: 7ff9f8f0 x11: 
>>> x12:  x13: 
>>> x14: 7ff8242f x15: 7ff82435
>>> x16: 7ff84388 x17: 7ff84388
>>> x18: 7df1ade8 x19: 7df1aa80
>>> x20: 7ff92cb8 x21: 7ff9f800
>>> x22: 7ff9f000 x23: 0078
>>> x24: 7ff9f8f0 x25: 
>>> x26: 7ff9f800 x27: 7ff9f000
>>> x28: 7ff9fb00 x29: 7df1aca0
>>>
>>> Resetting CPU ...
>>>
>>> resetting …
>>>
>>> Is this a known problem?
>>
>> Is this issue with usb?
>> I have usb off on zcu102 that's why if this usb issue
>> I am not aware about it.
>
>
> After a bit of digging, turns out it's CONFIG_BLK. If I disable that
> things
> work again (albeit without mmc access, since that one requires
> CONFIG_BLK
> now).

 I don't have a zynqmp device, so cannot test with that unfortunately.
>>>
>>>
>>> Well, QEMU supports zcu102 emulation in the latest version, so you could
>>> use
>>> that to emulate the board:
>>>
>>>$ qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m
>>> 2G
>>> -drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0
>>>
>>> However, I don't see the data abort with the emulated device, only with
>>> actual hardware. Probably because real hardware is more upset about
>>> reading
>>> from address 0 ;). But I can provoke the oops even in QEMU if I unmap the
>>> first page from the memory map using the patch below.
>>>
>>> The oops happens in blk_dread because block_dev->bdev is NULL.
>>
>> Yes, this field really should be removed. As the comment says it's a
>> hangover from pre-CONFIG_BLK where functions use a struct blk_dev * to
>> specify the block device instead of a struct udevice *. It came up
>> recently on a patch you sent also which is why I am so against using
>> it.
>>
>> That said, I'm not sure why it is unset. The path should be:
>>
>> sdhci_bind()
>> mmc_bind()
>> blk_create_devicef()
>> blk_create_device()
>> which sets:
>>
>> desc->bdev = dev;
>>
>> [snip]
>
>
> The special case about ZynqMP is that it has 2 storage backends, one that
> uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI
> controller). I guess something goes wrong with the latter.

OK, well it would be good to convert it. It certainly won't work
without it and I'm a little surprised that it compiles :-)

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

Re: [U-Boot] ZynqMP breakage

[Alexander Graf]

On 09/06/2016 02:52 PM, Simon Glass wrote:

Hi Alex,

On 6 September 2016 at 03:09, Alexander Graf  wrote:

On 09/06/2016 03:05 AM, Simon Glass wrote:

Hi Alex,

On 5 September 2016 at 04:51, Alexander Graf  wrote:

On 08/19/2016 08:45 AM, Michal Simek wrote:

On 16.8.2016 20:39, Alexander Graf wrote:

Hi Michal,

I just tried to run the latest u-boot master + a few patches to
implement
generic PSCI RTS support on zynqmp and got this:

e
U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200) Xilinx
ZynqMP ZCU102

I2C:   ready
DRAM:  4 GiB
EL Level:   EL2
MMC:   sdhci@ff17: 0
Using default environment

In:serial@ff00
Out:   serial@ff00
Err:   serial@ff00
Bootmode: SD_MODE1
SCSI:  SATA link 0 timeout.
Target spinup took 0 ms.
AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
scanning bus for devices...
"Synchronous Abort" handler, esr 0x9604
ELR: 7ff42d20
LR:  7ff3ff10
x0 :  x1 : 
x2 : 0001 x3 : 7df1aa80
x4 :  x5 : 0001
x6 : 0200 x7 : 0004
x8 : 7ff9f800 x9 : 0008
x10: 7ff9f8f0 x11: 
x12:  x13: 
x14: 7ff8242f x15: 7ff82435
x16: 7ff84388 x17: 7ff84388
x18: 7df1ade8 x19: 7df1aa80
x20: 7ff92cb8 x21: 7ff9f800
x22: 7ff9f000 x23: 0078
x24: 7ff9f8f0 x25: 
x26: 7ff9f800 x27: 7ff9f000
x28: 7ff9fb00 x29: 7df1aca0

Resetting CPU ...

resetting …

Is this a known problem?

Is this issue with usb?
I have usb off on zcu102 that's why if this usb issue
I am not aware about it.


After a bit of digging, turns out it's CONFIG_BLK. If I disable that
things
work again (albeit without mmc access, since that one requires CONFIG_BLK
now).

I don't have a zynqmp device, so cannot test with that unfortunately.


Well, QEMU supports zcu102 emulation in the latest version, so you could use
that to emulate the board:

   $ qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m 2G
-drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0

However, I don't see the data abort with the emulated device, only with
actual hardware. Probably because real hardware is more upset about reading
from address 0 ;). But I can provoke the oops even in QEMU if I unmap the
first page from the memory map using the patch below.

The oops happens in blk_dread because block_dev->bdev is NULL.

Yes, this field really should be removed. As the comment says it's a
hangover from pre-CONFIG_BLK where functions use a struct blk_dev * to
specify the block device instead of a struct udevice *. It came up
recently on a patch you sent also which is why I am so against using
it.

That said, I'm not sure why it is unset. The path should be:

sdhci_bind()
mmc_bind()
blk_create_devicef()
blk_create_device()
which sets:

desc->bdev = dev;

[snip]


The special case about ZynqMP is that it has 2 storage backends, one 
that uses DM (the sdhc controller) and one that isn't converted to DM 
(the AHCI controller). I guess something goes wrong with the latter.



Alex

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

Re: [U-Boot] [PATCH v2 3/7] arm: omap-common: adds secure image name common to OMAP and keystone

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:38AM -0400, Madan Srinivas wrote:

> As K2 can directly boot u-boot, add u-boot_HS_MLO as the
> secure image while booting secure K2 devicesr, for all
> boot modes other than SPI flash.
> 
> Signed-off-by: Madan Srinivas 
> 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 4/7] arm: omap-common: Enable support for K2 HS devices in u-boot

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:39AM -0400, Madan Srinivas wrote:

> From: Vitaly Andrianov 
> 
> Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family
> of SoCs also have high security enabled models. Allow K2E devices to
> be built with HS Device Type Support.
> 
> This patch applies on top of the patch
> ti: omap-common: Allow AM33xx devices to be built securely
> submitted by Andrew Davis
> 
> Signed-off-by: Vitaly Andrianov 
> Signed-off-by: Madan Srinivas 
> Acked-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Building u-boot.imx and SPL simultaneously

[Tom Rini]

On Fri, Sep 02, 2016 at 10:53:58PM +0200, Petr Kulhavy wrote:
> Hi Fabio,
> 
> On 02/09/16 22:03, Fabio Estevam wrote:
> >You don't need u-boot.imx to boot the board with imx_usb_loader.
> >Check the README update that Stefano did with this commit:
> >
> >commit 40f4839ce12adfc0223d6e3035cf9c3a4754a0ec
> >Author: Stefano Babic 
> >Date:   Fri Dec 11 17:30:42 2015 +0100
> >
> > imx_common: check for Serial Downloader in spl_boot_device
> >
> > Check for bmode before reading the boot device
> > to check if a serial downloader is started,
> > and returns UART if the serial downloader is set,
> > letting SPL to wait for an image if
> > CONFIG_SPL_YMODEM_SUPPORT is set.
> >
> > This allows to load again a SPL based board
> > with imx_usb_loader together with a tool
> > such as kermit.
> >
> > Signed-off-by: Stefano Babic 
> > CC: Tim Harvey 
> > CC: Fabio Estevam 
> > CC: Eric Nelson 
> > Reviewed-by: Eric Nelson 
> > Tested-by: Eric Nelson 
> This is not particularly what I want to do. I want to load the
> u-boot.img directly via the imx_usb_loader.
> The kermit method is unacceptably slow for a production environment.

Another place this doesn't work (which is where it doesn't work for me)
is when the console is already open and I can't easily take it away to
shoot over the next stage via Y-MODEM.

Would it be possible to implement having the next stage also be sent via
imx_usb_loader?  ie there's examples today of doing u-boot.imx + kernel
+ initrd via imx_usb_loader, so what would be needed for SPL +
u-boot.img (+ kenrel + initrd) via imx_usb_loader?  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 v2 1/7] include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:36AM -0400, Madan Srinivas wrote:

> The function board_fit_image_post_process is defined only when the config
> CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not
> use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will
> be defined, which will result in an implicit declaration of function
> 'board_fit_image_post_process' warning while building u-boot. This
> patch fixes this warning.
> 
> Signed-off-by: Madan Srinivas 
> Acked-by: Andrew F. Davis 
> 
> Cc: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Building u-boot.imx and SPL simultaneously

[Tom Rini]

On Tue, Sep 06, 2016 at 10:53:30AM -0300, Otavio Salvador wrote:
> On Tue, Sep 6, 2016 at 10:40 AM, Tom Rini  wrote:
> > On Fri, Sep 02, 2016 at 10:53:58PM +0200, Petr Kulhavy wrote:
> >> Hi Fabio,
> >>
> >> On 02/09/16 22:03, Fabio Estevam wrote:
> >> >You don't need u-boot.imx to boot the board with imx_usb_loader.
> >> >Check the README update that Stefano did with this commit:
> >> >
> >> >commit 40f4839ce12adfc0223d6e3035cf9c3a4754a0ec
> >> >Author: Stefano Babic 
> >> >Date:   Fri Dec 11 17:30:42 2015 +0100
> >> >
> >> > imx_common: check for Serial Downloader in spl_boot_device
> >> >
> >> > Check for bmode before reading the boot device
> >> > to check if a serial downloader is started,
> >> > and returns UART if the serial downloader is set,
> >> > letting SPL to wait for an image if
> >> > CONFIG_SPL_YMODEM_SUPPORT is set.
> >> >
> >> > This allows to load again a SPL based board
> >> > with imx_usb_loader together with a tool
> >> > such as kermit.
> >> >
> >> > Signed-off-by: Stefano Babic 
> >> > CC: Tim Harvey 
> >> > CC: Fabio Estevam 
> >> > CC: Eric Nelson 
> >> > Reviewed-by: Eric Nelson 
> >> > Tested-by: Eric Nelson 
> >> This is not particularly what I want to do. I want to load the
> >> u-boot.img directly via the imx_usb_loader.
> >> The kermit method is unacceptably slow for a production environment.
> >
> > Another place this doesn't work (which is where it doesn't work for me)
> > is when the console is already open and I can't easily take it away to
> > shoot over the next stage via Y-MODEM.
> >
> > Would it be possible to implement having the next stage also be sent via
> > imx_usb_loader?  ie there's examples today of doing u-boot.imx + kernel
> > + initrd via imx_usb_loader, so what would be needed for SPL +
> > u-boot.img (+ kenrel + initrd) via imx_usb_loader?  Thanks!
> 
> It should be the same except that the image will be already loaded and
> we need to instruct the SPL to jump to it. Am I missing something?
> 
> ...
> zImage-foo:load 0x8200
> core-image-minimal-foo.cpio.gz:load 0x8380
> u-boot.imx:clear_dcd,jump header

Yes, I want to load SPL + u-boot.img so SPL will need to know that it's
going to fall back to ROM and allow it to be given u-boot.img to load
into DRAM :)

-- 
Tom


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

[U-Boot] [PATCH] fsl-ifc-nand : Corrected the programming of chip select

[Matt Weber]

Corrected the chip selection in IFC_NAND_CSEL register. Due to this
issue in multi-chip nand use-case, IFC was always pointing to the last
probed chip even though the user select another device through "nand
device" command.

Signed-off-by: Ronak Desai 
Signed-off-by: Matthew Weber 
---
 drivers/mtd/nand/fsl_ifc_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 7001cbd..2ce4a7d 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -296,7 +296,7 @@ static int fsl_ifc_run_command(struct mtd_info *mtd)
int i;
 
/* set the chip select for NAND Transaction */
-   ifc_out32(>ifc_nand.nand_csel, ifc_ctrl->cs_nand);
+   ifc_out32(>ifc_nand.nand_csel, priv->bank << IFC_NAND_CSEL_SHIFT);
 
/* start read/write seq */
ifc_out32(>ifc_nand.nandseq_strt,
-- 
1.9.1

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

Re: [U-Boot] Building u-boot.imx and SPL simultaneously

[Eric Nelson]

Hi Tom,

On 09/06/2016 06:40 AM, Tom Rini wrote:
> On Fri, Sep 02, 2016 at 10:53:58PM +0200, Petr Kulhavy wrote:
>> Hi Fabio,
>>
>> On 02/09/16 22:03, Fabio Estevam wrote:
>>> You don't need u-boot.imx to boot the board with imx_usb_loader.
>>> Check the README update that Stefano did with this commit:
>>>
>>> commit 40f4839ce12adfc0223d6e3035cf9c3a4754a0ec
>>> Author: Stefano Babic 
>>> Date:   Fri Dec 11 17:30:42 2015 +0100
>>>
>>> imx_common: check for Serial Downloader in spl_boot_device
>>>
>>> Check for bmode before reading the boot device
>>> to check if a serial downloader is started,
>>> and returns UART if the serial downloader is set,
>>> letting SPL to wait for an image if
>>> CONFIG_SPL_YMODEM_SUPPORT is set.
>>>
>>> This allows to load again a SPL based board
>>> with imx_usb_loader together with a tool
>>> such as kermit.
>>>
>>> Signed-off-by: Stefano Babic 
>>> CC: Tim Harvey 
>>> CC: Fabio Estevam 
>>> CC: Eric Nelson 
>>> Reviewed-by: Eric Nelson 
>>> Tested-by: Eric Nelson 
>> This is not particularly what I want to do. I want to load the
>> u-boot.img directly via the imx_usb_loader.
>> The kermit method is unacceptably slow for a production environment.
> 
> Another place this doesn't work (which is where it doesn't work for me)
> is when the console is already open and I can't easily take it away to
> shoot over the next stage via Y-MODEM.
> 
> Would it be possible to implement having the next stage also be sent via
> imx_usb_loader?  ie there's examples today of doing u-boot.imx + kernel
> + initrd via imx_usb_loader, so what would be needed for SPL +
> u-boot.img (+ kenrel + initrd) via imx_usb_loader?  Thanks!
> 

SPL+u-boot.img could be bundled into a single image through the
use of plugins which would require:

- updates to mkimage to support plugins, and
- Makefile updates to produce a third output (u-boot.imx?), and
- an update to SPL startup on i.MX to check for the plugin flag
and return to the boot ROM after startup (instead of loading
U-Boot) if set.

Troy implemented the key bits back in 2012, and I provided
some links here:

http://lists.denx.de/pipermail/u-boot/2016-June/258784.html

Regards,


Eric

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

Re: [U-Boot] [PATCH v3 6/8] libfdt: simplify fdt_del_mem_rsv()

[Simon Glass]

On 6 September 2016 at 07:17, Masahiro Yamada
 wrote:
> The variable "err" is unneeded.
>
> [ Device Tree Compiler commit: 36fd7331fb11276c09a6affc0d8cd4977f2fe100 ]
>
> Signed-off-by: Masahiro Yamada 
> Signed-off-by: David Gibson 
> ---
>
> Changes in v3: None
>
>  lib/libfdt/fdt_rw.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)

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

Re: [U-Boot] Building u-boot.imx and SPL simultaneously

[Petr Kulhavy]

On 06/09/16 16:00, Eric Nelson wrote:

Hi Tom,

On 09/06/2016 06:40 AM, Tom Rini wrote:

On Fri, Sep 02, 2016 at 10:53:58PM +0200, Petr Kulhavy wrote:

Another place this doesn't work (which is where it doesn't work for me)
is when the console is already open and I can't easily take it away to
shoot over the next stage via Y-MODEM.

Would it be possible to implement having the next stage also be sent via
imx_usb_loader?  ie there's examples today of doing u-boot.imx + kernel
+ initrd via imx_usb_loader, so what would be needed for SPL +
u-boot.img (+ kenrel + initrd) via imx_usb_loader?  Thanks!


SPL+u-boot.img could be bundled into a single image through the
use of plugins which would require:

- updates to mkimage to support plugins, and
- Makefile updates to produce a third output (u-boot.imx?), and
- an update to SPL startup on i.MX to check for the plugin flag
and return to the boot ROM after startup (instead of loading
U-Boot) if set.

Maybe this jumping to RBL forth and back is not needed at all.
If the SPL+img was loaded as one chunk into DRAM instead of the on-chip 
RAM (would require DDR initialization via DCD as it happens for the IMX 
image) then the SPL could jump directly into the uboot image, couldn't it?


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

Re: [U-Boot] Building u-boot.imx and SPL simultaneously

[Tom Rini]

On Tue, Sep 06, 2016 at 04:12:55PM +0200, Petr Kulhavy wrote:
> 
> 
> On 06/09/16 16:00, Eric Nelson wrote:
> >Hi Tom,
> >
> >On 09/06/2016 06:40 AM, Tom Rini wrote:
> >>On Fri, Sep 02, 2016 at 10:53:58PM +0200, Petr Kulhavy wrote:
> >>
> >>Another place this doesn't work (which is where it doesn't work for me)
> >>is when the console is already open and I can't easily take it away to
> >>shoot over the next stage via Y-MODEM.
> >>
> >>Would it be possible to implement having the next stage also be sent via
> >>imx_usb_loader?  ie there's examples today of doing u-boot.imx + kernel
> >>+ initrd via imx_usb_loader, so what would be needed for SPL +
> >>u-boot.img (+ kenrel + initrd) via imx_usb_loader?  Thanks!
> >>
> >SPL+u-boot.img could be bundled into a single image through the
> >use of plugins which would require:
> >
> >- updates to mkimage to support plugins, and
> >- Makefile updates to produce a third output (u-boot.imx?), and
> >- an update to SPL startup on i.MX to check for the plugin flag
> >and return to the boot ROM after startup (instead of loading
> >U-Boot) if set.
> Maybe this jumping to RBL forth and back is not needed at all.
> If the SPL+img was loaded as one chunk into DRAM instead of the
> on-chip RAM (would require DDR initialization via DCD as it happens
> for the IMX image) then the SPL could jump directly into the uboot
> image, couldn't it?

Yes but many of the use cases involve "get away from doing DCD script
DDR init".  That's basically what the u-boot.imx version does, there's
the header up front that does DDR init and then u-boot is loaded into
DRAM.

-- 
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] Building u-boot.imx and SPL simultaneously

[Tom Rini]

On Tue, Sep 06, 2016 at 07:00:56AM -0700, Eric Nelson wrote:
> Hi Tom,
> 
> On 09/06/2016 06:40 AM, Tom Rini wrote:
> > On Fri, Sep 02, 2016 at 10:53:58PM +0200, Petr Kulhavy wrote:
> >> Hi Fabio,
> >>
> >> On 02/09/16 22:03, Fabio Estevam wrote:
> >>> You don't need u-boot.imx to boot the board with imx_usb_loader.
> >>> Check the README update that Stefano did with this commit:
> >>>
> >>> commit 40f4839ce12adfc0223d6e3035cf9c3a4754a0ec
> >>> Author: Stefano Babic 
> >>> Date:   Fri Dec 11 17:30:42 2015 +0100
> >>>
> >>> imx_common: check for Serial Downloader in spl_boot_device
> >>>
> >>> Check for bmode before reading the boot device
> >>> to check if a serial downloader is started,
> >>> and returns UART if the serial downloader is set,
> >>> letting SPL to wait for an image if
> >>> CONFIG_SPL_YMODEM_SUPPORT is set.
> >>>
> >>> This allows to load again a SPL based board
> >>> with imx_usb_loader together with a tool
> >>> such as kermit.
> >>>
> >>> Signed-off-by: Stefano Babic 
> >>> CC: Tim Harvey 
> >>> CC: Fabio Estevam 
> >>> CC: Eric Nelson 
> >>> Reviewed-by: Eric Nelson 
> >>> Tested-by: Eric Nelson 
> >> This is not particularly what I want to do. I want to load the
> >> u-boot.img directly via the imx_usb_loader.
> >> The kermit method is unacceptably slow for a production environment.
> > 
> > Another place this doesn't work (which is where it doesn't work for me)
> > is when the console is already open and I can't easily take it away to
> > shoot over the next stage via Y-MODEM.
> > 
> > Would it be possible to implement having the next stage also be sent via
> > imx_usb_loader?  ie there's examples today of doing u-boot.imx + kernel
> > + initrd via imx_usb_loader, so what would be needed for SPL +
> > u-boot.img (+ kenrel + initrd) via imx_usb_loader?  Thanks!
> > 
> 
> SPL+u-boot.img could be bundled into a single image through the
> use of plugins which would require:
> 
> - updates to mkimage to support plugins, and
> - Makefile updates to produce a third output (u-boot.imx?), and
> - an update to SPL startup on i.MX to check for the plugin flag
> and return to the boot ROM after startup (instead of loading
> U-Boot) if set.
> 
> Troy implemented the key bits back in 2012, and I provided
> some links here:
> 
> http://lists.denx.de/pipermail/u-boot/2016-June/258784.html

Ah yes, this.  I really would like to see this come in as I think it'll
be required to really drop the old style u-boot.imx binaries for cases
like factory programming.  As well as the use cases outlined before too
about supporting multiple boards more easily.

-- 
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 v2 10/11] arm: dts: socfpga: Add dts for Stratix 10 socdk

[Dinh Nguyen]

On 09/06/2016 05:03 AM, Chin Liang See wrote:
> Add device tree for Stratix 10 SoC development kit
> 
> Signed-off-by: Chin Liang See 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Ley Foon Tan 
> Acked-by: Marek Vasut 
> ---
>  arch/arm/dts/Makefile|  3 +-
>  arch/arm/dts/socfpga_stratix10_socdk.dts | 63 
> 
>  2 files changed, 65 insertions(+), 1 deletion(-)
>  create mode 100755 arch/arm/dts/socfpga_stratix10_socdk.dts
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 223124e..c5e2d3c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -127,7 +127,8 @@ dtb-$(CONFIG_ARCH_SOCFPGA) += 
> \
>   socfpga_cyclone5_sockit.dtb \
>   socfpga_cyclone5_socrates.dtb   \
>   socfpga_cyclone5_sr1500.dtb \
> - socfpga_cyclone5_vining_fpga.dtb
> + socfpga_cyclone5_vining_fpga.dtb\
> + socfpga_stratix10_socdk.dtb
>  
>  dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb
>  dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
> diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts 
> b/arch/arm/dts/socfpga_stratix10_socdk.dts
> new file mode 100755
> index 000..7465358
> --- /dev/null
> +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> @@ -0,0 +1,63 @@
> +/*
> + *  Copyright (C) 2016 Intel Corporation
> + *
> + * SPDX-License-Identifier:  GPL-2.0
> + */
> +
> +/dts-v1/;
> +/* First 4KB has trampoline code for secondary cores. */
> +/memreserve/ 0x 0x0001000;

ARM64 should be using PSCI for SMP. I don't think the trampoline code is
needed.

> +#include "skeleton.dtsi"
> +
> +/ {
> + model = "Altera SOCFPGA Stratix 10 SoC Development Kit";
> + compatible = "altr,socfpga-stratix10", "altr,socfpga";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + memory {
> + name = "memory";
> + device_type = "memory";
> + reg = <0x0 0x4000>; /* 1GB */
> + };

are you sure we still have only 1GB?

> +
> + regulator_3_3v: 3-3-v-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "3.3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + device_type = "soc";
> + ranges;
> +
> + mmc0: dwmmc0@0xff808000 {
> + compatible = "altr,socfpga-dw-mshc";
> + reg = <0xff808000 0x1000>;
> + interrupts = <0 139 4>;

This interrupt number is not correct. Copy/paste error from Cyclone5?
For S10, I think it's 96.

> + num-slots = <1>;
> + broken-cd;
> + bus-width = <4>;
> + fifo-depth = <0x400>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + drvsel = <3>;
> + smplsel = <0>;
> + status = "okay";
> + u-boot,dm-pre-reloc;
> + vmmc-supply = <_3_3v>;
> + vqmmc-supply = <_3_3v>;
> + };
> + };
> +};
> 

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

Re: [U-Boot] ZynqMP breakage

[Simon Glass]

Hi Michal,

On 6 September 2016 at 07:40, Michal Simek  wrote:
> Hi,
>
> On 6.9.2016 14:57, Simon Glass wrote:
>> Hi Alex,
>>
>> On 6 September 2016 at 06:55, Alexander Graf  wrote:
>>> On 09/06/2016 02:52 PM, Simon Glass wrote:

 Hi Alex,

 On 6 September 2016 at 03:09, Alexander Graf  wrote:
>
> On 09/06/2016 03:05 AM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 5 September 2016 at 04:51, Alexander Graf  wrote:
>>>
>>> On 08/19/2016 08:45 AM, Michal Simek wrote:

 On 16.8.2016 20:39, Alexander Graf wrote:
>
> Hi Michal,
>
> I just tried to run the latest u-boot master + a few patches to
> implement
> generic PSCI RTS support on zynqmp and got this:
>
> e
> U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200)
> Xilinx
> ZynqMP ZCU102
>
> I2C:   ready
> DRAM:  4 GiB
> EL Level:   EL2
> MMC:   sdhci@ff17: 0
> Using default environment
>
> In:serial@ff00
> Out:   serial@ff00
> Err:   serial@ff00
> Bootmode: SD_MODE1
> SCSI:  SATA link 0 timeout.
> Target spinup took 0 ms.
> AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
> scanning bus for devices...
> "Synchronous Abort" handler, esr 0x9604
> ELR: 7ff42d20
> LR:  7ff3ff10
> x0 :  x1 : 
> x2 : 0001 x3 : 7df1aa80
> x4 :  x5 : 0001
> x6 : 0200 x7 : 0004
> x8 : 7ff9f800 x9 : 0008
> x10: 7ff9f8f0 x11: 
> x12:  x13: 
> x14: 7ff8242f x15: 7ff82435
> x16: 7ff84388 x17: 7ff84388
> x18: 7df1ade8 x19: 7df1aa80
> x20: 7ff92cb8 x21: 7ff9f800
> x22: 7ff9f000 x23: 0078
> x24: 7ff9f8f0 x25: 
> x26: 7ff9f800 x27: 7ff9f000
> x28: 7ff9fb00 x29: 7df1aca0
>
> Resetting CPU ...
>
> resetting …
>
> Is this a known problem?

 Is this issue with usb?
 I have usb off on zcu102 that's why if this usb issue
 I am not aware about it.
>>>
>>>
>>> After a bit of digging, turns out it's CONFIG_BLK. If I disable that
>>> things
>>> work again (albeit without mmc access, since that one requires
>>> CONFIG_BLK
>>> now).
>>
>> I don't have a zynqmp device, so cannot test with that unfortunately.
>
>
> Well, QEMU supports zcu102 emulation in the latest version, so you could
> use
> that to emulate the board:
>
>$ qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m
> 2G
> -drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0
>
> However, I don't see the data abort with the emulated device, only with
> actual hardware. Probably because real hardware is more upset about
> reading
> from address 0 ;). But I can provoke the oops even in QEMU if I unmap the
> first page from the memory map using the patch below.
>
> The oops happens in blk_dread because block_dev->bdev is NULL.

 Yes, this field really should be removed. As the comment says it's a
 hangover from pre-CONFIG_BLK where functions use a struct blk_dev * to
 specify the block device instead of a struct udevice *. It came up
 recently on a patch you sent also which is why I am so against using
 it.

 That said, I'm not sure why it is unset. The path should be:

 sdhci_bind()
 mmc_bind()
 blk_create_devicef()
 blk_create_device()
 which sets:

 desc->bdev = dev;

 [snip]
>>>
>>>
>>> The special case about ZynqMP is that it has 2 storage backends, one that
>>> uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI
>>> controller). I guess something goes wrong with the latter.
>>
>> OK, well it would be good to convert it. It certainly won't work
>> without it and I'm a little surprised that it compiles :-)
>
> probably good time to convert it. Driver itself has only sata init
> sequence and then it is just compatible with ahci. That's why conversion
> should be pretty easy.
>
> Simon: Which driver should I use as inspiration for conversion?

I looked at sata a while back, so here are a few ideas...

Existing sata.h functions should be #ifdef'd out

- init_sata() should be handled by the driver probe() method
- hopefully 

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

[Tom Rini]

On Tue, Sep 06, 2016 at 10:51:05AM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> The following changes since commit 46fe9eb08812cc27a0d5cd97d97373c14d578fe9:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-net (2016-08-23
> 07:20:36 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 19c6e9ac4a43d7e261220e2de4bb1045165558c0:
> 
>   mx6ul_14x14_ev: Enable the CCGR clocks earlier (2016-09-06 10:35:02 +0200)

OK, NAK.  This is breaking a whole bunch of imx6 boards (nitrogen6s1g is
just the latest most in my build cycle, but I'm at 59 failed to build
atm).  Since the release is next week, please give these a
re-evaluation.  I think that perhaps:

> Breno Lima (1):
>   warp7: Modify fdt_file environment variable
> 
> Christopher Spinrath (1):
>   ARM: board: cm_fx6: fix mtd partition fixup
[snip]
> Fabio Estevam (9):
[snip]
>   warp: Fix RAM size runtime detection
[snip]
>   mx6ul_14x14_evk: Pass refsel and refr fields to avoid hang
>   mx6ul_14x14_evk: Adjust SPL DDR3 settings
>   mx6ul_14x14_ev: Enable the CCGR clocks earlier
[snip]
> Stefan Agner (11):
>   mtd: nand: mxs: fix cache alignment for cache lines >32

and maybe a few others are the type of bugfixes we still want at this
stage, 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 v2 1/3] warp7: Add a secure mode target

[Fabio Estevam]

On Tue, Sep 6, 2016 at 8:08 AM, Stefano Babic  wrote:

> You're right, strange, something went wrong. Now they are on the server.

Ok, great. As these three patches didn't make into your pull request
to Tom: will you submit another pull request which includes them?

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

[U-Boot] [PATCH v3 0/8] Clean-up: squash lines for immediate return

[Masahiro Yamada]

ret = [expression];
if (ret)
return ret;

return 0;

...  is equivalent to:

return [expression];

First, I sent a tree-wide patch:
http://patchwork.ozlabs.org/patch/665199/

In the review of v1, Stephen suggested that
twee-wide conversion with something like Coccinelle
can break code uniformity.
I took a closer look once again, I found many hunks
we should not change.

So, here is an updated series.

I limited this refactoring to cases, I think, really
beneficial.
(Mostly, they well be simple wrappers with this series.)

I also split patches per-subsystem
for easier review and Acked-by
(or NACK if reviewers found no good reason to change).



Masahiro Yamada (8):
  mmc: squash lines for immediate return
  video: squash lines for immediate return
  usb: replace ehci_*_remove() with usb_deregister()
  usb: squash lines for immediate return
  x86: squash lines for immediate return
  libfdt: simplify fdt_del_mem_rsv()
  arch,board: squash lines for immediate return
  drivers: squash lines for immediate return

 arch/arm/cpu/arm920t/imx/timer.c  |  6 +-
 arch/arm/cpu/armv7/am33xx/sys_info.c  |  4 +---
 arch/arm/cpu/sa1100/timer.c   |  5 +
 arch/arm/mach-zynq/cpu.c  |  8 ++--
 arch/blackfin/cpu/interrupts.c|  5 +
 arch/m68k/lib/time.c  |  4 +---
 arch/powerpc/cpu/mpc512x/cpu.c|  6 +-
 arch/powerpc/cpu/mpc83xx/cpu.c|  6 +-
 arch/x86/cpu/baytrail/valleyview.c|  8 +---
 arch/x86/cpu/ivybridge/ivybridge.c|  8 +---
 arch/x86/cpu/qemu/qemu.c  |  8 +---
 arch/x86/cpu/queensbay/tnc.c  |  8 +---
 arch/xtensa/lib/time.c|  5 +
 board/amcc/bamboo/bamboo.c|  6 +-
 board/amcc/bubinga/bubinga.c  |  5 +
 board/amcc/canyonlands/canyonlands.c  |  6 +-
 board/corscience/tricorder/tricorder-eeprom.c | 20 +--
 board/freescale/common/zm7300.c   |  4 +---
 board/samsung/goni/goni.c |  8 +---
 board/ti/omap5_uevm/evm.c |  5 +
 common/usb.c  | 20 +++
 common/usb_kbd.c  |  5 +
 common/usb_storage.c  |  9 +++--
 drivers/block/sym53c8xx.c |  5 ++---
 drivers/ddr/fsl/ddr1_dimm_params.c| 12 ++--
 drivers/ddr/fsl/ddr2_dimm_params.c| 12 ++--
 drivers/ddr/marvell/a38x/ddr3_a38x.c  |  6 +-
 drivers/mmc/atmel_sdhci.c |  7 +--
 drivers/mmc/exynos_dw_mmc.c   |  7 +--
 drivers/mmc/mmc_boot.c| 28 ---
 drivers/mmc/msm_sdhci.c   |  7 +--
 drivers/mmc/rockchip_dw_mmc.c |  7 +--
 drivers/mmc/rockchip_sdhci.c  |  7 +--
 drivers/mmc/sandbox_mmc.c |  7 +--
 drivers/mmc/zynq_sdhci.c  |  7 +--
 drivers/power/axp809.c|  8 +---
 drivers/rtc/m48t35ax.c|  4 +---
 drivers/usb/host/ehci-atmel.c | 13 +
 drivers/usb/host/ehci-fsl.c   | 13 +
 drivers/usb/host/ehci-generic.c   |  7 +--
 drivers/usb/host/ehci-marvell.c   | 13 +
 drivers/usb/host/ehci-mx6.c   | 13 +
 drivers/usb/host/ehci-pci.c   | 13 +
 drivers/usb/host/ehci-tegra.c | 13 +
 drivers/usb/host/ehci-zynq.c  | 13 +
 drivers/usb/host/xhci-fsl.c   |  7 +--
 drivers/video/bridge/ptn3460.c|  7 +--
 drivers/video/broadwell_igd.c |  5 +
 drivers/video/exynos/exynos_dp_lowlevel.c |  6 +-
 drivers/video/tegra124/display.c  |  8 +---
 drivers/video/vidconsole-uclass.c |  6 +-
 lib/libfdt/fdt_rw.c   |  6 +-
 52 files changed, 75 insertions(+), 361 deletions(-)

-- 
1.9.1

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

Re: [U-Boot] [PATCH] eth: asix88179: Reset device during probe with DM_ETH enabled

[Nikolaus Schulz]

On Mon, Sep 05, 2016 at 07:04:49PM -0600, Simon Glass wrote:
> On 30 August 2016 at 08:01, Nikolaus Schulz
>  wrote:
> > With the ethernet driver model enabled, reset the device before reading
> > the MAC address, just like it's done for the non-device-model code path.
> > This avoids a timeout when the interface is first used.
> >
> > Signed-off-by: Nikolaus Schulz 
> > ---
> >  drivers/usb/eth/asix88179.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/usb/eth/asix88179.c b/drivers/usb/eth/asix88179.c
> > index 7548269..0725940 100644
> > --- a/drivers/usb/eth/asix88179.c
> > +++ b/drivers/usb/eth/asix88179.c
> > @@ -878,6 +878,10 @@ static int ax88179_eth_probe(struct udevice *dev)
> > usb_dev = priv->ueth.pusb_dev;
> > priv->maxpacketsize = usb_dev->epmaxpacketout[AX_ENDPOINT_OUT];
> >
> > +   ret = asix_basic_reset(>ueth, priv);
> > +   if (ret)
> > +   return ret;
> > +
> > /* Get the MAC address */
> > ret = asix_read_mac(>ueth, pdata->enetaddr);
> > if (ret)
> 
> How come this doesn't happen in ax88179_eth_start()?

In fact I first had put it there, but that was basically killing the
ethernet. And having it in the probe function matches the non-DM code
path, which has it in ax88179_eth_get_info.

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

[U-Boot] [PATCH] efi_loader: provide efi_mem_desc version

[Mian Yousaf Kaukab]

Provide version of struct efi_mem_desc in efi_get_memory_map().

EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines
memory descriptor version to 1. Linux kernel also expects descriptor
version to be 1 and prints following warning during boot if its not:

Unexpected EFI_MEMORY_DESCRIPTOR version 0

Signed-off-by: Mian Yousaf Kaukab 
---
Resending the patch as previous attempt was blocked for some reason.

 include/efi.h   | 2 ++
 lib/efi_loader/efi_memory.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/include/efi.h b/include/efi.h
index 83de2d4..5a3b8cf 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -159,6 +159,8 @@ struct efi_mem_desc {
u64 attribute;
 };
 
+#define EFI_MEMORY_DESCRIPTOR_VERSION 1
+
 /* Allocation types for calls to boottime->allocate_pages*/
 #define EFI_ALLOCATE_ANY_PAGES 0
 #define EFI_ALLOCATE_MAX_ADDRESS   1
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index df3547c..80e4e26 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -339,6 +339,9 @@ efi_status_t efi_get_memory_map(unsigned long 
*memory_map_size,
if (descriptor_size)
*descriptor_size = sizeof(struct efi_mem_desc);
 
+   if (descriptor_version)
+   *descriptor_version = EFI_MEMORY_DESCRIPTOR_VERSION;
+
if (*memory_map_size < map_size)
return EFI_BUFFER_TOO_SMALL;
 
-- 
2.6.6

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

Re: [U-Boot] [PATCH v2 11/11] arm: socfpga: Add support for Stratix 10 SoC dev kit

[Dinh Nguyen]

On 09/06/2016 05:03 AM, Chin Liang See wrote:
> Add support for Stratix 10 SoC development kit
> 
> Signed-off-by: Chin Liang See 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Ley Foon Tan 
> ---
> Changes for v2
> - Sorting the config alphabetically
> ---

Please re-check all of your new file attributes for this series.

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

Re: [U-Boot] [PATCH] treewide: compress lines for immediate return

[Stefano Babic]

Hi Masahiro,

On 02/09/2016 12:36, Masahiro Yamada wrote:
>   -ret = expression;
>   -if (ret)
>   -return ret;
>   -return 0;
>   +return expression;
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/arm/cpu/armv7/bcm235xx/clk-bsc.c   |  6 +-
>  arch/arm/cpu/armv7/bcm281xx/clk-bsc.c   |  6 +-
>  arch/arm/mach-rockchip/rk3288/sdram_rk3288.c| 11 --
>  arch/arm/mach-uniphier/dram/umc-ld20.c  |  6 +-
>  arch/powerpc/lib/bootm.c|  6 +-
>  arch/x86/cpu/baytrail/valleyview.c  |  8 +--
>  arch/x86/cpu/broadwell/cpu.c|  6 +-
>  arch/x86/cpu/broadwell/sata.c   |  7 +--
>  arch/x86/cpu/ivybridge/bd82x6x.c|  6 +-
>  arch/x86/cpu/ivybridge/cpu.c|  6 +-
>  arch/x86/cpu/ivybridge/gma.c|  6 +-
>  arch/x86/cpu/ivybridge/ivybridge.c  |  8 +--
>  arch/x86/cpu/qemu/qemu.c|  8 +--
>  arch/x86/cpu/queensbay/tnc.c| 14 ++---
>  board/compulab/cm_fx6/cm_fx6.c  |  6 +-
>  board/freescale/common/fsl_validate.c   |  6 +-
>  board/freescale/mx6qsabreauto/mx6qsabreauto.c   | 11 +++---
>  board/freescale/mx6sxsabreauto/mx6sxsabreauto.c | 11 +++---
>  board/keymile/km_arm/fpga_config.c  | 14 ++---
>  board/kosagi/novena/novena.c|  6 +-
>  board/samsung/goni/goni.c   |  8 +--
>  board/ti/common/board_detect.c  |  6 +-
>  drivers/adc/adc-uclass.c| 12 ++-
>  drivers/core/root.c | 12 ++-
>  drivers/dfu/dfu_sf.c|  8 ++-
>  drivers/gpio/74x164_gpio.c  |  7 +--
>  drivers/gpio/axp_gpio.c |  6 +-
>  drivers/misc/cros_ec.c  |  6 +-
>  drivers/misc/pca9551_led.c  | 13 ++--
>  drivers/misc/tegra186_bpmp.c|  6 +-
>  drivers/mmc/atmel_sdhci.c   |  7 +--
>  drivers/mmc/davinci_mmc.c   |  6 +-
>  drivers/mmc/exynos_dw_mmc.c |  7 +--
>  drivers/mmc/mmc-uclass.c|  7 +--
>  drivers/mmc/mmc_boot.c  | 28 
> +++--
>  drivers/mmc/mmc_legacy.c|  7 +--
>  drivers/mmc/msm_sdhci.c |  7 +--
>  drivers/mmc/mxcmmc.c|  6 +-
>  drivers/mmc/pxa_mmc_gen.c   | 21 +++
>  drivers/mmc/rockchip_dw_mmc.c   |  7 +--
>  drivers/mmc/rockchip_sdhci.c|  7 +--
>  drivers/mmc/sandbox_mmc.c   |  7 +--
>  drivers/mmc/zynq_sdhci.c|  7 +--
>  drivers/mtd/nand/fsl_elbc_nand.c|  6 +-
>  drivers/mtd/nand/fsl_ifc_nand.c |  5 +
>  drivers/mtd/nand/tegra_nand.c   |  6 +-
>  drivers/mtd/nand/vf610_nfc.c|  6 +-
>  drivers/mtd/ubi/attach.c| 14 -
>  drivers/net/fm/eth.c|  6 +-
>  drivers/net/mvpp2.c | 16 --
>  drivers/net/phy/mv88e6352.c |  6 +-
>  drivers/net/xilinx_emaclite.c   |  7 +--
>  drivers/pci/pcie_imx.c  | 12 ++-
>  drivers/power/axp809.c  |  8 +--
>  drivers/rtc/i2c_rtc_emul.c  | 13 ++--
>  drivers/usb/host/ehci-atmel.c   |  8 +--
>  drivers/usb/host/ehci-fsl.c |  8 +--
>  drivers/usb/host/ehci-marvell.c |  8 +--
>  drivers/usb/host/ehci-mx6.c |  8 +--
>  drivers/usb/host/ehci-pci.c |  8 +--
>  drivers/usb/host/ehci-zynq.c|  8 +--
>  drivers/usb/host/xhci-fsl.c |  7 +--
>  drivers/usb/ulpi/ulpi.c |  6 +-
>  drivers/video/bridge/ptn3460.c  |  8 +--
>  drivers/video/rockchip/rk_edp.c |  6 +-
>  drivers/video/simple_panel.c|  7 +--
>  drivers/video/tegra124/display.c|  8 +--
>  drivers/video/vidconsole-uclass.c   |  7 +--
>  fs/ubifs/budget.c   |  7 ++-
>  fs/ubifs/gc.c   |  5 +
>  fs/ubifs/lpt_commit.c   |  5 +
>  fs/ubifs/ubifs.c|  6 +-
>  lib/libfdt/fdt_rw.c |  6 +-
>  lib/rsa/rsa-checksum.c 

[U-Boot] [PATCH] efi_loader: provide efi_mem_desc version

[Mian Yousaf Kaukab]

Provide version of struct efi_mem_desc in efi_get_memory_map().

EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines
memory descriptor version to 1. Linux kernel also expects descriptor
version to be 1 and prints following warning during boot if its not:

Unexpected EFI_MEMORY_DESCRIPTOR version 0

Signed-off-by: Mian Yousaf Kaukab 
---
 include/efi.h   | 2 ++
 lib/efi_loader/efi_memory.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/include/efi.h b/include/efi.h
index 83de2d4..5a3b8cf 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -159,6 +159,8 @@ struct efi_mem_desc {
u64 attribute;
 };
 
+#define EFI_MEMORY_DESCRIPTOR_VERSION 1
+
 /* Allocation types for calls to boottime->allocate_pages*/
 #define EFI_ALLOCATE_ANY_PAGES 0
 #define EFI_ALLOCATE_MAX_ADDRESS   1
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index df3547c..80e4e26 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -339,6 +339,9 @@ efi_status_t efi_get_memory_map(unsigned long 
*memory_map_size,
if (descriptor_size)
*descriptor_size = sizeof(struct efi_mem_desc);
 
+   if (descriptor_version)
+   *descriptor_version = EFI_MEMORY_DESCRIPTOR_VERSION;
+
if (*memory_map_size < map_size)
return EFI_BUFFER_TOO_SMALL;
 
-- 
2.6.6

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

Re: [U-Boot] ZynqMP breakage

[Michal Simek]

Hi,

On 6.9.2016 14:57, Simon Glass wrote:
> Hi Alex,
> 
> On 6 September 2016 at 06:55, Alexander Graf  wrote:
>> On 09/06/2016 02:52 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 6 September 2016 at 03:09, Alexander Graf  wrote:

 On 09/06/2016 03:05 AM, Simon Glass wrote:
>
> Hi Alex,
>
> On 5 September 2016 at 04:51, Alexander Graf  wrote:
>>
>> On 08/19/2016 08:45 AM, Michal Simek wrote:
>>>
>>> On 16.8.2016 20:39, Alexander Graf wrote:

 Hi Michal,

 I just tried to run the latest u-boot master + a few patches to
 implement
 generic PSCI RTS support on zynqmp and got this:

 e
 U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200)
 Xilinx
 ZynqMP ZCU102

 I2C:   ready
 DRAM:  4 GiB
 EL Level:   EL2
 MMC:   sdhci@ff17: 0
 Using default environment

 In:serial@ff00
 Out:   serial@ff00
 Err:   serial@ff00
 Bootmode: SD_MODE1
 SCSI:  SATA link 0 timeout.
 Target spinup took 0 ms.
 AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
 flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
 scanning bus for devices...
 "Synchronous Abort" handler, esr 0x9604
 ELR: 7ff42d20
 LR:  7ff3ff10
 x0 :  x1 : 
 x2 : 0001 x3 : 7df1aa80
 x4 :  x5 : 0001
 x6 : 0200 x7 : 0004
 x8 : 7ff9f800 x9 : 0008
 x10: 7ff9f8f0 x11: 
 x12:  x13: 
 x14: 7ff8242f x15: 7ff82435
 x16: 7ff84388 x17: 7ff84388
 x18: 7df1ade8 x19: 7df1aa80
 x20: 7ff92cb8 x21: 7ff9f800
 x22: 7ff9f000 x23: 0078
 x24: 7ff9f8f0 x25: 
 x26: 7ff9f800 x27: 7ff9f000
 x28: 7ff9fb00 x29: 7df1aca0

 Resetting CPU ...

 resetting …

 Is this a known problem?
>>>
>>> Is this issue with usb?
>>> I have usb off on zcu102 that's why if this usb issue
>>> I am not aware about it.
>>
>>
>> After a bit of digging, turns out it's CONFIG_BLK. If I disable that
>> things
>> work again (albeit without mmc access, since that one requires
>> CONFIG_BLK
>> now).
>
> I don't have a zynqmp device, so cannot test with that unfortunately.


 Well, QEMU supports zcu102 emulation in the latest version, so you could
 use
 that to emulate the board:

$ qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m
 2G
 -drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0

 However, I don't see the data abort with the emulated device, only with
 actual hardware. Probably because real hardware is more upset about
 reading
 from address 0 ;). But I can provoke the oops even in QEMU if I unmap the
 first page from the memory map using the patch below.

 The oops happens in blk_dread because block_dev->bdev is NULL.
>>>
>>> Yes, this field really should be removed. As the comment says it's a
>>> hangover from pre-CONFIG_BLK where functions use a struct blk_dev * to
>>> specify the block device instead of a struct udevice *. It came up
>>> recently on a patch you sent also which is why I am so against using
>>> it.
>>>
>>> That said, I'm not sure why it is unset. The path should be:
>>>
>>> sdhci_bind()
>>> mmc_bind()
>>> blk_create_devicef()
>>> blk_create_device()
>>> which sets:
>>>
>>> desc->bdev = dev;
>>>
>>> [snip]
>>
>>
>> The special case about ZynqMP is that it has 2 storage backends, one that
>> uses DM (the sdhc controller) and one that isn't converted to DM (the AHCI
>> controller). I guess something goes wrong with the latter.
> 
> OK, well it would be good to convert it. It certainly won't work
> without it and I'm a little surprised that it compiles :-)

probably good time to convert it. Driver itself has only sata init
sequence and then it is just compatible with ahci. That's why conversion
should be pretty easy.

Simon: Which driver should I use as inspiration for conversion?

Thanks,
Michal


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

Re: [U-Boot] Building u-boot.imx and SPL simultaneously

[Otavio Salvador]

On Tue, Sep 6, 2016 at 10:40 AM, Tom Rini  wrote:
> On Fri, Sep 02, 2016 at 10:53:58PM +0200, Petr Kulhavy wrote:
>> Hi Fabio,
>>
>> On 02/09/16 22:03, Fabio Estevam wrote:
>> >You don't need u-boot.imx to boot the board with imx_usb_loader.
>> >Check the README update that Stefano did with this commit:
>> >
>> >commit 40f4839ce12adfc0223d6e3035cf9c3a4754a0ec
>> >Author: Stefano Babic 
>> >Date:   Fri Dec 11 17:30:42 2015 +0100
>> >
>> > imx_common: check for Serial Downloader in spl_boot_device
>> >
>> > Check for bmode before reading the boot device
>> > to check if a serial downloader is started,
>> > and returns UART if the serial downloader is set,
>> > letting SPL to wait for an image if
>> > CONFIG_SPL_YMODEM_SUPPORT is set.
>> >
>> > This allows to load again a SPL based board
>> > with imx_usb_loader together with a tool
>> > such as kermit.
>> >
>> > Signed-off-by: Stefano Babic 
>> > CC: Tim Harvey 
>> > CC: Fabio Estevam 
>> > CC: Eric Nelson 
>> > Reviewed-by: Eric Nelson 
>> > Tested-by: Eric Nelson 
>> This is not particularly what I want to do. I want to load the
>> u-boot.img directly via the imx_usb_loader.
>> The kermit method is unacceptably slow for a production environment.
>
> Another place this doesn't work (which is where it doesn't work for me)
> is when the console is already open and I can't easily take it away to
> shoot over the next stage via Y-MODEM.
>
> Would it be possible to implement having the next stage also be sent via
> imx_usb_loader?  ie there's examples today of doing u-boot.imx + kernel
> + initrd via imx_usb_loader, so what would be needed for SPL +
> u-boot.img (+ kenrel + initrd) via imx_usb_loader?  Thanks!

It should be the same except that the image will be already loaded and
we need to instruct the SPL to jump to it. Am I missing something?

...
zImage-foo:load 0x8200
core-image-minimal-foo.cpio.gz:load 0x8380
u-boot.imx:clear_dcd,jump header

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/11] arm: socfpga: stratix10: Add SOCFPGA Stratix10 base address

[Dinh Nguyen]

On 09/06/2016 05:03 AM, Chin Liang See wrote:
> Add base address header file for Stratix10 SoC
> 
> Signed-off-by: Chin Liang See 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Ley Foon Tan 
> Acked-by: Marek Vasut 
> ---
>  arch/arm/mach-socfpga/include/mach/base_addr_s10.h | 48 
> ++
>  1 file changed, 48 insertions(+)
>  create mode 100755 arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h 
> b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> new file mode 100755

Shouldn't this be 644?

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

Re: [U-Boot] [PATCH v3 2/8] video: squash lines for immediate return

[Simon Glass]

On 6 September 2016 at 07:17, Masahiro Yamada
 wrote:
> For vidconsole_post_probe(), it is common coding style to let a
> probe method return the value of a register function.
>
> The others will become simple wrapper functions.
>
> Signed-off-by: Masahiro Yamada 
> Acked-by: Anatolij Gustschin 
> ---
>
> Changes in v3:
>   - Two more fixes
>   - s/resister/register/
>
>  drivers/video/bridge/ptn3460.c| 7 +--
>  drivers/video/broadwell_igd.c | 5 +
>  drivers/video/exynos/exynos_dp_lowlevel.c | 6 +-
>  drivers/video/tegra124/display.c  | 8 +---
>  drivers/video/vidconsole-uclass.c | 6 +-
>  5 files changed, 5 insertions(+), 27 deletions(-)

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

Re: [U-Boot] [PATCH v2 09/11] arm: socfpga: stratix10: Add board directory for Stratix 10 socdk

[Dinh Nguyen]

On 09/06/2016 05:03 AM, Chin Liang See wrote:
> Add board folder for Stratix 10 SoC development kit
> 
> Signed-off-by: Chin Liang See 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Ley Foon Tan 
> ---
>  board/altera/stratix10-socdk/MAINTAINERS | 7 +++
>  board/altera/stratix10-socdk/Makefile| 7 +++
>  board/altera/stratix10-socdk/socfpga.c   | 7 +++
>  3 files changed, 21 insertions(+)
>  create mode 100755 board/altera/stratix10-socdk/MAINTAINERS
>  create mode 100755 board/altera/stratix10-socdk/Makefile
>  create mode 100755 board/altera/stratix10-socdk/socfpga.c
> 
> diff --git a/board/altera/stratix10-socdk/MAINTAINERS 
> b/board/altera/stratix10-socdk/MAINTAINERS
> new file mode 100755

644?

> index 000..596933c
> --- /dev/null
> +++ b/board/altera/stratix10-socdk/MAINTAINERS
> @@ -0,0 +1,7 @@
> +SOCFPGA BOARD
> +M:   Chin-Liang See 
> +M:   Dinh Nguyen 
> +S:   Maintained
> +F:   board/altera/stratix10-socdk/
> +F:   include/configs/socfpga_stratix10_socdk.h
> +F:   configs/socfpga_stratix10_defconfig
> diff --git a/board/altera/stratix10-socdk/Makefile 
> b/board/altera/stratix10-socdk/Makefile
> new file mode 100755

644?

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

[U-Boot] UBI and UBIFS on ARM64

[Adam Oleksy]

Dear U-Boot community,
I'm developing software for Xilinx ZynqMP platform, which is made in
64-bit architecture. I would like to store every artifact needed to
boot up on the UBIFS partition. I faced problem, that u-boot does not
want to compile with enabled UBI/UBIFS support, due to lack of some
atomic operations on longs. So, I've written them (see
http://pastebin.com/ibp0Zt99). Please note, that I've written only
that functions, which are needed by UBI/UBIFS. Then UBIFS started work
on the target. Almost... because I've found that large files (~20MiB)
can't be read. I've enabled debug messages, but I don't know how to
interpret them (please see http://pastebin.com/gByDcdvw). Maybe you
are able to help me?
I've also checked how the UBIFS behaves in the Linux, and the result
is that everything works as expected. It means that I can write large
files to UBIFS, and read them back successfully.
Should you need any further information, please do not hesitate to contact me.

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

Re: [U-Boot] [PATCH v3 7/8] arch, board: squash lines for immediate return

[Minkyu Kang]

On 6 September 2016 at 22:17, Masahiro Yamada  wrote:

> Remove unneeded variables and assignments.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v3:
>   - More fixes
>
>  arch/arm/cpu/arm920t/imx/timer.c  |  6 +-
>  arch/arm/cpu/armv7/am33xx/sys_info.c  |  4 +---
>  arch/arm/cpu/sa1100/timer.c   |  5 +
>  arch/arm/mach-zynq/cpu.c  |  8 ++--
>  arch/blackfin/cpu/interrupts.c|  5 +
>  arch/m68k/lib/time.c  |  4 +---
>  arch/powerpc/cpu/mpc512x/cpu.c|  6 +-
>  arch/powerpc/cpu/mpc83xx/cpu.c|  6 +-
>  arch/xtensa/lib/time.c|  5 +
>  board/amcc/bamboo/bamboo.c|  6 +-
>  board/amcc/bubinga/bubinga.c  |  5 +
>  board/amcc/canyonlands/canyonlands.c  |  6 +-
>  board/corscience/tricorder/tricorder-eeprom.c | 20 +---
>  board/freescale/common/zm7300.c   |  4 +---
>  board/samsung/goni/goni.c |  8 +---
>  board/ti/omap5_uevm/evm.c |  5 +
>  16 files changed, 21 insertions(+), 82 deletions(-)
>
> diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
> index 1600568..e8329bb 100644
> --- a/board/samsung/goni/goni.c
> +++ b/board/samsung/goni/goni.c
> @@ -45,17 +45,11 @@ void i2c_init_board(void)
>
>  int power_init_board(void)
>  {
> -   int ret;
> -
> /*
>  * For PMIC the I2C bus is named as I2C5, but it is connected
>  * to logical I2C adapter 0
>  */
> -   ret = pmic_init(I2C_0);
> -   if (ret)
> -   return ret;
> -
> -   return 0;
> +   return pmic_init(I2C_0);
>  }
>
>  int dram_init(void)
>

Reviewed-by: Minkyu Kang 

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