Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

2018-08-21 Thread Bin Meng
Hi Marek,

On Tue, Aug 21, 2018 at 1:43 PM, Marek Vasut  wrote:
> On 08/21/2018 06:56 AM, Bin Meng wrote:
> [...]
>> The proposal I made is:
>>
>> * Keep pci-uclass driver's post_bind() and child_post_bind() only for
>> Sandbox configuration
>> * Keep the call to pci_bus_find_devfn() in pci_bind_bus_devices() only
>> for Sandbox configuration
>> * Sandbox is special. We should limit the mechanism of matching PCI
>> emulation device via "compatible" to sandbox only
>
> The above three points can be done separately and I don't care about
> this too much.
>

 That's my concern. Only doing this created confusing and incomplete
 design.
>>>
>>> Incomplete how ?
>>
>> I explained several times. I have to repeat here once again:
>>
>> Currently U-Boot supports two scenarios for PCI driver binding:
>>
>> - Declare a PCI device in the device tree. That requires specifying a
>> 'compatible' string as well as 'reg' property as defined by the 'PCI
>> Bus Binding' spec. DM uses the 'compatible' string to bind the driver
>> for the device.
>> - Don't declare a PCI device in the device tree. Instead, using
>> U_BOOT_PCI_DEVICE() to declare a device and driver mapping.
>>
>> You are creating a 3rd scenario which is a mix up of both scenario#1
>> and #2 in this patch, yet without any documentation, plus any
>> additional changes to impacted drivers.
>
> I am extending both, it's not a "third scenario".
>
> I said in the previous discussion I am willing to update the
> documentation to match the implementation, but that's about it.
>
>> So far almost all PCI device drivers in U-Boot supports both
>> scenarios, except PCI UART which currently only supports scenario#1.
>> If you declare what you do in this patch is pureblood then you should
>> revoke the other 2 at the same time. Leaving such in the mainstream
>> only creates chaos in the future and we should avoid doing that, given
>> we already had lots of discussion here.
>
> No. The compatible is valid for some PCI subdevs, ie. bridges, so that
> has to stay. You also need compatible for sandbox, you said that
> yourself. And declaring a PCI device with BFD in DT is needed, ie. for
> the r8a7794-style bindings.
>

OK, now new comments :) So you admit "compatible" can be valid for
some cases. I have to point out that your theory on PCI device probing
is self-contradictory. You refuse to add a "compatible" string to your
PCI device because you said the vendor/device id/class provides enough
information to bind the driver, then why do you want to specify your
devices in the device tree in the first place. According to your
theory, "Each PCI device already has a PCI ID and class which is used
to identify it and based on which the drivers bind to it, so a DT
compatible is NOT needed and is actually redundant and harmful.", I
would argue why not just creating a dedicate PCI device driver using
PCI ID and class information to do the driver binding and start from
there. As you mentioned PCI bus is probable bus like USB, everything
can be self-contained in the PCI device driver itself. There is no
need to create nothing in the device tree. If you want an example,
check 8250_pci.c in the Linux kernel. Everything that is needed to
configure the driver is included in the driver itself. It does not
read anything from the device tree.

> So again, how is the state of PCI more incomplete with this patch than
> without it ?
>
 Yes, you probably don't care about this. But I care about this
 as it impacts some other things like PCI uart driver which is used by
 some x86 boards.
>>>
>>> Sandbox changes impact PCI UART driver and x86 boards how ?
>>
>> See above. It's not about sandbox!
>
> So what is it about ? And how does this core change impact anything ?
> Does it change behavior for some board or break some tests for you ?
>
>> * Create DM PCI test case against the DT node assignment
>> * Remove all compatible string in U-Boot's PCI device drivers: eg:
>> ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers
>> should only use U_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
>> * Fork a "pci-ns16550" driver to support U_BOOT_PCI_DEVICE(), as
>> currently PCI ns16550 device driver uses "compatible" string to do the
>> matching, and update crownbay.dts and galileo.dts (so far I only know
>> two boards are using PCI ns16550 serial port)
>> * Make sure all DM PCI test cases are not broken
>> * Document all of the above changes in doc/driver-model/pci-info.txt
>
> I think you're just adding completely orthogonal stuff to this 5-liner
> patch into the list and overly complicate the situation. Sure, if you
> want to do all this, go ahead, but I don't see how this prevents this
> particular patch from being applied , except maybe for the documentation
> tweak.

 Please, think from the maintainer perspective. It's nothing related to

[U-Boot] [PATCH 0/8][RESEND] Device Tree support for PowerPC in u-boot

2018-08-21 Thread Jagdish Gediya
In current implementation, PowerPC does not support device tree in u-boot.
This patch enables device tree support for PowerPC platform .

T2080AQDS board used as first platform.
  
Dtb is embedded in the u-boot following below steps using binmam tool.
  
1. Remove bootpg and resetvec section if required
2. Append dtb using binman
3. Append bootpg and resetvec section back if removed in 1st step.
  
To enable binman tool, 'binman' node  has been added in the device tree.

Resend with adding missed u-boot mailing list

Jagdish Gediya (8):
  powerpc/dts: setup fdt blob at __init_end
  powerpc/dts: makefile changes to clean and build dts
  binman: Add a new "start-pos" property in section class
  binman: Add support for powerpc 'bootpg + resetvec' entry
  powerpc: mpc85xx: select BINMAN by default
  powerpc: dts: add u-boot.dtsi and mpc85xx-u-boot.dtsi
  powerpc: mpc85xx: Use binman to embed dtb inside u-boot
  powerpc: dts: Enable device tree support for T2080QDS

 Makefile  | 30 -
 arch/powerpc/Kconfig  |  1 +
 arch/powerpc/cpu/mpc8xxx/fdt.c| 12 +
 arch/powerpc/dts/Makefile | 14 ++
 arch/powerpc/dts/e6500_power_isa.dtsi | 39 
 arch/powerpc/dts/mpc85xx-u-boot.dtsi  | 16 +++
 arch/powerpc/dts/t2080qds.dts | 17 +++
 arch/powerpc/dts/t2080qds.dtsi| 64 +++
 arch/powerpc/dts/u-boot.dtsi  | 31 +
 board/freescale/t208xqds/README   | 17 +++
 configs/T2080QDS_NAND_defconfig   |  3 +-
 configs/T2080QDS_SDCARD_defconfig |  3 +-
 configs/T2080QDS_SPIFLASH_defconfig   |  3 +-
 configs/T2080QDS_defconfig|  3 +-
 dts/Makefile  |  2 +-
 tools/binman/bsection.py  | 13 +-
 tools/binman/etype/mpc85xx_bootpg_resetvec.py | 15 +++
 17 files changed, 274 insertions(+), 9 deletions(-)
 create mode 100644 arch/powerpc/dts/Makefile
 create mode 100644 arch/powerpc/dts/e6500_power_isa.dtsi
 create mode 100644 arch/powerpc/dts/mpc85xx-u-boot.dtsi
 create mode 100644 arch/powerpc/dts/t2080qds.dts
 create mode 100644 arch/powerpc/dts/t2080qds.dtsi
 create mode 100644 arch/powerpc/dts/u-boot.dtsi
 create mode 100644 tools/binman/etype/mpc85xx_bootpg_resetvec.py

-- 
2.7.4

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


[U-Boot] [PATCH 1/8][RESEND] powerpc/dts: setup fdt blob at __init_end

2018-08-21 Thread Jagdish Gediya
'__init_end' is defined in ld file. define 'board_fdt_blob_setup'
to setup the fdt blob at '&__init_end'.

Signed-off-by: Jagdish Gediya 
---
 arch/powerpc/cpu/mpc8xxx/fdt.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
index 0d877c4..a7f61fe 100644
--- a/arch/powerpc/cpu/mpc8xxx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -19,6 +20,17 @@
 #define CONFIG_USB_MAX_CONTROLLER_COUNT1
 #endif
 
+#ifdef CONFIG_OF_SEPARATE
+void *board_fdt_blob_setup(void)
+{
+   void *fdt_blob = NULL;
+
+   fdt_blob = (ulong *)&__init_end;
+
+   return fdt_blob;
+}
+#endif
+
 #if defined(CONFIG_MP) && (defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx))
 static int ft_del_cpuhandle(void *blob, int cpuhandle)
 {
-- 
2.7.4

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


[U-Boot] [PATCH 2/8][RESEND] powerpc/dts: makefile changes to clean and build dts

2018-08-21 Thread Jagdish Gediya
Signed-off-by: Jagdish Gediya 
---
 arch/powerpc/dts/Makefile | 12 
 dts/Makefile  |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/dts/Makefile

diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
new file mode 100644
index 000..de14e7b
--- /dev/null
+++ b/arch/powerpc/dts/Makefile
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+targets += $(dtb-y)
+
+# Add any required device tree compiler flags here
+DTC_FLAGS +=
+
+PHONY += dtbs
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+   @:
+
+clean-files := *.dtb
diff --git a/dts/Makefile b/dts/Makefile
index 36dfbe7..9a9a3d5 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -61,4 +61,4 @@ dtbs: $(obj)/dt.dtb $(obj)/dt-spl.dtb
 clean-files := dt.dtb.S dt-spl.dtb.S
 
 # Let clean descend into dts directories
-subdir- += ../arch/arm/dts ../arch/microblaze/dts ../arch/mips/dts 
../arch/sandbox/dts ../arch/x86/dts
+subdir- += ../arch/arm/dts ../arch/microblaze/dts ../arch/mips/dts 
../arch/sandbox/dts ../arch/x86/dts ../arch/powerpc/dts
-- 
2.7.4

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


[U-Boot] [PATCH 3/8][RESEND] binman: Add a new "start-pos" property in section class

2018-08-21 Thread Jagdish Gediya
currently binman calculates '_skip_at_start' based on 'end-at-4gb'
property and it is used for x86 images.

for powerpc architecture also, '_skip_at_start' should be set because
memory address 0xeff4 or 0xfff4 is the first entry offset.
'end-at-4gb' property is not applicable for 0xeff4 first entry
offset.

add new property start-pos' in section class so that
'_skip_at_start' can be calculated either based on 'end-at-4gb'
or based on 'start-pos'

Signed-off-by: Jagdish Gediya 
---
 tools/binman/bsection.py | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/binman/bsection.py b/tools/binman/bsection.py
index a0bd1b6..71f276d 100644
--- a/tools/binman/bsection.py
+++ b/tools/binman/bsection.py
@@ -40,6 +40,10 @@ class Section(object):
 used for x86 images, which want to use offsets such that a memory
 address (like 0xff80) is the first entry offset. This causes
 _skip_at_start to be set to the starting memory address.
+_start_pos: For powerpc, memory address 0xeff4 or 0xfff4 is the
+first entry offset. _end_4gb is not re-usable if first entry offset
+is 0xeff4. _start_pos causes _skip_at_start to be set to the
+starting memory address.
 _name_prefix: Prefix to add to the name of all entries within this
 section
 _entries: OrderedDict() of entries
@@ -61,6 +65,7 @@ class Section(object):
 self._sort = False
 self._skip_at_start = 0
 self._end_4gb = False
+self._start_pos = 0
 self._name_prefix = ''
 self._entries = OrderedDict()
 if not test:
@@ -79,10 +84,14 @@ class Section(object):
 self._pad_byte = fdt_util.GetInt(self._node, 'pad-byte', 0)
 self._sort = fdt_util.GetBool(self._node, 'sort-by-offset')
 self._end_4gb = fdt_util.GetBool(self._node, 'end-at-4gb')
-if self._end_4gb and not self._size:
-self._Raise("Section size must be provided when using end-at-4gb")
+self._start_pos = fdt_util.GetInt(self._node, 'start-pos', 0)
+if (self._end_4gb or self._start_pos) and not self._size:
+self._Raise("Section size must be provided when using end-at-4gb 
or "
+"start-pos")
 if self._end_4gb:
 self._skip_at_start = 0x1 - self._size
+if self._start_pos:
+self._skip_at_start = self._start_pos
 self._name_prefix = fdt_util.GetString(self._node, 'name-prefix')
 
 def _ReadEntries(self):
-- 
2.7.4

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


[U-Boot] [PATCH 4/8][RESEND] binman: Add support for powerpc 'bootpg + resetvec' entry

2018-08-21 Thread Jagdish Gediya
This entry contains the powerpc boot page and resetvec sections.

Signed-off-by: Jagdish Gediya 
---
 tools/binman/etype/mpc85xx_bootpg_resetvec.py | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 tools/binman/etype/mpc85xx_bootpg_resetvec.py

diff --git a/tools/binman/etype/mpc85xx_bootpg_resetvec.py 
b/tools/binman/etype/mpc85xx_bootpg_resetvec.py
new file mode 100644
index 000..d76fe95
--- /dev/null
+++ b/tools/binman/etype/mpc85xx_bootpg_resetvec.py
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2018 NXP
+#
+# Entry-type module for the mpc85xx bootpg and resetvec code for U-Boot
+#
+
+from entry import Entry
+from blob import Entry_blob
+
+class Entry_mpc85xx_bootpg_resetvec(Entry_blob):
+def __init__(self, section, etype, node):
+Entry_blob.__init__(self, section, etype, node)
+
+def GetDefaultFilename(self):
+return 'u-boot-br.bin'
-- 
2.7.4

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


[U-Boot] [PATCH 7/8][RESEND] powerpc: mpc85xx: Use binman to embed dtb inside u-boot

2018-08-21 Thread Jagdish Gediya
Below is the sequence to embed dtb inside u-boot,
1. Remove bootpg and resetvec section if needed
2. Append dtb
3. Append bootpg and resetvec section back if removed previously

Above procedure is required only when CONFIG_MPC85xx,
CONFIG_BINMAN and CONFIG_OF_SEPARATE are defined.

set PPC_MPC85XX_INCLUDE_DTB variable in Makefile if binman
need to be used.

set PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC variable in Makefile
if bootpg and resetvec section need to be removed before appending
dtb.

Signed-off-by: Jagdish Gediya 
---
 Makefile | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 884b7d9..aad9dca 100644
--- a/Makefile
+++ b/Makefile
@@ -797,6 +797,13 @@ else
 DO_STATIC_RELA =
 endif
 
+ifeq ($(CONFIG_MPC85xx)$(CONFIG_BINMAN)$(CONFIG_OF_SEPARATE),yyy)
+PPC_MPC85XX_INCLUDE_DTB := y
+ifeq ($(CONFIG_SYS_MPC85XX_NO_RESETVEC)$(CONFIG_NAND),)
+PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC := y
+endif
+endif
+
 # Always append ALL so that arch config.mk's can add custom ones
 ALL-y += u-boot.srec u-boot.bin u-boot.sym System.map binary_size_check
 
@@ -837,6 +844,10 @@ ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
 ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
 endif
 
+ifeq ($(PPC_MPC85XX_INCLUDE_DTB),y)
+ALL-y += u-boot-dtb.bin
+endif
+
 # Build a combined spl + u-boot image for sunxi
 ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
 ALL-y += u-boot-sunxi-with-spl.bin
@@ -938,7 +949,7 @@ u-boot-fit-dtb.bin: u-boot-nodtb.bin fit-dtb.blob
 
 u-boot.bin: u-boot-fit-dtb.bin FORCE
$(call if_changed,copy)
-else ifeq ($(CONFIG_OF_SEPARATE),y)
+else ifeq ($(CONFIG_OF_SEPARATE)$(PPC_MPC85XX_INCLUDE_DTB),y)
 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
 
@@ -979,7 +990,8 @@ spl/u-boot-spl.srec: spl/u-boot-spl FORCE
$(call if_changed,objcopy)
 
 OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
-   $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec)
+   $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
+   $(if $(PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC),-R .bootpg -R 
.resetvec)
 
 binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
@@ -1222,6 +1234,18 @@ u-boot-x86-16bit.bin: u-boot FORCE
$(call if_changed,objcopy)
 endif
 
+ifeq ($(PPC_MPC85XX_INCLUDE_DTB), y)
+u-boot-dtb.bin: u-boot.bin u-boot.dtb \
+   $(if $(PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC), u-boot-br.bin) FORCE
+   $(call if_changed,binman)
+
+ifeq ($(PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC),y)
+OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j .resetvec
+u-boot-br.bin: u-boot FORCE
+   $(call if_changed,objcopy)
+endif
+endif
+
 ifneq ($(CONFIG_ARCH_SUNXI),)
 ifeq ($(CONFIG_ARM64),)
 u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.img u-boot.dtb FORCE
@@ -1291,6 +1315,8 @@ spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE
 
 ifeq ($(ARCH),arm)
 UBOOT_BINLOAD := u-boot.img
+else ifeq ($(PPC_MPC85XX_INCLUDE_DTB),y)
+UBOOT_BINLOAD := u-boot-dtb.bin
 else
 UBOOT_BINLOAD := u-boot.bin
 endif
-- 
2.7.4

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


[U-Boot] [PATCH 8/8][RESEND] powerpc: dts: Enable device tree support for T2080QDS

2018-08-21 Thread Jagdish Gediya
Add device tree for T2080QDS board and enable CONFIG_OF_CONTROL
so that device tree can be compiled.

update board README for device tree usage.

Signed-off-by: Jagdish Gediya 
---
 arch/powerpc/dts/Makefile |  2 ++
 arch/powerpc/dts/e6500_power_isa.dtsi | 39 +
 arch/powerpc/dts/t2080qds.dts | 17 ++
 arch/powerpc/dts/t2080qds.dtsi| 64 +++
 board/freescale/t208xqds/README   | 17 ++
 configs/T2080QDS_NAND_defconfig   |  3 +-
 configs/T2080QDS_SDCARD_defconfig |  3 +-
 configs/T2080QDS_SPIFLASH_defconfig   |  3 +-
 configs/T2080QDS_defconfig|  3 +-
 9 files changed, 147 insertions(+), 4 deletions(-)
 create mode 100644 arch/powerpc/dts/e6500_power_isa.dtsi
 create mode 100644 arch/powerpc/dts/t2080qds.dts
 create mode 100644 arch/powerpc/dts/t2080qds.dtsi

diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
index de14e7b..a19aa56 100644
--- a/arch/powerpc/dts/Makefile
+++ b/arch/powerpc/dts/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 
+dtb-$(CONFIG_TARGET_T2080QDS) += t2080qds.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/powerpc/dts/e6500_power_isa.dtsi 
b/arch/powerpc/dts/e6500_power_isa.dtsi
new file mode 100644
index 000..1b06170
--- /dev/null
+++ b/arch/powerpc/dts/e6500_power_isa.dtsi
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * e6500 Power ISA Device Tree Source (include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ * Copyright 2018 NXP
+ */
+
+/ {
+   cpus {
+   power-isa-version = "2.06";
+   power-isa-b;// Base
+   power-isa-e;// Embedded
+   power-isa-atb;  // Alternate Time Base
+   power-isa-cs;   // Cache Specification
+   power-isa-ds;   // Decorated Storage
+   power-isa-e.ed; // Embedded.Enhanced Debug
+   power-isa-e.pd; // Embedded.External PID
+   power-isa-e.hv; // Embedded.Hypervisor
+   power-isa-e.le; // Embedded.Little-Endian
+   power-isa-e.pm; // Embedded.Performance Monitor
+   power-isa-e.pc; // Embedded.Processor Control
+   power-isa-ecl;  // Embedded Cache Locking
+   power-isa-exp;  // External Proxy
+   power-isa-fp;   // Floating Point
+   power-isa-fp.r; // Floating Point.Record
+   power-isa-mmc;  // Memory Coherence
+   power-isa-scpm; // Store Conditional Page Mobility
+   power-isa-wt;   // Wait
+   power-isa-64;   // 64-bit
+   power-isa-e.pt; // Embedded.Page Table
+   power-isa-e.hv.lrat;// Embedded.Hypervisor.LRAT
+   power-isa-e.em; // Embedded Multi-Threading
+   power-isa-v;// Vector (AltiVec)
+   fsl,eref-er;// Enhanced Reservations
+   fsl,eref-deo;   // Data Cache Extended Operations
+   mmu-type = "power-embedded";
+   };
+};
diff --git a/arch/powerpc/dts/t2080qds.dts b/arch/powerpc/dts/t2080qds.dts
new file mode 100644
index 000..bf8cb23
--- /dev/null
+++ b/arch/powerpc/dts/t2080qds.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * T2080QDS Device Tree Source
+ *
+ * Copyright 2013 - 2015 Freescale Semiconductor Inc.
+ * Copyright 2018 NXP
+ */
+
+/include/ "t2080qds.dtsi"
+
+/ {
+   model = "fsl,T2080QDS";
+   compatible = "fsl,T2080QDS";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&mpic>;
+};
diff --git a/arch/powerpc/dts/t2080qds.dtsi b/arch/powerpc/dts/t2080qds.dtsi
new file mode 100644
index 000..2006dec
--- /dev/null
+++ b/arch/powerpc/dts/t2080qds.dtsi
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * T2080/T2081 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ * Copyright 2018 NXP
+ */
+
+/dts-v1/;
+
+/include/ "e6500_power_isa.dtsi"
+
+/ {
+   model = "fsl,T2080QDS";
+   compatible = "fsl,T2080QDS";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&mpic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: PowerPC,e6500@0 {
+   device_type = "cpu";
+   reg = <0 1>;
+   fsl,portid-mapping = <0x8000>;
+   };
+   cpu1: PowerPC,e6500@2 {
+   device_type = "cpu";
+   reg = <2 3>;
+   fsl,portid-mapping = <0x8000>;
+   };
+   cpu2: PowerPC,e6500@4 {
+  

[U-Boot] [PATCH 6/8][RESEND] powerpc: dts: add u-boot.dtsi and mpc85xx-u-boot.dtsi

2018-08-21 Thread Jagdish Gediya
add required binman node inside dts to use binman to prepare
u-boot-dtb.bin

Signed-off-by: Jagdish Gediya 
---
 arch/powerpc/dts/mpc85xx-u-boot.dtsi | 16 
 arch/powerpc/dts/u-boot.dtsi | 31 +++
 2 files changed, 47 insertions(+)
 create mode 100644 arch/powerpc/dts/mpc85xx-u-boot.dtsi
 create mode 100644 arch/powerpc/dts/u-boot.dtsi

diff --git a/arch/powerpc/dts/mpc85xx-u-boot.dtsi 
b/arch/powerpc/dts/mpc85xx-u-boot.dtsi
new file mode 100644
index 000..637db11
--- /dev/null
+++ b/arch/powerpc/dts/mpc85xx-u-boot.dtsi
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP
+ */
+
+#include 
+
+/ {
+#if defined(CONFIG_BINMAN)
+   binman {
+   u-boot-with-ucode-ptr {
+   optional-ucode;
+   };
+   };
+#endif
+};
diff --git a/arch/powerpc/dts/u-boot.dtsi b/arch/powerpc/dts/u-boot.dtsi
new file mode 100644
index 000..ebe160f
--- /dev/null
+++ b/arch/powerpc/dts/u-boot.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP
+ */
+
+#include 
+
+/ {
+#if defined(CONFIG_BINMAN) && defined(CONFIG_MPC85xx)
+   binman {
+   filename = "u-boot-dtb.bin";
+   start-pos = ;
+   sort-by-pos;
+   pad-byte = <0xff>;
+   size = ;
+
+   u-boot-with-ucode-ptr {
+   offset = ;
+   };
+
+   u-boot-dtb-with-ucode {
+   align = <256>;
+   };
+#if !defined(CONFIG_SYS_MPC85XX_NO_RESETVEC) && !defined(CONFIG_NAND)
+   mpc85xx-bootpg-resetvec {
+   offset = <(CONFIG_RESET_VECTOR_ADDRESS - 0xffc)>;
+   };
+#endif
+   };
+#endif
+};
-- 
2.7.4

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


[U-Boot] [PATCH 5/8][RESEND] powerpc: mpc85xx: select BINMAN by default

2018-08-21 Thread Jagdish Gediya
Signed-off-by: Jagdish Gediya 
---
 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8faef0b..c727d91 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -20,6 +20,7 @@ config MPC85xx
select CREATE_ARCH_SYMLINK
select SYS_FSL_DDR
select SYS_FSL_DDR_BE
+   select BINMAN
imply CMD_HASH
imply CMD_IRQ
imply USB_EHCI_HCD if USB
-- 
2.7.4

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


Re: [U-Boot] Booting into winCE .nb0 without access to source files

2018-08-21 Thread Andy Pont

Michael wrote...

I have an awkward situation, short of it is we have a custom i.MX53 
board, the nk.nb0 and eboot.nb0 files to boot into windows (with no 
source code), and an Ubuntu VM with the source code and compiled files 
of uboot from august 2009 (as well as some flavour of linux that I'm 
not 100% sure on). I need to figure out a way to boot into either the 
nk.nb0 or eboot.nb0 so that we can run our software.
eboot.nb0 is the Windows CE bootloader and probably needs to be executed 
first.  The nk.nb0 file is the actual Windows CE image itself.  
Depending on the hardware configuration it may be that these are images 
that are copied as-is to RAM or could be XIP images for execution 
directly from flash if the hardware supports it and is configured that 
way.


Based on my research so far, I am hopeful that I may be able to have 
uboot start either eboot.nb0 or nk.nb0, and it won't crash the hardware 
in the process (we don't have the resources to do more in depth 
troubleshooting of the board design or re-write our software for the 
linux version).
This may not be successful.  One or both of the .nb0 files will contain 
hardware initialisation code and it may be that the initialisation 
provided by U-Boot causes a conflict.


If you want to contact me off list to discuss Windows CE specifics then 
we have the expertise to maybe help you move this forward.


-Andy.

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


Re: [U-Boot] [PATCH 1/3] x86: Include bss subsections in linker script

2018-08-21 Thread Bin Meng
On Mon, Aug 20, 2018 at 8:32 PM, Alexander Graf  wrote:
> When we build with -fdata-sections we may end up with bss subsections. Our
> linker script explicitly lists only a single consecutive bss section though.
>
> Adapt the statement to also include subsections.
>
> This fixes booting efi-x86_app_defconfig.
>
> Signed-off-by: Alexander Graf 
> ---
>  arch/x86/cpu/u-boot-64.lds  | 2 +-
>  arch/x86/cpu/u-boot.lds | 2 +-
>  arch/x86/lib/elf_ia32_efi.lds   | 2 +-
>  arch/x86/lib/elf_x86_64_efi.lds | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>

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


Re: [U-Boot] [PATCH 2/3] x86: Enable -fdata-sections always

2018-08-21 Thread Bin Meng
On Mon, Aug 20, 2018 at 8:32 PM, Alexander Graf  wrote:
> We left -fdata-sections disabled for x86_64 before because we encountered
> random bugs that were at that time inexplicable.
>
> Turns out this really was just side effects of missing .bss* statements
> in the linker scripts. With those fixed, we can enable data sections for all
> targets.
>
> Signed-off-by: Alexander Graf 
> ---
>  arch/x86/config.mk | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>

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


Re: [U-Boot] [PATCH 04/10] Add UCLASS_TEE for Trusted Execution Environment

2018-08-21 Thread Jens Wiklander
Hi Simon,

On Fri, Aug 17, 2018 at 06:48:47AM -0600, Simon Glass wrote:
> Hi Jens,
> 
> On 13 August 2018 at 09:53, Jens Wiklander  wrote:
> > Adds a uclass to interface with a TEE (Trusted Execution Environment).
> >
> > A TEE driver is a driver that interfaces with a trusted OS running in
> > some secure environment, for example, TrustZone on ARM cpus, or a
> > separate secure co-processor etc.
> >
> > The TEE subsystem can serve a TEE driver for a Global Platform compliant
> > TEE, but it's not limited to only Global Platform TEEs.
> >
> > The over all design is based on the TEE subsystem in the Linux kernel,
> > tailored for U-boot.
> >
> > Signed-off-by: Jens Wiklander 
> > ---
> >  MAINTAINERS  |   6 ++
> >  drivers/Kconfig  |   2 +
> >  drivers/Makefile |   1 +
> >  drivers/tee/Kconfig  |   8 ++
> >  drivers/tee/Makefile |   3 +
> >  drivers/tee/tee-uclass.c | 180 +++
> >  include/dm/uclass-id.h   |   1 +
> >  include/tee.h| 134 +
> >  8 files changed, 335 insertions(+)
> >  create mode 100644 drivers/tee/Kconfig
> >  create mode 100644 drivers/tee/Makefile
> >  create mode 100644 drivers/tee/tee-uclass.c
> >  create mode 100644 include/tee.h
> >
> 
> Please add a sandbox driver and a test in test/dm for any new uclass.

OK

> 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 58b61ac05882..7458c606ee92 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -571,6 +571,12 @@ TQ GROUP
> >  S: Orphaned (Since 2016-02)
> >  T: git git://git.denx.de/u-boot-tq-group.git
> >
> > +TEE
> > +M: Jens Wiklander 
> > +S: Maintained
> > +F: drivers/tee/
> > +F: include/tee.h
> > +
> >  UBI
> >  M: Kyungmin Park 
> >  M: Heiko Schocher 
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index c72abf893297..f3249ab1d143 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -94,6 +94,8 @@ source "drivers/spmi/Kconfig"
> >
> >  source "drivers/sysreset/Kconfig"
> >
> > +source "drivers/tee/Kconfig"
> > +
> >  source "drivers/thermal/Kconfig"
> >
> >  source "drivers/timer/Kconfig"
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index d53208540ea6..0fcae36f50f7 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -103,6 +103,7 @@ obj-y += smem/
> >  obj-y += soc/
> >  obj-$(CONFIG_REMOTEPROC) += remoteproc/
> >  obj-y += thermal/
> > +obj-$(CONFIG_TEE) += tee/
> >
> >  obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
> >  endif
> > diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
> > new file mode 100644
> > index ..817ab331b0f8
> > --- /dev/null
> > +++ b/drivers/tee/Kconfig
> > @@ -0,0 +1,8 @@
> > +# Generic Trusted Execution Environment Configuration
> > +config TEE
> > +   bool "Trusted Execution Environment support"
> > +   depends on ARM && (ARM64 || CPU_V7A)
> > +   select ARM_SMCCC
> > +   help
> > + This implements a generic interface towards a Trusted Execution
> > + Environment (TEE).
> > diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
> > new file mode 100644
> > index ..b6d8e16e6211
> > --- /dev/null
> > +++ b/drivers/tee/Makefile
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +obj-y += tee-uclass.o
> > diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
> > new file mode 100644
> > index ..f0243a0f2e4e
> > --- /dev/null
> > +++ b/drivers/tee/tee-uclass.c
> > @@ -0,0 +1,180 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2018 Linaro Limited
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct tee_uclass_priv {
> > +   struct list_head list_shm;
> 
> Struct comment please
> 
> > +};
> > +
> > +static const struct tee_driver_ops *tee_get_ops(struct udevice *dev)
> > +{
> > +   return device_get_ops(dev);
> > +}
> > +
> > +void tee_get_version(struct udevice *dev, struct tee_version_data *vers)
> > +{
> > +   tee_get_ops(dev)->get_version(dev, vers);
> > +}
> > +
> > +int tee_open_session(struct udevice *dev, struct tee_open_session_arg *arg,
> > +ulong num_param, struct tee_param *param)
> > +{
> > +   return tee_get_ops(dev)->open_session(dev, arg, num_param, param);
> > +}
> > +
> > +int tee_close_session(struct udevice *dev, u32 session)
> > +{
> > +   return tee_get_ops(dev)->close_session(dev, session);
> > +}
> > +
> > +int tee_invoke_func(struct udevice *dev, struct tee_invoke_arg *arg,
> > +   ulong num_param, struct tee_param *param)
> > +{
> > +   return tee_get_ops(dev)->invoke_func(dev, arg, num_param, param);
> > +}
> > +
> > +struct tee_shm *__tee_shm_add(struct udevice *dev, ulong align, void *addr,
> > + ulong size, u32 flags)
> > +{
> > +   struct tee_shm *shm;
> > +   void *p = addr;
> > +
> > +   if (flags & TEE_SHM_ALLOC) {
> > +  

[U-Boot] [PATCH u-boot-marvell v3 04/12] board: turris_mox: Fixup U-Boot's device tree if PCIe connected

2018-08-21 Thread Marek Behún
If PCIe Mox module is connected we want to have PCIe node enabled
in U-Boot's device tree.

Signed-off-by: Marek Behun 
---
 arch/arm/dts/armada-3720-turris-mox.dts |  7 +++
 board/CZ.NIC/turris_mox/turris_mox.c| 82 +
 configs/turris_mox_defconfig|  1 +
 3 files changed, 90 insertions(+)

diff --git a/arch/arm/dts/armada-3720-turris-mox.dts 
b/arch/arm/dts/armada-3720-turris-mox.dts
index bef100afce..a817f20920 100644
--- a/arch/arm/dts/armada-3720-turris-mox.dts
+++ b/arch/arm/dts/armada-3720-turris-mox.dts
@@ -130,3 +130,10 @@
vbus-supply = <®_usb3_vbus>;
status = "okay";
 };
+
+&pcie0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pcie_pins>;
+   reset-gpio = <&gpiosb 3 GPIO_ACTIVE_HIGH>;
+   status = "disabled";
+};
diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index b6a0ca4626..c4622a49c2 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -4,17 +4,99 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_WDT_ARMADA_37XX
 #include 
 #endif
 
+#define MAX_MOX_MODULES10
+
+#define MOX_MODULE_SFP 0x1
+#define MOX_MODULE_PCI 0x2
+#define MOX_MODULE_TOPAZ   0x3
+#define MOX_MODULE_PERIDOT 0x4
+#define MOX_MODULE_USB30x5
+#define MOX_MODULE_PASSPCI 0x6
+
+#define ARMADA_37XX_NB_GPIO_SEL0xd0013830
+#define ARMADA_37XX_SPI_CTRL   0xd0010600
+#define ARMADA_37XX_SPI_CFG0xd0010604
+#define ARMADA_37XX_SPI_DOUT   0xd0010608
+#define ARMADA_37XX_SPI_DIN0xd001060c
+
+#define PCIE_PATH  "/soc/pcie@d007"
+
 DECLARE_GLOBAL_DATA_PTR;
 
+#if defined(CONFIG_OF_BOARD_FIXUP)
+int board_fix_fdt(void *blob)
+{
+   u8 topology[MAX_MOX_MODULES];
+   int i, size, node;
+   bool enable;
+
+   /*
+* SPI driver is not loaded in driver model yet, but we have to find out
+* if pcie should be enabled in U-Boot's device tree. Therefore we have
+* to read SPI by reading/writing SPI registers directly
+*/
+
+   writel(0x563fa, ARMADA_37XX_NB_GPIO_SEL);
+   writel(0x10df, ARMADA_37XX_SPI_CFG);
+   writel(0x2005b, ARMADA_37XX_SPI_CTRL);
+
+   while (!(readl(ARMADA_37XX_SPI_CTRL) & 0x2))
+   udelay(1);
+
+   for (i = 0; i < MAX_MOX_MODULES; ++i) {
+   writel(0x0, ARMADA_37XX_SPI_DOUT);
+
+   while (!(readl(ARMADA_37XX_SPI_CTRL) & 0x2))
+   udelay(1);
+
+   topology[i] = readl(ARMADA_37XX_SPI_DIN) & 0xff;
+   if (topology[i] == 0xff)
+   break;
+
+   topology[i] &= 0xf;
+   }
+
+   size = i;
+
+   writel(0x5b, ARMADA_37XX_SPI_CTRL);
+
+   if (size > 1 && (topology[1] == MOX_MODULE_PCI ||
+topology[1] == MOX_MODULE_USB3 ||
+topology[1] == MOX_MODULE_PASSPCI))
+   enable = true;
+   else
+   enable = false;
+
+   node = fdt_path_offset(blob, PCIE_PATH);
+
+   if (node < 0) {
+   printf("Cannot find PCIe node in U-Boot's device tree!\n");
+   return 0;
+   }
+
+   if (fdt_setprop_string(blob, node, "status",
+  enable ? "okay" : "disabled") < 0) {
+   printf("Cannot %s PCIe in U-Boot's device tree!\n",
+  enable ? "enable" : "disable");
+   return 0;
+   }
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_WDT_ARMADA_37XX
 static struct udevice *watchdog_dev;
 
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index de9aedc764..47ab914ce9 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -13,6 +13,7 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_ARCH_EARLY_INIT_R=y
+CONFIG_OF_BOARD_FIXUP=y
 CONFIG_CMD_CLK=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_I2C=y
-- 
2.16.4

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


Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

2018-08-21 Thread Marek Vasut
On 08/21/2018 09:16 AM, Bin Meng wrote:
> Hi Marek,
> 
> On Tue, Aug 21, 2018 at 1:43 PM, Marek Vasut  wrote:
>> On 08/21/2018 06:56 AM, Bin Meng wrote:
>> [...]
>>> The proposal I made is:
>>>
>>> * Keep pci-uclass driver's post_bind() and child_post_bind() only for
>>> Sandbox configuration
>>> * Keep the call to pci_bus_find_devfn() in pci_bind_bus_devices() only
>>> for Sandbox configuration
>>> * Sandbox is special. We should limit the mechanism of matching PCI
>>> emulation device via "compatible" to sandbox only
>>
>> The above three points can be done separately and I don't care about
>> this too much.
>>
>
> That's my concern. Only doing this created confusing and incomplete
> design.

 Incomplete how ?
>>>
>>> I explained several times. I have to repeat here once again:
>>>
>>> Currently U-Boot supports two scenarios for PCI driver binding:
>>>
>>> - Declare a PCI device in the device tree. That requires specifying a
>>> 'compatible' string as well as 'reg' property as defined by the 'PCI
>>> Bus Binding' spec. DM uses the 'compatible' string to bind the driver
>>> for the device.
>>> - Don't declare a PCI device in the device tree. Instead, using
>>> U_BOOT_PCI_DEVICE() to declare a device and driver mapping.
>>>
>>> You are creating a 3rd scenario which is a mix up of both scenario#1
>>> and #2 in this patch, yet without any documentation, plus any
>>> additional changes to impacted drivers.
>>
>> I am extending both, it's not a "third scenario".
>>
>> I said in the previous discussion I am willing to update the
>> documentation to match the implementation, but that's about it.
>>
>>> So far almost all PCI device drivers in U-Boot supports both
>>> scenarios, except PCI UART which currently only supports scenario#1.
>>> If you declare what you do in this patch is pureblood then you should
>>> revoke the other 2 at the same time. Leaving such in the mainstream
>>> only creates chaos in the future and we should avoid doing that, given
>>> we already had lots of discussion here.
>>
>> No. The compatible is valid for some PCI subdevs, ie. bridges, so that
>> has to stay. You also need compatible for sandbox, you said that
>> yourself. And declaring a PCI device with BFD in DT is needed, ie. for
>> the r8a7794-style bindings.
>>
> 
> OK, now new comments :) So you admit "compatible" can be valid for
> some cases.

_some_ select ones, and that is a _very_ important distinction.

> I have to point out that your theory on PCI device probing
> is self-contradictory.You refuse to add a "compatible" string to your
> PCI device because you said the vendor/device id/class provides enough
> information to bind the driver, then why do you want to specify your
> devices in the device tree in the first place.

Because of the USB PHY , which is attached to that device and can not be
probed on the PCI bus, unlike the device itself ?

> According to your
> theory, "Each PCI device already has a PCI ID and class which is used
> to identify it and based on which the drivers bind to it, so a DT
> compatible is NOT needed and is actually redundant and harmful.", I
> would argue why not just creating a dedicate PCI device driver using
> PCI ID and class information to do the driver binding and start from
> there.

Because the same device with the same PCI ID can be used without that PHY .

> As you mentioned PCI bus is probable bus like USB, everything
> can be self-contained in the PCI device driver itself. There is no
> need to create nothing in the device tree. If you want an example,
> check 8250_pci.c in the Linux kernel. Everything that is needed to
> configure the driver is included in the driver itself. It does not
> read anything from the device tree.

Well, see above for why this approach doesn't work.

>> So again, how is the state of PCI more incomplete with this patch than
>> without it ?
>>
> Yes, you probably don't care about this. But I care about this
> as it impacts some other things like PCI uart driver which is used by
> some x86 boards.

 Sandbox changes impact PCI UART driver and x86 boards how ?
>>>
>>> See above. It's not about sandbox!
>>
>> So what is it about ? And how does this core change impact anything ?
>> Does it change behavior for some board or break some tests for you ?
>>
>>> * Create DM PCI test case against the DT node assignment
>>> * Remove all compatible string in U-Boot's PCI device drivers: eg:
>>> ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers
>>> should only use U_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
>>> * Fork a "pci-ns16550" driver to support U_BOOT_PCI_DEVICE(), as
>>> currently PCI ns16550 device driver uses "compatible" string to do the
>>> matching, and update crownbay.dts and galileo.dts (so far I only know
>>> two boards are using PCI ns16550 serial port)
>>> * Make sure all DM PCI test cases are not broken

[U-Boot] [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb board.

2018-08-21 Thread Pramod Kumar
ls1088ardb-pb is another varinat of the ls1088ardb.
This board support two m.2 x2 gen 3 pcie card slot.
There is no support of sata, pcie standard slot,
miniPCIE slot and TDM in this board.

Signed-off-by: Pramod Kumar 
---
Changes in v2:
 - Fix the compilation issue when building u-boot for SD boot.

 arch/arm/Kconfig  |  14 +++
 arch/arm/cpu/armv8/Kconfig|   1 +
 board/freescale/ls1088a/Kconfig   |  43 +++
 board/freescale/ls1088a/MAINTAINERS   |  18 +++
 board/freescale/ls1088a/Makefile  |   1 +
 board/freescale/ls1088a/ddr.h |   6 +-
 board/freescale/ls1088a/ls1088a.c |  25 +++-
 ... ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} |   2 +-
 ...defconfig => ls1088ardb_pb_qspi_defconfig} |   2 +-
 ...ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} |   2 +-
 ...ig => ls1088ardb_pb_sdcard_qspi_defconfig} |   2 +-
 include/configs/ls1088ardb_pb.h   | 113 ++
 12 files changed, 219 insertions(+), 10 deletions(-)
 copy configs/{ls1088ardb_qspi_SECURE_BOOT_defconfig => 
ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} (97%)
 copy configs/{ls1088ardb_qspi_defconfig => ls1088ardb_pb_qspi_defconfig} (97%)
 copy configs/{ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig => 
ls1088ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} (98%)
 copy configs/{ls1088ardb_sdcard_qspi_defconfig => 
ls1088ardb_pb_sdcard_qspi_defconfig} (98%)
 create mode 100644 include/configs/ls1088ardb_pb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 63ec02403a..a653823934 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1120,6 +1120,20 @@ config TARGET_LS1088ARDB
  development platform that supports the QorIQ LS1088A
  Layerscape Architecture processor.
 
+config TARGET_LS1088ARDB_PB
+bool "Support ls1088ardb_pb"
+select ARCH_LS1088A
+select ARM64
+select ARMV8_MULTIENTRY
+select ARCH_MISC_INIT
+select BOARD_LATE_INIT
+select SUPPORT_SPL
+help
+  Support for NXP LS1088ARDB_PB platform.
+  The LS1088A Reference design board (RDB_PB) is a high-performance
+  development platform that supports the QorIQ LS1088A
+  Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
bool "Support ls1021aqds"
select ARCH_LS1021A
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index c8bebabdf6..8ede276b65 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -100,6 +100,7 @@ config PSCI_RESET
   !TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
   !TARGET_LS2080ARDB && !TARGET_LS2080A_EMU && \
   !TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \
+  !TARGET_LS1088ARDB_PB && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1012A2G5RDB && !TARGET_LS1012AQDS && \
   !TARGET_LS1012AFRWY && \
diff --git a/board/freescale/ls1088a/Kconfig b/board/freescale/ls1088a/Kconfig
index 8bb828e3fd..9f20d7247f 100644
--- a/board/freescale/ls1088a/Kconfig
+++ b/board/freescale/ls1088a/Kconfig
@@ -59,3 +59,46 @@ endif
 
 source "board/freescale/common/Kconfig"
 endif
+
+if TARGET_LS1088ARDB_PB
+
+config SYS_BOARD
+   default "ls1088a"
+
+config SYS_VENDOR
+   default "freescale"
+
+config SYS_SOC
+   default "fsl-layerscape"
+
+config SYS_CONFIG_NAME
+   default "ls1088ardb_pb"
+
+if SYS_LS_PPA_FW_IN_XIP
+
+config SYS_LS_PPA_FW_ADDR
+   hex "PPA Firmware Addr"
+   default 0x2040
+
+if CHAIN_OF_TRUST
+config SYS_LS_PPA_ESBC_ADDR
+   hex "PPA Firmware HDR Addr"
+   default 0x2068
+endif
+endif
+
+if (SYS_LS_PPA_FW_IN_MMC || SYS_LS_PPA_FW_IN_NAND)
+
+config SYS_LS_PPA_FW_ADDR
+   hex "PPA Firmware Addr"
+   default 0x40
+
+if CHAIN_OF_TRUST
+config SYS_LS_PPA_ESBC_ADDR
+   hex "PPA Firmware HDR Addr"
+   default 0x68
+endif
+endif
+
+source "board/freescale/common/Kconfig"
+endif
diff --git a/board/freescale/ls1088a/MAINTAINERS 
b/board/freescale/ls1088a/MAINTAINERS
index 4d804d9447..5d841076bc 100644
--- a/board/freescale/ls1088a/MAINTAINERS
+++ b/board/freescale/ls1088a/MAINTAINERS
@@ -7,6 +7,14 @@ F: include/configs/ls1088ardb.h
 F: configs/ls1088ardb_qspi_defconfig
 F: configs/ls1088ardb_sdcard_qspi_defconfig
 
+LS1088ARDB_PB BOARD
+M: Pramod Kumar 
+S: Maintained
+F: board/freescale/ls1088a/
+F: include/configs/ls1088ardb_pb.h
+F: configs/ls1088ardb_pb_qspi_defconfig
+F: configs/ls1088ardb_pb_sdcard_qspi_defconfig
+
 LS1088AQDS BOARD
 M: Prabhakar Kushwaha 
 M: Ashish Kumar 
@@ -34,3 +42,13 @@ LS1088ARDB_SD_SECURE_BOOT BOARD
 M: Sumit Garg 
 S: Maintained
 F: configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig
+
+LS1088ARDB_PB_QSPI_SECURE_BOOT BOARD
+M: Udit Agarwal 
+S: Maintained
+F: configs/ls1088ardb_pb_qspi_SECURE_BOOT_de

[U-Boot] [PATCH] configs: sama5d2_xplained: Add defconfig for ENV/boot from eMMC

2018-08-21 Thread Codrin Ciubotariu
This adds a defconfig for sama5d2_xplained board to get environment from
eMMC. The defconfig is made from sama5d2_xplained_mmc_defconfig, with
'bootcmd' and 'bootargs' changed to kernel, device-tree and rootfs from
eMMC. The environment is expected to be found in eMMC's FAT
partition.

Signed-off-by: Codrin Ciubotariu 
---
 configs/sama5d2_xplained_emmc_defconfig | 88 +
 include/configs/sama5d2_xplained.h  |  4 +-
 2 files changed, 90 insertions(+), 2 deletions(-)
 create mode 100644 configs/sama5d2_xplained_emmc_defconfig

diff --git a/configs/sama5d2_xplained_emmc_defconfig 
b/configs/sama5d2_xplained_emmc_defconfig
new file mode 100644
index 000..ca5d4f42212
--- /dev/null
+++ b/configs/sama5d2_xplained_emmc_defconfig
@@ -0,0 +1,88 @@
+CONFIG_ARM=y
+CONFIG_ARCH_AT91=y
+CONFIG_SYS_TEXT_BASE=0x26f0
+CONFIG_TARGET_SAMA5D2_XPLAINED=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL=y
+CONFIG_DEBUG_UART_BOARD_INIT=y
+CONFIG_DEBUG_UART_BASE=0xf802
+CONFIG_DEBUG_UART_CLOCK=8300
+CONFIG_SPL_FAT_SUPPORT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="at91-sama5d2_xplained"
+CONFIG_DEBUG_UART=y
+CONFIG_ENV_VARS_UBOOT_CONFIG=y
+CONFIG_FIT=y
+CONFIG_SYS_EXTRA_OPTIONS="SAMA5D2,SYS_USE_MMC"
+CONFIG_SD_BOOT=y
+CONFIG_BOOTDELAY=3
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rw 
rootwait"
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_I2C=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma-names"
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_AT91=y
+CONFIG_AT91_UTMI=y
+CONFIG_AT91_H32MX=y
+CONFIG_AT91_GENERIC_CLK=y
+CONFIG_DM_GPIO=y
+CONFIG_ATMEL_PIO4=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_AT91=y
+CONFIG_I2C_EEPROM=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ATMEL=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_DM_ETH=y
+CONFIG_MACB=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_SERIAL=y
+CONFIG_DEBUG_UART_ATMEL=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_ATMEL_USART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_TIMER=y
+CONFIG_SPL_TIMER=y
+CONFIG_ATMEL_PIT_TIMER=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_ATMEL_USBA=y
+CONFIG_DM_VIDEO=y
+CONFIG_ATMEL_HLCD=y
diff --git a/include/configs/sama5d2_xplained.h 
b/include/configs/sama5d2_xplained.h
index b205d8d6045..72bea8cdcf0 100644
--- a/include/configs/sama5d2_xplained.h
+++ b/include/configs/sama5d2_xplained.h
@@ -39,8 +39,8 @@
 /* bootstrap + u-boot + env in sd card */
 #undef CONFIG_BOOTCOMMAND
 
-#define CONFIG_BOOTCOMMAND "fatload mmc 1:1 0x2100 
at91-sama5d2_xplained.dtb; " \
-   "fatload mmc 1:1 0x2200 zImage; " \
+#define CONFIG_BOOTCOMMAND "fatload mmc " CONFIG_ENV_FAT_DEVICE_AND_PART " 
0x2100 at91-sama5d2_xplained.dtb; " \
+   "fatload mmc " CONFIG_ENV_FAT_DEVICE_AND_PART " 
0x2200 zImage; " \
"bootz 0x2200 - 0x2100"
 
 #elif CONFIG_SPI_BOOT
-- 
2.17.1

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


Re: [U-Boot] [PATCH 1/8][RESEND] powerpc/dts: setup fdt blob at __init_end

2018-08-21 Thread Bin Meng
Hi Jagdish,

On Wed, Aug 22, 2018 at 2:18 AM, Jagdish Gediya  wrote:
> '__init_end' is defined in ld file. define 'board_fdt_blob_setup'
> to setup the fdt blob at '&__init_end'.
>
> Signed-off-by: Jagdish Gediya 
> ---
>  arch/powerpc/cpu/mpc8xxx/fdt.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
> index 0d877c4..a7f61fe 100644
> --- a/arch/powerpc/cpu/mpc8xxx/fdt.c
> +++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -19,6 +20,17 @@
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT1
>  #endif
>
> +#ifdef CONFIG_OF_SEPARATE
> +void *board_fdt_blob_setup(void)

Instead of creating an mpc85xx-specific board_fdt_blob_setup(), can we
modify the mpc85xx linker scripts to use common _end symbol instead of
the __init_end symbol so that the generic board_fdt_blob_setup() can
be used?

> +{
> +   void *fdt_blob = NULL;
> +
> +   fdt_blob = (ulong *)&__init_end;
> +
> +   return fdt_blob;
> +}
> +#endif
> +
>  #if defined(CONFIG_MP) && (defined(CONFIG_MPC85xx) || 
> defined(CONFIG_MPC86xx))
>  static int ft_del_cpuhandle(void *blob, int cpuhandle)
>  {
> --

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


Re: [U-Boot] [PATCH 2/8][RESEND] powerpc/dts: makefile changes to clean and build dts

2018-08-21 Thread Bin Meng
On Wed, Aug 22, 2018 at 2:18 AM, Jagdish Gediya  wrote:
> Signed-off-by: Jagdish Gediya 
> ---
>  arch/powerpc/dts/Makefile | 12 
>  dts/Makefile  |  2 +-
>  2 files changed, 13 insertions(+), 1 deletion(-)
>  create mode 100644 arch/powerpc/dts/Makefile
>

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


Re: [U-Boot] [PATCH 4/8][RESEND] binman: Add support for powerpc 'bootpg + resetvec' entry

2018-08-21 Thread Bin Meng
On Wed, Aug 22, 2018 at 2:18 AM, Jagdish Gediya  wrote:
> This entry contains the powerpc boot page and resetvec sections.

Again, PowerPC Book-E or e500 would be better since other PowerPC
variants like 60x (mpc83xx) does not have boot page and resetvec
sections.

>
> Signed-off-by: Jagdish Gediya 
> ---
>  tools/binman/etype/mpc85xx_bootpg_resetvec.py | 15 +++
>  1 file changed, 15 insertions(+)
>  create mode 100644 tools/binman/etype/mpc85xx_bootpg_resetvec.py
>
> diff --git a/tools/binman/etype/mpc85xx_bootpg_resetvec.py 
> b/tools/binman/etype/mpc85xx_bootpg_resetvec.py
> new file mode 100644
> index 000..d76fe95
> --- /dev/null
> +++ b/tools/binman/etype/mpc85xx_bootpg_resetvec.py
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright 2018 NXP
> +#
> +# Entry-type module for the mpc85xx bootpg and resetvec code for U-Boot
> +#
> +
> +from entry import Entry
> +from blob import Entry_blob
> +
> +class Entry_mpc85xx_bootpg_resetvec(Entry_blob):

Please adjust the name here accordingly.

> +def __init__(self, section, etype, node):
> +Entry_blob.__init__(self, section, etype, node)
> +
> +def GetDefaultFilename(self):
> +return 'u-boot-br.bin'
> --

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


Re: [U-Boot] [PATCH 6/8][RESEND] powerpc: dts: add u-boot.dtsi and mpc85xx-u-boot.dtsi

2018-08-21 Thread Bin Meng
On Wed, Aug 22, 2018 at 2:18 AM, Jagdish Gediya  wrote:
> add required binman node inside dts to use binman to prepare

nits: Add

> u-boot-dtb.bin
>
> Signed-off-by: Jagdish Gediya 
> ---
>  arch/powerpc/dts/mpc85xx-u-boot.dtsi | 16 
>  arch/powerpc/dts/u-boot.dtsi | 31 +++
>  2 files changed, 47 insertions(+)
>  create mode 100644 arch/powerpc/dts/mpc85xx-u-boot.dtsi
>  create mode 100644 arch/powerpc/dts/u-boot.dtsi
>
> diff --git a/arch/powerpc/dts/mpc85xx-u-boot.dtsi 
> b/arch/powerpc/dts/mpc85xx-u-boot.dtsi
> new file mode 100644
> index 000..637db11
> --- /dev/null
> +++ b/arch/powerpc/dts/mpc85xx-u-boot.dtsi
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018 NXP
> + */
> +
> +#include 
> +
> +/ {
> +#if defined(CONFIG_BINMAN)
> +   binman {
> +   u-boot-with-ucode-ptr {
> +   optional-ucode;
> +   };
> +   };
> +#endif

Please merge this into the u-boot.dtsi, as you already used the #ifdef
there for MPC85xx only.

> +};
> diff --git a/arch/powerpc/dts/u-boot.dtsi b/arch/powerpc/dts/u-boot.dtsi
> new file mode 100644
> index 000..ebe160f
> --- /dev/null
> +++ b/arch/powerpc/dts/u-boot.dtsi
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018 NXP
> + */
> +
> +#include 
> +
> +/ {
> +#if defined(CONFIG_BINMAN) && defined(CONFIG_MPC85xx)
> +   binman {
> +   filename = "u-boot-dtb.bin";
> +   start-pos = ;
> +   sort-by-pos;
> +   pad-byte = <0xff>;
> +   size = ;
> +
> +   u-boot-with-ucode-ptr {
> +   offset = ;
> +   };
> +
> +   u-boot-dtb-with-ucode {
> +   align = <256>;
> +   };
> +#if !defined(CONFIG_SYS_MPC85XX_NO_RESETVEC) && !defined(CONFIG_NAND)
> +   mpc85xx-bootpg-resetvec {
> +   offset = <(CONFIG_RESET_VECTOR_ADDRESS - 0xffc)>;
> +   };
> +#endif
> +   };
> +#endif
> +};
>

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


Re: [U-Boot] [PATCH 3/8][RESEND] binman: Add a new "start-pos" property in section class

2018-08-21 Thread Bin Meng
On Wed, Aug 22, 2018 at 2:06 AM, Jagdish Gediya  wrote:
> currently binman calculates '_skip_at_start' based on 'end-at-4gb'

nits: Currently

> property and it is used for x86 images.
>
> for powerpc architecture also, '_skip_at_start' should be set because

powerpc -> PowerPC Book-E, or maybe just e500?

> memory address 0xeff4 or 0xfff4 is the first entry offset.

I think you need describe in more details about what these addresses
are, for example I believe they are the flash address where you want
to store the u-boot image in the flash?

> 'end-at-4gb' property is not applicable for 0xeff4 first entry
> offset.
>
> add new property start-pos' in section class so that

nits: Add a property 'start-pos' in Section

> '_skip_at_start' can be calculated either based on 'end-at-4gb'
> or based on 'start-pos'
>
> Signed-off-by: Jagdish Gediya 
> ---
>  tools/binman/bsection.py | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/tools/binman/bsection.py b/tools/binman/bsection.py
> index a0bd1b6..71f276d 100644
> --- a/tools/binman/bsection.py
> +++ b/tools/binman/bsection.py
> @@ -40,6 +40,10 @@ class Section(object):
>  used for x86 images, which want to use offsets such that a memory
>  address (like 0xff80) is the first entry offset. This causes
>  _skip_at_start to be set to the starting memory address.
> +_start_pos: For powerpc, memory address 0xeff4 or 0xfff4 is 
> the

powerpc -> PowerPC Book-E or e500?

Also please describe some details about these addresses.

> +first entry offset. _end_4gb is not re-usable if first entry 
> offset
> +is 0xeff4. _start_pos causes _skip_at_start to be set to the
> +starting memory address.
>  _name_prefix: Prefix to add to the name of all entries within this
>  section
>  _entries: OrderedDict() of entries
> @@ -61,6 +65,7 @@ class Section(object):
>  self._sort = False
>  self._skip_at_start = 0
>  self._end_4gb = False
> +self._start_pos = 0
>  self._name_prefix = ''
>  self._entries = OrderedDict()
>  if not test:
> @@ -79,10 +84,14 @@ class Section(object):
>  self._pad_byte = fdt_util.GetInt(self._node, 'pad-byte', 0)
>  self._sort = fdt_util.GetBool(self._node, 'sort-by-offset')
>  self._end_4gb = fdt_util.GetBool(self._node, 'end-at-4gb')
> -if self._end_4gb and not self._size:
> -self._Raise("Section size must be provided when using 
> end-at-4gb")
> +self._start_pos = fdt_util.GetInt(self._node, 'start-pos', 0)
> +if (self._end_4gb or self._start_pos) and not self._size:
> +self._Raise("Section size must be provided when using end-at-4gb 
> or "
> +"start-pos")
>  if self._end_4gb:
>  self._skip_at_start = 0x1 - self._size
> +if self._start_pos:
> +self._skip_at_start = self._start_pos

So the _start_pos takes precedence over the _end_4gb, please document
this. Or if you don't want the precedence, use elif

>  self._name_prefix = fdt_util.GetString(self._node, 'name-prefix')
>
>  def _ReadEntries(self):
> --

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


Re: [U-Boot] [PATCH 7/8][RESEND] powerpc: mpc85xx: Use binman to embed dtb inside u-boot

2018-08-21 Thread Bin Meng
On Wed, Aug 22, 2018 at 2:18 AM, Jagdish Gediya  wrote:
> Below is the sequence to embed dtb inside u-boot,
> 1. Remove bootpg and resetvec section if needed
> 2. Append dtb
> 3. Append bootpg and resetvec section back if removed previously
>
> Above procedure is required only when CONFIG_MPC85xx,
> CONFIG_BINMAN and CONFIG_OF_SEPARATE are defined.
>
> set PPC_MPC85XX_INCLUDE_DTB variable in Makefile if binman
> need to be used.
>
> set PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC variable in Makefile
> if bootpg and resetvec section need to be removed before appending
> dtb.
>
> Signed-off-by: Jagdish Gediya 
> ---
>  Makefile | 30 --
>  1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 884b7d9..aad9dca 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -797,6 +797,13 @@ else
>  DO_STATIC_RELA =
>  endif
>
> +ifeq ($(CONFIG_MPC85xx)$(CONFIG_BINMAN)$(CONFIG_OF_SEPARATE),yyy)
> +PPC_MPC85XX_INCLUDE_DTB := y
> +ifeq ($(CONFIG_SYS_MPC85XX_NO_RESETVEC)$(CONFIG_NAND),)
> +PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC := y
> +endif
> +endif

This looks not good to me. Can you do the similar thing like x86? eg:
Not defining PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC here, instead use
Kconfig option to control the boot page and the reset vector. Besides,
the name itself is odd too.

> +
>  # Always append ALL so that arch config.mk's can add custom ones
>  ALL-y += u-boot.srec u-boot.bin u-boot.sym System.map binary_size_check
>
> @@ -837,6 +844,10 @@ ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
>  ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
>  endif
>
> +ifeq ($(PPC_MPC85XX_INCLUDE_DTB),y)
> +ALL-y += u-boot-dtb.bin
> +endif
> +
>  # Build a combined spl + u-boot image for sunxi
>  ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
>  ALL-y += u-boot-sunxi-with-spl.bin
> @@ -938,7 +949,7 @@ u-boot-fit-dtb.bin: u-boot-nodtb.bin fit-dtb.blob
>
>  u-boot.bin: u-boot-fit-dtb.bin FORCE
> $(call if_changed,copy)
> -else ifeq ($(CONFIG_OF_SEPARATE),y)
> +else ifeq ($(CONFIG_OF_SEPARATE)$(PPC_MPC85XX_INCLUDE_DTB),y)

This is a generic rule and we should not change it. The default rule
should work on mpc85xx too, like x86.

>  u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
> $(call if_changed,cat)
>
> @@ -979,7 +990,8 @@ spl/u-boot-spl.srec: spl/u-boot-spl FORCE
> $(call if_changed,objcopy)
>
>  OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
> -   $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec)
> +   $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
> +   $(if $(PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC),-R .bootpg -R 
> .resetvec)
>
>  binary_size_check: u-boot-nodtb.bin FORCE
> @file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
> @@ -1222,6 +1234,18 @@ u-boot-x86-16bit.bin: u-boot FORCE
> $(call if_changed,objcopy)
>  endif
>
> +ifeq ($(PPC_MPC85XX_INCLUDE_DTB), y)
> +u-boot-dtb.bin: u-boot.bin u-boot.dtb \
> +   $(if $(PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC), u-boot-br.bin) FORCE
> +   $(call if_changed,binman)
> +

See above comments. No need to add a mpc85xx-specific rule for u-boot-dtb.bin

> +ifeq ($(PPC_MPC85XX_REMOVE_BOOTPG_RESETVEC),y)
> +OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j .resetvec
> +u-boot-br.bin: u-boot FORCE
> +   $(call if_changed,objcopy)
> +endif
> +endif
> +
>  ifneq ($(CONFIG_ARCH_SUNXI),)
>  ifeq ($(CONFIG_ARM64),)
>  u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.img u-boot.dtb FORCE
> @@ -1291,6 +1315,8 @@ spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE
>
>  ifeq ($(ARCH),arm)
>  UBOOT_BINLOAD := u-boot.img
> +else ifeq ($(PPC_MPC85XX_INCLUDE_DTB),y)
> +UBOOT_BINLOAD := u-boot-dtb.bin
>  else
>  UBOOT_BINLOAD := u-boot.bin
>  endif

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


Re: [U-Boot] [PATCH 5/8][RESEND] powerpc: mpc85xx: select BINMAN by default

2018-08-21 Thread Bin Meng
On Wed, Aug 22, 2018 at 2:18 AM, Jagdish Gediya  wrote:
> Signed-off-by: Jagdish Gediya 
> ---
>  arch/powerpc/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng 

But I suspect you probably need adjust this patch's order to make it
come later in this series?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 8/8][RESEND] powerpc: dts: Enable device tree support for T2080QDS

2018-08-21 Thread Bin Meng
On Wed, Aug 22, 2018 at 2:18 AM, Jagdish Gediya  wrote:
> Add device tree for T2080QDS board and enable CONFIG_OF_CONTROL
> so that device tree can be compiled.
>
> update board README for device tree usage.
>
> Signed-off-by: Jagdish Gediya 
> ---
>  arch/powerpc/dts/Makefile |  2 ++
>  arch/powerpc/dts/e6500_power_isa.dtsi | 39 +
>  arch/powerpc/dts/t2080qds.dts | 17 ++
>  arch/powerpc/dts/t2080qds.dtsi| 64 
> +++

Are all these dts files imported from Linux? It looks only interrupt
controller node is present but other peripherals nodes are missing.

>  board/freescale/t208xqds/README   | 17 ++
>  configs/T2080QDS_NAND_defconfig   |  3 +-
>  configs/T2080QDS_SDCARD_defconfig |  3 +-
>  configs/T2080QDS_SPIFLASH_defconfig   |  3 +-
>  configs/T2080QDS_defconfig|  3 +-
>  9 files changed, 147 insertions(+), 4 deletions(-)
>  create mode 100644 arch/powerpc/dts/e6500_power_isa.dtsi
>  create mode 100644 arch/powerpc/dts/t2080qds.dts
>  create mode 100644 arch/powerpc/dts/t2080qds.dtsi
>
> diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
> index de14e7b..a19aa56 100644
> --- a/arch/powerpc/dts/Makefile
> +++ b/arch/powerpc/dts/Makefile
> @@ -1,5 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0+
>
> +dtb-$(CONFIG_TARGET_T2080QDS) += t2080qds.dtb
> +
>  targets += $(dtb-y)
>
>  # Add any required device tree compiler flags here
> diff --git a/arch/powerpc/dts/e6500_power_isa.dtsi 
> b/arch/powerpc/dts/e6500_power_isa.dtsi
> new file mode 100644
> index 000..1b06170
> --- /dev/null
> +++ b/arch/powerpc/dts/e6500_power_isa.dtsi
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * e6500 Power ISA Device Tree Source (include)
> + *
> + * Copyright 2013 Freescale Semiconductor Inc.
> + * Copyright 2018 NXP
> + */
> +
> +/ {
> +   cpus {
> +   power-isa-version = "2.06";
> +   power-isa-b;// Base
> +   power-isa-e;// Embedded
> +   power-isa-atb;  // Alternate Time Base
> +   power-isa-cs;   // Cache Specification
> +   power-isa-ds;   // Decorated Storage
> +   power-isa-e.ed; // Embedded.Enhanced Debug
> +   power-isa-e.pd; // Embedded.External PID
> +   power-isa-e.hv; // Embedded.Hypervisor
> +   power-isa-e.le; // Embedded.Little-Endian
> +   power-isa-e.pm; // Embedded.Performance Monitor
> +   power-isa-e.pc; // Embedded.Processor Control
> +   power-isa-ecl;  // Embedded Cache Locking
> +   power-isa-exp;  // External Proxy
> +   power-isa-fp;   // Floating Point
> +   power-isa-fp.r; // Floating Point.Record
> +   power-isa-mmc;  // Memory Coherence
> +   power-isa-scpm; // Store Conditional Page Mobility
> +   power-isa-wt;   // Wait
> +   power-isa-64;   // 64-bit
> +   power-isa-e.pt; // Embedded.Page Table
> +   power-isa-e.hv.lrat;// Embedded.Hypervisor.LRAT
> +   power-isa-e.em; // Embedded Multi-Threading
> +   power-isa-v;// Vector (AltiVec)
> +   fsl,eref-er;// Enhanced Reservations
> +   fsl,eref-deo;   // Data Cache Extended Operations
> +   mmu-type = "power-embedded";
> +   };
> +};
> diff --git a/arch/powerpc/dts/t2080qds.dts b/arch/powerpc/dts/t2080qds.dts
> new file mode 100644
> index 000..bf8cb23
> --- /dev/null
> +++ b/arch/powerpc/dts/t2080qds.dts
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * T2080QDS Device Tree Source
> + *
> + * Copyright 2013 - 2015 Freescale Semiconductor Inc.
> + * Copyright 2018 NXP
> + */
> +
> +/include/ "t2080qds.dtsi"
> +
> +/ {
> +   model = "fsl,T2080QDS";
> +   compatible = "fsl,T2080QDS";
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   interrupt-parent = <&mpic>;
> +};
> diff --git a/arch/powerpc/dts/t2080qds.dtsi b/arch/powerpc/dts/t2080qds.dtsi
> new file mode 100644
> index 000..2006dec
> --- /dev/null
> +++ b/arch/powerpc/dts/t2080qds.dtsi
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * T2080/T2081 Silicon/SoC Device Tree Source (pre include)
> + *
> + * Copyright 2013 Freescale Semiconductor Inc.
> + * Copyright 2018 NXP
> + */
> +
> +/dts-v1/;
> +
> +/include/ "e6500_power_isa.dtsi"
> +
> +/ {
> +   model = "fsl,T2080QDS";
> +   compatible = "fsl,T2080QDS";
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   interrupt-parent = <&mpic>;
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>

[U-Boot] [PATCH] mmc: omap_hsmmc: Make DM_GPIO calls dependent on DM_GPIO

2018-08-21 Thread Adam Ford
The getcd and getwp functions when DM_MMC is enabled are
assumming the DM_GPIO is enabled.  In cases (like SPL) where
DM_GPIO may not be enabled, wrap these calls in an #ifdef

Signed-off-by: Adam Ford 

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index caaa914604..4d171f457e 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1365,9 +1365,10 @@ static int omap_hsmmc_set_ios(struct udevice *dev)
 static int omap_hsmmc_getcd(struct udevice *dev)
 {
struct omap_hsmmc_data *priv = dev_get_priv(dev);
-   int value;
-
+   int value = -1;
+#if CONFIG_IS_ENABLED(DM_GPIO)
value = dm_gpio_get_value(&priv->cd_gpio);
+#endif
/* if no CD return as 1 */
if (value < 0)
return 1;
@@ -1379,10 +1380,11 @@ static int omap_hsmmc_getcd(struct udevice *dev)
 
 static int omap_hsmmc_getwp(struct udevice *dev)
 {
+   int value = 0;
+#if CONFIG_IS_ENABLED(DM_GPIO)
struct omap_hsmmc_data *priv = dev_get_priv(dev);
-   int value;
-
value = dm_gpio_get_value(&priv->wp_gpio);
+#endif
/* if no WP return as 0 */
if (value < 0)
return 0;
@@ -1901,9 +1903,11 @@ static int omap_hsmmc_probe(struct udevice *dev)
device_get_supply_regulator(dev, "pbias-supply",
&priv->pbias_supply);
 #endif
-#if defined(OMAP_HSMMC_USE_GPIO) && CONFIG_IS_ENABLED(OF_CONTROL)
+#if defined(OMAP_HSMMC_USE_GPIO)
+#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(DM_GPIO)
gpio_request_by_name(dev, "cd-gpios", 0, &priv->cd_gpio, GPIOD_IS_IN);
gpio_request_by_name(dev, "wp-gpios", 0, &priv->wp_gpio, GPIOD_IS_IN);
+#endif
 #endif
 
mmc->dev = dev;
-- 
2.17.1

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


[U-Boot] [PATCH 0/3] configs: sama5d27_som1_ek: Cleanup and new

2018-08-21 Thread Codrin Ciubotariu
This series basically adds a new defconfig for sama5d27_som1_ek board
to boot from uSD. Also needed to cleanup the board's config header.

Codrin Ciubotariu (3):
  configs: sama5d27_som1_ek: Remove unnecessary FAT_ENV_xxx macros
  configs: sama5d27_som1_ek: Set CONFIG_BOOTARGS using Kconfig
  configs: sama5d27_som1_ek: Add defconfig for ENV/boot from uSD

 configs/sama5d27_som1_ek_mmc1_defconfig | 91 +
 configs/sama5d27_som1_ek_mmc_defconfig  |  2 +
 include/configs/sama5d27_som1_ek.h  | 10 +--
 3 files changed, 95 insertions(+), 8 deletions(-)
 create mode 100644 configs/sama5d27_som1_ek_mmc1_defconfig

-- 
2.17.1

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


[U-Boot] [PATCH 1/3] configs: sama5d27_som1_ek: Remove unnecessary FAT_ENV_xxx macros

2018-08-21 Thread Codrin Ciubotariu
FAT_ENV_xxx options can now be set using Kconfig, so we no longer
need them in the config files.

Signed-off-by: Codrin Ciubotariu 
---
 include/configs/sama5d27_som1_ek.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/configs/sama5d27_som1_ek.h 
b/include/configs/sama5d27_som1_ek.h
index 0cae301da26..5e2249711de 100644
--- a/include/configs/sama5d27_som1_ek.h
+++ b/include/configs/sama5d27_som1_ek.h
@@ -39,9 +39,6 @@
 #undef CONFIG_BOOTCOMMAND
 #ifdef CONFIG_SD_BOOT
 /* u-boot env in sd/mmc card */
-#define FAT_ENV_INTERFACE  "mmc"
-#define FAT_ENV_DEVICE_AND_PART"0"
-#define FAT_ENV_FILE   "uboot.env"
 #define CONFIG_ENV_SIZE0x4000
 /* bootstrap + u-boot + env in sd card */
 #define CONFIG_BOOTCOMMAND "fatload mmc 0:1 0x2100 
at91-sama5d27_som1_ek.dtb; " \
-- 
2.17.1

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


[U-Boot] [PATCH 2/3] configs: sama5d27_som1_ek: Set CONFIG_BOOTARGS using Kconfig

2018-08-21 Thread Codrin Ciubotariu
CONFIG_BOOTARGS can be set using Kconfig, so we no longer need it
in the config files.

Signed-off-by: Codrin Ciubotariu 
---
 configs/sama5d27_som1_ek_mmc_defconfig | 2 ++
 include/configs/sama5d27_som1_ek.h | 3 ---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/configs/sama5d27_som1_ek_mmc_defconfig 
b/configs/sama5d27_som1_ek_mmc_defconfig
index 53d4b7ce0ca..8e50cef8dbc 100644
--- a/configs/sama5d27_som1_ek_mmc_defconfig
+++ b/configs/sama5d27_som1_ek_mmc_defconfig
@@ -22,6 +22,8 @@ CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="SAMA5D2"
 CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=3
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rw 
rootwait"
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_HUSH_PARSER=y
diff --git a/include/configs/sama5d27_som1_ek.h 
b/include/configs/sama5d27_som1_ek.h
index 5e2249711de..5b1f77ba24c 100644
--- a/include/configs/sama5d27_som1_ek.h
+++ b/include/configs/sama5d27_som1_ek.h
@@ -44,9 +44,6 @@
 #define CONFIG_BOOTCOMMAND "fatload mmc 0:1 0x2100 
at91-sama5d27_som1_ek.dtb; " \
"fatload mmc 0:1 0x2200 zImage; " \
"bootz 0x2200 - 0x2100"
-#undef CONFIG_BOOTARGS
-#define CONFIG_BOOTARGS \
-   "console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rw rootwait"
 #endif
 
 #ifdef CONFIG_QSPI_BOOT
-- 
2.17.1

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


[U-Boot] [PATCH 3/3] configs: sama5d27_som1_ek: Add defconfig for ENV/boot from uSD

2018-08-21 Thread Codrin Ciubotariu
This adds a defconfig for sama5d27_som1_ek board to get environment from
uSD. The defconfig is made from sama5d27_som1_ek_mmc_defconfig, with
'bootcmd' and 'bootargs' changed to kernel, device-tree and rootfs from
uSD. The environment is expected to be found in uSD's FAT partition.

Signed-off-by: Codrin Ciubotariu 
---
 configs/sama5d27_som1_ek_mmc1_defconfig | 91 +
 include/configs/sama5d27_som1_ek.h  |  4 +-
 2 files changed, 93 insertions(+), 2 deletions(-)
 create mode 100644 configs/sama5d27_som1_ek_mmc1_defconfig

diff --git a/configs/sama5d27_som1_ek_mmc1_defconfig 
b/configs/sama5d27_som1_ek_mmc1_defconfig
new file mode 100644
index 000..0ac2445887d
--- /dev/null
+++ b/configs/sama5d27_som1_ek_mmc1_defconfig
@@ -0,0 +1,91 @@
+CONFIG_ARM=y
+CONFIG_ARCH_AT91=y
+CONFIG_SYS_TEXT_BASE=0x23f0
+CONFIG_TARGET_SAMA5D27_SOM1_EK=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL=y
+CONFIG_DEBUG_UART_BOARD_INIT=y
+CONFIG_DEBUG_UART_BASE=0xf802
+CONFIG_DEBUG_UART_CLOCK=8200
+CONFIG_SPL_FAT_SUPPORT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="at91-sama5d27_som1_ek"
+CONFIG_DEBUG_UART=y
+CONFIG_ENV_VARS_UBOOT_CONFIG=y
+CONFIG_FIT=y
+CONFIG_SYS_EXTRA_OPTIONS="SAMA5D2"
+CONFIG_SD_BOOT=y
+CONFIG_BOOTDELAY=3
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk root=/dev/mmcblk1p2 rw 
rootwait"
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_I2C=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma-names"
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_DEVICE_AND_PART="1"
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_AT91=y
+CONFIG_AT91_UTMI=y
+CONFIG_AT91_H32MX=y
+CONFIG_AT91_GENERIC_CLK=y
+CONFIG_DM_GPIO=y
+CONFIG_ATMEL_PIO4=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_AT91=y
+CONFIG_I2C_EEPROM=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ATMEL=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_SST=y
+CONFIG_DM_ETH=y
+CONFIG_MACB=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_SERIAL=y
+CONFIG_DEBUG_UART_ATMEL=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_ATMEL_USART=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_TIMER=y
+CONFIG_SPL_TIMER=y
+CONFIG_ATMEL_PIT_TIMER=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_ATMEL_USBA=y
+CONFIG_DM_VIDEO=y
+CONFIG_ATMEL_HLCD=y
diff --git a/include/configs/sama5d27_som1_ek.h 
b/include/configs/sama5d27_som1_ek.h
index 5b1f77ba24c..6af4fb51855 100644
--- a/include/configs/sama5d27_som1_ek.h
+++ b/include/configs/sama5d27_som1_ek.h
@@ -41,8 +41,8 @@
 /* u-boot env in sd/mmc card */
 #define CONFIG_ENV_SIZE0x4000
 /* bootstrap + u-boot + env in sd card */
-#define CONFIG_BOOTCOMMAND "fatload mmc 0:1 0x2100 
at91-sama5d27_som1_ek.dtb; " \
-   "fatload mmc 0:1 0x2200 zImage; " \
+#define CONFIG_BOOTCOMMAND "fatload mmc " CONFIG_ENV_FAT_DEVICE_AND_PART " 
0x2100 at91-sama5d27_som1_ek.dtb; " \
+   "fatload mmc " CONFIG_ENV_FAT_DEVICE_AND_PART " 
0x2200 zImage; " \
"bootz 0x2200 - 0x2100"
 #endif
 
-- 
2.17.1

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


Re: [U-Boot] Cavium Octeon support for u-boot

2018-08-21 Thread Alexander Graf

Hi Aaron,

On 08/21/2018 08:07 AM, Aaron Williams wrote:

The Octeon version of U-Boot is based off an older versin of U-Boot (2012.07)
with a lot of features backported. For example, I have backported NVME support
as well as the latest filesystem code. Since there have been significant
changes to U-Boot (i.e. 64-bit support) that were missing at the time it would
be a massive undertaking to support the current U-Boot with Octeon or to push
the Octeon support upstream. While in general the changes to the core U-Boot
were fairly minimal for Octeon, there were significant changes to board.c.

Hopefully we can get OcteonTX pushed upstream, however, since we are tracking
the current U-Boot releases. I'm not sure how to go about doing this, since I
would basically need a branch that I can maintain.


What help exactly do you need here? We already do see partners shipping 
with random downstream versions of U-Boot on Octeon TX and every time I 
see them missing out on amazing efi_loader fixes, a tiny fraction of my 
heart dies :).


So I would really like to see Octeon TX support simply developed fully 
upstream. That way your partners (and again their downstreams) can base 
on upstream U-Boot versions and are not tied to particular older 
versions that may be lacking features or bug fixes.



Thanks,

Alex



No significant new work is planned for the Octeon SDK or bootloader, however,
other than maintenance releases or adding features as needed by customers.

Although the Octeon code makes extensive use of the device tree, it does not
follow the dm model since that was not available when the U-Boot work took
place.

The way the Linux kernel and simple executive applications are started is also
unique to Octeon since multi-core support was also not present. This code is
complex due to the way it has evolved while trying to maintain backwards
compatibility.

Another potential barrier to upstreaming Octeon support is the fact that it
makes heavy use of our rather large SDK and the sheer amount of code. A quick
check with wc shows that we have around a million lines of code involved under
arch/mips/cpu/octeon, arch/mips/include/asm/arch-octeon and board/octeon/
common. This doesn't include the various drivers, either, or our custom
board.c file needed for the required flexibility. Around 434Klocs are the
hardware register definition files, which admittedly are huge due to the
autogenerated nature of them and all the comments and big/little endian
support. These files are shared by U-Boot, the Linux kernel and simple-
executive applications.

Some of the SDK and common board code is a mess since it tries to avoid
changes to the core of U-Boot. The networking and QLM configuration code is a
bit of a  mess since it has evolved over many years. I'm sorry to say that the
SFP/QSFP code I recently added just makes it worse due to the way it ties in
phy support. There's duplication of code between U-Boot and our SDK in the
networking code, especially for things like phy link support. Some phys also
just don't map cleanly into the U-Boot (or Linux for that matter) model. Inphi
(Cortina) and the Microsemi (Vitesse) in particular do not map into the one
phy per MAC model and all hell breaks loose with QSFPs where multiple MACs
share a phy or one MAC is split between multiple phys.

We also have implemented hooks in a number  of key places that are missing in
standard U-Boot. For example, we use a hook in the serial driver for a number
of boards to poll the SFP/QSFP ports to detect when a module is plugged in or
unplugged and to update activity LEDs.

We have also implemented something similar to native application support so
that simple-executive applications can make calls into U-Boot via a context
switching mechanism. This is used for filesystem access as well as some phy
operations with our 25G Liquid I/O boards.

We also run U-Boot in KSEG2 rather than KSEG0 so that U-Boot is always mapped
to the same virtual address regardless of where it is loaded in physical
memory. We do this for several reasons. First of all, it eliminates the need
to perform relocation fixups. Second of all, this frees up the lower 2GB of
memory space which can be a tight resource with a number of customers. While
we compile it as n32, it could conceivably be compiled as n64 but continue to
run in kseg2. n64 mode would simplify things by allowing the removal of using
cvmx_read_csr/cvmx_write_csr to instead use readq/writeq. The mapping between
virtual and physical addresses in our drivers would need to remain since there
is no IOMMU.

The code for bringing multiple cores out of reset and starting SE and the
Linux kernel would be tricky to port. There is a fair amount of assembly code
I've maintained on Octeon in order to do this.

Some of the fixes could also be pushed upstream, such as endian fixes we have
made in the USB and ext4 code.

Right now the main limitation to doing this is I'm pretty much the only one
maintaining Octeon support for U-B

Re: [U-Boot] [PATCH v2 0/6] musb-new: Improve shutdown code

2018-08-21 Thread Jagan Teki
On Fri, Jul 20, 2018 at 12:43 PM, Jagan Teki  wrote:
> This is v2 for previous series[1], by excluding sunxi phy changes.
>
> One patch mark it as 'RFC' about "including UCLASS_USB_DEV_GENERIC
> into shutdown caller" so expecting some inputs on the same
>
> [1] https://patchwork.ozlabs.org/cover/941588/
>
> Jagan Teki (6):
>   usb: musb-new: Fix improper musb host pointer
>   usb: musb-new: sunxi: Allocate struct phy in private
>   dm: usb: Add UCLASS_USB_DEV_GENERIC shutdown
>   musb-new: sunxi: Access ahb_reset0_cfg via ccm offset
>   usb: musb-new: sunxi: Add proper musb exit support
>   usb: musb-new: Call musb_platform_exit from musb_stop

I'm planning to apply by excluding RFC patch, let me know if anyone
has any inputs.

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


[U-Boot] [PATCH] env: ubi: Add missing ENV_NAME

2018-08-21 Thread Marek Vasut
Add missing environment name for UBI, to prevent this NULL in output:
Loading Environment from ...
and rather have a valid UBI there:
Loading Environment from UBI...

Signed-off-by: Marek Vasut 
---
 env/ubi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/env/ubi.c b/env/ubi.c
index eb2346f3a1..1dfdf0a8c8 100644
--- a/env/ubi.c
+++ b/env/ubi.c
@@ -168,6 +168,7 @@ static int env_ubi_load(void)
 
 U_BOOT_ENV_LOCATION(ubi) = {
.location   = ENVL_UBI,
+   ENV_NAME("UBI")
.load   = env_ubi_load,
.save   = env_save_ptr(env_ubi_save),
 };
-- 
2.17.1

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


[U-Boot] [PATCH] ARM: dts: socfpga: Add missing NAND reset

2018-08-21 Thread Marek Vasut
The NAND reset is missing from DT, so the reset manager cannot unreset the NAND.
Add the missing DT reset entry.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Ley Foon Tan 
---
 arch/arm/dts/socfpga_arria10.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/socfpga_arria10.dtsi 
b/arch/arm/dts/socfpga_arria10.dtsi
index 573974be04..46f2fd4b69 100644
--- a/arch/arm/dts/socfpga_arria10.dtsi
+++ b/arch/arm/dts/socfpga_arria10.dtsi
@@ -673,6 +673,7 @@
interrupts = <0 99 4>;
dma-mask = <0x>;
clocks = <&nand_clk>;
+   resets = <&rst NAND_RESET>;
status = "disabled";
};
 
-- 
2.17.1

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


[U-Boot] [PATCH] mtd: nand: denali_dt: Add reset support

2018-08-21 Thread Marek Vasut
Add optional reset support into the Denali NAND driver. In case there is
a valid reset entry in the DT, the reset gets deasserted before the NAND
controller gets used.

Signed-off-by: Marek Vasut 
Cc: Masahiro Yamada 
---
 drivers/mtd/nand/denali_dt.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index 65a7797f0f..6fcd7d3843 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "denali.h"
 
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev)
const struct denali_dt_data *data;
struct clk clk;
struct resource res;
+   struct reset_ctl reset_ctl;
int ret;
 
data = (void *)dev_get_driver_data(dev);
@@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
 
denali->clk_x_rate = clk_get_rate(&clk);
 
+   ret = reset_get_by_index(dev, 0, &reset_ctl);
+   if (!ret) {
+   reset_assert(&reset_ctl);
+   udelay(2);
+   reset_deassert(&reset_ctl);
+   }
+
return denali_init(denali);
 }
 
-- 
2.17.1

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


[U-Boot] [PATCH] ARM: socfpga: Fix Arria10 SPI and NAND U-Boot offset

2018-08-21 Thread Marek Vasut
The SPL size on Gen5 is 4*64kiB, but on A10 it is 4*256kiB.
Handle the difference.

Signed-off-by: Marek Vasut 
---
 include/configs/socfpga_common.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 55ca0fb5b0..fbfc6b63a0 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -266,12 +266,20 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 
 /* SPL QSPI boot support */
 #ifdef CONFIG_SPL_SPI_SUPPORT
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x4
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x10
+#endif
 #endif
 
 /* SPL NAND boot support */
 #ifdef CONFIG_SPL_NAND_SUPPORT
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 #define CONFIG_SYS_NAND_U_BOOT_OFFS0x4
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+#define CONFIG_SYS_NAND_U_BOOT_OFFS0x10
+#endif
 #endif
 
 /*
-- 
2.17.1

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


[U-Boot] [PATCH] ARM: dts: socfpga: Drop ad-hoc UART clock frequency encoding from DT

2018-08-21 Thread Marek Vasut
The UART clock frequency can be obtained from the clock framework by the
ns16550 driver, so drop this redundant DT node.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Ley Foon Tan 
---
 arch/arm/dts/socfpga_arria10_socdk.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/socfpga_arria10_socdk.dtsi 
b/arch/arm/dts/socfpga_arria10_socdk.dtsi
index 9160c20bd0..b202b382f4 100644
--- a/arch/arm/dts/socfpga_arria10_socdk.dtsi
+++ b/arch/arm/dts/socfpga_arria10_socdk.dtsi
@@ -154,7 +154,6 @@
 };
 
 &uart1 {
-   clock-frequency = <5000>;
u-boot,dm-pre-reloc;
status = "okay";
 };
-- 
2.17.1

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


[U-Boot] [PATCH 0/8] [1/3] Initial support Texas Instrument's AM654 Platform

2018-08-21 Thread Lokesh Vutla
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.

The device is partitioned into three functional domains, each containing
specific processing cores and peripherals:
Some highlights in each domain are:
- MAIN Domain:
--
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* DDR Subsystem (DDRSS) with Error Correcting Code (ECC)
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
  PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* eQEP/eCAP, eHRPWM.
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
  GPIO

- MCU Domain:
-
* Dual lock-step capable R5F uC for safety-critical applications
* Flash subsystem with OSPI and Hyperbus interfaces
* High data throughput capable distributed DMA architecture under MCU NAVSS
* Dual ADCSS, Dual CAN-FD.

- WKUP Domain:
--
* Centralized System Controller for Security, Power, and Resource
  management.

For further deails see AM65x Technical Reference Manual (SPRUID7, April 2018):
http://www.ti.com/lit/pdf/spruid7

This is a complex SoC and the support to add this SoC is very huge. So I
tried to split into 3 separate series:
[1/3] Adding base SoC support
[2/3] Base drivers that allow minimal boot.
[3/3] EVM support with dts and defconfig changes.

This series adds base SoC support. The rest of the two series will be a
follow up of this series.

On AM65x family devices, ROM supports boot only via MCU(R5). This means that
bootloader has to run on R5 core. In order to meet this constraint,
keeping safety in picture and to have faster boot time, the software boot
architecture is designed as: https://pastebin.ubuntu.com/p/NxSvDbMtSk/
Any feedback is highly appreciated.

Andreas Dannenberg (1):
  arm: K3: am654: Unlock control module registers during init

Lokesh Vutla (7):
  arm: K3: Add initial support for TI's K3 generation of SoCs
  arm: K3: Add support for AM654 SoC definition
  arm: K3: Update _start instruction
  arm: K3: am654: Add support for boot device detection
  armv8: K3: am654: Add custom MMU support
  armv8: K3: am654: Introduce FIT generator script
  armv8: K3: am654: Add support for generating build targets

 Kconfig  |   2 +-
 MAINTAINERS  |   1 +
 arch/arm/Kconfig |   8 ++
 arch/arm/Makefile|   1 +
 arch/arm/include/asm/spl.h   |   2 +-
 arch/arm/lib/vectors.S   |   8 ++
 arch/arm/mach-k3/Kconfig |  50 
 arch/arm/mach-k3/Makefile|   7 ++
 arch/arm/mach-k3/am6_init.c  | 123 +++
 arch/arm/mach-k3/arm64-mmu.c |  45 +++
 arch/arm/mach-k3/config.mk   |  21 
 arch/arm/mach-k3/include/mach/am6_hardware.h |  44 +++
 arch/arm/mach-k3/include/mach/am6_spl.h  |  36 ++
 arch/arm/mach-k3/include/mach/clock.h|  16 +++
 arch/arm/mach-k3/include/mach/hardware.h |  12 ++
 arch/arm/mach-k3/include/mach/spl.h  |  12 ++
 common/spl/Kconfig   |   2 +-
 drivers/serial/ns16550.c |   5 +-
 scripts/Makefile.spl |   9 ++
 tools/k3/k3_fit_atf.sh   |  98 +++
 20 files changed, 497 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-k3/Kconfig
 create mode 100644 arch/arm/mach-k3/Makefile
 create mode 100644 arch/arm/mach-k3/am6_init.c
 create mode 100644 arch/arm/mach-k3/arm64-mmu.c
 create mode 100644 arch/arm/mach-k3/config.mk
 create mode 100644 arch/arm/mach-k3/include/mach/am6_hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/am6_spl.h
 create mode 100644 arch/arm/mach-k3/include/mach/clock.h
 create mode 100644 arch/arm/mach-k3/include/mach/hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/spl.h
 create mode 100755 tools/k3/k3_fit_atf.sh

-- 
2.18.0

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


[U-Boot] [PATCH 1/8] arm: K3: Add initial support for TI's K3 generation of SoCs

2018-08-21 Thread Lokesh Vutla
Add support for Texas Instruments' K3 Generation Processor
families.

Signed-off-by: Lokesh Vutla 
---
 Kconfig  |  2 +-
 MAINTAINERS  |  1 +
 arch/arm/Kconfig |  8 
 arch/arm/Makefile|  1 +
 arch/arm/mach-k3/Kconfig | 12 
 common/spl/Kconfig   |  2 +-
 drivers/serial/ns16550.c |  5 +++--
 7 files changed, 27 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-k3/Kconfig

diff --git a/Kconfig b/Kconfig
index db0f545e45..04ffc26753 100644
--- a/Kconfig
+++ b/Kconfig
@@ -447,7 +447,7 @@ config SYS_EXTRA_OPTIONS
 config SYS_TEXT_BASE
depends on !NIOS2 && !XTENSA
depends on !EFI_APP
-   default 0x8080 if ARCH_OMAP2PLUS
+   default 0x8080 if ARCH_OMAP2PLUS || ARCH_K3
default 0x4a00 if ARCH_SUNXI && !MACH_SUN9I && !MACH_SUN8I_V3S
default 0x2a00 if ARCH_SUNXI && MACH_SUN9I
default 0x42e0 if ARCH_SUNXI && MACH_SUN8I_V3S
diff --git a/MAINTAINERS b/MAINTAINERS
index 8f237128b2..1971197ec0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -272,6 +272,7 @@ M:  Tom Rini 
 S: Maintained
 T: git git://git.denx.de/u-boot-ti.git
 F: arch/arm/mach-davinci/
+F: arch/arm/mach-k3/
 F: arch/arm/mach-keystone/
 F: arch/arm/include/asm/arch-omap*/
 F: arch/arm/include/asm/ti-common/
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 63ec02403a..deed8103de 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -646,6 +646,12 @@ config ARCH_KEYSTONE
imply CMD_SAVES
imply FIT
 
+config ARCH_K3
+   bool "Texas Instruments' K3 Architecture"
+   select SPL
+   select SUPPORT_SPL
+   select FIT
+
 config ARCH_OMAP2PLUS
bool "TI OMAP2+"
select CPU_V7A
@@ -1377,6 +1383,8 @@ source "arch/arm/mach-highbank/Kconfig"
 
 source "arch/arm/mach-integrator/Kconfig"
 
+source "arch/arm/mach-k3/Kconfig"
+
 source "arch/arm/mach-keystone/Kconfig"
 
 source "arch/arm/mach-kirkwood/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index cac58bdc4d..cbcb357f3d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -58,6 +58,7 @@ machine-$(CONFIG_ARCH_BCMSTB) += bcmstb
 machine-$(CONFIG_ARCH_DAVINCI) += davinci
 machine-$(CONFIG_ARCH_EXYNOS)  += exynos
 machine-$(CONFIG_ARCH_HIGHBANK)+= highbank
+machine-$(CONFIG_ARCH_K3)  += k3
 machine-$(CONFIG_ARCH_KEYSTONE)+= keystone
 # TODO: rename CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD
 machine-$(CONFIG_KIRKWOOD) += kirkwood
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
new file mode 100644
index 00..552b84923e
--- /dev/null
+++ b/arch/arm/mach-k3/Kconfig
@@ -0,0 +1,12 @@
+if ARCH_K3
+
+choice
+   prompt "Texas Instruments' K3 based SoC select"
+   optional
+
+endchoice
+
+config SYS_SOC
+   default "k3"
+
+endif
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0ad1e049a9..11c2c0133f 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -171,7 +171,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
default 0x140 if ARCH_MVEBU
default 0x200 if ARCH_SOCFPGA || ARCH_AT91
default 0x300 if ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || OMAP44XX || \
-OMAP54XX || AM33XX || AM43XX
+OMAP54XX || AM33XX || AM43XX || ARCH_K3
default 0x4000 if ARCH_ROCKCHIP
help
  Address on the MMC to load U-Boot from, when the MMC is being used
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 9c80090aa7..f48d82f051 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
;
 
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
-#if defined(CONFIG_ARCH_OMAP2PLUS)
+#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3)
serial_out(0x7, &com_port->mdr1);   /* mode select reset TL16C750*/
 #endif
 
@@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(ns16550_getfcr(com_port), &com_port->fcr);
if (baud_divisor != -1)
NS16550_setbrg(com_port, baud_divisor);
-#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX)
+#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \
+   defined(CONFIG_ARCH_K3)
/* /16 is proper to hit 115200 with 48MHz */
serial_out(0, &com_port->mdr1);
 #endif
-- 
2.18.0

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


[U-Boot] [PATCH 2/8] arm: K3: Add support for AM654 SoC definition

2018-08-21 Thread Lokesh Vutla
The AM654 device is designed for industrial automation and PLC
controller class platforms among other applications. Introduce
base support for AM654 SoC.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/Kconfig  | 31 ++
 arch/arm/mach-k3/Makefile |  6 +
 arch/arm/mach-k3/am6_init.c   | 32 +++
 arch/arm/mach-k3/include/mach/clock.h | 16 ++
 4 files changed, 85 insertions(+)
 create mode 100644 arch/arm/mach-k3/Makefile
 create mode 100644 arch/arm/mach-k3/am6_init.c
 create mode 100644 arch/arm/mach-k3/include/mach/clock.h

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 552b84923e..c532fbd061 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -4,9 +4,40 @@ choice
prompt "Texas Instruments' K3 based SoC select"
optional
 
+config SOC_K3_AM6
+   bool "TI's K3 based AM6 SoC Family Support"
+
 endchoice
 
 config SYS_SOC
default "k3"
 
+config NON_SECURE_MSRAM_SIZE
+   hex "Size of the MCU OC-MSRAM"
+   default 0x8
+   help
+ Describes the total size of the MCU MSRAM. This doesn't
+ specify the total size of SPL as ROM can use some part
+ of this RAM. Once ROM gives control to SPL then this
+ complete size can be usable.
+
+config MAX_DOWNLODABLE_IMAGE_SIZE
+   hex "Maximum size of the image"
+   default 0x58000
+   help
+ Describes the maximum size of the image that ROM can download
+ from any boot media.
+
+config MCU_SCRATCHPAD_BASE
+   hex "Base address of Scratchpad RAM"
+   default 0x4028 if SOC_K3_AM6
+   help
+ Describes the base address of MCU Scratchpad RAM.
+
+config MCU_SCRATCHPAD_SIZE
+   hex "Size of Scratchpad RAM"
+   default 0x200 if SOC_K3_AM6
+   help
+ Describes the size of MCU Scratchpad RAM.
+
 endif
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
new file mode 100644
index 00..356fc27b11
--- /dev/null
+++ b/arch/arm/mach-k3/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+#  Lokesh Vutla 
+
+obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
new file mode 100644
index 00..7a78e85938
--- /dev/null
+++ b/arch/arm/mach-k3/am6_init.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: Architecture initialization
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+
+#ifdef CONFIG_SPL_BUILD
+void board_init_f(ulong dummy)
+{
+   /* Init DM early in-order to invoke system controller */
+   spl_early_init();
+
+   /* Prepare console output */
+   preloader_console_init();
+}
+
+u32 spl_boot_device(void)
+{
+   return BOOT_DEVICE_RAM;
+}
+#endif
+
+#ifndef CONFIG_SYSRESET
+void reset_cpu(ulong ignored)
+{
+}
+#endif
diff --git a/arch/arm/mach-k3/include/mach/clock.h 
b/arch/arm/mach-k3/include/mach/clock.h
new file mode 100644
index 00..c4dbacb128
--- /dev/null
+++ b/arch/arm/mach-k3/include/mach/clock.h
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: Common SoC clock definitions.
+ *
+ * (C) Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+#ifndef __ASM_ARCH_CLOCK_H
+#define __ASM_ARCH_CLOCK_H
+
+#include 
+
+/* Clock Defines */
+#define V_OSCK 2400
+#define V_SCLK V_OSCK
+
+#endif /* __ASM_ARCH_CLOCK_H */
-- 
2.18.0

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


[U-Boot] [PATCH 3/8] arm: K3: Update _start instruction

2018-08-21 Thread Lokesh Vutla
On K3 family SoCs, once the ROM loads image on R5, M3 resets R5 and
expects to start executing from 0x0. In order to handle this ROM
updates the boot vector of R5 such that first 64 bytes of image load
address are mapped to 0x0.

In this case, it is SPL's responsibility to jump to the proper image
location. So, update the PC with address of reset vector(like how
other exception vectors are handled), instead of branching to reset.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/lib/vectors.S | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S
index d629cb1dc2..2ca6e2494a 100644
--- a/arch/arm/lib/vectors.S
+++ b/arch/arm/lib/vectors.S
@@ -19,7 +19,11 @@
  * for the non-boot0 case or by a boot0-header.
  */
 .macro ARM_VECTORS
+#ifdef CONFIG_ARCH_K3
+   ldr pc, _reset
+#else
b   reset
+#endif
ldr pc, _undefined_instruction
ldr pc, _software_interrupt
ldr pc, _prefetch_abort
@@ -94,6 +98,7 @@ _start:
  *
  */
 
+   .globl  _reset
.globl  _undefined_instruction
.globl  _software_interrupt
.globl  _prefetch_abort
@@ -102,6 +107,9 @@ _start:
.globl  _irq
.globl  _fiq
 
+#ifdef CONFIG_ARCH_K3
+_reset:.word reset
+#endif
 _undefined_instruction:.word undefined_instruction
 _software_interrupt:   .word software_interrupt
 _prefetch_abort:   .word prefetch_abort
-- 
2.18.0

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


[U-Boot] [PATCH 4/8] arm: K3: am654: Add support for boot device detection

2018-08-21 Thread Lokesh Vutla
AM654 allows for booting from primary or backup boot media.
Both media can be chosen individually based on switch settings.
ROM looks for a valid image in primary boot media, if not found
then looks in backup boot media. In order to pass this boot media
information to boot loader, ROM stores a value at a particular
address. Add support for reading this information and determining
the boot media correctly.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
Signed-off-by: Vignesh R 
---
 arch/arm/include/asm/spl.h   |  2 +-
 arch/arm/mach-k3/Kconfig |  7 +++
 arch/arm/mach-k3/am6_init.c  | 54 +++-
 arch/arm/mach-k3/include/mach/am6_hardware.h | 23 +
 arch/arm/mach-k3/include/mach/am6_spl.h  | 36 +
 arch/arm/mach-k3/include/mach/hardware.h | 12 +
 arch/arm/mach-k3/include/mach/spl.h  | 12 +
 7 files changed, 144 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-k3/include/mach/am6_hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/am6_spl.h
 create mode 100644 arch/arm/mach-k3/include/mach/hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/spl.h

diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h
index b9e8a4f5d5..e568af2561 100644
--- a/arch/arm/include/asm/spl.h
+++ b/arch/arm/include/asm/spl.h
@@ -8,7 +8,7 @@
 
 #if defined(CONFIG_ARCH_OMAP2PLUS) \
|| defined(CONFIG_EXYNOS4) || defined(CONFIG_EXYNOS5) \
-   || defined(CONFIG_EXYNOS4210)
+   || defined(CONFIG_EXYNOS4210) || defined(CONFIG_ARCH_K3)
 /* Platform-specific defines */
 #include 
 
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index c532fbd061..117e5b4e4a 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -40,4 +40,11 @@ config MCU_SCRATCHPAD_SIZE
help
  Describes the size of MCU Scratchpad RAM.
 
+config BOOT_PARAM_TABLE_INDEX
+   hex "Address of Array Index to be used within BOOT_PARAM_TABLE"
+   default 0x41c7fbfc if SOC_K3_AM6
+   help
+ Address at which ROM stores the value which determines if SPL
+ is booted up by primary boot media or secondary boot media.
+
 endif
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 7a78e85938..8a7cedf66f 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -7,11 +7,26 @@
  */
 
 #include 
+#include 
 #include 
+#include 
 
 #ifdef CONFIG_SPL_BUILD
+static void store_boot_index_from_rom(void)
+{
+   u32 *boot_index = (u32 *)K3_BOOT_PARAM_TABLE_INDEX_VAL;
+
+   *boot_index = *(u32 *)(CONFIG_BOOT_PARAM_TABLE_INDEX);
+}
+
 void board_init_f(ulong dummy)
 {
+   /*
+* Cannot delay this further as there is a chance that
+* BOOT_PARAM_TABLE_INDEX can be over written by SPL MALLOC section.
+*/
+   store_boot_index_from_rom();
+
/* Init DM early in-order to invoke system controller */
spl_early_init();
 
@@ -19,10 +34,47 @@ void board_init_f(ulong dummy)
preloader_console_init();
 }
 
-u32 spl_boot_device(void)
+static u32 __get_backup_bootmedia(u32 devstat)
 {
+   u32 bkup_boot = (devstat & CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASK) >>
+   CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT;
+
+   switch (bkup_boot) {
+#define __BKUP_BOOT_DEVICE(n)  \
+   case BACKUP_BOOT_DEVICE_##n:\
+   return BOOT_DEVICE_##n;
+   __BKUP_BOOT_DEVICE(USB);
+   __BKUP_BOOT_DEVICE(UART);
+   __BKUP_BOOT_DEVICE(ETHERNET);
+   __BKUP_BOOT_DEVICE(MMC2);
+   __BKUP_BOOT_DEVICE(SPI);
+   __BKUP_BOOT_DEVICE(HYPERFLASH);
+   __BKUP_BOOT_DEVICE(I2C);
+   };
+
return BOOT_DEVICE_RAM;
 }
+
+static u32 __get_primary_bootmedia(u32 devstat)
+{
+   u32 bootmode = devstat & CTRLMMR_MAIN_DEVSTAT_BOOTMODE_MASK;
+
+   if (bootmode == BOOT_DEVICE_OSPI || bootmode == BOOT_DEVICE_QSPI)
+   bootmode = BOOT_DEVICE_SPI;
+
+   return bootmode;
+}
+
+u32 spl_boot_device(void)
+{
+   u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
+   u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
+
+   if (bootindex == K3_PRIMARY_BOOTMODE)
+   return __get_primary_bootmedia(devstat);
+   else
+   return __get_backup_bootmedia(devstat);
+}
 #endif
 
 #ifndef CONFIG_SYSRESET
diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h 
b/arch/arm/mach-k3/include/mach/am6_hardware.h
new file mode 100644
index 00..b56aa60ec7
--- /dev/null
+++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: AM6 SoC definitions, structures etc.
+ *
+ * (C) Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+#ifndef __ASM_ARCH_AM6_HARDWARE_H
+#define __ASM_ARCH_AM6_HARDWARE_H
+
+#include 
+
+#define CTRL_MMR0_BASE 0x0010

[U-Boot] [PATCH 8/8] armv8: K3: am654: Add support for generating build targets

2018-08-21 Thread Lokesh Vutla
Update Makefile to generate
- tispl.bin: First stage bootloader on ARMv8 core
- u-boot.img: Second stage bootloader on ARMv8 core.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/config.mk | 21 +
 scripts/Makefile.spl   |  9 +
 2 files changed, 30 insertions(+)
 create mode 100644 arch/arm/mach-k3/config.mk

diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
new file mode 100644
index 00..eb604a418e
--- /dev/null
+++ b/arch/arm/mach-k3/config.mk
@@ -0,0 +1,21 @@
+#
+# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+#  Lokesh Vutla 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifdef CONFIG_SPL_BUILD
+
+ifdef CONFIG_ARM64
+SPL_ITS := u-boot-spl-k3.its
+$(SPL_ITS): FORCE
+   $(srctree)/tools/k3/k3_fit_atf.sh \
+   $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@
+
+ALL-y  += tispl.bin
+endif
+
+else
+ALL-y  += u-boot.img
+endif
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 252f13826d..e494d185e4 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -144,6 +144,10 @@ quiet_cmd_mkimage = MKIMAGE $@
 cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
+quiet_cmd_mkfitimage = MKIMAGE $@
+cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f $(SPL_ITS) 
-E $@ \
+   $(if $(KBUILD_VERBOSE:1=), MKIMAGEOUTPUT)
+
 MKIMAGEFLAGS_MLO = -T omapimage -a $(CONFIG_SPL_TEXT_BASE)
 
 MKIMAGEFLAGS_MLO.byteswap = -T omapimage -n byteswap -a $(CONFIG_SPL_TEXT_BASE)
@@ -407,3 +411,8 @@ $(obj)/$(SPL_BIN).multidtb.fit.gz: 
$(obj)/$(SPL_BIN).multidtb.fit
 
 $(obj)/$(SPL_BIN).multidtb.fit.lzo: $(obj)/$(SPL_BIN).multidtb.fit
@lzop -f9 $< > $@
+
+ifdef CONFIG_ARCH_K3
+tispl.bin: $(obj)/u-boot-spl-nodtb.bin $(SHRUNK_ARCH_DTB) $(SPL_ITS) FORCE
+   $(call if_changed,mkfitimage)
+endif
-- 
2.18.0

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


[U-Boot] [PATCH 00/25] [2/3] Initial support Texas Instrument's AM654 Platform

2018-08-21 Thread Lokesh Vutla
Continue from PART 1/3.

This series adds all the driver support that are required to boot AM654 SoC.
The drivers are:
- TISCI Communication protocol to system controller
- Clock, power, reset drivers.
- Mailbox driver to communication to system controller.
- remoteproc drivers to start system controller and start armv8 core.
- Basic mmc sdhci driver.

Andreas Dannenberg (12):
  firmware: ti_sci: Add support for board configuration
  firmware: ti_sci: Add support for device control
  firmware: ti_sci: Add support for reboot core service
  dm: firmware: Automatically bind child devices
  dm: reset: Update uclass to allow querying reset status
  reset: Extend reset control with an optional data field
  reset: Introduce TI System Control Interface (TI SCI) reset driver
  clk: Allow clock defaults to be set also during re-reloc state
  clk: Extend clock control with an optional data field
  clk: Introduce TI System Control Interface (TI SCI) clock driver
  power domain: Introduce TI System Control Interface (TI SCI) power
domain driver
  sysreset: Add TI System Control Interface (TI SCI) sysreset driver

Lokesh Vutla (13):
  firmware: Add basic support for TI System Control Interface (TI SCI)
protocol
  firmware: ti_sci: Add support for clock control
  firmware: ti_sci: Add support for processor control services
  power domain: Add support for multiple powerdomains per device
  mailbox: Allow attaching private data for mbox_chan
  mailbox: Introduce K3 Secure Proxy Driver
  spl: Allow mailbox drivers to be used within SPL
  remoteproc: Allow for individual remoteproc initialization
  remoteproc: Introduce K3 system controller
  remoteproc: Introduce K3 remoteproc driver
  spl: Allow remoteproc drivers to be used within SPL
  mmc: k3_arasan: Add sdhci driver support for K3 family SoCs
  gpio: do not include  for ARCH_K3

 arch/arm/include/asm/gpio.h   |3 +-
 common/spl/Kconfig|   14 +
 doc/device-tree-bindings/clock/ti,sci-clk.txt |   53 +
 doc/device-tree-bindings/firmware/ti,sci.txt  |   76 +
 .../mailbox/k3-secure-proxy.txt   |   40 +
 .../power/ti,sci-pm-domain.txt|   52 +
 .../remoteproc/k3-rproc.txt   |   50 +
 .../remoteproc/k3-system-controller.txt   |   24 +
 .../reset/ti,sci-reset.txt|   54 +
 .../sysreset/ti,sci-sysreset.txt  |   29 +
 drivers/Makefile  |3 +-
 drivers/clk/Kconfig   |8 +
 drivers/clk/Makefile  |1 +
 drivers/clk/clk-ti-sci.c  |  217 ++
 drivers/clk/clk-uclass.c  |4 -
 drivers/firmware/Kconfig  |   13 +
 drivers/firmware/Makefile |1 +
 drivers/firmware/firmware-uclass.c|3 +
 drivers/firmware/ti_sci.c | 2033 +
 drivers/firmware/ti_sci.h |  680 ++
 drivers/mailbox/Kconfig   |   10 +
 drivers/mailbox/Makefile  |3 +-
 drivers/mailbox/k3-sec-proxy.c|  438 
 drivers/mmc/Kconfig   |9 +
 drivers/mmc/Makefile  |1 +
 drivers/mmc/k3_arsan_sdhci.c  |  109 +
 drivers/power/domain/Kconfig  |7 +
 drivers/power/domain/Makefile |1 +
 drivers/power/domain/power-domain-uclass.c|   11 +-
 drivers/power/domain/ti-sci-power-domain.c|  107 +
 drivers/remoteproc/Kconfig|   18 +
 drivers/remoteproc/Makefile   |4 +-
 drivers/remoteproc/k3_rproc.c |  244 ++
 drivers/remoteproc/k3_system_controller.c |  323 +++
 drivers/remoteproc/rproc-uclass.c |   19 +
 drivers/reset/Kconfig |8 +
 drivers/reset/Makefile|1 +
 drivers/reset/reset-ti-sci.c  |  206 ++
 drivers/reset/reset-uclass.c  |9 +
 drivers/sysreset/Kconfig  |7 +
 drivers/sysreset/Makefile |1 +
 drivers/sysreset/sysreset-ti-sci.c|   73 +
 include/clk.h |   12 +-
 include/linux/soc/ti/k3-sec-proxy.h   |   25 +
 include/linux/soc/ti/ti_sci_protocol.h|  315 +++
 include/mailbox.h |7 +-
 include/power-domain.h|   19 +
 include/remoteproc.h  |9 +
 include/reset-uclass.h|8 +
 include/reset.h   |   26 +-
 50 files changed, 5364 insertions(+), 24 deletions(-)
 create mode 100644 doc/device-tree-bindings/clock/ti,sci-clk.txt
 create mode 100644 doc/device-tree-bindings/firmware/ti,sci.txt
 create mode 100644 doc/device-tree-bindings/mailbox/k3-secure-proxy.txt
 create mode 100644 doc/device-tree-bindi

[U-Boot] [PATCH 6/8] armv8: K3: am654: Add custom MMU support

2018-08-21 Thread Lokesh Vutla
Add MMU mappings for AM654 SoC.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/Makefile|  1 +
 arch/arm/mach-k3/arm64-mmu.c | 45 
 2 files changed, 46 insertions(+)
 create mode 100644 arch/arm/mach-k3/arm64-mmu.c

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 356fc27b11..e9b7ee5210 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -4,3 +4,4 @@
 #  Lokesh Vutla 
 
 obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
+obj-$(CONFIG_ARM64) += arm64-mmu.o
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
new file mode 100644
index 00..41a9dbf899
--- /dev/null
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -0,0 +1,45 @@
+/*
+ * K3: ARM64 MMU setup
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ * (This file is derived from arch/arm/cpu/armv8/zynqmp/cpu.c)
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
+#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3)
+
+/* ToDo: Add 64bit IO */
+struct mm_region am654_mem_map[NR_MMU_REGIONS] = {
+   {
+   .virt = 0x0UL,
+   .phys = 0x0UL,
+   .size = 0x8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   .virt = 0x8000UL,
+   .phys = 0x8000UL,
+   .size = 0x8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0x88000UL,
+   .phys = 0x88000UL,
+   .size = 0x8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   /* List terminator */
+   0,
+   }
+};
+
+struct mm_region *mem_map = am654_mem_map;
-- 
2.18.0

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


[U-Boot] [PATCH 10/25] reset: Introduce TI System Control Interface (TI SCI) reset driver

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.

This patch adds a reset driver that communicates to the system
controller over the TI SCI protocol for performing reset management of
various devices present on the SoC. Various reset functionalities are
achieved by the means of different TI SCI device operations provided by
the TI SCI framework.

This code is loosely based on the drivers/reset/reset-ti-sci.c driver of
the Linux kernel.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 .../reset/ti,sci-reset.txt|  54 +
 drivers/reset/Kconfig |   8 +
 drivers/reset/Makefile|   1 +
 drivers/reset/reset-ti-sci.c  | 206 ++
 4 files changed, 269 insertions(+)
 create mode 100644 doc/device-tree-bindings/reset/ti,sci-reset.txt
 create mode 100644 drivers/reset/reset-ti-sci.c

diff --git a/doc/device-tree-bindings/reset/ti,sci-reset.txt 
b/doc/device-tree-bindings/reset/ti,sci-reset.txt
new file mode 100644
index 00..e7e2d13f9f
--- /dev/null
+++ b/doc/device-tree-bindings/reset/ti,sci-reset.txt
@@ -0,0 +1,54 @@
+Texas Instruments TI SCI Reset Controller
+=
+
+Some TI SoCs contain a system controller (like the SYSFW, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI SCI [1].
+
+[1] http://processors.wiki.ti.com/index.php/TISCI
+
+Reset Controller Node
+=
+The reset controller node represents the resets of various hardware modules
+present on the SoC managed by the SYSFW. Because this relies on the TI SCI
+protocol to communicate with the SYSFW it must be a child of the sysfw node.
+
+Required Properties:
+
+ - compatible: Must be "ti,sci-reset"
+ - #reset-cells: Must be 2. Please see the reset consumer node below for
+usage details.
+
+Example (AM65x):
+
+   sysfw: sysfw {
+   compatible = "ti,am654-system-controller";
+   ...
+   k3_reset: reset-controller {
+   compatible = "ti,sci-reset";
+   #reset-cells = <2>;
+   };
+   };
+
+Reset Consumers
+===
+Each of the reset consumer nodes should have the following properties,
+in addition to their own properties.
+
+Required Properties:
+
+ - resets: A phandle and reset specifier pair, one pair for each reset signal
+  that affects the device, or that the device manages. The phandle
+  should point to the TI SCI reset controller node, and the reset
+  specifier should have 2 cell-values. The first cell should contain
+  the device ID. The second cell should contain the reset mask value
+  used by system controller.
+
+Example (AM65x):
+
+   uart2: serial@0280 {
+   compatible = "ti,omap4-uart";
+   ...
+   resets = <&k3_reset 5 1>;
+   };
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 33c39b7fb6..9c5208b7da 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -49,6 +49,14 @@ config TEGRA186_RESET
  Enable support for manipulating Tegra's on-SoC reset signals via IPC
  requests to the BPMP (Boot and Power Management Processor).
 
+config RESET_TI_SCI
+   bool "TI System Control Interface (TI SCI) reset driver"
+   depends on DM_RESET && TI_SCI_PROTOCOL
+   help
+ This enables the reset driver support over TI System Control Interface
+ available on some new TI's SoCs. If you wish to use reset resources
+ managed by the TI System Controller, say Y here. Otherwise, say N.
+
 config RESET_BCM6345
bool "Reset controller driver for BCM6345"
depends on DM_RESET && ARCH_BMIPS
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index ad08be4c8c..abdfa0c663 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_STI_RESET) += sti-reset.o
 obj-$(CONFIG_STM32_RESET) += stm32-reset.o
 obj-$(CONFIG_TEGRA_CAR_RESET) += tegra-car-reset.o
 obj-$(CONFIG_TEGRA186_RESET) += tegra186-reset.o
+obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
 obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
 obj-$(CONFIG_AST2500_RESET) += ast2500-rese

[U-Boot] [PATCH 12/25] clk: Extend clock control with an optional data field

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Some systems require more than a single ID to identify and configure any
clock provider. For those scenarios add an optional data field to the
clock control structure.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 include/clk.h | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/clk.h b/include/clk.h
index f6d1cc53a1..c0a20cd47a 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -40,10 +40,12 @@ struct udevice;
  *
  * @dev: The device which implements the clock signal.
  * @id: The clock signal ID within the provider.
+ * @data: An optional data field for scenarios where a single integer ID is not
+ *   sufficient. If used, it can be populated through an .of_xlate op and
+ *   processed during the various clock ops.
  *
- * Currently, the clock API assumes that a single integer ID is enough to
- * identify and configure any clock signal for any clock provider. If this
- * assumption becomes invalid in the future, the struct could be expanded to
+ * Should additional information to identify and configure any clock signal
+ * for any provider be required in the future, the struct could be expanded to
  * either (a) add more fields to allow clock providers to store additional
  * information, or (b) replace the id field with an opaque pointer, which the
  * provider would dynamically allocated during its .of_xlate op, and process
@@ -53,10 +55,10 @@ struct udevice;
 struct clk {
struct udevice *dev;
/*
-* Written by of_xlate. We assume a single id is enough for now. In the
-* future, we might add more fields here.
+* Written by of_xlate. In the future, we might add more fields here.
 */
unsigned long id;
+   unsigned long data;
 };
 
 /**
-- 
2.18.0

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


[U-Boot] [PATCH 7/8] armv8: K3: am654: Introduce FIT generator script

2018-08-21 Thread Lokesh Vutla
Add a script that is capable of generating a FIT image
source file that combines ATF, SPL(64 bit) and DT.
This combined image is used by R5 SPL and start ATF
on ARMv8 core.

Signed-off-by: Lokesh Vutla 
---
 tools/k3/k3_fit_atf.sh | 98 ++
 1 file changed, 98 insertions(+)
 create mode 100755 tools/k3/k3_fit_atf.sh

diff --git a/tools/k3/k3_fit_atf.sh b/tools/k3/k3_fit_atf.sh
new file mode 100755
index 00..ef84e3d182
--- /dev/null
+++ b/tools/k3/k3_fit_atf.sh
@@ -0,0 +1,98 @@
+#!/bin/sh
+#
+# script to generate FIT image source for K3 Family boards with
+# ATF, OPTEE, SPL and multiple device trees (given on the command line).
+# Inspired from board/sunxi/mksunxi_fit_atf.sh
+#
+# usage: $0  [ [&2
+   ATF=/dev/null
+fi
+
+[ -z "$TEE" ] && TEE="bl32.bin"
+
+if [ ! -f $TEE ]; then
+   echo "WARNING OPTEE file $TEE NOT found, resulting might be 
non-functional" >&2
+   TEE=/dev/null
+fi
+
+cat << __HEADER_EOF
+/dts-v1/;
+
+/ {
+   description = "Configuration to load ATF and SPL";
+   #address-cells = <1>;
+
+   images {
+   atf {
+   description = "ARM Trusted Firmware";
+   data = /incbin/("$ATF");
+   type = "firmware";
+   arch = "arm64";
+   compression = "none";
+   os = "arm-trusted-firmware";
+   load = <0x7000>;
+   entry = <0x7000>;
+   };
+   tee {
+   description = "OPTEE";
+   data = /incbin/("$TEE");
+   type = "tee";
+   arch = "arm64";
+   compression = "none";
+   os = "tee";
+   load = <0x9e80>;
+   entry = <0x9e80>;
+   };
+   spl {
+   description = "SPL (64-bit)";
+   data = /incbin/("spl/u-boot-spl-nodtb.bin");
+   type = "standalone";
+   os = "U-Boot";
+   arch = "arm64";
+   compression = "none";
+   load = <0x8008>;
+   entry = <0x8008>;
+   };
+__HEADER_EOF
+
+for dtname in $*
+do
+   cat << __FDT_IMAGE_EOF
+   $(basename $dtname) {
+   description = "$(basename $dtname .dtb)";
+   data = /incbin/("$dtname");
+   type = "flat_dt";
+   arch = "arm";
+   compression = "none";
+   };
+__FDT_IMAGE_EOF
+done
+
+cat << __CONF_HEADER_EOF
+   };
+   configurations {
+   default = "$(basename $1)";
+
+__CONF_HEADER_EOF
+
+for dtname in $*
+do
+   cat << __CONF_SECTION_EOF
+   $(basename $dtname) {
+   description = "$(basename $dtname .dtb)";
+   firmware = "atf";
+   loadables = "tee", "spl";
+   fdt = "$(basename $dtname)";
+   };
+__CONF_SECTION_EOF
+done
+
+cat << __ITS_EOF
+   };
+};
+__ITS_EOF
-- 
2.18.0

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


[U-Boot] [PATCH 04/25] firmware: ti_sci: Add support for clock control

2018-08-21 Thread Lokesh Vutla
In general, we expect to function at a device level of abstraction,
however, for proper operation of hardware blocks, many clocks directly
supplying the hardware block needs to be queried or configured.

Introduce support for the set of SCI message protocol support that
provide us with this capability.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 drivers/firmware/ti_sci.c  | 639 +
 drivers/firmware/ti_sci.h  | 289 +++
 include/linux/soc/ti/ti_sci_protocol.h |  78 +++
 3 files changed, 1006 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index fc55b0f67a..af7c5c7ee9 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -774,6 +774,629 @@ static int ti_sci_cmd_get_device_resets(const struct 
ti_sci_handle *handle,
   NULL);
 }
 
+/**
+ * ti_sci_set_clock_state() - Set clock state helper
+ * @handle:pointer to TI SCI handle
+ * @dev_id:Device identifier this request is for
+ * @clk_id:Clock identifier for the device for this request.
+ * Each device has it's own set of clock inputs. This indexes
+ * which clock input to modify.
+ * @flags: Header flags as needed
+ * @state: State to request for the clock.
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_set_clock_state(const struct ti_sci_handle *handle,
+ u32 dev_id, u8 clk_id,
+ u32 flags, u8 state)
+{
+   struct ti_sci_msg_req_set_clock_state req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TI_SCI_MSG_SET_CLOCK_STATE,
+flags | TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.dev_id = dev_id;
+   req.clk_id = clk_id;
+   req.request_state = state;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   return -ENODEV;
+
+   return ret;
+}
+
+/**
+ * ti_sci_cmd_get_clock_state() - Get clock state helper
+ * @handle:pointer to TI SCI handle
+ * @dev_id:Device identifier this request is for
+ * @clk_id:Clock identifier for the device for this request.
+ * Each device has it's own set of clock inputs. This indexes
+ * which clock input to modify.
+ * @programmed_state:  State requested for clock to move to
+ * @current_state: State that the clock is currently in
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_get_clock_state(const struct ti_sci_handle *handle,
+ u32 dev_id, u8 clk_id,
+ u8 *programmed_state, u8 *current_state)
+{
+   struct ti_sci_msg_resp_get_clock_state *resp;
+   struct ti_sci_msg_req_get_clock_state req;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   if (!programmed_state && !current_state)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TI_SCI_MSG_GET_CLOCK_STATE,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.dev_id = dev_id;
+   req.clk_id = clk_id;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_resp_get_clock_state *)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   return -ENODEV;
+
+   if (programmed_state)
+   *programmed_state = resp->programmed_state;
+   if (current_state)
+   *current_state = resp->current_state;
+
+   return ret;
+}
+
+/**
+ * ti_sci_cmd_get_clock() - G

[U-Boot] [PATCH 5/8] arm: K3: am654: Unlock control module registers during init

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

By default the device control module registers are locked,
preventing any writes to its registers.
Unlock those registers as part of the init flow.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/am6_init.c  | 39 
 arch/arm/mach-k3/include/mach/am6_hardware.h | 21 +++
 2 files changed, 60 insertions(+)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 8a7cedf66f..d7f1dff1db 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -12,6 +12,42 @@
 #include 
 
 #ifdef CONFIG_SPL_BUILD
+static void mmr_unlock(u32 base, u32 partition)
+{
+   /* Translate the base address */
+   phys_addr_t part_base = base + partition * CTRL_MMR0_PARTITION_SIZE;
+
+   /* Unlock the requested partition if locked using two-step sequence */
+   writel(CTRLMMR_LOCK_KICK0_UNLOCK_VAL, part_base + CTRLMMR_LOCK_KICK0);
+   writel(CTRLMMR_LOCK_KICK1_UNLOCK_VAL, part_base + CTRLMMR_LOCK_KICK1);
+}
+
+static void ctrl_mmr_unlock(void)
+{
+   /* Unlock all WKUP_CTRL_MMR0 module registers */
+   mmr_unlock(WKUP_CTRL_MMR0_BASE, 0);
+   mmr_unlock(WKUP_CTRL_MMR0_BASE, 1);
+   mmr_unlock(WKUP_CTRL_MMR0_BASE, 2);
+   mmr_unlock(WKUP_CTRL_MMR0_BASE, 3);
+   mmr_unlock(WKUP_CTRL_MMR0_BASE, 6);
+   mmr_unlock(WKUP_CTRL_MMR0_BASE, 7);
+
+   /* Unlock all MCU_CTRL_MMR0 module registers */
+   mmr_unlock(MCU_CTRL_MMR0_BASE, 0);
+   mmr_unlock(MCU_CTRL_MMR0_BASE, 1);
+   mmr_unlock(MCU_CTRL_MMR0_BASE, 2);
+   mmr_unlock(MCU_CTRL_MMR0_BASE, 6);
+
+   /* Unlock all CTRL_MMR0 module registers */
+   mmr_unlock(CTRL_MMR0_BASE, 0);
+   mmr_unlock(CTRL_MMR0_BASE, 1);
+   mmr_unlock(CTRL_MMR0_BASE, 2);
+   mmr_unlock(CTRL_MMR0_BASE, 3);
+   mmr_unlock(CTRL_MMR0_BASE, 6);
+   mmr_unlock(CTRL_MMR0_BASE, 7);
+
+}
+
 static void store_boot_index_from_rom(void)
 {
u32 *boot_index = (u32 *)K3_BOOT_PARAM_TABLE_INDEX_VAL;
@@ -27,6 +63,9 @@ void board_init_f(ulong dummy)
 */
store_boot_index_from_rom();
 
+   /* Make all control module registers accessible */
+   ctrl_mmr_unlock();
+
/* Init DM early in-order to invoke system controller */
spl_early_init();
 
diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h 
b/arch/arm/mach-k3/include/mach/am6_hardware.h
index b56aa60ec7..62bc7262a3 100644
--- a/arch/arm/mach-k3/include/mach/am6_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
@@ -17,6 +17,27 @@
 #define CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASKGENMASK(6, 4)
 #define CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT   4
 
+#define WKUP_CTRL_MMR0_BASE0x4300
+#define MCU_CTRL_MMR0_BASE 0x40f0
+
+/*
+ * The CTRL_MMR0 memory space is divided into several equally-spaced
+ * partitions, so defining the partition size allows us to determine
+ * register addresses common to those partitions.
+ */
+#define CTRL_MMR0_PARTITION_SIZE   0x4000
+
+/*
+ * CTRL_MMR0, WKUP_CTRL_MMR0, and MCU_CTR_MMR0 lock/kick-mechanism
+ * shared register definitions.
+ */
+#define CTRLMMR_LOCK_KICK0 0x01008
+#define CTRLMMR_LOCK_KICK0_UNLOCK_VAL  0x68ef3490
+#define CTRLMMR_LOCK_KICK0_UNLOCKED_MASK   BIT(0)
+#define CTRLMMR_LOCK_KICK0_UNLOCKED_SHIFT  0
+#define CTRLMMR_LOCK_KICK1 0x0100c
+#define CTRLMMR_LOCK_KICK1_UNLOCK_VAL  0xd172bc5a
+
 /* MCU SCRATCHPAD usage */
 #define K3_BOOT_PARAM_TABLE_INDEX_VAL  CONFIG_MCU_SCRATCHPAD_BASE
 
-- 
2.18.0

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


[U-Boot] [PATCH 03/25] firmware: ti_sci: Add support for device control

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

TI-SCI message protocol provides support for management of various
hardware entitites within the SoC. Introduce the fundamental
device management capability support to the driver protocol
as part of this change.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 drivers/firmware/ti_sci.c  | 391 +
 drivers/firmware/ti_sci.h  |  98 +++
 include/linux/soc/ti/ti_sci_protocol.h |  81 +
 3 files changed, 570 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index ce7483307e..fc55b0f67a 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -396,6 +396,384 @@ static int ti_sci_cmd_set_board_config_pm(const struct 
ti_sci_handle *handle,
  addr, size);
 }
 
+/**
+ * ti_sci_set_device_state() - Set device state helper
+ * @handle:pointer to TI SCI handle
+ * @id:Device identifier
+ * @flags: flags to setup for the device
+ * @state: State to move the device to
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_set_device_state(const struct ti_sci_handle *handle,
+  u32 id, u32 flags, u8 state)
+{
+   struct ti_sci_msg_req_set_device_state req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TI_SCI_MSG_SET_DEVICE_STATE,
+flags | TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.id = id;
+   req.state = state;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   return -ENODEV;
+
+   return ret;
+}
+
+/**
+ * ti_sci_get_device_state() - Get device state helper
+ * @handle:Handle to the device
+ * @id:Device Identifier
+ * @clcnt: Pointer to Context Loss Count
+ * @resets:pointer to resets
+ * @p_state:   pointer to p_state
+ * @c_state:   pointer to c_state
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_get_device_state(const struct ti_sci_handle *handle,
+  u32 id,  u32 *clcnt,  u32 *resets,
+  u8 *p_state,  u8 *c_state)
+{
+   struct ti_sci_msg_resp_get_device_state *resp;
+   struct ti_sci_msg_req_get_device_state req;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   if (!clcnt && !resets && !p_state && !c_state)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   /* Response is expected, so need of any flags */
+   xfer = ti_sci_setup_one_xfer(info, TI_SCI_MSG_GET_DEVICE_STATE, 0,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.id = id;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_resp_get_device_state *)xfer->tx_message.buf;
+   if (!ti_sci_is_response_ack(resp))
+   return -ENODEV;
+
+   if (clcnt)
+   *clcnt = resp->context_loss_count;
+   if (resets)
+   *resets = resp->resets;
+   if (p_state)
+   *p_state = resp->programmed_state;
+   if (c_state)
+   *c_state = resp->current_state;
+
+   return ret;
+}
+
+/**
+ * ti_sci_cmd_get_device() - command to request for device managed by TISCI
+ * @handle:Pointer to TISCI handle as retrieved by *ti_sci_get_handle
+ * @id:Device Identifier
+ *
+ * Request for the device - NOTE: the client MUST maintain integrity of
+ * usage count by balancing get_device with put_device. No refcounting is
+ * managed by driver for that purpose.
+ *
+ * NOTE: The request is for exclusive access for the processor.
+ *
+ * Return: 0 if all went fine, else return app

[U-Boot] [PATCH 05/25] firmware: ti_sci: Add support for reboot core service

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Since system controller now has control over SoC power management, it
needs to be explicitly requested to reboot the SoC. Add support for
it.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 drivers/firmware/ti_sci.c  | 47 ++
 drivers/firmware/ti_sci.h  | 11 ++
 include/linux/soc/ti/ti_sci_protocol.h | 12 +++
 3 files changed, 70 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index af7c5c7ee9..e04bae2ef4 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1397,6 +1397,50 @@ static int ti_sci_cmd_clk_get_freq(const struct 
ti_sci_handle *handle,
return ret;
 }
 
+/**
+ * ti_sci_cmd_core_reboot() - Command to request system reset
+ * @handle:pointer to TI SCI handle
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_core_reboot(const struct ti_sci_handle *handle)
+{
+   struct ti_sci_msg_req_reboot req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TI_SCI_MSG_SYS_RESET,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   return -ENODEV;
+
+   return ret;
+}
+
 /*
  * ti_sci_setup_ops() - Setup the operations structures
  * @info:  pointer to TISCI pointer
@@ -1407,6 +1451,7 @@ static void ti_sci_setup_ops(struct ti_sci_info *info)
struct ti_sci_board_ops *bops = &ops->board_ops;
struct ti_sci_dev_ops *dops = &ops->dev_ops;
struct ti_sci_clk_ops *cops = &ops->clk_ops;
+   struct ti_sci_core_ops *core_ops = &ops->core_ops;
 
bops->board_config = ti_sci_cmd_set_board_config;
bops->board_config_rm = ti_sci_cmd_set_board_config_rm;
@@ -1439,6 +1484,8 @@ static void ti_sci_setup_ops(struct ti_sci_info *info)
cops->get_best_match_freq = ti_sci_cmd_clk_get_match_freq;
cops->set_freq = ti_sci_cmd_clk_set_freq;
cops->get_freq = ti_sci_cmd_clk_get_freq;
+
+   core_ops->reboot_device = ti_sci_cmd_core_reboot;
 }
 
 /**
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index 7b7c7e7530..714a066985 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -95,6 +95,17 @@ struct ti_sci_msg_resp_version {
u8 abi_minor;
 } __packed;
 
+/**
+ * struct ti_sci_msg_req_reboot - Reboot the SoC
+ * @hdr:   Generic Header
+ *
+ * Request type is TI_SCI_MSG_SYS_RESET, responded with a generic
+ * ACK/NACK message.
+ */
+struct ti_sci_msg_req_reboot {
+   struct ti_sci_msg_hdr hdr;
+} __packed;
+
 /**
  * struct ti_sci_msg_board_config - Board configuration message
  * @hdr:   Generic Header
diff --git a/include/linux/soc/ti/ti_sci_protocol.h 
b/include/linux/soc/ti/ti_sci_protocol.h
index cec1c1a2bd..e3ce993fa3 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -213,16 +213,28 @@ struct ti_sci_clk_ops {
u64 *current_freq);
 };
 
+/**
+ * struct ti_sci_core_ops - SoC Core Operations
+ * @reboot_device: Reboot the SoC
+ * Returns 0 for successful request(ideally should never return),
+ * else returns corresponding error value.
+ */
+struct ti_sci_core_ops {
+   int (*reboot_device)(const struct ti_sci_handle *handle);
+};
+
 /**
  * struct ti_sci_ops - Function support for TI SCI
  * @board_ops: Miscellaneous operations
  * @dev_ops:   Device specific operations
  * @clk_ops:   Clock specific operations
+ * @core_ops:  Core specific operations
  */
 struct ti_sci_ops {
struct ti_sci_board_ops board_ops;
struct ti_sci_dev_ops dev_ops;
struct ti_sci_clk_ops clk_ops;
+   struct ti_sci_core_ops core_ops;
 };
 
 /**
-- 
2.18.0

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


[U-Boot] [PATCH 15/25] power domain: Introduce TI System Control Interface (TI SCI) power domain driver

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.

This patch adds a power domain driver that communicates to the system
controller over the TI SCI protocol for performing power management of
various devices present on the SoC. Various power domain functionalities
are achieved by the means of different TI SCI device operations provided
by the TI SCI framework.

This code is loosely based on the drivers/soc/ti/ti_sci_pm_domains.c
driver of the Linux kernel.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 .../power/ti,sci-pm-domain.txt|  52 +
 drivers/power/domain/Kconfig  |   7 ++
 drivers/power/domain/Makefile |   1 +
 drivers/power/domain/ti-sci-power-domain.c| 107 ++
 4 files changed, 167 insertions(+)
 create mode 100644 doc/device-tree-bindings/power/ti,sci-pm-domain.txt
 create mode 100644 drivers/power/domain/ti-sci-power-domain.c

diff --git a/doc/device-tree-bindings/power/ti,sci-pm-domain.txt 
b/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
new file mode 100644
index 00..0e190e20fe
--- /dev/null
+++ b/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
@@ -0,0 +1,52 @@
+Texas Instruments TI SCI Generic Power Domain
+=
+
+Some TI SoCs contain a system controller (like the SYSFW, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI SCI [1].
+
+[1] http://processors.wiki.ti.com/index.php/TISCI
+
+PM Domain Node
+==
+The PM domain node represents the global PM domain managed by the SYSFW. 
Because
+this relies on the TI SCI protocol to communicate with the SYSFW it must be a
+child of the sysfw node.
+
+Required Properties:
+
+- compatible: Must be "ti,sci-pm-domain"
+- #power-domain-cells: Must be 1 so that an id can be provided in each
+  device node.
+
+Example (AM65x):
+
+   sysfw: sysfw {
+   compatible = "ti,am654-system-controller";
+   ...
+   k3_pds: power-controller {
+   compatible = "ti,sci-pm-domain";
+   #power-domain-cells = <1>;
+   };
+   };
+
+PM Domain Consumers
+===
+Hardware blocks belonging to a PM domain should contain a "power-domains"
+property that is a phandle pointing to the corresponding PM domain node
+along with an index representing the device id to be passed to the PMMC
+for device control.
+
+Required Properties:
+
+- power-domains: phandle pointing to the corresponding PM domain node
+and an ID representing the device.
+
+Example (AM65x):
+
+   uart2: serial@0280 {
+   compatible = "ti,omap4-uart";
+   ...
+   power-domains = <&k3_pds 0x3f>;
+   };
diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig
index 7cfa761498..80b0b48b0f 100644
--- a/drivers/power/domain/Kconfig
+++ b/drivers/power/domain/Kconfig
@@ -31,4 +31,11 @@ config TEGRA186_POWER_DOMAIN
  Enable support for manipulating Tegra's on-SoC power domains via IPC
  requests to the BPMP (Boot and Power Management Processor).
 
+config TI_SCI_POWER_DOMAIN
+   bool "Enable the TI SCI-based power domain driver"
+   depends on POWER_DOMAIN && TI_SCI_PROTOCOL
+   help
+ Generic power domain implementation for TI devices implementing the
+ TI SCI protocol.
+
 endmenu
diff --git a/drivers/power/domain/Makefile b/drivers/power/domain/Makefile
index 020eee2378..9c6399b722 100644
--- a/drivers/power/domain/Makefile
+++ b/drivers/power/domain/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_BCM6328_POWER_DOMAIN) += bcm6328-power-domain.o
 obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain.o
 obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain-test.o
 obj-$(CONFIG_TEGRA186_POWER_DOMAIN) += tegra186-power-domain.o
+obj-$(CONFIG_TI_SCI_POWER_DOMAIN) += ti-sci-power-domain.o
diff --git a/drivers/power/domain/ti-sci-power-domain.c 
b/drivers/power/domain/ti-sci-power-domain.c
new file mode 100644
index 00..aafde62cbf
--- /dev/null
+++ b/drivers/power/domain/ti-sci-power-domain.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments System Control Interface (TI SCI) power domain driver
+ *
+ * Copy

[U-Boot] [PATCH 25/25] gpio: do not include for ARCH_K3

2018-08-21 Thread Lokesh Vutla
As no gpio.h is defined in arch/arm/mach-k3/include/,
to avoid compilation failure, do not include asm/arch/gpio.h.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/gpio.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 1c5e87340c..3039e66bf9 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -1,4 +1,5 @@
-#if !defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARCH_STI)
+#if !defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARCH_STI) && \
+   !defined(CONFIG_ARCH_K3)
 #include 
 #endif
 #include 
-- 
2.18.0

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


[U-Boot] [PATCH 08/25] dm: reset: Update uclass to allow querying reset status

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Add a reset operations function pointer to support querying the current
status of a reset control.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 drivers/reset/reset-uclass.c |  9 +
 include/reset-uclass.h   |  8 
 include/reset.h  | 14 ++
 3 files changed, 31 insertions(+)

diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
index 3899537635..89e39c6b5a 100644
--- a/drivers/reset/reset-uclass.c
+++ b/drivers/reset/reset-uclass.c
@@ -192,6 +192,15 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
return 0;
 }
 
+int reset_status(struct reset_ctl *reset_ctl)
+{
+   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+
+   debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
+
+   return ops->rst_status(reset_ctl);
+}
+
 int reset_release_all(struct reset_ctl *reset_ctl, int count)
 {
int i, ret;
diff --git a/include/reset-uclass.h b/include/reset-uclass.h
index c17d738b31..7b5cc3cb3b 100644
--- a/include/reset-uclass.h
+++ b/include/reset-uclass.h
@@ -76,6 +76,14 @@ struct reset_ops {
 * @return 0 if OK, or a negative error code.
 */
int (*rst_deassert)(struct reset_ctl *reset_ctl);
+   /**
+* rst_status - Check reset signal status.
+*
+* @reset_ctl:  The reset signal to check.
+* @return 0 if deasserted, positive if asserted, or a negative
+*   error code.
+*/
+   int (*rst_status)(struct reset_ctl *reset_ctl);
 };
 
 #endif
diff --git a/include/reset.h b/include/reset.h
index a7bbc1c331..34ebb096dd 100644
--- a/include/reset.h
+++ b/include/reset.h
@@ -206,6 +206,15 @@ int reset_deassert(struct reset_ctl *reset_ctl);
  */
 int reset_deassert_bulk(struct reset_ctl_bulk *bulk);
 
+/**
+ * rst_status - Check reset signal status.
+ *
+ * @reset_ctl: The reset signal to check.
+ * @return 0 if deasserted, positive if asserted, or a negative
+ *   error code.
+ */
+int reset_status(struct reset_ctl *reset_ctl);
+
 /**
  * reset_release_all - Assert/Free an array of previously requested resets.
  *
@@ -279,6 +288,11 @@ static inline int reset_deassert_bulk(struct 
reset_ctl_bulk *bulk)
return 0;
 }
 
+static inline int reset_status(struct reset_ctl *reset_ctl)
+{
+   return -ENOTSUPP;
+}
+
 static inline int reset_release_all(struct reset_ctl *reset_ctl, int count)
 {
return 0;
-- 
2.18.0

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


[U-Boot] [PATCH 2/6] board: ti: am65x: Add README

2018-08-21 Thread Lokesh Vutla
Add README file that describes the building and booting procedure.

Signed-off-by: Lokesh Vutla 
---
 board/ti/am65x/README | 134 ++
 1 file changed, 134 insertions(+)
 create mode 100644 board/ti/am65x/README

diff --git a/board/ti/am65x/README b/board/ti/am65x/README
new file mode 100644
index 00..1956142270
--- /dev/null
+++ b/board/ti/am65x/README
@@ -0,0 +1,134 @@
+Introduction:
+-
+The AM65x family of SoCs is the first device family from K3 Multicore
+SoC architecture, targeted for broad market and industrial control with
+aim to meet the complex processing needs of modern embedded products.
+
+The device is built over three domains, each containing specific processing
+cores, voltage domains and peripherals:
+1. Wake-up (WKUP) domain:
+   - Device Management and Security Controller (DMSC)
+2. Microcontroller (MCU) domain:
+   - Dual Core ARM Cortex-R5F processor
+3. MAIN domain:
+   - Quad core 64-bit ARM Cortex-A53
+
+More info can be found in TRM: http://www.ti.com/lit/pdf/spruid7
+
+Boot Flow:
+--
+On AM65x family devices, ROM supports boot only via MCU(R5). This means that
+bootloader has to run on R5 core. In order to meet this constraint,
+keeping safety in picture and to have faster boot time, the software boot
+architecture is designed as below:
+
+++
+|DMSC| R5|A53|
+++
+|++  |   |   |
+||  Reset |  |   |   |
+|++  |   |   |
+| :  |   |   |
+|++  |   +---+   |   |
+|| *rom*  |--|-->| Reset rls |   |   |
+|++  |   +---+   |   |
+|||  | : |   |
+||  rom   |  | : |   |
+||services|  | : |   |
+|||  |   +-+ |   |
+|||  |   |  *R5 rom*   | |   |
+|||  |   +-+ |   |
+|||<-|---|Load and auth| |   |
+|||  |   | tiboot3.bin | |   |
+|||  |   +-+ |   |
+|||  | : |   |
+|||  | : |   |
+|||  | : |   |
+|||  |   +-+ |   |
+|| Start  |  |   |  *R5 SPL*   | |   |
+|| System |  |   +-+ |   |
+||Firmware|<-|---|Load and auth| |   |
+|++  |   |  sysfw bin  | |   |
+|:   |   +-+ |   |
+|+-+ |   | DDR | |   |
+|| *SYSFW* | |   |config   | |   |
+|+-+ |   +-+ |   |
+|| |<|---|Load | |   |
+|| | |   |  tispl.bin  | |   |
+|| | |   +-+ |   |
+|| |<|---| Start A53   | |   |
+|| | |   |  and Reset  | |   |
+|| | |   +-+ |   |
+|| | |   | +---+ |
+|| |-|---|>| Reset rls | |
+|| | |   | +---+ |
+||  DMSC   | |   |  :|
+||Services | |   | +---+ |
+|| |<|---|>|*ATF/OPTEE*| |
+|| | |   | +---+ |
+|| | |   |  :|
+|| | |   | +---+ |
+|| |<|---|>| *A53 SPL* | |
+|| | |   | +---

[U-Boot] [PATCH 06/25] firmware: ti_sci: Add support for processor control services

2018-08-21 Thread Lokesh Vutla
TI-SCI message protocol provides support for controlling of various
physical cores available in SoC. In order to control which host is
capable of controlling a physical processor core, there is a processor
access control list that needs to be populated as part of the board
configuration data.

Introduce support for the set of TI-SCI message protocol apis that
provide us with this capability of controlling physical cores.

ToDo:
- Create separate TISCI commands for control, config, status flags.
- Update Documentation.

Signed-off-by: Lokesh Vutla 
---
 drivers/firmware/ti_sci.c  | 371 +
 drivers/firmware/ti_sci.h  | 181 
 include/linux/soc/ti/ti_sci_protocol.h |  37 +++
 3 files changed, 589 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index e04bae2ef4..32d69dab2f 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1441,6 +1441,368 @@ static int ti_sci_cmd_core_reboot(const struct 
ti_sci_handle *handle)
return ret;
 }
 
+/**
+ * ti_sci_cmd_proc_request() - Command to request a physical processor control
+ * @handle:Pointer to TI SCI handle
+ * @proc_id:   Processor ID this request is for
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_proc_request(const struct ti_sci_handle *handle,
+  u8 proc_id)
+{
+   struct ti_sci_msg_req_proc_request req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_REQUEST,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.processor_id = proc_id;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   ret = -ENODEV;
+
+   return ret;
+}
+
+/**
+ * ti_sci_cmd_proc_release() - Command to release a physical processor control
+ * @handle:Pointer to TI SCI handle
+ * @proc_id:   Processor ID this request is for
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_proc_release(const struct ti_sci_handle *handle,
+  u8 proc_id)
+{
+   struct ti_sci_msg_req_proc_release req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_RELEASE,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.processor_id = proc_id;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   ret = -ENODEV;
+
+   return ret;
+}
+
+/**
+ * ti_sci_cmd_proc_handover() - Command to handover a physical processor
+ * control to a host in the processor's access
+ * control list.
+ * @handle:Pointer to TI SCI handle
+ * @proc_id:   Processor ID this request is for
+ * @host_id:   Host ID to get the control of the processor
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_proc_handover(const struct ti_sci_handle *handle,
+   u8 proc_id, u8 host_id)
+{
+   struct ti_sci_msg_req_proc_handover req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_PROC_

[U-Boot] [PATCH 07/25] dm: firmware: Automatically bind child devices

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

To support scenarios where a firmware device node has subnodes that
have their own drivers automatically scan the DT and bind those when
the firmware device gets bound.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 drivers/firmware/firmware-uclass.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/firmware-uclass.c 
b/drivers/firmware/firmware-uclass.c
index d09923595b..3d33b6deba 100644
--- a/drivers/firmware/firmware-uclass.c
+++ b/drivers/firmware/firmware-uclass.c
@@ -7,4 +7,7 @@
 UCLASS_DRIVER(firmware) = {
.id = UCLASS_FIRMWARE,
.name   = "firmware",
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+   .post_bind  = dm_scan_fdt_dev,
+#endif
 };
-- 
2.18.0

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


[U-Boot] [PATCH 13/25] clk: Introduce TI System Control Interface (TI SCI) clock driver

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.

This patch adds a clock driver that communicates to the system
controller over the TI SCI protocol for performing clock management of
various devices present on the SoC. Various clock functionality is
achieved by the means of different TI SCI device operations provided by
the TI SCI framework.

This code is loosely based on the drivers/clk/keystone/sci-clk.c driver
of the Linux kernel.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Vignesh R 
Signed-off-by: Lokesh Vutla 
---
 doc/device-tree-bindings/clock/ti,sci-clk.txt |  53 +
 drivers/clk/Kconfig   |   8 +
 drivers/clk/Makefile  |   1 +
 drivers/clk/clk-ti-sci.c  | 217 ++
 4 files changed, 279 insertions(+)
 create mode 100644 doc/device-tree-bindings/clock/ti,sci-clk.txt
 create mode 100644 drivers/clk/clk-ti-sci.c

diff --git a/doc/device-tree-bindings/clock/ti,sci-clk.txt 
b/doc/device-tree-bindings/clock/ti,sci-clk.txt
new file mode 100644
index 00..c6fe48200c
--- /dev/null
+++ b/doc/device-tree-bindings/clock/ti,sci-clk.txt
@@ -0,0 +1,53 @@
+Texas Instruments TI SCI Clock Controller
+=
+
+All clocks on Texas Instruments' SoCs that contain a System Controller,
+are only controlled by this entity. Communication between a host processor
+running an OS and the System Controller happens through a protocol known
+as TI SCI[1]. This clock implementation plugs into the common clock
+framework and makes use of the TI SCI protocol on clock API requests.
+
+[1] http://processors.wiki.ti.com/index.php/TISCI
+
+Clock Controller Node
+=
+The clock controller node represents the clocks managed by the SYSFW. Because
+this relies on the TI SCI protocol to communicate with the SYSFW it must be a
+child of the sysfw node.
+
+Required Properties:
+
+- compatible: Must be "ti,k2g-sci-clk"
+- #clock-cells: Must be be 2. In clock consumers, this cell represents the
+   device ID and clock ID exposed by the SYSFW firmware.
+
+Example (AM65x):
+
+   dmsc: dmsc {
+   compatible = "ti,k2g-sci";
+   ...
+   k3_clks: clocks {
+   compatible = "ti,k2g-sci-clk";
+   #clock-cells = <2>;
+   };
+   };
+
+Clock Consumers
+===
+Hardware blocks supplied by a clock should contain a "clocks" property that is
+a phandle pointing to the clock controller node along with an index 
representing
+the device id together with a clock ID to be passed to the SYSFW for device
+control.
+
+Required Properties:
+
+- clocks: phandle pointing to the corresponding clock node, an ID representing
+ the device, and an index representing a clock.
+
+Example (AM65x):
+
+   uart2: serial@0280 {
+   compatible = "ti,omap4-uart";
+   ...
+   clocks = <&k3_clks 0x0007 1>;
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 18bf8a6d28..45638caf96 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -54,6 +54,14 @@ config CLK_STM32F
  This clock driver adds support for RCC clock management
  for STM32F4 and STM32F7 SoCs.
 
+config CLK_TI_SCI
+   bool "TI System Control Interface (TI SCI) clock driver"
+   depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL
+   help
+ This enables the clock driver support over TI System Control Interface
+ available on some new TI's SoCs. If you wish to use clock resources
+ managed by the TI System Controller, say Y here. Otherwise, say N.
+
 config CLK_HSDK
bool "Enable cgu clock driver for HSDK"
depends on CLK
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 146283c723..1544a1d82d 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_MACH_PIC32) += clk_pic32.o
 obj-$(CONFIG_SANDBOX) += clk_sandbox.o
 obj-$(CONFIG_SANDBOX) += clk_sandbox_test.o
 obj-$(CONFIG_STM32H7) += clk_stm32h7.o
+obj-$(CONFIG_CLK_TI_SCI) += clk-ti-sci.o
diff --git a/drivers/clk/clk-ti-sci.c b/drivers/clk/clk-ti-sci.c
new file mode 100644
index 00..c25415d410
--- /dev/null
+++ b/drivers/clk/clk-ti-sci.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments System Control Interface (TI SCI) clock driver
+ *
+ * Copyright (C) 2018 Texas

[U-Boot] [PATCH 0/6] [3/3] Initial support Texas Instrument's AM654 Platform

2018-08-21 Thread Lokesh Vutla
Continue from PART 2/3...

This series adds arm64 support for AM654 EVM. Patch 2/6 describes the
boot flow in detail. I would recommend to go through the patch in order
to understand the entire boot flow.

Right now only arm64 support is added. r5 support will be posted later
once loading of system firmware is ported to generic filesystem loader.

Andreas Dannenberg (1):
  include: am654_evm: Establish initial environment for SD card boot

Lokesh Vutla (5):
  board: ti: am654: a53: Add initial support for am654
  board: ti: am65x: Add README
  arm64: dts: k3: Add Support for AM654 SoC
  arm64: dts: k3: Add u-boot specific nodes
  configs: am65x_evm_a53: Add initial support

 arch/arm/dts/Makefile|   2 +
 arch/arm/dts/k3-am65-main.dtsi   |  31 +++
 arch/arm/dts/k3-am65.dtsi|  87 
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 203 +++
 arch/arm/dts/k3-am654-base-board.dts |  36 
 arch/arm/dts/k3-am654.dtsi   | 115 +++
 arch/arm/mach-k3/Kconfig |   1 +
 board/ti/am65x/Kconfig   |  30 +++
 board/ti/am65x/MAINTAINERS   |   6 +
 board/ti/am65x/Makefile  |   8 +
 board/ti/am65x/README| 134 
 board/ti/am65x/evm.c |  68 +++
 configs/am65x_evm_a53_defconfig  |  71 +++
 include/configs/am65x_evm.h  |  71 +++
 include/dt-bindings/pinctrl/k3-am65.h|  49 +
 15 files changed, 912 insertions(+)
 create mode 100644 arch/arm/dts/k3-am65-main.dtsi
 create mode 100644 arch/arm/dts/k3-am65.dtsi
 create mode 100644 arch/arm/dts/k3-am654-base-board-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am654-base-board.dts
 create mode 100644 arch/arm/dts/k3-am654.dtsi
 create mode 100644 board/ti/am65x/Kconfig
 create mode 100644 board/ti/am65x/MAINTAINERS
 create mode 100644 board/ti/am65x/Makefile
 create mode 100644 board/ti/am65x/README
 create mode 100644 board/ti/am65x/evm.c
 create mode 100644 configs/am65x_evm_a53_defconfig
 create mode 100644 include/configs/am65x_evm.h
 create mode 100644 include/dt-bindings/pinctrl/k3-am65.h

-- 
2.18.0

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


[U-Boot] [PATCH 21/25] remoteproc: Introduce K3 system controller

2018-08-21 Thread Lokesh Vutla
K3 specific SoCs have a dedicated microcontroller for doing
resource management. Any HLOS/firmware on compute clusters should
load a firmware to this microcontroller before accessing any resource.
Adding support for loading this firmware.

After the K3 system controller got loaded with firmware and started
up it sends out a boot notification message through the secure proxy
facility using the TI SCI protocol. Intercept and receive this message
through the rproc start operation which will need to get invoked
explicitly after the firmware got loaded.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
---
 .../remoteproc/k3-system-controller.txt   |  24 ++
 drivers/remoteproc/Kconfig|   9 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/k3_system_controller.c | 323 ++
 4 files changed, 357 insertions(+)
 create mode 100644 doc/device-tree-bindings/remoteproc/k3-system-controller.txt
 create mode 100644 drivers/remoteproc/k3_system_controller.c

diff --git a/doc/device-tree-bindings/remoteproc/k3-system-controller.txt 
b/doc/device-tree-bindings/remoteproc/k3-system-controller.txt
new file mode 100644
index 00..32f4720b0d
--- /dev/null
+++ b/doc/device-tree-bindings/remoteproc/k3-system-controller.txt
@@ -0,0 +1,24 @@
+Texas Instruments' K3 System Controller
+=
+
+K3 specific SoCs have a dedicated microcontroller for doing
+resource management. Any HLOS/firmware on compute clusters should
+load a firmware to this microcontroller before accessing any resource.
+This driver communicates with ROM for loading this firmware.
+
+Required properties:
+
+- compatible:  Shall be: "ti,am654-system-controller"
+- mbox-names:  "tx" for Transfer channel
+   "rx" for Receive channel
+- mboxes:  Corresponding phandles to mailbox channels.
+
+
+Example:
+
+
+system-controller: system-controller {
+   compatible = "ti,am654-system-controller";
+   mboxes= <&secproxy 4>, <&secproxy 5>;
+   mbox-names = "tx", "rx";
+};
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index becae5f85d..812d30153b 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -13,6 +13,15 @@ config REMOTEPROC
depends on DM
 
 # Please keep the configuration alphabetically sorted.
+config K3_SYSTEM_CONTROLLER
+   bool "Support for TI' K3 System Controller"
+   select REMOTEPROC
+   depends on DM
+   depends on ARCH_K3
+   depends on OF_CONTROL
+   help
+ Say 'y' here to add support for TI' K3 System Controller.
+
 config REMOTEPROC_SANDBOX
bool "Support for Test processor for Sandbox"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index bda995e21b..bfd02ad52d 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -7,5 +7,6 @@
 obj-$(CONFIG_REMOTEPROC) += rproc-uclass.o
 
 # Remote proc drivers - Please keep this list alphabetically sorted.
+obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
 obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
 obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
diff --git a/drivers/remoteproc/k3_system_controller.c 
b/drivers/remoteproc/k3_system_controller.c
new file mode 100644
index 00..3c316a1234
--- /dev/null
+++ b/drivers/remoteproc/k3_system_controller.c
@@ -0,0 +1,323 @@
+// SPDX-License-Identifier:GPL-2.0+
+/*
+ * Texas Instruments' K3 System Controller Driver
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define K3_MSG_R5_TO_M3_M3FW   0x8105
+#define K3_MSG_M3_TO_R5_CERT_RESULT0x8805
+#define K3_MSG_M3_TO_R5_BOOT_NOTIFICATION  0x000A
+
+#define K3_FLAGS_MSG_CERT_AUTH_PASS0x55
+#define K3_FLAGS_MSG_CERT_AUTH_FAIL0xff
+
+/**
+ * struct k3_sysctrler_msg_hdr - Generic Header for Messages and responses.
+ * @cmd_id:Message ID. One of K3_MSG_*
+ * @host_id:   Host ID of the message
+ * @seq_ne:Message identifier indicating a transfer sequence.
+ * @flags: Flags for the message.
+ */
+struct k3_sysctrler_msg_hdr {
+   u16 cmd_id;
+   u8 host_id;
+   u8 seq_nr;
+   u32 flags;
+} __attribute__ ((__packed__));
+
+/**
+ * struct k3_sysctrler_load_msg - Message format for Firmware loading
+ * @hdr:   Generic message hdr
+ * @buffer_address:Address at which firmware is located.
+ * @buffer_size:   Size of the firmware.
+ */
+struct k3_sysctrler_load_msg {
+   struct k3_sysctrler_msg_hdr hdr;
+   u32 buffer_address;
+   u32 buffer_size;
+} __attribute__ ((__packed__));
+
+/**
+ * struct k3_sysctrler_boot_notification_msg - Message format for boot
+ *

[U-Boot] [PATCH 22/25] remoteproc: Introduce K3 remoteproc driver

2018-08-21 Thread Lokesh Vutla
Add support for K3 based remoteproc driver that
communicates with TISCI to start start a remote processor.

Signed-off-by: Lokesh Vutla 
---
 .../remoteproc/k3-rproc.txt   |  50 
 drivers/remoteproc/Kconfig|   9 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/k3_rproc.c | 244 ++
 4 files changed, 304 insertions(+)
 create mode 100644 doc/device-tree-bindings/remoteproc/k3-rproc.txt
 create mode 100644 drivers/remoteproc/k3_rproc.c

diff --git a/doc/device-tree-bindings/remoteproc/k3-rproc.txt 
b/doc/device-tree-bindings/remoteproc/k3-rproc.txt
new file mode 100644
index 00..0a1e858225
--- /dev/null
+++ b/doc/device-tree-bindings/remoteproc/k3-rproc.txt
@@ -0,0 +1,50 @@
+Texas Instruments' K3 Remote processor driver
+=
+
+In K3 generation Socs, loading an image on any processing entity
+cannot be done directly from U-Boot. In order to load an image,
+remoteproc driver should communicate to SYSFW with a specific sequence.
+Also enable the timer required for this remotecore.
+
+Required properties:
+
+- compatible:  Shall be: "ti,am654-rproc"
+- reg: base address of the remoteproc timer.
+- power-domains:   Should contain two sets of entries:
+   First set corresponds to pm domain of the
+   remotecore timer. Seconf entry corresponds to the
+   remoteproc to start.
+   This property is as per the binding,
+   doc/device-tree-bindings/power/ti,sci-pm-domain.txt
+- resets:  Should contain a phandle to a reset controller node
+   and an args specifier containing the remote code
+   device id and reset mask value. This is as per the
+   doc/device-tree-bindings/reset/ti,sci-reset.txt
+- ti,sci:  Phandle to TI-SCI compatible System controller node.
+- ti,sci-proc-id:  Processor id as identified by TISCI
+
+Optional properties:
+
+- assigned-clocks: Should contain a phandle to clock node and an args
+   specifier containing the remote core device id and
+   the clock id within the remote core. This is as per
+   doc/device-tree-bindings/clock/ti,sci-clk.txt
+- assigned-clock-rates: One entry for each entry of assigned-clocks. This is
+   the frequency at which the corresponding clock needs
+   to be assigned.
+- ti,sci-host-id:  Host ID to which the processor control is transferred to
+
+Example:
+-
+
+a53_0: a53@0 {
+   compatible = "ti,am654-rproc";
+   power-domains = <&k3_pds 61>,
+   <&k3_pds 202>;
+   resets = <&k3_reset 202 0>;
+   assigned-clocks = <&k3_clks 202 0>;
+   assigned-clock-rates = <8>;
+   ti,sci = <&dmsc>;
+   ti,sci-proc-id = <32>;
+   ti,sci-host-id = <10>;
+};
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 812d30153b..9eb532bc7a 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -22,6 +22,15 @@ config K3_SYSTEM_CONTROLLER
help
  Say 'y' here to add support for TI' K3 System Controller.
 
+config REMOTEPROC_K3
+   bool "Support for TI's K3 based remoteproc driver"
+   select REMOTEPROC
+   depends on DM
+   depends on ARCH_K3
+   depends on OF_CONTROL
+   help
+ Say 'y' here to add support for TI' K3 remoteproc driver.
+
 config REMOTEPROC_SANDBOX
bool "Support for Test processor for Sandbox"
select REMOTEPROC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index bfd02ad52d..87ef9e61a7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_REMOTEPROC) += rproc-uclass.o
 
 # Remote proc drivers - Please keep this list alphabetically sorted.
 obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
+obj-$(CONFIG_REMOTEPROC_K3) += k3_rproc.o
 obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
 obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
diff --git a/drivers/remoteproc/k3_rproc.c b/drivers/remoteproc/k3_rproc.c
new file mode 100644
index 00..4028d4aa66
--- /dev/null
+++ b/drivers/remoteproc/k3_rproc.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier:GPL-2.0+
+/*
+ * Texas Instruments' K3 Remoteproc driver
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INVALID_ID 0x
+
+#define GTC_CNTCR_REG  0x0
+#define GTC_CNTR_EN0x3
+
+/**
+ * struct k3_rproc_privdata - Structure representing Remote processor data.
+ * @rproc_pwrdmn:  rpro

[U-Boot] [PATCH 17/25] mailbox: Allow attaching private data for mbox_chan

2018-08-21 Thread Lokesh Vutla
Sometimes mbox controllers wants to store private data in
mbox_chan so that it can be used at a later point of time.
Adding support for hooking private data.

Signed-off-by: Lokesh Vutla 
---
 include/mailbox.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/include/mailbox.h b/include/mailbox.h
index c64951b2f7..93f4715e16 100644
--- a/include/mailbox.h
+++ b/include/mailbox.h
@@ -44,6 +44,7 @@ struct udevice;
  *
  * @dev: The device which implements the mailbox.
  * @id: The mailbox channel ID within the provider.
+ * @con_priv: Hook for controller driver to attach private data
  *
  * Currently, the mailbox API assumes that a single integer ID is enough to
  * identify and configure any mailbox channel for any mailbox provider. If this
@@ -56,11 +57,9 @@ struct udevice;
  */
 struct mbox_chan {
struct udevice *dev;
-   /*
-* Written by of_xlate. We assume a single id is enough for now. In the
-* future, we might add more fields here.
-*/
+   /* Written by of_xlate.*/
unsigned long id;
+   void *con_priv;
 };
 
 /**
-- 
2.18.0

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


[U-Boot] [PATCH 18/25] mailbox: Introduce K3 Secure Proxy Driver

2018-08-21 Thread Lokesh Vutla
Secure Proxy module manages hardware threads that are meant
for communication between the processor entities. Adding
support for this driver.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
---
 .../mailbox/k3-secure-proxy.txt   |  40 ++
 drivers/mailbox/Kconfig   |  10 +
 drivers/mailbox/Makefile  |   1 +
 drivers/mailbox/k3-sec-proxy.c| 438 ++
 include/linux/soc/ti/k3-sec-proxy.h   |  25 +
 5 files changed, 514 insertions(+)
 create mode 100644 doc/device-tree-bindings/mailbox/k3-secure-proxy.txt
 create mode 100644 drivers/mailbox/k3-sec-proxy.c
 create mode 100644 include/linux/soc/ti/k3-sec-proxy.h

diff --git a/doc/device-tree-bindings/mailbox/k3-secure-proxy.txt 
b/doc/device-tree-bindings/mailbox/k3-secure-proxy.txt
new file mode 100644
index 00..f3add0d4e7
--- /dev/null
+++ b/doc/device-tree-bindings/mailbox/k3-secure-proxy.txt
@@ -0,0 +1,40 @@
+Texas Instruments' K3 Secure Proxy
+===
+
+The Texas Instruments' K3 Secure Proxy is a mailbox controller that has
+configurable threads maintained by System power processor. Each thread
+has different address space that can be used to send or receive messages.
+
+Secure Proxy Device Node:
+===
+Required properties:
+
+- compatible:  Shall be: "ti,am654-secure-proxy"
+- reg-namesdata - Map the data region
+   scfg - Map the secure configuration region
+   rt - Map the Realtime region.
+- reg: Contains the register map per reg-names.
+- #mbox-cells  Shall be 1. Contains the thread ID.
+
+Example:
+
+
+secproxy: secproxy@285b {
+   compatible = "ti,am654-secure-proxy";
+   reg = <0x2a38 0x8>,
+   <0x2a40 0x8>,
+   <0x2a48 0x8>;
+   reg-names = "rt", "scfg", "data";
+   #mbox-cells = <1>;
+};
+
+client:
+
+systemcontroller: systemcontroller {
+   [...]
+   # RX thread ID is 4.
+   # TX thread ID is 5.
+   mboxes= <&secproxy 4>,
+   <&secproxy 5>;
+   [...]
+};
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 9649b70589..2836ee4a7b 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -24,4 +24,14 @@ config TEGRA_HSP
  This enables support for the NVIDIA Tegra HSP Hw module, which
  implements doorbells, mailboxes, semaphores, and shared interrupts.
 
+config K3_SEC_PROXY
+   bool "Texas Instruments K3 Secure Proxy Driver"
+   depends on DM_MAILBOX && ARCH_K3
+   help
+ An implementation of Secure proxy slave driver for K3 SoCs from
+ Texas Instruments. Secure proxy is a communication entity mainly
+ used for communication between multiple processors with the SoC.
+ Select this driver if your platform has support for this hardware
+ block.
+
 endmenu
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 155dbeb099..4ac85d412f 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DM_MAILBOX) += mailbox-uclass.o
 obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox.o
 obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox-test.o
 obj-$(CONFIG_TEGRA_HSP) += tegra-hsp.o
+obj-$(CONFIG_K3_SEC_PROXY) += k3-sec-proxy.o
diff --git a/drivers/mailbox/k3-sec-proxy.c b/drivers/mailbox/k3-sec-proxy.c
new file mode 100644
index 00..4654c8cb82
--- /dev/null
+++ b/drivers/mailbox/k3-sec-proxy.c
@@ -0,0 +1,438 @@
+// SPDX-License-Identifier:GPL-2.0+
+/*
+ * Texas Instruments' K3 Secure proxy Driver
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* SEC PROXY RT THREAD STATUS */
+#define RT_THREAD_STATUS   0x0
+#define RT_THREAD_THRESHOLD0x4
+#define RT_THREAD_STATUS_ERROR_SHIFT   31
+#define RT_THREAD_STATUS_ERROR_MASKBIT(31)
+#define RT_THREAD_STATUS_CUR_CNT_SHIFT 0
+#define RT_THREAD_STATUS_CUR_CNT_MASK  GENMASK(7, 0)
+
+/* SEC PROXY SCFG THREAD CTRL */
+#define SCFG_THREAD_CTRL   0x1000
+#define SCFG_THREAD_CTRL_DIR_SHIFT 31
+#define SCFG_THREAD_CTRL_DIR_MASK  BIT(31)
+
+#define SEC_PROXY_THREAD(base, x)  ((base) + (0x1000 * (x)))
+#define THREAD_IS_RX   1
+#define THREAD_IS_TX   0
+
+/**
+ * struct k3_sec_proxy_desc - Description of secure proxy integration.
+ * @thread_count:  Number of Threads.
+ * @max_msg_size:  Message size in bytes.
+ * @data_start_offset: Offset of the First data register of the thread
+ * @data_end_offset:   Offset of the Last data register of the thread
+ * @valid_

[U-Boot] [PATCH 16/25] sysreset: Add TI System Control Interface (TI SCI) sysreset driver

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Devices from the TI K3 family of SoCs like the AM654x contain a Device
Management and Security Controller (SYSFW) that manages the low-level
device control (like clocks, resets etc) for the various hardware
modules present on the SoC. These device control operations are provided
to the host processor OS through a communication protocol called the TI
System Control Interface (TI SCI) protocol.

This patch adds a system reset driver that communicates to the system
controller over the TI SCI protocol for allowing to perform a system-
wide SoC reset.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 .../sysreset/ti,sci-sysreset.txt  | 29 
 drivers/sysreset/Kconfig  |  7 ++
 drivers/sysreset/Makefile |  1 +
 drivers/sysreset/sysreset-ti-sci.c| 73 +++
 4 files changed, 110 insertions(+)
 create mode 100644 doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt
 create mode 100644 drivers/sysreset/sysreset-ti-sci.c

diff --git a/doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt 
b/doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt
new file mode 100644
index 00..02704c6487
--- /dev/null
+++ b/doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt
@@ -0,0 +1,29 @@
+Texas Instruments TI SCI System Reset Controller
+
+
+Some TI SoCs contain a system controller (like the SYSFW, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI SCI [1].
+
+[1] http://processors.wiki.ti.com/index.php/TISCI
+
+System Reset Controller Node
+
+The sysreset controller node represents the reset for the overall SoC
+which is managed by the SYSFW. Because this relies on the TI SCI protocol
+to communicate with the SYSFW it must be a child of the sysfw node.
+
+Required Properties:
+
+ - compatible: Must be "ti,sci-sysreset"
+
+Example (AM65x):
+
+   sysfw: sysfw {
+   compatible = "ti,am654-system-controller";
+   ...
+   k3_sysreset: sysreset-controller {
+   compatible = "ti,sci-sysreset";
+   };
+   };
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 9b2fda4d25..ed1d437fb0 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -36,6 +36,13 @@ config SYSRESET_PSCI
  Enable PSCI SYSTEM_RESET function call.  To use this, PSCI firmware
  must be running on your system.
 
+config SYSRESET_TI_SCI
+   bool "TI System Control Interface (TI SCI) system reset driver"
+   depends on TI_SCI_PROTOCOL
+   help
+ This enables the system reset driver support over TI System Control
+ Interface available on some new TI's SoCs.
+
 endif
 
 config SYSRESET_SYSCON
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index 707f1d7469..02ee1df6b0 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SYSRESET) += sysreset-uclass.o
 obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
 obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
 obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
+obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
 obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
 obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
 obj-$(CONFIG_SYSRESET_X86) += sysreset_x86.o
diff --git a/drivers/sysreset/sysreset-ti-sci.c 
b/drivers/sysreset/sysreset-ti-sci.c
new file mode 100644
index 00..890a607c4b
--- /dev/null
+++ b/drivers/sysreset/sysreset-ti-sci.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments System Control Interface (TI SCI) system reset driver
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Andreas Dannenberg 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct ti_sci_sysreset_data - sysreset controller information structure
+ * @sci: TI SCI handle used for communication with system controller
+ */
+struct ti_sci_sysreset_data {
+   const struct ti_sci_handle *sci;
+};
+
+static int ti_sci_sysreset_probe(struct udevice *dev)
+{
+   struct ti_sci_sysreset_data *data = dev_get_priv(dev);
+
+   debug("%s(dev=%p)\n", __func__, dev);
+
+   if (!data)
+   return -ENOMEM;
+
+   /* Store handle for communication with the system controller */
+   data->sci = ti_sci_get_handle(dev);
+   if (IS_ERR(data->sci))
+   return PTR_ERR(data->sci);
+
+   return 0;
+}
+
+static int ti_sci_sysreset_request(struct udevice *dev, enum sysreset_t type)
+{
+   struct ti_sci_sysreset_data *data = dev_get_priv(dev);
+   const struct ti_sci_handle *sci = data->sci;
+   const 

[U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
which introduced the functionality for setting clock defaults such as
rates and parents will skip the processing when executing in a re-reloc
state. This for example can prevent the assigning of clock parents
when running in SPL code. Go ahead and remove this limitation.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 drivers/clk/clk-uclass.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 2b15978e14..04b369aa5a 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
 {
int ret;
 
-   /* If this is running pre-reloc state, don't take any action. */
-   if (!(gd->flags & GD_FLG_RELOC))
-   return 0;
-
debug("%s(%s)\n", __func__, dev_read_name(dev));
 
ret = clk_set_default_parents(dev);
-- 
2.18.0

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


[U-Boot] [PATCH 23/25] spl: Allow remoteproc drivers to be used within SPL

2018-08-21 Thread Lokesh Vutla
Add an option for building remoteproc drivers within SPL.

Signed-off-by: Lokesh Vutla 
---
 common/spl/Kconfig  | 6 ++
 drivers/Makefile| 2 +-
 drivers/remoteproc/Makefile | 2 +-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 67275eb39d..ba6be4dc40 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -642,6 +642,12 @@ config SPL_RAM_DEVICE
  be already in memory when SPL takes over, e.g. loaded by the boot
  ROM.
 
+config SPL_REMOTEPROC
+   bool "Support REMOTEPROCS"
+   help
+ Enable support for REMOTEPROCs in SPL. This permits to load
+ a remote processor firmware in SPL.
+
 config SPL_RTC_SUPPORT
bool "Support RTC drivers"
help
diff --git a/drivers/Makefile b/drivers/Makefile
index c0124765db..23ea609b09 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_$(SPL_TPL_)SPI_FLASH_SUPPORT) += mtd/spi/
 obj-$(CONFIG_$(SPL_TPL_)SPI_SUPPORT) += spi/
 obj-$(CONFIG_$(SPL_TPL_)TIMER) += timer/
 obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox/
+obj-$(CONFIG_$(SPL_)REMOTEPROC) += remoteproc/
 
 ifndef CONFIG_TPL_BUILD
 ifdef CONFIG_SPL_BUILD
@@ -102,7 +103,6 @@ obj-y += input/
 # SOC specific infrastructure drivers.
 obj-y += smem/
 obj-y += soc/
-obj-$(CONFIG_REMOTEPROC) += remoteproc/
 obj-y += thermal/
 obj-y += axi/
 
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 87ef9e61a7..77eb708523 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -4,7 +4,7 @@
 # Texas Instruments Incorporated - http://www.ti.com/
 #
 
-obj-$(CONFIG_REMOTEPROC) += rproc-uclass.o
+obj-$(CONFIG_$(SPL_)REMOTEPROC) += rproc-uclass.o
 
 # Remote proc drivers - Please keep this list alphabetically sorted.
 obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
-- 
2.18.0

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


[U-Boot] [PATCH 14/25] power domain: Add support for multiple powerdomains per device

2018-08-21 Thread Lokesh Vutla
There are cases where there are more than one power domain
attached to the device inorder to get the device functional.
So add support for enabling power domain based on the index.

Signed-off-by: Lokesh Vutla 
---
 drivers/power/domain/power-domain-uclass.c | 11 +--
 include/power-domain.h | 19 +++
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/power/domain/power-domain-uclass.c 
b/drivers/power/domain/power-domain-uclass.c
index 9e9ec4f419..2ea0ff24c7 100644
--- a/drivers/power/domain/power-domain-uclass.c
+++ b/drivers/power/domain/power-domain-uclass.c
@@ -28,7 +28,8 @@ static int power_domain_of_xlate_default(struct power_domain 
*power_domain,
return 0;
 }
 
-int power_domain_get(struct udevice *dev, struct power_domain *power_domain)
+int power_domain_get_by_index(struct udevice *dev,
+ struct power_domain *power_domain, int index)
 {
struct ofnode_phandle_args args;
int ret;
@@ -38,7 +39,8 @@ int power_domain_get(struct udevice *dev, struct power_domain 
*power_domain)
debug("%s(dev=%p, power_domain=%p)\n", __func__, dev, power_domain);
 
ret = dev_read_phandle_with_args(dev, "power-domains",
-"#power-domain-cells", 0, 0, &args);
+"#power-domain-cells", 0, index,
+&args);
if (ret) {
debug("%s: dev_read_phandle_with_args failed: %d\n",
  __func__, ret);
@@ -73,6 +75,11 @@ int power_domain_get(struct udevice *dev, struct 
power_domain *power_domain)
return 0;
 }
 
+int power_domain_get(struct udevice *dev, struct power_domain *power_domain)
+{
+   return power_domain_get_by_index(dev, power_domain, 0);
+}
+
 int power_domain_free(struct power_domain *power_domain)
 {
struct power_domain_ops *ops = power_domain_dev_ops(power_domain->dev);
diff --git a/include/power-domain.h b/include/power-domain.h
index a558fbbdb2..0c6d77e813 100644
--- a/include/power-domain.h
+++ b/include/power-domain.h
@@ -97,6 +97,25 @@ int power_domain_get(struct udevice *dev, struct 
power_domain *power_domain)
 }
 #endif
 
+/**
+ * power_domain_get_by_index - Get the indexed power domain for a device.
+ *
+ * @dev:   The client device.
+ * @power_domain:  A pointer to a power domain struct to initialize.
+ * @index: Power domain index to be powered on.
+ *
+ * @return 0 if OK, or a negative error code.
+ */
+#if CONFIG_IS_ENABLED(POWER_DOMAIN)
+int power_domain_get_by_index(struct udevice *dev,
+ struct power_domain *power_domain, int index);
+#else
+int power_domain_get_by_index(struct udevice *dev,
+ struct power_domain *power_domain, int index)
+   return -ENOSYS;
+}
+#endif
+
 /**
  * power_domain_free - Free a previously requested power domain.
  *
-- 
2.18.0

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


[U-Boot] [PATCH 24/25] mmc: k3_arasan: Add sdhci driver support for K3 family SoCs

2018-08-21 Thread Lokesh Vutla
AM654 has an arasan sdhci controller and a mmc phy attached to it.
Add basic support for K3 specific arasan sdhci controller.

Cc: Jaehoon Chung 
Signed-off-by: Lokesh Vutla 
---
 drivers/mmc/Kconfig  |   9 +++
 drivers/mmc/Makefile |   1 +
 drivers/mmc/k3_arsan_sdhci.c | 109 +++
 3 files changed, 119 insertions(+)
 create mode 100644 drivers/mmc/k3_arsan_sdhci.c

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 377b1c4b3b..27dfccb9b2 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -402,6 +402,15 @@ config MMC_SDHCI_CADENCE
 
  If unsure, say N.
 
+config MMC_SDHCI_K3_ARASAN
+   bool "Arasan SDHCI controller for TI's K3 based SoCs"
+   depends on ARCH_K3
+   depends on MMC_SDHCI
+   depends on DM_MMC && OF_CONTROL && BLK
+   help
+ Support for Arasan SDHCI host controller on Texas Instruments'
+ K3 family based SoC platforms
+
 config MMC_SDHCI_KONA
bool "SDHCI support on Broadcom KONA platform"
depends on MMC_SDHCI
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index f6191862d6..23c5b0daef 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_MMC_SDHCI_ATMEL) += atmel_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_BCM2835)+= bcm2835_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_BCMSTB) += bcmstb_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_CADENCE)+= sdhci-cadence.o
+obj-$(CONFIG_MMC_SDHCI_K3_ARASAN)  += k3_arsan_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_KONA)   += kona_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_MSM)+= msm_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_MV) += mv_sdhci.o
diff --git a/drivers/mmc/k3_arsan_sdhci.c b/drivers/mmc/k3_arsan_sdhci.c
new file mode 100644
index 00..1da25dc55d
--- /dev/null
+++ b/drivers/mmc/k3_arsan_sdhci.c
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier:GPL-2.0+
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Texas Instruments' K3 SD Host Controller Interface
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define K3_ARASAN_SDHCI_MIN_FREQ   0
+
+struct k3_arasan_sdhci_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+   unsigned int f_max;
+};
+
+static int k3_arasan_sdhci_probe(struct udevice *dev)
+{
+   struct k3_arasan_sdhci_plat *plat = dev_get_platdata(dev);
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct sdhci_host *host = dev_get_priv(dev);
+   struct power_domain sdhci_pwrdmn;
+   struct clk clk;
+   unsigned long clock;
+   int ret;
+
+   ret = power_domain_get_by_index(dev, &sdhci_pwrdmn, 0);
+   if (ret) {
+   dev_err(dev, "failed to get power domain\n");
+   return ret;
+   }
+
+   ret = power_domain_on(&sdhci_pwrdmn);
+   if (ret) {
+   dev_err(dev, "Power domain on failed\n");
+   return ret;
+   }
+
+   ret = clk_get_by_index(dev, 0, &clk);
+   if (ret) {
+   dev_err(dev, "failed to get clock\n");
+   return ret;
+   }
+
+   clock = clk_get_rate(&clk);
+   if (IS_ERR_VALUE(clock)) {
+   dev_err(dev, "failed to get rate\n");
+   return clock;
+   }
+
+   host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD |
+  SDHCI_QUIRK_BROKEN_R1B;
+
+   host->max_clk = clock;
+
+   ret = sdhci_setup_cfg(&plat->cfg, host, plat->f_max,
+ K3_ARASAN_SDHCI_MIN_FREQ);
+   host->mmc = &plat->mmc;
+   if (ret)
+   return ret;
+   host->mmc->priv = host;
+   host->mmc->dev = dev;
+   upriv->mmc = host->mmc;
+
+   return sdhci_probe(dev);
+}
+
+static int k3_arasan_sdhci_ofdata_to_platdata(struct udevice *dev)
+{
+   struct k3_arasan_sdhci_plat *plat = dev_get_platdata(dev);
+   struct sdhci_host *host = dev_get_priv(dev);
+
+   host->name = dev->name;
+   host->ioaddr = (void *)dev_read_addr(dev);
+   host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
+   plat->f_max = dev_read_u32_default(dev, "max-frequency", 0);
+
+   return 0;
+}
+
+static int k3_arasan_sdhci_bind(struct udevice *dev)
+{
+   struct k3_arasan_sdhci_plat *plat = dev_get_platdata(dev);
+
+   return sdhci_bind(dev, &plat->mmc, &plat->cfg);
+}
+
+static const struct udevice_id k3_arasan_sdhci_ids[] = {
+   { .compatible = "arasan,sdhci-5.1" },
+   { }
+};
+
+U_BOOT_DRIVER(k3_arasan_sdhci_drv) = {
+   .name   = "k3_arasan_sdhci",
+   .id = UCLASS_MMC,
+   .of_match   = k3_arasan_sdhci_ids,
+   .ofdata_to_platdata = k3_arasan_sdhci_ofdata_to_platdata,
+   .ops= &sdhci_ops,
+   .bind   = k3_arasan_sdhci_bind,
+   .probe  = k3_arasan_sdhci_probe,
+   .priv_auto_alloc_size = sizeof(struct sdhci_host),
+   .platdata

[U-Boot] [PATCH 3/6] include: am654_evm: Establish initial environment for SD card boot

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Create a basic U-Boot environment that allows the automatic loading
of a Linux Kernel located at /boot/Image and an associated device tree
blob located at /boot/k3-am654-base-board.dtb from the secondary
partition of an ext4-formatted SD card on the AM654x EVM. Furthermore
the boot.scr and uEnv.txt detection and loading schemes are supported
in a manner already known from other TI platforms.

Note that this is intended to be a starting point to enable initial
board use and will most certainly get extended and refactored as
different boot media become available.

Signed-off-by: Andreas Dannenberg 
---
 include/configs/am65x_evm.h | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index ee8a984cfc..06b7624cd1 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 
 #define CONFIG_ENV_SIZE(128 << 10)
 
@@ -30,6 +31,40 @@
 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\
CONFIG_NON_SECURE_MSRAM_SIZE - 4)
 
+/* U-Boot general configuration */
+#define EXTRA_ENV_AM65X_BOARD_SETTINGS \
+   "findfdt="  \
+   "if test $board_name = am65x; then "\
+   "setenv name_fdt k3-am654-base-board.dtb; " \
+   "else if test $name_fdt = undefined; then " \
+   "echo WARNING: Could not determine device tree to use;"\
+   "fi; fi; "  \
+   "setenv fdtfile ${name_fdt}\0"  \
+   "loadaddr=0x8008\0" \
+   "fdtaddr=0x8200\0"  \
+   "name_kern=Image\0" \
+   "console=ttyS2,115200n8\0"  \
+   "args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280\0" \
+   "run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}\0"
+
+/* U-Boot MMC-specific configuration */
+#define EXTRA_ENV_AM65X_BOARD_SETTINGS_MMC \
+   "boot=mmc\0"\
+   "mmcdev=1\0"\
+   "bootpart=1:2\0"\
+   "bootdir=/boot\0"   \
+   "rd_spec=-\0"   \
+   "init_mmc=run args_all args_mmc\0"  \
+   "get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}\0" \
+   "get_kern_mmc=load mmc ${bootpart} ${loadaddr} "\
+   "${bootdir}/${name_kern}\0"
+
+/* Incorporate settings into the U-Boot environment */
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   DEFAULT_MMC_TI_ARGS \
+   EXTRA_ENV_AM65X_BOARD_SETTINGS  \
+   EXTRA_ENV_AM65X_BOARD_SETTINGS_MMC
+
 /* Now for the remaining common defines */
 #include 
 
-- 
2.18.0

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


[U-Boot] [PATCH 4/6] arm64: dts: k3: Add Support for AM654 SoC

2018-08-21 Thread Lokesh Vutla
Add initial DT support for AM654 EVM that runs on A53.

Signed-off-by: Lokesh Vutla 
---
- Fetched from Linux next that are in queue for 4.19-rc1

 arch/arm/dts/Makefile|   2 +
 arch/arm/dts/k3-am65-main.dtsi   |  31 
 arch/arm/dts/k3-am65.dtsi|  87 
 arch/arm/dts/k3-am654-base-board.dts |  36 +
 arch/arm/dts/k3-am654.dtsi   | 115 +++
 board/ti/am65x/evm.c |  12 +++
 6 files changed, 283 insertions(+)
 create mode 100644 arch/arm/dts/k3-am65-main.dtsi
 create mode 100644 arch/arm/dts/k3-am65.dtsi
 create mode 100644 arch/arm/dts/k3-am654-base-board.dts
 create mode 100644 arch/arm/dts/k3-am654.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ebfa227262..150e1d4090 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -549,6 +549,8 @@ dtb-$(CONFIG_TARGET_STM32MP1) += \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb
 
+dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
new file mode 100644
index 00..2409344df4
--- /dev/null
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+&cbass_main {
+   gic500: interrupt-controller@180 {
+   compatible = "arm,gic-v3";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x0180 0x1>, /* GICD */
+ <0x0188 0x9>; /* GICR */
+   /*
+* vcpumntirq:
+* virtual CPU interface maintenance interrupt
+*/
+   interrupts = ;
+
+   gic_its: gic-its@1820 {
+   compatible = "arm,gic-v3-its";
+   reg = <0x0182 0x1>;
+   msi-controller;
+   #msi-cells = <1>;
+   };
+   };
+};
diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
new file mode 100644
index 00..cede1fa098
--- /dev/null
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Texas Instruments K3 AM654 SoC";
+   compatible = "ti,am654";
+   interrupt-parent = <&gic500>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   chosen { };
+
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+
+   psci: psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+   };
+
+   a53_timer0: timer-cl0-cpu0 {
+   compatible = "arm,armv8-timer";
+   interrupts = , /* cntpsirq */
+, /* cntpnsirq */
+, /* cntvirq */
+; /* cnthpirq */
+   };
+
+   pmu: pmu {
+   compatible = "arm,armv8-pmuv3";
+   /* Recommendation from GIC500 TRM Table A.3 */
+   interrupts = ;
+   };
+
+   cbass_main: interconnect@10 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0010 0x00 0x0010 0x0002>, /* ctrl mmr */
+<0x0060 0x00 0x0060 0x1100>, /* GPIO */
+<0x0090 0x00 0x0090 0x00012000>, /* serdes */
+<0x0100 0x00 0x0100 0x0af02400>, /* Most 
peripherals */
+<0x3080 0x00 0x3080 0x0bc0>, /* MAIN NAVSS 
*/
+/* MCUSS Range */
+<0x2838 0x00 0x2838 0x0388>,
+<0x4020 0x00 0x4020 0x00900100>,
+<0x4204 0x00 0x4204 0x03ac2400>,
+<0x4510 0x00 0x4510 0x00c24000>,
+<0x4600 0x00 0x4600 0x0020>,
+<0x4700 0x00 0x4700 0x00068400>;
+
+   cbass_mcu: interconnect@2838 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x2838 0x2838 0x0388>, /* MCU 
NAVSS*/
+   

[U-Boot] [PATCH 02/25] firmware: ti_sci: Add support for board configuration

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

TI-SCI message protocol provides support for board configuration
to assign resources and other board related operations.
Introduce the board configuration capability support to the driver protocol
as part of this change.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 drivers/firmware/ti_sci.c  | 137 +
 drivers/firmware/ti_sci.h  |  21 
 include/linux/soc/ti/ti_sci_protocol.h |  38 +++
 3 files changed, 196 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index c1169987ad..ce7483307e 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -275,6 +275,142 @@ static inline bool ti_sci_is_response_ack(void *r)
return hdr->flags & TI_SCI_FLAG_RESP_GENERIC_ACK ? true : false;
 }
 
+/**
+ * cmd_set_board_config_using_msg() - Common command to send board 
configuration
+ *message
+ * @handle:pointer to TI SCI handle
+ * @msg_type:  One of the TISCI message types to set board configuration
+ * @addr:  Address where the board config structure is located
+ * @size:  Size of the board config structure
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int cmd_set_board_config_using_msg(const struct ti_sci_handle *handle,
+ u16 msg_type, u64 addr, u32 size)
+{
+   struct ti_sci_msg_board_config req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, msg_type,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req.boardcfgp_high = (addr >> 32) & 0x;
+   req.boardcfgp_low = addr & 0x;
+   req.boardcfg_size = size;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   return -ENODEV;
+
+   return ret;
+}
+
+/**
+ * ti_sci_cmd_set_board_config() - Command to send board configuration message
+ * @handle:pointer to TI SCI handle
+ * @addr:  Address where the board config structure is located
+ * @size:  Size of the board config structure
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_set_board_config(const struct ti_sci_handle *handle,
+  u64 addr, u32 size)
+{
+   return cmd_set_board_config_using_msg(handle,
+ TI_SCI_MSG_BOARD_CONFIG,
+ addr, size);
+}
+
+/**
+ * ti_sci_cmd_set_board_config_rm() - Command to send board resource
+ *   management configuration
+ * @handle:pointer to TI SCI handle
+ * @addr:  Address where the board RM config structure is located
+ * @size:  Size of the RM config structure
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static
+int ti_sci_cmd_set_board_config_rm(const struct ti_sci_handle *handle,
+  u64 addr, u32 size)
+{
+   return cmd_set_board_config_using_msg(handle,
+ TI_SCI_MSG_BOARD_CONFIG_RM,
+ addr, size);
+}
+
+/**
+ * ti_sci_cmd_set_board_config_security() - Command to send board security
+ * configuration message
+ * @handle:pointer to TI SCI handle
+ * @addr:  Address where the board security config structure is located
+ * @size:  Size of the security config structure
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static
+int ti_sci_cmd_set_board_config_security(const struct ti_sci_handle *handle,
+u64 addr, u32 size)
+{
+   return cmd_set_board_config_using_msg(handle,
+ TI_SCI_MSG_BOARD_CONFIG_SECURITY,
+ addr, size);
+}
+
+/**
+ * ti_sci_cmd_set_board_config_pm() - Command to send board power and clock
+ *   configuration message
+ * @handle:pointer to TI SCI handle
+ * @addr:  Address where the board PM config structure is loca

[U-Boot] [PATCH 09/25] reset: Extend reset control with an optional data field

2018-08-21 Thread Lokesh Vutla
From: Andreas Dannenberg 

Some systems require more than a single ID to identify and configure any
reset provider. For those scenarios add an optional data field to the
reset control structure.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 include/reset.h | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/reset.h b/include/reset.h
index 34ebb096dd..bc495a90c2 100644
--- a/include/reset.h
+++ b/include/reset.h
@@ -40,10 +40,12 @@ struct udevice;
  *
  * @dev: The device which implements the reset signal.
  * @id: The reset signal ID within the provider.
+ * @data: An optional data field for scenarios where a single integer ID is not
+ *   sufficient. If used, it can be populated through an .of_xlate op and
+ *   processed during the various reset ops.
  *
- * Currently, the reset API assumes that a single integer ID is enough to
- * identify and configure any reset signal for any reset provider. If this
- * assumption becomes invalid in the future, the struct could be expanded to
+ * Should additional information to identify and configure any reset signal
+ * for any provider be required in the future, the struct could be expanded to
  * either (a) add more fields to allow reset providers to store additional
  * information, or (b) replace the id field with an opaque pointer, which the
  * provider would dynamically allocated during its .of_xlate op, and process
@@ -53,10 +55,10 @@ struct udevice;
 struct reset_ctl {
struct udevice *dev;
/*
-* Written by of_xlate. We assume a single id is enough for now. In the
-* future, we might add more fields here.
+* Written by of_xlate. In the future, we might add more fields here.
 */
unsigned long id;
+   unsigned long data;
 };
 
 /**
-- 
2.18.0

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


[U-Boot] [PATCH 01/25] firmware: Add basic support for TI System Control Interface (TI SCI) protocol

2018-08-21 Thread Lokesh Vutla
Texas Instrument's System Control Interface (TI SCI) message protocol is
used in Texas Instrument's System on Chip (SoC) such as those in the K3
family AM654 SoC to communicate between various compute processors with
a central system controller entity.

The TI SCI message protocol provides support for management of various
hardware entities within the SoC. Add support driver to allow
communication with system controller entity within the SoC using the
mailbox client.

This is mostly derived from the TI SCI driver in Linux located at
drivers/firmware/ti_sci.c.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
Signed-off-by: Andreas Dannenberg 
---
 doc/device-tree-bindings/firmware/ti,sci.txt |  76 
 drivers/firmware/Kconfig |  13 +
 drivers/firmware/Makefile|   1 +
 drivers/firmware/ti_sci.c| 448 +++
 drivers/firmware/ti_sci.h|  80 
 include/linux/soc/ti/ti_sci_protocol.h   |  69 +++
 6 files changed, 687 insertions(+)
 create mode 100644 doc/device-tree-bindings/firmware/ti,sci.txt
 create mode 100644 drivers/firmware/ti_sci.c
 create mode 100644 drivers/firmware/ti_sci.h
 create mode 100644 include/linux/soc/ti/ti_sci_protocol.h

diff --git a/doc/device-tree-bindings/firmware/ti,sci.txt 
b/doc/device-tree-bindings/firmware/ti,sci.txt
new file mode 100644
index 00..4d40d0dcb6
--- /dev/null
+++ b/doc/device-tree-bindings/firmware/ti,sci.txt
@@ -0,0 +1,76 @@
+Texas Instruments System Control Interface (TI-SCI) Message Protocol
+
+
+Texas Instrument's processors including those belonging to Keystone generation
+of processors have separate hardware entity which is now responsible for the
+management of the System on Chip (SoC) system. These include various system
+level functions as well.
+
+An example of such an SoC is K2G, which contains the system control hardware
+block called Power Management Micro Controller (PMMC). This hardware block is
+initialized early into boot process and provides services to Operating Systems
+on multiple processors including ones running Linux.
+
+See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
+
+TI-SCI controller Device Node:
+=
+
+The TI-SCI node describes the Texas Instrument's System Controller entity node.
+This parent node may optionally have additional children nodes which describe
+specific functionality such as clocks, power domain, reset or additional
+functionality as may be required for the SoC. This hierarchy also describes the
+relationship between the TI-SCI parent node to the child node.
+
+Required properties:
+---
+- compatible: should be "ti,k2g-sci"
+- mbox-names:
+   "rx" - Mailbox corresponding to receive path
+   "tx" - Mailbox corresponding to transmit path
+
+- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
+ property should contain a phandle to the mailbox controller device
+ node and an args specifier that will be the phandle to the intended
+ sub-mailbox child node to be used for communication.
+
+Optional Properties:
+---
+- reg-names:
+   debug_messages - Map the Debug message region
+- reg:  register space corresponding to the debug_messages
+- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
+- ti,secure-host: If the host is defined as secure.
+
+Example:
+-
+   dmsc: dmsc {
+   compatible = "ti,k2g-sci";
+   ti,host-id = <12>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   }
+
+
+TI-SCI Client Device Node:
+=
+
+Client nodes are maintained as children of the relevant TI-SCI device node.
+
+Example:
+-
+   dmsc: dmsc {
+   compatible = "ti,k2g-sci";
+   ...
+
+   my_clk_node: clk_node {
+   ...
+   ...
+   };
+
+   my_pd_node: pd_node {
+   ...
+   ...
+   };
+   };
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 4c32426e0e..cb73b70f5b 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -4,3 +4,16 @@ config FIRMWARE
 config ARM_PSCI_FW
bool
select FIRMWARE
+
+config TI_SCI_PROTOCOL
+   tristate "TI System Control Interface (TISCI) Message Protocol"
+   depends on K3_SEC_PROXY
+   select FIRMWARE
+   help
+ TI System Control Interface (TISCI) Message Protocol is used to manage
+ compute systems such as ARM, DSP etc with the system controller in
+ complex System on Chip (SoC) such as those found on certain K3
+ generation SoC from TI.
+
+ This protocol library is used by client 

[U-Boot] [PATCH 19/25] spl: Allow mailbox drivers to be used within SPL

2018-08-21 Thread Lokesh Vutla
Add an option for building mailbox drivers within SPL.

Signed-off-by: Lokesh Vutla 
---
 common/spl/Kconfig   | 8 
 drivers/Makefile | 1 +
 drivers/mailbox/Makefile | 2 +-
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 11c2c0133f..67275eb39d 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -430,6 +430,14 @@ config SPL_LIBGENERIC_SUPPORT
  boards. Enable this option to build the code in lib/ as part of an
  SPL build.
 
+config SPL_DM_MAILBOX
+   bool "Support Mailbox"
+   help
+ Enable support for Mailbox within SPL. This enable the inter
+ processor communication protocols tobe used within SPL. Enable
+ this option to build the drivers in drivers/mailbox as part of
+ SPL build.
+
 config SPL_MMC_SUPPORT
bool "Support MMC"
depends on MMC
diff --git a/drivers/Makefile b/drivers/Makefile
index d296354b3c..c0124765db 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_$(SPL_TPL_)SERIAL_SUPPORT) += serial/
 obj-$(CONFIG_$(SPL_TPL_)SPI_FLASH_SUPPORT) += mtd/spi/
 obj-$(CONFIG_$(SPL_TPL_)SPI_SUPPORT) += spi/
 obj-$(CONFIG_$(SPL_TPL_)TIMER) += timer/
+obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox/
 
 ifndef CONFIG_TPL_BUILD
 ifdef CONFIG_SPL_BUILD
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4ac85d412f..243ff6f3ce 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -2,7 +2,7 @@
 #
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_DM_MAILBOX) += mailbox-uclass.o
+obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox-uclass.o
 obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox.o
 obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox-test.o
 obj-$(CONFIG_TEGRA_HSP) += tegra-hsp.o
-- 
2.18.0

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


[U-Boot] [PATCH 20/25] remoteproc: Allow for individual remoteproc initialization

2018-08-21 Thread Lokesh Vutla
Existing rproc_init() api tries to initialize all available
remoteproc devices. This will fail when there is dependency
among available remoteprocs. So introduce a separate api
that allows to initialize remoteprocs individually based
on id.

Signed-off-by: Lokesh Vutla 
---
 drivers/remoteproc/rproc-uclass.c | 19 +++
 include/remoteproc.h  |  9 +
 2 files changed, 28 insertions(+)

diff --git a/drivers/remoteproc/rproc-uclass.c 
b/drivers/remoteproc/rproc-uclass.c
index 1fc3d424b3..c8a41a6332 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -272,6 +272,25 @@ int rproc_init(void)
return ret;
 }
 
+int rproc_dev_init(int id)
+{
+   struct udevice *dev = NULL;
+   int ret;
+
+   ret = uclass_get_device_by_seq(UCLASS_REMOTEPROC, id, &dev);
+   if (ret) {
+   debug("Unknown remote processor id '%d' requested(%d)\n",
+ id, ret);
+   return ret;
+   }
+
+   ret = device_probe(dev);
+   if (ret)
+   debug("%s: Failed to initialize - %d\n", dev->name, ret);
+
+   return ret;
+}
+
 int rproc_load(int id, ulong addr, ulong size)
 {
struct udevice *dev = NULL;
diff --git a/include/remoteproc.h b/include/remoteproc.h
index c3c3f46a1a..a59dba8481 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -85,6 +85,14 @@ struct dm_rproc_ops {
  */
 int rproc_init(void);
 
+/**
+ * rproc_dev_init() - Initialize a remote proc device based on id
+ * @id:id of the remote processor
+ *
+ * Return: 0 if all ok, else appropriate error value.
+ */
+int rproc_dev_init(int id);
+
 /**
  * rproc_is_initialized() - check to see if remoteproc devices are initialized
  *
@@ -150,6 +158,7 @@ int rproc_ping(int id);
 int rproc_is_running(int id);
 #else
 static inline int rproc_init(void) { return -ENOSYS; }
+static inline int rproc_dev_init(int id) { return -ENOSYS; }
 static inline bool rproc_is_initialized(void) { return false; }
 static inline int rproc_load(int id, ulong addr, ulong size) { return -ENOSYS; 
}
 static inline int rproc_start(int id) { return -ENOSYS; }
-- 
2.18.0

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


[U-Boot] [PATCH 5/6] arm64: dts: k3: Add u-boot specific nodes

2018-08-21 Thread Lokesh Vutla
Add the minimum dt nodes required to boot. These nodes
will get deleted as kernel gets these nodes added in the
main dts files.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 203 +++
 include/dt-bindings/pinctrl/k3-am65.h|  49 +
 2 files changed, 252 insertions(+)
 create mode 100644 arch/arm/dts/k3-am654-base-board-u-boot.dtsi
 create mode 100644 include/dt-bindings/pinctrl/k3-am65.h

diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
new file mode 100644
index 00..d4ecb3be10
--- /dev/null
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include 
+
+/ {
+   chosen {
+   stdout-path = "serial2:115200n8";
+   };
+
+   aliases {
+   serial2 = &main_uart0;
+   };
+};
+
+&cbass_main{
+   u-boot,dm-spl;
+   secure_proxy: secure_proxy@32c0 {
+   compatible = "ti,am654-secure-proxy";
+   #mbox-cells = <1>;
+   reg-names = "target_data", "rt", "scfg";
+   reg = <0x32c0 0x10>,
+ <0x3240 0x10>,
+ <0x3280 0x10>;
+   interrupt-names = "rx_011";
+   interrupts = ;
+   };
+
+   dmsc: dmsc {
+   compatible = "ti,k2g-sci";
+   ti,host-id = <12>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   /*
+* In case of rare platforms that does not use am6 as
+* system master, use /delete-property/
+*/
+   ti,system-reboot-controller;
+   mbox-names = "rx", "tx";
+
+   mboxes= <&secure_proxy 11>,
+   <&secure_proxy 13>;
+
+   k3_pds: power-controller {
+   compatible = "ti,sci-pm-domain";
+   #power-domain-cells = <1>;
+   };
+
+   k3_clks: clocks {
+   compatible = "ti,k2g-sci-clk";
+   #clock-cells = <2>;
+   };
+
+   k3_reset: reset-controller {
+   compatible = "ti,sci-reset";
+   #reset-cells = <2>;
+   };
+
+   k3_sysreset: sysreset-controller {
+   compatible = "ti,sci-sysreset";
+   };
+   };
+
+   main_pmx0: pinmux@11c000 {
+   compatible = "pinctrl-single";
+   reg = <0x11c000 0x2e4>;
+   #pinctrl-cells = <1>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <0x>;
+   };
+
+   main_pmx1: pinmux@11c2e8 {
+   compatible = "pinctrl-single";
+   reg = <0x11c2e8 0x24>;
+   #pinctrl-cells = <1>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <0x>;
+   };
+
+   main_uart0: serial@280 {
+   compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+   reg = <0x0280 0x100>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   interrupts = ;
+   clock-frequency = <4800>;
+   current-speed = <115200>;
+   status = "disabled";
+   u-boot,dm-pre-reloc;
+   };
+
+   sdhci0: sdhci@04F8 {
+   compatible = "arasan,sdhci-5.1";
+   reg = <0x4F8 0x1000>,
+ <0x4F9 0x400>;
+   clocks = <&k3_clks 47 1>;
+   power-domains = <&k3_pds 47>;
+   max-frequency = <2500>;
+   };
+
+   sdhci1: sdhci@04FA {
+   compatible = "arasan,sdhci-5.1";
+   reg = <0x4FA 0x1000>,
+ <0x4FB 0x400>;
+   clocks = <&k3_clks 48 1>;
+   power-domains = <&k3_pds 48>;
+   max-frequency = <2500>;
+   };
+
+};
+
+&secure_proxy {
+   u-boot,dm-spl;
+};
+
+&dmsc {
+   u-boot,dm-spl;
+};
+
+&k3_pds {
+   u-boot,dm-spl;
+};
+
+&k3_clks {
+   u-boot,dm-spl;
+};
+
+&k3_reset {
+   u-boot,dm-spl;
+};
+
+&main_pmx0 {
+   u-boot,dm-spl;
+   main_uart0_pins_default: main_uart0_pins_default {
+   pinctrl-single,pins = <
+   AM65X_IOPAD(0x01e4, PIN_INPUT | MUX_MODE0)  /* 
(AF11) UART0_RXD */
+   AM65X_IOPAD(0x01e8, PIN_OUTPUT | MUX_MODE0) /* 
(AE11) UART0_TXD */
+   AM65X_IOPAD(0x01ec, PIN_INPUT | MUX_MODE0)  /* 
(AG11) UART0_CTSn */
+   AM65X_IOPAD(0x01f0, PIN_OUTPUT | MUX_MODE0) /* 
(AD11) UART0_RTSn */
+   >;
+   };
+
+  

[U-Boot] [PATCH 6/6] configs: am65x_evm_a53: Add initial support

2018-08-21 Thread Lokesh Vutla
Add initial defconfig support for AM65x that runs on A53.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
---
 board/ti/am65x/MAINTAINERS  |  1 +
 configs/am65x_evm_a53_defconfig | 71 +
 2 files changed, 72 insertions(+)
 create mode 100644 configs/am65x_evm_a53_defconfig

diff --git a/board/ti/am65x/MAINTAINERS b/board/ti/am65x/MAINTAINERS
index c5921b4a28..ca1ce58f72 100644
--- a/board/ti/am65x/MAINTAINERS
+++ b/board/ti/am65x/MAINTAINERS
@@ -3,3 +3,4 @@ M:  Lokesh Vutla 
 S: Maintained
 F: board/ti/am65x/
 F: include/configs/am65x_evm.h
+F: configs/am65x_evm_a53_defconfig
diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
new file mode 100644
index 00..5b08409249
--- /dev/null
+++ b/configs/am65x_evm_a53_defconfig
@@ -0,0 +1,71 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SOC_K3_AM6=y
+CONFIG_TARGET_AM654_A53_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FAT_SUPPORT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am654-base-board"
+CONFIG_DISTRO_DEFAULTS=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_K3_ARASAN=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_K3=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
-- 
2.18.0

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


[U-Boot] [PATCH 1/6] board: ti: am654: a53: Add initial support for am654

2018-08-21 Thread Lokesh Vutla
Add initial support for AM654 based EVM running on A53. Enable
4GB of DDR available on the EVM so that kernel DTB file
can be updated accordingly.

Signed-off-by: Lokesh Vutla 
[Andreas: Added 4GB ddr support]
Signed-off-by: Andreas Dannenberg 
---
 arch/arm/mach-k3/Kconfig|  1 +
 board/ti/am65x/Kconfig  | 30 
 board/ti/am65x/MAINTAINERS  |  5 
 board/ti/am65x/Makefile |  8 ++
 board/ti/am65x/evm.c| 56 +
 include/configs/am65x_evm.h | 36 
 6 files changed, 136 insertions(+)
 create mode 100644 board/ti/am65x/Kconfig
 create mode 100644 board/ti/am65x/MAINTAINERS
 create mode 100644 board/ti/am65x/Makefile
 create mode 100644 board/ti/am65x/evm.c
 create mode 100644 include/configs/am65x_evm.h

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 117e5b4e4a..df3ba32df6 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -47,4 +47,5 @@ config BOOT_PARAM_TABLE_INDEX
  Address at which ROM stores the value which determines if SPL
  is booted up by primary boot media or secondary boot media.
 
+source "board/ti/am65x/Kconfig"
 endif
diff --git a/board/ti/am65x/Kconfig b/board/ti/am65x/Kconfig
new file mode 100644
index 00..fb616e8fd5
--- /dev/null
+++ b/board/ti/am65x/Kconfig
@@ -0,0 +1,30 @@
+#
+# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+#  Lokesh Vutla 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+choice
+   prompt "K3 AM65 based boards"
+   optional
+
+config TARGET_AM654_A53_EVM
+   bool "TI K3 based AM654 EVM running on A53"
+   select ARM64
+   select SOC_K3_AM6
+
+endchoice
+
+if TARGET_AM654_A53_EVM
+
+config SYS_BOARD
+   default "am65x"
+
+config SYS_VENDOR
+   default "ti"
+
+config SYS_CONFIG_NAME
+   default "am65x_evm"
+
+endif
diff --git a/board/ti/am65x/MAINTAINERS b/board/ti/am65x/MAINTAINERS
new file mode 100644
index 00..c5921b4a28
--- /dev/null
+++ b/board/ti/am65x/MAINTAINERS
@@ -0,0 +1,5 @@
+AM65x BOARD
+M: Lokesh Vutla 
+S: Maintained
+F: board/ti/am65x/
+F: include/configs/am65x_evm.h
diff --git a/board/ti/am65x/Makefile b/board/ti/am65x/Makefile
new file mode 100644
index 00..94dddfcc4a
--- /dev/null
+++ b/board/ti/am65x/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+#  Lokesh Vutla 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := evm.o
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
new file mode 100644
index 00..db2c90e948
--- /dev/null
+++ b/board/ti/am65x/evm.c
@@ -0,0 +1,56 @@
+/*
+ * Board specific initialization for AM654 EVM
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+#ifdef CONFIG_PHYS_64BIT
+   gd->ram_size = 0x1;
+#else
+   gd->ram_size = 0x8000;
+#endif
+
+   return 0;
+}
+
+ulong board_get_usable_ram_top(ulong total_size)
+{
+#ifdef CONFIG_PHYS_64BIT
+   /* Limit RAM used by U-Boot to the DDR low region */
+   if (gd->ram_top > 0x1)
+   return 0x1;
+#endif
+
+   return gd->ram_top;
+}
+
+int dram_init_banksize(void)
+{
+   /* Bank 0 declares the memory available in the DDR low region */
+   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].size = 0x8000;
+
+#ifdef CONFIG_PHYS_64BIT
+   /* Bank 1 declares the memory available in the DDR high region */
+   gd->bd->bi_dram[1].start = CONFIG_SYS_SDRAM_BASE1;
+   gd->bd->bi_dram[1].size = 0x8000;
+#endif
+
+   return 0;
+}
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
new file mode 100644
index 00..ee8a984cfc
--- /dev/null
+++ b/include/configs/am65x_evm.h
@@ -0,0 +1,36 @@
+/*
+ * Configuration header file for K3 AM654 EVM
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __CONFIG_AM654_EVM_H
+#define __CONFIG_AM654_EVM_H
+
+#include 
+#include 
+
+#define CONFIG_ENV_SIZE(128 << 10)
+
+/* DDR Configuration */
+#define CONFIG_NR_DRAM_BANKS   2
+#define CONFIG_SYS_SDRAM_BASE1 0x88000
+
+/* SPL Loader Configuration */
+#ifdef CONFIG_TARGET_AM654_A53_EVM
+#define CONFIG_SPL_TEXT_BASE   0x8008
+#endif
+
+#define CONFIG_SKIP_LOWLEVEL_INIT
+
+#define CONFIG_SPL_MAX_SIZECONFIG_MAX_DOWNLODABLE_IMAGE_SIZE
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\
+   CONFIG_NON_SECURE_MSRAM_SIZE - 4)
+
+/* Now for the remaining common define

Re: [U-Boot] [PATCH v2 00/18] spi: mpc8xxx: DM conversion

2018-08-21 Thread Christophe LEROY

Hi Mario,

Le 10/08/2018 à 09:57, Mario Six a écrit :

Hi Christophe,

On Fri, Aug 10, 2018 at 9:35 AM Christophe LEROY
 wrote:


Hello Mario,

Le 26/04/2018 à 10:36, Mario Six a écrit :

Hi Joakim,

On Thu, Apr 26, 2018 at 10:23 AM, Joakim Tjernlund
 wrote:

On Thu, 2018-04-26 at 11:35 +0530, Jagan Teki wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On Thu, Apr 26, 2018 at 11:24 AM, Mario Six  wrote:

Hi Jagan,

On Thu, Apr 26, 2018 at 7:30 AM, Jagan Teki  wrote:

On Thu, Apr 19, 2018 at 6:06 PM, Mario Six  wrote:

This is v2 of a patch series that adds support for DM to the MPC8XXX SPI
driver, cleans up the driver code, fixes a few minor problems.

Some TODOs are left over for later, such as proper SPI speed setting,
and support for SPI mode setting. These would be enhancements to the
original functionality, and can come later.

The legacy functionality is removed in this version, so old boards in
the tree might end up with broken SPI functionality.

Mario Six (18):
spi: mpc8xxx: Use short type names
spi: mpc8xxx: Fix comments
spi: mpc8xxx: Rename camel-case variables
spi: mpc8xxx: Fix space after cast
spi: mpc8xxx: Fix function names in strings
spi: mpc8xxx: Replace defines with enums
spi: mpc8xxx: Use IO accessors
spi: mpc8xxx: Simplify if
spi: mpc8xxx: Get rid of is_read
spi: mpc8xxx: Simplify logic a bit
spi: mpc8xxx: Reduce scope of loop variables
spi: mpc8xxx: Make code more readable
spi: mpc8xxx: Rename variable
spi: mpc8xxx: Document LEN setting better
spi: mpc8xxx: Re-order transfer setup
spi: mpc8xxx: Fix if check
spi: mpc8xxx: Use get_timer
spi: mpc8xxx: Convert to DM


Boards with
- configs/MPC8349EMDS_defconfig
- configs/ids8313_defconfig

are using this driver, so Kim, Heiko please convert enable DM_SPI for the same.

Use below tree for respective changes and update on top of this.
http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/next



I have a few series in the making that will enable DM on the MPC83xx platform
(I'm doing a respin on the first right now). If there is still interests in the
boards, I could push it to the MPC83xx repository (but mind that the work
required per board is quite extensive).

Also, MPC8349EMDS is de facto abandoned, and I don't have access to the
hardware, so I can't really maintain it.


It's up to you, look like this board maintained by Kim is not
available with freescale e-mail (or may be changed) if none can't
maintain, it better to drop the board.


we use custom 832x boards so please don't remove 83xx from u-boot.



I'm not planning to do that; on the contrary: I'm trying to update the platform
to fully support DM (I hope to get a fully converted board in after the next
release).

The problem is that we only use MPC8308 SoCs, so I can only vouche for the
correctness of that specific SoC. Everything else is a bit up in the air, since
I'm changing code blindly pretty much.


I have a MPC8321 board so I may test it on it if it helps.



That would be very much appreciated! Thanks.


Indeed, your driver implements SPI in CPU Mode AFAIU

In the MPC8321 Reference Manual this state that 'SPI in CPU Mode applies 
to MPC8360E and MPC8568E only'.


And as the driver doesn't implement QUICC Engine Mode, I won't use it 
for the 8xx yet. I'll port the mpc8xx driver to DM and see later if we 
can implement QE Mode in mpc8xxx and merge it with the mpc8xx once we 
have generic GPIOs on the 8xx.


Christophe




In the meantime, I was thinking about using your converted driver and
see if I can adapt it to support MPC8xx as well, instead of converting
the mpc8xx_spi driver to DM, however I've not been able to find your
patches in the master tree allthough they are flagged as accepted in
patchwork.

Are they on another branch somewhere ?


Hmm, indeed. I thought they would be in the SPI custodian repository, but
apparently they are not?

@Jagan: Were those patches forgotten somehow?


Thanks
Christophe


Best regards,
Mario


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


[U-Boot] [PATCH] ARM: dts: am33xx: fix SLEWCTRL_FAST pinctrl binding

2018-08-21 Thread Christian.Amann
From: Christian Amann 

Copy missing Kernel patch to make SLEWCTRL_SLOW available in device tree
and to correct the value of SLEWCTRL_FAST.
After this patch, the Kernel and U-boot device tree settings for
SLEWCTRL have the same effect.

Original Kernel patch message:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=424e0f039bfa8a51fb5c5178b6ece8baa4996469

"
According to AM335x TRM, Document spruh73l, Revised February 2015,
Section 9.2.2 Pad Control Registers, setting bit 6 of the pad control
registers actually sets the SLEWCTRL value to slow rather than fast as
the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that
sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for
completeness. Current users of the macro (i2c and mdio) are left
unmodified as SLEWCTRL_FAST was the macro used and actual desired state.
Tested on am335x-gp-evm with no difference in software performance seen.
Signed-off-by: Dave Gerlach 
Signed-off-by: Tony Lindgren 
"

Signed-off-by: Christian Amann 
---
 include/dt-bindings/pinctrl/am33xx.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/dt-bindings/pinctrl/am33xx.h 
b/include/dt-bindings/pinctrl/am33xx.h
index 2fbc804..226f772 100644
--- a/include/dt-bindings/pinctrl/am33xx.h
+++ b/include/dt-bindings/pinctrl/am33xx.h
@@ -13,7 +13,8 @@
 
 #define PULL_DISABLE   (1 << 3)
 #define INPUT_EN   (1 << 5)
-#define SLEWCTRL_FAST  (1 << 6)
+#define SLEWCTRL_SLOW  (1 << 6)
+#define SLEWCTRL_FAST  0
 
 /* update macro depending on INPUT_EN and PULL_ENA */
 #undef PIN_OUTPUT
-- 
2.7.4

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


[U-Boot] [PATCH] ARM: omap3_logic_defconfig: Convert to DM_SPL

2018-08-21 Thread Adam Ford
The OF_CONTROL and OF_PLATDATA are not really useful without DM.
This patch supports DM_SPL, but it requires manual references
both Serial and MMC.

Signed-off-by: Adam Ford 

diff --git a/board/logicpd/omap3som/omap3logic.c 
b/board/logicpd/omap3som/omap3logic.c
index fbad89b696..620423bbc8 100644
--- a/board/logicpd/omap3som/omap3logic.c
+++ b/board/logicpd/omap3som/omap3logic.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,36 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/* This is only needed until SPL gets OF support */
+#ifdef CONFIG_SPL_BUILD
+static const struct ns16550_platdata omap3logic_serial = {
+   .base = OMAP34XX_UART1,
+   .reg_shift = 2,
+   .clock = V_NS16550_CLK,
+   .fcr = UART_FCR_DEFVAL,
+};
+
+U_BOOT_DEVICE(omap3logic_uart) = {
+   "ns16550_serial",
+   &omap3logic_serial
+};
+
+static const struct omap_hsmmc_plat omap3_logic_mmc0_platdata = {
+   .base_addr = (struct hsmmc *)OMAP_HSMMC1_BASE,
+   .cfg.host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS | MMC_MODE_4BIT,
+   .cfg.f_min = 40,
+   .cfg.f_max = 5200,
+   .cfg.voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195,
+   .cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
+};
+
+U_BOOT_DEVICE(am335x_mmc0) = {
+   .name = "omap_hsmmc",
+   .platdata = &omap3_logic_mmc0_platdata,
+};
+
+#endif
+
 /*
  * two dimensional array of strucures containining board name and Linux
  * machine IDs; row it selected based on CPU column is slected based
diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
index 1807e280a4..c6acfab602 100644
--- a/configs/omap3_logic_defconfig
+++ b/configs/omap3_logic_defconfig
@@ -1,11 +1,11 @@
 CONFIG_ARM=y
 CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_TI_COMMON_CMD_OPTIONS=y
+# CONFIG_SPL_GPIO_SUPPORT is not set
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_OMAP3_LOGIC=y
 # CONFIG_SPL_OMAP3_ID_NAND is not set
 CONFIG_SPL=y
-CONFIG_DEFAULT_DEVICE_TREE="logicpd-torpedo-37xx-devkit"
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_NR_DRAM_BANKS=2
 # CONFIG_USE_BOOTCOMMAND is not set
@@ -29,9 +29,11 @@ 
CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(MLO),1792k(u-boot),128k(spl-
 CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="logicpd-torpedo-37xx-devkit"
 CONFIG_SPL_OF_PLATDATA=y
 # CONFIG_ENV_IS_IN_FAT is not set
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_SPL_DM=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x8200
 CONFIG_DM_I2C=y
@@ -43,10 +45,10 @@ CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
 CONFIG_SYS_NAND_U_BOOT_OFFS=0x8
 CONFIG_SPL_NAND_SIMPLE=y
-CONFIG_NETDEVICES=y
 CONFIG_SMC911X=y
 CONFIG_SMC911X_BASE=0x0800
 CONFIG_SMC911X_32_BIT=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.17.1

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


[U-Boot] [PULL 2018.09] efi patch queue 2018-08-21

2018-08-21 Thread Alexander Graf
Hi Tom,

This is my current patch queue for efi to be applied for 2018.09.  Please pull.

Alex


The following changes since commit 9f8cf76be256a83643ee05de6cffaeb452ed0931:

  Convert CONFIG_SYS_I2C_DAVINCI to Kconfig (2018-08-17 15:43:38 -0400)

are available in the git repository at:

  git://github.com/agraf/u-boot.git tags/signed-efi-2018.09

for you to fetch changes up to dbb148b22cbf242156edf53cca6d661cd320cb83:

  cmd: efi: Clarify calculation precedence for '&' and '?' (2018-08-21 00:04:24 
+0200)


Patch queue for efi - 2018-08-21

A few fixes for 2018.09. Most noticable are:

  - unbreak x86 target (-fdata-section fallout)
  - fix undefined behavior in a few corner cases
  - make Jetson TX1 boot again
  - RTS fixes
  - implement reset for simple output


AKASHI Takahiro (1):
  efi_loader: fix a parameter check at CreateEvent()

Alexander Graf (4):
  sandbox: Move BSS after EFI sections
  x86: Include bss subsections in linker script
  x86: Enable -fdata-sections always
  riscv: Include bss subsections in linker script

Eugeniu Rosca (3):
  efi: Fix truncation of constant value
  efi: Add EFI_MEMORY_{NV, MORE_RELIABLE, RO} attributes
  cmd: efi: Clarify calculation precedence for '&' and '?'

Heinrich Schuchardt (7):
  efi_loader: relocate pointer to tables
  efi_loader: avoid NULL dereference in efi_get_memory_map()
  lib: crc32: mark function crc32() as __efi_runtime
  efi_loader: update runtime services table crc32
  efi_loader: document runtime functions
  efi_selftest: correct block device unit test
  efi_loader: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.Reset()

Stephen Warren (1):
  Revert "efi_loader: efi_allocate_pages is too restrictive"

 arch/riscv/cpu/ax25/u-boot.lds   |   2 +-
 arch/sandbox/cpu/u-boot.lds  |   5 +-
 arch/x86/config.mk   |   4 +-
 arch/x86/cpu/u-boot-64.lds   |   2 +-
 arch/x86/cpu/u-boot.lds  |   2 +-
 arch/x86/lib/elf_ia32_efi.lds|   2 +-
 arch/x86/lib/elf_x86_64_efi.lds  |   2 +-
 cmd/efi.c|  27 ++--
 include/efi.h|  28 ++---
 include/efi_loader.h |   3 +
 lib/crc32.c  |  26 ++--
 lib/efi_loader/efi_boottime.c|  15 +--
 lib/efi_loader/efi_console.c |  22 ++--
 lib/efi_loader/efi_memory.c  |  13 +-
 lib/efi_loader/efi_runtime.c | 177 ++-
 lib/efi_selftest/efi_selftest_block_device.c |   2 +-
 16 files changed, 250 insertions(+), 82 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 27/58] fastboot: sunxi: Update fastboot mmc default device

2018-08-21 Thread Jagan Teki
On Mon, Aug 20, 2018 at 5:14 PM, Maxime Ripard
 wrote:
> On Sun, Aug 19, 2018 at 07:26:44PM +0530, Jagan Teki wrote:
>> Usually eMMC is default mmc device for fastboot.
>>
>> By enabling DM_MMC, the mmc devices are probed as per
>> DT status not with respect to MMC_SUNXI_SLOT_EXTRA in
>> U-Boot proper.
>>
>> Allwinner SoC has maximum of 4 mmc controllers start from
>> mmc0...mmc3 on which mmc2 can be used an eMMC controller
>> eventhough mmc3 some boards used as eMMC.
>>
>> So, update the default fastboot device as 2 to make the
>> standard usage irrespective of DT node status.
>>
>> Other corner cases like different device usage, or specific
>> mmc node status is not enabled in order in DTS must explicitly
>> add config on the specific defconfig file.
>>
>> Cc: Olliver Schinagl 
>> Cc: Chen-Yu Tsai 
>> Signed-off-by: Jagan Teki 
>
> This breaks all existing users, since if DM_MMC isn't set (and it
> isn't at the moment), the MMC IDs won't change, and you're changing it
> from either 0 or 1 to 2.

True, bisectable issue. will take care on next version.

>
> Can't we have a DT property instead? It looks much better than having
> to deal with a non stable ID in Kconfig.

What do you mean by DT property handle? mmc2 is eMMC in all sunXi
isn't? ie reason I make it default.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/2] arm: dts: Add Rock960 devicetree support

2018-08-21 Thread Manivannan Sadhasivam
Add devicetree support for Vamrs Limited Rock960. This board is one of
the 96Boards Consumer Edition platform.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/dts/rk3399-rock960.dts | 348 
 1 file changed, 348 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-rock960.dts

diff --git a/arch/arm/dts/rk3399-rock960.dts b/arch/arm/dts/rk3399-rock960.dts
new file mode 100644
index 000..8662548e642
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock960.dts
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include "rk3399.dtsi"
+#include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
+
+/ {
+   model = "Vamrs Limited Rock960 96Board";
+   compatible = "rockchip,rk3399-rock960", "rockchip,rk3399";
+
+   chosen {
+   stdout-path = &uart2;
+   u-boot,spl-boot-order = \
+   &sdhci, &sdmmc;
+   };
+
+   vccsys: vccsys {
+   compatible = "regulator-fixed";
+   regulator-name = "vccsys";
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc5v0_sys: vcc5v0-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc5v0_usb: vcc5v0-usb {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_usb";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc5v0_host0: vcc5v0-host0-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_host0";
+   gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+   };
+
+   vcc5v0_host1: vcc5v0-host1-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_host1";
+   gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+   };
+
+   vcc5v0_host2: vcc5v0-host2-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_host2";
+   gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+   };
+
+   vbus_typec: vbus-typec-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vbus_typec";
+   gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+   };
+
+   vdd_log: vdd-log {
+   compatible = "pwm-regulator";
+   pwms = <&pwm2 0 25000 1>;
+   regulator-name = "vdd_log";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-init-microvolt = <90>;
+   };
+};
+
+&emmc_phy {
+   status = "okay";
+};
+
+&pwm0 {
+   status = "okay";
+};
+
+&pwm2 {
+   status = "okay";
+};
+
+&pwm3 {
+   status = "okay";
+};
+
+&saradc {
+   status = "okay";
+};
+
+&sdmmc {
+   u-boot,dm-pre-reloc;
+   bus-width = <4>;
+   status = "okay";
+};
+
+&sdhci {
+   bus-width = <8>;
+   mmc-hs400-1_8v;
+   mmc-hs400-enhanced-strobe;
+   non-removable;
+   status = "okay";
+};
+
+&uart2 {
+   status = "okay";
+};
+
+&i2c0 {
+   status = "okay";
+   clock-frequency = <40>;
+   i2c-scl-falling-time-ns = <50>;
+   i2c-scl-rising-time-ns = <100>;
+   u-boot,dm-pre-reloc;
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   reg = <0x1b>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+   #clock-cells = <1>;
+   clock-output-names = "rtc_clko_soc", "rtc_clko_wifi";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pmic_int_l>;
+   rockchip,system-power-controller;
+   wakeup-source;
+
+   vcc1-supply = <&vcc5v0_sys>;
+   vcc2-supply = <&vcc5v0_sys>;
+   vcc3-supply = <&vcc5v0_sys>;
+   vcc4-supply = <&vcc5v0_sys>;
+   vcc6-supply = <&vcc5v0_sys>;
+   vcc7-supply = <&vcc5v0_sys>;
+   vcc8-supply = <&vcc5v0_sys>;
+   vcc9-supply = <&vcc5v0_sys>;
+   vcc10-supply = <&vcc5v0_sys>;
+   vcc11-supply = <&vcc5v0_sys>;
+  

[U-Boot] [PATCH 0/2] Add Rock960 board support

2018-08-21 Thread Manivannan Sadhasivam
This patchset adds board support for Vamrs Limited Rock960,
which is one of the 96Boards Consumer Edition platform based
on Rockchip RK3399 SoC.

On this board, U-Boot will be loaded by ATF as a BL33 image
which in turn loads Linux kernel from eMMC or SD card. Instructions
for building and flashing the images are specified in board
README.md file.

More information about this board can be found in 96Boards product
page: https://www.96boards.org/product/rock960/

The board support includes only the necessary interfaces required
to boot Linux kernel.

Thanks,
Mani

Manivannan Sadhasivam (2):
  arm: dts: Add Rock960 devicetree support
  board: Add Vamrs Limited Rock960 board support

 arch/arm/dts/rk3399-rock960.dts | 348 
 arch/arm/mach-rockchip/rk3399/Kconfig   |  16 +
 board/vamrs/rock960_rk3399/Kconfig  |  15 +
 board/vamrs/rock960_rk3399/MAINTAINERS  |   6 +
 board/vamrs/rock960_rk3399/Makefile |   6 +
 board/vamrs/rock960_rk3399/README   |  79 +
 board/vamrs/rock960_rk3399/rock960-rk3399.c |  50 +++
 configs/rock960-rk3399_defconfig|  62 
 include/configs/rock960_rk3399.h|  15 +
 9 files changed, 597 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-rock960.dts
 create mode 100644 board/vamrs/rock960_rk3399/Kconfig
 create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
 create mode 100644 board/vamrs/rock960_rk3399/Makefile
 create mode 100644 board/vamrs/rock960_rk3399/README
 create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
 create mode 100644 configs/rock960-rk3399_defconfig
 create mode 100644 include/configs/rock960_rk3399.h

-- 
2.17.1

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


[U-Boot] [PATCH 2/2] board: Add Vamrs Limited Rock960 board support

2018-08-21 Thread Manivannan Sadhasivam
Add board support for Vamrs Limited Rock960 board, which is
one of the 96Boards Consumer Edition platform.

Rock960 features:
* CPU: ARMv8 64bit Big-Little architecture,
* Big: dual-core Cortex-A72
* Little: quad-core Cortex-A53
* IRAM: 200KB
* DRAM: 2GB/4GB LPDDR3 @ 1866MHz
* eMMC: 16/32GB eMMC 5.1
* PMU: RK808
* SD/MMC
* USB:
* 1x USB 3.0 type A, 1x USB 2.0 type A (host mode only) and
  1x USB 3.0 type C OTG
* Display:
* 1x HDMI 2.0(Type A - full) up to 4Kx2K@60Hz,
  1x 4L - MIPI DSI up to 1080p@60Hz,
  1x DP 1.2(Type C) up to 4Kx2K@60
* Camera: 2x 4-lane MIPI CSI
* PCI-E: 4- lane M.2 PCI-E 2.1
* Low Speed Expansion Connector
* High Speed Expansion Connector

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/mach-rockchip/rk3399/Kconfig   | 16 +
 board/vamrs/rock960_rk3399/Kconfig  | 15 
 board/vamrs/rock960_rk3399/MAINTAINERS  |  6 ++
 board/vamrs/rock960_rk3399/Makefile |  6 ++
 board/vamrs/rock960_rk3399/README   | 79 +
 board/vamrs/rock960_rk3399/rock960-rk3399.c | 50 +
 configs/rock960-rk3399_defconfig| 62 
 include/configs/rock960_rk3399.h| 15 
 8 files changed, 249 insertions(+)
 create mode 100644 board/vamrs/rock960_rk3399/Kconfig
 create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
 create mode 100644 board/vamrs/rock960_rk3399/Makefile
 create mode 100644 board/vamrs/rock960_rk3399/README
 create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
 create mode 100644 configs/rock960-rk3399_defconfig
 create mode 100644 include/configs/rock960_rk3399.h

diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
b/arch/arm/mach-rockchip/rk3399/Kconfig
index 415466a49bb..ce4605187e3 100644
--- a/arch/arm/mach-rockchip/rk3399/Kconfig
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -28,6 +28,21 @@ config TARGET_PUMA_RK3399
   * HDMI, eDP, MIPI-DSI, MIPI-DSI/CSI and MIPI-CSI
   * SPI, I2C, I2S, UART, GPIO, ...
 
+config TARGET_ROCK960_RK3399
+   bool "Vamrs Limited Rock960 board"
+   help
+ Support for Rock960 board. This board complies with
+ 96Board Consumer Edition Specification.
+
+ Features:
+  * Rockchip RK3399 SoC (2xCortex A72, 4xCortex A53, ARM Mali T860MP4)
+  * 2GiB/4GiB RAM
+  * 16/32GB eMMC, uSD slot
+  * WiFi, Bluetooth
+  * 1x USB 3.0 type A, 1x USB 2.0 type A (host mode only), 1x USB 3.0 
type C OTG
+  * HDMI
+  * 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
+
 endchoice
 
 config SYS_SOC
@@ -38,5 +53,6 @@ config SYS_MALLOC_F_LEN
 
 source "board/rockchip/evb_rk3399/Kconfig"
 source "board/theobroma-systems/puma_rk3399/Kconfig"
+source "board/vamrs/rock960_rk3399/Kconfig"
 
 endif
diff --git a/board/vamrs/rock960_rk3399/Kconfig 
b/board/vamrs/rock960_rk3399/Kconfig
new file mode 100644
index 000..cacc53f3780
--- /dev/null
+++ b/board/vamrs/rock960_rk3399/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_ROCK960_RK3399
+
+config SYS_BOARD
+   default "rock960_rk3399"
+
+config SYS_VENDOR
+   default "vamrs"
+
+config SYS_CONFIG_NAME
+   default "rock960_rk3399"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y
+
+endif
diff --git a/board/vamrs/rock960_rk3399/MAINTAINERS 
b/board/vamrs/rock960_rk3399/MAINTAINERS
new file mode 100644
index 000..9f3fe75f4fb
--- /dev/null
+++ b/board/vamrs/rock960_rk3399/MAINTAINERS
@@ -0,0 +1,6 @@
+ROCK960-RK3399
+M:  Manivannan Sadhasivam manivannan.sadhasi...@linaro.org
+S:  Maintained
+F:  board/rockchip/rock960_rk3399
+F:  include/configs/rock960_rk3399.h
+F:  configs/rock960-rk3399_defconfig
diff --git a/board/vamrs/rock960_rk3399/Makefile 
b/board/vamrs/rock960_rk3399/Makefile
new file mode 100644
index 000..6c3e475b3a8
--- /dev/null
+++ b/board/vamrs/rock960_rk3399/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018 Manivannan Sadhasivam 
+#
+
+obj-y  += rock960-rk3399.o
diff --git a/board/vamrs/rock960_rk3399/README 
b/board/vamrs/rock960_rk3399/README
new file mode 100644
index 000..be6b5cd1d34
--- /dev/null
+++ b/board/vamrs/rock960_rk3399/README
@@ -0,0 +1,79 @@
+Introduction
+
+
+Rock960 is a 96Boards Consumer Edition platform featuring the Rockchip
+RK3399 SoC.
+
+Rock960 features:
+   * CPU: ARMv8 64bit Big-Little architecture,
+   * Big: dual-core Cortex-A72
+   * Little: quad-core Cortex-A53
+   * IRAM: 200KB
+   * DRAM: 2GB/4GB LPDDR3 @ 1866MHz
+   * eMMC: 16/32GB eMMC 5.1
+   * PMU: RK808
+   * SD/MMC
+   * USB:
+   * 1x USB 3.0 type A, 1x USB 2.0 type A (host mode only) and
+ 1x USB 3.0 type

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

2018-08-21 Thread Tom Warren
 Tom,

Please pull u-boot-tegra/master into U-Boot/master. Thanks!

All Tegra builds are OK, and Stephen's automated test system reports that
all tests pass.

The following changes since commit b71d9e8b3805305ea4116733f515061710ad7081:

  Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2018-08-20
13:41:56 -0400)

are available in the git repository at:

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

for you to fetch changes up to 3d186cf3f3ab5c18ede0f0a4ff85ffe99839bc7b:

  ARM: tegra: avoid more operations in non-secure world (2018-08-21
08:41:00 -0700)


Nicolas Chauvet (1):
  arm: tegra: Restore host1x/dc dm-pre-reloc properties

Stephen Warren (1):
  ARM: tegra: avoid more operations in non-secure world

 arch/arm/dts/tegra20-u-boot.dtsi | 10 ++
 arch/arm/mach-tegra/ap.c |  9 +++--
 arch/arm/mach-tegra/gpu.c| 18 --
 3 files changed, 29 insertions(+), 8 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 0/2] Add Rock960 board support

2018-08-21 Thread Manivannan Sadhasivam
This patchset adds board support for Vamrs Limited Rock960,
which is one of the 96Boards Consumer Edition platform based
on Rockchip RK3399 SoC.

On this board, U-Boot will be loaded by ATF as a BL33 image
which in turn loads Linux kernel from eMMC or SD card. Instructions
for building and flashing the images are specified in board
README.md file.

More information about this board can be found in 96Boards product
page: https://www.96boards.org/product/rock960/

The board support includes only the necessary interfaces required
to boot Linux kernel.

Thanks,
Mani

Manivannan Sadhasivam (2):
  arm: dts: Add Rock960 devicetree support
  board: Add Vamrs Limited Rock960 board support

 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/rk3399-rock960.dts | 348 
 arch/arm/mach-rockchip/rk3399/Kconfig   |  16 +
 board/vamrs/rock960_rk3399/Kconfig  |  15 +
 board/vamrs/rock960_rk3399/MAINTAINERS  |   6 +
 board/vamrs/rock960_rk3399/Makefile |   6 +
 board/vamrs/rock960_rk3399/README   |  79 +
 board/vamrs/rock960_rk3399/rock960-rk3399.c |  50 +++
 configs/rock960-rk3399_defconfig|  62 
 include/configs/rock960_rk3399.h|  15 +
 10 files changed, 598 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-rock960.dts
 create mode 100644 board/vamrs/rock960_rk3399/Kconfig
 create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
 create mode 100644 board/vamrs/rock960_rk3399/Makefile
 create mode 100644 board/vamrs/rock960_rk3399/README
 create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
 create mode 100644 configs/rock960-rk3399_defconfig
 create mode 100644 include/configs/rock960_rk3399.h

-- 
2.17.1

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


[U-Boot] [PATCH v2 1/2] arm: dts: Add Rock960 devicetree support

2018-08-21 Thread Manivannan Sadhasivam
Add devicetree support for Vamrs Limited Rock960. This board is one of
the 96Boards Consumer Edition platform.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v2:

* Added missing DTB entry in arch/arm/dts/Makefile

 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/rk3399-rock960.dts | 348 
 2 files changed, 349 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-rock960.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ebfa2272627..9b891826b73 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -51,6 +51,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3399-puma-ddr1333.dtb \
rk3399-puma-ddr1600.dtb \
rk3399-puma-ddr1866.dtb \
+   rk3399-rock960.dtb \
rv1108-evb.dtb
 dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-nanopi-k2.dtb \
diff --git a/arch/arm/dts/rk3399-rock960.dts b/arch/arm/dts/rk3399-rock960.dts
new file mode 100644
index 000..8662548e642
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock960.dts
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include "rk3399.dtsi"
+#include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
+
+/ {
+   model = "Vamrs Limited Rock960 96Board";
+   compatible = "rockchip,rk3399-rock960", "rockchip,rk3399";
+
+   chosen {
+   stdout-path = &uart2;
+   u-boot,spl-boot-order = \
+   &sdhci, &sdmmc;
+   };
+
+   vccsys: vccsys {
+   compatible = "regulator-fixed";
+   regulator-name = "vccsys";
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc5v0_sys: vcc5v0-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc5v0_usb: vcc5v0-usb {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_usb";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc5v0_host0: vcc5v0-host0-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_host0";
+   gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+   };
+
+   vcc5v0_host1: vcc5v0-host1-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_host1";
+   gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+   };
+
+   vcc5v0_host2: vcc5v0-host2-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_host2";
+   gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+   };
+
+   vbus_typec: vbus-typec-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vbus_typec";
+   gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+   };
+
+   vdd_log: vdd-log {
+   compatible = "pwm-regulator";
+   pwms = <&pwm2 0 25000 1>;
+   regulator-name = "vdd_log";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-init-microvolt = <90>;
+   };
+};
+
+&emmc_phy {
+   status = "okay";
+};
+
+&pwm0 {
+   status = "okay";
+};
+
+&pwm2 {
+   status = "okay";
+};
+
+&pwm3 {
+   status = "okay";
+};
+
+&saradc {
+   status = "okay";
+};
+
+&sdmmc {
+   u-boot,dm-pre-reloc;
+   bus-width = <4>;
+   status = "okay";
+};
+
+&sdhci {
+   bus-width = <8>;
+   mmc-hs400-1_8v;
+   mmc-hs400-enhanced-strobe;
+   non-removable;
+   status = "okay";
+};
+
+&uart2 {
+   status = "okay";
+};
+
+&i2c0 {
+   status = "okay";
+   clock-frequency = <40>;
+   i2c-scl-falling-time-ns = <50>;
+   i2c-scl-rising-time-ns = <100>;
+   u-boot,dm-pre-reloc;
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   reg = <0x1b>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+   #clock-cells = <1>;
+   clock-output-names = "rtc_clko_soc", "rtc_clko_wifi";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pmic_int_l>;
+  

[U-Boot] [PATCH v2 2/2] board: Add Vamrs Limited Rock960 board support

2018-08-21 Thread Manivannan Sadhasivam
Add board support for Vamrs Limited Rock960 board, which is
one of the 96Boards Consumer Edition platform.

Rock960 features:
* CPU: ARMv8 64bit Big-Little architecture,
* Big: dual-core Cortex-A72
* Little: quad-core Cortex-A53
* IRAM: 200KB
* DRAM: 2GB/4GB LPDDR3 @ 1866MHz
* eMMC: 16/32GB eMMC 5.1
* PMU: RK808
* SD/MMC
* USB:
* 1x USB 3.0 type A, 1x USB 2.0 type A (host mode only) and
  1x USB 3.0 type C OTG
* Display:
* 1x HDMI 2.0(Type A - full) up to 4Kx2K@60Hz,
  1x 4L - MIPI DSI up to 1080p@60Hz,
  1x DP 1.2(Type C) up to 4Kx2K@60
* Camera: 2x 4-lane MIPI CSI
* PCI-E: 4- lane M.2 PCI-E 2.1
* Low Speed Expansion Connector
* High Speed Expansion Connector

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v2: None

 arch/arm/mach-rockchip/rk3399/Kconfig   | 16 +
 board/vamrs/rock960_rk3399/Kconfig  | 15 
 board/vamrs/rock960_rk3399/MAINTAINERS  |  6 ++
 board/vamrs/rock960_rk3399/Makefile |  6 ++
 board/vamrs/rock960_rk3399/README   | 79 +
 board/vamrs/rock960_rk3399/rock960-rk3399.c | 50 +
 configs/rock960-rk3399_defconfig| 62 
 include/configs/rock960_rk3399.h| 15 
 8 files changed, 249 insertions(+)
 create mode 100644 board/vamrs/rock960_rk3399/Kconfig
 create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
 create mode 100644 board/vamrs/rock960_rk3399/Makefile
 create mode 100644 board/vamrs/rock960_rk3399/README
 create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
 create mode 100644 configs/rock960-rk3399_defconfig
 create mode 100644 include/configs/rock960_rk3399.h

diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
b/arch/arm/mach-rockchip/rk3399/Kconfig
index 415466a49bb..ce4605187e3 100644
--- a/arch/arm/mach-rockchip/rk3399/Kconfig
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -28,6 +28,21 @@ config TARGET_PUMA_RK3399
   * HDMI, eDP, MIPI-DSI, MIPI-DSI/CSI and MIPI-CSI
   * SPI, I2C, I2S, UART, GPIO, ...
 
+config TARGET_ROCK960_RK3399
+   bool "Vamrs Limited Rock960 board"
+   help
+ Support for Rock960 board. This board complies with
+ 96Board Consumer Edition Specification.
+
+ Features:
+  * Rockchip RK3399 SoC (2xCortex A72, 4xCortex A53, ARM Mali T860MP4)
+  * 2GiB/4GiB RAM
+  * 16/32GB eMMC, uSD slot
+  * WiFi, Bluetooth
+  * 1x USB 3.0 type A, 1x USB 2.0 type A (host mode only), 1x USB 3.0 
type C OTG
+  * HDMI
+  * 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
+
 endchoice
 
 config SYS_SOC
@@ -38,5 +53,6 @@ config SYS_MALLOC_F_LEN
 
 source "board/rockchip/evb_rk3399/Kconfig"
 source "board/theobroma-systems/puma_rk3399/Kconfig"
+source "board/vamrs/rock960_rk3399/Kconfig"
 
 endif
diff --git a/board/vamrs/rock960_rk3399/Kconfig 
b/board/vamrs/rock960_rk3399/Kconfig
new file mode 100644
index 000..cacc53f3780
--- /dev/null
+++ b/board/vamrs/rock960_rk3399/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_ROCK960_RK3399
+
+config SYS_BOARD
+   default "rock960_rk3399"
+
+config SYS_VENDOR
+   default "vamrs"
+
+config SYS_CONFIG_NAME
+   default "rock960_rk3399"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y
+
+endif
diff --git a/board/vamrs/rock960_rk3399/MAINTAINERS 
b/board/vamrs/rock960_rk3399/MAINTAINERS
new file mode 100644
index 000..9f3fe75f4fb
--- /dev/null
+++ b/board/vamrs/rock960_rk3399/MAINTAINERS
@@ -0,0 +1,6 @@
+ROCK960-RK3399
+M:  Manivannan Sadhasivam manivannan.sadhasi...@linaro.org
+S:  Maintained
+F:  board/rockchip/rock960_rk3399
+F:  include/configs/rock960_rk3399.h
+F:  configs/rock960-rk3399_defconfig
diff --git a/board/vamrs/rock960_rk3399/Makefile 
b/board/vamrs/rock960_rk3399/Makefile
new file mode 100644
index 000..6c3e475b3a8
--- /dev/null
+++ b/board/vamrs/rock960_rk3399/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018 Manivannan Sadhasivam 
+#
+
+obj-y  += rock960-rk3399.o
diff --git a/board/vamrs/rock960_rk3399/README 
b/board/vamrs/rock960_rk3399/README
new file mode 100644
index 000..be6b5cd1d34
--- /dev/null
+++ b/board/vamrs/rock960_rk3399/README
@@ -0,0 +1,79 @@
+Introduction
+
+
+Rock960 is a 96Boards Consumer Edition platform featuring the Rockchip
+RK3399 SoC.
+
+Rock960 features:
+   * CPU: ARMv8 64bit Big-Little architecture,
+   * Big: dual-core Cortex-A72
+   * Little: quad-core Cortex-A53
+   * IRAM: 200KB
+   * DRAM: 2GB/4GB LPDDR3 @ 1866MHz
+   * eMMC: 16/32GB eMMC 5.1
+   * PMU: RK808
+   * SD/MMC
+   * USB:
+   * 1x USB 3.0 type A, 1x USB 2.0 type A (host mode only) and
+  

Re: [U-Boot] [PATCH] dm: test: Fix typo in test-main comment

2018-08-21 Thread Simon Glass
On 20 August 2018 at 00:03, Michal Simek  wrote:
> Trivial fix.
>
> Signed-off-by: Michal Simek 
> ---
>
>  test/dm/test-main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH] efi_loader: Rename sections to allow for implicit data

2018-08-21 Thread Simon Glass
Hi Alex,

On 20 August 2018 at 06:23, Alexander Graf  wrote:
>
> On 08/17/2018 02:49 PM, Simon Glass wrote:
>>
>> Hi,
>>
>> On 9 August 2018 at 23:45, Bin Meng  wrote:
>>>
>>> Hi Alex,
>>>
>>> On Wed, Aug 8, 2018 at 1:16 AM, Alexander Graf  wrote:


> Am 07.08.2018 um 18:12 schrieb Simon Glass :
>
> Hi Alex,
>
>> On 11 June 2018 at 23:48, Alexander Graf  wrote:
>> Some times gcc may generate data that is then used within code that may
>> be part of an efi runtime section. That data could be jump tables,
>> constants or strings.
>>
>> In order to make sure we catch these, we need to ensure that gcc emits
>> them into a section that we can relocate together with all the other
>> efi runtime bits. This only works if the -ffunction-sections and
>> -fdata-sections flags are passed and the efi runtime functions are
>> in a section that starts with ".text".
>>
>> Up to now we had all efi runtime bits in sections that did not
>> interfere with the normal section naming scheme, but this forces
>> us to do so. Hence we need to move the efi_loader text/data/rodata
>> sections before the global *(.text*) catch-all section.
>>
>> With this patch in place, we should hopefully have an easier time
>> to extend the efi runtime functionality in the future.
>>
>> Signed-off-by: Alexander Graf 
>> ---
>> arch/arm/config.mk|  4 ++--
>> arch/arm/cpu/armv8/u-boot.lds | 24 +
>> arch/arm/cpu/u-boot.lds   | 36 
>> ++-
>> arch/arm/mach-zynq/u-boot.lds | 36 
>> ++-
>> arch/riscv/cpu/ax25/u-boot.lds| 26 +-
>> arch/sandbox/config.mk|  3 +++
>> arch/sandbox/cpu/u-boot.lds   |  9 
>> arch/x86/config.mk|  2 +-
>> arch/x86/cpu/u-boot.lds   | 32 
>> ++-
>> board/qualcomm/dragonboard410c/u-boot.lds | 17 +--
>> board/qualcomm/dragonboard820c/u-boot.lds | 24 +
>> board/ti/am335x/u-boot.lds| 36 
>> ++-
>> include/efi_loader.h  |  4 ++--
>> 13 files changed, 154 insertions(+), 99 deletions(-)
>>
> I missed this at the time, probably thinking the subject made it sound
> innocuous. There is no 'sandbox:' tag.
>
> This seems to break sandbox in a pretty strange way:
>
> gdb --args /tmp/crosfw/sandbox/u-boot -D
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /tmp/crosfw/sandbox/u-boot...done.
> (gdb) r
> Starting program: /tmp/crosfw/sandbox/u-boot -D
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x55571520 in open@plt ()
> (gdb) up
> #1  0x55571e9a in sandbox_read_fdt_from_file ()
> at /home/sjg/c/src/third_party/u-boot/files/arch/sandbox/cpu/cpu.c:264
> 264 fd = os_open(fname, OS_O_RDONLY);
> (gdb) print fname
> $1 = 0x77ff "/tmp/crosfw/sandbox/u-boot.dtb"
> (gdb) q
>
>
> Also the commit message suggests that this patch changes sandbox to
> use --gc-sections, which is not obvious from the subject. I think that
> should be a separate commit and in fact it should really be separate
> commits for each arch, I think. That might help people notice it...
>
> I only noticed now since the EFI pull request has landed.

 Can you try my bss patch really quick? Maybe we're just overwriting gd.

 Alex

>>> This patch breaks efi-x86_app_defconfig. The EFI application no longer
>>> boots. I was testing on top of u-boot/master.
>>>
>>> If I do:
>>>
>>> diff --git a/arch/x86/config.mk b/arch/x86/config.mk
>>> index 586e11a..fc119ec 100644
>>> --- a/arch/x86/config.mk
>>> +++ b/arch/x86/config.mk
>>> @@ -24,7 +24,6 @@ endif
>>>   ifeq ($(I

Re: [U-Boot] [PATCH v3 03/10] video: add support of MIPI DSI interface

2018-08-21 Thread Simon Glass
Hi,

On 17 August 2018 at 08:38, Yannick Fertré  wrote:
> Mipi_display.c contains a set of dsi helpers.
> This file is a copy of file drm_mipi_dsi.c (linux kernel).
>
> Signed-off-by: Yannick Fertré 
> ---
>  drivers/video/Kconfig|   8 +
>  drivers/video/Makefile   |   1 +
>  drivers/video/mipi_dsi.c | 828 
> +++
>  include/mipi_dsi.h   | 451 ++
>  4 files changed, 1288 insertions(+)
>  create mode 100644 drivers/video/mipi_dsi.c
>  create mode 100644 include/mipi_dsi.h

Yes I think you need a uclass. However it is probably not applicable
for this file, but for the other one, where you have the transfer()
method. You should set up a uclass for that.

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


Re: [U-Boot] [PATCH v3 04/10] video: add MIPI DSI host controller bridge

2018-08-21 Thread Simon Glass
Hi,

On 17 August 2018 at 08:38, Yannick Fertré  wrote:
> Add a Synopsys Designware MIPI DSI host bridge driver, based on the
> Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
>
> Signed-off-by: Yannick Fertré 
> ---
>  drivers/video/Kconfig   |   9 +
>  drivers/video/Makefile  |   1 +
>  drivers/video/dw_mipi_dsi.c | 827 
> 
>  include/dw_mipi_dsi.h   |  33 ++
>  4 files changed, 870 insertions(+)
>  create mode 100644 drivers/video/dw_mipi_dsi.c
>  create mode 100644 include/dw_mipi_dsi.h

This needs to use driver model. E.g. add your operations as a uclass
and go from there.

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


Re: [U-Boot] Disabling CONFIG_DM_I2C_COMPAT in twl4030 PMIC

2018-08-21 Thread Simon Glass
Hi,

On 19 August 2018 at 17:33, Tom Rini  wrote:
> On Sun, Aug 19, 2018 at 01:37:29PM -0500, Adam Ford wrote:
>> On Sun, Aug 19, 2018 at 11:53 AM Tom Rini  wrote:
>> >
>> > On Sun, Aug 19, 2018 at 09:45:30AM -0500, Adam Ford wrote:
>> > > On Fri, Aug 17, 2018 at 10:21 PM Adam Ford  wrote:
>> > > >
>> > > > I am working to disable CONFIG_DM_I2C_COMPAT for the omap3 boards.
>> > > > Some of these boards use the TWL4030 PMIC which is still using the
>> > > > older i2c_write and i2c_read functions.
>> > > >
>> > > > I wonder if someone can point me to a good patch that I can use a
>> > > > model one how to appropriately port I2C drivers forward?  I'd like to
>> > > > disable this feature so the notice goes away since it seems like
>> > > > DM_I2C should be do-able by now.
>> > > >
>> > >
>> > > More specifically, the TWL4030 has multiple I2C addresses, but it's
>> > > primary address is 0x48 and is assigned in the device tree as such.  I
>> > > have been able to create the primary PMIC on address 0x48, but there
>> > > are multiple i2c addresses through which it can be addressed.  The
>> > > device tree for the twl4030 lists multuple sub-regulators, but they
>> > > are not contained within  'regulators' node, and the bind function
>> > > cannot locate the children because there are no regulator-names
>> > > associated.  The individual regulators are sub-nodes, but their
>> > > control registers are not necessarily on the same i2c address of the
>> > > primary.  The additional i2c addresses are 0x49, 0x4a, and 0x4b, but
>> > > none are listed in the device tree.
>> > >
>> > > What I'd like to do is replace the stock initialization sequence with
>> > > a more generic one that not only initializes the PMIC and all
>> > > corresponding registers, I'd also like to have it set all the
>> > > sub-regulators based on the voltage ratings listed by the device tree,
>> > >  I was hoping someone might teach me the 'proper' way to create these
>> > > 3 additional i2c devices (not shown on the device tree) on the same
>> > > I2C bus as the original, have them list all sub-regulators of the
>> > > original PMIC, and be able to address them individually.
>> >
>> > So, when you refer to the device tree I assume you're talking about one
>> > that's relatively in sync with the Linux kernel and all of these devices
>> > Just Work there.  So, in that case, how does Linux go from "the device
>> > tree describes $this" to "we need to bind drivers x/y/z" ?
>>
>> From what I can tell, each regulator in the PMIC is independant to
>> each other.  They're using .compatible = "xxx" for each regulator, and
>> they have a bunch of macros to connect either twl4030 or 6030 to the
>> table.
>> They also have a helper function that associates the various i2c
>> addresses to each regulator.
>>
>> Currently, we're using CONFIG_DM_I2C_COMPAT to allow the i2c_read and
>> i2c_write funtions to exist where part of the parameter is the pass
>> the i2c address which is then abstracted by the twl driver.
>>
>> If I create the PMIC type, the address of the PMIC is contained so all
>> read/write functions go to 0x48 instead of 0x4b, where I want it.
>>
>> I can certainly try to create completely separate regulators using the
>> .compatible flag, but it's not clear to me how to assign the I2C
>> address to a manually generated regulator because each regulator is a
>> sub-node of the PMIC.  It's also not clear to how to continue to
>> associate the reulators to the PMIC.
>>
>> Would it be better to just create a bunch of individual regulators?
>> They would all share the same I2C address, and I am not sure if that's
>> a conflict or not.
>
> Simon, Jaehoon, any ideas on how to make this setup that works under
> Linux work here?  Thanks!

I was not aware that we could support multiple I2C addresses with a
single device. How does Linux handle that? It is particularly strange
to me that the DT does not specify the addresses.

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


Re: [U-Boot] [PATCH v2 1/3] ofnode: add ofnode_by_prop_value()

2018-08-21 Thread Simon Glass
On 20 August 2018 at 03:09, Jens Wiklander  wrote:
> Adds ofnode_by_prop_value() to search for nodes with a given property
> and value, an ofnode version of fdt_node_offset_by_prop_value().
>
> Signed-off-by: Jens Wiklander 
> ---
>  drivers/core/of_access.c | 27 +++
>  drivers/core/ofnode.c| 14 ++
>  include/dm/of_access.h   | 16 
>  include/dm/ofnode.h  | 14 ++
>  4 files changed, 71 insertions(+)

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


Re: [U-Boot] [RFC PATCH v2 3/6] dm: usb: Add UCLASS_USB_DEV_GENERIC shutdown

2018-08-21 Thread Simon Glass
Hi Jagan,

On 17 August 2018 at 07:37, Jagan Teki  wrote:
> Hi Simon,
>
> On Fri, Aug 17, 2018 at 6:18 PM, Simon Glass  wrote:
>> Hi Jagan,
>>
>> On 7 August 2018 at 01:03, Jagan Teki  wrote:
>>> On Tue, Jul 24, 2018 at 5:18 AM, Simon Glass  wrote:
 Hi Jagan,

 On 20 July 2018 at 01:13, Jagan Teki  wrote:
> Some OTG controllers which operates on Peripheral
> mode are registered as UCLASS_USB_DEV_GENERIC.
>
> So add support to shutdown them as well. shutdown
> happened during 'usb reset' and U-Boot handoff code
> for Linux boot.
>
> controller restarting in 'usb reset' like probing
> again is still missing for this type of UCLASS.
>
> Cc: Simon Glass 
> Signed-off-by: Jagan Teki 
> ---
> Note:
> I tried of traversing for multiple UCLASS in removal
> code in usb_stop, but couldn't come with proper solutions.
> I don't think any other area of code need a requirement like
> this, or may be I'm missing. any help would appreciate.
>
> Changes for v2:
> - none
>
>  drivers/usb/host/usb-uclass.c | 43 +++
>  1 file changed, 43 insertions(+)
>
> diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
> index 611ea97a72..99cf3d2b49 100644
> --- a/drivers/usb/host/usb-uclass.c
> +++ b/drivers/usb/host/usb-uclass.c
> @@ -158,6 +158,45 @@ int usb_get_max_xfer_size(struct usb_device *udev, 
> size_t *size)
> return ops->get_max_xfer_size(bus, size);
>  }
>
> +int __usb_stop(void)

 Why the __ ? I think it should be something like 
 usb_remove_and_unbind_all()

> +{
> +   struct udevice *bus;
> +   struct udevice *rh;
> +   struct uclass *uc;
> +   struct usb_uclass_priv *uc_priv;
> +   int err = 0, ret;
> +
> +   /* De-activate any devices that have been activated */
> +   ret = uclass_get(UCLASS_USB_DEV_GENERIC, &uc);
> +   if (ret)
> +   return ret;
> +
> +   uc_priv = uc->priv;
> +
> +   uclass_foreach_dev(bus, uc) {
> +   ret = device_remove(bus, DM_REMOVE_NORMAL);
> +   if (ret && !err)
> +   err = ret;
> +
> +   /* Locate root hub device */
> +   device_find_first_child(bus, &rh);
> +   if (rh) {
> +   /*
> +* All USB devices are children of root hub.
> +* Unbinding root hub will unbind all of its 
> children.
> +*/
> +   ret = device_unbind(rh);
> +   if (ret && !err)
> +   err = ret;
> +   }
> +   }
> +
> +   uc_priv->companion_device_count = 0;
> +   usb_started = 0;
> +
> +   return err;
> +}
> +
>  int usb_stop(void)
>  {
> struct udevice *bus;
> @@ -166,6 +205,10 @@ int usb_stop(void)
> struct usb_uclass_priv *uc_priv;
> int err = 0, ret;
>
> +   ret = __usb_stop();
> +   if (ret)
> +   return ret;
> +

 This looks like the same code that appears below here, or very
 similar. Why is this needed?
>>>
>>> Here the usage-case it to remove/unbind UCLASS_USB and
>>> UCLASS_USB_DEV_GENERIC and same code will use to do that, any
>>> suggestions?
>>
>> I'm just wondering why you appear to be duplicating the exact code
>> that is already there? Maybe I am missing something, iwc please can
>> you explain it?
>
> Yes, the code is duplicate. Here, I'm looking for suggestion to
> unbind/remove multiple UCLASS's like UCLASS_USB and
> ULASS_USB_DEV_GENERIC in this use-case. do you have any? or am I
> missing something?

But if you unbind the bus, doesn't this automatically unbind its children?

At the very least, it seems like there is some common code here that
you should factor out.

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


Re: [U-Boot] [RESEND PATCH v9 01/18] Revert "efi_loader: Rename sections to allow for implicit data"

2018-08-21 Thread Simon Glass
Hi Alex,

On 20 August 2018 at 16:29, Alexander Graf  wrote:
>
>
>
> On 20.08.18 20:54, Simon Glass wrote:
> > This partially reverts commit 7e21fbca26d18327cf7cabaad08df276a06a07d8.
> >
> > That change broke sandbox EFI support for unknown reasons. It also changes
>
> Wouldn't it be better to just figure out the reasons? So far all bugs
> I've found were linker script related and quite obvious once you start
> to dig into them.
>
> > sandbox to use--gc-sections which we don't want.
>
> Why don't we want gc-sections with sandbox?

It is a space optimisation which we don't need for sandbox. It also
complicates the object files unnecessarily.

Put another way, why is it desirable?

>
> > For now I am just reverting the sandbox portion as presumably this change
> > is safe on other architectures.
>
> Sandbox is your target, so you're free to do whatever you like :). But
> I'm not sure this is the right path forward. I'd rather like to keep
> things consistent.

In what sense?

>
> So what do you expect happens with this patch? A resend of a patch 1/18
> by itself doesn't really tell me what you're trying to say.

The resend was due to me noticing that people did not get the patch on
cc. I only sent this one patch, but I can resend send the whole series
if you like.

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


  1   2   >