[U-Boot] bootefi regression from v2017.9: GRUB fails to see partitions on NXP LS1043A

[Mathew McBride]

Hi all,

We are testing EFI support on u-boot for our (Traverse) NXP LS1043 
boards, as being able to only maintain one bootloader codebase (u-boot) 
is very appealing to us.


So far it has worked well, but I have had trouble getting it to work 
under v2017.11-rc*. It works fine on v2017.09.


I've traced the issue to this commit:
95c5553ea268144056c4bafc318b9e8b5c096a6c efi_loader: refactor boot 
device and loaded_image handling


After this commit, GRUB is unable to see the partitions of any attached 
devices, yet alone its own memdisk.
(This is a grub binary which I've built with modules in the memdisk, in 
theory it can function without a storage device)


Before:

Device 0: Vendor: TOSHIBA Rev: 1.00 Prod: TransMemory
Type: Removable Hard Disk
Capacity: 7391.2 MB = 7.2 GB (15137280 x 512)
... is now current device
Scanning usb 0:1...
reading /dtb/fsl-ls1043a-rdb.dtb
23140 bytes read in 43 ms (525.4 KiB/s)
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
238592 bytes read in 153 ms (1.5 MiB/s)
## Starting EFI application at 8100 ...
Scanning disks on scsi...
Scanning disks on usb...
Scanning disks on mmc...
Card did not respond to voltage select!
mmc_init: -95, time 46
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 8 disks
Welcome to GRUB!

error: file `/boot/grub/arm64-efi/normal.mod' not found.
Entering rescue mode...
grub rescue> insmod fat
grub rescue> ls
(memdisk) (hd0) (hd0,gpt2) (hd0,gpt1)
grub rescue> ls (memdisk)/
boot/
grub rescue> ls (hd0,gpt1)/
grub/ vmlinuz-4.14.0-rc5-00018-g52569513daea 
System.map-4.14.0-rc5-00018-g52569513daea 
config-4.14.0-rc5-00018-g52569513daea efi/ dtb/



After:

reading efi/boot/bootaa64.efi
238592 bytes read in 153 ms (1.5 MiB/s)
## Starting EFI application at 8100 ...
Scanning disks on scsi...
Scanning disks on usb...
Scanning disks on mmc...
Card did not respond to voltage select!
mmc_init: -95, time 46
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 8 disks
Welcome to GRUB!

error: variable `root' isn't set.
Entering rescue mode...
grub rescue> ls
(hd0)

The tests above are on a LS1043ARDB (reference board), loading u-boot 
from NAND and booting GRUB from a USB drive.



I am not a EFI expert at all, but is there anything I can do to help 
debug/fix this?




Regards,
Matt


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

[U-Boot] [PATCH] armv8: update gd after relocate

[Kever Yang]

We need to update gd in assamble code after relocate,
this is a fix to:
adc421e arm: move gd handling outside of C code

Signed-off-by: Kever Yang 
---

 arch/arm/lib/crt0_64.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index 62fad45..2008b76 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -113,6 +113,8 @@ relocation_return:
 #endif /* !CONFIG_SPL_BUILD */
 #if defined(CONFIG_SPL_BUILD)
bl  spl_relocate_stack_gd   /* may return NULL */
+   /* set up gd here, outside any C code */
+   mov x18, x0
/*
 * Perform 'sp = (x0 != NULL) ? x0 : sp' while working
 * around the constraint that conditional moves can not
-- 
1.9.1

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

[U-Boot] [PATCH] m68k: doc: update outdated documentation

[Angelo Dureghello]

Update m68k documentation to reflect the current ColdFire
architecture support status.

Signed-off-by: Angelo Dureghello 
---
 doc/README.m54418twr |   2 +
 doc/README.m68k  | 216 ---
 2 files changed, 102 insertions(+), 116 deletions(-)

diff --git a/doc/README.m54418twr b/doc/README.m54418twr
index f69ae01912..1d90fccbcf 100644
--- a/doc/README.m54418twr
+++ b/doc/README.m54418twr
@@ -13,6 +13,8 @@ Changed files:
 - board/freescale/m54418twr/Makefile   Makefile
 - board/freescale/m54418twr/config.mk  config make
 - board/freescale/m54418twr/u-boot.lds Linker description
+- board/freescale/m54418twr/sbf_dram_init.S
+DDR/SDRAM initialization
 
 - arch/m68k/cpu/mcf5445x/cpu.c cpu specific code
 - arch/m68k/cpu/mcf5445x/cpu_init.cFlexbus ChipSelect, Mux pins setup, 
icache and RTC extra regs
diff --git a/doc/README.m68k b/doc/README.m68k
index 9d5c08f768..f867ca1fbb 100644
--- a/doc/README.m68k
+++ b/doc/README.m68k
@@ -1,96 +1,90 @@
 
-U-Boot for Motorola M68K
+U-Boot for Motorola (or Freescale/NXP) ColdFire processors
 
-
+===
 History
 
-August 08,2005;Jens Scharsig 
+November 02, 2017  Angelo Dureghello 
+August   08, 2005  Jens Scharsig 
MCF5282 implementation without preloader
-January 12, 2004;  
-
+January  12, 2004  
+===
+
 
 This file contains status information for the port of U-Boot to the
-Motorola M68K series of CPUs.
+Motorola ColdFire series of CPUs.
+
+
+1. Overview
 
-1. OVERVIEW

-Bernhard Kuhn ported U-Boot 0.4.0 to the Motorola Coldfire
-architecture. The patches of Bernhard support the MCF5272 and
-MCF5282. A great disadvantage of these patches was that they needed
-a pre-bootloader to start U-Boot. Because of this, a new port was
-created which no longer needs a first stage booter.
+The ColdFire instruction set is "assembly source" compatible but an evolution
+of the original 68000 instruction set. Some not much used instructions has
+been removed. The instructions are only 16, 32, or 48 bits long, a
+simplification compared to the 68000 series.
 
-Although this port is intended to cover all M68k processors, only
-the parts for the Motorola Coldfire MCF5272 and MCF5282 are
-implemented at the moment. Additional CPUs and boards will be
-hopefully added soon!
+Bernhard Kuhn ported U-Boot 0.4.0 to the Motorola ColdFire architecture.
+The patches of Bernhard support the MCF5272 and MCF5282. A great disadvantage
+of these patches was that they needed a pre-bootloader to start U-Boot.
+Because of this, a new port was created which no longer needs a first stage
+booter.
 
+Thanks mainly to Freescale but also to several other contributors, U-Boot now
+supports nearly the entire range of ColdFire processors and their related
+development boards.
 
-2. SUPPORTED CPUs
--
 
-2.1 Motorola Coldfire MCF5272
--
-CPU specific code is located in: arch/m68k/cpu/mcf52x2
+2. Supported CPU families
 
+Please "make menuconfig" with ARCH=m68k, or check arch/m68k/cpu to see the
+currently supported processor and families.
 
-2.1 Motorola Coldfire MCF5282
--
-CPU specific code is located in: arch/m68k/cpu/mcf52x2
 
-The MCF5282 Port no longer needs a preloader and can place in external or
-internal FLASH.
+3. Supported boards
 
+U-Boot supports actually more than 40 ColdFire based boards.
+Board configuration can be done trough include/configs/.h but the
+current recommended method is to use the new and more friendly approach as
+the "make menuconfig" way, very similar to the Linux way.
 
-3. SUPPORTED BOARDs

+To know details as memory map, build targets, default setup, etc, of a
+specific board please check:
 
-3.1 Motorola M5272C3 EVB
-
-Board specific code is located in: board/m5272c3
+include/configs/.h
+and/or
+configs/_defconfig
 
-To configure the board, type: make M5272C3_config
+It is possible to build all ColdFire boards in a single command-line command,
+from u-boot root directory, as:
 
-U-Boot Memory Map:
---
-0xffe0 - 0xffe3U-Boot
-0xffe04000 - 0xffe05fffenvironment (embedded in U-Boot!)
-0xffe4 - 0xfree for linux/applications
+./tools/buildman/buildman m68k
 
 
-3.2 Motorola M5282 EVB
-
-Board specific code is located in: board/m5282evb
+3.1. Build U-Boot for a specific board
 
-To 

[U-Boot] [PATCH] arm64: support running at addr other than linked to

[Stephen Warren]

From: Stephen Warren 

This is required in the case where U-Boot is typically loaded and run at
a particular address, but for some reason the RAM at that location is not
available, e.g. due to memory fragmentation loading other boot binaries or
firmware, splitting an SMP complex between various different OSs without
using e.g. the EL2 second-stage page tables to hide the memory asignments,
or due to known ECC failures.

Signed-off-by: Stephen Warren 
---
 arch/arm/Kconfig  | 16 
 arch/arm/cpu/armv8/start.S| 26 ++
 arch/arm/include/asm/config.h |  4 
 arch/arm/lib/crt0_64.S|  8 
 arch/arm/lib/relocate_64.S| 23 ++-
 5 files changed, 68 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 83b7aa51dc2c..294b456414bc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -9,6 +9,22 @@ config ARM64
select PHYS_64BIT
select SYS_CACHE_SHIFT_6
 
+if ARM64
+config POSITION_INDEPENDENT
+   bool "Generate position-independent pre-relocation code"
+   help
+ U-Boot expects to be linked to a specific hard-coded address, and to
+ be loaded to and run from that address. This option lifts that
+ restriction, thus allowing the code to be loaded to and executed
+ from almost any address. This logic relies on the relocation
+ information that is embedded into the binary to support U-Boot
+ relocating itself to the top-of-RAM later during execution.
+endif
+
+config STATIC_RELA
+   bool
+   default y if ARM64 && !POSITION_INDEPENDENT
+
 config DMA_ADDR_T_64BIT
bool
default y if ARM64
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 5c500be51d1f..03e744e4a673 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -57,6 +57,32 @@ reset:
 .globl save_boot_params_ret
 save_boot_params_ret:
 
+#if CONFIG_POSITION_INDEPENDENT
+   /*
+* Fix .rela.dyn relocations. This allows U-Boot to be loaded to and
+* executed at a different address than it was linked at.
+*/
+pie_fixup:
+   adr x0, _start  /* x0 <- Runtime value of _start */
+   ldr x1, _TEXT_BASE  /* x1 <- Linked value of _start */
+   sub x9, x0, x1  /* x9 <- Run-vs-link offset */
+   adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */
+   adr x3, __rel_dyn_end   /* x3 <- Runtime &__rel_dyn_end */
+pie_fix_loop:
+   ldp x0, x1, [x2], #16   /* (x0, x1) <- (Link location, fixup) */
+   ldr x4, [x2], #8/* x4 <- addend */
+   cmp w1, #1027   /* relative fixup? */
+   bne pie_skip_reloc
+   /* relative fix: store addend plus offset at dest location */
+   add x0, x0, x9
+   add x4, x4, x9
+   str x4, [x0]
+pie_skip_reloc:
+   cmp x2, x3
+   b.lopie_fix_loop
+pie_fixup_done:
+#endif
+
 #ifdef CONFIG_SYS_RESET_SCTRL
bl reset_sctrl
 #endif
diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h
index 5674d37c04df..9f178293818e 100644
--- a/arch/arm/include/asm/config.h
+++ b/arch/arm/include/asm/config.h
@@ -10,10 +10,6 @@
 #define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
 
-#ifdef CONFIG_ARM64
-#define CONFIG_STATIC_RELA
-#endif
-
 #if defined(CONFIG_ARCH_LS1021A) || \
defined(CONFIG_CPU_PXA27X) || \
defined(CONFIG_CPU_MONAHANS) || \
diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index 9c46c93ca4c5..da7c62cbe0aa 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -98,6 +98,14 @@ ENTRY(_main)
ldr x18, [x18, #GD_NEW_GD]  /* x18 <- gd->new_gd */
 
adr lr, relocation_return
+#if CONFIG_POSITION_INDEPENDENT
+   /* Add in link-vs-runtime offset */
+   adr x0, _start  /* x0 <- Runtime value of _start */
+   ldr x9, _TEXT_BASE  /* x9 <- Linked value of _start */
+   sub x9, x9, x0  /* x9 <- Run-vs-link offset */
+   add lr, lr, x9
+#endif
+   /* Add in link-vs-relocation offset */
ldr x9, [x18, #GD_RELOC_OFF]/* x9 <- gd->reloc_off */
add lr, lr, x9  /* new return address after relocation */
ldr x0, [x18, #GD_RELOCADDR]/* x0 <- gd->relocaddr */
diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S
index fdba004363af..04804524ed65 100644
--- a/arch/arm/lib/relocate_64.S
+++ b/arch/arm/lib/relocate_64.S
@@ -27,11 +27,24 @@ ENTRY(relocate_code)
/*
 * Copy u-boot from flash to RAM
 */
-   ldr x1, =__image_copy_start /* x1 <- SRC &__image_copy_start */
-   subsx9, x0, x1  /* x9 <- relocation offset */
+   adr x1, __image_copy_start  /* x1 <- Run 

Re: [U-Boot] sunxi: broken sun4i_emacs, all boards?

[Artturi Alm]

On Sun, Oct 22, 2017 at 11:08:43PM +0300, Artturi Alm wrote:
> Hi,
> 
> this has been 'blocking' my attempts to revive the A10-boards i have
> since early june, or so.
> 
> now i found this commit abc3e4df59f54cf3dda42a35a75d617fe861f5fe, which
> left the drivers/net/Makefile untouched, essentially breaking sunxi_emac.
> 
> the diff below didn't fix it however, i can see how it does arp who-has,
> and the remote replying, but u-boot does act as if nothing is received back?
> 
> -Artturi
> 

ping? apparently i forgot to cc anyone at first try.

-Artturi

> 
> U-Boot SPL 2017.11-rc2-2-g24b253e-dirty (Oct 22 2017 - 22:07:19)
> DRAM: 1024 MiB
> CPU: 100800Hz, AXI/AHB/APB: 3/2/2
> Trying to boot from MMC1
> 
> 
> U-Boot 2017.11-rc2-2-g24b253e-dirty (Oct 22 2017 - 22:07:19 +0300) 
> Allwinner Technology
> 
> CPU:   Allwinner A10 (SUN4I)
> Model: Cubietech Cubieboard
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> Net:   eth0: ethernet@01c0b000
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB OHCI 1.0
> USB2:   USB EHCI 1.00
> USB3:   USB OHCI 1.0
> scanning bus 0 for devices... 1 USB Device(s) found
> scanning bus 2 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> => env set ipaddr 192.168.2.10
> => ping 192.168.2.2
> resetting device
> ENET Speed is 100 Mbps - FULL duplex connection
> Using ethernet@01c0b000 device
> 
> ARP Retry count exceeded; starting again
> ping failed; host 192.168.2.2 is not alive
> =>
> 
> 
> 
> 
> 
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index d67927c..2e35563 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -219,6 +219,7 @@ config SUN7I_GMAC
>  config SUN4I_EMAC
>   bool "Allwinner Sun4i Ethernet MAC support"
>   depends on DM_ETH
> +select PHYLIB
>   help
> This driver supports the Allwinner based SUN4I Ethernet MAC.
>  
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 94a4fd8..ac5443c 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -21,7 +21,7 @@ obj-$(CONFIG_DNET) += dnet.o
>  obj-$(CONFIG_E1000) += e1000.o
>  obj-$(CONFIG_E1000_SPI) += e1000_spi.o
>  obj-$(CONFIG_EEPRO100) += eepro100.o
> -obj-$(CONFIG_SUNXI_EMAC) += sunxi_emac.o
> +obj-$(CONFIG_SUN4I_EMAC) += sunxi_emac.o
>  obj-$(CONFIG_SUN8I_EMAC) += sun8i_emac.o
>  obj-$(CONFIG_ENC28J60) += enc28j60.o
>  obj-$(CONFIG_EP93XX) += ep93xx_eth.o
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 9175117..b12f7e1 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -291,7 +291,7 @@ extern int soft_i2c_gpio_scl;
>  #endif /* CONFIG_VIDEO */
>  
>  /* Ethernet support */
> -#ifdef CONFIG_SUNXI_EMAC
> +#ifdef CONFIG_SUN4I_EMAC
>  #define CONFIG_PHY_ADDR  1
>  #define CONFIG_MII   /* MII PHY management   */
>  #endif
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index 3037d61..82b927c 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -2272,7 +2272,6 @@ CONFIG_STV0991_HZ
>  CONFIG_STV0991_HZ_CLOCK
>  CONFIG_ST_SMI
>  CONFIG_SUNXI_AHCI
> -CONFIG_SUNXI_EMAC
>  CONFIG_SUNXI_GPIO
>  CONFIG_SUNXI_MAX_FB_SIZE
>  CONFIG_SUNXI_USB_PHYS
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Build failure in u-boot-mmc/master: undefined reference to error

[Stephen Warren]

On 10/24/2017 01:54 AM, Jaehoon Chung wrote:

On 10/24/2017 12:22 AM, Stephen Warren wrote:

On 10/22/2017 08:53 PM, Jaehoon Chung wrote:

Dear Stephen,

On 10/21/2017 12:47 AM, Stephen Warren wrote:

With the latest content of u-boot-mmc/master, 41dc35a149b3 "drivers: mmc: Avoid 
memory leak in case of failure", all Tegra boards (perhaps others too; my system 
only tests Tegra) fail to build with the following error:


I had found the same error at build testing, I will fix it on today.
Thanks for noticing it.


Thanks.

I see that the build failures are fixed now, but the following unit-tests are 
failing on sandbox:

test_ut[ut_dm_blk_base]
test_ut[ut_dm_blk_devnum]
test_ut[ut_dm_blk_get_from_parent]
test_ut[ut_dm_mmc_base]
test_ut[ut_dm_mmc_blk]

For example:


=> ut dm blk_base
Test: dm_test_blk_base: blk.c
unable to select a mode
mmc_init: -524, time 6
/var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/test/dm/blk.c:40,
 dm_test_blk_base(): 0 == blk_first_device(IF_TYPE_HOST, ): Expected 0, got 
-524
Test: dm_test_blk_base: blk.c (flat tree)
unable to select a mode
mmc_init: -524, time 6
/var/lib/jenkins/workspace/u-boot-denx_uboot_mmc-master-build/src/u-boot/test/dm/blk.c:40,
 dm_test_blk_base(): 0 == blk_first_device(IF_TYPE_HOST, ): Expected 0, got 
-524
Failures: 2


You should be able to reproduce this by running the following from the U-Boot 
source tree:

./test/py/test.py --bd sandbox --build


Will check. thanks!


Jaehoon, did you find the issue? I don't see any new commits pushed.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] board: sysam: stmark2: add missing environment location

[Angelo Dureghello]

Signed-off-by: Angelo Dureghello 
---
 configs/stmark2_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/stmark2_defconfig b/configs/stmark2_defconfig
index 3639aaa9e3..d34ffda260 100644
--- a/configs/stmark2_defconfig
+++ b/configs/stmark2_defconfig
@@ -18,6 +18,7 @@ CONFIG_CMD_SPI=y
 # CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_REGEX=y
-- 
2.14.1

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

[U-Boot] [PATCH 9/9] arm: zynq: Add board support for cc108

[Michal Simek]

cc108 board is wiring uart via PL which is good platform for SPL fpga
support.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/zynq-cc108.dts  | 116 +++
 configs/zynq_cc108_defconfig |  54 
 3 files changed, 171 insertions(+)
 create mode 100644 arch/arm/dts/zynq-cc108.dts
 create mode 100644 configs/zynq_cc108_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6db64f91016c..565e679b182b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -124,6 +124,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER_SLD8) += \
uniphier-sld8-ref.dtb
 
 dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
+   zynq-cc108.dtb \
zynq-zc706.dtb \
zynq-zed.dtb \
zynq-zybo.dtb \
diff --git a/arch/arm/dts/zynq-cc108.dts b/arch/arm/dts/zynq-cc108.dts
new file mode 100644
index ..a55e82b2102c
--- /dev/null
+++ b/arch/arm/dts/zynq-cc108.dts
@@ -0,0 +1,116 @@
+/*
+ * Xilinx CC108 board DTS
+ *
+ * (C) Copyright 2007-2013 Xilinx, Inc.
+ * (C) Copyright 2007-2013 Michal Simek
+ * (C) Copyright 2007-2012 PetaLogix Qld Pty Ltd
+ *
+ * Michal SIMEK 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+/dts-v1/;
+/include/ "zynq-7000.dtsi"
+
+/ {
+   compatible = "xlnx,zynq-cc108", "xlnx,zynq-7000";
+   model = "Xilinx Zynq";
+
+   aliases {
+   ethernet0 = 
+   serial0 = 
+   spi0 = 
+   };
+
+   chosen {
+   bootargs = "";
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x2000>;
+   };
+
+   usb_phy0: phy0 {
+   compatible = "usb-nop-xceiv";
+   #phy-cells = <0>;
+   };
+
+   usb_phy1: phy1 {
+   compatible = "usb-nop-xceiv";
+   #phy-cells = <0>;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii-id";
+   phy-handle = <_phy>;
+
+   ethernet_phy: ethernet-phy@1 {
+   reg = <1>;
+   device_type = "ethernet-phy";
+   };
+};
+
+ {
+   status = "okay";
+   is-dual = <0>;
+   num-cs = <1>;
+   flash@0 { /* 16 MB */
+   compatible = "n25q128a11";
+   reg = <0x0>;
+   spi-max-frequency = <5000>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <4>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   partition@0 {
+   label = "qspi-fsbl-uboot-bs";
+   reg = <0x0 0x40>; /* 4MB */
+   };
+   partition@0x40 {
+   label = "qspi-linux";
+   reg = <0x40 0x40>; /* 4MB */
+   };
+   partition@0x80 {
+   label = "qspi-rootfs";
+   reg = <0x80 0x40>; /* 4MB */
+   };
+   partition@0xc0 {
+   label = "qspi-devicetree";
+   reg = <0xc0 0x10>; /* 1MB */
+   };
+   partition@0xd0 {
+   label = "qspi-scratch";
+   reg = <0xd0 0x20>; /* 2MB */
+   };
+   partition@0xf0 {
+   label = "qspi-uboot-env";
+   reg = <0xf0 0x10>; /* 1MB */
+   };
+   };
+};
+
+ {
+   status = "okay";
+   broken-cd ;
+   wp-inverted ;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   dr_mode = "host";
+   usb-phy = <_phy0>;
+};
+
+ {
+   status = "okay";
+   dr_mode = "host";
+   usb-phy = <_phy1>;
+};
diff --git a/configs/zynq_cc108_defconfig b/configs/zynq_cc108_defconfig
new file mode 100644
index ..7927017ae1aa
--- /dev/null
+++ b/configs/zynq_cc108_defconfig
@@ -0,0 +1,54 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ZYNQ=y
+CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_DEFAULT_DEVICE_TREE="zynq-cc108"
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_VERBOSE=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_DFU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ZYNQ=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y

[U-Boot] [PATCH 6/9] arm: zynq: Enable debug console on zc770 xm010 by default

[Michal Simek]

Enable debug console.

Signed-off-by: Michal Simek 
---

 configs/zynq_zc770_xm010_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/zynq_zc770_xm010_defconfig 
b/configs/zynq_zc770_xm010_defconfig
index c70ac6bec230..49083e82814e 100644
--- a/configs/zynq_zc770_xm010_defconfig
+++ b/configs/zynq_zc770_xm010_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
 CONFIG_SYS_TEXT_BASE=0x400
 CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm010"
+CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
@@ -43,5 +44,8 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_ZYNQ_GEM=y
+CONFIG_DEBUG_UART_ZYNQ=y
+CONFIG_DEBUG_UART_BASE=0xe0001000
+CONFIG_DEBUG_UART_CLOCK=5000
 CONFIG_ZYNQ_SPI=y
 CONFIG_ZYNQ_QSPI=y
-- 
1.9.1

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

[U-Boot] [PATCH 7/9] arm: zynq: Enable MACRONIX flash for zc702/zc706/zc770 xm010

[Michal Simek]

Enable MACRONIX flash for boards with QSPI enabled.

Signed-off-by: Michal Simek 
---

 configs/zynq_zc702_defconfig   | 1 +
 configs/zynq_zc706_defconfig   | 1 +
 configs/zynq_zc770_xm010_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig
index de014482cc29..54fcbfae7ae6 100644
--- a/configs/zynq_zc702_defconfig
+++ b/configs/zynq_zc702_defconfig
@@ -46,6 +46,7 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
index f14bed856f31..e1b8c226c8e5 100644
--- a/configs/zynq_zc706_defconfig
+++ b/configs/zynq_zc706_defconfig
@@ -45,6 +45,7 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
diff --git a/configs/zynq_zc770_xm010_defconfig 
b/configs/zynq_zc770_xm010_defconfig
index 49083e82814e..a00919faf80e 100644
--- a/configs/zynq_zc770_xm010_defconfig
+++ b/configs/zynq_zc770_xm010_defconfig
@@ -39,6 +39,7 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
-- 
1.9.1

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

[U-Boot] [PATCH 8/9] arm: zynq: Enable qspi for zc770_xm013

[Michal Simek]

Enable qspi driver and flashes for this board.

Signed-off-by: Michal Simek 
---

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

diff --git a/configs/zynq_zc770_xm013_defconfig 
b/configs/zynq_zc770_xm013_defconfig
index d51256b124a3..39f6199c47f9 100644
--- a/configs/zynq_zc770_xm013_defconfig
+++ b/configs/zynq_zc770_xm013_defconfig
@@ -30,4 +30,9 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_ZYNQ_GEM=y
+CONFIG_ZYNQ_QSPI=y
-- 
1.9.1

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

[U-Boot] [PATCH 4/9] arm: zynq: Sync location of DT properties with Linux

[Michal Simek]

This is trival change which only ensures the same location with Linux
kernel.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynq-7000.dtsi | 2 +-
 arch/arm/dts/zynq-zybo.dts  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
index f993e19ef280..d9774d85d10b 100644
--- a/arch/arm/dts/zynq-7000.dtsi
+++ b/arch/arm/dts/zynq-7000.dtsi
@@ -105,10 +105,10 @@
gpio0: gpio@e000a000 {
compatible = "xlnx,zynq-gpio-1.0";
#gpio-cells = <2>;
-   #interrupt-cells = <2>;
clocks = < 42>;
gpio-controller;
interrupt-controller;
+   #interrupt-cells = <2>;
interrupt-parent = <>;
interrupts = <0 20 4>;
reg = <0xe000a000 0x1000>;
diff --git a/arch/arm/dts/zynq-zybo.dts b/arch/arm/dts/zynq-zybo.dts
index f3eebb088287..52ec5a45667a 100644
--- a/arch/arm/dts/zynq-zybo.dts
+++ b/arch/arm/dts/zynq-zybo.dts
@@ -31,8 +31,8 @@
};
 
usb_phy0: phy0 {
-   compatible = "usb-nop-xceiv";
#phy-cells = <0>;
+   compatible = "usb-nop-xceiv";
reset-gpios = < 46 1>;
};
 };
-- 
1.9.1

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

[U-Boot] [PATCH 5/9] arm: zynq: Enable bootz command for Xilinx platforms

[Michal Simek]

bootz command is valid way how to boot Linux kernel. Enable it by
default.

Signed-off-by: Michal Simek 
---

 configs/zynq_zc702_defconfig   | 1 +
 configs/zynq_zc706_defconfig   | 1 +
 configs/zynq_zc770_xm010_defconfig | 1 +
 configs/zynq_zc770_xm011_defconfig | 1 +
 configs/zynq_zc770_xm012_defconfig | 1 +
 configs/zynq_zc770_xm013_defconfig | 1 +
 configs/zynq_zed_defconfig | 1 +
 7 files changed, 7 insertions(+)

diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig
index 5fd1ff093e99..de014482cc29 100644
--- a/configs/zynq_zc702_defconfig
+++ b/configs/zynq_zc702_defconfig
@@ -12,6 +12,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_THOR_DOWNLOAD=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_DFU=y
diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
index 8964f57e1dcb..f14bed856f31 100644
--- a/configs/zynq_zc706_defconfig
+++ b/configs/zynq_zc706_defconfig
@@ -11,6 +11,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_THOR_DOWNLOAD=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_DFU=y
diff --git a/configs/zynq_zc770_xm010_defconfig 
b/configs/zynq_zc770_xm010_defconfig
index dbca4a62ef30..c70ac6bec230 100644
--- a/configs/zynq_zc770_xm010_defconfig
+++ b/configs/zynq_zc770_xm010_defconfig
@@ -11,6 +11,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_FPGA_LOADBP=y
 CONFIG_CMD_FPGA_LOADFS=y
diff --git a/configs/zynq_zc770_xm011_defconfig 
b/configs/zynq_zc770_xm011_defconfig
index b1511d81f774..193c118c5743 100644
--- a/configs/zynq_zc770_xm011_defconfig
+++ b/configs/zynq_zc770_xm011_defconfig
@@ -12,6 +12,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_FPGA_LOADBP=y
 CONFIG_CMD_FPGA_LOADFS=y
diff --git a/configs/zynq_zc770_xm012_defconfig 
b/configs/zynq_zc770_xm012_defconfig
index 71b379add3b2..c62bdb1ef453 100644
--- a/configs/zynq_zc770_xm012_defconfig
+++ b/configs/zynq_zc770_xm012_defconfig
@@ -12,6 +12,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_IMLS=y
 CONFIG_CMD_FPGA_LOADBP=y
 CONFIG_CMD_FPGA_LOADFS=y
diff --git a/configs/zynq_zc770_xm013_defconfig 
b/configs/zynq_zc770_xm013_defconfig
index 4ffb2f971883..d51256b124a3 100644
--- a/configs/zynq_zc770_xm013_defconfig
+++ b/configs/zynq_zc770_xm013_defconfig
@@ -12,6 +12,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_FPGA_LOADBP=y
 CONFIG_CMD_FPGA_LOADFS=y
diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig
index 17a8809dd27d..8fafe081408a 100644
--- a/configs/zynq_zed_defconfig
+++ b/configs/zynq_zed_defconfig
@@ -10,6 +10,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
+CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_THOR_DOWNLOAD=y
 CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
-- 
1.9.1

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

[U-Boot] [PATCH 3/9] arm: zynq: Remove empty ifdef env structures from config file

[Michal Simek]

All these configs were moved to Kconfig that's why this empty ifdef
structure is not needed anymore.

Signed-off-by: Michal Simek 
---

 include/configs/zynq-common.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index b9599c73a673..8de2ac351ca8 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -157,12 +157,6 @@
 
 /* Environment */
 #ifndef CONFIG_ENV_IS_NOWHERE
-# ifdef CONFIG_MTD_NOR_FLASH
-/* Environment in NOR flash */
-# elif defined(CONFIG_ZYNQ_QSPI)
-/* Environment in Serial Flash */
-# endif
-
 # define CONFIG_ENV_SECT_SIZE  CONFIG_ENV_SIZE
 # define CONFIG_ENV_OFFSET 0xE
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH 2/9] arm: zynq: Add device-type property for zynq ethernet phy nodes

[Michal Simek]

From: Sai Pavan Boddu 

Mention device-type = "ethernet-phy", as qemu will need this in absence
of compatible.

Signed-off-by: Sai Pavan Boddu 
Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynq-zc702.dts   | 1 +
 arch/arm/dts/zynq-zc706.dts   | 1 +
 arch/arm/dts/zynq-zc770-xm010.dts | 1 +
 arch/arm/dts/zynq-zc770-xm013.dts | 1 +
 arch/arm/dts/zynq-zed.dts | 1 +
 arch/arm/dts/zynq-zybo.dts| 1 +
 6 files changed, 6 insertions(+)

diff --git a/arch/arm/dts/zynq-zc702.dts b/arch/arm/dts/zynq-zc702.dts
index 7b0c23fa5d26..da698a19ccd1 100644
--- a/arch/arm/dts/zynq-zc702.dts
+++ b/arch/arm/dts/zynq-zc702.dts
@@ -96,6 +96,7 @@
 
ethernet_phy: ethernet-phy@7 {
reg = <7>;
+   device_type = "ethernet-phy";
};
 };
 
diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index 8b0177bc512a..d342306293b4 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -50,6 +50,7 @@
 
ethernet_phy: ethernet-phy@7 {
reg = <7>;
+   device_type = "ethernet-phy";
};
 };
 
diff --git a/arch/arm/dts/zynq-zc770-xm010.dts 
b/arch/arm/dts/zynq-zc770-xm010.dts
index 42af313c13dd..cc5ba98d6bd9 100644
--- a/arch/arm/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/dts/zynq-zc770-xm010.dts
@@ -47,6 +47,7 @@
 
ethernet_phy: ethernet-phy@7 {
reg = <7>;
+   device_type = "ethernet-phy";
};
 };
 
diff --git a/arch/arm/dts/zynq-zc770-xm013.dts 
b/arch/arm/dts/zynq-zc770-xm013.dts
index 07e92b88fb0f..81a6aa562a94 100644
--- a/arch/arm/dts/zynq-zc770-xm013.dts
+++ b/arch/arm/dts/zynq-zc770-xm013.dts
@@ -42,6 +42,7 @@
 
ethernet_phy: ethernet-phy@7 {
reg = <7>;
+   device_type = "ethernet-phy";
};
 };
 
diff --git a/arch/arm/dts/zynq-zed.dts b/arch/arm/dts/zynq-zed.dts
index 0ac7532300f0..a9ff0e6fa814 100644
--- a/arch/arm/dts/zynq-zed.dts
+++ b/arch/arm/dts/zynq-zed.dts
@@ -47,6 +47,7 @@
 
ethernet_phy: ethernet-phy@0 {
reg = <0>;
+   device_type = "ethernet-phy";
};
 };
 
diff --git a/arch/arm/dts/zynq-zybo.dts b/arch/arm/dts/zynq-zybo.dts
index d59a3831352d..f3eebb088287 100644
--- a/arch/arm/dts/zynq-zybo.dts
+++ b/arch/arm/dts/zynq-zybo.dts
@@ -48,6 +48,7 @@
 
ethernet_phy: ethernet-phy@0 {
reg = <0>;
+   device_type = "ethernet-phy";
};
 };
 
-- 
1.9.1

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

[U-Boot] [PATCH 1/9] arm: zynq: Add SCL & SDA GPIO entries for recovery

[Michal Simek]

From: Chirag Parekh 

Wire i2c pinmuxing gpio recovery for zc702.

Signed-off-by: Chirag Parekh 
Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynq-zc702.dts | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/zynq-zc702.dts b/arch/arm/dts/zynq-zc702.dts
index 2696e70a89a7..7b0c23fa5d26 100644
--- a/arch/arm/dts/zynq-zc702.dts
+++ b/arch/arm/dts/zynq-zc702.dts
@@ -107,8 +107,11 @@
  {
status = "okay";
clock-frequency = <40>;
-   pinctrl-names = "default";
+   pinctrl-names = "default", "gpio";
pinctrl-0 = <_i2c0_default>;
+   pinctrl-1 = <_i2c0_gpio>;
+   scl-gpios = < 50 0>;
+   sda-gpios = < 51 0>;
 
i2cswitch@74 {
compatible = "nxp,pca9548";
@@ -299,6 +302,19 @@
};
};
 
+   pinctrl_i2c0_gpio: i2c0-gpio {
+   mux {
+   groups = "gpio0_50_grp", "gpio0_51_grp";
+   function = "gpio0";
+   };
+
+   conf {
+   groups = "gpio0_50_grp", "gpio0_51_grp";
+   slew-rate = <0>;
+   io-standard = <1>;
+   };
+   };
+
pinctrl_sdhci0_default: sdhci0-default {
mux {
groups = "sdio0_2_grp";
-- 
1.9.1

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

Re: [U-Boot] SPDX License status

[Masahiro Yamada]

2017-08-25 16:46 GMT+09:00 Wolfgang Denk :
> Dear Tom,
>
> In message <20170825012557.GK2827@bill-the-cat> you wrote:
>>
>> Actual code we have to take care with anyhow, but it's still up to the
>> person that has to handle the syncing.
>
> Really?  Should we not rather implement a common, consistent policy
> for the whole project?
>
> Our patch submission already include a rule for new code [1]:
>
> If you add new files, please always make sure that these
> contain your copyright note and a GPLv2+
> SPDX-License-Identifier, for example like this:
>
> (C) Copyright 2010  Joe Hacker 
>
> SPDX-License-Identifier:GPL-2.0+
>
> Should we not ask the same for code merged from other projects?
>
> [1] Bullet #3 in 
> http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
>
> Best regards,
>
> Wolfgang Denk
>
> --


As you may have already noticed, there seemed to be a progress in Linux.

https://lkml.org/lkml/2017/11/2/590



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

Re: [U-Boot] [PATCH v2] ARM: zynq: Add support for SYZYGY Hub board

[Tom McLeod]

Hi Michal,

>Patch looks good but only this prefix needs to be added to the Linux
>kernel. It should be present in this file. Please send the patch and
>when it is added to linux-next I will add your patch

It looks like our vendor prefix has been accepted into linux-next.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/
Documentation/devicetree/bindings/vendor-prefixes.txt?h=master

Please let me know if you need anything else to apply our u-boot patch.

Thanks,
-Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] scsi: ceva: Start port in probe

[Mian Yousaf Kaukab]

On 11/02/2017 03:53 PM, Michal Simek wrote:

The patch:
"dm: ahci: Unwind the confusing init code"
(sha1: 7cf1afce7fa3fe64189020fe14b93f7326dd0758)
introduce bug for ceva sata because port didn't start.
On the other hand the dwc_ahci.c was fixed correctly.
Do the same change for ceva too.

Signed-off-by: Michal Simek


Thanks Michal!

Tested-by: Mian Yousaf Kaukab 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] sunxi: binman: Add U-Boot binary size check

[Frank Kunz]

Am Donnerstag, 19. Oktober 2017, 16:04:18 CET schrieb Maxime Ripard:
> The U-boot binary may trip over its actual allocated size in the storage.
> In such a case, the environment will not be readable anymore (because
> corrupted when the new image was flashed), and any attempt at using saveenv
> to reconstruct the environment will result in a corrupted U-boot binary.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/dts/sunxi-u-boot.dtsi | 11 +++
>  1 file changed, 11 insertions(+)

Hello,

I found that this patch causes the sunxi-fel tool to fail with:

sunxi-fel uboot u-boot-sunxi-with-spl.bin
U-Boot image data size mismatch: expected 516032, got 389212

Is there a patch for the sunxi tools missing?

Br,
Frank
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] arm64: ls1043ardb: Add sd_bootcmd for distro fallback in case of sdboot

[York Sun]

On 11/01/2017 04:19 AM, Shengzhou Liu wrote:
> 
> York, 
> please drop this version, I will update it and send next new version to add 
> distro secureboot together. 
> 

Shengzhou,

Do not mark the patch as "superseded" if you haven't sent a new version.
You can mark it as "Not Applicable" instead.

Thanks.

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

Re: [U-Boot] [PATCH v4 2/2] armv8: ls1088: Enable SATA for ls1088

[York Sun]

On 11/01/2017 09:20 PM, Ashish Kumar wrote:
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Amrita Kumari 
> ---
> v2: Rebase to top
> v3: Consolidate defines in common file
> v4: Protect define using CONFIG_SCSI
> 

Andy,

Does this set represent the latest change you and Ashish agreed on?
Please give your review comment.

York

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

Re: [U-Boot] [Patch V5 1/2] armv8: ls1088ardb: Add SD boot support for ls1088

[York Sun]

On 11/01/2017 09:21 PM, Ashish Kumar wrote:
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Raghav Dogra 
> ---
> 
> v5:
> Rewording and incorporation of review comments in README
> Move define to defconfig
> 
>  arch/arm/Kconfig   |  1 +
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 | 45 
> ++
>  board/freescale/ls1088a/MAINTAINERS|  1 +
>  board/freescale/ls1088a/ddr.c  |  5 ++-
>  configs/ls1088ardb_sdcard_qspi_defconfig   | 42 
>  include/configs/ls1088a_common.h   | 25 
>  include/configs/ls1088ardb.h   | 30 ++-
>  7 files changed, 146 insertions(+), 3 deletions(-)
>  create mode 100644 configs/ls1088ardb_sdcard_qspi_defconfig
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 83b7aa5..5707111 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -938,6 +938,7 @@ config TARGET_LS1088ARDB
>   select ARMV8_MULTIENTRY
>   select ARCH_MISC_INIT
>   select BOARD_LATE_INIT
> + select SUPPORT_SPL
>   help
> Support for NXP LS1088ARDB platform.
> The LS1088A Reference design board (RDB) is a high-performance
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 
> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> index 7867c37..a4ed24f 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
> @@ -201,6 +201,51 @@ nand write  8  u-boot image>
>  Notice the difference from QDS is SRC, SRC_ADDR and the offset of u-boot 
> image
>  to match board NAND device with 4KB/page, block size 512KB.
>  
> +Booting from SD/eMMC
> +---
> +Booting from SD/eMMC requires two images, RCW and u-boot-with-spl.bin.
> +The difference between SD boot RCW image and QSPI-NOR boot image is the PBI
> +command sequence. Below is one example for PBI commands for RDB and QDS 
> which uses
> +SD device with block size 512. Block location can be calculated by dividing 
> offset with
> +block size.

Inconsistent wrap-back length at multiple places. Please fix.

> +
> +1) Block Copy: SRC=0x0040, SRC_ADDR=0x0010, DEST_ADDR=0x1800a000,
> +BLOCK_SIZE=0x00016000
> +
> +This command copies u-boot image from SD device into OCRAM. The values need
> +to adjust accordingly for SD/eMMC
> +
> +SRC  should match the cfg_rcw_src, the reset config pins.
> + The value for source(SRC) can be 0x0040 or 0x0041
> + depending upon SD or eMMC.
> +SRC_ADDR is the offset of u-boot-with-spl.bin image in SD device. In
> + the example above, 1MB. This is same as QSPI-NOR.
> +DEST_ADDRis configured at 0x1800a000, matching bootloc set above.
> +BLOCK_SIZE   is the size to be copied by PBI.
> +
> +2) CCSR 4-byte write to 0x01e00404, data=0x
> +3) CCSR 4-byte write to 0x01e00400, data=0x1800a000
> +The above two commands set bootloc register to 0x_1800a000 where
> +the u-boot code will be running in OCRAM.
> +
> +
> +RCW image should be written at 8th block of device(SD/eMMC). Example of using
> +u-boot command
> +
> +mmc erase 0x8 0x10
> +mmc write  0x8  value=10>
> +
> +To form the SD-Boot image, build u-boot with SD config, for example,
> +ls1088ardb_sdcard_qspi_defconfig. The image needed is u-boot-with-spl.bin.
> +The u-boot image should be written to match SRC_ADDR, in above example 
> offset 0x10
> +in other work it means block location 0x800
> +
> +mmc erase 0x800 0x1800
> +mmc write  0x800  count>
> +
> +With these two images in SD/eMMC device, the board can boot from SD/eMMC.
> +
> +
>  MMU Translation Tables
>  ==
>  
> diff --git a/board/freescale/ls1088a/MAINTAINERS 
> b/board/freescale/ls1088a/MAINTAINERS
> index e1e6d4b..68f23d6 100644
> --- a/board/freescale/ls1088a/MAINTAINERS
> +++ b/board/freescale/ls1088a/MAINTAINERS
> @@ -5,6 +5,7 @@ S:Maintained
>  F:   board/freescale/ls1088a/
>  F:   include/configs/ls1088ardb.h
>  F:   configs/ls1088ardb_qspi_defconfig
> +F:   configs/ls1088ardb_sdcard_qspi_defconfig
>  
>  LS1088AQDS BOARD
>  M:   Prabhakar Kushwaha 
> diff --git a/board/freescale/ls1088a/ddr.c b/board/freescale/ls1088a/ddr.c
> index 0ecfd65..e24bfd5 100644
> --- a/board/freescale/ls1088a/ddr.c
> +++ b/board/freescale/ls1088a/ddr.c
> @@ -96,7 +96,10 @@ int fsl_initdram(void)
>  {
>   puts("Initializing DDRusing SPD\n");
>  
> +#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD)
> + gd->ram_size = fsl_ddr_sdram_size();
> +#else
>   gd->ram_size = fsl_ddr_sdram();
> -
> +#endif
>   return 0;
>  }
> diff --git a/configs/ls1088ardb_sdcard_qspi_defconfig 
> b/configs/ls1088ardb_sdcard_qspi_defconfig
> new file mode 100644
> index 000..b677b2f
> --- 

Re: [U-Boot] [PATCH 1/3] arm64: ls1088ardb: Add distro boot support

[York Sun]

On 11/01/2017 10:48 PM, Ashish Kumar wrote:
> Disto boot support give flexibility to run distro RFS like ubuntu's

s/Disto/Distro
s/give/gives
S/ubuntu/Ubuntu

> being deployed from SD card or USB stick. If it fails
> to detect external storage, fall back to qspi/sd boot.
> 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Zhang Ying 
> ---
>  include/configs/ls1088ardb.h | 113 
> +--
>  1 file changed, 88 insertions(+), 25 deletions(-)
> 
> diff --git a/include/configs/ls1088ardb.h b/include/configs/ls1088ardb.h
> index eef9a07..c7d1fd3 100644
> --- a/include/configs/ls1088ardb.h
> +++ b/include/configs/ls1088ardb.h
> @@ -258,40 +258,103 @@
>  
>  /* Initial environment variables */
>  #if defined(CONFIG_QSPI_BOOT)
> -#undef CONFIG_EXTRA_ENV_SETTINGS
> -#define CONFIG_EXTRA_ENV_SETTINGS\
> - "hwconfig=fsl_ddr:bank_intlv=auto\0"\
> - "loadaddr=0x9010\0" \
> - "kernel_addr=0x10\0"\
> - "ramdisk_addr=0x80\0"   \
> - "ramdisk_size=0x200\0"  \
> - "fdt_high=0xa000\0" \
> - "initrd_high=0x\0"  \
> - "kernel_start=0x100\0"  \
> - "kernel_load=0xa000\0"  \
> - "kernel_size=0x280\0"   \
> +#define MC_INIT_CMD  \
>   "mcinitcmd=sf probe 0:0;sf read 0x8000 0xA0 0x10;"  \
> - "sf read 0x8010 0xE0 0x10;" \
> - "fsl_mc start mc 0x8000 0x8010\0"   \
> - "mcmemsize=0x7000 \0"
> + "sf read 0x8010 0xE0 0x10;" \
> + "fsl_mc start mc 0x8000 0x8010\0"   \
> + "mcmemsize=0x7000\0"
>  #elif defined(CONFIG_SD_BOOT)
> +#define MC_INIT_CMD  \
> + "mcinitcmd=mmcinfo;mmc read 0x8000 0x5000 0x800;"   \
> + "mmc read 0x8010 0x7000 0x800;" \
> + "fsl_mc start mc 0x8000 0x8010\0"   \
> + "mcmemsize=0x7000\0"
> +#endif
> +
>  #undef CONFIG_EXTRA_ENV_SETTINGS
>  #define CONFIG_EXTRA_ENV_SETTINGS\
> + "BOARD=ls1088ardb\0"\
>   "hwconfig=fsl_ddr:bank_intlv=auto\0"\
> - "loadaddr=0x9010\0" \
> - "kernel_addr=0x800\0"   \
>   "ramdisk_addr=0x80\0"   \
>   "ramdisk_size=0x200\0"  \
>   "fdt_high=0xa000\0" \
>   "initrd_high=0x\0"  \
> - "kernel_start=0x8000\0" \
> - "kernel_load=0xa000\0"  \
> - "kernel_size=0x14000\0" \
> - "mcinitcmd=mmcinfo;mmc read 0x8000 0x5000 0x800;"   \
> - "mmc read 0x8010 0x7000 0x800;" \
> - "fsl_mc start mc 0x8000 0x8010\0"   \
> - "mcmemsize=0x7000 \0"
> -
> + "fdt_addr=0x64f0\0" \
> + "kernel_addr=0x100\0"   \
> + "kernel_addr_sd=0x8000\0"   \
> + "kernel_start=0x58010\0"\
> + "kernelheader_start=0x58080\0"  \
> + "scriptaddr=0x8000\0"   \
> + "scripthdraddr=0x8008\0"\
> + "fdtheader_addr_r=0x8010\0" \
> + "kernelheader_addr=0x80\0"  \
> + "kernelheader_addr_r=0x8020\0"  \
> + "kernel_addr_r=0x8100\0"\
> + "kernelheader_size=0x4\0"   \
> + "fdt_addr_r=0x9000\0"   \
> + "load_addr=0xa000\0"\
> + "kernel_size=0x280\0"   \
> + "kernel_size_sd=0x14000\0"  \
> + MC_INIT_CMD \
> + BOOTENV \
> + "boot_scripts=ls1088ardb_boot.scr\0"\
> + "boot_script_hdr=hdr_ls1088ardb_bs.out\0"   \
> + "scan_dev_for_boot_part="   \
> + "part list ${devtype} ${devnum} devplist; " \
> + "env exists devplist || setenv devplist 1; "\
> + "for distro_bootpart in ${devplist}; do "   \
> + "if fstype ${devtype} " \
> + "${devnum}:${distro_bootpart} " \
> + "bootfstype; then " \
> + "run scan_dev_for_boot; "   \
> + "fi; "  \
> + "done\0"\
> + "scan_dev_for_boot="\
> + "echo Scanning ${devtype} " \
> + "${devnum}:${distro_bootpart}...; " \
> + "for prefix in ${boot_prefixes}; do "   \
> + "run scan_dev_for_scripts; "

Re: [U-Boot] [PATCH 2/3] armv8: ls1088ardb: Add CONFIG_DISTRO_DEFAULTS qspi-defconfig

[York Sun]

On 11/01/2017 10:48 PM, Ashish Kumar wrote:
> Signed-off-by: Ashish Kumar 
> ---
>  configs/ls1088ardb_qspi_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/ls1088ardb_qspi_defconfig 
> b/configs/ls1088ardb_qspi_defconfig
> index db15d31..6ec949c 100644
> --- a/configs/ls1088ardb_qspi_defconfig
> +++ b/configs/ls1088ardb_qspi_defconfig
> @@ -40,3 +40,4 @@ CONFIG_USB_DWC3=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
>  CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
> +CONFIG_DISTRO_DEFAULTS=y
> 

Since you already mixed QSPI and SD changes in patch #1, it doesn't make
much sense to have patch #2 and #3 separated. You can squash all three
into one for this case.

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

[U-Boot] [PATCH] ata: Fix ahci wording

[Michal Simek]

s/achi_/ahci_/g

Signed-off-by: Michal Simek 
---

 drivers/ata/ahci.c  | 4 ++--
 drivers/ata/dwc_ahci.c  | 2 +-
 drivers/ata/sata_ceva.c | 4 ++--
 include/ahci.h  | 8 
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5e4df19386bd..690d35c890d2 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1026,7 +1026,7 @@ void scsi_low_level_init(int busdevfunc)
 
 #ifndef CONFIG_SCSI_AHCI_PLAT
 # if defined(CONFIG_DM_PCI) || defined(CONFIG_DM_SCSI)
-int achi_init_one_dm(struct udevice *dev)
+int ahci_init_one_dm(struct udevice *dev)
 {
struct ahci_uc_priv *uc_priv = dev_get_uclass_priv(dev);
 
@@ -1035,7 +1035,7 @@ int achi_init_one_dm(struct udevice *dev)
 #endif
 #endif
 
-int achi_start_ports_dm(struct udevice *dev)
+int ahci_start_ports_dm(struct udevice *dev)
 {
struct ahci_uc_priv *uc_priv = dev_get_uclass_priv(dev);
 
diff --git a/drivers/ata/dwc_ahci.c b/drivers/ata/dwc_ahci.c
index b16304baedbd..029b7784f64c 100644
--- a/drivers/ata/dwc_ahci.c
+++ b/drivers/ata/dwc_ahci.c
@@ -85,7 +85,7 @@ static int dwc_ahci_probe(struct udevice *dev)
if (ret)
return ret;
 
-   return achi_start_ports_dm(dev);
+   return ahci_start_ports_dm(dev);
 }
 
 static const struct udevice_id dwc_ahci_ids[] = {
diff --git a/drivers/ata/sata_ceva.c b/drivers/ata/sata_ceva.c
index 3ef7b49215c4..bae26898bad2 100644
--- a/drivers/ata/sata_ceva.c
+++ b/drivers/ata/sata_ceva.c
@@ -118,11 +118,11 @@ static int sata_ceva_probe(struct udevice *dev)
 
ceva_init_sata(plat->base);
 
-   ret = achi_init_one_dm(dev);
+   ret = ahci_init_one_dm(dev);
if (ret)
return ret;
 
-   return achi_start_ports_dm(dev);
+   return ahci_start_ports_dm(dev);
 }
 
 static const struct udevice_id sata_ceva_ids[] = {
diff --git a/include/ahci.h b/include/ahci.h
index 33171b7ffd63..cc36d81f98a6 100644
--- a/include/ahci.h
+++ b/include/ahci.h
@@ -234,18 +234,18 @@ int ahci_init(void __iomem *base);
 int ahci_reset(void __iomem *base);
 
 /**
- * achi_init_one_dm() - set up a single AHCI port
+ * ahci_init_one_dm() - set up a single AHCI port
  *
  * @dev: Controller to init
  */
-int achi_init_one_dm(struct udevice *dev);
+int ahci_init_one_dm(struct udevice *dev);
 
 /**
- * achi_start_ports_dm() - start all AHCI ports for a controller
+ * ahci_start_ports_dm() - start all AHCI ports for a controller
  *
  * @dev: Controller containing ports to start
  */
-int achi_start_ports_dm(struct udevice *dev);
+int ahci_start_ports_dm(struct udevice *dev);
 
 /**
  * ahci_init_dm() - init AHCI for a controller, finding all ports
-- 
1.9.1

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

[U-Boot] [PATCH] scsi: ceva: Start port in probe

[Michal Simek]

The patch:
"dm: ahci: Unwind the confusing init code"
(sha1: 7cf1afce7fa3fe64189020fe14b93f7326dd0758)
introduce bug for ceva sata because port didn't start.
On the other hand the dwc_ahci.c was fixed correctly.
Do the same change for ceva too.

Signed-off-by: Michal Simek 
---

 drivers/ata/sata_ceva.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/sata_ceva.c b/drivers/ata/sata_ceva.c
index d582e5ba80f0..3ef7b49215c4 100644
--- a/drivers/ata/sata_ceva.c
+++ b/drivers/ata/sata_ceva.c
@@ -113,11 +113,16 @@ static int ceva_init_sata(ulong mmio)
 
 static int sata_ceva_probe(struct udevice *dev)
 {
+   int ret;
struct scsi_platdata *plat = dev_get_uclass_platdata(dev);
 
ceva_init_sata(plat->base);
 
-   return achi_init_one_dm(dev);
+   ret = achi_init_one_dm(dev);
+   if (ret)
+   return ret;
+
+   return achi_start_ports_dm(dev);
 }
 
 static const struct udevice_id sata_ceva_ids[] = {
-- 
1.9.1

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

[U-Boot] [PATCH v3] DW SPI: Get clock value from Device Tree

[Eugeniy Paltsev]

Add option to set spi controller clock frequency via device tree
using standard clock bindings.
Old way of setting spi controller clock frequency (via implementation
of 'cm_get_spi_controller_clk_hz' function in platform specific code)
remains supported for backward compatibility with targets which don't use
generic clock framework.

Signed-off-by: Eugeniy Paltsev 
---

Marek, Jagan,
How about this implementation?

As both SOCFPGA_GEN5 and SOCFPGA_ARRIA10 don't use generic clock framework,
we can determine way of clock getting based on CONFIG_IS_ENABLED(CLK) macro.

So we don't need any weak functions / soc-specific ifdefs in driver / changes
in SOCFPGA_* stuff.


Changes v2->v3:
  * get rid of soc-specific ifdefs in driver.

Changes v1->v2:
  * disable clock if we can't get the rate.
  * get rid of cm_get_spi_controller_clk_hz weak declaration.

 drivers/spi/designware_spi.c | 69 +++-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 5aa507b..ad64949 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -11,6 +11,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,7 +19,13 @@
 #include 
 #include 
 #include 
+/*
+ * Some targets (like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) which don't implement
+ * generic clock framework and uses their clock_manager functions.
+ */
+#if !CONFIG_IS_ENABLED(OF_CONTROL) || !CONFIG_IS_ENABLED(CLK)
 #include 
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -94,6 +101,7 @@ struct dw_spi_priv {
void __iomem *regs;
unsigned int freq;  /* Default frequency */
unsigned int mode;
+   unsigned long bus_clk_rate;
 
int bits_per_word;
u8 cs;  /* chip select pin */
@@ -176,14 +184,73 @@ static void spi_hw_init(struct dw_spi_priv *priv)
debug("%s: fifo_len=%d\n", __func__, priv->fifo_len);
 }
 
+#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK)
+static int dw_spi_of_get_clk(struct udevice *bus)
+{
+   struct dw_spi_priv *priv = dev_get_priv(bus);
+   struct clk clk;
+   int ret;
+
+   ret = clk_get_by_index(bus, 0, );
+   if (ret)
+   return -EINVAL;
+
+   ret = clk_enable();
+   if (ret && ret != -ENOSYS)
+   return ret;
+
+   priv->bus_clk_rate = clk_get_rate();
+   if (!priv->bus_clk_rate) {
+   clk_disable();
+   return -EINVAL;
+   }
+
+   clk_free();
+
+   return 0;
+}
+#endif
+
+static int dw_spi_get_clk(struct udevice *bus)
+{
+   struct dw_spi_priv *priv = dev_get_priv(bus);
+
+#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK)
+   int ret;
+
+   /* Try to get clock frequency from device tree */
+   ret = dw_spi_of_get_clk(bus);
+   if (ret)
+   return ret;
+#else
+   /*
+* Some targets (like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) don't implement
+* generic clock framework and use cm_get_spi_controller_clk_hz
+* function (defined in asm/arch/clock_manager.h) to get spi controller
+* clock frequency.
+*/
+   priv->bus_clk_rate = cm_get_spi_controller_clk_hz();
+#endif
+
+   if (!priv->bus_clk_rate)
+   return -EINVAL;
+
+   return 0;
+}
+
 static int dw_spi_probe(struct udevice *bus)
 {
struct dw_spi_platdata *plat = dev_get_platdata(bus);
struct dw_spi_priv *priv = dev_get_priv(bus);
+   int ret;
 
priv->regs = plat->regs;
priv->freq = plat->frequency;
 
+   ret = dw_spi_get_clk(bus);
+   if (ret)
+   return ret;
+
/* Currently only bits_per_word == 8 supported */
priv->bits_per_word = 8;
 
@@ -369,7 +436,7 @@ static int dw_spi_set_speed(struct udevice *bus, uint speed)
spi_enable_chip(priv, 0);
 
/* clk_div doesn't support odd number */
-   clk_div = cm_get_spi_controller_clk_hz() / speed;
+   clk_div = priv->bus_clk_rate / speed;
clk_div = (clk_div + 1) & 0xfffe;
dw_writel(priv, DW_SPI_BAUDR, clk_div);
 
-- 
2.9.3

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

Re: [U-Boot] Problem with initialize in mmc_initialize in mmc.c

[Faiz Abbas]

On Monday 30 October 2017 07:37 PM, Faiz Abbas wrote:
> Hi,
> 
> The variable *initialized* in mmc_initialize() is declared as static and
> initialised to 0 in the following commit. This makes the compiler put it
> in the .bss section of the image.
> 
> commit 1b26bab12e85e8b0d382d6775e40d14445249574
> Author: Daniel Kochmański 
> Date:   Fri May 29 16:55:43 2015 +0200
> 
> mmc: Protect `mmc_initialize` from initialising mmc multiple times
> 
> `mmc_initialize` might be called multiple times leading to the
> mmc-controllers being initialised twice, and initialising the
> `mmc_devices` list head twice which may lead to memory leaks.
> 
> Signed-off-by: Daniel Kochmański 
> CC: Roy Spliet 
> Cc: Ian Campbell 
> CC: Pantelis Antoniou 
> Acked-by: Hans de Goede 
> Signed-off-by: Hans de Goede 
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index da47037..f12546a 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1762,6 +1762,11 @@ static void do_preinit(void)
> 
>  int mmc_initialize(bd_t *bis)
>  {
> +   static int initialized = 0;
> +   if (initialized)/* Avoid initializing mmc multiple times */
> +   return 0;
> +   initialized = 1;
> +
> INIT_LIST_HEAD (_devices);
> cur_dev_num = 0;
> 
> 
> .bss should not be accessed in u-boot before relocation because it
> overlaps with fdt and writing to variables in .bss can corrupt the fdt.
> MMC can be probed before relocation if it contains the u-boot
> environment. Therefore, I tried to move this variable to the .data
> section by
> 
> static int initialized __attribute__((section(".data")));
> 
> When *initialized* was a part of .bss it was getting re-initilized to 0
> as a part of relocation. Therefore, mmc was getting probed again
> successfully after relocation with new addresses for mmc devices.
> 
> Now when *initialized* is not a part of .bss, it holds its value across
> relocation and a second call to mmc_initialize() returns without doing
> anything. However, the *mmc_devices* list containing pointers to the
> older locations of mmc devices is not refreshed and thus mmc devices
> fail to enumerate.
> 
> So *initialized* is a problem whether it is in .data or .bss.
> I am not sure how to fix this. Any help is appreciated.

I have been told that all pointers are supposed to be updated during
relocation. Can anyone point to relevant code or example of the same?

Thanks,
Faiz
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mmc: sdhci: don't clear SDHCI_INT_STATUS register during CMD_INHIBIT

[Jorge Ramirez-Ortiz]

Fixes emmc initialization regression on the db410c platform.

Clearing this register while SDHCI_PRESENT_STATE reports
SDHCI_CMD_INHIBIT leads to undefined behaviour on the db410c.

When commit 7dde50 was merged (mmc: sdhci: Wait for SDHCI_INT_DATA_END
when transferring), SDHCI transfers transitioned to wait for bit
SDHCI_INT_DATA_END before flagging transfers done.

Without this patch, the db410 platform fails to initialize its eMMC
due to all of its transfers timing out (SDHCI_INT_DATA_END is never
raised after all the blocks have been transferred).

Signed-off-by: Jorge Ramirez-Ortiz 
---
 drivers/mmc/sdhci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 11d1f0c..f0c5aad 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -157,7 +157,6 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
/* Timeout unit - ms */
static unsigned int cmd_timeout = SDHCI_CMD_DEFAULT_TIMEOUT;
 
-   sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;
 
/* We shouldn't wait for data inihibit for stop commands, even
@@ -181,6 +180,8 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
udelay(1000);
}
 
+   sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS);
+
mask = SDHCI_INT_RESPONSE;
if (!(cmd->resp_type & MMC_RSP_PRESENT))
flags = SDHCI_CMD_RESP_NONE;
-- 
2.7.4

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

Re: [U-Boot] [PATCH] sunxi: lower the DRAM frequency of Nano Pi NEO2 to 504MHz

[Maxime Ripard]

On Thu, Nov 02, 2017 at 11:36:52AM +0800, Icenowy Zheng wrote:
> The BSP of Nano Pi NEO2 provided by FriendlyARM uses 504MHz DRAM
> frequency, which is much lower than the current 672MHz used in
> mainline.
> 
> Switch to use the BSP-provided frequency 504MHz for DRAM.
> 
> Thanks to Thomas Kaiser, who pointed out the frequency problem.

What issue does this patch fix? BSPs have often been way underclocked
in the past.

Did you encounter any corruption?

Maxime

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


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

Re: [U-Boot] [PATCH] sunxi: set the default CPUx frequency of H5 to 816MHz

[Maxime Ripard]

On Wed, Nov 01, 2017 at 08:31:46AM +0800, Icenowy Zheng wrote:
> 在 2017-10-31 21:54，Maxime Ripard 写道：
> > On Tue, Oct 31, 2017 at 04:05:36PM +0800, icen...@aosc.io wrote:
> > > 在 2017-10-31 15:57，Jagan Teki 写道：
> > > > On Tue, Oct 31, 2017 at 5:06 AM, Icenowy Zheng  wrote:
> > > > > Some H5 boards are designed to start at 1.1V CPUx voltage (e.g. Nano
> > > > > Pi
> > > > > NEO2), which may not work properly at 1008MHz if the chip's quality is
> > > > > not so good.
> > > > >
> > > > > Lower the default CPUx frequency of H5 to 816MHz.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng 
> > > > > ---
> > > > >  arch/arm/mach-sunxi/Kconfig | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > > > > index 09cfec6f57..1fededd0a3 100644
> > > > > --- a/arch/arm/mach-sunxi/Kconfig
> > > > > +++ b/arch/arm/mach-sunxi/Kconfig
> > > > > @@ -397,9 +397,9 @@ config SYS_CLK_FREQ
> > > > > default 100800 if MACH_SUN5I
> > > > > default 100800 if MACH_SUN6I
> > > > > default 91200 if MACH_SUN7I
> > > > > +   default 81600 if MACH_SUN50I || MACH_SUN50I_H5
> > > > > default 100800 if MACH_SUN8I
> > > >
> > > > Even orangepi pc2 has 1.1v after power-on and it's work fine [1] did
> > > > you find an issue with neo2?
> > 
> > So you have one single model that fails, and you change the default
> > frequency of all the boards using that SoC?
> 
> But I think we have already set the default frequency to 816MHz for
> A64, and it seems that several H5 boards are designed to start at 1.1v
> (see the notes by Jagan above).
> 
> > 
> > It seems a bit overkill.
> > 
> > I guess we have two solutions:
> >   1) Change the frequency in that board config
> >   2) Change the voltage in that board config
> 
> NEO2 don't have any voltage adjusting, it's fixed at 1.1V.
> 
> And according to the Orange Pi PC2 and Prime schematics, they both
> start at 1.1V. (The Prime schematics even says "For H5 adjust
> VDD-CPUX to 1.1V).

And what about the Zero Plus 2 ?

Maxime

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


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

Re: [U-Boot] [PATCH] sunxi: lower the DRAM frequency of Nano Pi NEO2 to 504MHz

[Jagan Teki]

On Thu, Nov 2, 2017 at 1:57 PM, Icenowy Zheng  wrote:
> 在 2017-11-02 16:25，Jagan Teki 写道：
>>
>> On Thu, Nov 2, 2017 at 9:06 AM, Icenowy Zheng  wrote:
>>>
>>> The BSP of Nano Pi NEO2 provided by FriendlyARM uses 504MHz DRAM
>>> frequency, which is much lower than the current 672MHz used in
>>> mainline.
>>>
>>> Switch to use the BSP-provided frequency 504MHz for DRAM.
>>>
>>> Thanks to Thomas Kaiser, who pointed out the frequency problem.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  configs/nanopi_neo2_defconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/configs/nanopi_neo2_defconfig
>>> b/configs/nanopi_neo2_defconfig
>>> index b8e089176f..e210af4f0e 100644
>>> --- a/configs/nanopi_neo2_defconfig
>>> +++ b/configs/nanopi_neo2_defconfig
>>> @@ -1,7 +1,7 @@
>>>  CONFIG_ARM=y
>>>  CONFIG_ARCH_SUNXI=y
>>>  CONFIG_MACH_SUN50I_H5=y
>>> -CONFIG_DRAM_CLK=672
>>> +CONFIG_DRAM_CLK=504

Did you find this abort[3] with existing master, look like autoboot corrupted

[3] https://paste.ubuntu.com/25872498/

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

[U-Boot] problem with configuration

[pranav prakash]

Hello Sir,
I want networking support in u-boot , In beaglebone black I easily got that. 
But if i want the same in AM3354BZCZD80 processor I am unable to get that 
.while booting from SD-card it is working but i am unable to boot from 
network.can you tell me where and all i have to do the modification to 
configure network booting in AM3354BZCZD80.Or can you give me a source link 
which i can use .



with regards 
pranav
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] video: sunxi: de2: add support for LCD SimpleFB

[Maxime Ripard]

On Wed, Nov 01, 2017 at 10:18:07PM +0800, Icenowy Zheng wrote:
> Add support for setting up SimpleFB for LCD display output in DE2
> SimpleFB setup code.
> 
> Signed-off-by: Icenowy Zheng 

Acked-by: Maxime Ripard 

Maxime

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


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

Re: [U-Boot] [PATCH v2 1/2] video: sunxi: de2: fix SimpleFB node creation when HDMI not initialized

[Maxime Ripard]

On Wed, Nov 01, 2017 at 10:18:06PM +0800, Icenowy Zheng wrote:
> When HDMI is not initialized (e.g. no monitor is plugged), the current
> SimpleFB code will still create a broken SimpleFB node.
> 
> Detect whether HDMI is initialized when creating SimpleFB node.
> 
> Fixes: be5b96f0e411 ("sunxi: setup simplefb for Allwinner DE2")
> Signed-off-by: Icenowy Zheng 

Acked-by: Maxime Ripard 

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


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

Re: [U-Boot] [PATCH 0/2] Disable hybrid mode for SPANSION S25FS-S family

[Rajat Srivastava]

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Tuesday, October 31, 2017 1:32 PM
> To: Rajat Srivastava 
> Cc: u-boot@lists.denx.de; York Sun ; Suresh Gupta
> 
> Subject: Re: [PATCH 0/2] Disable hybrid mode for SPANSION S25FS-S family
> 
> On Mon, Oct 30, 2017 at 5:23 PM, Rajat Srivastava 
> wrote:
> >> On Mon, Oct 30, 2017 at 11:52 AM, Jagan Teki
> >> 
> >> wrote:
> >> > On Mon, Oct 16, 2017 at 12:54 PM, Rajat Srivastava
> >> >  wrote:
> >> >> The S25FS-S family physical sectors may be configured as a hybrid
> >> >> combination of eight 4-kB parameter sectors at the top or bottom
> >> >> of the address space with all but one of the remaining sectors
> >> >> being uniform size. The default status of the flash is the hybrid
> >> >> architecture.
> >> >>
> >> >> Since the parameter sectors and the uniform sectors have different
> >> >> erase commands, it is a problem to implement erase functionality
> >> >> for hybrid mode in current U-boot code. Also, enabling hybrid mode
> >> >> doesn't provide any significant benefit.
> >> >
> >> > I think I've asked this question before, keeping the state of the
> >> > flash remains same. Can't erase parameter and uniform sectors
> >> > individually during operations like
> >> > - parameter sectors with erase commands (20h or 21h)
> >> > - uniform sectors with erase commands (D8h or DCh)
> >>
> >> I understand that even we can do parameter and uniform sectors
> >> individually with the help of offsets we still have 224. Any idea why
> >> we need hybrid mode with this off 244 sector size? if require we can even
> write cypress on this case.
> >>
> > Hi Jagan
> >
> > I am not aware of usage of the remaining 244 sector area. We will discuss 
> > this
> with Cypress.
> >
> > Moreover, do you have any idea where we apply offset based checks in code?
> And if we do apply checks, will that look good with current Uboot code?
> > I think no one is going to use hybrid mode and even if someone wants to, 
> > they
> can modify the code.
> 
> We can change the erase opcode based on the offsets in erase ops, since if we
> disable hybrid now, if someone want to re-enable for another reason (say some
> kind of protection PB, not sure) will end-up conflict. Better we can ask 
> Cypress
> about this and mean while we can post this change on spi-nor Linux for further
> discussion.
> 
Thanks Jagan. I am working on creating a similar patch in Linux.

Best regards
Rajat
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] disk: part_dos: fix part_get_info_extended() function

[Shawn Guo]

From: Shawn Guo 

The check in part_get_info_extended() for a successful partition
searching misses a condition for extended partition. In case of
(ext_part_sector == 0), we should anyway mark the partition as found,
even if it's an extended partition, i.e. (is_extended(pt->sys_ind) == 0).
Otherwise, the extended partition (type 0x0f) will never be identified,
and the following recursive call to part_get_info_extended() will get a
wrong 'part_num' and 'which_part' parameter.  In the end, all those
partitions in extended table will not be identified.

Let's add the missing OR condition of (ext_part_sector == 0) for
is_extended() check to fix the problem.

The issue is discovered by running fastboot flash to an extended
partition on eMMC.

  $ fastboot flash mmcsda5 cache.img
  target reported max download size of 536870912 bytes
  sending 'mmcsda5' (18796 KB)...
  OKAY [  2.144s]
  writing 'mmcsda5'...
  FAILED (remote: cannot find partition)
  finished. total time: 2.261s

Signed-off-by: Shawn Guo 
---
 disk/part_dos.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk/part_dos.c b/disk/part_dos.c
index 1a36be0446ac..4485eb704852 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -210,7 +210,7 @@ static int part_get_info_extended(struct blk_desc *dev_desc,
if (((pt->boot_ind & ~0x80) == 0) &&
(pt->sys_ind != 0) &&
(part_num == which_part) &&
-   (is_extended(pt->sys_ind) == 0)) {
+   (ext_part_sector == 0 || is_extended(pt->sys_ind) == 0)) {
info->blksz = DOS_PART_DEFAULT_SECTOR;
info->start = (lbaint_t)(ext_part_sector +
le32_to_int(pt->start4));
-- 
1.9.1

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

Re: [U-Boot] About the way to fix platform specific issue in source file xhci.c (U-Boot)

[Ran Wang]

Hi Bin,

> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Thursday, November 02, 2017 4:37 PM
> To: Ran Wang 
> Cc: Marek Vasut ; Marek Vasut
> ; open list 
> Subject: Re: [U-Boot] About the way to fix platform specific issue in source
> file xhci.c (U-Boot)
> 
> Hi Ran,
> 
> On Thu, Nov 2, 2017 at 10:29 AM, Ran Wang  wrote:
> > Hi Bin,
> >
> >> -Original Message-
> >> From: Bin Meng [mailto:bmeng...@gmail.com]
> >> Sent: Wednesday, November 01, 2017 6:08 PM
> >> To: Marek Vasut 
> >> Cc: Ran Wang ; Marek Vasut
> >> ; open list 
> >> Subject: Re: [U-Boot] About the way to fix platform specific issue in
> >> source file xhci.c (U-Boot)
> >>
> >> Hi Ran,
> >>
> >> On Wed, Nov 1, 2017 at 4:19 PM, Marek Vasut  wrote:
> >> > On 11/01/2017 07:22 AM, Ran Wang wrote:
> >> >> Hi Marek,
> >> >>
> >> >>> -Original Message-
> >> >>> From: Ran Wang
> >> >>> Sent: Wednesday, November 01, 2017 9:05 AM
> >> >>> To: Marek Vasut ; Marek Vasut
> >> 
> >> >>> Cc: open list 
> >> >>> Subject: RE: [U-Boot] About the way to fix platform specific
> >> >>> issue in source file xhci.c (U-Boot)
> >> >>>
> >> >>> Hi Marek,
> >>  -Original Message-
> >>  From: Marek Vasut [mailto:ma...@denx.de]
> >>  Sent: Tuesday, October 31, 2017 6:24 PM
> >>  To: Ran Wang ; Marek Vasut
> >> >>> 
> >>  Cc: open list ; Bin Meng
> >>  
> >>  Subject: Re: [U-Boot] About the way to fix platform specific
> >>  issue in source file xhci.c (U-Boot)
> >> 
> >>  On 10/31/2017 10:43 AM, Ran Wang wrote:
> >> > Hi
> >> >> -Original Message-
> >> >> From: Marek Vasut [mailto:marek.va...@gmail.com]
> >> >> Sent: Tuesday, October 31, 2017 5:31 PM
> >> >> To: Ran Wang ; Marek Vasut
> >> 
> >> >> Cc: open list 
> >> >> Subject: Re: [U-Boot] About the way to fix platform specific
> >> >> issue in source file xhci.c (U-Boot)
> >> >>
> >> >> On 10/31/2017 10:15 AM, Ran Wang wrote:
> >> >>> Hi Marek,
> >> >>
> >> >> Hi!
> >> >>
> >>  -Original Message-
> >>  From: Marek Vasut [mailto:ma...@denx.de]
> >>  Sent: Monday, October 30, 2017 6:55 PM
> >>  To: Ran Wang 
> >>  Cc: bmeng...@gmail.com
> >>  Subject: Re: About the way to fix platform specific issue in
> >>  source file xhci.c
> >>  (U-Boot)
> >> 
> >>  On 10/30/2017 09:39 AM, Ran Wang wrote:
> >> > Hi Vasut,
> >> >For git://git.denx.de/u-boot-usb.git, I work out a patch
> >> > to fix USB issue
> >>  which will happen on SoC LS2080A only (it's using DWC3).
> >> >Per my understanding, we should not use platform define
> >> > in xhci.c to
> >>  control its effect. However, I am not sure how to do it that
> >>  can be accepted by upstream, so send you this mail for
> >>  suggestion before I post the patch to patchwork. Thank you
> >>  in
> >> advance.
> >> 
> >>  This should be fixed in common code, not in drivers.
> >> >>>
> >> >>> Did you mean it should be fixed in common/usb*.c rather than
> >> >> drivers/usb/*?
> >> >>
> >> >> Yes
> >> >>
> >> >>> If yes, is it acceptable that I use 'if
> >> >>> defined(CONFIG_ARCH_LS2080A)' in
> >> >> common/usb.c?
> >> >>
> >> >> No
> >> >>
> >> >>> If answer is no, how should I do? I cannot find an example
> >> >>> and not sure it's OK to related rule.
> >> >>
> >> >> What is the problem exactly ?
> >> >> I recall there were reports of shitty USB sticks failing, but
> >> >> without further details, it's hard to tell if this is the same 
> >> >> problem.
> >> >>
> >> > We observed some USB2.0 drives (Transcend 8GB, 4GB, Samtec)
> >> > fail to be enumerated by U-Boot, and if we try to add some time
> >> > interval between control transfers (not in bulk transfers),
> >> > issue get
> >> resolved.
> >> 
> >>  Try disabling cache support, does it still happen ?
> >>  I had such an issue with DWC2 controller and it failed due to
> >>  incorrect cache handling.
> >> 
> >> >>> Could you pls tell me where to disable it on DWC3? May sure I do
> >> >>> the right change.
> >> >>
> >> >> I try to remove function dcache_enable() calling, failure still
> >> >> happen. And I think cache issue might not be able to bypass if I
> >> >> only add
> >> delay in control message sends.
> >> >>
> >> >> More debugging shows that xHC 

Re: [U-Boot] About the way to fix platform specific issue in source file xhci.c (U-Boot)

[Bin Meng]

Hi Ran,

On Thu, Nov 2, 2017 at 10:29 AM, Ran Wang  wrote:
> Hi Bin,
>
>> -Original Message-
>> From: Bin Meng [mailto:bmeng...@gmail.com]
>> Sent: Wednesday, November 01, 2017 6:08 PM
>> To: Marek Vasut 
>> Cc: Ran Wang ; Marek Vasut
>> ; open list 
>> Subject: Re: [U-Boot] About the way to fix platform specific issue in source
>> file xhci.c (U-Boot)
>>
>> Hi Ran,
>>
>> On Wed, Nov 1, 2017 at 4:19 PM, Marek Vasut  wrote:
>> > On 11/01/2017 07:22 AM, Ran Wang wrote:
>> >> Hi Marek,
>> >>
>> >>> -Original Message-
>> >>> From: Ran Wang
>> >>> Sent: Wednesday, November 01, 2017 9:05 AM
>> >>> To: Marek Vasut ; Marek Vasut
>> 
>> >>> Cc: open list 
>> >>> Subject: RE: [U-Boot] About the way to fix platform specific issue
>> >>> in source file xhci.c (U-Boot)
>> >>>
>> >>> Hi Marek,
>>  -Original Message-
>>  From: Marek Vasut [mailto:ma...@denx.de]
>>  Sent: Tuesday, October 31, 2017 6:24 PM
>>  To: Ran Wang ; Marek Vasut
>> >>> 
>>  Cc: open list ; Bin Meng 
>>  Subject: Re: [U-Boot] About the way to fix platform specific issue
>>  in source file xhci.c (U-Boot)
>> 
>>  On 10/31/2017 10:43 AM, Ran Wang wrote:
>> > Hi
>> >> -Original Message-
>> >> From: Marek Vasut [mailto:marek.va...@gmail.com]
>> >> Sent: Tuesday, October 31, 2017 5:31 PM
>> >> To: Ran Wang ; Marek Vasut
>> 
>> >> Cc: open list 
>> >> Subject: Re: [U-Boot] About the way to fix platform specific
>> >> issue in source file xhci.c (U-Boot)
>> >>
>> >> On 10/31/2017 10:15 AM, Ran Wang wrote:
>> >>> Hi Marek,
>> >>
>> >> Hi!
>> >>
>>  -Original Message-
>>  From: Marek Vasut [mailto:ma...@denx.de]
>>  Sent: Monday, October 30, 2017 6:55 PM
>>  To: Ran Wang 
>>  Cc: bmeng...@gmail.com
>>  Subject: Re: About the way to fix platform specific issue in
>>  source file xhci.c
>>  (U-Boot)
>> 
>>  On 10/30/2017 09:39 AM, Ran Wang wrote:
>> > Hi Vasut,
>> >For git://git.denx.de/u-boot-usb.git, I work out a patch to
>> > fix USB issue
>>  which will happen on SoC LS2080A only (it's using DWC3).
>> >Per my understanding, we should not use platform define in
>> > xhci.c to
>>  control its effect. However, I am not sure how to do it that
>>  can be accepted by upstream, so send you this mail for
>>  suggestion before I post the patch to patchwork. Thank you in
>> advance.
>> 
>>  This should be fixed in common code, not in drivers.
>> >>>
>> >>> Did you mean it should be fixed in common/usb*.c rather than
>> >> drivers/usb/*?
>> >>
>> >> Yes
>> >>
>> >>> If yes, is it acceptable that I use 'if
>> >>> defined(CONFIG_ARCH_LS2080A)' in
>> >> common/usb.c?
>> >>
>> >> No
>> >>
>> >>> If answer is no, how should I do? I cannot find an example and
>> >>> not sure it's OK to related rule.
>> >>
>> >> What is the problem exactly ?
>> >> I recall there were reports of shitty USB sticks failing, but
>> >> without further details, it's hard to tell if this is the same 
>> >> problem.
>> >>
>> > We observed some USB2.0 drives (Transcend 8GB, 4GB, Samtec) fail
>> > to be enumerated by U-Boot, and if we try to add some time
>> > interval between control transfers (not in bulk transfers), issue get
>> resolved.
>> 
>>  Try disabling cache support, does it still happen ?
>>  I had such an issue with DWC2 controller and it failed due to
>>  incorrect cache handling.
>> 
>> >>> Could you pls tell me where to disable it on DWC3? May sure I do the
>> >>> right change.
>> >>
>> >> I try to remove function dcache_enable() calling, failure still
>> >> happen. And I think cache issue might not be able to bypass if I only add
>> delay in control message sends.
>> >>
>> >> More debugging shows that xHC will generate TRB event with complete
>> >> code of TX_ERR for Set
>>
>> Do you mean xHC "Address Device" command?
>
> Yes
>>
>> >> Address command TRB execution. Then U-Boot pop "USB device not
>> >> accepting new address (error=8000)".
>> >>
>>
>> What is the completion codes for the TX_ERR you were seeing?
>
> It's 0x04: USB Transaction Error
>>

OK, I see.

>> >> Anyway, now I work out a patch fix in common/usb.c as below, is it
>> acceptable?
>> >> diff --git a/common/usb.c b/common/usb.c index
>> 0904259757..26f2e89ba3
>> >> 100644
>> >> --- a/common/usb.c
>> >> +++ b/common/usb.c
>> >> @@ -223,6 +223,8 @@ int 

Re: [U-Boot] [PATCH] sunxi: lower the DRAM frequency of Nano Pi NEO2 to 504MHz

[Icenowy Zheng]

在 2017-11-02 16:25，Jagan Teki 写道：

On Thu, Nov 2, 2017 at 9:06 AM, Icenowy Zheng  wrote:

The BSP of Nano Pi NEO2 provided by FriendlyARM uses 504MHz DRAM
frequency, which is much lower than the current 672MHz used in
mainline.

Switch to use the BSP-provided frequency 504MHz for DRAM.

Thanks to Thomas Kaiser, who pointed out the frequency problem.

Signed-off-by: Icenowy Zheng 
---
 configs/nanopi_neo2_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/nanopi_neo2_defconfig 
b/configs/nanopi_neo2_defconfig

index b8e089176f..e210af4f0e 100644
--- a/configs/nanopi_neo2_defconfig
+++ b/configs/nanopi_neo2_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN50I_H5=y
-CONFIG_DRAM_CLK=672
+CONFIG_DRAM_CLK=504


Can you point me the BSP, here what I refer to have [1]


The file at [1] is just from mainline.

The BSP configuration is at [2].

[2] 
https://github.com/friendlyarm/h5_lichee/blob/master/tools/pack/chips/sun50iw2p1/configs/cheetah-p1/board/sys_config_nanopi-neo2.fex




[1]
https://github.com/friendlyarm/u-boot/blob/sunxi-v2017.x/configs/nanopi_neo2_defconfig

thanks!

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

Re: [U-Boot] [PATCH] sunxi: lower the DRAM frequency of Nano Pi NEO2 to 504MHz

[Jagan Teki]

On Thu, Nov 2, 2017 at 9:06 AM, Icenowy Zheng  wrote:
> The BSP of Nano Pi NEO2 provided by FriendlyARM uses 504MHz DRAM
> frequency, which is much lower than the current 672MHz used in
> mainline.
>
> Switch to use the BSP-provided frequency 504MHz for DRAM.
>
> Thanks to Thomas Kaiser, who pointed out the frequency problem.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  configs/nanopi_neo2_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/nanopi_neo2_defconfig b/configs/nanopi_neo2_defconfig
> index b8e089176f..e210af4f0e 100644
> --- a/configs/nanopi_neo2_defconfig
> +++ b/configs/nanopi_neo2_defconfig
> @@ -1,7 +1,7 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_MACH_SUN50I_H5=y
> -CONFIG_DRAM_CLK=672
> +CONFIG_DRAM_CLK=504

Can you point me the BSP, here what I refer to have [1]

[1] 
https://github.com/friendlyarm/u-boot/blob/sunxi-v2017.x/configs/nanopi_neo2_defconfig

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

Re: [U-Boot] [PATCH 1/2] common: Generic file system firmware loader

[Chee, Tien Fong]

On Rab, 2017-11-01 at 10:26 +0100, Marek Vasut wrote:
> On 11/01/2017 10:18 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Generic firmware loader framework contains some common
> > functionality
> > which is factored out from splash loader. It is reusable by any
> > specific driver file system firmware loader. Specific driver file
> > system
> > firmware loader handling can be defined with both weak function
> > fsloader_preprocess and fs_loading.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  common/Makefile   |   1 +
> >  common/load_fs.c  | 217
> > ++
> >  include/load_fs.h |  38 ++
> >  3 files changed, 256 insertions(+)
> >  create mode 100644 common/load_fs.c
> >  create mode 100644 include/load_fs.h
> [...]
> 
> > 
> > +int flash_select_fs_dev(struct flash_location *location)
> Why does everything have flash_ prefix ?
> 
I can remove the flash_ prefix, this generic FS loader should support
for all filesystem instead of flash.

> I also mentioned the API should copy the linux firmware loader API.
> 
If i'm not mistaken, you are referring firmware loader API in this
link https://github.com/torvalds/linux/blob/f007cad159e99fa2acd3b2e9364
fbb32ad28b971/drivers/base/firmware_class.c#L1264.

Actually we have almost same framework in filesystem loader portion,
just different implementation, and Linux firmware loader is more
specific to Linux environment such as hard code path searching in RFS.
The generic FS loader in this patch is much more flexible, let user to
define their own prefer implementation.
 Linux FS firmware loader  <--->   U-Boot FS firmware loader
--       ---
1) request_firmware flash_load_fs
2) _request_firmware_prepare          weak fsloader_preprocess
3) fw_get_filesystem_firmware          weak fs_loading                
         
> > +   int res;
> > +
> > +   switch (location->storage) {
> > +   case FLASH_STORAGE_MMC:
> > +   res = fs_set_blk_dev("mmc", location->devpart,
> > FS_TYPE_ANY);
> > +   break;
> > +   case FLASH_STORAGE_USB:
> > +   res = fs_set_blk_dev("usb", location->devpart,
> > FS_TYPE_ANY);
> > +   break;
> > +   case FLASH_STORAGE_SATA:
> > +   res = fs_set_blk_dev("sata", location->devpart,
> > FS_TYPE_ANY);
> > +   break;
> > +   case FLASH_STORAGE_NAND:
> > +   if (location->ubivol != NULL)
> > +   res = fs_set_blk_dev("ubi", NULL,
> > FS_TYPE_UBIFS);
> > +   else
> > +   res = -ENODEV;
> > +   break;
> > +   default:
> > +   error("Error: unsupported location storage.\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   if (res)
> > +   error("Error: could not access storage.\n");
> > +
> > +   return res;
> > +}
> > +
> > +#ifndef CONFIG_SPL_BUILD
> > +#ifdef CONFIG_USB_STORAGE
> This looks wrong, the USB can be supported in SPL no problem. And
> this
Technically, USB can be supported in SPL, but the build for USB in SPL
is not supported yet.
> USB init shouldn't be duplicated here IMO.
> 
This is just for the case USB init is not yet started, but loader is
called 1st.
> > 
> > +static int flash_init_usb(void)
> > +{
> > +   int err;
> > +
> > +   err = usb_init();
> > +   if (err)
> > +   return err;
> > +
> > +#ifndef CONFIG_DM_USB
> > +   err = usb_stor_scan(1) < 0 ? -ENODEV : 0;
> > +#endif
> > +
> > +   return err;
> > +}
> > +#else
> > +static inline int flash_init_usb(void)
> Don't use inline , the compiler can decide better.
> 
Okay.
> [...]
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Enable HDMI on i.MX6 without VPU

[Nikolay Petukhov]

Hi Stefano,

On i.MX6 SoCs without VPU(MCIMX6Q4AVT10AD) the HDMI is not working.
That's because hdmi_isfr's parent clock, video_27m, is not correctly
ungated.

The video_27m clock is gated by CCM_CCGR3[CG8] - mipi_core_cfg_clk_enable.

On i.MX6 SoCs with VPU, the HDMI is working thanks to the
CCM_CMEOR[mod_en_ov_vpu] bit which makes the video_27m ungated whatever
is in CCM_CCGR3[CG8].

This patch make the HDMI to work in every case by gating the mipi_core_cfg
clock.

Signed-off-by: Nikolay Petukhov 
Cc: Stefano Babic sba...@denx.de
---
 arch/arm/mach-imx/mx6/soc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index b724668..8b976f7 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -655,6 +655,11 @@ void imx_setup_hdmi(void)
 int reg, count;
 u8 val;

+/* Turn on MIPI core cfg clock */
+reg = readl(_ccm->CCGR3);
+reg |= MXC_CCM_CCGR3_MIPI_CORE_CFG_MASK;
+writel(reg, _ccm->CCGR3);
+
 /* Turn on HDMI PHY clock */
 reg = readl(_ccm->CCGR2);
 reg |=  MXC_CCM_CCGR2_HDMI_TX_IAHBCLK_MASK|
-- 
2.7.4





2017-10-31 15:33 GMT+05:00 Stefano Babic :

> Hi Nikolay,
>
> On 10/10/2017 16:27, Nikolay Petukhov wrote:
> > Hi, all
> >
> > This patch enables HDMI on CPU without VPU.
> > A similar patch for the mainline
> > kernel:https://patchwork.kernel.org/patch/9874831/
> > Tested on MCIMX6Q4AVT10AD.
> >
>
> This is stored in the commit message if I apply. Please rewrite the
> commit message to be suitable for inclusion.
>
> >
> > Signed-off-by: Nikolay Petukhov  > >
> > Cc: Stefano Babic sba...@denx.de 
> > ---
> >  arch/arm/mach-imx/mx6/soc.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
> > index b724668..8b976f7 100644
> > --- a/arch/arm/mach-imx/mx6/soc.c
> > +++ b/arch/arm/mach-imx/mx6/soc.c
> > @@ -655,6 +655,11 @@ void imx_setup_hdmi(void)
> >  int reg, count;
> >  u8 val;
> >
> > +/* Turn on MIPI core cfg clock */
> > +reg = readl(_ccm->CCGR3);
> > +reg |= MXC_CCM_CCGR3_MIPI_CORE_CFG_MASK;
> > +writel(reg, _ccm->CCGR3);
> > +
> >  /* Turn on HDMI PHY clock */
> >  reg = readl(_ccm->CCGR2);
> >  reg |=  MXC_CCM_CCGR2_HDMI_TX_IAHBCLK_MASK|
> > --
> > 2.7.4
> >
> >
>
> 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
> =
>



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

Re: [U-Boot] [PATCH 1/3] spl: set SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR to 0x4000 for rockchip

[Jagan Teki]

On Thu, Nov 2, 2017 at 12:46 PM, Kever Yang  wrote:
> Rockchip use a 'loader2' partition for U-Boot, so u-boot.bin or
> u-boot.itb load by SPL need to locate at0x4000. Detail here:
> http://opensource.rock-chips.com/wiki_Boot_option

Sorry, I'm not clear is this because of arm64 itb?  and we should have
16320 sectors in between SPL and U-Boot which is huge isn't it?

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

[U-Boot] [PATCH 3/3] rockchip: remove SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR from defconfig

[Kever Yang]

Use default value 0x4000 for SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR instead
of define a new one.

Signed-off-by: Kever Yang 
---

 configs/evb-rk3399_defconfig | 1 -
 configs/firefly-rk3399_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 7a0bd4a..a6c5b82 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -12,7 +12,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_GPT=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index 94b9209..c942072 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -12,7 +12,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_SPL_ATF_SUPPORT=y
 CONFIG_SPL_ATF_TEXT_BASE=0x0001
 CONFIG_CMD_BOOTZ=y
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] rockchip: doc: update U-Boot location info

[Kever Yang]

Update rockchip U-Boot location to 0x4000/16384.

Signed-off-by: Kever Yang 
---

 doc/README.rockchip | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index 4b7be0b..9d5af3d 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -99,13 +99,13 @@ To write an image that boots from an SD card (assumed to be 
/dev/sdc):
./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
sudo dd if=out of=/dev/sdc seek=64 && \
-   sudo dd if=firefly-rk3288/u-boot-dtb.img of=/dev/sdc seek=256
+   sudo dd if=firefly-rk3288/u-boot-dtb.img of=/dev/sdc seek=16384
 
 This puts the Rockchip header and SPL image first and then places the U-Boot
-image at block 256 (i.e. 128KB from the start of the SD card). This
+image at block 16384 (i.e. 4MB from the start of the SD card). This
 corresponds with this setting in U-Boot:
 
-   #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 256
+   #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x4000
 
 Put this SD (or micro-SD) card into your board and reset it. You should see
 something like:
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] spl: set SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR to 0x4000 for rockchip

[Kever Yang]

Rockchip use a 'loader2' partition for U-Boot, so u-boot.bin or
u-boot.itb load by SPL need to locate at0x4000. Detail here:
http://opensource.rock-chips.com/wiki_Boot_option

Signed-off-by: Kever Yang 
---

 common/spl/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0bd8370..e987c07 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -142,11 +142,12 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
default 0x50 if ARCH_SUNXI
default 0x75 if ARCH_DAVINCI
default 0x8a if ARCH_MX6
-   default 0x100 if ARCH_ROCKCHIP || ARCH_UNIPHIER
+   default 0x100 if ARCH_UNIPHIER
default 0x140 if ARCH_MVEBU
default 0x200 if ARCH_SOCFPGA || ARCH_AT91
default 0x300 if ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || OMAP44XX || \
 OMAP54XX || AM33XX || AM43XX
+   default 0x4000 if ARCH_ROCKCHIP
help
  Address on the MMC to load U-Boot from, when the MMC is being used
  in raw mode. Units: MMC sectors (1 sector = 512 bytes).
-- 
1.9.1

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