Re: [U-Boot] [PATCH 0/4] ath79: fix some minor defects

[Daniel Schwierzeck]

Am 03.05.2016 um 23:28 schrieb Marek Vasut:
> On 04/15/2016 01:19 PM, Daniel Schwierzeck wrote:
>>
>>
>> Am 12.04.2016 um 05:09 schrieb Wills Wang:
>>>
>>> These series of patch based on top of mips/next, it fix some defects on
>>> the previous patch series "add support for atheros ath79 based SOCs".
>>>
>>>
>>> Wills Wang (4):
>>>   ath79: spi: Remove the explicit pinctrl setting
>>>   ar933x: serial: Remove the explicit pinctrl setting
>>>   ath79: ar933x: use BIT macro for bit shift operation
>>>   ath79: add readonly attribute for ath79_soc_desc
>>>
>>>  arch/mips/mach-ath79/ar933x/ddr.c | 14 +++---
>>>  arch/mips/mach-ath79/cpu.c|  8 
>>>  drivers/serial/serial_ar933x.c| 16 ++--
>>>  drivers/spi/ath79_spi.c   | 12 
>>>  4 files changed, 13 insertions(+), 37 deletions(-)
>>>
>>
>> all four patches applied to u-boot-mips/next, thanks!
>>
> Can you please update next on top of u-boot/master , so I can submit the
> ar9344 ? Thanks!

ok, done

-- 
- Daniel



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

[U-Boot] [PATCH v5 3/3] spl: Support loading a FIT from FAT FS

[Lokesh Vutla]

Detect a FIT when loading from a FAT File system and handle it using the
new FIT SPL support.

Signed-off-by: Lokesh Vutla 
---
 common/spl/spl_fat.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
index d761b26..cdb9811 100644
--- a/common/spl/spl_fat.c
+++ b/common/spl/spl_fat.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int fat_registered;
 
@@ -39,6 +40,20 @@ static int spl_register_fat_device(struct blk_desc 
*block_dev, int partition)
return err;
 }
 
+static ulong spl_fit_read(struct spl_load_info *load, ulong file_offset,
+ ulong size, void *buf)
+{
+   loff_t actread;
+   int ret;
+   char *filename = (char *)load->priv;
+
+   ret = fat_read_file(filename, buf, file_offset, size, );
+   if (ret)
+   return ret;
+
+   return actread;
+}
+
 int spl_load_image_fat(struct blk_desc *block_dev,
int partition,
const char *filename)
@@ -57,9 +72,21 @@ int spl_load_image_fat(struct blk_desc *block_dev,
if (err <= 0)
goto end;
 
-   spl_parse_image_header(header);
+   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+   image_get_magic(header) == FDT_MAGIC) {
+   struct spl_load_info load;
+
+   debug("Found FIT\n");
+   load.read = spl_fit_read;
+   load.bl_len = 1;
+   load.priv = (void *)filename;
 
-   err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
+   return spl_load_simple_fit(, 0, header);
+   } else {
+   spl_parse_image_header(header);
+
+   err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
+   }
 
 end:
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-- 
2.7.4

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

[U-Boot] [PATCH] Fix various typos, scattered over the code.

[Robert P. J. Day]

Spelling corrections for (among other things):

* environment
* override
* variable
* ftd (should be "fdt", for flattened device tree)
* embedded
* FTDI
* emulation
* controller

---

  the fixes for "controller" here are independent of the previous
patch.

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 d580a43..a9b12a4 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
@@ -180,7 +180,7 @@ ulong get_ddr_freq(ulong ctrl_num)

/*
 * DDR controller 0 & 1 are on memory complex 0
-* DDR controler 2 is on memory complext 1
+* DDR controller 2 is on memory complext 1
 */
 #ifdef CONFIG_SYS_FSL_HAS_DP_DDR
if (ctrl_num >= 2)
diff --git a/arch/arm/mach-uniphier/boot-mode/boot-mode.c 
b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
index b08cd6c..614f85f 100644
--- a/arch/arm/mach-uniphier/boot-mode/boot-mode.c
+++ b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
@@ -110,7 +110,7 @@ static int do_mmcsetn(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])

 U_BOOT_CMD(
   mmcsetn, 1,  1,  do_mmcsetn,
-   "Set the first MMC (not SD) dev number to \"mmc_first_dev\" enviroment",
+   "Set the first MMC (not SD) dev number to \"mmc_first_dev\" 
environment",
""
 );
 #endif
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index f852a1f..fe37d1f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -145,7 +145,7 @@ config MIPS_BOOT_ENV_LEGACY
  Enable this option if you want U-Boot to hand over the Yamon-style
  environment to the kernel. Information like memory size, initrd
  address and size will be prepared as zero-terminated key/value list.
- The address of the enviroment is stored in register $a2.
+ The address of the environment is stored in register $a2.

 config MIPS_BOOT_FDT
bool "Hand over a flattened device tree to Linux kernel"
diff --git a/arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c 
b/arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c
index 916451a..455136c 100644
--- a/arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c
+++ b/arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c
@@ -1151,7 +1151,7 @@ phys_size_t initdram(int board_type)
dram_size *= ranks;
debug("dram_size = %lu\n", dram_size);

-   /* Start the SDRAM controler */
+   /* Start the SDRAM controller */
mtsdram(DDR0_02, DDR0_02_START_ENCODE(1));
denali_wait_for_dlllock();

diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 64e4e30..8c171b1 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -812,9 +812,9 @@ static int calculate_cmp_img_sig(struct 
fsl_secboot_img_priv *img)
 }
 /* haddr - Address of the header of image to be validated.
  * arg_hash_str - Option hash string. If provided, this
- * overides the key hash in the SFP fuses.
+ * overrides the key hash in the SFP fuses.
  * img_addr_ptr - Optional pointer to address of image to be validated.
- * If non zero addr, this overides the addr of image in header,
+ * If non zero addr, this overrides the addr of image in header,
  * otherwise updated to image addr in header.
  * Acts as both input and output of function.
  * This pointer shouldn't be NULL.
diff --git a/board/freescale/mx28evk/README b/board/freescale/mx28evk/README
index a248fb2..b8bee89 100644
--- a/board/freescale/mx28evk/README
+++ b/board/freescale/mx28evk/README
@@ -45,7 +45,7 @@ or

 or

-"make mx28evk_spi_config"   - store enviroment variables into SPI NOR flash
+"make mx28evk_spi_config"   - store environment variables into SPI NOR 
flash

 Choose the target accordingly.

diff --git a/cmd/fdt.c b/cmd/fdt.c
index 4c18962..898217f 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -1055,7 +1055,7 @@ static char fdt_help_text[] =
" - addr of key blob\n"
"  default 
gd->fdt_blob\n"
 #endif
-   "NOTE: Dereference aliases by omiting the leading '/', "
+   "NOTE: Dereference aliases by omitting the leading '/', "
"e.g. fdt print ethernet0.";
 #endif

diff --git a/cmd/mtdparts.c b/cmd/mtdparts.c
index 86a4689..44b2c3a 100644
--- a/cmd/mtdparts.c
+++ b/cmd/mtdparts.c
@@ -1742,7 +1742,7 @@ int mtdparts_init(void)
debug("last_partition : %s\n", last_partition);
debug("env_partition  : %s\n", current_partition);

-   /* if mtdids varible is empty try to use defaults */
+   /* if mtdids variable is empty try to use defaults */
if (!ids) {
if (mtdids_default) {
debug("mtdids variable not defined, using default\n");
diff --git a/doc/README.commands.spl b/doc/README.commands.spl
index ac33273..cb3e0c8 100644
--- a/doc/README.commands.spl
+++ 

Re: [U-Boot] [PATCH 6/7] usb: hub: Don't continue on get_port_status failure

[Chin Liang See]

On Wed, 2016-05-04 at 10:05 +0200, Stefan Roese wrote:
> On 03.05.2016 22:51, Marek Vasut wrote:
> > The code shouldn't continue probing the port if get_port_status()
> > failed.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Chin Liang See 
> > Cc: Dinh Nguyen 
> > Cc: Hans de Goede 
> > Cc: Stefan Roese 
> > Cc: Stephen Warren 
> > ---
> >   common/usb_hub.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/common/usb_hub.c b/common/usb_hub.c
> > index 4f59802..0f39c9f 100644
> > --- a/common/usb_hub.c
> > +++ b/common/usb_hub.c
> > @@ -402,6 +402,7 @@ static int usb_scan_port(struct usb_device_scan
> > *usb_scan)
> > free(usb_scan);
> > return 0;
> > }
> > +   return 0;
> > }
> > 
> > portstatus = le16_to_cpu(portsts->wPortStatus);
> > 
> 
> Thanks for spotting this:
> 
> Reviewed-by: Stefan Roese 
> 

Reviewed-by: Chin Liang See 
Tested-by: Chin Liang See 

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH 1/7] usb: Don't init pointer to zero, but NULL

[Chin Liang See]

On Wed, 2016-05-04 at 09:36 +0200, Stefan Roese wrote:
> On 03.05.2016 22:51, Marek Vasut wrote:
> > The pointer should always be inited to NULL, not zero (0). These
> > are
> > two different things and not necessarily equal.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Chin Liang See 
> > Cc: Dinh Nguyen 
> > Cc: Hans de Goede 
> > Cc: Stefan Roese 
> > Cc: Stephen Warren 
> > ---
> >   common/usb.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/common/usb.c b/common/usb.c
> > index 4d0de4d..63429d4 100644
> > --- a/common/usb.c
> > +++ b/common/usb.c
> > @@ -1064,7 +1064,7 @@ static int usb_prepare_device(struct
> > usb_device *dev, int addr, bool do_read,
> > 
> >   int usb_select_config(struct usb_device *dev)
> >   {
> > -   unsigned char *tmpbuf = 0;
> > +   unsigned char *tmpbuf = NULL;
> > int err;
> > 
> > err = get_descriptor_len(dev, USB_DT_DEVICE_SIZE,
> > USB_DT_DEVICE_SIZE);
> > 
> 
> Reviewed-by: Stefan Roese 
> 

Reviewed-by: Chin Liang See 
Tested-by: Chin Liang See 

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH 2/7] usb: dwc2: Resend setup packet in all fail cases

[Chin Liang See]

On Tue, 2016-05-03 at 22:51 +0200, Marek Vasut wrote:
> The USB function can respond to a Setup packet with ACK or, in
> case it's busy, it can ignore the Setup packet. The USB function
> usually gets busy if we hammer it with Control EP transfers too
> much (ie. sending multiple Get Descriptor requests in a single
> microframe tends to trigger it on certain USB sticks). The DWC2
> controller will interpret not receiving an ACK after Setup packet
> as XACTERR. Check for this condition and if it happens, retry
> sending the Setup packet.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> Cc: Hans de Goede 
> Cc: Stefan Roese 
> Cc: Stephen Warren 
> ---
>  drivers/usb/host/dwc2.c | 14 ++
>  1 file changed, 14 insertions(+)
> 

Reviewed-by: Chin Liang See 
Tested-by: Chin Liang See 

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

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

[Vignesh R]

This API helps to map physical register addresss pace of device to
virtual address space easily. Its just a wrapper around map_physmem()
with MAP_NOCACHE flag.

Signed-off-by: Vignesh R 
Suggested-by: Simon Glass 
---

v3: Explicitly include header file

v2: New patch

 drivers/core/device.c | 6 ++
 include/dm/device.h   | 9 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 1322991d6c7b..6b19b4b8c7a0 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -678,6 +679,11 @@ void *dev_get_addr_ptr(struct udevice *dev)
return (void *)(uintptr_t)dev_get_addr_index(dev, 0);
 }
 
+void *dev_map_physmem(struct udevice *dev, unsigned long size)
+{
+   return map_physmem(dev_get_addr(dev), size, MAP_NOCACHE);
+}
+
 bool device_has_children(struct udevice *dev)
 {
return !list_empty(>child_head);
diff --git a/include/dm/device.h b/include/dm/device.h
index 8970fc015c7e..5253b5410d9a 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -463,6 +463,15 @@ fdt_addr_t dev_get_addr(struct udevice *dev);
  */
 void *dev_get_addr_ptr(struct udevice *dev);
 
+/* * dev_map_physmem() - Map bus memory into CPU space
+ *
+ * @dev: Pointer to device
+ * @size: size of the memory to map
+ *
+ * @return addr
+ */
+void *dev_map_physmem(struct udevice *dev, unsigned long size);
+
 /**
  * dev_get_addr_index() - Get the indexed reg property of a device
  *
-- 
2.8.2

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

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

[Vignesh R]

This series converts davinci_spi driver to adapt to driver model
framework. And enables the driver on k2l, k2e, k2hk evms. Also,
added support for davinci_spi on k2g evm.

Tested on k2l, k2e, k2hk and k2g evms.

Rebased on top of v2016.05-rc3

Vignesh R (12):
  dm: core: implement dev_map_phsymem()
  spi: davinci_spi: Convert to driver to adapt to DM
  keystone2: spi: do not define DM_SPI and DM_SPI_FLASH for SPL build
  ARM: dts: keystone2: add SPI aliases for davinci SPI nodes
  ARM: dts: k2hk: Enable Davinci SPI controller
  defconfig: k2hk_evm_defconfig: enable SPI driver model
  ARM: dts: k2e: Enable Davinci SPI controller
  defconfig: k2e_evm_defconfig: enable SPI driver model
  ARM: dts: k2l: Enable Davinci SPI controller
  defconfig: k2l_evm_defconfig: enable SPI driver model
  ARM: dts: k2g: add support for Davinci SPI controller
  defconfig: k2g_evm_defconfig: enable SPI driver model

 arch/arm/dts/k2e-evm.dts |   3 +-
 arch/arm/dts/k2g-evm.dts |  24 +++
 arch/arm/dts/k2g.dtsi|  47 +
 arch/arm/dts/k2hk-evm.dts|   3 +-
 arch/arm/dts/k2l-evm.dts |   3 +-
 arch/arm/dts/keystone.dtsi   |   3 +
 configs/k2e_evm_defconfig|   2 +
 configs/k2g_evm_defconfig|   2 +
 configs/k2hk_evm_defconfig   |   2 +
 configs/k2l_evm_defconfig|   2 +
 drivers/core/device.c|   6 +
 drivers/spi/davinci_spi.c| 327 +--
 include/configs/ti_armv7_keystone2.h |   4 +
 include/dm/device.h  |   9 +
 14 files changed, 344 insertions(+), 93 deletions(-)

-- 
2.8.2

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

[U-Boot] [PATCH v3 05/12] ARM: dts: k2hk: Enable Davinci SPI controller

[Vignesh R]

Now that davinci_spi driver has been converted to DM framework, enable
the same in DT. Also add "spi-flash" as compatible property to
n25q128a11 node as it is required for flash device to be probed in
U-Boot.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 arch/arm/dts/k2hk-evm.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k2hk-evm.dts b/arch/arm/dts/k2hk-evm.dts
index 660ebf58d547..c5cad2c9da80 100644
--- a/arch/arm/dts/k2hk-evm.dts
+++ b/arch/arm/dts/k2hk-evm.dts
@@ -147,10 +147,11 @@
 };
 
  {
+   status = "okay";
nor_flash: n25q128a11@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "Micron,n25q128a11";
+   compatible = "Micron,n25q128a11", "spi-flash";
spi-max-frequency = <5400>;
m25p,fast-read;
reg = <0>;
-- 
2.8.2

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

[U-Boot] [PATCH v3 07/12] ARM: dts: k2e: Enable Davinci SPI controller

[Vignesh R]

Now that davinci_spi driver has been converted to DM framework, enable
the same in DT. Also add "spi-flash" as compatible property to
n25q128a11 node as it is required for flash device to be probed in
U-Boot.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 arch/arm/dts/k2e-evm.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k2e-evm.dts b/arch/arm/dts/k2e-evm.dts
index 50c83c21d911..e2c3fb49102a 100644
--- a/arch/arm/dts/k2e-evm.dts
+++ b/arch/arm/dts/k2e-evm.dts
@@ -119,10 +119,11 @@
 };
 
  {
+   status = "okay";
nor_flash: n25q128a11@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "Micron,n25q128a11";
+   compatible = "Micron,n25q128a11", "spi-flash";
spi-max-frequency = <5400>;
m25p,fast-read;
reg = <0>;
-- 
2.8.2

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

[U-Boot] [PATCH v3 10/12] defconfig: k2l_evm_defconfig: enable SPI driver model

[Vignesh R]

Enable SPI and SPI Flash driver model as K2L SPI controller driver
supports driver model.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 configs/k2l_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/k2l_evm_defconfig b/configs/k2l_evm_defconfig
index 844dd57163f5..1ba7d23e9c78 100644
--- a/configs/k2l_evm_defconfig
+++ b/configs/k2l_evm_defconfig
@@ -28,6 +28,8 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_TI_AEMIF=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_DM_ETH=y
-- 
2.8.2

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

[U-Boot] [PATCH v3 11/12] ARM: dts: k2g: add support for Davinci SPI controller

[Vignesh R]

K2G SoC has 4 SPI instances that are compatible with davinci_spi
controller(present on previous generation of Keystone2 devices). Add DT
nodes for the same. K2G EVM has a N25Q128A13 SPI NOR flash connected on
SPI-1. Add DT bindings for the same.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 arch/arm/dts/k2g-evm.dts | 24 
 arch/arm/dts/k2g.dtsi| 47 +++
 2 files changed, 71 insertions(+)

diff --git a/arch/arm/dts/k2g-evm.dts b/arch/arm/dts/k2g-evm.dts
index 0ca36ef39ad3..38ca7ae1b6b9 100644
--- a/arch/arm/dts/k2g-evm.dts
+++ b/arch/arm/dts/k2g-evm.dts
@@ -31,3 +31,27 @@
  {
phy-handle = <>;
 };
+
+ {
+   status = "okay";
+
+   spi_nor: flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <5000>;
+   m25p,fast-read;
+   reg = <0>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x8>;
+   read-only;
+   };
+
+   partition@1 {
+   label = "misc";
+   reg = <0x8 0xf8>;
+   };
+   };
+};
diff --git a/arch/arm/dts/k2g.dtsi b/arch/arm/dts/k2g.dtsi
index a3ed444d3c31..88b1a8e998ac 100644
--- a/arch/arm/dts/k2g.dtsi
+++ b/arch/arm/dts/k2g.dtsi
@@ -19,6 +19,10 @@
 
aliases {
serial0 = 
+   spi0 = 
+   spi1 = 
+   spi2 = 
+   spi3 = 
};
 
memory {
@@ -88,5 +92,48 @@
ti,lpsc_module = <1>;
};
 
+   spi0: spi@21805400 {
+   compatible = "ti,keystone-spi", "ti,dm6441-spi";
+   reg = <0x21805400 0x200>;
+   num-cs = <4>;
+   ti,davinci-spi-intr-line = <0>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   spi1: spi@21805800 {
+   compatible = "ti,keystone-spi", "ti,dm6441-spi";
+   reg = <0x21805800 0x200>;
+   num-cs = <4>;
+   ti,davinci-spi-intr-line = <0>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   spi2: spi@21805c00 {
+   compatible = "ti,keystone-spi", "ti,dm6441-spi";
+   reg = <0x21805C00 0x200>;
+   num-cs = <4>;
+   ti,davinci-spi-intr-line = <0>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   spi3: spi@21806000 {
+   compatible = "ti,keystone-spi", "ti,dm6441-spi";
+   reg = <0x21806000 0x200>;
+   num-cs = <4>;
+   ti,davinci-spi-intr-line = <0>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
};
 };
-- 
2.8.2

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

[U-Boot] [PATCH v3 09/12] ARM: dts: k2l: Enable Davinci SPI controller

[Vignesh R]

Now that davinci_spi driver has been converted to DM framework, enable
the same in DT. Also add "spi-flash" as compatible property to
n25q128a11 node as it is required for flash device to be probed in
U-Boot.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 arch/arm/dts/k2l-evm.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k2l-evm.dts b/arch/arm/dts/k2l-evm.dts
index 9a69a6b55374..da0661ba3e8a 100644
--- a/arch/arm/dts/k2l-evm.dts
+++ b/arch/arm/dts/k2l-evm.dts
@@ -96,10 +96,11 @@
 };
 
  {
+   status ="okay";
nor_flash: n25q128a11@0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "Micron,n25q128a11";
+   compatible = "Micron,n25q128a11", "spi-flash";
spi-max-frequency = <5400>;
m25p,fast-read;
reg = <0>;
-- 
2.8.2

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

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

[Vignesh R]

Enable SPI and SPI Flash driver model as K2G SPI controller driver
supports driver model.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 configs/k2g_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig
index d0b45ce3f8a5..33722ce9c421 100644
--- a/configs/k2g_evm_defconfig
+++ b/configs/k2g_evm_defconfig
@@ -27,6 +27,8 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_DM_ETH=y
-- 
2.8.2

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

Re: [U-Boot] Issue with USB mass storage (thumb drives)

[Diego]

In data martedì 3 maggio 2016 23:01:10, Marek Vasut ha scritto:
> On 04/29/2016 09:58 AM, Diego wrote:
> > In data venerdì 29 aprile 2016 00:49:22, Marek Vasut ha scritto:
> >> Urgh, so you seem to have third revision of this stick. I have two
> > 
> >> sticks which are exactly the same and work in U-Boot on MX6 wandboard:
> > Hi Marek,
> > 
> > how big is the file you're trying to load?
> >
> > For me it fails for files bigger than 16MB:
>
> Ha ok, I see it now. According to the bus analyzer, the stick Acks long
> block transfer, but then just times out, I guess because it prepares the
> data or something. Just a dummy question, did you try reducing
> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work.
> 

Hi Marek,

that was the original argument of my mail thread:
http://lists.denx.de/pipermail/u-boot/2016-April/251799.html
Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed 
out on TD".

I was questioning what was the best approach to fix the problem.
It seems that 65536 doesn't work for quite some USB thumb drives. Seeing my 
experience, my coworker's experience, and previous mails in this same thread, 
I'd guess something like 50% or lower work with 65535, while something like 
90% or more work with 32767.
http://lists.denx.de/pipermail/u-boot/2016-February/245893.html

So I see three options:
1) 65535 default with quirk table
2) 32767 default without quirk table
3) 32767 default with quirk table

Personally I think 3) would be the safest solution, but I think 2) would at 
least work for most thumb drives.
As the transfer speed wouldn't be affected much for 32767:
http://lists.denx.de/pipermail/u-boot/2016-February/246267.html
and as the quirk table for 65535 would grow quite a lot with time, I think.

Bests,
Diego

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

Re: [U-Boot] [PATCH 4/7] usb: Wait after sending Set Configuration request

[Stefan Roese]

On 04.05.2016 11:45, Chin Liang See wrote:

On Wed, 2016-05-04 at 09:41 +0200, Stefan Roese wrote:

On 03.05.2016 22:51, Marek Vasut wrote:

Some devices, like the SanDisk Cruzer Pop need some time to process
the Set Configuration request, so wait a little until they are
ready.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Hans de Goede 
Cc: Stefan Roese 
Cc: Stephen Warren 
---
   common/usb.c | 8 
   1 file changed, 8 insertions(+)

diff --git a/common/usb.c b/common/usb.c
index 63429d4..205041b 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1107,6 +1107,14 @@ int usb_select_config(struct usb_device
*dev)
"len %d, status %lX\n", dev->act_len, dev
->status);
return err;
}
+
+   /*
+* Wait until the Set Configuration request gets processed
by the
+* device. This is required by at least SanDisk Cruzer Pop
USB 2.0
+* and Kingston DT Ultimate 32GB USB 3.0 on DWC2 OTG
controller.
+*/
+   mdelay(10);
+
debug("new device strings: Mfr=%d, Product=%d,
SerialNumber=%d\n",
  dev->descriptor.iManufacturer, dev
->descriptor.iProduct,
  dev->descriptor.iSerialNumber);



As you might have expected, I'm not a fan of adding new delays to
the common USB code. As this negatively affects all platforms. Did
you test these two sticks that require this delay on other platforms
than SoCFPGA? I would be very interested to know, if these keys are
successfully detected without this patch on other platforms. I
don't have access to these USB keys, so I can't test it on my
platforms.



Actually this series of patches (include the delay) help for all my
problematic pen drives too. It sound to me these pen drives need time
to process.


This delay (I'm talking mainly about the 1000ms delay per USB hub
in patch 7/7) does not seem to be necessary on other platforms.

Chin, could you please test again without this patch 7/7 but
with "usb_pgood_delay" set to 1000? And let us know if this
also fixes all the problems with your problematic pen drives?
That would be very helpful.

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

Re: [U-Boot] [PATCH V2 2/2] mtd: cqspi: Simplify indirect read code

[Stefan Roese]

On 03.05.2016 19:25, Marek Vasut wrote:

The indirect read code is a pile of nastiness. This patch replaces
the whole unmaintainable indirect read implementation with the one
from upcoming Linux CQSPI driver, which went through multiple rounds
of thorough review and testing. All the patch does is it plucks out
duplicate ad-hoc code distributed across the driver and replaces it
with more compact code doing exactly the same thing. There is no
speed change of the read operation.

Signed-off-by: Marek Vasut 
Cc: Anatolij Gustschin 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Jagan Teki 
Cc: Pavel Machek 
Cc: Stefan Roese 
Cc: Vignesh R 
---
V2: Handle non-4-byte aligned transfers


Reviewed-by: Stefan Roese 
Tested-by: Stefan Roese 

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

Re: [U-Boot] [PATCH 4/7] usb: Wait after sending Set Configuration request

[Chin Liang See]

On Wed, 2016-05-04 at 09:41 +0200, Stefan Roese wrote:
> On 03.05.2016 22:51, Marek Vasut wrote:
> > Some devices, like the SanDisk Cruzer Pop need some time to process
> > the Set Configuration request, so wait a little until they are
> > ready.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Chin Liang See 
> > Cc: Dinh Nguyen 
> > Cc: Hans de Goede 
> > Cc: Stefan Roese 
> > Cc: Stephen Warren 
> > ---
> >   common/usb.c | 8 
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/common/usb.c b/common/usb.c
> > index 63429d4..205041b 100644
> > --- a/common/usb.c
> > +++ b/common/usb.c
> > @@ -1107,6 +1107,14 @@ int usb_select_config(struct usb_device
> > *dev)
> > "len %d, status %lX\n", dev->act_len, dev
> > ->status);
> > return err;
> > }
> > +
> > +   /*
> > +* Wait until the Set Configuration request gets processed
> > by the
> > +* device. This is required by at least SanDisk Cruzer Pop
> > USB 2.0
> > +* and Kingston DT Ultimate 32GB USB 3.0 on DWC2 OTG
> > controller.
> > +*/
> > +   mdelay(10);
> > +
> > debug("new device strings: Mfr=%d, Product=%d,
> > SerialNumber=%d\n",
> >   dev->descriptor.iManufacturer, dev
> > ->descriptor.iProduct,
> >   dev->descriptor.iSerialNumber);
> > 
> 
> As you might have expected, I'm not a fan of adding new delays to
> the common USB code. As this negatively affects all platforms. Did
> you test these two sticks that require this delay on other platforms
> than SoCFPGA? I would be very interested to know, if these keys are
> successfully detected without this patch on other platforms. I
> don't have access to these USB keys, so I can't test it on my
> platforms.
> 

Actually this series of patches (include the delay) help for all my
problematic pen drives too. It sound to me these pen drives need time
to process. But at same time, its strange to me that the device didn't
NAK (as I added printout for NAK) to indicate that its busy.

Seems that this issue is noticed at Freescale too. 
http://lists.denx.de/pipermail/u-boot/2015-December/238434.html. Cc'ed
them as they might can share more details on this.

Chin Liang



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

Re: [U-Boot] [PATCH 1/2] mtd: cqspi: Simplify indirect write code

[Stefan Roese]

On 03.05.2016 19:18, Marek Vasut wrote:

On 05/03/2016 07:00 PM, Stefan Roese wrote:

On 03.05.2016 18:53, Marek Vasut wrote:

On 05/02/2016 05:20 PM, Stefan Roese wrote:

On 29.04.2016 12:13, Marek Vasut wrote:

On 28.04.2016 00:36, Marek Vasut wrote:

The indirect write code is buggy pile of nastiness which fails
horribly
when the system runs fast enough to saturate the controller. The
failure
results in some pages (256B) not being written to the flash. This
can be
observed on systems which run with Dcache enabled and L2 cache
enabled,
like the Altera SoCFPGA.

This patch replaces the whole unmaintainable indirect write
implementation
with the one from upcoming Linux CQSPI driver, which went through
multiple
rounds of thorough review and testing. While this makes the patch
look
terrifying and violates all best-practices of software
development, all
the patch does is it plucks out duplicate ad-hoc code distributed
across
the driver and replaces it with more compact code doing exactly
the same
thing.

Signed-off-by: Marek Vasut 
Cc: Anatolij Gustschin 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Jagan Teki 
Cc: Pavel Machek 
Cc: Stefan Roese 
Cc: Vignesh R 


I've applied both patches and tested them on SR1500 (SPI-NOR used
for booting and redundant environment). This is what I get upon
"saveeenv":

=> saveenv
Saving Environment to SPI Flash...
SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB,
total 16 MiB
Erasing SPI flash...Writing to SPI flash...data abort
pc : [<3ff8368a>]  lr : [<3ff8301b>]
reloc pc : [<010216ca>]lr : [<0102105b>]
sp : 3bf54eb8  ip : 3ff82f69 fp : 0002
r10:   r9 : 3bf5dee8 r8 : 
r7 : 0001  r6 : 3bf54f9b r5 : 0001  r4 : 3bf5e520
r3 :   r2 : 3bf54f9b r1 : 0001  r0 : ffa0
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

U-Boot SPL 2016.05-rc3-9-ge1bf9b8 (Apr 29 2016 - 11:25:46)


Any idea, what might be going wrong here?


Does it work without the patch ?


Yes, of course. I wouldn't have posted as a reply to this patch
if this is not the root cause.


*grumble*


?


I just sensed slight USB subtext here ;-)


The board is using SPI NOR for env storage from the beginning.


It only happens if you use redundant env in SPI NOR.


   Where does your PC point to at the time

of the crash ,which function is it ?


Its in cadence_qspi_apb_indirect_write_execute().

I debugged this issue a bit and found the following problem
in cadence_qspi_apb_indirect_write_execute():

saveenv issues a 1-byte SPI write transfer with a non 4-byte
aligned txbuf. This causes the data-abort here. Here my small
patch that fixes the problem:


Thanks, see below.


diff --git a/drivers/spi/cadence_qspi_apb.c
b/drivers/spi/cadence_qspi_apb.c
index ac47c6f..021a3e8 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -745,7 +745,15 @@ int
cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
*plat,

  while (remaining > 0) {
  write_bytes = remaining > page_size ? page_size :
remaining;
-   writesl(plat->ahbbase, txbuf,
DIV_ROUND_UP(write_bytes, 4));
+
+   /*
+* Handle non 4-byte aligned access differently to avoid
+* data-aborts
+*/
+   if (((u32)txbuf % 4) || (write_bytes % 4))
+   writesb(plat->ahbbase, txbuf, write_bytes);
+   else
+   writesl(plat->ahbbase, txbuf, write_bytes >> 2);

  ret = wait_for_bit("QSPI", plat->regbase +
CQSPI_REG_SDRAMLEVEL,
 CQSPI_REG_SDRAMLEVEL_WR_MASK <<


Please fell free to use this patch as-is and squash it into
your patches or enhance it while doing this. The read function
is also missing this unaligned handling.


Im afraid of the performance hit that we can suffer if we use byte-level
access for every unaligned buffer.


This is why is wrote: "or enhance it while doing this". You might want
to change the code to first write the (optionally) unaligned bytes,
then the aligned bytes via writesl() and last the (optionally) unaligned
bytes.


What do you think
about using a bounce-buffer instead ?


I would prefer the simple solution I've drafted above.


OK, I checked how many aligned and unaligned transfers happens and I
guess it's really not worth going through the bounce buffer for 1 byte
which only happens once during saveenv.

I'll squash it and pick via socfpga tree, so we can get this in 2016.05
and have working QSPI NOR support there.


Good, thanks!


And of course the Linux driver version as well.


Does linux use unaligned buffers internally ?


Frankly, I don't know for sure. But I suspect, that you can also
see unaligned buffers (and sizes!!!) in Linux as 

Re: [U-Boot] [PATCH V2 1/2] mtd: cqspi: Simplify indirect write code

[Stefan Roese]

On 03.05.2016 19:25, Marek Vasut wrote:

The indirect write code is buggy pile of nastiness which fails horribly
when the system runs fast enough to saturate the controller. The failure
results in some pages (256B) not being written to the flash. This can be
observed on systems which run with Dcache enabled and L2 cache enabled,
like the Altera SoCFPGA.

This patch replaces the whole unmaintainable indirect write implementation
with the one from upcoming Linux CQSPI driver, which went through multiple
rounds of thorough review and testing. While this makes the patch look
terrifying and violates all best-practices of software development, all
the patch does is it plucks out duplicate ad-hoc code distributed across
the driver and replaces it with more compact code doing exactly the same
thing.

Signed-off-by: Marek Vasut 
Cc: Anatolij Gustschin 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Jagan Teki 
Cc: Pavel Machek 
Cc: Stefan Roese 
Cc: Vignesh R 
---
V2: Handle non-4-byte aligned transfers


Reviewed-by: Stefan Roese 
Tested-by: Stefan Roese 

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

Re: [U-Boot] [PATCH 7/7] usb: hub: Increase the query delay

[Marek Vasut]

On 05/04/2016 10:07 AM, Stefan Roese wrote:
> On 03.05.2016 22:51, Marek Vasut wrote:
>> Increase the query delay, otherwise some sticks are not detected.
>> The problem shows up on the USB bus analyzer such that the stick
>> takes longer time to switch from FS mode to HS mode than the code
>> allows.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Chin Liang See 
>> Cc: Dinh Nguyen 
>> Cc: Hans de Goede 
>> Cc: Stefan Roese 
>> Cc: Stephen Warren 
>> ---
>>   common/usb_hub.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/common/usb_hub.c b/common/usb_hub.c
>> index 0f39c9f..6cd274a 100644
>> --- a/common/usb_hub.c
>> +++ b/common/usb_hub.c
>> @@ -145,7 +145,7 @@ static void usb_hub_power_on(struct usb_hub_device
>> *hub)
>>* Do a minimum delay of the larger value of 100ms or pgood_delay
>>* so that the power can stablize before the devices are queried
>>*/
>> -hub->query_delay = get_timer(0) + max(100, (int)pgood_delay);
>> +hub->query_delay = get_timer(0) + max(1000, (int)pgood_delay);
>>
>>   /*
>>* Record the power-on timeout here. The max. delay (timeout)
>>
> 
> We have touched this part of the delay a number of times in my
> USB scanning patch series. I've integrated all very valuable
> suggestions from Stephen and Hans and I'm pretty sure that the
> current implementation is aligned with the USB spec.

Sadly, not everyone goes exactly be the USB spec it seems.
Especially the cheap sticks which are the majority in the market.

> And tested
> successfully one multiple platforms without regression.
> Stephen did some tests on Tegra and Hans on sunxi. I tested
> mainly on x86. But I now also tested on Armada XP (see
> below).

All of which use the same EHCI or XHCI controller, correct ?

> As mentioned before, the current version causes no problems with
> all my USB sticks on the congatec x86 board. Even the 2 ones that
> are problematic when connected to the SoCFPGA. They are detected
> without any issues on this board. Thats why I assume, that the
> real problem here is the DWC driver and not the generic USB
> handling code.

The logic here is flawed. If the code works against EHCI controller and
does not work against DWC2 controller, you cannot infer from this that
the DWC2 controller is the problem.

This can also be specific behavior of the EHCI controller, and I in fact
suspect it is, but you cannot decide this without checking the
bus itself.

> My feeling is that increasing this initial delay
> (before the scanning starts) just papers over the real problem
> most likely hidden somewhere in the DWC driver. This is just
> a feeling though which I can't prove somehow other than testing
> the common USB code on different platforms. And I really have
> no deeper knowledge of the DWC driver to manifest this feeling
> or even fix this potential problem there.

The bus analyzer tells me that the stick just takes longer to come out
of FS mode and switch to HS mode when the USB started from reset state
of the controller, I decide to trust what the analyzer shows me instead.

See attached logs.

> I've already mentioned this in another mail. My suggestion for
> SoCFPGA boards that need to use these problematic USB keys is
> to use the already available solution to set "usb_pgood_delay"
> to 1000. This effectively does the same as this patch. Without
> implying this general 1 second delay per hub (!!!) to all other
> platforms that use USB in U-Boot.
> 
> To test my suspicions about this being a DWC (SoCFPGA?) only
> problem, I've also tested all my current USB sticks including
> the 2 problematic ones (on SoCrates) on another ARM platform
> (additionally to all my test on x86). I've used the Marvell
> Armada XP development board (db-mv784mp-gp) for this. And all
> USB sticks are detected without any problems on this platform.

I see, it would be interesting to know what happens on the bus on the
marvell board compared to the socfpga board. For the socfpga, the bus
starts from complete cold state, could it be the marvell does have the
EHCI running when you do your tests ? That would explain why the stick
might be ready much faster on your platform.

> As a result of all this, I would like to have this patch not
> applied. As it negatively touches the common USB code to fix
> (paper over?) a problem only seen on one platform (AFAIK). And
> we already have the solution of this "usb_pgood_delay" that
> can be used on SoCFPGA. To manifest this, here again the
> numbers for the USB scanning time on x86, without and with
> this patch:
> 
> Without this patch:
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 9 USB Device(s) found
> 
> time: 1.940 seconds
> 
> With this patch:
> => time usb start
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 9 USB Device(s) found
> 
> time: 

[U-Boot] [PATCH v5 2/3] spl: Allow to load a FIT containing U-Boot from FS

[Lokesh Vutla]

This provides a way to load a FIT containing U-Boot and a selection of device
tree files from a File system. Making sure that all the reads and writes
are aligned to their respective needs.

Signed-off-by: Lokesh Vutla 
---
 common/spl/spl_fit.c | 76 +---
 include/spl.h| 10 +++
 2 files changed, 71 insertions(+), 15 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index b1cfa97..ace2543 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -82,6 +82,42 @@ static int spl_fit_select_fdt(const void *fdt, int images, 
int *fdt_offsetp)
return -ENOENT;
 }
 
+static int get_aligned_image_offset(struct spl_load_info *info, int offset)
+{
+   /*
+* If it is a FS read, get the first address before offset which is
+* aligned to ARCH_DMA_MINALIGN. If it is raw read return the
+* block number to which offset belongs.
+*/
+   if (info->priv)
+   return offset & ~(ARCH_DMA_MINALIGN - 1);
+
+   return offset / info->bl_len;
+}
+
+static int get_aligned_image_overhead(struct spl_load_info *info, int offset)
+{
+   /*
+* If it is a FS read, get the difference between the offset and
+* the first address before offset which is aligned to
+* ARCH_DMA_MINALIGN. If it is raw read return the offset within the
+* block.
+*/
+   if (info->priv)
+   return offset & (ARCH_DMA_MINALIGN - 1);
+
+   return offset % info->bl_len;
+}
+
+static int get_aligned_image_size(struct spl_load_info *info, int data_size,
+ int offset)
+{
+   if (info->priv)
+   return data_size + get_aligned_image_overhead(info, offset);
+
+   return (data_size + info->bl_len - 1) / info->bl_len;
+}
+
 int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
 {
int sectors;
@@ -91,7 +127,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
void *load_ptr;
int fdt_offset, fdt_len;
int data_offset, data_size;
-   int base_offset;
+   int base_offset, align_len;
int src_sector;
void *dst;
 
@@ -117,8 +153,10 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
 * In fact the FIT has its own load address, but we assume it cannot
 * be before CONFIG_SYS_TEXT_BASE.
 */
-   fit = (void *)(CONFIG_SYS_TEXT_BASE - size - info->bl_len);
-   sectors = (size + info->bl_len - 1) / info->bl_len;
+   align_len = ARCH_DMA_MINALIGN - 1;
+   fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len -
+   align_len) & ~align_len);
+   sectors = get_aligned_image_size(info, size, 0);
count = info->read(info, sector, sectors, fit);
debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",
  sector, sectors, fit, count);
@@ -151,19 +189,23 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
 * byte will be at 'load'. This may mean we need to load it starting
 * before then, since we can only read whole blocks.
 */
-   sectors = (data_size + info->bl_len - 1) / info->bl_len;
data_offset += base_offset;
+   sectors = get_aligned_image_size(info, data_size, data_offset);
load_ptr = (void *)load;
debug("U-Boot size %x, data %p\n", data_size, load_ptr);
-   dst = load_ptr - (data_offset % info->bl_len);
+   dst = load_ptr;
 
/* Read the image */
-   src_sector = sector + data_offset / info->bl_len;
-   debug("image: data_offset=%x, dst=%p, src_sector=%x, sectors=%x\n",
- data_offset, dst, src_sector, sectors);
+   src_sector = sector + get_aligned_image_offset(info, data_offset);
+   debug("Aligned image read: dst=%p, src_sector=%x, sectors=%x\n",
+ dst, src_sector, sectors);
count = info->read(info, src_sector, sectors, dst);
if (count != sectors)
return -EIO;
+   debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
+ data_size);
+   memcpy(dst, dst + get_aligned_image_overhead(info, data_offset),
+  data_size);
 
/* Figure out which device tree the board wants to use */
fdt_len = spl_fit_select_fdt(fit, images, _offset);
@@ -173,14 +215,15 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
/*
 * Read the device tree and place it after the image. There may be
 * some extra data before it since we can only read entire blocks.
+* And also align the destination address to ARCH_DMA_MINALIGN.
 */
-   dst = load_ptr + data_size;
+   dst = (void *)((load + data_size + align_len) & ~align_len);
fdt_offset += base_offset;
-   sectors = (fdt_len + info->bl_len - 1) 

[U-Boot] [PATCH v5 1/3] spl: fit: Fix the number of bytes read when reading fdt from fit

[Lokesh Vutla]

sectors field is not being updated when reading fdt from fit image. Because of
this size_of(u-boot.bin) is being read when reading fdt. Fixing it by updating
the sectors field properly.

Signed-off-by: Lokesh Vutla 
---
 common/spl/spl_fit.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 1a5c027..b1cfa97 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -176,6 +176,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
sector, void *fit)
 */
dst = load_ptr + data_size;
fdt_offset += base_offset;
+   sectors = (fdt_len + info->bl_len - 1) / info->bl_len;
count = info->read(info, sector + fdt_offset / info->bl_len, sectors,
   dst);
debug("fit read %x sectors to %x, dst %p, data_offset %x\n",
-- 
2.7.4

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

[U-Boot] [PATCH v5 0/3] spl: Add support to load FIT from Filesystem

[Lokesh Vutla]

Some devices like MMC, USB can be formatted to a FS and can act as a boot media.
Given that FIT image load support in SPL support only raw devices, SPL should
also be able to support loading FIT image from a File system.
This series add support to load FIT image from a filesystem and also adding
hooks to FAT FS.

Testing:
DRA74-evm:
MMC Boot: http://pastebin.ubuntu.com/16214433/
eMMC(RAW) Boot: http://pastebin.ubuntu.com/16214420/

AM57xx-evm:
MMC Boot: http://pastebin.ubuntu.com/16214374/

Changes since v4:
- Removed unnecessary else statements.
- Fixed number of bytes read when reading u-boot image from FIT.

Changes since v3:
- Use the same function for reading the fit from FS or raw device.

Lokesh Vutla (3):
  spl: fit: Fix the number of bytes read when reading fdt from fit
  spl: Allow to load a FIT containing U-Boot from FS
  spl: Support loading a FIT from FAT FS

 common/spl/spl_fat.c | 31 --
 common/spl/spl_fit.c | 75 ++--
 include/spl.h| 10 +++
 3 files changed, 100 insertions(+), 16 deletions(-)

-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 00/12] ARM: Keystone2: Convert davinci_spi to DM

[Vignesh R]

On 04/25/2016 04:29 PM, Vignesh R wrote:
> 
> 
> This series converts davinci_spi driver to adapt to driver model
> framework. And enables the driver on k2l, k2e, k2hk evms. Also,
> added support for davinci_spi on k2g evm.
> 
> Tested on k2l, k2e, k2hk and k2g evms.
> 

I have posted a v3 rebasing on top of 2016.05-rc3 and fixing a build issue.

> 
> v1: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/258285
> 
> Vignesh R (12):
>   dm: core: implement dev_map_phsymem()
>   spi: davinci_spi: Convert to driver to adapt to DM
>   keystone2: spi: do not define DM_SPI and DM_SPI_FLASH for SPL build
>   ARM: dts: keystone2: add SPI aliases for davinci SPI nodes
>   ARM: dts: k2hk: Enable Davinci SPI controller
>   defconfig: k2hk_evm_defconfig: enable SPI driver model
>   ARM: dts: k2e: Enable Davinci SPI controller
>   defconfig: k2e_evm_defconfig: enable SPI driver model
>   ARM: dts: k2l: Enable Davinci SPI controller
>   defconfig: k2l_evm_defconfig: enable SPI driver model
>   ARM: dts: k2g: add support for Davinci SPI controller
>   defconfig: k2g_evm_defconfig: enable SPI driver model
> 
>  arch/arm/dts/k2e-evm.dts |   3 +-
>  arch/arm/dts/k2g-evm.dts |  24 +++
>  arch/arm/dts/k2g.dtsi|  47 +
>  arch/arm/dts/k2hk-evm.dts|   3 +-
>  arch/arm/dts/k2l-evm.dts |   3 +-
>  arch/arm/dts/keystone.dtsi   |   3 +
>  configs/k2e_evm_defconfig|   2 +
>  configs/k2g_evm_defconfig|   2 +
>  configs/k2hk_evm_defconfig   |   2 +
>  configs/k2l_evm_defconfig|   2 +
>  drivers/core/device.c|   5 +
>  drivers/spi/davinci_spi.c| 327 
> +--
>  include/configs/ti_armv7_keystone2.h |   4 +
>  include/dm/device.h  |  10 ++
>  14 files changed, 344 insertions(+), 93 deletions(-)
> 

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

Re: [U-Boot] [PATCH 4/7] usb: Wait after sending Set Configuration request

[Marek Vasut]

On 05/04/2016 09:41 AM, Stefan Roese wrote:
> On 03.05.2016 22:51, Marek Vasut wrote:
>> Some devices, like the SanDisk Cruzer Pop need some time to process
>> the Set Configuration request, so wait a little until they are ready.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Chin Liang See 
>> Cc: Dinh Nguyen 
>> Cc: Hans de Goede 
>> Cc: Stefan Roese 
>> Cc: Stephen Warren 
>> ---
>>   common/usb.c | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/common/usb.c b/common/usb.c
>> index 63429d4..205041b 100644
>> --- a/common/usb.c
>> +++ b/common/usb.c
>> @@ -1107,6 +1107,14 @@ int usb_select_config(struct usb_device *dev)
>>   "len %d, status %lX\n", dev->act_len, dev->status);
>>   return err;
>>   }
>> +
>> +/*
>> + * Wait until the Set Configuration request gets processed by the
>> + * device. This is required by at least SanDisk Cruzer Pop USB 2.0
>> + * and Kingston DT Ultimate 32GB USB 3.0 on DWC2 OTG controller.
>> + */
>> +mdelay(10);
>> +
>>   debug("new device strings: Mfr=%d, Product=%d, SerialNumber=%d\n",
>> dev->descriptor.iManufacturer, dev->descriptor.iProduct,
>> dev->descriptor.iSerialNumber);
>>
> 
> As you might have expected, I'm not a fan of adding new delays to
> the common USB code. As this negatively affects all platforms. Did
> you test these two sticks that require this delay on other platforms
> than SoCFPGA?

Yes, on intel. Many microframes pass between these control EP requests,
while on the dwc2 in u-boot, quite a few of these requests end in the
same microframe because the code is fast, which is what the stick does
not like.

> I would be very interested to know, if these keys are
> successfully detected without this patch on other platforms. I
> don't have access to these USB keys, so I can't test it on my
> platforms.
> 
> Thanks,
> Stefan


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

[U-Boot] [PATCH] ARM64: zynqmp: Add debug uart for zc1751-dc1

[Michal Simek]

It is helpful for debugging.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index 9b40b1f6c740..77a508e74237 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -41,6 +41,11 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_DM_ETH=y
 CONFIG_ZYNQ_GEM=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_ZYNQ=y
+CONFIG_DEBUG_UART_BASE=0xff00
+CONFIG_DEBUG_UART_CLOCK=1
+CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_USB=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
-- 
1.9.1

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

[U-Boot] [PATCH v3 03/12] keystone2: spi: do not define DM_SPI and DM_SPI_FLASH for SPL build

[Vignesh R]

Since Keystone2 devices do not have support DM in SPL, do not define
DM_SPI and DM_SPI_FLASH for SPL build.

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

diff --git a/include/configs/ti_armv7_keystone2.h 
b/include/configs/ti_armv7_keystone2.h
index 2c9028c73558..985dd0625ab0 100644
--- a/include/configs/ti_armv7_keystone2.h
+++ b/include/configs/ti_armv7_keystone2.h
@@ -89,6 +89,10 @@
 #define CONFIG_SYS_SPI2
 #define CONFIG_SYS_SPI2_BASE   KS2_SPI2_BASE
 #define CONFIG_SYS_SPI2_NUM_CS 4
+#ifdef CONFIG_SPL_BUILD
+#undef CONFIG_DM_SPI
+#undef CONFIG_DM_SPI_FLASH
+#endif
 
 /* Network Configuration */
 #define CONFIG_PHYLIB
-- 
2.8.2

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

[U-Boot] [PATCH v3 04/12] ARM: dts: keystone2: add SPI aliases for davinci SPI nodes

[Vignesh R]

Add aliases for SPI nodes in order for it to be probed by the DM
framework.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 arch/arm/dts/keystone.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/dts/keystone.dtsi b/arch/arm/dts/keystone.dtsi
index f39b969f8d43..be97f3f21f92 100644
--- a/arch/arm/dts/keystone.dtsi
+++ b/arch/arm/dts/keystone.dtsi
@@ -19,6 +19,9 @@
 
aliases {
serial0 = 
+   spi0 = 
+   spi1 = 
+   spi2 = 
};
 
chosen {
-- 
2.8.2

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

[U-Boot] [PATCH v3 02/12] spi: davinci_spi: Convert to driver to adapt to DM

[Vignesh R]

Convert davinci_spi driver so that it complies with SPI DM framework.

Signed-off-by: Vignesh R 
---

v3: No changes

v2: Add comments to struct davinci_spi_slave members.
Use dev_map_physmem() added by previous patch.

 drivers/spi/davinci_spi.c | 327 +-
 1 file changed, 237 insertions(+), 90 deletions(-)

diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 0bd4f88926f1..75c8681d4e93 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* SPIGCR0 */
 #define SPIGCR0_SPIENA_MASK0x1
@@ -51,6 +52,7 @@
 /* SPIDEF */
 #define SPIDEF_CSDEF0_MASK BIT(0)
 
+#ifndef CONFIG_DM_SPI
 #define SPI0_BUS   0
 #define SPI0_BASE  CONFIG_SYS_SPI_BASE
 /*
@@ -83,6 +85,9 @@
 #define SPI2_NUM_CSCONFIG_SYS_SPI2_NUM_CS
 #define SPI2_BASE  CONFIG_SYS_SPI2_BASE
 #endif
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
 
 /* davinci spi register set */
 struct davinci_spi_regs {
@@ -114,16 +119,17 @@ struct davinci_spi_regs {
 
 /* davinci spi slave */
 struct davinci_spi_slave {
+#ifndef CONFIG_DM_SPI
struct spi_slave slave;
+#endif
struct davinci_spi_regs *regs;
-   unsigned int freq;
+   unsigned int freq; /* current SPI bus frequency */
+   unsigned int mode; /* current SPI mode used */
+   u8 num_cs; /* total no. of CS available */
+   u8 cur_cs; /* CS of current slave */
+   bool half_duplex;  /* true, if master is half-duplex only */
 };
 
-static inline struct davinci_spi_slave *to_davinci_spi(struct spi_slave *slave)
-{
-   return container_of(slave, struct davinci_spi_slave, slave);
-}
-
 /*
  * This functions needs to act like a macro to avoid pipeline reloads in the
  * loops below. Use always_inline. This gains us about 160KiB/s and the bloat
@@ -144,15 +150,14 @@ static inline u32 davinci_spi_xfer_data(struct 
davinci_spi_slave *ds, u32 data)
return buf_reg_val;
 }
 
-static int davinci_spi_read(struct spi_slave *slave, unsigned int len,
+static int davinci_spi_read(struct davinci_spi_slave *ds, unsigned int len,
u8 *rxp, unsigned long flags)
 {
-   struct davinci_spi_slave *ds = to_davinci_spi(slave);
unsigned int data1_reg_val;
 
/* enable CS hold, CS[n] and clear the data bits */
data1_reg_val = ((1 << SPIDAT1_CSHOLD_SHIFT) |
-(slave->cs << SPIDAT1_CSNR_SHIFT));
+(ds->cur_cs << SPIDAT1_CSNR_SHIFT));
 
/* wait till TXFULL is deasserted */
while (readl(>regs->buf) & SPIBUF_TXFULL_MASK)
@@ -175,15 +180,14 @@ static int davinci_spi_read(struct spi_slave *slave, 
unsigned int len,
return 0;
 }
 
-static int davinci_spi_write(struct spi_slave *slave, unsigned int len,
+static int davinci_spi_write(struct davinci_spi_slave *ds, unsigned int len,
 const u8 *txp, unsigned long flags)
 {
-   struct davinci_spi_slave *ds = to_davinci_spi(slave);
unsigned int data1_reg_val;
 
/* enable CS hold and clear the data bits */
data1_reg_val = ((1 << SPIDAT1_CSHOLD_SHIFT) |
-(slave->cs << SPIDAT1_CSNR_SHIFT));
+(ds->cur_cs << SPIDAT1_CSNR_SHIFT));
 
/* wait till TXFULL is deasserted */
while (readl(>regs->buf) & SPIBUF_TXFULL_MASK)
@@ -209,16 +213,15 @@ static int davinci_spi_write(struct spi_slave *slave, 
unsigned int len,
return 0;
 }
 
-#ifndef CONFIG_SPI_HALF_DUPLEX
-static int davinci_spi_read_write(struct spi_slave *slave, unsigned int len,
- u8 *rxp, const u8 *txp, unsigned long flags)
+static int davinci_spi_read_write(struct davinci_spi_slave *ds, unsigned
+ int len, u8 *rxp, const u8 *txp,
+ unsigned long flags)
 {
-   struct davinci_spi_slave *ds = to_davinci_spi(slave);
unsigned int data1_reg_val;
 
/* enable CS hold and clear the data bits */
data1_reg_val = ((1 << SPIDAT1_CSHOLD_SHIFT) |
-(slave->cs << SPIDAT1_CSNR_SHIFT));
+(ds->cur_cs << SPIDAT1_CSNR_SHIFT));
 
/* wait till TXFULL is deasserted */
while (readl(>regs->buf) & SPIBUF_TXFULL_MASK)
@@ -237,7 +240,115 @@ static int davinci_spi_read_write(struct spi_slave 
*slave, unsigned int len,
 
return 0;
 }
-#endif
+
+
+static int __davinci_spi_claim_bus(struct davinci_spi_slave *ds, int cs)
+{
+   unsigned int mode = 0, scalar;
+
+   /* Enable the SPI hardware */
+   writel(SPIGCR0_SPIRST_MASK, >regs->gcr0);
+   udelay(1000);
+   writel(SPIGCR0_SPIENA_MASK, >regs->gcr0);
+
+   /* Set master mode, powered up and not activated */
+   writel(SPIGCR1_MASTER_MASK | SPIGCR1_CLKMOD_MASK, >regs->gcr1);
+
+   /* CS, CLK, SIMO 

[U-Boot] [PATCH v3 06/12] defconfig: k2hk_evm_defconfig: enable SPI driver model

[Vignesh R]

Enable SPI and SPI Flash driver model as K2HK SPI controller driver
supports driver model.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 configs/k2hk_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/k2hk_evm_defconfig b/configs/k2hk_evm_defconfig
index 3975e804e534..21b8e1d2d383 100644
--- a/configs/k2hk_evm_defconfig
+++ b/configs/k2hk_evm_defconfig
@@ -28,6 +28,8 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_TI_AEMIF=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_DM_ETH=y
-- 
2.8.2

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

[U-Boot] [PATCH v3 08/12] defconfig: k2e_evm_defconfig: enable SPI driver model

[Vignesh R]

Enable SPI and SPI Flash driver model as K2E SPI controller driver
supports driver model.

Signed-off-by: Vignesh R 
Reviewed-by: Tom Rini 
---
 configs/k2e_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/k2e_evm_defconfig b/configs/k2e_evm_defconfig
index 044a9bf5b6e3..1e5003e8d23c 100644
--- a/configs/k2e_evm_defconfig
+++ b/configs/k2e_evm_defconfig
@@ -28,6 +28,8 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_TI_AEMIF=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_DM_ETH=y
-- 
2.8.2

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

[U-Boot] [PATCH] mmc: sdhci: Disable internal clock enable bit

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Disable internal clock by clearing the internal
clock enable bit. This bit needs to be cleared too
when we stop the SDCLK for changing the frequency
divisor. This bit should be set to zero when the
device is not using the Host controller.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/mmc/sdhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index ef7e6150f933..73f05b712f89 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -303,7 +303,7 @@ static int sdhci_set_clock(struct mmc *mmc, unsigned int 
clock)
}
 
reg = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
-   reg &= ~SDHCI_CLOCK_CARD_EN;
+   reg &= ~(SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN);
sdhci_writew(host, reg, SDHCI_CLOCK_CONTROL);
 
if (clock == 0)
-- 
1.9.1

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

Re: [U-Boot] [PATCH 3/7] usb: dwc2: Throttle the setup packet resending

[Chin Liang See]

On Tue, 2016-05-03 at 22:51 +0200, Marek Vasut wrote:
> Abort the request in case any of the tokens in the packet failed to
> complete transfer 10 times. This is a precaution needed so that we
> don't end in endless loop when scanning the bus with some braindead
> devices.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> Cc: Hans de Goede 
> Cc: Stefan Roese 
> Cc: Stephen Warren 
> ---
>  drivers/usb/host/dwc2.c | 44 ---
> -
>  1 file changed, 32 insertions(+), 12 deletions(-)
> 

Reviewed-by: Chin Liang See 
Tested-by: Chin Liang See 

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

Re: [U-Boot] [PATCH 0/4] ath79: fix some minor defects

[Marek Vasut]

On 05/04/2016 12:07 PM, Daniel Schwierzeck wrote:
> 
> 
> Am 03.05.2016 um 23:28 schrieb Marek Vasut:
>> On 04/15/2016 01:19 PM, Daniel Schwierzeck wrote:
>>>
>>>
>>> Am 12.04.2016 um 05:09 schrieb Wills Wang:

 These series of patch based on top of mips/next, it fix some defects on
 the previous patch series "add support for atheros ath79 based SOCs".


 Wills Wang (4):
   ath79: spi: Remove the explicit pinctrl setting
   ar933x: serial: Remove the explicit pinctrl setting
   ath79: ar933x: use BIT macro for bit shift operation
   ath79: add readonly attribute for ath79_soc_desc

  arch/mips/mach-ath79/ar933x/ddr.c | 14 +++---
  arch/mips/mach-ath79/cpu.c|  8 
  drivers/serial/serial_ar933x.c| 16 ++--
  drivers/spi/ath79_spi.c   | 12 
  4 files changed, 13 insertions(+), 37 deletions(-)

>>>
>>> all four patches applied to u-boot-mips/next, thanks!
>>>
>> Can you please update next on top of u-boot/master , so I can submit the
>> ar9344 ? Thanks!
> 
> ok, done
> 
Thank you!

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

Re: [U-Boot] Issue with USB mass storage (thumb drives)

[Marek Vasut]

On 05/04/2016 11:13 AM, Diego wrote:
> In data martedì 3 maggio 2016 23:01:10, Marek Vasut ha scritto:
>> On 04/29/2016 09:58 AM, Diego wrote:
>>> In data venerdì 29 aprile 2016 00:49:22, Marek Vasut ha scritto:
 Urgh, so you seem to have third revision of this stick. I have two
>>>
 sticks which are exactly the same and work in U-Boot on MX6 wandboard:
>>> Hi Marek,
>>>
>>> how big is the file you're trying to load?
>>>
>>> For me it fails for files bigger than 16MB:
>>
>> Ha ok, I see it now. According to the bus analyzer, the stick Acks long
>> block transfer, but then just times out, I guess because it prepares the
>> data or something. Just a dummy question, did you try reducing
>> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work.
>>
> 
> Hi Marek,
> 
> that was the original argument of my mail thread:
> http://lists.denx.de/pipermail/u-boot/2016-April/251799.html
> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI 
> timed 
> out on TD".
> 
> I was questioning what was the best approach to fix the problem.
> It seems that 65536 doesn't work for quite some USB thumb drives. Seeing my 
> experience, my coworker's experience, and previous mails in this same thread, 
> I'd guess something like 50% or lower work with 65535, while something like 
> 90% or more work with 32767.
> http://lists.denx.de/pipermail/u-boot/2016-February/245893.html
> 
> So I see three options:
> 1) 65535 default with quirk table
> 2) 32767 default without quirk table
> 3) 32767 default with quirk table
> 
> Personally I think 3) would be the safest solution, but I think 2) would at 
> least work for most thumb drives.

1) with the quirk table would be the way to go, modern(ish) drives
should work fine with 65535 .

> As the transfer speed wouldn't be affected much for 32767:
> http://lists.denx.de/pipermail/u-boot/2016-February/246267.html
> and as the quirk table for 65535 would grow quite a lot with time, I think.

Yeah, but with old drives only, which I think is soon gonna be moot.

> Bests,
> Diego
> 


-- 
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 5/7] usb: Assure Get Descriptor request is in separate microframe

[Marek Vasut]

On 05/04/2016 10:03 AM, Stefan Roese wrote:
> On 03.05.2016 22:51, Marek Vasut wrote:
>> The Kingston DT Ultimate USB 3.0 stick is sensitive to this first
>> Get Descriptor request and if the request is not in a separate
>> microframe, the stick refuses to operate. Add slight delay, which
>> is enough for one microframe to pass on any USB spec revision.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Chin Liang See 
>> Cc: Dinh Nguyen 
>> Cc: Hans de Goede 
>> Cc: Stefan Roese 
>> Cc: Stephen Warren 
>> ---
>>   common/usb.c | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/common/usb.c b/common/usb.c
>> index 205041b..8d9efe5 100644
>> --- a/common/usb.c
>> +++ b/common/usb.c
>> @@ -1077,6 +1077,14 @@ int usb_select_config(struct usb_device *dev)
>>   le16_to_cpus(>descriptor.idProduct);
>>   le16_to_cpus(>descriptor.bcdDevice);
>>
>> +/*
>> + * Kingston DT Ultimate 32GB USB 3.0 seems to be extremely sensitive
>> + * about this first Get Descriptor request. If there are any other
>> + * requests in the first microframe, the stick crashes. Wait about
>> + * one microframe duration here (1mS for USB 1.x , 125uS for USB
>> 2.0).
>> + */
>> +mdelay(1);
>> +
>>   /* only support for one config for now */
>>   err = usb_get_configuration_len(dev, 0);
>>   if (err >= 0) {
>>
> 
> Again my question, if this problem also occurs on other platforms
> with this USB key. A 1ms delay is not really a big deal, but its
> my general feeling that we should manifest such changes by testing
> on different platforms.

I tested it by connecting the bus analyzer between the stick and socfpga
and between the stick and x86 host. I wouldn't be able to
come up with this solution. btw. any ehci ends up inserting these
control requests into separate microframes, but we need the mdelay
to also cater for ohci/uhci, which has longer frames (1ms).

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

[U-Boot] [PATCH 1/7] armv8: fsl-layerscape: Put SMMU config code in SMMU_BASE

[Prabhakar Kushwaha]

It is not mandatory for Layerscape SoCs to have SMMU. SoCs like
LS1012A are layerscape SoC without SMMU IP.

So put SMMU configuration code under SMMU_BASE.

Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 04831ca..d743ffe 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -94,11 +94,13 @@ ENTRY(lowlevel_init)
bl  ccn504_set_qos
 #endif
 
+#ifdef SMMU_BASE
/* Set the SMMU page size in the sACR register */
ldr x1, =SMMU_BASE
ldr w0, [x1, #0x10]
orr w0, w0, #1 << 16  /* set sACR.pagesize to indicate 64K page */
str w0, [x1, #0x10]
+#endif
 
/* Initialize GIC Secure Bank Status */
 #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3)
-- 
1.9.1


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

[U-Boot] [PATCH 5/7] armv8: fsl-layerscape: Add support of QorIQ LS1012A SoC

[Prabhakar Kushwaha]

The QorIQ LS1012A processor, optimized for battery-backed or
USB-powered, integrates a single ARM Cortex-A53 core with a hardware
packet forwarding engine and high-speed interfaces to deliver
line-rate networking performance.

This patch add support of LS1012A SoC along with
 - Update platform & DDR clock read logic as per SVR
 - Define MMDC controller register set.
 - Update LUT base address for PCIe
 - Avoid L3 platform cache compilation
 - Update USB address, errata
 - SerDes table
 - Added CSU IDs for SDHC2, SAI-1 to SAI-4

Signed-off-by: Calvin Johnson 
Signed-off-by: Makarand Pawagi 
Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |  4 +
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 24 --
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |  2 +
 arch/arm/cpu/armv8/fsl-layerscape/ls1012a_serdes.c | 74 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 31 +++
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |  1 +
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |  1 +
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  4 +
 .../include/asm/arch-fsl-layerscape/ns_access.h| 10 +++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |  1 +
 include/fsl_mmdc.h | 94 ++
 include/linux/usb/xhci-fsl.h   |  6 +-
 12 files changed, 245 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1012a_serdes.c
 create mode 100644 include/fsl_mmdc.h

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 5f86ef9..eb2cbc3 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -28,3 +28,7 @@ endif
 ifneq ($(CONFIG_LS1043A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls1043a_serdes.o
 endif
+
+ifneq ($(CONFIG_LS1012A),)
+obj-$(CONFIG_SYS_HAS_SERDES) += ls1012a_serdes.o
+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 4fc3186..41c3688 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
@@ -33,6 +33,7 @@ void get_sys_info(struct sys_info *sys_info)
 #endif
struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_CLK_ADDR);
unsigned int cpu;
+   unsigned int svr, ver;
const u8 core_cplx_pll[8] = {
[0] = 0,/* CC1 PPL / 1 */
[1] = 0,/* CC1 PPL / 2 */
@@ -59,12 +60,20 @@ void get_sys_info(struct sys_info *sys_info)
sys_info->freq_ddrbus = sysclk;
 #endif
 
-   sys_info->freq_systembus *= (gur_in32(>rcwsr[0]) >>
-   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_SHIFT) &
-   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_MASK;
-   sys_info->freq_ddrbus *= (gur_in32(>rcwsr[0]) >>
-   FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_SHIFT) &
-   FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_MASK;
+   svr = gur_in32(>svr);
+   ver = SVR_SOC_VER(svr);
+   if (ver == SVR_LS1012) {
+   sys_info->freq_ddrbus *= (gur_in32(>rcwsr[0]) >>
+   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_SHIFT) &
+   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_MASK;
+   } else {
+   sys_info->freq_systembus *= (gur_in32(>rcwsr[0]) >>
+   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_SHIFT) &
+   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_MASK;
+   sys_info->freq_ddrbus *= (gur_in32(>rcwsr[0]) >>
+   FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_SHIFT) &
+   FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_MASK;
+   }
 
for (i = 0; i < CONFIG_SYS_FSL_NUM_CC_PLLS; i++) {
ratio[i] = (in_be32(>pllcgsr[i].pllcngsr) >> 1) & 0xff;
@@ -83,6 +92,9 @@ void get_sys_info(struct sys_info *sys_info)
freq_c_pll[cplx_pll] / core_cplx_pll_div[c_pll_sel];
}
 
+   if (ver == SVR_LS1012)
+   sys_info->freq_systembus = sys_info->freq_ddrbus / 2;
+
 #define HWA_CGA_M1_CLK_SEL 0xe000
 #define HWA_CGA_M1_CLK_SHIFT   29
 #ifdef CONFIG_SYS_DPAA_FMAN
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index d743ffe..5af6b73 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -183,6 +183,7 @@ ENTRY(lowlevel_init)
ret
 ENDPROC(lowlevel_init)
 
+#ifdef CONFIG_FSL_LSCH3
 hnf_pstate_poll:
/* x0 has the desired status, return 0 for success, 1 for timeout
 * clobber x1, x2, x3, x4, x6, x7
@@ -260,6 +261,7 @@ ENTRY(__asm_flush_l3_cache)
mov lr, x29
ret
 ENDPROC(__asm_flush_l3_cache)
+#endif
 
 

[U-Boot] [PATCH 6/7] armv8: ls1012a: Add support of ls1012aqds board

[Prabhakar Kushwaha]

QorIQ LS1012A Development System (LS1012AQDS) is a high-performance
development platform, with a complete debugging environment.
The LS1012AQDS board supports the QorIQ LS1012A processor and is
optimized to support the high-bandwidth DDR3L memory and
a full complement of high-speed SerDes ports.

Signed-off-by: Calvin Johnson 
Signed-off-by: Pratiyush Mohan Srivastava 
Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/Kconfig  |  10 ++
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/fsl-ls1012a-qds.dts  |  14 ++
 arch/arm/dts/fsl-ls1012a-qds.dtsi | 123 
 arch/arm/dts/fsl-ls1012a.dtsi | 119 +++
 board/freescale/ls1012aqds/Kconfig|  15 ++
 board/freescale/ls1012aqds/MAINTAINERS|   6 +
 board/freescale/ls1012aqds/Makefile   |   7 +
 board/freescale/ls1012aqds/README |  94 
 board/freescale/ls1012aqds/ls1012aqds.c   | 202 ++
 board/freescale/ls1012aqds/ls1012aqds_qixis.h |  35 +
 configs/ls1012aqds_qspi_defconfig |  32 
 include/configs/ls1012a_common.h  | 195 +
 include/configs/ls1012aqds.h  | 133 +
 14 files changed, 987 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dts
 create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1012a.dtsi
 create mode 100644 board/freescale/ls1012aqds/Kconfig
 create mode 100644 board/freescale/ls1012aqds/MAINTAINERS
 create mode 100644 board/freescale/ls1012aqds/Makefile
 create mode 100644 board/freescale/ls1012aqds/README
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds.c
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds_qixis.h
 create mode 100644 configs/ls1012aqds_qspi_defconfig
 create mode 100644 include/configs/ls1012a_common.h
 create mode 100644 include/configs/ls1012aqds.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..2540045 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -673,6 +673,15 @@ config TARGET_HIKEY
  Support for HiKey 96boards platform. It features a HI6220
  SoC, with 8xA53 CPU, mali450 gpu, and 1GB RAM.
 
+config TARGET_LS1012AQDS
+   bool "Support ls1012aqds"
+   select ARM64
+   help
+ Support for Freescale LS1012AQDS platform.
+ The LS1012A Development System (QDS) is a high-performance
+ development platform that supports the QorIQ LS1012A
+ Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
bool "Support ls1021aqds"
select CPU_V7
@@ -831,6 +840,7 @@ source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
 source "board/freescale/ls1043ardb/Kconfig"
+source "board/freescale/ls1012aqds/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx25pdk/Kconfig"
 source "board/freescale/mx28evk/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d1f8e22..b26870a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -113,7 +113,8 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2080a-rdb.dtb
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
-   fsl-ls1043a-rdb.dtb
+   fsl-ls1043a-rdb.dtb \
+   fsl-ls1012a-qds.dtb
 
 dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb
 
diff --git a/arch/arm/dts/fsl-ls1012a-qds.dts b/arch/arm/dts/fsl-ls1012a-qds.dts
new file mode 100644
index 000..ef6de34
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-qds.dts
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include "fsl-ls1012a-qds.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   };
+};
diff --git a/arch/arm/dts/fsl-ls1012a-qds.dtsi 
b/arch/arm/dts/fsl-ls1012a-qds.dtsi
new file mode 100644
index 000..a32a84a
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-qds.dtsi
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/include/ "fsl-ls1012a.dtsi"
+
+/ {
+   model = "LS1012A QDS Board";
+   aliases {
+   spi0 = 
+   spi1 = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   dflash0: n25q128a {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <100>; /* input clock */
+   };
+
+   dflash1: sst25wf040b {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency 

[U-Boot] [PATCH 4/7] armv8: fsl-layerscape: fix compile warning "rcw_tmp"

[Prabhakar Kushwaha]

arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c: In function
‘get_sys_info’:
arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c:29:6: warning:
unused variable ‘rcw_tmp’ [-Wunused-variable]
  u32 rcw_tmp;

Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

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 453a93d..4fc3186 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
@@ -25,7 +25,10 @@ void get_sys_info(struct sys_info *sys_info)
struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
u32 ccr;
 #endif
-#if defined(CONFIG_FSL_ESDHC) || defined(CONFIG_SYS_DPAA_FMAN)
+#if (defined(CONFIG_FSL_ESDHC) &&\
+   defined(CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK)) ||\
+   defined(CONFIG_SYS_DPAA_FMAN)
+
u32 rcw_tmp;
 #endif
struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_CLK_ADDR);
-- 
1.9.1


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

[U-Boot] [PATCH 0/7] armv8: fsl-layerscape: Add support of LS1012A SoC and platform

[Prabhakar Kushwaha]

The QorIQ LS1012A processor is a new Freescale' SoC optimized for 
battery-backed or USB-powered, integrates a single ARM Cortex-A53
core with a hardware packet forwarding engine and high-speed 
interfaces to deliver line-rate networking performance.

LS1012AQDS, LS1012ARDB are a high-performance development platform
using LS1012A SoC.

This patch-set add support of LS1012A SoC, platfrom along with modify
existing code to support LS1012A. 

This patch set is dependent upon following spi related patches
https://patchwork.ozlabs.org/patch/597365/
https://patchwork.ozlabs.org/patch/597366/
https://patchwork.ozlabs.org/patch/597367/
https://patchwork.ozlabs.org/patch/597368/
https://patchwork.ozlabs.org/patch/597369/

Prabhakar Kushwaha (7):
  armv8: fsl-layerscape: Put SMMU config code in SMMU_BASE
  armv8: fsl-layerscape: Avoid LS1043A specifc defines
  driver: mtd: spi: Adding support for QSPI flash
  armv8: fsl-layerscape: fix compile warning "rcw_tmp"
  armv8: fsl-layerscape: Add support of QorIQ LS1012A SoC
  armv8: ls1012a: Add support of ls1012aqds board
  armv8: ls1012a: Add support of ls1012ardb board

 arch/arm/Kconfig   |  20 ++
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c |  29 ++-
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |   4 +
 arch/arm/cpu/armv8/fsl-layerscape/ls1012a_serdes.c |  74 
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   2 +-
 arch/arm/dts/Makefile  |   4 +-
 arch/arm/dts/fsl-ls1012a-qds.dts   |  14 ++
 arch/arm/dts/fsl-ls1012a-qds.dtsi  | 123 
 arch/arm/dts/fsl-ls1012a-rdb.dts   |  16 ++
 arch/arm/dts/fsl-ls1012a-rdb.dtsi  |  39 
 arch/arm/dts/fsl-ls1012a.dtsi  | 119 
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  31 +++
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   1 +
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   3 +-
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |   4 +
 .../include/asm/arch-fsl-layerscape/ns_access.h|  10 +
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   1 +
 board/freescale/ls1012aqds/Kconfig |  15 ++
 board/freescale/ls1012aqds/MAINTAINERS |   6 +
 board/freescale/ls1012aqds/Makefile|   7 +
 board/freescale/ls1012aqds/README  |  94 +
 board/freescale/ls1012aqds/ls1012aqds.c| 202 
 board/freescale/ls1012aqds/ls1012aqds_qixis.h  |  35 
 board/freescale/ls1012ardb/Kconfig |  15 ++
 board/freescale/ls1012ardb/MAINTAINERS |   6 +
 board/freescale/ls1012ardb/Makefile|   7 +
 board/freescale/ls1012ardb/README  |  89 +
 board/freescale/ls1012ardb/ls1012ardb.c| 210 +
 configs/ls1012aqds_qspi_defconfig  |  32 
 configs/ls1012ardb_qspi_defconfig  |  32 
 drivers/mtd/spi/sf_params.c|   1 +
 drivers/mtd/spi/spi_flash.c|   5 +-
 include/configs/ls1012a_common.h   | 195 +++
 include/configs/ls1012aqds.h   | 133 +
 include/configs/ls1012ardb.h   |  59 ++
 include/fsl_mmdc.h |  94 +
 include/linux/usb/xhci-fsl.h   |   6 +-
 38 files changed, 1728 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1012a_serdes.c
 create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dts
 create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dts
 create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1012a.dtsi
 create mode 100644 board/freescale/ls1012aqds/Kconfig
 create mode 100644 board/freescale/ls1012aqds/MAINTAINERS
 create mode 100644 board/freescale/ls1012aqds/Makefile
 create mode 100644 board/freescale/ls1012aqds/README
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds.c
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds_qixis.h
 create mode 100644 board/freescale/ls1012ardb/Kconfig
 create mode 100644 board/freescale/ls1012ardb/MAINTAINERS
 create mode 100644 board/freescale/ls1012ardb/Makefile
 create mode 100644 board/freescale/ls1012ardb/README
 create mode 100644 board/freescale/ls1012ardb/ls1012ardb.c
 create mode 100644 configs/ls1012aqds_qspi_defconfig
 create mode 100644 configs/ls1012ardb_qspi_defconfig
 create mode 100644 include/configs/ls1012a_common.h
 create mode 100644 include/configs/ls1012aqds.h
 create mode 100644 include/configs/ls1012ardb.h
 create mode 100644 include/fsl_mmdc.h

-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH] imx6: cache: disable L2 before touching Auxiliary Control Register

[Stefano Babic]

Hi Peng,

On 04/05/2016 09:27, Peng Fan wrote:
> From: Peng Fan 
> 
> According PL310 TRM, Auxiliary Control Register
> "
> The register must be written to using a secure access, and it can be
> read using either a secure or a NS access. If you write to this register
> with a NS access, it results in a write response with a DECERR response,
> and the register is not updated. Writing to this register with the L2
> cache enabled, that is, bit[0] of L2 Control Register set to 1,
> results in a SLVERR.
> "
> 
> So If L2 cache is already enabled by ROM, chaning value of ACR
> will cause SLVERR and uboot hang.
> 
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> ---
>  arch/arm/imx-common/cache.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/imx-common/cache.c b/arch/arm/imx-common/cache.c
> index 54b021c..b775488 100644
> --- a/arch/arm/imx-common/cache.c
> +++ b/arch/arm/imx-common/cache.c
> @@ -43,6 +43,12 @@ void v7_outer_cache_enable(void)
>  
>  
>   /*
> +  * Must disable the L2 before changing the latency parameters
> +  * and auxiliary control register.
> +  */
> + clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
> +
> + /*
>* Set bit 22 in the auxiliary control register. If this bit
>* is cleared, PL310 treats Normal Shared Non-cacheable
>* accesses as Cacheable no-allocate.
> @@ -59,9 +65,6 @@ void v7_outer_cache_enable(void)
>   }
>  #endif
>  
> - /* Must disable the L2 before changing the latency parameters */
> - clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
> -
>   writel(0x132, >pl310_tag_latency_ctrl);
>   writel(0x132, >pl310_data_latency_ctrl);
>  
> 

It should be fine to have in release, I think.

Acked-by : Stefano Babic 

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] Issue with USB mass storage (thumb drives)

[Diego]

In data mercoledì 4 maggio 2016 13:45:57, Marek Vasut ha scritto:
> On 05/04/2016 11:13 AM, Diego wrote:
> > In data martedì 3 maggio 2016 23:01:10, Marek Vasut ha scritto:
> >> On 04/29/2016 09:58 AM, Diego wrote:
> >>> For me it fails for files bigger than 16MB:
> >> Ha ok, I see it now. According to the bus analyzer, the stick Acks long
> >> block transfer, but then just times out, I guess because it prepares the
> >> data or something. Just a dummy question, did you try reducing
> >> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work.
> > 
> > Hi Marek,
> > 
> > that was the original argument of my mail thread:
> > http://lists.denx.de/pipermail/u-boot/2016-April/251799.html
> > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI
> > timed out on TD".
> > 
> > I was questioning what was the best approach to fix the problem.
> > It seems that 65536 doesn't work for quite some USB thumb drives. Seeing
> > my
> > experience, my coworker's experience, and previous mails in this same
> > thread, I'd guess something like 50% or lower work with 65535, while
> > something like 90% or more work with 32767.
> > http://lists.denx.de/pipermail/u-boot/2016-February/245893.html
> > 
> > So I see three options:
> > 1) 65535 default with quirk table
> > 2) 32767 default without quirk table
> > 3) 32767 default with quirk table
> > 
> > Personally I think 3) would be the safest solution, but I think 2) would
> > at
> > least work for most thumb drives.
> 
> 1) with the quirk table would be the way to go, modern(ish) drives
> should work fine with 65535 .
> 

I personally can't see any improvement with more recent thumb drives, quite 
the opposite.
WORKING WITH 65535:
- ancient Sandisk 256MB
ID 0781:5151 SanDisk Corp. Cruzer Micro Flash Drive
- old Sony 8GB
ID 054c:0243 Sony Corp. MicroVault Flash Drive
- recent Kingston DT101 G2 16GB
ID 0951:1642 Kingston Technology DT101 G2

NOT WORKING WITH 65535:
- recent Kingston G3 16GB
ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB
- new Kingston USB 2.0 8GB
ID 0951:1689 Kingston Technology DataTraveler SE9
- brand new Kingston G2 16GB / 32GB USB 3.0
ID 0951:1666 Kingston Technology DataTraveler G4

Why are you saying modern(ish) drives should work?

For others following the thread, please post your experience, especially with 
more recent drives (remember to test with files >16MB).

Diego

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

[U-Boot] [RFC PATCH] spl: Setup default value for OF_LIST

[Michal Simek]

OF_LIST can't remain empty that's why setup it up to default DTB.

If it is empty u-boot.img is created without FDT partition:
For example:
  ./tools/mkimage -f auto -A arm -T firmware -C none -O u-boot -a
0x800 -e 0 -n "U-Boot 2016.05-rc3 ..." -E -b  -d u-boot-nodtb.bin u-boot.img
Can't set 'timestamp' property for '' node (FDT_ERR_NOSPACE)
FIT description: Firmware image with one or more FDT blobs
Created: Wed May  4 15:02:52 2016
 Image 0 (firmware@1)
  Description:  U-Boot 2016.05-rc3-00080-gff2e12ae22a8-dirty for zynqmp
board
  Created:  Wed May  4 15:02:52 2016
  Type: Firmware
  Compression:  uncompressed
  Data Size:unavailable
  Architecture: ARM
  Load Address: 0x0800
 Default Configuration: 'conf@1'
 Configuration 0 (conf@1)
  Description:  unavailable
  Kernel:   unavailable

And then image like this doesn't contain description and link to FDT and
can't boot.

Signed-off-by: Michal Simek 
---

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

diff --git a/dts/Kconfig b/dts/Kconfig
index d5850093539d..c56c1299c09f 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -62,6 +62,7 @@ config DEFAULT_DEVICE_TREE
 config OF_LIST
string "List of device tree files to include for DT control"
depends on SPL_LOAD_FIT
+   default DEFAULT_DEVICE_TREE
help
  This option specifies a list of device tree files to use for DT
  control. These will be packaged into a FIT. At run-time, SPL will
-- 
1.9.1

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

[U-Boot] [PATCH] mmc: Fix error in RPMB code

[Marek Vasut]

Since we do not build any board with CONFIG_SUPPORT_EMMC_RPMB , this
piece of code evaded conversion. Fix the following compiler error:

cmd/mmc.c: In function 'do_mmcrpmb':
cmd/mmc.c:316:32: error: 'struct blk_desc' has no member named 'part_num'
  original_part = mmc->block_dev.part_num;
^

Signed-off-by: Marek Vasut 
Cc: Pantelis Antoniou 
Cc: Tom Rini 
---
 cmd/mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index 39ef072..c5454bf 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -313,7 +313,7 @@ static int do_mmcrpmb(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_FAILURE;
}
/* Switch to the RPMB partition */
-   original_part = mmc->block_dev.part_num;
+   original_part = mmc->block_dev.hwpart;
if (mmc_select_hwpart(curr_device, MMC_PART_RPMB) != 0)
return CMD_RET_FAILURE;
ret = cp->cmd(cmdtp, flag, argc, argv);
-- 
2.7.0

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

[U-Boot] [PATCH] spl: fit: Print error message when FDT is not present

[Michal Simek]

When FDT is not present in the image user doesn't get any error what's
wrong. Print error message if LIBCOMMON_SUPPORT is enabled.

Signed-off-by: Michal Simek 
Seris-cc: uboot
---

 common/spl/spl_fit.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ace254348ad9..c11c03ff2f86 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -39,8 +39,13 @@ static int spl_fit_select_fdt(const void *fdt, int images, 
int *fdt_offsetp)
 node >= 0;
 node = fdt_next_subnode(fdt, node)) {
name = fdt_getprop(fdt, node, "description", );
-   if (!name)
+   if (!name) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+   printf("%s: Missing FDT description in DTB\n",
+  __func__);
+#endif
return -EINVAL;
+   }
if (board_fit_config_name_match(name))
continue;
 
-- 
1.9.1

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

[U-Boot] [PATCH 3/7] driver: mtd: spi: Adding support for QSPI flash

[Prabhakar Kushwaha]

Serial number, vendor id and page size are added for QSPI flash
common on both LS1012AQDS and LS1012ARDB i.e. S25FS512SDSMFI011.

Signed-off-by: Pratiyush Mohan Srivastava 
Signed-off-by: Calvin Johnson 
Signed-off-by: Mingkai Hu 
Signed-off-by: Prabhakar Kushwaha 
---
 drivers/mtd/spi/sf_params.c | 1 +
 drivers/mtd/spi/spi_flash.c | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 4f37e33..c577d9e 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -67,6 +67,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"S25FL128S_64K",  0x012018, 0x4d01,64 * 1024,   256, RD_FULL,  
 WR_QPP},
{"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,  
 WR_QPP},
{"S25FL256S_64K",  0x010219, 0x4d01,64 * 1024,   512, RD_FULL,  
 WR_QPP},
+   {"S25FS512S",  0x010220, 0x4D00,   128 * 1024,   512, RD_FULL,  
 WR_QPP},
{"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,  
 WR_QPP},
{"S25FL512S_64K",  0x010220, 0x4d01,64 * 1024,  1024, RD_FULL,  
 WR_QPP},
{"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,  
 WR_QPP},
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index fa0e799..64d4e0f 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1072,7 +1072,8 @@ int spi_flash_scan(struct spi_flash *flash)
 * sector that is not overlaid by the parameter sectors.
 * The uniform sector erase command has no effect on parameter sectors.
 */
-   if (jedec == 0x0219 && (ext_jedec & 0xff00) == 0x4d00) {
+   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
+   (ext_jedec & 0xff00) == 0x4d00) {
int ret;
u8 id[6];
 
@@ -1146,7 +1147,7 @@ int spi_flash_scan(struct spi_flash *flash)
 * have 256b pages.
 */
if (ext_jedec == 0x4d00) {
-   if ((jedec == 0x0215) || (jedec == 0x216))
+   if ((jedec == 0x0215) || (jedec == 0x216) || (jedec == 0x220))
flash->page_size = 256;
else
flash->page_size = 512;
-- 
1.9.1


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

Re: [U-Boot] [PATCH] tools: env: fix config file loading in env library

[Stefano Babic]

On 29/04/2016 22:00, Anatolij Gustschin wrote:
> env library is broken as the config file pointer is only initialized
> in main(). When running in the env library parse_config() fails:
> 
>   Cannot parse config file '(null)': Bad address
> 
> Ensure that config file pointer is always initialized.
> 
> Signed-off-by: Anatolij Gustschin 
> Cc: Stefano Babic 
> ---
>  tools/env/fw_env.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
> index 1420ac5..06cf63d 100644
> --- a/tools/env/fw_env.c
> +++ b/tools/env/fw_env.c
> @@ -1325,6 +1325,9 @@ static int parse_config ()
>   struct stat st;
>  
>  #if defined(CONFIG_FILE)
> + if (!common_args.config_file)
> + common_args.config_file = CONFIG_FILE;
> +
>   /* Fills in DEVNAME(), ENVSIZE(), DEVESIZE(). Or don't. */
>   if (get_config(common_args.config_file)) {
>   fprintf(stderr, "Cannot parse config file '%s': %m\n",
> 

Reviewed-by : Stefano Babic 

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 07/18] net: macb: Convert to driver model

[Simon Glass]

Hi,

On 4 May 2016 at 01:32, Yang, Wenyou  wrote:
>
> Hi
>
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heiko
> > Schocher
> > Sent: 2016年5月3日 15:54
> > To: Simon Glass 
> > Cc: U-Boot Mailing List ; Joe Hershberger
> > 
> > Subject: Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver model
> >
> > Hello Simon,
> >
> > Am 03.05.2016 um 08:40 schrieb Simon Glass:
> > > Add driver-model support to this driver. The old code remains for now
> > > so that we can convert boards one at a time.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > >   drivers/net/macb.c | 119
> > +
> > >   1 file changed, 119 insertions(+)
> >
> > Thanks!
> >
> > Reviewed-by: Heiko Schocher 
> >
> > tested on the smartweb, corvus, taurus and axm board
> >
> > Tested-by: Heiko Schocher 
>
> I tried to test this patch series on SAMA5D2 Xplained board, but I have the 
> compile warning below. Did you experience it?
>
> ---8<-
> drivers/net/macb.c: In function 'macb_phy_init':
> drivers/net/macb.c:487:9: warning: passing argument 3 of 'phy_connect' from 
> incompatible pointer type [enabled by default]
> In file included from include/miiphy.h:22:0,
>  from drivers/net/macb.c:36:
> include/phy.h:226:20: note: expected 'struct udevice *' but argument is of 
> type 'const struct device **'
> --->8

No I don't see that problem. I did a full build test. What is the
board config name you are using?
>
> Thanks.
>
> >
> > bye,
> > Heiko
> > --
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>
>
> Best Regards,
> Wenyou Yang

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

Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver model

[Simon Glass]

Hi Joe,

On 3 May 2016 at 14:54, Joe Hershberger  wrote:
> On Tue, May 3, 2016 at 1:40 AM, Simon Glass  wrote:
>> Add driver-model support to this driver. The old code remains for now so
>> that we can convert boards one at a time.
>>
>> Signed-off-by: Simon Glass 
>
> Acked-by: Joe Hershberger 
>
> But with a nit...
>
>> ---
>
> 
>
>> +static const struct eth_ops macb_eth_ops = {
>> +   .start  = macb_start,
>> +   .send   = macb_send,
>> +   .recv   = macb_recv,
>> +   .stop   = macb_stop,
>> +   .free_pkt   = macb_free_pkt,
>> +   .write_hwaddr   = macb_write_hwaddr,
>> +};
>> +
>> +static int macb_eth_probe(struct udevice *dev)
>> +{
>> +   struct eth_pdata *pdata = dev_get_platdata(dev);
>> +   struct macb_device *macb = dev_get_priv(dev);
>> +
>> +   macb->regs = (void *)pdata->iobase;
>> +
>> +   _macb_eth_initialize(macb);
>> +#if defined(CONFIG_CMD_MII) || defined(CONFIG_PHYLIB)
>> +   miiphy_register(dev->name, macb_miiphy_read, macb_miiphy_write);
>
> It's unfortunate that you're proliferating the oldest phy API. My
> semantic patch can come along and clean it up later as long as this is
> in before I run it again.

OK, hopefully that will work.

>
>> +   macb->bus = miiphy_get_dev_by_name(dev->name);
>> +#endif
>> +
>> +   return 0;
>> +}

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

[U-Boot] OMAP 3530 - BeagleBoard Rev. C4

[Derald D. Woods]

Hi Tom,

Is anyone still attempting to boot the OMAP 3530 BeagleBoard with U-Boot 
master?


In order to boot my BeagleBoard Rev. C4, I need to basically undefine 
CONFIG_SPL_EXT_SUPPORT and CONFIG_SYS_THUMB_BUILD.


There is some background in this old thread from last year:
- http://lists.denx.de/pipermail/u-boot/2015-July/220332.html

The thread ended without an apparent solution.

What does work is this patch from EEWiki:
- 
https://github.com/eewiki/u-boot-patches/blob/master/v2016.03/0001-omap3_beagle-uEnv.txt-bootz-n-fixes.patch


If there is some additional useful information, I would be happy to take 
a look.


I use the board for testing generic code intended for other OMAP3 systems.


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

Re: [U-Boot] [PATCH v2] fdt: fix setting MAC addresses for multiple interfaces

[Lev Iserovich]

Hi Joe,

Thanks for fixing that up, I'll try to stick to patman in the future.

--Lev

On 05/03/2016 03:52 PM, Joe Hershberger wrote:

Hi Lev,

I had already applied your previous patch with a few minor
adjustments. Please look at what's in my tree and send a patch on top
of that if you care to make further improvements.

Also, you might want to consider using tools/patman/patman when
working on patches and sending to the list.

Thanks,
-Joe

http://git.denx.de/?p=u-boot/u-boot-net.git;a=commitdiff;h=f383f32d5568a3a1a4d31efa97f5cf991961a5e8


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

[U-Boot] how to feed kernel, initrd and rootfs into uboot

[JPT]

Hi,

I am having difficulties installing openwrt on an old router box.

The guide stops after u-boot is up and running.
https://wiki.openwrt.org/toh/arcadyan/arv752dpw#brnboot

I know how to load kernel image etc into RAM, but it does not boot the
kernel. What am I doing wrong?

I already posted in openwrt forums, but it seems nobody is going to
help. :( https://forum.openwrt.org/viewtopic.php?id=64615

U-Boot 2013.10-openwrt4 (May 03 2016 - 16:56:57) ARV752DPW

Board: Arcadyan ARV752DPW
SoC:   Lantiq Danube-S v1.5
CPU:   333.333 MHz
IO:166.667 MHz
BUS:   83.333 MHz
BOOT:  NOR
DRAM:  64 MiB
Flash: 8 MiB
Using default environment

In:serial
Out:   serial
Err:   serial
Net:   Board Net Initialization Failed
ltq-eth
Hit any key to stop autoboot:  0

ARV752DPW # printenv
...
addconsole=setenv bootargs $bootargs console=$consoledev,$baudrate
...
baudrate=115200
bootcmd=bootm ${kernel_addr}
consoledev=ttyLTQ1
kernel_addr=0xB004
loadaddr=0x8100
stderr=serial
stdin=serial
stdout=serial

bootargs is not defined :(

now I use "loadx" to load the kernel into ram.
after that I "bootm". Nothing happens. Then I tried
  setenv bootargs console=ttyLTQ1,115200
Did not change anything.

Why does it load to 0x8100 ? The device has got 64MB RAM, which is
0x0400 

~/src/openwrt/bin/lantiq$
4,3M openwrt-lantiq-xway-ARV752DPW-squashfs.image
1,4M openwrt-lantiq-xway-ARV752DPW-uImage
4,0M openwrt-lantiq-xway-ARV752DPW-uImage-initramfs
178K uboot-lantiq-arv752dpw_brn/openwrt-lantiq-arv752dpw_brn-u-boot.img
packages/

which file should I load to what address?
then bootm  
but what to do with the squashfs?
what bootargs do I need?


Please CC to my email, I did not subscribe to the list.


thank you very much

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

Re: [U-Boot] [PATCH 0/6] arm64: Pine64 fixes and updates

[Chen-Yu Tsai]

On Thu, May 5, 2016 at 6:36 AM, André Przywara  wrote:
> On 04/05/16 23:15, Peter Robinson wrote:
>> On Wed, May 4, 2016 at 11:05 PM, André Przywara  
>> wrote:
>>> On 04/05/16 22:53, Peter Robinson wrote:
 On Wed, May 4, 2016 at 10:15 PM, Andre Przywara  
 wrote:
> This series improves the Pine64 support.
> The first patch fixes a build break, see details in the commit message.
> Patch 2/6 reverts a no longer needed memory reservation, as the firmware
> bits that used to live in DRAM now can reside in SRAM.
> To allow U-Boot to be easily loaded by Allwinner's boot0 loader, patch
> 3/6 reserves some space at the beginning of the image to (optionally)
> fit in a header required by boot0.
> Patch 4/6 adjusts the default load addresses in the environment to
> meet the arm64 requirements (especially the kernel load address).
> The device tree files included in the original Pine64 commit are
> outdated, so patch 5/6 replaces some with more mature versions and also
> adjusts the naming to match other sunxi boards.
> The final patch renames the _defconfig file to get rid of the _plus_
> insert.
>
> Please review, comment and apply, if possible.

 I'll test this tomorrow on my 1Gb Plus board,
>>>
>>> Thanks!
>>>
 it would be good to have
 a README.pine64 with details about where to get the ATF firmware from
 and how to use it with this u-boot to get a booted device something
 similar to README.odroid
>>>
>>> Yes, I am on the documentation.
>>
>> Cool, btw what's the redistribution license on the ATF firmware, is it
>> redistributable by distributions (like other firmware),
>
> ATF is the "ARM Trusted Firmware", which is a proper OpenSource project
> under a BSD license. The home is on github [1].
> In the moment I am working with an Allwinner provided codebase and
> having fixes on top, but I removed quite some useless code already and
> started with a proper upstream port.
> I will push the repository onto my github fork [2] (once I manage to get
> off mail and IRC ;-)
>
>> is it usable on all devices with a AllWinner A64?
>
> I would think so. A good part of the code in there is about the cores
> and the GIC: so pretty generic. In the moment all power management is on
> a SoC level - but in the future we might drive the PMIC from ATF as
> well, which would potentially differ between boards.

Unlikely, unless the board vendor has awesome hardware design skills.
The SoC and PMIC are sold as a packaged set. One does not go without
the other.

If you look at the PMIC datasheets, you'll see the application design
example and default settings match perfectly with the SoC.

ChenYu

>
>> Will it be needed with the proper SPL you mention below?
>
> Yes, the most prominent feature that ATF provides on the Pine64 is the
> PSCI service. ATF is actually the PSCI reference implementation, so it
> does the right thing and is more advanced than what U-Boot provides, for
> instance.
> Also ATF cares about some errata fixups for various cores, some of them
> can only be provided by firmware (in EL3).
>
> So I think ATF should take over the actual firmware load that U-Boot
> carried in the past for various boards as well.
> For the Pine64 I would very much like U-Boot to be just a boot loader.
>
>>> As we lack DRAM initialization at the moment, I use a tool to assemble
>>> all the firmware bits together with boot0 into an image.
>>> This should supersede Alex' pine64_image tool.
>>
>> OK, I've been using Alex's tool to date.
>>
>>> Shall this tool (written in C) also be part of U-Boot, say in the tools
>>> directory? Or is this better pushed into the sunxi-tools repository?
>>> Eventually with a proper SPL we will not need it anymore, so I refrained
>>> from pushing it into U-Boot for now.
>>
>> TBH I've no idea what's best here, I suppose it depends on timeframes,
>> it might just be useful to put it in a git repo somewhere and
>> reference it in a readme, once there's patches that have the proper
>> SPL update the readme as part of it.
>
> Yes, expect it to appear on [3] anytime soon.
>
> Cheers,
> Andre.
>
> [1] https://github.com/ARM-software/arm-trusted-firmware
> [2] https://github.com/apritzel/arm-trusted-firmware
> [3] https://github.com/apritzel/pine64
>

> P.S. tools/buildman/README was TL;DR, so I just tested Pine64 and
> Bananapi compilation. If someone with a working buildman setup could
> test this for build regressions, I'd be grateful.
>
> Andre Przywara (6):
>   arm/arm64: Move barrier instructions into separate header
>   Revert "sunxi: Reserve ATF memory space on A64"
>   arm64: sunxi: reserve space for boot0 header
>   arm64: sunxi: adjust default load addresses
>   arm64: Pine64: update FDT files
>   Pine64: rename defconfig
>
>  arch/arm/cpu/armv8/start.S |   3 +
>  

Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver model

[Yang, Wenyou]

Hi Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2016年5月5日 10:38
> To: Yang, Wenyou 
> Cc: h...@denx.de; U-Boot Mailing List ; Joe Hershberger
> 
> Subject: Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver model
> 
> Hi,
> 
> On 4 May 2016 at 01:32, Yang, Wenyou  wrote:
> >
> > Hi
> >
> > > -Original Message-
> > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
> > > Heiko Schocher
> > > Sent: 2016年5月3日 15:54
> > > To: Simon Glass 
> > > Cc: U-Boot Mailing List ; Joe Hershberger
> > > 
> > > Subject: Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver
> > > model
> > >
> > > Hello Simon,
> > >
> > > Am 03.05.2016 um 08:40 schrieb Simon Glass:
> > > > Add driver-model support to this driver. The old code remains for
> > > > now so that we can convert boards one at a time.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > >   drivers/net/macb.c | 119
> > > +
> > > >   1 file changed, 119 insertions(+)
> > >
> > > Thanks!
> > >
> > > Reviewed-by: Heiko Schocher 
> > >
> > > tested on the smartweb, corvus, taurus and axm board
> > >
> > > Tested-by: Heiko Schocher 
> >
> > I tried to test this patch series on SAMA5D2 Xplained board, but I have the
> compile warning below. Did you experience it?
> >
> > ---8<-
> > drivers/net/macb.c: In function 'macb_phy_init':
> > drivers/net/macb.c:487:9: warning: passing argument 3 of 'phy_connect'
> > from incompatible pointer type [enabled by default] In file included from
> include/miiphy.h:22:0,
> >  from drivers/net/macb.c:36:
> > include/phy.h:226:20: note: expected 'struct udevice *' but argument is of 
> > type
> 'const struct device **'
> > --->8
> 
> No I don't see that problem. I did a full build test. What is the board 
> config name
> you are using?

The board is SAMA5D2 Xplained board, the .config file is attached.

I noticed that in include/phy.h file,  phy_connect() has different prototype 
for enabling CONFIG_DM_ETH or not.

So, I think this issue should be exist.

> >
> > Thanks.
> >
> > >
> > > bye,
> > > Heiko
> > > --
> > > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > http://lists.denx.de/mailman/listinfo/u-boot
> >
> >
> > Best Regards,
> > Wenyou Yang
> 
> Regards,
> Simon


Best Regards,
Wenyou Yang


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

Re: [U-Boot] [PATCH] malloc: improve memalign fragmentation fix

[Tom Rini]

On Mon, Apr 25, 2016 at 03:55:42PM -0600, Stephen Warren wrote:

> From: Stephen Warren 
> 
> Commit 4f144a416469 "malloc: work around some memalign fragmentation
> issues" enhanced memalign() so that it can succeed in more cases where
> heap fragmentation is present. However, it did not solve as many cases
> as it could. This patch enhances the code to cover more cases.
> 
> The alignment code works by allocating more space than the user requests,
> then adjusting the returned pointer to achieve alignment. In general, one
> must allocate "alignment" bytes more than the user requested in order to
> guarantee that alignment is possible. This is what the original code does.
> The previous enhancement attempted a second allocation if the padded
> allocation failed, and succeeded if that allocation just happened to be
> aligned; a fluke that happened often in practice. There are still cases
> where this could fail, yet where it is still possible to honor the user's
> allocation request. In particular, if the heap contains a free region that
> is large enough for the user's request, and for leading padding to ensure
> alignment, but has no or little space for any trailing padding. In this
> case, we can make a third(!) allocation attempt after calculating exactly
> the size of the leading padding required to achieve alignment, which is
> the minimal over-allocation needed for the overall memalign() operation to
> succeed if the third and second allocations end up at the same location.
> 
> This patch isn't checkpatch-clean, since it conforms to the existing
> coding style in dlmalloc.c, which is different to the rest of U-Boot.
> 
> Signed-off-by: Stephen Warren 

Reviewed-by: Tom Rini 

... for the next release, 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 07/18] net: macb: Convert to driver model

[Simon Glass]

Hi,

On May 4, 2016 21:15, "Yang, Wenyou"  wrote:
>
> Hi Simon,
>
> > -Original Message-
> > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> > Sent: 2016年5月5日 10:38
> > To: Yang, Wenyou 
> > Cc: h...@denx.de; U-Boot Mailing List ; Joe
Hershberger
> > 
> > Subject: Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver model
> >
> > Hi,
> >
> > On 4 May 2016 at 01:32, Yang, Wenyou  wrote:
> > >
> > > Hi
> > >
> > > > -Original Message-
> > > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
> > > > Heiko Schocher
> > > > Sent: 2016年5月3日 15:54
> > > > To: Simon Glass 
> > > > Cc: U-Boot Mailing List ; Joe Hershberger
> > > > 
> > > > Subject: Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver
> > > > model
> > > >
> > > > Hello Simon,
> > > >
> > > > Am 03.05.2016 um 08:40 schrieb Simon Glass:
> > > > > Add driver-model support to this driver. The old code remains for
> > > > > now so that we can convert boards one at a time.
> > > > >
> > > > > Signed-off-by: Simon Glass 
> > > > > ---
> > > > >
> > > > >   drivers/net/macb.c | 119
> > > > +
> > > > >   1 file changed, 119 insertions(+)
> > > >
> > > > Thanks!
> > > >
> > > > Reviewed-by: Heiko Schocher 
> > > >
> > > > tested on the smartweb, corvus, taurus and axm board
> > > >
> > > > Tested-by: Heiko Schocher 
> > >
> > > I tried to test this patch series on SAMA5D2 Xplained board, but I
have the
> > compile warning below. Did you experience it?
> > >
> > > ---8<-
> > > drivers/net/macb.c: In function 'macb_phy_init':
> > > drivers/net/macb.c:487:9: warning: passing argument 3 of 'phy_connect'
> > > from incompatible pointer type [enabled by default] In file included
from
> > include/miiphy.h:22:0,
> > >  from drivers/net/macb.c:36:
> > > include/phy.h:226:20: note: expected 'struct udevice *' but argument
is of type
> > 'const struct device **'
> > > --->8
> >
> > No I don't see that problem. I did a full build test. What is the board
config name
> > you are using?
>
> The board is SAMA5D2 Xplained board, the .config file is attached.
>
> I noticed that in include/phy.h file,  phy_connect() has different
prototype for enabling CONFIG_DM_ETH or not.
>
> So, I think this issue should be exist.

Is that board in mainline?

>
> > >
> > > Thanks.
> > >
> > > >
> > > > bye,
> > > > Heiko
> > > > --
> > > > DENX Software Engineering GmbH,  Managing Director: Wolfgang
Denk
> > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > > Germany ___
> > > > U-Boot mailing list
> > > > U-Boot@lists.denx.de
> > > > http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver model

[Yang, Wenyou]

Hi,

On 2016/5/5 11:18, Simon Glass wrote:


Hi,

On May 4, 2016 21:15, "Yang, Wenyou" > wrote:

>
> Hi Simon,
>
> > -Original Message-
> > From: s...@google.com  
[mailto:s...@google.com ] On Behalf Of Simon Glass

> > Sent: 2016年5月5日 10:38
> > To: Yang, Wenyou >
> > Cc: h...@denx.de ; U-Boot Mailing List 
>; Joe Hershberger

> > >
> > Subject: Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver model
> >
> > Hi,
> >
> > On 4 May 2016 at 01:32, Yang, Wenyou > wrote:

> > >
> > > Hi
> > >
> > > > -Original Message-
> > > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de 
] On Behalf Of

> > > > Heiko Schocher
> > > > Sent: 2016年5月3日 15:54
> > > > To: Simon Glass >
> > > > Cc: U-Boot Mailing List >; Joe Hershberger

> > > > >
> > > > Subject: Re: [U-Boot] [PATCH 07/18] net: macb: Convert to driver
> > > > model
> > > >
> > > > Hello Simon,
> > > >
> > > > Am 03.05.2016 um 08:40 schrieb Simon Glass:
> > > > > Add driver-model support to this driver. The old code 
remains for

> > > > > now so that we can convert boards one at a time.
> > > > >
> > > > > Signed-off-by: Simon Glass >

> > > > > ---
> > > > >
> > > > >   drivers/net/macb.c | 119
> > > > +
> > > > >   1 file changed, 119 insertions(+)
> > > >
> > > > Thanks!
> > > >
> > > > Reviewed-by: Heiko Schocher >
> > > >
> > > > tested on the smartweb, corvus, taurus and axm board
> > > >
> > > > Tested-by: Heiko Schocher >
> > >
> > > I tried to test this patch series on SAMA5D2 Xplained board, but 
I have the

> > compile warning below. Did you experience it?
> > >
> > > ---8<-
> > > drivers/net/macb.c: In function 'macb_phy_init':
> > > drivers/net/macb.c:487:9: warning: passing argument 3 of 
'phy_connect'
> > > from incompatible pointer type [enabled by default] In file 
included from

> > include/miiphy.h:22:0,
> > >  from drivers/net/macb.c:36:
> > > include/phy.h:226:20: note: expected 'struct udevice *' but 
argument is of type

> > 'const struct device **'
> > > --->8
> >
> > No I don't see that problem. I did a full build test. What is the 
board config name

> > you are using?
>
> The board is SAMA5D2 Xplained board, the .config file is attached.
>
> I noticed that in include/phy.h file,  phy_connect() has different 
prototype for enabling CONFIG_DM_ETH or not.

>
> So, I think this issue should be exist.

Is that board in mainline?


Yes, in mainline.

The type of 'dev' parameter of phy_connect() is struct udevice *, 
instead of struct eth_device * when enabling CONFIG_DM_ETH.



>
> > >
> > > Thanks.
> > >
> > > >
> > > > bye,
> > > > Heiko
> > > > --
> > > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > > Germany ___
> > > > U-Boot mailing list
> > > > U-Boot@lists.denx.de 
> > > > http://lists.denx.de/mailman/listinfo/u-boot

Regards,
Simon



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

Re: [U-Boot] [PATCH 4/7] usb: Wait after sending Set Configuration request

[Chin Liang See]

On Wed, 2016-05-04 at 12:00 +0200, Stefan Roese wrote:
> On 04.05.2016 11:45, Chin Liang See wrote:
> > On Wed, 2016-05-04 at 09:41 +0200, Stefan Roese wrote:
> > > On 03.05.2016 22:51, Marek Vasut wrote:
> > > > Some devices, like the SanDisk Cruzer Pop need some time to
> > > > process
> > > > the Set Configuration request, so wait a little until they are
> > > > ready.
> > > > 
> > > > Signed-off-by: Marek Vasut 
> > > > Cc: Chin Liang See 
> > > > Cc: Dinh Nguyen 
> > > > Cc: Hans de Goede 
> > > > Cc: Stefan Roese 
> > > > Cc: Stephen Warren 
> > > > ---
> > > >common/usb.c | 8 
> > > >1 file changed, 8 insertions(+)
> > > > 
> > > > diff --git a/common/usb.c b/common/usb.c
> > > > index 63429d4..205041b 100644
> > > > --- a/common/usb.c
> > > > +++ b/common/usb.c
> > > > @@ -1107,6 +1107,14 @@ int usb_select_config(struct usb_device
> > > > *dev)
> > > > "len %d, status %lX\n", dev
> > > > ->act_len, dev
> > > > ->status);
> > > > return err;
> > > > }
> > > > +
> > > > +   /*
> > > > +* Wait until the Set Configuration request gets
> > > > processed
> > > > by the
> > > > +* device. This is required by at least SanDisk Cruzer
> > > > Pop
> > > > USB 2.0
> > > > +* and Kingston DT Ultimate 32GB USB 3.0 on DWC2 OTG
> > > > controller.
> > > > +*/
> > > > +   mdelay(10);
> > > > +
> > > > debug("new device strings: Mfr=%d, Product=%d,
> > > > SerialNumber=%d\n",
> > > >   dev->descriptor.iManufacturer, dev
> > > > ->descriptor.iProduct,
> > > >   dev->descriptor.iSerialNumber);
> > > > 
> > > 
> > > As you might have expected, I'm not a fan of adding new delays to
> > > the common USB code. As this negatively affects all platforms.
> > > Did
> > > you test these two sticks that require this delay on other
> > > platforms
> > > than SoCFPGA? I would be very interested to know, if these keys
> > > are
> > > successfully detected without this patch on other platforms. I
> > > don't have access to these USB keys, so I can't test it on my
> > > platforms.
> > > 
> > 
> > Actually this series of patches (include the delay) help for all my
> > problematic pen drives too. It sound to me these pen drives need
> > time
> > to process.
> 
> This delay (I'm talking mainly about the 1000ms delay per USB hub
> in patch 7/7) does not seem to be necessary on other platforms.
> 
> Chin, could you please test again without this patch 7/7 but
> with "usb_pgood_delay" set to 1000? And let us know if this
> also fixes all the problems with your problematic pen drives?
> That would be very helpful.
> 

Yup, it works for my problematic pen drives. This apply to both with
and without setting the usb_pgood_delay to 1000.

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH v5 2/3] spl: Allow to load a FIT containing U-Boot from FS

[Michal Simek]

On 4.5.2016 14:04, Lokesh Vutla wrote:
> This provides a way to load a FIT containing U-Boot and a selection of device
> tree files from a File system. Making sure that all the reads and writes
> are aligned to their respective needs.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  common/spl/spl_fit.c | 76 
> +---
>  include/spl.h| 10 +++
>  2 files changed, 71 insertions(+), 15 deletions(-)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index b1cfa97..ace2543 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -82,6 +82,42 @@ static int spl_fit_select_fdt(const void *fdt, int images, 
> int *fdt_offsetp)
>   return -ENOENT;
>  }
>  
> +static int get_aligned_image_offset(struct spl_load_info *info, int offset)
> +{
> + /*
> +  * If it is a FS read, get the first address before offset which is
> +  * aligned to ARCH_DMA_MINALIGN. If it is raw read return the
> +  * block number to which offset belongs.
> +  */
> + if (info->priv)
> + return offset & ~(ARCH_DMA_MINALIGN - 1);
> +
> + return offset / info->bl_len;
> +}
> +
> +static int get_aligned_image_overhead(struct spl_load_info *info, int offset)
> +{
> + /*
> +  * If it is a FS read, get the difference between the offset and
> +  * the first address before offset which is aligned to
> +  * ARCH_DMA_MINALIGN. If it is raw read return the offset within the
> +  * block.
> +  */
> + if (info->priv)
> + return offset & (ARCH_DMA_MINALIGN - 1);
> +
> + return offset % info->bl_len;
> +}
> +
> +static int get_aligned_image_size(struct spl_load_info *info, int data_size,
> +   int offset)
> +{
> + if (info->priv)
> + return data_size + get_aligned_image_overhead(info, offset);
> +
> + return (data_size + info->bl_len - 1) / info->bl_len;
> +}
> +
>  int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
>  {
>   int sectors;
> @@ -91,7 +127,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
> sector, void *fit)
>   void *load_ptr;
>   int fdt_offset, fdt_len;
>   int data_offset, data_size;
> - int base_offset;
> + int base_offset, align_len;
>   int src_sector;
>   void *dst;
>  
> @@ -117,8 +153,10 @@ int spl_load_simple_fit(struct spl_load_info *info, 
> ulong sector, void *fit)
>* In fact the FIT has its own load address, but we assume it cannot
>* be before CONFIG_SYS_TEXT_BASE.
>*/
> - fit = (void *)(CONFIG_SYS_TEXT_BASE - size - info->bl_len);
> - sectors = (size + info->bl_len - 1) / info->bl_len;
> + align_len = ARCH_DMA_MINALIGN - 1;
> + fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len -
> + align_len) & ~align_len);
> + sectors = get_aligned_image_size(info, size, 0);
>   count = info->read(info, sector, sectors, fit);
>   debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",
> sector, sectors, fit, count);
> @@ -151,19 +189,23 @@ int spl_load_simple_fit(struct spl_load_info *info, 
> ulong sector, void *fit)
>* byte will be at 'load'. This may mean we need to load it starting
>* before then, since we can only read whole blocks.
>*/
> - sectors = (data_size + info->bl_len - 1) / info->bl_len;
>   data_offset += base_offset;
> + sectors = get_aligned_image_size(info, data_size, data_offset);
>   load_ptr = (void *)load;
>   debug("U-Boot size %x, data %p\n", data_size, load_ptr);
> - dst = load_ptr - (data_offset % info->bl_len);
> + dst = load_ptr;
>  
>   /* Read the image */
> - src_sector = sector + data_offset / info->bl_len;
> - debug("image: data_offset=%x, dst=%p, src_sector=%x, sectors=%x\n",
> -   data_offset, dst, src_sector, sectors);
> + src_sector = sector + get_aligned_image_offset(info, data_offset);
> + debug("Aligned image read: dst=%p, src_sector=%x, sectors=%x\n",
> +   dst, src_sector, sectors);
>   count = info->read(info, src_sector, sectors, dst);
>   if (count != sectors)
>   return -EIO;
> + debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
> +   data_size);
> + memcpy(dst, dst + get_aligned_image_overhead(info, data_offset),
> +data_size);
>  
>   /* Figure out which device tree the board wants to use */
>   fdt_len = spl_fit_select_fdt(fit, images, _offset);
> @@ -173,14 +215,15 @@ int spl_load_simple_fit(struct spl_load_info *info, 
> ulong sector, void *fit)
>   /*
>* Read the device tree and place it after the image. There may be
>* some extra data before it since we can only read entire blocks.
> +  * And also align the destination address to ARCH_DMA_MINALIGN.
>*/
> - dst = load_ptr + data_size;
> + dst = 

Re: [U-Boot] [PATCH] ARM: zynq: load u-boot.img whether CONFIG_OF_SEPARATE is defined or not

[Masahiro Yamada]

Hi Michal,

Does this patch look good?
or does it have impact on your customers?


2016-04-14 6:52 GMT+09:00 Masahiro Yamada :
> Since commit ad1ecd2063da ("fdt: Build a U-Boot binary without device
> tree"), u-boot-dtb.img is identical to u-boot.img, so SPL can always
> load u-boot.img whether CONFIG_OF_SEPARATE is defined or not.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  include/configs/zynq-common.h | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
> index 49d9fd0..3b5cd5b 100644
> --- a/include/configs/zynq-common.h
> +++ b/include/configs/zynq-common.h
> @@ -339,11 +339,7 @@
>  #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
>  #define CONFIG_SPL_LIBDISK_SUPPORT
>  #define CONFIG_SPL_FAT_SUPPORT
> -#ifdef CONFIG_OF_SEPARATE
> -# define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img"
> -#else
> -# define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img"
> -#endif
> +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img"
>  #endif
>
>  /* Disable dcache for SPL just for sure */
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
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] Fix various typos, scattered over the code.

[James Chargin]

Hi Robert,

I appreciate this work on typos. Thanks.


On 05/04/2016 01:47 AM, Robert P. J. Day wrote:


Spelling corrections for (among other things):

* environment
* override
* variable
* ftd (should be "fdt", for flattened device tree)
* embedded
* FTDI
* emulation
* controller

---

   the fixes for "controller" here are independent of the previous
patch.

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 d580a43..a9b12a4 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c
@@ -180,7 +180,7 @@ ulong get_ddr_freq(ulong ctrl_num)

/*
 * DDR controller 0 & 1 are on memory complex 0
-* DDR controler 2 is on memory complext 1
+* DDR controller 2 is on memory complext 1


Should this be

> +   * DDR controller 2 is on memory complex 1

Jim


 */
 ...


Regards,

--
Jim Chargin
AJA Video Systems   j...@aja.com
(530) 271-3334  http://www.aja.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix various typos, scattered over the code.

[Robert P. J. Day]

On Wed, 4 May 2016, James Chargin wrote:

> >/*
> >  * DDR controller 0 & 1 are on memory complex 0
> > -* DDR controler 2 is on memory complext 1
> > +* DDR controller 2 is on memory complext 1
>
> Should this be
>
> > +* DDR controller 2 is on memory complex 1

  well, of course it should, but i've already started another
repository for more typos so i'll just throw that into the next batch
and let tom apply the patch i sent in. trust me, there's lots more
where that came from.

rday

-- 


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

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


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

Re: [U-Boot] [PATCH v5 3/3] spl: Support loading a FIT from FAT FS

[Michal Simek]

On 4.5.2016 14:04, Lokesh Vutla wrote:
> Detect a FIT when loading from a FAT File system and handle it using the
> new FIT SPL support.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  common/spl/spl_fat.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
> index d761b26..cdb9811 100644
> --- a/common/spl/spl_fat.c
> +++ b/common/spl/spl_fat.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static int fat_registered;
>  
> @@ -39,6 +40,20 @@ static int spl_register_fat_device(struct blk_desc 
> *block_dev, int partition)
>   return err;
>  }
>  
> +static ulong spl_fit_read(struct spl_load_info *load, ulong file_offset,
> +   ulong size, void *buf)
> +{
> + loff_t actread;
> + int ret;
> + char *filename = (char *)load->priv;
> +
> + ret = fat_read_file(filename, buf, file_offset, size, );
> + if (ret)
> + return ret;
> +
> + return actread;
> +}
> +
>  int spl_load_image_fat(struct blk_desc *block_dev,
>   int partition,
>   const char *filename)
> @@ -57,9 +72,21 @@ int spl_load_image_fat(struct blk_desc *block_dev,
>   if (err <= 0)
>   goto end;
>  
> - spl_parse_image_header(header);
> + if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
> + image_get_magic(header) == FDT_MAGIC) {
> + struct spl_load_info load;
> +
> + debug("Found FIT\n");
> + load.read = spl_fit_read;
> + load.bl_len = 1;
> + load.priv = (void *)filename;
>  
> - err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
> + return spl_load_simple_fit(, 0, header);
> + } else {
> + spl_parse_image_header(header);
> +
> + err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
> + }
>  
>  end:
>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> 


Tested-by: Michal Simek 

Thanks,
Michal

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

Re: [U-Boot] [PATCH 1/2] spl: Make sure destination address is dma aligned when loading fit

[Lokesh Vutla]

On Wednesday 06 April 2016 05:32 PM, Lokesh Vutla wrote:
> Peripherals like spi etc. uses DMA for transfers. So, when loading the fit
> image the destination address should be dma aligned.

After the v5 of my FS support for FIT[1], this patch is no more
necessary. Patch 2 is alone sufficient.

[1] http://patchwork.ozlabs.org/patch/618403/

Thanks and regards,
Lokesh

> 
> Signed-off-by: Lokesh Vutla 
> ---
> - Assuming u-boot.bin load addr will always be dma aligned.
> 
>  common/spl/spl_fit.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 4c9fe7b..20396b9 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -91,7 +91,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
> sector, void *fit)
>   void *load_ptr;
>   int fdt_offset, fdt_len;
>   int data_offset, data_size;
> - int base_offset;
> + int base_offset, align_len;
>   int src_sector;
>   void *dst;
>  
> @@ -117,7 +117,9 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
> sector, void *fit)
>* In fact the FIT has its own load address, but we assume it cannot
>* be before CONFIG_SYS_TEXT_BASE.
>*/
> - fit = (void *)(CONFIG_SYS_TEXT_BASE - size - info->bl_len);
> + align_len = ARCH_DMA_MINALIGN - 1;
> + fit = (void *)((CONFIG_SYS_TEXT_BASE - size - info->bl_len -
> + align_len) & ~align_len);
>   sectors = (size + info->bl_len - 1) / info->bl_len;
>   count = info->read(info, sector, sectors, fit);
>   debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu\n",
> @@ -173,8 +175,9 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
> sector, void *fit)
>   /*
>* Read the device tree and place it after the image. There may be
>* some extra data before it since we can only read entire blocks.
> +  * And also align the destination address to ARCH_DMA_MINALIGN.
>*/
> - dst = load_ptr + data_size;
> + dst = (void *)((load + data_size + align_len) & ~align_len);
>   fdt_offset += base_offset;
>   count = info->read(info, sector + fdt_offset / info->bl_len, sectors,
>  dst);
> @@ -188,7 +191,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
> sector, void *fit)
>* After this we will have the U-Boot image and its device tree ready
>* for us to start.
>*/
> - memcpy(dst, dst + fdt_offset % info->bl_len, fdt_len);
> + memcpy(load_ptr + data_size, dst + fdt_offset % info->bl_len, fdt_len);
>  
>   return 0;
>  }
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] usb: Wait after sending Set Configuration request

[Sriram Dash]

>-Original Message-
>From: Chin Liang See [mailto:cl...@altera.com]
>Sent: Wednesday, May 04, 2016 3:15 PM
>To: Stefan Roese ; Marek Vasut ; u-
>b...@lists.denx.de
>Cc: Dinh Nguyen ; Hans de Goede
>; Stephen Warren ;
>sriram.d...@freescale.com; rajesh.bha...@freescale.com
>Subject: Re: [PATCH 4/7] usb: Wait after sending Set Configuration request
>
>On Wed, 2016-05-04 at 09:41 +0200, Stefan Roese wrote:
>> On 03.05.2016 22:51, Marek Vasut wrote:
>> > Some devices, like the SanDisk Cruzer Pop need some time to process
>> > the Set Configuration request, so wait a little until they are
>> > ready.
>> >
>> > Signed-off-by: Marek Vasut 
>> > Cc: Chin Liang See 
>> > Cc: Dinh Nguyen 
>> > Cc: Hans de Goede 
>> > Cc: Stefan Roese 
>> > Cc: Stephen Warren 
>> > ---
>> >   common/usb.c | 8 
>> >   1 file changed, 8 insertions(+)
>> >
>> > diff --git a/common/usb.c b/common/usb.c index 63429d4..205041b
>> > 100644
>> > --- a/common/usb.c
>> > +++ b/common/usb.c
>> > @@ -1107,6 +1107,14 @@ int usb_select_config(struct usb_device
>> > *dev)
>> >"len %d, status %lX\n", dev->act_len, dev
>> > ->status);
>> >return err;
>> >}
>> > +
>> > +  /*
>> > +   * Wait until the Set Configuration request gets processed
>> > by the
>> > +   * device. This is required by at least SanDisk Cruzer Pop
>> > USB 2.0
>> > +   * and Kingston DT Ultimate 32GB USB 3.0 on DWC2 OTG
>> > controller.
>> > +   */
>> > +  mdelay(10);
>> > +
>> >debug("new device strings: Mfr=%d, Product=%d,
>> > SerialNumber=%d\n",
>> >  dev->descriptor.iManufacturer, dev
>> > ->descriptor.iProduct,
>> >  dev->descriptor.iSerialNumber);
>> >
>>
>> As you might have expected, I'm not a fan of adding new delays to the
>> common USB code. As this negatively affects all platforms. Did you
>> test these two sticks that require this delay on other platforms than
>> SoCFPGA? I would be very interested to know, if these keys are
>> successfully detected without this patch on other platforms. I don't
>> have access to these USB keys, so I can't test it on my platforms.
>>
>
>Actually this series of patches (include the delay) help for all my 
>problematic pen
>drives too. It sound to me these pen drives need time to process. But at same 
>time,
>its strange to me that the device didn't NAK (as I added printout for NAK) to 
>indicate
>that its busy.
>
>Seems that this issue is noticed at Freescale too.
>http://lists.denx.de/pipermail/u-boot/2015-December/238434.html. Cc'ed them as
>they might can share more details on this.
>

Hello,

In our case, for some  USB 2.0 stick(notably : Sandisk Cruzer blade 4 GB) on 
USB 3.0 controller, 
we were getting timeouts in get descriptor string, and were not able to 
retrieve the manufacturer,
product id , serial number.

Later we discovered, they needed a little more time (~ 2 ms) after setting 
configuration. However,
as per the usb set address delay, we choose 10 ms delay(to support even slower 
devices).

Sriram

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

Re: [U-Boot] [PATCH 5/7] usb: Assure Get Descriptor request is in separate microframe

[Stephen Warren]

On 05/03/2016 02:51 PM, Marek Vasut wrote:

The Kingston DT Ultimate USB 3.0 stick is sensitive to this first
Get Descriptor request and if the request is not in a separate
microframe, the stick refuses to operate. Add slight delay, which
is enough for one microframe to pass on any USB spec revision.



diff --git a/common/usb.c b/common/usb.c



+   /*
+* Kingston DT Ultimate 32GB USB 3.0 seems to be extremely sensitive
+* about this first Get Descriptor request. If there are any other
+* requests in the first microframe, the stick crashes. Wait about
+* one microframe duration here (1mS for USB 1.x , 125uS for USB 2.0).
+*/
+   mdelay(1);


Do we know the connection speed here? If so, we could sleep 1ms for 
USB1.x and 125us for USB2.x, thus reducing any performance impact. 
Still, this is a short delay that I think only happens once per actual 
device so perhaps it isn't worth it.

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

Re: [U-Boot] [PATCH 7/7] usb: hub: Increase the query delay

[Stephen Warren]

On 05/03/2016 02:51 PM, Marek Vasut wrote:

Increase the query delay, otherwise some sticks are not detected.
The problem shows up on the USB bus analyzer such that the stick
takes longer time to switch from FS mode to HS mode than the code
allows.



diff --git a/common/usb_hub.c b/common/usb_hub.c



@@ -145,7 +145,7 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
 * Do a minimum delay of the larger value of 100ms or pgood_delay
 * so that the power can stablize before the devices are queried
 */
-   hub->query_delay = get_timer(0) + max(100, (int)pgood_delay);
+   hub->query_delay = get_timer(0) + max(1000, (int)pgood_delay);


The comment right above that line of code should be updated to say 1000 
not 100, and to mention why we're using the non-spec value.


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

[U-Boot] [PATCH 0/4] efi_loader: PXE boot support

[Alexander Graf]

One of the most common boot cases with EFI on arm64 is to boot from the
network using PXE boot. While TianoCore implements that just fine, we
were lacking support for it in U-Boot so far.

But no longer! Here is a patch set, enabling PXE booting of EFI payloads.
With this patch set, I was successfully able to automatically boot our
normal (usually used with TianoCore based systems) environment to boot
and run grub2 and a kernel from there with U-Boot.

Alexander Graf (4):
  efi_loader: Add network access support
  bootp: Move vendor class identifier set to function
  net: Move the VCI and client arch values to Kconfig
  distro: Add efi pxe boot code

 cmd/bootefi.c  |   7 +
 configs/ls2080a_emu_defconfig  |   1 +
 configs/ls2080a_simu_defconfig |   1 +
 configs/thunderx_88xx_defconfig|   1 +
 configs/vexpress_aemv8a_dram_defconfig |   1 +
 configs/vexpress_aemv8a_juno_defconfig |   1 +
 configs/vexpress_aemv8a_semi_defconfig |   1 +
 configs/vexpress_ca15_tc2_defconfig|   1 +
 configs/vexpress_ca5x2_defconfig   |   1 +
 configs/vexpress_ca9x4_defconfig   |   1 +
 include/config_distro_bootcmd.h|  37 -
 include/config_distro_defaults.h   |  21 ---
 include/configs/ls2080a_emu.h  |   1 -
 include/configs/ls2080a_simu.h |   1 -
 include/configs/thunderx_88xx.h|   2 -
 include/configs/vexpress_aemv8a.h  |   2 -
 include/configs/vexpress_ca15_tc2.h|   1 -
 include/configs/vexpress_ca5x2.h   |   1 -
 include/configs/vexpress_ca9x4.h   |   1 -
 include/efi_api.h  | 119 ++
 include/efi_loader.h   |   7 +
 include/net.h  |   2 +-
 lib/efi_loader/Makefile|   1 +
 lib/efi_loader/efi_net.c   | 291 +
 net/Kconfig|  12 ++
 net/bootp.c|  37 +++--
 net/net.c  |   4 +-
 net/tftp.c |   2 +
 28 files changed, 511 insertions(+), 47 deletions(-)
 create mode 100644 lib/efi_loader/efi_net.c

-- 
1.8.5.6

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

[U-Boot] [PATCH 2/4] bootp: Move vendor class identifier set to function

[Alexander Graf]

Both the dhcp as well as the bootp case add vendor class identifier
parameters into their packets. Let's move that into a separate function
to make overlaying easier.

Signed-off-by: Alexander Graf 
---
 net/bootp.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/net/bootp.c b/net/bootp.c
index d91b307..d718e35 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -411,6 +411,17 @@ static void bootp_timeout_handler(void)
e += vci_strlen;\
} while (0)
 
+static u8 *add_vci(u8 *e)
+{
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_NET_VCI_STRING)
+   put_vci(e, CONFIG_SPL_NET_VCI_STRING);
+#elif defined(CONFIG_BOOTP_VCI_STRING)
+   put_vci(e, CONFIG_BOOTP_VCI_STRING);
+#endif
+
+   return e;
+}
+
 /*
  * Initialize BOOTP extension fields in the request.
  */
@@ -508,11 +519,7 @@ static int dhcp_extended(u8 *e, int message_type, struct 
in_addr server_ip,
}
 #endif
 
-#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_NET_VCI_STRING)
-   put_vci(e, CONFIG_SPL_NET_VCI_STRING);
-#elif defined(CONFIG_BOOTP_VCI_STRING)
-   put_vci(e, CONFIG_BOOTP_VCI_STRING);
-#endif
+   e = add_vci(e);
 
 #if defined(CONFIG_BOOTP_VENDOREX)
x = dhcp_vendorex_prep(e);
@@ -598,14 +605,7 @@ static int bootp_extended(u8 *e)
*e++ = (576 - 312 + OPT_FIELD_SIZE) & 0xff;
 #endif
 
-#if defined(CONFIG_BOOTP_VCI_STRING) || \
-   (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_NET_VCI_STRING))
-#ifdef CONFIG_SPL_BUILD
-   put_vci(e, CONFIG_SPL_NET_VCI_STRING);
-#else
-   put_vci(e, CONFIG_BOOTP_VCI_STRING);
-#endif
-#endif
+   add_vci(e);
 
 #if defined(CONFIG_BOOTP_SUBNETMASK)
*e++ = 1;   /* Subnet mask request */
-- 
1.8.5.6

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

[U-Boot] [PATCH 4/4] distro: Add efi pxe boot code

[Alexander Graf]

Now that we can expose network functionality to EFI applications,
the logical next step is to load them via pxe to execute them as
well.

This patch adds the necessary bits to the distro script to automatically
load and execute EFI payloads. It identifies the dhcp client as a uEFI
capable PXE client, hoping the server returns a tftp path to a workable
EFI binary that we can then execute.

To enable boards that don't come with a working device tree preloaded,
this patch also adds support to load a device tree from the /dtb directory
on the remote tftp server.

Signed-off-by: Alexander Graf 
---
 include/config_distro_bootcmd.h | 37 -
 net/bootp.c | 13 +++--
 2 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 7f67344..c18731e 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -230,13 +230,48 @@
 #endif
 
 #if defined(CONFIG_CMD_DHCP)
+#if defined(CONFIG_EFI_LOADER)
+#if defined(CONFIG_ARM64)
+#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00011:UNDI:003000"
+#elif defined(CONFIG_ARM)
+#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000"
+#else
+#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:0:UNDI:003000"
+#endif
+
+/*
+ * Ask the dhcp server for an EFI binary. If we get one, check for a
+ * device tree in the same folder. Then boot everything. If the file was
+ * not an EFI binary, we just return from the bootefi command and continue.
+ */
+#define BOOTENV_EFI_RUN_DHCP \
+   "setenv efi_fdtfile ${fdtfile}; " \
+   BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
+   "setenv efi_old_vci ${bootp_vci};"\
+   "setenv bootp_vci " BOOTENV_EFI_PXE_VCI ";"   \
+   "if dhcp ${kernel_addr_r}; then " \
+   "tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};"  \
+   "if fdt addr ${fdt_addr_r}; then "\
+   "bootefi ${kernel_addr_r} ${fdt_addr_r}; "\
+   "else "   \
+   "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
+   "fi;" \
+   "fi;" \
+   "setenv bootp_vci ${efi_old_vci};"\
+   "setenv efi_fdtfile;" \
+   "setenv efi_old_vci;"
+#else
+#define BOOTENV_EFI_RUN_DHCP
+#endif
 #define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \
"bootcmd_dhcp=" \
BOOTENV_RUN_NET_USB_START \
BOOTENV_RUN_NET_PCI_ENUM \
"if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \
"source ${scriptaddr}; " \
-   "fi\0"
+   "fi;" \
+   BOOTENV_EFI_RUN_DHCP \
+   "\0"
 #define BOOTENV_DEV_NAME_DHCP(devtypeu, devtypel, instance) \
"dhcp "
 #else
diff --git a/net/bootp.c b/net/bootp.c
index d718e35..85dc524 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -413,12 +413,21 @@ static void bootp_timeout_handler(void)
 
 static u8 *add_vci(u8 *e)
 {
+   char *vci = NULL;
+   char *env_vci = getenv("bootp_vci");
+
 #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_NET_VCI_STRING)
-   put_vci(e, CONFIG_SPL_NET_VCI_STRING);
+   vci = CONFIG_SPL_NET_VCI_STRING;
 #elif defined(CONFIG_BOOTP_VCI_STRING)
-   put_vci(e, CONFIG_BOOTP_VCI_STRING);
+   vci = CONFIG_BOOTP_VCI_STRING;
 #endif
 
+   if (env_vci)
+   vci = env_vci;
+
+   if (vci)
+   put_vci(e, vci);
+
return e;
 }
 
-- 
1.8.5.6

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

[U-Boot] [PATCH 1/4] efi_loader: Add network access support

[Alexander Graf]

We can now successfully boot EFI applications from disk, but users
may want to also run them from a PXE setup.

This patch implements rudimentary network support, allowing a payload
to send and receive network packets.

With this patch, I was able to successfully run grub2 with network
access inside of QEMU's -M xlnx-ep108.

Signed-off-by: Alexander Graf 
---
 cmd/bootefi.c|   7 ++
 include/efi_api.h| 119 +++
 include/efi_loader.h |   7 ++
 include/net.h|   2 +-
 lib/efi_loader/Makefile  |   1 +
 lib/efi_loader/efi_net.c | 291 +++
 net/bootp.c  |   2 +
 net/net.c|   4 +-
 net/tftp.c   |   2 +
 9 files changed, 432 insertions(+), 3 deletions(-)
 create mode 100644 lib/efi_loader/efi_net.c

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 7f552fc..d3a2331 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -197,6 +197,13 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
 #ifdef CONFIG_LCD
efi_gop_register();
 #endif
+#ifdef CONFIG_NET
+   void *nethandle = loaded_image_info.device_handle;
+   efi_net_register();
+
+   if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
+   loaded_image_info.device_handle = nethandle;
+#endif
 
/* Call our payload! */
 #ifdef DEBUG_EFI
diff --git a/include/efi_api.h b/include/efi_api.h
index 51d7586..20035d7 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -412,4 +412,123 @@ struct efi_gop
struct efi_gop_mode *mode;
 };
 
+#define EFI_SIMPLE_NETWORK_GUID \
+   EFI_GUID(0xa19832b9, 0xac25, 0x11d3, \
+0x9a, 0x2d, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
+struct efi_mac_address {
+   char mac_addr[32];
+};
+
+struct efi_ip_address {
+   u8 ip_addr[16];
+};
+
+enum efi_simple_network_state {
+   EFI_NETWORK_STOPPED,
+   EFI_NETWORK_STARTED,
+   EFI_NETWORK_INITIALIZED,
+};
+
+struct efi_simple_network_mode {
+   enum efi_simple_network_state state;
+   u32 hwaddr_size;
+   u32 media_header_size;
+   u32 max_packet_size;
+   u32 nvram_size;
+   u32 nvram_access_size;
+   u32 receive_filter_mask;
+   u32 receive_filter_setting;
+   u32 max_mcast_filter_count;
+   u32 mcast_filter_count;
+   struct efi_mac_address mcast_filter[16];
+   struct efi_mac_address current_address;
+   struct efi_mac_address broadcast_address;
+   struct efi_mac_address permanent_address;
+   u8 if_type;
+   u8 mac_changeable;
+   u8 multitx_supported;
+   u8 media_present_supported;
+   u8 media_present;
+};
+
+#define EFI_SIMPLE_NETWORK_RECEIVE_UNICAST   0x01,
+#define EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST 0x02,
+#define EFI_SIMPLE_NETWORK_RECEIVE_BROADCAST 0x04,
+#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS   0x08,
+#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST 0x10,
+
+struct efi_simple_network
+{
+   u64 revision;
+   efi_status_t (EFIAPI *start)(struct efi_simple_network *this);
+   efi_status_t (EFIAPI *stop)(struct efi_simple_network *this);
+   efi_status_t (EFIAPI *initialize)(struct efi_simple_network *this,
+   ulong extra_rx, ulong extra_tx);
+   efi_status_t (EFIAPI *reset)(struct efi_simple_network *this,
+   int extended_verification);
+   efi_status_t (EFIAPI *shutdown)(struct efi_simple_network *this);
+   efi_status_t (EFIAPI *receive_filters)(struct efi_simple_network *this,
+   u32 enable, u32 disable, int reset_mcast_filter,
+   ulong mcast_filter_count,
+   struct efi_mac_address *mcast_filter);
+   efi_status_t (EFIAPI *station_address)(struct efi_simple_network *this,
+   int reset, struct efi_mac_address *new_mac);
+   efi_status_t (EFIAPI *statistics)(struct efi_simple_network *this,
+   int reset, ulong *stat_size, void *stat_table);
+   efi_status_t (EFIAPI *mcastiptomac)(struct efi_simple_network *this,
+   int ipv6, struct efi_ip_address *ip,
+   struct efi_mac_address *mac);
+   efi_status_t (EFIAPI *nvdata)(struct efi_simple_network *this,
+   int read_write, ulong offset, ulong buffer_size,
+   char *buffer);
+   efi_status_t (EFIAPI *get_status)(struct efi_simple_network *this,
+   u32 *int_status, void **txbuf);
+   efi_status_t (EFIAPI *transmit)(struct efi_simple_network *this,
+   ulong header_size, ulong buffer_size, void *buffer,
+   struct efi_mac_address *src_addr,
+   struct efi_mac_address *dest_addr, u16 *protocol);
+   efi_status_t (EFIAPI *receive)(struct efi_simple_network *this,
+   ulong *header_size, 

Re: [U-Boot] [PATCH 7/7] usb: hub: Increase the query delay

[Stefan Roese]

On 04.05.2016 13:39, Marek Vasut wrote:

On 05/04/2016 10:07 AM, Stefan Roese wrote:

On 03.05.2016 22:51, Marek Vasut wrote:

Increase the query delay, otherwise some sticks are not detected.
The problem shows up on the USB bus analyzer such that the stick
takes longer time to switch from FS mode to HS mode than the code
allows.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Hans de Goede 
Cc: Stefan Roese 
Cc: Stephen Warren 
---
   common/usb_hub.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index 0f39c9f..6cd274a 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -145,7 +145,7 @@ static void usb_hub_power_on(struct usb_hub_device
*hub)
* Do a minimum delay of the larger value of 100ms or pgood_delay
* so that the power can stablize before the devices are queried
*/
-hub->query_delay = get_timer(0) + max(100, (int)pgood_delay);
+hub->query_delay = get_timer(0) + max(1000, (int)pgood_delay);

   /*
* Record the power-on timeout here. The max. delay (timeout)



We have touched this part of the delay a number of times in my
USB scanning patch series. I've integrated all very valuable
suggestions from Stephen and Hans and I'm pretty sure that the
current implementation is aligned with the USB spec.


Sadly, not everyone goes exactly be the USB spec it seems.
Especially the cheap sticks which are the majority in the market.


And tested
successfully one multiple platforms without regression.
Stephen did some tests on Tegra and Hans on sunxi. I tested
mainly on x86. But I now also tested on Armada XP (see
below).


All of which use the same EHCI or XHCI controller, correct ?


As mentioned before, the current version causes no problems with
all my USB sticks on the congatec x86 board. Even the 2 ones that
are problematic when connected to the SoCFPGA. They are detected
without any issues on this board. Thats why I assume, that the
real problem here is the DWC driver and not the generic USB
handling code.


The logic here is flawed. If the code works against EHCI controller and
does not work against DWC2 controller, you cannot infer from this that
the DWC2 controller is the problem.

This can also be specific behavior of the EHCI controller, and I in fact
suspect it is, but you cannot decide this without checking the
bus itself.


My feeling is that increasing this initial delay
(before the scanning starts) just papers over the real problem
most likely hidden somewhere in the DWC driver. This is just
a feeling though which I can't prove somehow other than testing
the common USB code on different platforms. And I really have
no deeper knowledge of the DWC driver to manifest this feeling
or even fix this potential problem there.


The bus analyzer tells me that the stick just takes longer to come out
of FS mode and switch to HS mode when the USB started from reset state
of the controller, I decide to trust what the analyzer shows me instead.

See attached logs.


I've already mentioned this in another mail. My suggestion for
SoCFPGA boards that need to use these problematic USB keys is
to use the already available solution to set "usb_pgood_delay"
to 1000. This effectively does the same as this patch. Without
implying this general 1 second delay per hub (!!!) to all other
platforms that use USB in U-Boot.

To test my suspicions about this being a DWC (SoCFPGA?) only
problem, I've also tested all my current USB sticks including
the 2 problematic ones (on SoCrates) on another ARM platform
(additionally to all my test on x86). I've used the Marvell
Armada XP development board (db-mv784mp-gp) for this. And all
USB sticks are detected without any problems on this platform.


I see, it would be interesting to know what happens on the bus on the
marvell board compared to the socfpga board. For the socfpga, the bus
starts from complete cold state, could it be the marvell does have the
EHCI running when you do your tests ? That would explain why the stick
might be ready much faster on your platform.


As a result of all this, I would like to have this patch not
applied. As it negatively touches the common USB code to fix
(paper over?) a problem only seen on one platform (AFAIK). And
we already have the solution of this "usb_pgood_delay" that
can be used on SoCFPGA. To manifest this, here again the
numbers for the USB scanning time on x86, without and with
this patch:

Without this patch:
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found

time: 1.940 seconds

With this patch:
=> time usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found

time: 5.421 seconds


Well that's great, removing some delays makes the code run faster and
breaks some platform. Stefan, I need a solution for this 

Re: [U-Boot] [PATCH 3/7] usb: dwc2: Throttle the setup packet resending

[Stephen Warren]

On 05/03/2016 02:51 PM, Marek Vasut wrote:

Abort the request in case any of the tokens in the packet failed to
complete transfer 10 times. This is a precaution needed so that we
don't end in endless loop when scanning the bus with some braindead
devices.


Does this affect USB keyboards when SYS_USB_EVENT_POLL_VIA_CONTROL_EP is 
enabled? IIRC control transactions to HID devices can be held off for 
some duration based on polling intervals, and this patch might abort 
them early?


Or do we typically expect to use interrupt transfers for keyboards, so 
this isn't too relevant (although there are some platforms that enable 
SYS_USB_EVENT_POLL_VIA_CONTROL_EP). Maybe not DWC2 platforms though; I 
didn't check.

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

[U-Boot] [PATCH 3/4] net: Move the VCI and client arch values to Kconfig

[Alexander Graf]

We have a bunch of boards that define their vendor class identifier and
client archs in the board files or in the distro config. Move everything
to the generic Kconfig options.

We're missing the distinction between i386 and x86_64, as I couldn't find
any config variable that would tell us the difference. Is that really important
to people? I guess not, so I left it out.

Signed-off-by: Alexander Graf 
---
 configs/ls2080a_emu_defconfig  |  1 +
 configs/ls2080a_simu_defconfig |  1 +
 configs/thunderx_88xx_defconfig|  1 +
 configs/vexpress_aemv8a_dram_defconfig |  1 +
 configs/vexpress_aemv8a_juno_defconfig |  1 +
 configs/vexpress_aemv8a_semi_defconfig |  1 +
 configs/vexpress_ca15_tc2_defconfig|  1 +
 configs/vexpress_ca5x2_defconfig   |  1 +
 configs/vexpress_ca9x4_defconfig   |  1 +
 include/config_distro_defaults.h   | 21 -
 include/configs/ls2080a_emu.h  |  1 -
 include/configs/ls2080a_simu.h |  1 -
 include/configs/thunderx_88xx.h|  2 --
 include/configs/vexpress_aemv8a.h  |  2 --
 include/configs/vexpress_ca15_tc2.h|  1 -
 include/configs/vexpress_ca5x2.h   |  1 -
 include/configs/vexpress_ca9x4.h   |  1 -
 net/Kconfig| 12 
 18 files changed, 21 insertions(+), 30 deletions(-)

diff --git a/configs/ls2080a_emu_defconfig b/configs/ls2080a_emu_defconfig
index f9b4eac..30a6381 100644
--- a/configs/ls2080a_emu_defconfig
+++ b/configs/ls2080a_emu_defconfig
@@ -25,3 +25,4 @@ CONFIG_CMD_CACHE=y
 # CONFIG_CMD_MISC is not set
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
+CONFIG_BOOTP_VCI_STRING="U-Boot.LS2080A-EMU"
diff --git a/configs/ls2080a_simu_defconfig b/configs/ls2080a_simu_defconfig
index 728fa25..a095b8a 100644
--- a/configs/ls2080a_simu_defconfig
+++ b/configs/ls2080a_simu_defconfig
@@ -28,3 +28,4 @@ CONFIG_CMD_FAT=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
+CONFIG_BOOTP_VCI_STRING="U-Boot.LS2080A-SIMU"
diff --git a/configs/thunderx_88xx_defconfig b/configs/thunderx_88xx_defconfig
index b7078e0..cb33f60 100644
--- a/configs/thunderx_88xx_defconfig
+++ b/configs/thunderx_88xx_defconfig
@@ -22,3 +22,4 @@ CONFIG_DEBUG_UART_BASE=0x87e02400
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SKIP_INIT=y
 CONFIG_REGEX=y
+CONFIG_BOOTP_VCI_STRING="Diagnostics"
diff --git a/configs/vexpress_aemv8a_dram_defconfig 
b/configs/vexpress_aemv8a_dram_defconfig
index 989f068..c0708b2 100644
--- a/configs/vexpress_aemv8a_dram_defconfig
+++ b/configs/vexpress_aemv8a_dram_defconfig
@@ -24,3 +24,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_FAT=y
 CONFIG_DM=y
 CONFIG_OF_LIBFDT=y
+CONFIG_BOOTP_VCI_STRING="U-Boot.armv8.vexpress_aemv8a"
diff --git a/configs/vexpress_aemv8a_juno_defconfig 
b/configs/vexpress_aemv8a_juno_defconfig
index c70851f..5af9f58 100644
--- a/configs/vexpress_aemv8a_juno_defconfig
+++ b/configs/vexpress_aemv8a_juno_defconfig
@@ -24,3 +24,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_FAT=y
 CONFIG_DM=y
 CONFIG_OF_LIBFDT=y
+CONFIG_BOOTP_VCI_STRING="U-Boot.armv8.vexpress_aemv8a"
diff --git a/configs/vexpress_aemv8a_semi_defconfig 
b/configs/vexpress_aemv8a_semi_defconfig
index b0a2f67..379dff2 100644
--- a/configs/vexpress_aemv8a_semi_defconfig
+++ b/configs/vexpress_aemv8a_semi_defconfig
@@ -24,3 +24,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_FAT=y
 CONFIG_DM=y
 CONFIG_OF_LIBFDT=y
+CONFIG_BOOTP_VCI_STRING="U-Boot.armv8.vexpress_aemv8a"
diff --git a/configs/vexpress_ca15_tc2_defconfig 
b/configs/vexpress_ca15_tc2_defconfig
index 2f141dd..c39faaa 100644
--- a/configs/vexpress_ca15_tc2_defconfig
+++ b/configs/vexpress_ca15_tc2_defconfig
@@ -24,3 +24,4 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_LIBFDT=y
+CONFIG_BOOTP_VCI_STRING="U-Boot.armv7.vexpress_ca15x2_tc2"
diff --git a/configs/vexpress_ca5x2_defconfig b/configs/vexpress_ca5x2_defconfig
index c495ee5..e71d45e 100644
--- a/configs/vexpress_ca5x2_defconfig
+++ b/configs/vexpress_ca5x2_defconfig
@@ -24,3 +24,4 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_LIBFDT=y
+CONFIG_BOOTP_VCI_STRING="U-Boot.armv7.vexpress_ca5x2"
diff --git a/configs/vexpress_ca9x4_defconfig b/configs/vexpress_ca9x4_defconfig
index fcd6e26..20100a3 100644
--- a/configs/vexpress_ca9x4_defconfig
+++ b/configs/vexpress_ca9x4_defconfig
@@ -24,3 +24,4 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_LIBFDT=y
+CONFIG_BOOTP_VCI_STRING="U-Boot.armv7.vexpress_ca9x4"
diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h
index 766a212..dfc2cbc 100644
--- a/include/config_distro_defaults.h
+++ b/include/config_distro_defaults.h
@@ -20,27 +20,6 @@
 #define CONFIG_BOOTP_PXE
 #define CONFIG_BOOTP_SUBNETMASK
 
-#if defined(__arm__) || defined(__aarch64__)
-#define CONFIG_BOOTP_PXE_CLIENTARCH 0x100
-#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__)
-#if !defined(CONFIG_BOOTP_VCI_STRING)
-#define CONFIG_BOOTP_VCI_STRING   

Re: [U-Boot] [PATCH 0/6] arm64: Pine64 fixes and updates

[André Przywara]

On 04/05/16 23:15, Peter Robinson wrote:
> On Wed, May 4, 2016 at 11:05 PM, André Przywara  
> wrote:
>> On 04/05/16 22:53, Peter Robinson wrote:
>>> On Wed, May 4, 2016 at 10:15 PM, Andre Przywara  
>>> wrote:
 This series improves the Pine64 support.
 The first patch fixes a build break, see details in the commit message.
 Patch 2/6 reverts a no longer needed memory reservation, as the firmware
 bits that used to live in DRAM now can reside in SRAM.
 To allow U-Boot to be easily loaded by Allwinner's boot0 loader, patch
 3/6 reserves some space at the beginning of the image to (optionally)
 fit in a header required by boot0.
 Patch 4/6 adjusts the default load addresses in the environment to
 meet the arm64 requirements (especially the kernel load address).
 The device tree files included in the original Pine64 commit are
 outdated, so patch 5/6 replaces some with more mature versions and also
 adjusts the naming to match other sunxi boards.
 The final patch renames the _defconfig file to get rid of the _plus_
 insert.

 Please review, comment and apply, if possible.
>>>
>>> I'll test this tomorrow on my 1Gb Plus board,
>>
>> Thanks!
>>
>>> it would be good to have
>>> a README.pine64 with details about where to get the ATF firmware from
>>> and how to use it with this u-boot to get a booted device something
>>> similar to README.odroid
>>
>> Yes, I am on the documentation.
> 
> Cool, btw what's the redistribution license on the ATF firmware, is it
> redistributable by distributions (like other firmware),

ATF is the "ARM Trusted Firmware", which is a proper OpenSource project
under a BSD license. The home is on github [1].
In the moment I am working with an Allwinner provided codebase and
having fixes on top, but I removed quite some useless code already and
started with a proper upstream port.
I will push the repository onto my github fork [2] (once I manage to get
off mail and IRC ;-)

> is it usable on all devices with a AllWinner A64?

I would think so. A good part of the code in there is about the cores
and the GIC: so pretty generic. In the moment all power management is on
a SoC level - but in the future we might drive the PMIC from ATF as
well, which would potentially differ between boards.

> Will it be needed with the proper SPL you mention below?

Yes, the most prominent feature that ATF provides on the Pine64 is the
PSCI service. ATF is actually the PSCI reference implementation, so it
does the right thing and is more advanced than what U-Boot provides, for
instance.
Also ATF cares about some errata fixups for various cores, some of them
can only be provided by firmware (in EL3).

So I think ATF should take over the actual firmware load that U-Boot
carried in the past for various boards as well.
For the Pine64 I would very much like U-Boot to be just a boot loader.

>> As we lack DRAM initialization at the moment, I use a tool to assemble
>> all the firmware bits together with boot0 into an image.
>> This should supersede Alex' pine64_image tool.
> 
> OK, I've been using Alex's tool to date.
> 
>> Shall this tool (written in C) also be part of U-Boot, say in the tools
>> directory? Or is this better pushed into the sunxi-tools repository?
>> Eventually with a proper SPL we will not need it anymore, so I refrained
>> from pushing it into U-Boot for now.
> 
> TBH I've no idea what's best here, I suppose it depends on timeframes,
> it might just be useful to put it in a git repo somewhere and
> reference it in a readme, once there's patches that have the proper
> SPL update the readme as part of it.

Yes, expect it to appear on [3] anytime soon.

Cheers,
Andre.

[1] https://github.com/ARM-software/arm-trusted-firmware
[2] https://github.com/apritzel/arm-trusted-firmware
[3] https://github.com/apritzel/pine64

>>>
 P.S. tools/buildman/README was TL;DR, so I just tested Pine64 and
 Bananapi compilation. If someone with a working buildman setup could
 test this for build regressions, I'd be grateful.

 Andre Przywara (6):
   arm/arm64: Move barrier instructions into separate header
   Revert "sunxi: Reserve ATF memory space on A64"
   arm64: sunxi: reserve space for boot0 header
   arm64: sunxi: adjust default load addresses
   arm64: Pine64: update FDT files
   Pine64: rename defconfig

  arch/arm/cpu/armv8/start.S |   3 +
  arch/arm/dts/Makefile  |   3 +-
  arch/arm/dts/a64.dtsi  | 564 
 --
  arch/arm/dts/pine64.dts|  62 ---
  arch/arm/dts/pine64_common.dtsi|  76 
  arch/arm/dts/pine64_plus.dts   |  63 ---
  arch/arm/dts/sun50i-a64-pine64-common.dtsi |  80 
  arch/arm/dts/sun50i-a64-pine64-plus.dts|  59 +++
  arch/arm/dts/sun50i-a64-pine64.dts |  58 +++

Re: [U-Boot] [PATCH] malloc: improve memalign fragmentation fix

[Stephen Warren]

On 04/25/2016 03:55 PM, Stephen Warren wrote:

From: Stephen Warren 

Commit 4f144a416469 "malloc: work around some memalign fragmentation
issues" enhanced memalign() so that it can succeed in more cases where
heap fragmentation is present. However, it did not solve as many cases
as it could. This patch enhances the code to cover more cases.

The alignment code works by allocating more space than the user requests,
then adjusting the returned pointer to achieve alignment. In general, one
must allocate "alignment" bytes more than the user requested in order to
guarantee that alignment is possible. This is what the original code does.
The previous enhancement attempted a second allocation if the padded
allocation failed, and succeeded if that allocation just happened to be
aligned; a fluke that happened often in practice. There are still cases
where this could fail, yet where it is still possible to honor the user's
allocation request. In particular, if the heap contains a free region that
is large enough for the user's request, and for leading padding to ensure
alignment, but has no or little space for any trailing padding. In this
case, we can make a third(!) allocation attempt after calculating exactly
the size of the leading padding required to achieve alignment, which is
the minimal over-allocation needed for the overall memalign() operation to
succeed if the third and second allocations end up at the same location.

This patch isn't checkpatch-clean, since it conforms to the existing
coding style in dlmalloc.c, which is different to the rest of U-Boot.


Tom, what do you think of this approach? Is it something we can go with? 
If so, it'd be great to apply is ASAP to clean up all the test results 
in my automated system.


An alternative might be to enhance mALLOc() to know how to search for 
aligned chunks, thus avoiding any retries. I avoided that to prevent the 
code diverging too much from the original dlmalloc.c that was imported 
from elsewhere, and keep the patch minimal. Still, that might be the 
right long-term answer.

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

Re: [U-Boot] [PATCH V2 1/2] mtd: cqspi: Simplify indirect write code

[Pavel Machek]

Hi!

> The indirect write code is buggy pile of nastiness which fails horribly
> when the system runs fast enough to saturate the controller. The failure
> results in some pages (256B) not being written to the flash. This can be
> observed on systems which run with Dcache enabled and L2 cache enabled,
> like the Altera SoCFPGA.
> 
> This patch replaces the whole unmaintainable indirect write implementation
> with the one from upcoming Linux CQSPI driver, which went through multiple
> rounds of thorough review and testing. While this makes the patch look
> terrifying and violates all best-practices of software development, all
> the patch does is it plucks out duplicate ad-hoc code distributed across
> the driver and replaces it with more compact code doing exactly the same
> thing.

Ok, sorry, I still don't understand the changelog.

First, it describes the bug with L2 cache enabled, but then it says
that "all the patch does .. doing exactly the same thing".

So I assume it does not do the same thing, but replaces duplicated
code in u-boot with working code from Linux?

Thanks for doing this,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] dm: core: allow drivers to refuse to bind

[Stephen Warren]

On 04/19/2016 04:19 PM, Stephen Warren wrote:

From: Stephen Warren 

In some cases, drivers may not want to bind to a device. Allow bind() to
return -ENODEV in this case, and don't treat this as an error. This can
be useful in situations where some information source other than the DT
node's main status property indicates whether the device should be
enabled, for example other DT properties might indicate this, or the
driver might query non-DT sources such as system fuses or a version number
register.


Simon, this series is assigned to you in patchwork. Are you the right 
person to apply it?

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

Re: [U-Boot] [PATCH V2] buildman: allow more incremental building

[Tom Rini]

On Wed, May 04, 2016 at 12:55:15PM -0600, Stephen Warren wrote:
> On 04/11/2016 10:48 AM, Stephen Warren wrote:
> >From: Stephen Warren 
> >
> >One use-case for buildman is to continually run it interactively after
> >each small step in a large refactoring operation. This gives more
> >immediate feedback than making a number of commits and then going back and
> >testing them. For this to work well, buildman needs to be extremely fast.
> >At present, a couple issues prevent it being as fast as it could be:
> >
> >1) Each time buildman runs "make %_defconfig", it runs "make mrproper"
> >first. This throws away all previous build results, requiring a
> >from-scratch build. Optionally avoiding this would speed up the build, at
> >the cost of potentially causing or missing some build issues.
> >
> >2) A build tree is created per thread rather than per board. When a thread
> >switches between building different boards, this often causes many files
> >to be rebuilt due to changing config options. Using a separate build tree
> >for each board would avoid this. This does put more strain on the system's
> >disk cache, but it is worth it on my system at least.
> >
> >This commit adds two command-line options to implement the changes
> >described above; -I ("--incremental") turns of "make mrproper" and -P
> >("--per-board-out-dir") creats a build directory per board rather than per
> >thread.
> >
> >Tested:
> >
> > ./tools/buildman/buildman.py tegra
> > ./tools/buildman/buildman.py -I -P tegra
> > ./tools/buildman/buildman.py -b tegra_dev tegra
> > ./tools/buildman/buildman.py -b tegra_dev -I -P tegra
> >
> >... each once after deleting the buildman result/work directory, and once
> >"incrementally" after a previous identical invocation.
> >
> >Signed-off-by: Stephen Warren 
> >Reviewed-by: Tom Rini 
> >Acked-by: Simon Glass  # v1
> >Tested-by: Simon Glass  # v1
> 
> Tom, it's been over 3 weeks since I posted this, and Simon ack'd v2.

Well, the release is next week.  Simon didn't include it in a PR since
v2 was posted so I assume he was figuring on waiting until next release
for it.  Does this really need to come in before the release or can it
wait?

-- 
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] pci: tegra: fix DM conversion issues on Tegra20

[Stephen Warren]

On 04/20/2016 03:46 PM, Stephen Warren wrote:

From: Stephen Warren 

Tegra20's PCIe controller has a couple of quirks. There are workarounds in
the driver for these, but they don't work after the DM conversion:

1) The PCI_CLASS value is wrong in HW.

This is worked around in pci_tegra_read_config() by patching up the value
read from that register. Pre-DM, the PCIe core always read this via a
16-bit access to the 16-bit offset 0xa. With DM, 32-bit accesses are used,
so we need to check for offset 0x8 instead. Mask the offset value back to
32-bit alignment to make this work in all cases.

2) Accessing devices other than dev 1 causes a data abort.

Pre-DM, this was worked around in pci_skip_dev(), which the PCIe core code
called during enumeration while iterating over a bus. The DM PCIe core
doesn't use this function. Instead, enhance tegra_pcie_conf_address() to
validate the bdf being accessed, and refuse to access invalid devices.
Since pci_skip_dev() isn't used, delete it.

I've also validated that both these WARs are only needed for Tegra20, by
testing on Tegra30/Cardhu and Tegra124/Jetson TKx. So, compile them in
conditionally.

Fixes: e81ca88451cf ("dm: tegra: pci: Convert tegra boards to driver model for 
PCI")
Signed-off-by: Stephen Warren 


TomW, I'd like to make sure this one gets into the upcoming release, 
since it's a functional bug-fix.

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

Re: [U-Boot] [PATCH] ARM: tegra: import latest Jetson TK1 spreadsheet

[Stephen Warren]

On 04/21/2016 04:03 PM, Stephen Warren wrote:

From: Stephen Warren 

This imports v11 of "Jetson TK1 Development Platform Pin Mux" from
https://developer.nvidia.com/embedded/downloads.

The new version defines the mux option for the MIPI pad ctrl selection.
The OWR pin no longer has an entry in the configuration table because
the only mux option it support is OWR, that feature isn't supported, and
hence can't conflict with any other pin. This pin can only usefully be
used as a GPIO.


TomW, could this please also be applied in time for the upcoming release?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] buildman: allow more incremental building

[Stephen Warren]

On 05/04/2016 12:58 PM, Tom Rini wrote:

On Wed, May 04, 2016 at 12:55:15PM -0600, Stephen Warren wrote:

On 04/11/2016 10:48 AM, Stephen Warren wrote:

From: Stephen Warren 

One use-case for buildman is to continually run it interactively after
each small step in a large refactoring operation. This gives more
immediate feedback than making a number of commits and then going back and
testing them. For this to work well, buildman needs to be extremely fast.
At present, a couple issues prevent it being as fast as it could be:

1) Each time buildman runs "make %_defconfig", it runs "make mrproper"
first. This throws away all previous build results, requiring a
from-scratch build. Optionally avoiding this would speed up the build, at
the cost of potentially causing or missing some build issues.

2) A build tree is created per thread rather than per board. When a thread
switches between building different boards, this often causes many files
to be rebuilt due to changing config options. Using a separate build tree
for each board would avoid this. This does put more strain on the system's
disk cache, but it is worth it on my system at least.

This commit adds two command-line options to implement the changes
described above; -I ("--incremental") turns of "make mrproper" and -P
("--per-board-out-dir") creats a build directory per board rather than per
thread.

Tested:

 ./tools/buildman/buildman.py tegra
 ./tools/buildman/buildman.py -I -P tegra
 ./tools/buildman/buildman.py -b tegra_dev tegra
 ./tools/buildman/buildman.py -b tegra_dev -I -P tegra

... each once after deleting the buildman result/work directory, and once
"incrementally" after a previous identical invocation.

Signed-off-by: Stephen Warren 
Reviewed-by: Tom Rini 
Acked-by: Simon Glass  # v1
Tested-by: Simon Glass  # v1


Tom, it's been over 3 weeks since I posted this, and Simon ack'd v2.


Well, the release is next week.  Simon didn't include it in a PR since
v2 was posted so I assume he was figuring on waiting until next release
for it.  Does this really need to come in before the release or can it
wait?


I suppose it isn't critical to the functionality of the release, so from 
that perspective it can wait.


I will point out that the patch was first posted over 5 weeks ago, 
within the merge window, and the only revision was the addition of some 
README text, so I'd be disappointed if it took another 3 weeks to get 
applied.

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

Re: [U-Boot] [PATCH V2 1/2] mtd: cqspi: Simplify indirect write code

[Marek Vasut]

On 05/04/2016 09:04 PM, Pavel Machek wrote:
> Hi!
> 
>> The indirect write code is buggy pile of nastiness which fails horribly
>> when the system runs fast enough to saturate the controller. The failure
>> results in some pages (256B) not being written to the flash. This can be
>> observed on systems which run with Dcache enabled and L2 cache enabled,
>> like the Altera SoCFPGA.
>>
>> This patch replaces the whole unmaintainable indirect write implementation
>> with the one from upcoming Linux CQSPI driver, which went through multiple
>> rounds of thorough review and testing. While this makes the patch look
>> terrifying and violates all best-practices of software development, all
>> the patch does is it plucks out duplicate ad-hoc code distributed across
>> the driver and replaces it with more compact code doing exactly the same
>> thing.
> 
> Ok, sorry, I still don't understand the changelog.
> 
> First, it describes the bug with L2 cache enabled, but then it says
> that "all the patch does .. doing exactly the same thing".
> 
> So I assume it does not do the same thing, but replaces duplicated
> code in u-boot with working code from Linux?

Ah right, the linux code also does FIFO level checking, so it doesn't
overflow during the writes.

> Thanks for doing this,
>   Pavel
>   
> 


-- 
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] dm: allow setting driver_data before/during bind

[Stephen Warren]

On 05/01/2016 01:27 PM, Simon Glass wrote:

Hi Stephen,

On 28 April 2016 at 17:08, Stephen Warren  wrote:

From: Stephen Warren 

This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.

Signed-off-by: Stephen Warren 
---
  drivers/core/device.c| 7 ---
  drivers/core/lists.c | 6 +++---
  drivers/gpio/dwapb_gpio.c| 2 +-
  drivers/gpio/s5p_gpio.c  | 2 +-
  drivers/gpio/sunxi_gpio.c| 2 +-
  drivers/gpio/tegra_gpio.c| 2 +-
  drivers/mtd/spi/sandbox.c| 2 +-
  drivers/net/mvpp2.c  | 3 ++-
  drivers/pci/pci-uclass.c | 5 ++---
  drivers/power/pmic/pmic-uclass.c | 2 +-
  drivers/usb/host/usb-uclass.c| 5 ++---
  include/dm/device-internal.h | 5 +++--
  12 files changed, 22 insertions(+), 21 deletions(-)


I'm not sure this extra parameter carries its weight:

- most callers just pass 0


The same is true of the existing platdata field in many cases.


- the field is supposed to be set up by device tree and probing tables, not code


While the existence of this new parameter does allow arbitrary code to 
set the parameter, this patch only actually sets the parameter in the 
case where DT and probing tables have determined that value.



- bind() methods should not care about the driver data (they are not
allowed to touch hardware), so setting it later is fine


Not touching HW is fine, but the driver data can still feed into purely 
SW decisions that bind makes. More details below.



- you can already pass platform data to the driver which is the
preferred communication method from a parent to its children


I don't believe this is possible for devices instantiated from DT is it? 
In that case, platform data is always NULL:


int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
   struct udevice **devp)
...
ret = device_bind(parent, entry, name, NULL, id->data,
  offset, );

(That quoted code is with this patch applied, and the NULL value is the 
platform data parameter.)



Also it's not clear from your Tegra 186 GPIO patch where you are using this.


Here's the relevant part from the Tegra186 GPIO driver patch I posted:


+static int tegra186_gpio_bind(struct udevice *parent)
+{
+   struct tegra186_gpio_platdata *parent_plat = parent->platdata;
+   struct tegra186_gpio_ctlr_data *ctlr_data =
+   (struct tegra186_gpio_ctlr_data *)parent->driver_data;

...

+   /* If this is a child device, there is nothing to do here */
+   if (parent_plat)
+   return 0;

...

+   for (port = 0; port < ctlr_data->port_count; port++) {

...

+   plat->name = ctlr_data->ports[port].name;
+   plat->regs = &(regs[ctlr_data->ports[port].offset / 4]);


The data is used to determine how many child devices (one per port) to 
create, and the name and register offset of each one. This is modelled 
after the logic in the previous Tegra GPIO driver that you wrote, with 
the unfortunate modification that the register layout is more 
"interesting" on Tegra186, and so we can't determine the number of and 
parameters for the child devices purely algorithmically, since the 
register layout is decidedly non-linear.


I suppose an alternative would be to create separate U_BOOT_DRIVER()s 
for each compatible value with different register layout, and then have 
the bind() for each of those call into some common implementation with a 
hard-coded parameter. Still, it seems like the usage in the current code 
is exactly what udevice_id.data is for; to avoid having to implement 
separate functions that do that.


Perhaps the creation of the child devices could happen in probe() rather 
than bind()? I imagine there's some reason this wouldn't work (such as 
this causing the devices to be created too late to be referenced by 
other drivers?) or you would have done this in the existing Tegra GPIO 
driver.

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

Re: [U-Boot] [PATCH V2] buildman: allow more incremental building

[Stephen Warren]

On 04/11/2016 10:48 AM, Stephen Warren wrote:

From: Stephen Warren 

One use-case for buildman is to continually run it interactively after
each small step in a large refactoring operation. This gives more
immediate feedback than making a number of commits and then going back and
testing them. For this to work well, buildman needs to be extremely fast.
At present, a couple issues prevent it being as fast as it could be:

1) Each time buildman runs "make %_defconfig", it runs "make mrproper"
first. This throws away all previous build results, requiring a
from-scratch build. Optionally avoiding this would speed up the build, at
the cost of potentially causing or missing some build issues.

2) A build tree is created per thread rather than per board. When a thread
switches between building different boards, this often causes many files
to be rebuilt due to changing config options. Using a separate build tree
for each board would avoid this. This does put more strain on the system's
disk cache, but it is worth it on my system at least.

This commit adds two command-line options to implement the changes
described above; -I ("--incremental") turns of "make mrproper" and -P
("--per-board-out-dir") creats a build directory per board rather than per
thread.

Tested:

 ./tools/buildman/buildman.py tegra
 ./tools/buildman/buildman.py -I -P tegra
 ./tools/buildman/buildman.py -b tegra_dev tegra
 ./tools/buildman/buildman.py -b tegra_dev -I -P tegra

... each once after deleting the buildman result/work directory, and once
"incrementally" after a previous identical invocation.

Signed-off-by: Stephen Warren 
Reviewed-by: Tom Rini 
Acked-by: Simon Glass  # v1
Tested-by: Simon Glass  # v1


Tom, it's been over 3 weeks since I posted this, and Simon ack'd v2.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/3] spl: fit: Fix the number of bytes read when reading fdt from fit

[Michal Simek]

On 4.5.2016 14:04, Lokesh Vutla wrote:
> sectors field is not being updated when reading fdt from fit image. Because of
> this size_of(u-boot.bin) is being read when reading fdt. Fixing it by updating
> the sectors field properly.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  common/spl/spl_fit.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 1a5c027..b1cfa97 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -176,6 +176,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong 
> sector, void *fit)
>*/
>   dst = load_ptr + data_size;
>   fdt_offset += base_offset;
> + sectors = (fdt_len + info->bl_len - 1) / info->bl_len;
>   count = info->read(info, sector + fdt_offset / info->bl_len, sectors,
>  dst);
>   debug("fit read %x sectors to %x, dst %p, data_offset %x\n",
> 

Tested-by: Michal Simek 

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

[U-Boot] [PATCH 7/7] armv8: ls1012a: Add support of ls1012ardb board

[Prabhakar Kushwaha]

QorIQ LS1012A Reference Design System (LS1012ARDB) is a high-performance
development platform, with a complete debugging environment.
The LS1012ARDB board supports the QorIQ LS1012A processor and is
optimized to support the high-bandwidth DDR3L memory and
a full complement of high-speed SerDes ports.

Signed-off-by: Calvin Johnson 
Signed-off-by: Pratiyush Mohan Srivastava 
Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/Kconfig|  10 ++
 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/fsl-ls1012a-rdb.dts|  16 +++
 arch/arm/dts/fsl-ls1012a-rdb.dtsi   |  39 ++
 board/freescale/ls1012ardb/Kconfig  |  15 +++
 board/freescale/ls1012ardb/MAINTAINERS  |   6 +
 board/freescale/ls1012ardb/Makefile |   7 ++
 board/freescale/ls1012ardb/README   |  89 ++
 board/freescale/ls1012ardb/ls1012ardb.c | 210 
 configs/ls1012ardb_qspi_defconfig   |  32 +
 include/configs/ls1012ardb.h|  59 +
 11 files changed, 485 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dts
 create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dtsi
 create mode 100644 board/freescale/ls1012ardb/Kconfig
 create mode 100644 board/freescale/ls1012ardb/MAINTAINERS
 create mode 100644 board/freescale/ls1012ardb/Makefile
 create mode 100644 board/freescale/ls1012ardb/README
 create mode 100644 board/freescale/ls1012ardb/ls1012ardb.c
 create mode 100644 configs/ls1012ardb_qspi_defconfig
 create mode 100644 include/configs/ls1012ardb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2540045..31dfac2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -682,6 +682,15 @@ config TARGET_LS1012AQDS
  development platform that supports the QorIQ LS1012A
  Layerscape Architecture processor.
 
+config TARGET_LS1012ARDB
+   bool "Support ls1012ardb"
+   select ARM64
+   help
+ Support for Freescale LS1012ARDB platform.
+ The LS1012A Reference design board (RDB) is a high-performance
+ development platform that supports the QorIQ LS1012A
+ Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
bool "Support ls1021aqds"
select CPU_V7
@@ -841,6 +850,7 @@ source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
 source "board/freescale/ls1043ardb/Kconfig"
 source "board/freescale/ls1012aqds/Kconfig"
+source "board/freescale/ls1012ardb/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx25pdk/Kconfig"
 source "board/freescale/mx28evk/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b26870a..9324d82 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -114,7 +114,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-ls1012a-qds.dtb
+   fsl-ls1012a-qds.dtb \
+   fsl-ls1012a-rdb.dtb
 
 dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb
 
diff --git a/arch/arm/dts/fsl-ls1012a-rdb.dts b/arch/arm/dts/fsl-ls1012a-rdb.dts
new file mode 100644
index 000..4ec9786
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-rdb.dts
@@ -0,0 +1,16 @@
+/*
+ * Device Tree file for Freescale Layerscape-1012A family SoC.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include "fsl-ls1012a-rdb.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   };
+};
diff --git a/arch/arm/dts/fsl-ls1012a-rdb.dtsi 
b/arch/arm/dts/fsl-ls1012a-rdb.dtsi
new file mode 100644
index 000..71aba78
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-rdb.dtsi
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1012A family SoC.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * 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.
+ */
+
+/include/ "fsl-ls1012a.dtsi"
+
+/ {
+   model = "LS1012A RDB Board";
+   aliases {
+   spi0 = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   qflash0: s25fl128s@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/board/freescale/ls1012ardb/Kconfig 
b/board/freescale/ls1012ardb/Kconfig
new file mode 100644
index 000..3f67c28
--- /dev/null
+++ b/board/freescale/ls1012ardb/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_LS1012ARDB
+
+config SYS_BOARD
+   default "ls1012ardb"
+
+config SYS_VENDOR
+ 

[U-Boot] [PATCH 2/7] armv8: fsl-layerscape: Avoid LS1043A specifc defines

[Prabhakar Kushwaha]

Other than LS1043A, LS1012A also Chassis Gen2 Architecture compliant.

So Avoid LS1043A specific defines in arch/arm

Signed-off-by: Prabhakar Kushwaha 
---
 arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 2 +-
 arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 0cb0100..41f9547 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -222,7 +222,7 @@ int sata_init(void)
 }
 #endif
 
-#elif defined(CONFIG_LS1043A)
+#elif defined(CONFIG_FSL_LSCH2)
 #ifdef CONFIG_SCSI_AHCI_PLAT
 int sata_init(void)
 {
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h 
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
index f71c2c1..c4fb7c9 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
@@ -55,7 +55,7 @@ enum srds {
FSL_SRDS_1  = 0,
FSL_SRDS_2  = 1,
 };
-#elif defined(CONFIG_LS1043A)
+#elif defined(CONFIG_FSL_LSCH2)
 enum srds_prtcl {
NONE = 0,
PCIE1,
-- 
1.9.1


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

Re: [U-Boot] [PATCH V2] buildman: allow more incremental building

[Tom Rini]

On Wed, May 04, 2016 at 01:30:47PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 4 May 2016 at 13:09, Stephen Warren  wrote:
> > On 05/04/2016 12:58 PM, Tom Rini wrote:
> >>
> >> On Wed, May 04, 2016 at 12:55:15PM -0600, Stephen Warren wrote:
> >>>
> >>> On 04/11/2016 10:48 AM, Stephen Warren wrote:
> 
>  From: Stephen Warren 
> 
>  One use-case for buildman is to continually run it interactively after
>  each small step in a large refactoring operation. This gives more
>  immediate feedback than making a number of commits and then going back
>  and
>  testing them. For this to work well, buildman needs to be extremely
>  fast.
>  At present, a couple issues prevent it being as fast as it could be:
> 
>  1) Each time buildman runs "make %_defconfig", it runs "make mrproper"
>  first. This throws away all previous build results, requiring a
>  from-scratch build. Optionally avoiding this would speed up the build,
>  at
>  the cost of potentially causing or missing some build issues.
> 
>  2) A build tree is created per thread rather than per board. When a
>  thread
>  switches between building different boards, this often causes many files
>  to be rebuilt due to changing config options. Using a separate build
>  tree
>  for each board would avoid this. This does put more strain on the
>  system's
>  disk cache, but it is worth it on my system at least.
> 
>  This commit adds two command-line options to implement the changes
>  described above; -I ("--incremental") turns of "make mrproper" and -P
>  ("--per-board-out-dir") creats a build directory per board rather than
>  per
>  thread.
> 
>  Tested:
> 
>   ./tools/buildman/buildman.py tegra
>   ./tools/buildman/buildman.py -I -P tegra
>   ./tools/buildman/buildman.py -b tegra_dev tegra
>   ./tools/buildman/buildman.py -b tegra_dev -I -P tegra
> 
>  ... each once after deleting the buildman result/work directory, and
>  once
>  "incrementally" after a previous identical invocation.
> 
>  Signed-off-by: Stephen Warren 
>  Reviewed-by: Tom Rini 
>  Acked-by: Simon Glass  # v1
>  Tested-by: Simon Glass  # v1
> >>>
> >>>
> >>> Tom, it's been over 3 weeks since I posted this, and Simon ack'd v2.
> >>
> >>
> >> Well, the release is next week.  Simon didn't include it in a PR since
> >> v2 was posted so I assume he was figuring on waiting until next release
> >> for it.  Does this really need to come in before the release or can it
> >> wait?
> 
> No I was just expecting you to pick it up as it is in your queue :-)

Welp, there you go then. pah, sorry, my fault.

-- 
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] pci: tegra: fix DM conversion issues on Tegra20

[Tom Warren]

I'll add it to u-boot-tegra/master for the next PR.

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, May 04, 2016 12:00 PM
> To: Tom Warren 
> Cc: u-boot@lists.denx.de; Simon Glass ; Stephen Warren
> 
> Subject: Re: [U-Boot] [PATCH] pci: tegra: fix DM conversion issues on Tegra20
> 
> On 04/20/2016 03:46 PM, Stephen Warren wrote:
> > From: Stephen Warren 
> >
> > Tegra20's PCIe controller has a couple of quirks. There are
> > workarounds in the driver for these, but they don't work after the DM
> conversion:
> >
> > 1) The PCI_CLASS value is wrong in HW.
> >
> > This is worked around in pci_tegra_read_config() by patching up the
> > value read from that register. Pre-DM, the PCIe core always read this
> > via a 16-bit access to the 16-bit offset 0xa. With DM, 32-bit accesses
> > are used, so we need to check for offset 0x8 instead. Mask the offset
> > value back to 32-bit alignment to make this work in all cases.
> >
> > 2) Accessing devices other than dev 1 causes a data abort.
> >
> > Pre-DM, this was worked around in pci_skip_dev(), which the PCIe core
> > code called during enumeration while iterating over a bus. The DM PCIe
> > core doesn't use this function. Instead, enhance
> > tegra_pcie_conf_address() to validate the bdf being accessed, and refuse to
> access invalid devices.
> > Since pci_skip_dev() isn't used, delete it.
> >
> > I've also validated that both these WARs are only needed for Tegra20,
> > by testing on Tegra30/Cardhu and Tegra124/Jetson TKx. So, compile them
> > in conditionally.
> >
> > Fixes: e81ca88451cf ("dm: tegra: pci: Convert tegra boards to driver
> > model for PCI")
> > Signed-off-by: Stephen Warren 
> 
> TomW, I'd like to make sure this one gets into the upcoming release, since 
> it's a
> functional bug-fix.
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: tegra: import latest Jetson TK1 spreadsheet

[Tom Warren]

I'll take a look. Thanks.

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, May 04, 2016 12:01 PM
> To: Tom Warren 
> Cc: u-boot@lists.denx.de; Simon Glass ; Stephen Warren
> 
> Subject: Re: [U-Boot] [PATCH] ARM: tegra: import latest Jetson TK1 spreadsheet
> 
> On 04/21/2016 04:03 PM, Stephen Warren wrote:
> > From: Stephen Warren 
> >
> > This imports v11 of "Jetson TK1 Development Platform Pin Mux" from
> > https://developer.nvidia.com/embedded/downloads.
> >
> > The new version defines the mux option for the MIPI pad ctrl selection.
> > The OWR pin no longer has an entry in the configuration table because
> > the only mux option it support is OWR, that feature isn't supported,
> > and hence can't conflict with any other pin. This pin can only
> > usefully be used as a GPIO.
> 
> TomW, could this please also be applied in time for the upcoming release?
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] buildman: allow more incremental building

[Simon Glass]

On 4 May 2016 at 14:27, Tom Rini  wrote:
> On Wed, May 04, 2016 at 01:30:47PM -0600, Simon Glass wrote:
>> Hi Tom,
>>
>> On 4 May 2016 at 13:09, Stephen Warren  wrote:
>> > On 05/04/2016 12:58 PM, Tom Rini wrote:
>> >>
>> >> On Wed, May 04, 2016 at 12:55:15PM -0600, Stephen Warren wrote:
>> >>>
>> >>> On 04/11/2016 10:48 AM, Stephen Warren wrote:
>> 
>>  From: Stephen Warren 
>> 
>>  One use-case for buildman is to continually run it interactively after
>>  each small step in a large refactoring operation. This gives more
>>  immediate feedback than making a number of commits and then going back
>>  and
>>  testing them. For this to work well, buildman needs to be extremely
>>  fast.
>>  At present, a couple issues prevent it being as fast as it could be:
>> 
>>  1) Each time buildman runs "make %_defconfig", it runs "make mrproper"
>>  first. This throws away all previous build results, requiring a
>>  from-scratch build. Optionally avoiding this would speed up the build,
>>  at
>>  the cost of potentially causing or missing some build issues.
>> 
>>  2) A build tree is created per thread rather than per board. When a
>>  thread
>>  switches between building different boards, this often causes many files
>>  to be rebuilt due to changing config options. Using a separate build
>>  tree
>>  for each board would avoid this. This does put more strain on the
>>  system's
>>  disk cache, but it is worth it on my system at least.
>> 
>>  This commit adds two command-line options to implement the changes
>>  described above; -I ("--incremental") turns of "make mrproper" and -P
>>  ("--per-board-out-dir") creats a build directory per board rather than
>>  per
>>  thread.
>> 
>>  Tested:
>> 
>>   ./tools/buildman/buildman.py tegra
>>   ./tools/buildman/buildman.py -I -P tegra
>>   ./tools/buildman/buildman.py -b tegra_dev tegra
>>   ./tools/buildman/buildman.py -b tegra_dev -I -P tegra
>> 
>>  ... each once after deleting the buildman result/work directory, and
>>  once
>>  "incrementally" after a previous identical invocation.
>> 
>>  Signed-off-by: Stephen Warren 
>>  Reviewed-by: Tom Rini 
>>  Acked-by: Simon Glass  # v1
>>  Tested-by: Simon Glass  # v1
>> >>>
>> >>>
>> >>> Tom, it's been over 3 weeks since I posted this, and Simon ack'd v2.
>> >>
>> >>
>> >> Well, the release is next week.  Simon didn't include it in a PR since
>> >> v2 was posted so I assume he was figuring on waiting until next release
>> >> for it.  Does this really need to come in before the release or can it
>> >> wait?
>>
>> No I was just expecting you to pick it up as it is in your queue :-)
>
> Welp, there you go then. pah, sorry, my fault.

No worries, I just grabbed it and will apply when the merge window opens.

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

Re: [U-Boot] [PATCH 1/2] dm: core: allow drivers to refuse to bind

[Stephen Warren]

On 05/04/2016 01:31 PM, Simon Glass wrote:

Hi Stephen,

On 4 May 2016 at 12:57, Stephen Warren  wrote:

On 04/19/2016 04:19 PM, Stephen Warren wrote:


From: Stephen Warren 

In some cases, drivers may not want to bind to a device. Allow bind() to
return -ENODEV in this case, and don't treat this as an error. This can
be useful in situations where some information source other than the DT
node's main status property indicates whether the device should be
enabled, for example other DT properties might indicate this, or the
driver might query non-DT sources such as system fuses or a version number
register.



Simon, this series is assigned to you in patchwork. Are you the right person
to apply it?


Yes. but not for this release, right?


Patch 2 in the series (which depends on this patch) fixes a bug for 
Tegra boards with LCD panels. Admittedly it appears to be only cosmetic 
(an error message is printed at boot), but "it's a bug" seems to satisfy 
the requirement to apply it for this release.

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

Re: [U-Boot] [PATCH 1/2] dm: core: allow drivers to refuse to bind

[Simon Glass]

+Tom Rini

Hi Stephen,

On 4 May 2016 at 13:46, Stephen Warren  wrote:
> On 05/04/2016 01:31 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 4 May 2016 at 12:57, Stephen Warren  wrote:
>>>
>>> On 04/19/2016 04:19 PM, Stephen Warren wrote:


 From: Stephen Warren 

 In some cases, drivers may not want to bind to a device. Allow bind() to
 return -ENODEV in this case, and don't treat this as an error. This can
 be useful in situations where some information source other than the DT
 node's main status property indicates whether the device should be
 enabled, for example other DT properties might indicate this, or the
 driver might query non-DT sources such as system fuses or a version
 number
 register.
>>>
>>>
>>>
>>> Simon, this series is assigned to you in patchwork. Are you the right
>>> person
>>> to apply it?
>>
>>
>> Yes. but not for this release, right?
>
>
> Patch 2 in the series (which depends on this patch) fixes a bug for Tegra
> boards with LCD panels. Admittedly it appears to be only cosmetic (an error
> message is printed at boot), but "it's a bug" seems to satisfy the
> requirement to apply it for this release.

Sorry, I didn't know that. Given the core nature of this patch I would
rather wait, and apply it next week. Let me know if you disagree.

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

Re: [U-Boot] [PATCH 6/6] Pine64: rename defconfig

[Peter Robinson]

On Wed, May 4, 2016 at 10:15 PM, Andre Przywara  wrote:
> Rename the defconfig file for the Pine64 from pine64_plus_defconfig to
> pine64_defconfig.
> The differences between the two versions (more RAM and a different
> Ethernet PHY) don't justify two board versions, so lets stick with the
> generic name and try to differentiate between the versions at runtime
> if this is needed later.
>
> Signed-off-by: Andre Przywara 
> ---
>  configs/pine64_defconfig  | 20 
>  configs/pine64_plus_defconfig | 20 
>  2 files changed, 20 insertions(+), 20 deletions(-)
>  create mode 100644 configs/pine64_defconfig
>  delete mode 100644 configs/pine64_plus_defconfig
>
> diff --git a/configs/pine64_defconfig b/configs/pine64_defconfig
> new file mode 100644
> index 000..0977334
> --- /dev/null
> +++ b/configs/pine64_defconfig
> @@ -0,0 +1,20 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_MACH_SUN50I=y
> +CONFIG_DRAM_CLK=672
> +CONFIG_DRAM_ZQ=3881915
> +# CONFIG_VIDEO is not set
> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"

If you're building a single u-boot for all variants of Pine64,
something which I'd prefer, I don't think we can just set a default
but rather need some logic to specify the DT name based on which board
is booting. This is done for example in the BeagleBone config to
detect the various variants of the BeagleBones.

Peter

> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> +CONFIG_HUSH_PARSER=y
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_MMC=y
> +# CONFIG_CMD_FPGA is not set
> +CONFIG_CMD_DHCP=y
> +CONFIG_CMD_MII=y
> +CONFIG_CMD_PING=y
> +CONFIG_CMD_EXT2=y
> +CONFIG_CMD_EXT4=y
> +CONFIG_CMD_FAT=y
> +CONFIG_CMD_FS_GENERIC=y
> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
> deleted file mode 100644
> index 0977334..000
> --- a/configs/pine64_plus_defconfig
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -CONFIG_ARM=y
> -CONFIG_ARCH_SUNXI=y
> -CONFIG_MACH_SUN50I=y
> -CONFIG_DRAM_CLK=672
> -CONFIG_DRAM_ZQ=3881915
> -# CONFIG_VIDEO is not set
> -CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
> -# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> -CONFIG_HUSH_PARSER=y
> -# CONFIG_CMD_IMLS is not set
> -# CONFIG_CMD_FLASH is not set
> -CONFIG_CMD_MMC=y
> -# CONFIG_CMD_FPGA is not set
> -CONFIG_CMD_DHCP=y
> -CONFIG_CMD_MII=y
> -CONFIG_CMD_PING=y
> -CONFIG_CMD_EXT2=y
> -CONFIG_CMD_EXT4=y
> -CONFIG_CMD_FAT=y
> -CONFIG_CMD_FS_GENERIC=y
> --
> 2.7.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/6] arm64: Pine64 fixes and updates

[Peter Robinson]

On Wed, May 4, 2016 at 10:15 PM, Andre Przywara  wrote:
> This series improves the Pine64 support.
> The first patch fixes a build break, see details in the commit message.
> Patch 2/6 reverts a no longer needed memory reservation, as the firmware
> bits that used to live in DRAM now can reside in SRAM.
> To allow U-Boot to be easily loaded by Allwinner's boot0 loader, patch
> 3/6 reserves some space at the beginning of the image to (optionally)
> fit in a header required by boot0.
> Patch 4/6 adjusts the default load addresses in the environment to
> meet the arm64 requirements (especially the kernel load address).
> The device tree files included in the original Pine64 commit are
> outdated, so patch 5/6 replaces some with more mature versions and also
> adjusts the naming to match other sunxi boards.
> The final patch renames the _defconfig file to get rid of the _plus_
> insert.
>
> Please review, comment and apply, if possible.

I'll test this tomorrow on my 1Gb Plus board, it would be good to have
a README.pine64 with details about where to get the ATF firmware from
and how to use it with this u-boot to get a booted device something
similar to README.odroid

Peter

> P.S. tools/buildman/README was TL;DR, so I just tested Pine64 and
> Bananapi compilation. If someone with a working buildman setup could
> test this for build regressions, I'd be grateful.
>
> Andre Przywara (6):
>   arm/arm64: Move barrier instructions into separate header
>   Revert "sunxi: Reserve ATF memory space on A64"
>   arm64: sunxi: reserve space for boot0 header
>   arm64: sunxi: adjust default load addresses
>   arm64: Pine64: update FDT files
>   Pine64: rename defconfig
>
>  arch/arm/cpu/armv8/start.S |   3 +
>  arch/arm/dts/Makefile  |   3 +-
>  arch/arm/dts/a64.dtsi  | 564 --
>  arch/arm/dts/pine64.dts|  62 ---
>  arch/arm/dts/pine64_common.dtsi|  76 
>  arch/arm/dts/pine64_plus.dts   |  63 ---
>  arch/arm/dts/sun50i-a64-pine64-common.dtsi |  80 
>  arch/arm/dts/sun50i-a64-pine64-plus.dts|  59 +++
>  arch/arm/dts/sun50i-a64-pine64.dts |  58 +++
>  arch/arm/dts/sun50i-a64.dtsi   | 624 
> +
>  arch/arm/include/asm/armv7.h   |  21 +-
>  arch/arm/include/asm/barriers.h|  44 ++
>  arch/arm/mach-sunxi/dram_helpers.c |   2 +-
>  board/sunxi/board.c|   9 -
>  configs/pine64_defconfig   |  20 +
>  configs/pine64_plus_defconfig  |  20 -
>  include/configs/sunxi-common.h |  18 +
>  17 files changed, 910 insertions(+), 816 deletions(-)
>  delete mode 100644 arch/arm/dts/a64.dtsi
>  delete mode 100644 arch/arm/dts/pine64.dts
>  delete mode 100644 arch/arm/dts/pine64_common.dtsi
>  delete mode 100644 arch/arm/dts/pine64_plus.dts
>  create mode 100644 arch/arm/dts/sun50i-a64-pine64-common.dtsi
>  create mode 100644 arch/arm/dts/sun50i-a64-pine64-plus.dts
>  create mode 100644 arch/arm/dts/sun50i-a64-pine64.dts
>  create mode 100644 arch/arm/dts/sun50i-a64.dtsi
>  create mode 100644 arch/arm/include/asm/barriers.h
>  create mode 100644 configs/pine64_defconfig
>  delete mode 100644 configs/pine64_plus_defconfig
>
> --
> 2.7.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/6] arm64: Pine64 fixes and updates

[André Przywara]

On 04/05/16 22:53, Peter Robinson wrote:
> On Wed, May 4, 2016 at 10:15 PM, Andre Przywara  
> wrote:
>> This series improves the Pine64 support.
>> The first patch fixes a build break, see details in the commit message.
>> Patch 2/6 reverts a no longer needed memory reservation, as the firmware
>> bits that used to live in DRAM now can reside in SRAM.
>> To allow U-Boot to be easily loaded by Allwinner's boot0 loader, patch
>> 3/6 reserves some space at the beginning of the image to (optionally)
>> fit in a header required by boot0.
>> Patch 4/6 adjusts the default load addresses in the environment to
>> meet the arm64 requirements (especially the kernel load address).
>> The device tree files included in the original Pine64 commit are
>> outdated, so patch 5/6 replaces some with more mature versions and also
>> adjusts the naming to match other sunxi boards.
>> The final patch renames the _defconfig file to get rid of the _plus_
>> insert.
>>
>> Please review, comment and apply, if possible.
> 
> I'll test this tomorrow on my 1Gb Plus board,

Thanks!

> it would be good to have
> a README.pine64 with details about where to get the ATF firmware from
> and how to use it with this u-boot to get a booted device something
> similar to README.odroid

Yes, I am on the documentation.
As we lack DRAM initialization at the moment, I use a tool to assemble
all the firmware bits together with boot0 into an image.
This should supersede Alex' pine64_image tool.
Shall this tool (written in C) also be part of U-Boot, say in the tools
directory? Or is this better pushed into the sunxi-tools repository?
Eventually with a proper SPL we will not need it anymore, so I refrained
from pushing it into U-Boot for now.

Cheers,
Andre.

> 
> Peter
> 
>> P.S. tools/buildman/README was TL;DR, so I just tested Pine64 and
>> Bananapi compilation. If someone with a working buildman setup could
>> test this for build regressions, I'd be grateful.
>>
>> Andre Przywara (6):
>>   arm/arm64: Move barrier instructions into separate header
>>   Revert "sunxi: Reserve ATF memory space on A64"
>>   arm64: sunxi: reserve space for boot0 header
>>   arm64: sunxi: adjust default load addresses
>>   arm64: Pine64: update FDT files
>>   Pine64: rename defconfig
>>
>>  arch/arm/cpu/armv8/start.S |   3 +
>>  arch/arm/dts/Makefile  |   3 +-
>>  arch/arm/dts/a64.dtsi  | 564 --
>>  arch/arm/dts/pine64.dts|  62 ---
>>  arch/arm/dts/pine64_common.dtsi|  76 
>>  arch/arm/dts/pine64_plus.dts   |  63 ---
>>  arch/arm/dts/sun50i-a64-pine64-common.dtsi |  80 
>>  arch/arm/dts/sun50i-a64-pine64-plus.dts|  59 +++
>>  arch/arm/dts/sun50i-a64-pine64.dts |  58 +++
>>  arch/arm/dts/sun50i-a64.dtsi   | 624 
>> +
>>  arch/arm/include/asm/armv7.h   |  21 +-
>>  arch/arm/include/asm/barriers.h|  44 ++
>>  arch/arm/mach-sunxi/dram_helpers.c |   2 +-
>>  board/sunxi/board.c|   9 -
>>  configs/pine64_defconfig   |  20 +
>>  configs/pine64_plus_defconfig  |  20 -
>>  include/configs/sunxi-common.h |  18 +
>>  17 files changed, 910 insertions(+), 816 deletions(-)
>>  delete mode 100644 arch/arm/dts/a64.dtsi
>>  delete mode 100644 arch/arm/dts/pine64.dts
>>  delete mode 100644 arch/arm/dts/pine64_common.dtsi
>>  delete mode 100644 arch/arm/dts/pine64_plus.dts
>>  create mode 100644 arch/arm/dts/sun50i-a64-pine64-common.dtsi
>>  create mode 100644 arch/arm/dts/sun50i-a64-pine64-plus.dts
>>  create mode 100644 arch/arm/dts/sun50i-a64-pine64.dts
>>  create mode 100644 arch/arm/dts/sun50i-a64.dtsi
>>  create mode 100644 arch/arm/include/asm/barriers.h
>>  create mode 100644 configs/pine64_defconfig
>>  delete mode 100644 configs/pine64_plus_defconfig
>>
>> --
>> 2.7.3
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
> 

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

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

[Tom Rini]

On Wed, May 04, 2016 at 02:36:41PM -0700, Tom Warren wrote:

> Tom,
> 
> Please pull u-boot-tegra/master into U-Boot/master. Thanks!
> 
> All tegra builds are OK (32-bit and 64-bit), and Stephen reports that tests
> of u-boot-tegra/master all pass.
> 
> The following changes since commit b38eaec53570821043c94ad44eabcb23747d9969:
> 
>   include/configs: Numerous typo fixes: "controler" -> "controller".
> (2016-05-03 21:36:13 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-tegra.git master
> 
> for you to fetch changes up to bbca7108db79076d3a9a9c112792d7c4608a665c:
> 
>   ARM: tegra: import latest Jetson TK1 spreadsheet (2016-05-04 13:31:04
> -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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