Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values from DT

[Mugunthan V N]

On Wednesday 13 April 2016 03:40 PM, Vignesh R wrote:
> In case of DT boot, don't read default speed and mode for SPI from
> CONFIG_*, instead read from DT node. This will make sure that boards
> with multiple SPI/QSPI controllers can be probed at different
> bus frequencies and SPI modes.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Mugunthan V N 

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

Re: [U-Boot] [PATCH 4/9] drivers: nand: implement a NAND uclass

[Mugunthan V N]

On Thursday 21 April 2016 07:41 PM, Simon Glass wrote:
> Hi Mugunthan,
> 
> On 20 April 2016 at 23:55, Mugunthan V N  wrote:
>> On Wednesday 20 April 2016 08:09 PM, Simon Glass wrote:
>>> Hi Mugunthan,
>>>
>>> On 1 April 2016 at 05:29, Mugunthan V N  wrote:
 Implement a NAND uclass so that the NAND devices can be
 accessed via the DM framework.

 Signed-off-by: Mugunthan V N 
 ---
  drivers/mtd/nand/Kconfig   | 10 +++
  drivers/mtd/nand/Makefile  |  2 ++
  drivers/mtd/nand/nand-uclass.c | 62 
 ++
  drivers/mtd/nand/nand.c|  6 +++-
  include/dm/uclass-id.h |  1 +
  include/nand.h |  5 
  6 files changed, 85 insertions(+), 1 deletion(-)
  create mode 100644 drivers/mtd/nand/nand-uclass.c

 diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
 index 7787505..53b57b8 100644
 --- a/drivers/mtd/nand/Kconfig
 +++ b/drivers/mtd/nand/Kconfig
 @@ -8,6 +8,16 @@ menuconfig NAND

  if NAND

 +config DM_NAND
 +   bool "Enable driver model for NAND"
 +   depends on NAND && DM
 +   help
 + Enable driver model for NAND. The NAND interface is then
 + implemented by the NAND uclass. Multiple NAND devices can
 + be attached and used. The 'nand' command works as normal.
 +
 + If the NAND drivers doesn't support DM, say N.
 +
  config SYS_NAND_SELF_INIT
 bool
 help
 diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
 index 6fb3718..7745705 100644
 --- a/drivers/mtd/nand/Makefile
 +++ b/drivers/mtd/nand/Makefile
 @@ -39,6 +39,8 @@ endif # not spl

  ifdef NORMAL_DRIVERS

 +obj-$(CONFIG_DM_NAND) += nand-uclass.o
 +
  obj-$(CONFIG_NAND_ECC_BCH) += nand_bch.o

  obj-$(CONFIG_NAND_ATMEL) += atmel_nand.o
 diff --git a/drivers/mtd/nand/nand-uclass.c 
 b/drivers/mtd/nand/nand-uclass.c
 new file mode 100644
 index 000..d68d357
 --- /dev/null
 +++ b/drivers/mtd/nand/nand-uclass.c
 @@ -0,0 +1,62 @@
 +/*
 + * NAND uclass driver for NAND bus.
 + *
 + * (C) Copyright 2012-2016
 + * Texas Instruments Incorporated, 
 + *
 + * SPDX-License-Identifier: GPL-2.0+
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +DECLARE_GLOBAL_DATA_PTR;
 +
 +#ifdef CONFIG_DM_NAND
 +
 +nand_info_t *get_nand_dev_by_index(int idx)
 +{
 +   nand_info_t *nand;
 +   struct udevice *dev;
 +   int ret;
 +
 +   ret = uclass_get_device(UCLASS_NAND, idx, );
 +   if (ret) {
 +   error("NAND device (%d) not found\n", idx);
>>>
>>> This should return -ENODEV. Also please avoid printf() in drivers. The
>>> caller can report the error.
>>>
>>
>> Return type is pointer so returned NULL and NULL denotes no dev.
>> Will change this error to debug in v2.
> 
> OK, I see that this is the existing API.
> 
>>
 +   return NULL;
 +   }
 +
 +   nand = (nand_info_t *)dev_get_uclass_priv(dev);
 +   if (!nand) {
 +   error("Nand device not ready\n");
 +   return NULL;
 +   }
>>>
>>> But if the device has been probed ((with uclass_get_device()) then
>>> this cannot be NULL.
>>
>> This check is just a failsafe. ideally it should not fail here.
> 
> I cannot get to probe the device without this data, since this would
> be a bug in DM. So the check has no value.
> 

Okay then I will remove this check as it doesn't add value.

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

Re: [U-Boot] [PATCH] zynq: Allow board specific files to over write CONFIG_EXTRA_ENV_SETTINGS.

[Michal Simek]

On 21.4.2016 20:14, Philip Balister wrote:
> The zynq-common.h header file is usually included last in the board specific
> header file. Check if the CONFIG_EXTRA_ENV_SETTINGS variable is set before
> applying the default value. This makes it easier for a board to set a
> board specific environment.
> 
> Cc: Michal Simek 
> Signed-off-by: Philip Balister 
> ---
>  include/configs/zynq-common.h | 2 ++
>  1 file changed, 2 insertions(+)

Did you rebase it on the top of latest tree?

I have added this some time ago
"ARM: zynq: Enable option to overwrite default variables"
commit b7b3efe75a46c3d6bff43b7b314d1fff90ca65ec

Thanks,
Michal

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

Re: [U-Boot] Please pull u-boot-x86

[Bin Meng]

On Fri, Apr 22, 2016 at 12:08 PM, Bin Meng  wrote:
> Hi Tom,
>
> The following changes since commit ee8b25fa354da7cfaafe0e6781e873c74c29bbad:
>
>   Prepare v2016.05-rc2 (2016-04-21 09:37:33 -0400)
>
> are available in the git repository at:
>
>   git://git.denx.de/u-boot-x86.git testing
>

Sorry, this should be:

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

Both testing and master point to the same HEAD.

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

[U-Boot] Please pull u-boot-x86

[Bin Meng]

Hi Tom,

The following changes since commit ee8b25fa354da7cfaafe0e6781e873c74c29bbad:

  Prepare v2016.05-rc2 (2016-04-21 09:37:33 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-x86.git testing

for you to fetch changes up to 7b63b1832b6e7671c4009bc084045a19cd86c87c:

  x86: Correct typo of Miao Yan's email address (2016-04-22 11:26:32 +0800)


Bin Meng (2):
  x86: qemu: Drop our own ACPI implementation
  x86: Correct typo of Miao Yan's email address

 arch/x86/cpu/qemu/Makefile |   3 -
 arch/x86/cpu/qemu/acpi.c   | 176
---
 arch/x86/cpu/qemu/acpi/cpu-hotplug.asl |  80 --
 arch/x86/cpu/qemu/acpi/dbug.asl|  25 --
 arch/x86/cpu/qemu/acpi/hpet.asl|  31 ---
 arch/x86/cpu/qemu/acpi/isa.asl | 102 ---
 arch/x86/cpu/qemu/acpi/pci-crs.asl |  61 --
 arch/x86/cpu/qemu/dsdt.asl | 412
--
 arch/x86/cpu/qemu/fw_cfg.c |   2 +-
 9 files changed, 1 insertion(+), 891 deletions(-)
 delete mode 100644 arch/x86/cpu/qemu/acpi.c
 delete mode 100644 arch/x86/cpu/qemu/acpi/cpu-hotplug.asl
 delete mode 100644 arch/x86/cpu/qemu/acpi/dbug.asl
 delete mode 100644 arch/x86/cpu/qemu/acpi/hpet.asl
 delete mode 100644 arch/x86/cpu/qemu/acpi/isa.asl
 delete mode 100644 arch/x86/cpu/qemu/acpi/pci-crs.asl
 delete mode 100644 arch/x86/cpu/qemu/dsdt.asl

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

Re: [U-Boot] [PATCH 1/3] fastboot: Clean up bulk-out logic

[Lukasz Majewski]

On Thu, 21 Apr 2016 19:59:21 -0700
Steve Rae  wrote:

> On Thu, Apr 21, 2016 at 3:03 AM, Lukasz Majewski
>  wrote:
> 
> > Hi Roger,
> >
> > > Just use ep->maxpacket to get the maxpacket size
> > > and simplify the bulk-out maxpacket alignment.
> > >
> > > Signed-off-by: Roger Quadros 
> > > Tested-by: Steve Rae 
> > > ---
> > >  drivers/usb/gadget/f_fastboot.c | 50
> > > +++-- 1 file changed, 23
> > > insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/usb/gadget/f_fastboot.c
> > > b/drivers/usb/gadget/f_fastboot.c index 7961231..28b244a 100644
> > > --- a/drivers/usb/gadget/f_fastboot.c
> > > +++ b/drivers/usb/gadget/f_fastboot.c
> > > @@ -39,6 +39,11 @@
> > >  #define TX_ENDPOINT_MAXIMUM_PACKET_SIZE  (0x0040)
> > >
> > >  #define EP_BUFFER_SIZE   4096
> > > +/*
> > > + * EP_BUFFER_SIZE must always be an integral multiple of
> > > maxpacket size
> > > + * (64 or 512 or 1024), else we break on certain controllers like
> > > DWC3
> > > + * that expect bulk OUT requests to be divisible by maxpacket
> > > size.
> > > + */
> > >
> > >  struct f_fastboot {
> > >   struct usb_function usb_function;
> > > @@ -57,7 +62,6 @@ static struct f_fastboot *fastboot_func;
> > >  static unsigned int fastboot_flash_session_id;
> > >  static unsigned int download_size;
> > >  static unsigned int download_bytes;
> > > -static bool is_high_speed;
> > >
> > >  static struct usb_endpoint_descriptor fs_ep_in = {
> > >   .bLength= USB_DT_ENDPOINT_SIZE,
> > > @@ -269,11 +273,6 @@ static int fastboot_set_alt(struct
> > > usb_function *f, debug("%s: func: %s intf: %d alt: %d\n",
> > > __func__, f->name, interface, alt);
> > >
> > > - if (gadget->speed == USB_SPEED_HIGH)
> > > - is_high_speed = true;
> > > - else
> > > - is_high_speed = false;
> > > -
> > >   d = fb_ep_desc(gadget, _ep_out, _ep_out);
> > >   ret = usb_ep_enable(f_fb->out_ep, d);
> > >   if (ret) {
> > > @@ -455,20 +454,27 @@ static void cb_getvar(struct usb_ep *ep,
> > > struct usb_request *req) fastboot_tx_write_str(response);
> > >  }
> > >
> > > -static unsigned int rx_bytes_expected(unsigned int maxpacket)
> > > +static unsigned int rx_bytes_expected(struct usb_ep *ep)
> > >  {
> > >   int rx_remain = download_size - download_bytes;
> > > - int rem = 0;
> > > - if (rx_remain < 0)
> > > + unsigned int rem;
> > > + unsigned int maxpacket = ep->maxpacket;
> > > +
> > > + if (rx_remain <= 0)
> > >   return 0;
> > > - if (rx_remain > EP_BUFFER_SIZE)
> > > + else if (rx_remain > EP_BUFFER_SIZE)
> > >   return EP_BUFFER_SIZE;
> > > - if (rx_remain < maxpacket) {
> > > - rx_remain = maxpacket;
> > > - } else if (rx_remain % maxpacket != 0) {
> > > - rem = rx_remain % maxpacket;
> > > +
> > > + /*
> > > +  * Some controllers e.g. DWC3 don't like OUT transfers to be
> > > +  * not ending in maxpacket boundary. So just make them happy
> > > by
> > > +  * always requesting for integral multiple of maxpackets.
> > > +  * This shouldn't bother controllers that don't care about
> > > it.
> > > +  */
> > > + rem = rx_remain % maxpacket;
> > > + if (rem > 0)
> > >   rx_remain = rx_remain + (maxpacket - rem);
> > > - }
> > > +
> > >   return rx_remain;
> > >  }
> > >
> > > @@ -480,7 +486,6 @@ static void rx_handler_dl_image(struct usb_ep
> > > *ep, struct usb_request *req) const unsigned char *buffer =
> > > req->buf; unsigned int buffer_size = req->actual;
> > >   unsigned int pre_dot_num, now_dot_num;
> > > - unsigned int max;
> > >
> > >   if (req->status != 0) {
> > >   printf("Bad status: %d\n", req->status);
> > > @@ -518,11 +523,7 @@ static void rx_handler_dl_image(struct usb_ep
> > > *ep, struct usb_request *req)
> > >   printf("\ndownloading of %d bytes finished\n",
> > > download_bytes); } else {
> > > - max = is_high_speed ? hs_ep_out.wMaxPacketSize :
> > > - fs_ep_out.wMaxPacketSize;
> > > - req->length = rx_bytes_expected(max);
> > > - if (req->length < ep->maxpacket)
> > > - req->length = ep->maxpacket;
> > > + req->length = rx_bytes_expected(ep);
> > >   }
> > >
> > >   req->actual = 0;
> > > @@ -533,7 +534,6 @@ static void cb_download(struct usb_ep *ep,
> > > struct usb_request *req) {
> > >   char *cmd = req->buf;
> > >   char response[FASTBOOT_RESPONSE_LEN];
> > > - unsigned int max;
> > >
> > >   strsep(, ":");
> > >   download_size = simple_strtoul(cmd, NULL, 16);
> > > @@ -549,11 +549,7 @@ static void cb_download(struct usb_ep *ep,
> > > struct usb_request *req) } else {
> > >   sprintf(response, "DATA%08x", download_size);
> > 

Re: [U-Boot] [PATCH] x86: qemu: Drop our own ACPI implementation

[Bin Meng]

On Wed, Apr 20, 2016 at 9:13 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 13 April 2016 at 01:52, Bin Meng  wrote:
>> Our own ACPI implementation (when CONFIG_QEMU_ACPI_TABLE is not set)
>> does not build anymore after x86 has been fully converted to DM PCI.
>> Instead of trying to fix the build errors, given we now have the ACPI
>> support via QEMU's fw_cfg interface, which is a more reliable way to
>> generate correct ACPI tables then by ourselves, hence drop our own
>> ACPI implementation.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> arch/x86/cpu/qemu/Makefile | 3 -
>> arch/x86/cpu/qemu/acpi.c | 176 --
>> arch/x86/cpu/qemu/acpi/cpu-hotplug.asl | 80 ---
>> arch/x86/cpu/qemu/acpi/dbug.asl | 25 --
>> arch/x86/cpu/qemu/acpi/hpet.asl | 31 ---
>> arch/x86/cpu/qemu/acpi/isa.asl | 102 
>> arch/x86/cpu/qemu/acpi/pci-crs.asl | 61 -
>> arch/x86/cpu/qemu/dsdt.asl | 412 -
>> 8 files changed, 890 deletions(-)
>> delete mode 100644 arch/x86/cpu/qemu/acpi.c
>> delete mode 100644 arch/x86/cpu/qemu/acpi/cpu-hotplug.asl
>> delete mode 100644 arch/x86/cpu/qemu/acpi/dbug.asl
>> delete mode 100644 arch/x86/cpu/qemu/acpi/hpet.asl
>> delete mode 100644 arch/x86/cpu/qemu/acpi/isa.asl
>> delete mode 100644 arch/x86/cpu/qemu/acpi/pci-crs.asl
>> delete mode 100644 arch/x86/cpu/qemu/dsdt.asl
>
> Reviewed-by: Simon Glass 
>

Added the review tag, and applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] armv8: fsl-layerscape: Remove unnecessary flushing dcache

[Alison Wang]

As the issue about the stack will get corrupted when switching between
the early and final mmu tables is fixed by commit
70e21b06425ad6e1e90931333a704a600941cfff, the workaround to flush dcache
is unnecessary and will be removed.

Signed-off-by: Alison Wang 
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index d939900..9a5a6b5 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -396,9 +396,6 @@ static inline void final_mmu_setup(void)
flush_dcache_range((ulong)level0_table,
   (ulong)level0_table + gd->arch.tlb_size);
 
-#ifdef CONFIG_SYS_DPAA_FMAN
-   flush_dcache_all();
-#endif
/* point TTBR to the new table */
set_ttbr_tcr_mair(el, (u64)level0_table, LAYERSCAPE_TCR_FINAL,
  MEMORY_ATTRIBUTES);
-- 
2.1.0.27.g96db324

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

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

[Huan Wang]

> On 04/18/2016 08:36 PM, Huan Wang wrote:
> > Hi, York,
> >
> >> On 03/28/2016 02:16 PM, Ed Swarthout wrote:
> >>> When switching between the early and final mmu tables, the stack
> >>> will get corrupted if the Non-Secure attribute is different.  For
> >>> ls1043a, this issue is currently masked because flush_dcache_all is
> >>> called before the switch when CONFIG_SYS_DPAA_FMAN is defined.
> >>>
> >>> Signed-off-by: Ed Swarthout 
> >>> ---
> >>>
> >>> Resend to fix diff format.
> >>>
> >>> denx/master with CONFIG_SYS_DPAA_FMAN undefined:
> >>> Fixes:
> >>>
> >>> U-Boot 2016.03-00530-g1fee6de (Mar 28 2016 - 13:46:36 -0500)
> >>> SoC:  LS1043E (0x87920010)
> >>> ...
> >>> Detected UDIMM 18ASF1G72AZ-2G1A1
> >>> 4 GiB (DDR4, 32-bit, CL=11, ECC on)
> >>>DDR Chip-Select Interleaving Mode: CS0+CS1 "Synchronous
> Abort"
> >>> handler, esr 0x8a00
> >>> ELR: deadbeefdeadbeef
> >>> LR:  deadbeefdeadbeef
> >>> x0 : 00ff440c0400 x1 : 00022518
> >>> x2 : 0040 x3 : 003f
> >>> x4 : 0004 x5 : 0001
> >>> x6 : 0009 x7 : 0020
> >>> x8 : 0015 x9 : 000c
> >>> x10: 0401 x11: 0008ffe06000
> >>> x12: 01ff x13: 4000
> >>> x14: 0020 x15: 0001
> >>> x16:  x17: 0002
> >>> x18: ffdd8d78 x19: deadbeefdeadbeef
> >>> x20: deadbeefdeadbeef x21: deadbeefdeadbeef
> >>> x22: deadbeefdeadbeef x23: deadbeefdeadbeef
> >>> x24: deadbeefdeadbeef x25: deadbeefdeadbeef
> >>> x26: deadbeefdeadbeef x27: 
> >>> x28: fff6ca90 x29: deadbeefdeadbeef
> >>>
> >>>
> >>>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 12 
> >>>  1 file changed, 8 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >>> b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >>> index 42ca7df..1f5842a 100644
> >>> --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >>> @@ -159,9 +159,11 @@ static const struct sys_mmu_table
> >> early_mmu_table[] = {
> >>>   { CONFIG_SYS_FSL_IFC_BASE, CONFIG_SYS_FSL_IFC_BASE,
> >>> CONFIG_SYS_FSL_IFC_SIZE, MT_DEVICE_NGNRNE, PTE_BLOCK_NON_SHARE },
> >>>   { CONFIG_SYS_FSL_DRAM_BASE1, CONFIG_SYS_FSL_DRAM_BASE1,
> >>> -   CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
> >>> +   CONFIG_SYS_FSL_DRAM_SIZE1, MT_NORMAL,
> >>> +   PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
> >>>   { CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
> >>> -   CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
> >>> +   CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL,
> >>> +   PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
> >>>  #endif
> >>>  };
> >>>
> >>> @@ -247,7 +249,8 @@ static const struct sys_mmu_table
> >>> final_mmu_table[]
> >> = {
> >>> CONFIG_SYS_FSL_QBMAN_SIZE, MT_DEVICE_NGNRNE,
> >>> PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
> >>>   { CONFIG_SYS_FSL_DRAM_BASE2, CONFIG_SYS_FSL_DRAM_BASE2,
> >>> -   CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
> >>> +   CONFIG_SYS_FSL_DRAM_SIZE2, MT_NORMAL,
> >>> +   PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
> >>>   { CONFIG_SYS_PCIE1_PHYS_ADDR, CONFIG_SYS_PCIE1_PHYS_ADDR,
> >>> CONFIG_SYS_PCIE1_PHYS_SIZE, MT_DEVICE_NGNRNE,
> >>> PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN }, @@ -258,7
> >>> +261,8 @@ static const struct sys_mmu_table final_mmu_table[] = {
> >>> CONFIG_SYS_PCIE3_PHYS_SIZE, MT_DEVICE_NGNRNE,
> >>> PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN },
> >>>   { CONFIG_SYS_FSL_DRAM_BASE3, CONFIG_SYS_FSL_DRAM_BASE3,
> >>> -   CONFIG_SYS_FSL_DRAM_SIZE3, MT_NORMAL, PTE_BLOCK_OUTER_SHARE },
> >>> +   CONFIG_SYS_FSL_DRAM_SIZE3, MT_NORMAL,
> >>> +   PTE_BLOCK_OUTER_SHARE | PTE_BLOCK_NS },
> >>>  #endif
> >>>  };
> >>>  #endif
> >>>
> >>
> >> Alison/Qianyu,
> >>
> >> This change looks right to me. Please see if if flushing can be
> removed.
> >>
> > [Alison Wang] I verified flushing can be removed.
> >
> 
> Thanks. Please submit a patch to remove the unnecessary flushing.
> 
[Alison Wang] Ok, I will send the patch.


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

Re: [U-Boot] [PATCH 3/3] usb: s3c-otg: Fix remaining bytes in debug messages

[Steve Rae]

On Thu, Apr 21, 2016 at 7:49 PM, Steve Rae  wrote:

>
>
> On Thu, Apr 21, 2016 at 3:05 AM, Lukasz Majewski 
> wrote:
>
>> Hi Roger,
>>
>> > Remaining bytes means bytes that are not yet transferred
>> > and not the bytes that were transferred in the last transfer.
>> >
>> > Reported-by: Lukasz Majewski 
>> > Signed-off-by: Roger Quadros 
>> > ---
>> >  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>> > b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c index a31d875..0594c3d
>> > 100644 --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>> > +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
>> > @@ -235,7 +235,7 @@ static void complete_rx(struct dwc2_udc *dev, u8
>> > ep_num) "%s: RX DMA done : ep = %d, rx bytes = %d/%d, "
>> >  "is_short = %d, DOEPTSIZ = 0x%x, remained bytes =
>> > %d\n", __func__, ep_num, req->req.actual, req->req.length,
>> > -is_short, ep_tsr, xfer_size);
>> > +is_short, ep_tsr, req->req.length -
>> > req->req.actual);
>> >   if (is_short || req->req.actual == req->req.length) {
>> >   if (ep_num == EP0_CON && dev->ep0state ==
>> > DATA_STATE_RECV) { @@ -292,7 +292,7 @@ static void complete_tx(struct
>> > dwc2_udc *dev, u8 ep_num) "%s: TX DMA done : ep = %d, tx bytes =
>> > %d/%d, " "is_short = %d, DIEPTSIZ = 0x%x, remained bytes = %d\n",
>> >   __func__, ep_num, req->req.actual, req->req.length,
>> > - is_short, ep_tsr, xfer_size);
>> > + is_short, ep_tsr, req->req.length - req->req.actual);
>> >
>> >   if (ep_num == 0) {
>> >   if (dev->ep0state == DATA_STATE_XMIT) {
>>
>> Acked-by: Lukasz Majewski 
>>
>> Tested-by: Steve Rae 
> [Test HW: bcm28155_ap board]
>
> Thanks, Steve
>

retry because patchworks missed this

Tested-by: Steve Rae 
[Test HW: bcm28155_ap board]



>
>
>> --
>> Best regards,
>>
>> Lukasz Majewski
>>
>> Samsung R Institute Poland (SRPOL) | Linux Platform Group
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] fastboot: Clean up bulk-out logic

[Steve Rae]

On Thu, Apr 21, 2016 at 3:03 AM, Lukasz Majewski 
wrote:

> Hi Roger,
>
> > Just use ep->maxpacket to get the maxpacket size
> > and simplify the bulk-out maxpacket alignment.
> >
> > Signed-off-by: Roger Quadros 
> > Tested-by: Steve Rae 
> > ---
> >  drivers/usb/gadget/f_fastboot.c | 50
> > +++-- 1 file changed, 23
> > insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/f_fastboot.c
> > b/drivers/usb/gadget/f_fastboot.c index 7961231..28b244a 100644
> > --- a/drivers/usb/gadget/f_fastboot.c
> > +++ b/drivers/usb/gadget/f_fastboot.c
> > @@ -39,6 +39,11 @@
> >  #define TX_ENDPOINT_MAXIMUM_PACKET_SIZE  (0x0040)
> >
> >  #define EP_BUFFER_SIZE   4096
> > +/*
> > + * EP_BUFFER_SIZE must always be an integral multiple of maxpacket
> > size
> > + * (64 or 512 or 1024), else we break on certain controllers like
> > DWC3
> > + * that expect bulk OUT requests to be divisible by maxpacket size.
> > + */
> >
> >  struct f_fastboot {
> >   struct usb_function usb_function;
> > @@ -57,7 +62,6 @@ static struct f_fastboot *fastboot_func;
> >  static unsigned int fastboot_flash_session_id;
> >  static unsigned int download_size;
> >  static unsigned int download_bytes;
> > -static bool is_high_speed;
> >
> >  static struct usb_endpoint_descriptor fs_ep_in = {
> >   .bLength= USB_DT_ENDPOINT_SIZE,
> > @@ -269,11 +273,6 @@ static int fastboot_set_alt(struct usb_function
> > *f, debug("%s: func: %s intf: %d alt: %d\n",
> > __func__, f->name, interface, alt);
> >
> > - if (gadget->speed == USB_SPEED_HIGH)
> > - is_high_speed = true;
> > - else
> > - is_high_speed = false;
> > -
> >   d = fb_ep_desc(gadget, _ep_out, _ep_out);
> >   ret = usb_ep_enable(f_fb->out_ep, d);
> >   if (ret) {
> > @@ -455,20 +454,27 @@ static void cb_getvar(struct usb_ep *ep, struct
> > usb_request *req) fastboot_tx_write_str(response);
> >  }
> >
> > -static unsigned int rx_bytes_expected(unsigned int maxpacket)
> > +static unsigned int rx_bytes_expected(struct usb_ep *ep)
> >  {
> >   int rx_remain = download_size - download_bytes;
> > - int rem = 0;
> > - if (rx_remain < 0)
> > + unsigned int rem;
> > + unsigned int maxpacket = ep->maxpacket;
> > +
> > + if (rx_remain <= 0)
> >   return 0;
> > - if (rx_remain > EP_BUFFER_SIZE)
> > + else if (rx_remain > EP_BUFFER_SIZE)
> >   return EP_BUFFER_SIZE;
> > - if (rx_remain < maxpacket) {
> > - rx_remain = maxpacket;
> > - } else if (rx_remain % maxpacket != 0) {
> > - rem = rx_remain % maxpacket;
> > +
> > + /*
> > +  * Some controllers e.g. DWC3 don't like OUT transfers to be
> > +  * not ending in maxpacket boundary. So just make them happy
> > by
> > +  * always requesting for integral multiple of maxpackets.
> > +  * This shouldn't bother controllers that don't care about
> > it.
> > +  */
> > + rem = rx_remain % maxpacket;
> > + if (rem > 0)
> >   rx_remain = rx_remain + (maxpacket - rem);
> > - }
> > +
> >   return rx_remain;
> >  }
> >
> > @@ -480,7 +486,6 @@ static void rx_handler_dl_image(struct usb_ep
> > *ep, struct usb_request *req) const unsigned char *buffer = req->buf;
> >   unsigned int buffer_size = req->actual;
> >   unsigned int pre_dot_num, now_dot_num;
> > - unsigned int max;
> >
> >   if (req->status != 0) {
> >   printf("Bad status: %d\n", req->status);
> > @@ -518,11 +523,7 @@ static void rx_handler_dl_image(struct usb_ep
> > *ep, struct usb_request *req)
> >   printf("\ndownloading of %d bytes finished\n",
> > download_bytes); } else {
> > - max = is_high_speed ? hs_ep_out.wMaxPacketSize :
> > - fs_ep_out.wMaxPacketSize;
> > - req->length = rx_bytes_expected(max);
> > - if (req->length < ep->maxpacket)
> > - req->length = ep->maxpacket;
> > + req->length = rx_bytes_expected(ep);
> >   }
> >
> >   req->actual = 0;
> > @@ -533,7 +534,6 @@ static void cb_download(struct usb_ep *ep, struct
> > usb_request *req) {
> >   char *cmd = req->buf;
> >   char response[FASTBOOT_RESPONSE_LEN];
> > - unsigned int max;
> >
> >   strsep(, ":");
> >   download_size = simple_strtoul(cmd, NULL, 16);
> > @@ -549,11 +549,7 @@ static void cb_download(struct usb_ep *ep,
> > struct usb_request *req) } else {
> >   sprintf(response, "DATA%08x", download_size);
> >   req->complete = rx_handler_dl_image;
> > - max = is_high_speed ? hs_ep_out.wMaxPacketSize :
> > - fs_ep_out.wMaxPacketSize;
> > - req->length = rx_bytes_expected(max);
> > - if (req->length < ep->maxpacket)
> > - req->length = 

Re: [U-Boot] [PATCH 3/3] usb: s3c-otg: Fix remaining bytes in debug messages

[Steve Rae]

On Thu, Apr 21, 2016 at 3:05 AM, Lukasz Majewski 
wrote:

> Hi Roger,
>
> > Remaining bytes means bytes that are not yet transferred
> > and not the bytes that were transferred in the last transfer.
> >
> > Reported-by: Lukasz Majewski 
> > Signed-off-by: Roger Quadros 
> > ---
> >  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> > b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c index a31d875..0594c3d
> > 100644 --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> > +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> > @@ -235,7 +235,7 @@ static void complete_rx(struct dwc2_udc *dev, u8
> > ep_num) "%s: RX DMA done : ep = %d, rx bytes = %d/%d, "
> >  "is_short = %d, DOEPTSIZ = 0x%x, remained bytes =
> > %d\n", __func__, ep_num, req->req.actual, req->req.length,
> > -is_short, ep_tsr, xfer_size);
> > +is_short, ep_tsr, req->req.length -
> > req->req.actual);
> >   if (is_short || req->req.actual == req->req.length) {
> >   if (ep_num == EP0_CON && dev->ep0state ==
> > DATA_STATE_RECV) { @@ -292,7 +292,7 @@ static void complete_tx(struct
> > dwc2_udc *dev, u8 ep_num) "%s: TX DMA done : ep = %d, tx bytes =
> > %d/%d, " "is_short = %d, DIEPTSIZ = 0x%x, remained bytes = %d\n",
> >   __func__, ep_num, req->req.actual, req->req.length,
> > - is_short, ep_tsr, xfer_size);
> > + is_short, ep_tsr, req->req.length - req->req.actual);
> >
> >   if (ep_num == 0) {
> >   if (dev->ep0state == DATA_STATE_XMIT) {
>
> Acked-by: Lukasz Majewski 
>
> Tested-by: Steve Rae 
[Test HW: bcm28155_ap board]

Thanks, Steve


> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R Institute Poland (SRPOL) | Linux Platform Group
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] SAMA5D2 xplained SD/eMMC boot

[Yang, Wenyou]

Hi Marek,

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: 2016年4月21日 10:59
> To: Yang, Wenyou 
> Cc: u-boot@lists.denx.de
> Subject: Re: SAMA5D2 xplained SD/eMMC boot
> 
> On 04/21/2016 04:46 AM, Yang, Wenyou wrote:
> > Hi,
> 
> Hi!
> 
> [...]
> pile of unnecessary email headers redacted.
> [...]
> 
>  Hi!
> 
>  I've been playing around with latest mainline u-boot on sama5d2
>  xplained ultra. I noticed that if I want to boot the board from
>  SD card (SDHCI1), the board will indeed load the SPL from it,
>  but SPL will try to load u-boot.img from eMMC
>  (SDHCI0) and fail, as my eMMC is blank.
> >>>
> >>> Yes, there is some issue to load u-boot.img. I found there is
> >>> something to do on
> >> sdhci.c.
> >>>
> >>> You can try this branch, it should works.
> >>>
> >>> https://github.com/linux4sam/u-boot-at91/commits/u-boot-2016.03-
> >>> at
> >>> 91
> >>
> >> I am not interested in using non-mainline stuff. Do you have any
> >> particular patch/commit which I can refer to ? I do not think
> >> this has anything to do with sdhci.c driver at all, it has to do
> >> with detecting the boot device from which SPL was started and
> >> loading u-boot.img from the same boot device instead of always using
> SDHCI0.
> >
> > I will test the mainline code. I will let you know when I get something.
> 
>  OK.
> 
>  Does the SoC have any sort of register which lists the current boot 
>  device ?
> >>>
> >>> In this SoC, there is not register to list the current boot device.
> >>
> >> And thus, it is not possible to detect at runtime from which device
> >> the SoC booted and thus load u-boot.img from the same device. Correct ?
> >
> > Yes,
> 
> Ha, thanks for confirming.

Sorry, can I correct what I said yesterday? There is a register to list the 
boot information exported by ROMCode.

The boot information is stored in R4 register when the ROMCode jumps to the 
bootstrap. 

Here is the contents definitions R4 on the SAMA5D2 (improved compared to old 
MPUs to take care of IOSet features).

/* bootFrom ID Definitions */
#define BOOT_FROM_KEY   (0xBAu << 24)

#define BOOT_FROM_SPI   (0x0u << 0)
#define BOOT_FROM_MCI   (0x1u << 0)
#define BOOT_FROM_SMC   (0x2u << 0)
#define BOOT_FROM_TWI   (0x3u << 0)
#define BOOT_FROM_QSPI  (0x4u << 0)

/* ID number of the IP from the data sheet */
#define BOOT_FROM_ID0   (0x0u << 4)
#define BOOT_FROM_ID1   (0x1u << 4)
#define BOOT_FROM_ID2   (0x2u << 4)
#define BOOT_FROM_ID3   (0x3u << 4)
#define BOOT_FROM_ID4   (0x4u << 4)

#define BOOT_FROM_ID_Pos4
#define BOOT_FROM_ID_Msk(0xfu << BOOT_FROM_ID_Pos)
#define BOOT_FROM_ID(value) ((BOOT_FROM_ID_Msk & ((value) << 
BOOT_FROM_ID_Pos)))

#define BOOT_FROM_TYPE_SD_OR_AT25   (0x0u << 8)
#define BOOT_FROM_TYPE_MMC_OR_AT45  (0x1u << 8)
#define BOOT_FROM_TYPE_EMMC (0x2u << 8)

/* QSPI serial flashes */
#define BOOT_FROM_TYPE_SPANSION (0x0u << 8)
#define BOOT_FROM_TYPE_MICRON   (0x1u << 8)
#define BOOT_FROM_TYPE_MACRONIX (0x2u << 8)

/* Chip Select or (MCI) Slot identifier used in code by the IP. */
#define BOOT_FROM_CS0   (0x0u << 12) // Slot A
#define BOOT_FROM_CS1   (0x1u << 12) // Slot B
#define BOOT_FROM_CS2   (0x2u << 12) // Slot C
#define BOOT_FROM_CS3   (0x3u << 12) // Slot D
#define BOOT_FROM_CS4   (0x4u << 12)

#define BOOT_FROM_CS_Pos12
#define BOOT_FROM_CS_Msk(0xfu << BOOT_FROM_CS_Pos)
#define BOOT_FROM_CS(value) ((BOOT_FROM_CS_Msk & ((value) << 
BOOT_FROM_CS_Pos)))

#define BOOT_FROM_IOSET_Pos 16
#define BOOT_FROM_IOSET_Msk (0x3u << BOOT_FROM_IOSET_Pos)
#define BOOT_FROM_IOSET(value)   ((BOOT_FROM_IOSET_Msk & ((value) << 
BOOT_FROM_IOSET_Pos)))>>


> [...]
> 
> --
> Best regards,
> Marek Vasut

Sorry for incorrect information before.


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

Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Tom Rini]

On Thu, Apr 21, 2016 at 05:56:11PM -0500, Andreas Dannenberg wrote:
> On Thu, Apr 21, 2016 at 04:27:42PM -0400, Tom Rini wrote:
> > On Thu, Apr 21, 2016 at 01:59:48PM -0500, Andreas Dannenberg wrote:
> > > On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> > > > On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> > > > >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> > > > >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > > > >>>Update the CPU string output so that the device
> > > > >>>type is now included as part of the CPU string that
> > > > >>>is printed as the SPL or u-boot comes up. This update
> > > > >>>adds a suffix of the form "-GP" or "-HS" for production
> > > > >>>devices, so that general purpose (GP) and high security
> > > > >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> > > > >>
> > > > >>When I'm building for AM437x HS and running on the device I don't see
> > > > >>that output. It seems like there is something funny going on with
> > > > >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> > > > >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> > > > >>preloader_console_init() in spl.c, hence the function that prints the
> > > > >>chip-type/rev specifics never gets invoked.
> > > > >
> > > > >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> > > > >I'll get the device name/type output by SPL as expected so that piece
> > > > >works. However this patch's commit message  implies the same should 
> > > > >also
> > > > >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> > > > >hardware at my desk but I looked at some boot logs from our test farms
> > > > >and I also don't see the device ID output by SPL so that may be just 
> > > > >how
> > > > >it currently is implemented generally for AM437* and has nothing to do
> > > > >with the patch discussed here.
> > > > This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> > > > statement "Applies to all OMAP5 variants" in the commit message. The 
> > > > omap4/5
> > > > use in the commit header is because the omap4 cpu.h header file had to 
> > > > be
> > > > updated in order to not break omap4 builds (because those builds DO use 
> > > > this
> > > > hwinit-common.c).
> > > 
> > > Daniel,
> > > thanks for clarifying/confirming my suspicion. Then I'm okay with this 
> > > patch.
> > 
> > Can we do a follow-up that moves this otherwise common code into the
> > rest of the families?
> 
> Hi Tom,
> just to make sure I understand your suggestion correctly, this is about
> a behind the scenes optimization to remove the code duplication we
> currently have in .../asm/arch-omap(4|5)/cpu.h, rather than making the
> CPU string output as part of SPL work on all of our (TI) platforms, yes?

I want as much consolidate and consistency of output as is both feasible
and practical.

-- 
Tom


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

Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Thu, Apr 21, 2016 at 04:27:42PM -0400, Tom Rini wrote:
> On Thu, Apr 21, 2016 at 01:59:48PM -0500, Andreas Dannenberg wrote:
> > On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> > > On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> > > >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> > > >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > > >>>Update the CPU string output so that the device
> > > >>>type is now included as part of the CPU string that
> > > >>>is printed as the SPL or u-boot comes up. This update
> > > >>>adds a suffix of the form "-GP" or "-HS" for production
> > > >>>devices, so that general purpose (GP) and high security
> > > >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> > > >>
> > > >>When I'm building for AM437x HS and running on the device I don't see
> > > >>that output. It seems like there is something funny going on with
> > > >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> > > >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> > > >>preloader_console_init() in spl.c, hence the function that prints the
> > > >>chip-type/rev specifics never gets invoked.
> > > >
> > > >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> > > >I'll get the device name/type output by SPL as expected so that piece
> > > >works. However this patch's commit message  implies the same should also
> > > >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> > > >hardware at my desk but I looked at some boot logs from our test farms
> > > >and I also don't see the device ID output by SPL so that may be just how
> > > >it currently is implemented generally for AM437* and has nothing to do
> > > >with the patch discussed here.
> > > This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> > > statement "Applies to all OMAP5 variants" in the commit message. The 
> > > omap4/5
> > > use in the commit header is because the omap4 cpu.h header file had to be
> > > updated in order to not break omap4 builds (because those builds DO use 
> > > this
> > > hwinit-common.c).
> > 
> > Daniel,
> > thanks for clarifying/confirming my suspicion. Then I'm okay with this 
> > patch.
> 
> Can we do a follow-up that moves this otherwise common code into the
> rest of the families?

Hi Tom,
just to make sure I understand your suggestion correctly, this is about
a behind the scenes optimization to remove the code duplication we
currently have in .../asm/arch-omap(4|5)/cpu.h, rather than making the
CPU string output as part of SPL work on all of our (TI) platforms, yes?

Thanks and Regards,

--
Andreas Dannenberg
Texas Instruments Inc

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

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

[Stephen Warren]

From: Stephen Warren 

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

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

Signed-off-by: Stephen Warren 
---
Note that the cleanup series I sent on Tuesday accidentally depends on
this being applied first. I'd expect this to have higher priority than
the cleanup series and be applied earlier anyway.

 board/nvidia/jetson-tk1/jetson-tk1.c   |  3 +++
 board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h | 12 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/board/nvidia/jetson-tk1/jetson-tk1.c 
b/board/nvidia/jetson-tk1/jetson-tk1.c
index 14f0ce54554e..a66b710cddab 100644
--- a/board/nvidia/jetson-tk1/jetson-tk1.c
+++ b/board/nvidia/jetson-tk1/jetson-tk1.c
@@ -31,6 +31,9 @@ void pinmux_init(void)
 
pinmux_config_drvgrp_table(jetson_tk1_drvgrps,
   ARRAY_SIZE(jetson_tk1_drvgrps));
+
+   pinmux_config_mipipadctrlgrp_table(jetson_tk1_mipipadctrlgrps,
+   ARRAY_SIZE(jetson_tk1_mipipadctrlgrps));
 }
 
 #ifdef CONFIG_PCI_TEGRA
diff --git a/board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h 
b/board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h
index b2b2057e3bd3..00e0cdc4b8c0 100644
--- a/board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h
+++ b/board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h
@@ -276,7 +276,6 @@ static const struct pmux_pingrp_config jetson_tk1_pingrps[] 
= {
PINCFG(CPU_PWR_REQ,CPU,  NORMAL, NORMAL,   OUTPUT,  
DEFAULT, DEFAULT),
PINCFG(PWR_INT_N,  PMI,  UP, TRISTATE, INPUT,   
DEFAULT, DEFAULT),
PINCFG(RESET_OUT_N,RESET_OUT_N,  NORMAL, NORMAL,   INPUT,   
DEFAULT, DEFAULT),
-   PINCFG(OWR,RSVD2,DOWN,   TRISTATE, OUTPUT,  
DEFAULT, NORMAL),
PINCFG(CLK_32K_IN, CLK,  NORMAL, TRISTATE, INPUT,   
DEFAULT, DEFAULT),
PINCFG(JTAG_RTCK,  RTCK, UP, NORMAL,   OUTPUT,  
DEFAULT, DEFAULT),
 };
@@ -296,4 +295,15 @@ static const struct pmux_pingrp_config 
jetson_tk1_pingrps[] = {
 static const struct pmux_drvgrp_config jetson_tk1_drvgrps[] = {
 };
 
+#define MIPIPADCTRLCFG(_grp, _mux) \
+   {   \
+   .grp= PMUX_MIPIPADCTRLGRP_##_grp,   \
+   .func   = PMUX_FUNC_##_mux, \
+   }
+
+static const struct pmux_mipipadctrlgrp_config jetson_tk1_mipipadctrlgrps[] = {
+   /* grp,   mux */
+   MIPIPADCTRLCFG(DSI_B, DSI_B),
+};
+
 #endif /* PINMUX_CONFIG_JETSON_TK1_H */
-- 
2.8.1

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

Re: [U-Boot] [PATCH] ts4800: add CONFIG_SYS_FSL_ERRATUM_ESDHC_A001

[Sebastien Bourdelin]

Hi,
I add Fabio Estevam in the loop as suggested by Marek Vasut on IRC.

On 04/21/2016 01:37 PM, Sebastien Bourdelin wrote:
> This commit fixes the MMC data transactions timeout problem on the
> TS4800.
>
> The changes introduced in the commit e978a31 on the timeout calculation
> for the MMC data transactions has revealed there is something wrong with
> the timeout setting of the eSDHC controller used in the IMX51.
>
> The IMX51 seems to be concerned by this erratum and without this change
> the MMC driver is unable to do any transactions.
>
> Signed-off-by: Sebastien Bourdelin 
> ---
>  include/configs/ts4800.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/configs/ts4800.h b/include/configs/ts4800.h
> index fcc9d80..5e5e4d3 100644
> --- a/include/configs/ts4800.h
> +++ b/include/configs/ts4800.h
> @@ -63,6 +63,8 @@
>  #define CONFIG_FSL_ESDHC
>  #define CONFIG_SYS_FSL_ESDHC_ADDRMMC_SDHC1_BASE_ADDR
>  
> +#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A001
> +
>  #define CONFIG_MMC
>  
>  #define CONFIG_CMD_MMC

The problem we found is related to the DTOCV field in the system control
register of the IMX51's eSDHC controller.  If we set the value 4, 8 or
12 in this DTOCV field the MMC driver is unable to do any data
transactions, we have a timeout (i.e: the DTOE field in the Interrupt
status register of the eSDHC controller is set to 1).
It works with other values, at least i tried with 5, 9, 11, 13 without
having any timeout.

Our guess and because we didn't find any errata related to this issue
for the IMX51 is that this device is impacted by the same problem then
devices MPC83XX and MPC85XX (see the ESDHC-A001 errata in the datasheet:
http://pdf.datasheetarchive.com/indexerfiles/Datasheets-SW1/DSASW0012367.pdf)

Perhaps someone from Freescale can give us more informations.

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

[U-Boot] [PATCH v2] ts4800: update environment to boot with device tree

[Damien Riegel]

This commit updates the environment variables to be able to boot with a
device tree. The expected partition layout on the SD card is:
 - partition 1: type 0xDA, contains u-boot.bin
 - partition 2: type 0xC (fat), contains zImage and device tree
 - partition 3: type 0x83, root filesystem.

Signed-off-by: Damien Riegel 
---
Changes in v2:
 - do not mess with LOADADDR anymore

 include/configs/ts4800.h | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/include/configs/ts4800.h b/include/configs/ts4800.h
index fcc9d80..b369b27 100644
--- a/include/configs/ts4800.h
+++ b/include/configs/ts4800.h
@@ -106,19 +106,28 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
-   "image=uImage\0" \
+   "image=zImage\0" \
+   "fdt_file=imx51-ts4800.dtb\0" \
+   "fdt_addr=0x90fe\0" \
"mmcdev=0\0" \
-   "mmcpart=1\0" \
-   "mmcargs=setenv bootargs root=/dev/mmcblk0p2 rootwait rw\0" \
+   "mmcpart=2\0" \
+   "mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
+   "mmcargs=setenv bootargs root=${mmcroot}\0" \
"addtty=setenv bootargs ${bootargs} console=ttymxc0,${baudrate}\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image};\0" \
+   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs addtty; " \
-"bootm; "
+   "if run loadfdt; then " \
+   "bootz ${loadaddr} - ${fdt_addr}; " \
+   "else " \
+   "echo ERR: cannot load FDT; " \
+   "fi; "
+
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
-- 
2.5.0

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

Re: [U-Boot] [PATCH 17/60] ARM: tegra: move apb_misc.h

[Stephen Warren]

On 04/21/2016 02:59 PM, Simon Glass wrote:

Hi Stephen,

On 20 April 2016 at 15:56, Stephen Warren  wrote:

On 04/20/2016 01:26 PM, Simon Glass wrote:


Hi Stephen,

On 19 April 2016 at 14:58, Stephen Warren  wrote:


From: Stephen Warren 

This header is only needed by code local to mach-tegra/, so move it there
to avoid polluting the global include path.




diff --git a/arch/arm/mach-tegra/tegra20/warmboot_avp.c
b/arch/arm/mach-tegra/tegra20/warmboot_avp.c
index 616358b657be..0ae401c569b6 100644
--- a/arch/arm/mach-tegra/tegra20/warmboot_avp.c
+++ b/arch/arm/mach-tegra/tegra20/warmboot_avp.c
@@ -11,10 +11,10 @@
   #include 
   #include 
   #include 
-#include 
   #include 
   #include 
   #include 
+#include "../apb_misc.h"



Is this really an improvement?



Yes:-P


What's the rationale?



As mentioned in the commit description, the content of the header is only
used by code in arch/arm/mach-tegra/. By moving the header file out of a
directory that's part of the include path, we ensure that code (such as
drivers and core code) can't access the header without explicitly doing
something unusual, which should ring alarm bells. This will help avoid
future additions of code that touches Tegra internals rather than accessing
functionality through standard/generic (or even custom but explicitly
"exported") APIs.


Well if that's what you want, OK.

The ../xxx.h looks odd to me - like a temporary hack. Also if we have
a driver for SoC functionality then it will likely need access to this
stuff. But I can't see a better way to do this, and it does achieve
your goal...

Reviewed-by: Simon Glass 


Thanks.

If we do end up with a "real" driver for this in drivers/xxx/, I would 
hope the register header would move into the same directory along with 
the C file so nothing else could access it, and other code would only 
access those registers by calling functions in the driver, those 
functions being prototyped in some public header file in include/ or 
arch/arm/mach-tegra/include/mach/ depending on whether the API was 
U-Boot-wide or Tegra-specific.


This current patch does mean if we get a driver, we'll have to move the 
header again, but I don't expect that to happen imminently (perhaps 
ever?) for most of the code in arch/arm/mach-tegra, with the possible 
exception of clock/reset/XUSB drivers. Equally, there would be so much 
change involved in converting everything not to access the register 
directly but instead use clean APIs that including a header move as well 
would likely be close to noise.

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

Re: [U-Boot] [PATCH 17/60] ARM: tegra: move apb_misc.h

[Simon Glass]

Hi Stephen,

On 20 April 2016 at 15:56, Stephen Warren  wrote:
> On 04/20/2016 01:26 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 19 April 2016 at 14:58, Stephen Warren  wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> This header is only needed by code local to mach-tegra/, so move it there
>>> to avoid polluting the global include path.
>
>
>>> diff --git a/arch/arm/mach-tegra/tegra20/warmboot_avp.c
>>> b/arch/arm/mach-tegra/tegra20/warmboot_avp.c
>>> index 616358b657be..0ae401c569b6 100644
>>> --- a/arch/arm/mach-tegra/tegra20/warmboot_avp.c
>>> +++ b/arch/arm/mach-tegra/tegra20/warmboot_avp.c
>>> @@ -11,10 +11,10 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> -#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include "../apb_misc.h"
>>
>>
>> Is this really an improvement?
>
>
> Yes:-P
>
>> What's the rationale?
>
>
> As mentioned in the commit description, the content of the header is only
> used by code in arch/arm/mach-tegra/. By moving the header file out of a
> directory that's part of the include path, we ensure that code (such as
> drivers and core code) can't access the header without explicitly doing
> something unusual, which should ring alarm bells. This will help avoid
> future additions of code that touches Tegra internals rather than accessing
> functionality through standard/generic (or even custom but explicitly
> "exported") APIs.

Well if that's what you want, OK.

The ../xxx.h looks odd to me - like a temporary hack. Also if we have
a driver for SoC functionality then it will likely need access to this
stuff. But I can't see a better way to do this, and it does achieve
your goal...

Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Tom Rini]

On Thu, Apr 21, 2016 at 01:59:48PM -0500, Andreas Dannenberg wrote:
> On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> > On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> > >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> > >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > >>>Update the CPU string output so that the device
> > >>>type is now included as part of the CPU string that
> > >>>is printed as the SPL or u-boot comes up. This update
> > >>>adds a suffix of the form "-GP" or "-HS" for production
> > >>>devices, so that general purpose (GP) and high security
> > >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> > >>
> > >>When I'm building for AM437x HS and running on the device I don't see
> > >>that output. It seems like there is something funny going on with
> > >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> > >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> > >>preloader_console_init() in spl.c, hence the function that prints the
> > >>chip-type/rev specifics never gets invoked.
> > >
> > >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> > >I'll get the device name/type output by SPL as expected so that piece
> > >works. However this patch's commit message  implies the same should also
> > >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> > >hardware at my desk but I looked at some boot logs from our test farms
> > >and I also don't see the device ID output by SPL so that may be just how
> > >it currently is implemented generally for AM437* and has nothing to do
> > >with the patch discussed here.
> > This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> > statement "Applies to all OMAP5 variants" in the commit message. The omap4/5
> > use in the commit header is because the omap4 cpu.h header file had to be
> > updated in order to not break omap4 builds (because those builds DO use this
> > hwinit-common.c).
> 
> Daniel,
> thanks for clarifying/confirming my suspicion. Then I'm okay with this patch.

Can we do a follow-up that moves this otherwise common code into the
rest of the families?

-- 
Tom


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

[U-Boot] [PATCH 3/4] ARM: OMAP5: Enable ABB configuration for MM voltage domain

[Nishanth Menon]

Since we setup the voltage and frequency for the MM domain, we *must*
setup the ABB configuration needed for the domain as well. If we do not
do this, kernel configuring just the frequency using the default boot
loader configured voltage can fail on many corner lot units.

Reported-by: Richard Woodruff 
Signed-off-by: Nishanth Menon 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c | 9 +
 arch/arm/cpu/armv7/omap5/hw_data.c | 1 +
 arch/arm/cpu/armv7/omap5/prcm-regs.c   | 4 
 arch/arm/include/asm/arch-omap5/omap.h | 1 +
 arch/arm/include/asm/omap_common.h | 4 
 5 files changed, 19 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 8fe695b992b1..da57b385c922 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -632,6 +632,15 @@ void scale_vcores(struct vcores_data const *vcores)
val = optimize_vcore_voltage(>mm);
do_scale_vcore(vcores->mm.addr, val, vcores->mm.pmic);
 
+   /* Configure MM ABB LDO after scale */
+   abb_setup(vcores->mm.efuse.reg,
+ (*ctrl)->control_wkup_ldovbb_mm_voltage_ctrl,
+ (*prcm)->prm_abbldo_mm_setup,
+ (*prcm)->prm_abbldo_mm_ctrl,
+ (*prcm)->prm_irqstatus_mpu,
+ vcores->mm.abb_tx_done_mask,
+ OMAP_ABB_FAST_OPP);
+
val = optimize_vcore_voltage(>gpu);
do_scale_vcore(vcores->gpu.addr, val, vcores->gpu.pmic);
 
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index a4b31e42e2c3..dfb1df6bce30 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -361,6 +361,7 @@ struct vcores_data omap5430_volts_es2 = {
.mm.value = VDD_MM_ES2,
.mm.addr = SMPS_REG_ADDR_45_IVA,
.mm.pmic = ,
+   .mm.abb_tx_done_mask = OMAP_ABB_MM_TXDONE_MASK,
 };
 
 struct vcores_data dra752_volts = {
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index c55c6af9e566..d126a3223192 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -352,6 +352,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_emif1_sdram_config_ext = 0x4AE0C144,
.control_emif2_sdram_config_ext = 0x4AE0C148,
.control_wkup_ldovbb_mpu_voltage_ctrl   = 0x4AE0C318,
+   .control_wkup_ldovbb_mm_voltage_ctrl= 0x4AE0C314,
.control_padconf_wkup_base  = 0x4AE0C800,
.control_smart1nopmio_padconf_0 = 0x4AE0CDA0,
.control_smart1nopmio_padconf_1 = 0x4AE0CDA4,
@@ -722,6 +723,7 @@ struct prcm_regs const omap5_es2_prcm = {
.cm_l3init_usb_otg_ss1_clkctrl = 0x4a0096f0,
 
/* prm irqstatus regs */
+   .prm_irqstatus_mpu = 0x4ae06010,
.prm_irqstatus_mpu_2 = 0x4ae06014,
 
/* l4 wkup regs */
@@ -751,6 +753,8 @@ struct prcm_regs const omap5_es2_prcm = {
 
.prm_abbldo_mpu_setup = 0x4ae07cdc,
.prm_abbldo_mpu_ctrl = 0x4ae07ce0,
+   .prm_abbldo_mm_setup = 0x4ae07ce4,
+   .prm_abbldo_mm_ctrl = 0x4ae07ce8,
 
/* SCRM stuff, used by some boards */
.scrm_auxclk0 = 0x4ae0a310,
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 1eeb8d5f626f..cfec5b063c21 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -215,6 +215,7 @@ struct s32ktimer {
 
 /* ABB tranxdone mask */
 #define OMAP_ABB_MPU_TXDONE_MASK   (0x1 << 7)
+#define OMAP_ABB_MM_TXDONE_MASK(0x1 << 31)
 
 /* ABB efuse masks */
 #define OMAP5_ABB_FUSE_VSET_MASK   (0x1F << 24)
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index d3e841752844..14c07fab34ab 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -234,6 +234,7 @@ struct prcm_regs {
u32 cm_l3init_usb_otg_ss1_clkctrl;
u32 cm_l3init_usb_otg_ss2_clkctrl;
 
+   u32 prm_irqstatus_mpu;
u32 prm_irqstatus_mpu_2;
 
/* cm2.l4per */
@@ -321,6 +322,8 @@ struct prcm_regs {
u32 prm_vc_cfg_i2c_clk;
u32 prm_abbldo_mpu_setup;
u32 prm_abbldo_mpu_ctrl;
+   u32 prm_abbldo_mm_setup;
+   u32 prm_abbldo_mm_ctrl;
 
u32 cm_div_m4_dpll_core;
u32 cm_div_m5_dpll_core;
@@ -441,6 +444,7 @@ struct omap_sys_ctrl_regs {
u32 control_emif1_sdram_config_ext;
u32 control_emif2_sdram_config_ext;
u32 control_wkup_ldovbb_mpu_voltage_ctrl;
+   u32 control_wkup_ldovbb_mm_voltage_ctrl;
u32 control_smart1nopmio_padconf_0;
u32 control_smart1nopmio_padconf_1;
u32 control_padconf_mode;
-- 
2.8.0

___

[U-Boot] [PATCH 1/4] ARM: OMAP5/DRA7: Get rid of control_std_fuse_opp_vdd_mpu_2

[Nishanth Menon]

This information is already available under vcores->volts.efuse.reg.
There is no reason for duplicating the information since AVS Class 0
definitions are common for OMAP5 and DRA7 and defined with
STD_FUSE_OPP_* macros. This allows a central location of defining
the ABB and voltage definitions especially since they are reused.

This also makes it simpler to prevent mistakes involved when changing
the boot OPP for the device.

Signed-off-by: Nishanth Menon 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c | 4 ++--
 arch/arm/cpu/armv7/omap5/prcm-regs.c   | 2 --
 arch/arm/include/asm/omap_common.h | 1 -
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index cb41055b91e6..27e6871fde86 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -584,7 +584,7 @@ void scale_vcores(struct vcores_data const *vcores)
debug("mpu: %d\n", vcores->mpu.value);
do_scale_vcore(vcores->mpu.addr, vcores->mpu.value, vcores->mpu.pmic);
/* Configure MPU ABB LDO after scale */
-   abb_setup((*ctrl)->control_std_fuse_opp_vdd_mpu_2,
+   abb_setup(vcores->mpu.efuse.reg,
  (*ctrl)->control_wkup_ldovbb_mpu_voltage_ctrl,
  (*prcm)->prm_abbldo_mpu_setup,
  (*prcm)->prm_abbldo_mpu_ctrl,
@@ -621,7 +621,7 @@ void scale_vcores(struct vcores_data const *vcores)
do_scale_vcore(vcores->mpu.addr, val, vcores->mpu.pmic);
 
/* Configure MPU ABB LDO after scale */
-   abb_setup((*ctrl)->control_std_fuse_opp_vdd_mpu_2,
+   abb_setup(vcores->mpu.efuse.reg,
  (*ctrl)->control_wkup_ldovbb_mpu_voltage_ctrl,
  (*prcm)->prm_abbldo_mpu_setup,
  (*prcm)->prm_abbldo_mpu_ctrl,
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index cd289ddd2be3..c55c6af9e566 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -297,7 +297,6 @@ struct prcm_regs const omap5_es1_prcm = {
 
 struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
-   .control_std_fuse_opp_vdd_mpu_2 = 0x4A0021B4,
.control_std_fuse_die_id_0  = 0x4A002200,
.control_std_fuse_die_id_1  = 0x4A002208,
.control_std_fuse_die_id_2  = 0x4A00220C,
@@ -440,7 +439,6 @@ struct omap_sys_ctrl_regs const dra7xx_ctrl = {
.control_srcomp_code_latch  = 0x4A002E84,
.control_ddr_control_ext_0  = 0x4A002E88,
.control_padconf_core_base  = 0x4A003400,
-   .control_std_fuse_opp_vdd_mpu_2 = 0x4A003B20,
.control_port_emif1_sdram_config= 0x4AE0C110,
.control_port_emif1_lpddr2_nvm_config   = 0x4AE0C114,
.control_port_emif2_sdram_config= 0x4AE0C118,
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 8c85f46db6ef..2daa440432c3 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -363,7 +363,6 @@ struct omap_sys_ctrl_regs {
u32 control_core_mac_id_0_hi;
u32 control_core_mac_id_1_lo;
u32 control_core_mac_id_1_hi;
-   u32 control_std_fuse_opp_vdd_mpu_2;
u32 control_phy_power_usb;
u32 control_core_mmr_lock1;
u32 control_core_mmr_lock2;
-- 
2.8.0

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

[U-Boot] [PATCH 2/4] ARM: OMAP5/DRA7: Move ABB TXDONE mask to voltage structure

[Nishanth Menon]

ABB TX_DONE mask will vary depending on ABB module. For example,
3630 never had ABB on IVA domain, while OMAP5 does use ABB on MM domain,
DRA7 has it on all domains with the exception of CORE, RTC.

Hence, move the txdone mask definition over to structure describing
voltage domain.

Signed-off-by: Nishanth Menon 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c | 4 ++--
 arch/arm/cpu/armv7/omap5/hw_data.c | 3 +++
 arch/arm/include/asm/omap_common.h | 2 ++
 board/ti/am57xx/board.c| 1 +
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 27e6871fde86..8fe695b992b1 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -589,7 +589,7 @@ void scale_vcores(struct vcores_data const *vcores)
  (*prcm)->prm_abbldo_mpu_setup,
  (*prcm)->prm_abbldo_mpu_ctrl,
  (*prcm)->prm_irqstatus_mpu_2,
- OMAP_ABB_MPU_TXDONE_MASK,
+ vcores->mpu.abb_tx_done_mask,
  OMAP_ABB_FAST_OPP);
 
/* The .mm member is not used for the DRA7xx */
@@ -626,7 +626,7 @@ void scale_vcores(struct vcores_data const *vcores)
  (*prcm)->prm_abbldo_mpu_setup,
  (*prcm)->prm_abbldo_mpu_ctrl,
  (*prcm)->prm_irqstatus_mpu_2,
- OMAP_ABB_MPU_TXDONE_MASK,
+ vcores->mpu.abb_tx_done_mask,
  OMAP_ABB_FAST_OPP);
 
val = optimize_vcore_voltage(>mm);
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index b69c0d13715a..a4b31e42e2c3 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -352,6 +352,7 @@ struct vcores_data omap5430_volts_es2 = {
.mpu.value = VDD_MPU_ES2,
.mpu.addr = SMPS_REG_ADDR_12_MPU,
.mpu.pmic = ,
+   .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
 
.core.value = VDD_CORE_ES2,
.core.addr = SMPS_REG_ADDR_8_CORE,
@@ -368,6 +369,7 @@ struct vcores_data dra752_volts = {
.mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr   = TPS659038_REG_ADDR_SMPS12,
.mpu.pmic   = ,
+   .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
 
.eve.value  = VDD_EVE_DRA752,
.eve.efuse.reg  = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
@@ -400,6 +402,7 @@ struct vcores_data dra722_volts = {
.mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr   = TPS65917_REG_ADDR_SMPS1,
.mpu.pmic   = ,
+   .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
 
.core.value = VDD_CORE_DRA72x,
.core.efuse.reg = STD_FUSE_OPP_VMIN_CORE_NOM,
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 2daa440432c3..d3e841752844 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -540,6 +540,8 @@ struct volts {
u32 addr;
struct volts_efuse_data efuse;
struct pmic_data *pmic;
+
+   u32 abb_tx_done_mask;
 };
 
 struct vcores_data {
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 17620896130d..2404eb586757 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -221,6 +221,7 @@ struct vcores_data beagle_x15_volts = {
.mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr   = TPS659038_REG_ADDR_SMPS12,
.mpu.pmic   = ,
+   .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
 
.eve.value  = VDD_EVE_DRA752,
.eve.efuse.reg  = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
-- 
2.8.0

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

[U-Boot] [PATCH 4/4] ARM: DRA7: Add ABB setup for all domains

[Nishanth Menon]

ABB should be initialized for all required domains voltage domain
for DRA7: IVA, GPU, EVE in addition to the existing MPU domain. If
we do not do this, kernel configuring just the frequency using the
default boot loader configured voltage can fail on many corner lot
units and has been hard to debug. This specifically is a concern with
DRA7 generation of SoCs since other than VDD_MPU, all other domains
are only permitted to setup the voltages to required OPP only at boot.

Reported-by: Richard Woodruff 
Signed-off-by: Nishanth Menon 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c | 24 
 arch/arm/cpu/armv7/omap5/hw_data.c |  6 ++
 arch/arm/cpu/armv7/omap5/prcm-regs.c   | 10 ++
 arch/arm/include/asm/arch-omap5/omap.h |  3 +++
 arch/arm/include/asm/omap_common.h |  9 +
 board/ti/am57xx/board.c|  3 +++
 6 files changed, 55 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index da57b385c922..ef2ac982171f 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -596,10 +596,34 @@ void scale_vcores(struct vcores_data const *vcores)
 
debug("gpu: %d\n", vcores->gpu.value);
do_scale_vcore(vcores->gpu.addr, vcores->gpu.value, vcores->gpu.pmic);
+   /* Configure GPU ABB LDO after scale */
+   abb_setup(vcores->gpu.efuse.reg,
+ (*ctrl)->control_wkup_ldovbb_gpu_voltage_ctrl,
+ (*prcm)->prm_abbldo_gpu_setup,
+ (*prcm)->prm_abbldo_gpu_ctrl,
+ (*prcm)->prm_irqstatus_mpu,
+ vcores->gpu.abb_tx_done_mask,
+ OMAP_ABB_FAST_OPP);
debug("eve: %d\n", vcores->eve.value);
do_scale_vcore(vcores->eve.addr, vcores->eve.value, vcores->eve.pmic);
+   /* Configure EVE ABB LDO after scale */
+   abb_setup(vcores->eve.efuse.reg,
+ (*ctrl)->control_wkup_ldovbb_eve_voltage_ctrl,
+ (*prcm)->prm_abbldo_eve_setup,
+ (*prcm)->prm_abbldo_eve_ctrl,
+ (*prcm)->prm_irqstatus_mpu,
+ vcores->eve.abb_tx_done_mask,
+ OMAP_ABB_FAST_OPP);
debug("iva: %d\n", vcores->iva.value);
do_scale_vcore(vcores->iva.addr, vcores->iva.value, vcores->iva.pmic);
+   /* Configure IVA ABB LDO after scale */
+   abb_setup(vcores->iva.efuse.reg,
+ (*ctrl)->control_wkup_ldovbb_iva_voltage_ctrl,
+ (*prcm)->prm_abbldo_iva_setup,
+ (*prcm)->prm_abbldo_iva_ctrl,
+ (*prcm)->prm_irqstatus_mpu,
+ vcores->iva.abb_tx_done_mask,
+ OMAP_ABB_FAST_OPP);
/* Might need udelay(1000) here if debug is enabled to see all prints */
 #else
u32 val;
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index dfb1df6bce30..88e8920bad31 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -377,12 +377,14 @@ struct vcores_data dra752_volts = {
.eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.eve.addr   = TPS659038_REG_ADDR_SMPS45,
.eve.pmic   = ,
+   .eve.abb_tx_done_mask = OMAP_ABB_EVE_TXDONE_MASK,
 
.gpu.value  = VDD_GPU_DRA752,
.gpu.efuse.reg  = STD_FUSE_OPP_VMIN_GPU_NOM,
.gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.gpu.addr   = TPS659038_REG_ADDR_SMPS6,
.gpu.pmic   = ,
+   .gpu.abb_tx_done_mask = OMAP_ABB_GPU_TXDONE_MASK,
 
.core.value = VDD_CORE_DRA752,
.core.efuse.reg = STD_FUSE_OPP_VMIN_CORE_NOM,
@@ -395,6 +397,7 @@ struct vcores_data dra752_volts = {
.iva.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.iva.addr   = TPS659038_REG_ADDR_SMPS8,
.iva.pmic   = ,
+   .iva.abb_tx_done_mask = OMAP_ABB_IVA_TXDONE_MASK,
 };
 
 struct vcores_data dra722_volts = {
@@ -420,18 +423,21 @@ struct vcores_data dra722_volts = {
.gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.gpu.addr   = TPS65917_REG_ADDR_SMPS3,
.gpu.pmic   = ,
+   .gpu.abb_tx_done_mask = OMAP_ABB_GPU_TXDONE_MASK,
 
.eve.value  = VDD_EVE_DRA72x,
.eve.efuse.reg  = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
.eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.eve.addr   = TPS65917_REG_ADDR_SMPS3,
.eve.pmic   = ,
+   .eve.abb_tx_done_mask = OMAP_ABB_EVE_TXDONE_MASK,
 
.iva.value  = VDD_IVA_DRA72x,
.iva.efuse.reg  = STD_FUSE_OPP_VMIN_IVA_NOM,
.iva.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.iva.addr   = TPS65917_REG_ADDR_SMPS3,
.iva.pmic   = ,
+   .iva.abb_tx_done_mask = OMAP_ABB_IVA_TXDONE_MASK,
 };
 
 /*
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 

[U-Boot] [PATCH 0/4] ARM: OMAP5/DRA7: Update ABB Configuration for all valid domains

[Nishanth Menon]

Original intent when Adaptive Body Bias(ABB) was supported in
bootloader was two fold:
a) ABB is mandatory for all OMAP5/DRA7 support
b) expectation was that linux kernel/Operating system will setup ABB
and voltage depending on the requirements of the platform.

However, over the last few years, few things changed:
i) DRA7 SoCs do not permit for voltage scaling beyond the bootloader's
initial settings thanks to a few silicon limitations. This implies
that the bootloader has to setup the correct voltage at boot for all
domains. Only the MPU voltage domain is excempt from this rule.
ii) software stack evolution tied up the voltage rails and ABB setup
together for obvious reasons of ABB is fundamentally related to
voltage rail configuration.

As a result of these, Linux and operating system just configures
just the frequency using the default boot loader configured voltage
can fail on many corner lot units and has been hard to debug. This
specifically is a concern with DRA7 generation of SoCs since other
than VDD_MPU, all other domains are only permitted to setup the
voltages to required OPP only at boot.

Given that OMAP5 closely matches DRA7, this series setsup ABB for all
domains consistent with the voltage configuration for all domains that
have need for ABB.

Series is based on v2016.05-rc2
Boot Log:
OMAP5uevm: http://pastebin.ubuntu.com/15971620/
AM572x-X15: http://pastebin.ubuntu.com/15971707/

Nishanth Menon (4):
  ARM: OMAP5/DRA7: Get rid of control_std_fuse_opp_vdd_mpu_2
  ARM: OMAP5/DRA7: Move ABB TXDONE mask to voltage structure
  ARM: OMAP5: Enable ABB configuration for MM voltage domain
  ARM: DRA7: Add ABB setup for all domains

 arch/arm/cpu/armv7/omap-common/clocks-common.c | 41 +++---
 arch/arm/cpu/armv7/omap5/hw_data.c | 10 +++
 arch/arm/cpu/armv7/omap5/prcm-regs.c   | 16 --
 arch/arm/include/asm/arch-omap5/omap.h |  4 +++
 arch/arm/include/asm/omap_common.h | 16 +-
 board/ti/am57xx/board.c|  4 +++
 6 files changed, 84 insertions(+), 7 deletions(-)

-- 
2.8.0

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

[U-Boot] [PATCH] zynq: Allow board specific files to over write CONFIG_EXTRA_ENV_SETTINGS.

[Philip Balister]

The zynq-common.h header file is usually included last in the board specific
header file. Check if the CONFIG_EXTRA_ENV_SETTINGS variable is set before
applying the default value. This makes it easier for a board to set a
board specific environment.

Cc: Michal Simek 
Signed-off-by: Philip Balister 
---
 include/configs/zynq-common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 9ff3df2..ea8b0b0 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -205,6 +205,7 @@
 #endif
 
 /* Default environment */
+#ifndef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"fit_image=fit.itb\0"   \
"load_addr=0x200\0" \
@@ -227,6 +228,7 @@
"load usb 0 ${load_addr} ${fit_image} && " \
"bootm ${load_addr}; fi\0" \
DFU_ALT_INFO
+#endif
 
 #define CONFIG_BOOTCOMMAND "run $modeboot"
 #define CONFIG_BOOTDELAY   3 /* -1 to Disable autoboot */
-- 
2.5.5

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

Re: [U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts

[Tom Rini]

On Thu, Apr 21, 2016 at 01:24:00PM -0500, Allred, Daniel wrote:
> On 4/21/2016 8:40 AM, Tom Rini wrote:
> >On Fri, Apr 15, 2016 at 03:28:07PM +0530, Lokesh Vutla wrote:
> >>
> >>
> >>On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> >>>From: Madan Srinivas 
> >>>
> >>>Adds new defconfig files for AM43xx secure devices.
> >>>These are the same as the non-secure parts, except for
> >>>   CONFIG_TI_SECURE_DEVICE option set to 'y'
> >>>   CONFIG_ISW_ENTRY_ADDR updated for secure images.
> >>>
> >>>Signed-off-by: Daniel Allred 
> >>>Signed-off-by: Madan Srinivas 
> >>>---
> >>>  configs/am43xx_hs_evm_defconfig  | 12 
> >>>  configs/am43xx_hs_evm_ethboot_defconfig  | 11 +++
> >>>  configs/am43xx_hs_evm_qspiboot_defconfig | 10 ++
> >>>  configs/am43xx_hs_evm_rtconly_defconfig  | 12 
> >>
> >>You do not need this defconfig. Also now only DT enabled configs are
> >>accepted. Ill let Tom to comment here.
> >
> >Yes, just like was done for the dra7xa/am57xx HS parts, we need to be
> >doing DM+DT here too.
> >
> So I understand to not create any new defconfigs that are not DM+DT,
> but what happens to these old ones? Are they deprecated? Or does
> someone need to patch/convert them?
> 
> I guess I'll just simplify this to make a single
> am437x_hs_evm_defconfig that mirrors the am437x_gp_evm_defconfig.

So, with Lokesh's series that lets us read FIT images in SPL from most
media forms, we can migrate things like am43xx_evm from non-DM+DT to
DM+DT and still support all of the various EVMs that includes and delete
the single board configs.  We should leverage this as much as possible
also for the HS versions.

-- 
Tom


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

Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> >>>Update the CPU string output so that the device
> >>>type is now included as part of the CPU string that
> >>>is printed as the SPL or u-boot comes up. This update
> >>>adds a suffix of the form "-GP" or "-HS" for production
> >>>devices, so that general purpose (GP) and high security
> >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> >>
> >>When I'm building for AM437x HS and running on the device I don't see
> >>that output. It seems like there is something funny going on with
> >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> >>preloader_console_init() in spl.c, hence the function that prints the
> >>chip-type/rev specifics never gets invoked.
> >
> >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> >I'll get the device name/type output by SPL as expected so that piece
> >works. However this patch's commit message  implies the same should also
> >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> >hardware at my desk but I looked at some boot logs from our test farms
> >and I also don't see the device ID output by SPL so that may be just how
> >it currently is implemented generally for AM437* and has nothing to do
> >with the patch discussed here.
> This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> statement "Applies to all OMAP5 variants" in the commit message. The omap4/5
> use in the commit header is because the omap4 cpu.h header file had to be
> updated in order to not break omap4 builds (because those builds DO use this
> hwinit-common.c).

Daniel,
thanks for clarifying/confirming my suspicion. Then I'm okay with this patch.

Regards,

--
Andreas Dannenberg
Texas Instruments Inc

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

Re: [U-Boot] [PATCH] mx6ul_evk: Remove SPL support

[Fabio Estevam]

On Thu, Apr 21, 2016 at 12:11 PM, Dennis Gilmore  wrote:

> ack, I agree that SPL should be fixed

Yes, I fixed SPL in v2.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts

[Allred, Daniel]

On 4/21/2016 8:40 AM, Tom Rini wrote:

On Fri, Apr 15, 2016 at 03:28:07PM +0530, Lokesh Vutla wrote:



On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:

From: Madan Srinivas 

Adds new defconfig files for AM43xx secure devices.
These are the same as the non-secure parts, except for
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_ISW_ENTRY_ADDR updated for secure images.

Signed-off-by: Daniel Allred 
Signed-off-by: Madan Srinivas 
---
  configs/am43xx_hs_evm_defconfig  | 12 
  configs/am43xx_hs_evm_ethboot_defconfig  | 11 +++
  configs/am43xx_hs_evm_qspiboot_defconfig | 10 ++
  configs/am43xx_hs_evm_rtconly_defconfig  | 12 


You do not need this defconfig. Also now only DT enabled configs are
accepted. Ill let Tom to comment here.


Yes, just like was done for the dra7xa/am57xx HS parts, we need to be
doing DM+DT here too.

So I understand to not create any new defconfigs that are not DM+DT, but 
what happens to these old ones? Are they deprecated? Or does someone 
need to patch/convert them?


I guess I'll just simplify this to make a single am437x_hs_evm_defconfig 
that mirrors the am437x_gp_evm_defconfig.


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

Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Allred, Daniel]

On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:

On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:

On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:

Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.


When I'm building for AM437x HS and running on the device I don't see
that output. It seems like there is something funny going on with
CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
ti_omap4_common.h and ti_omap5_common.h it is not seen by
preloader_console_init() in spl.c, hence the function that prints the
chip-type/rev specifics never gets invoked.


So when I run the patches on actual DRA72x HS and DRA74x HS hardware
I'll get the device name/type output by SPL as expected so that piece
works. However this patch's commit message  implies the same should also
work on AM437x HS which it doesn't. I don't have AM437x non-secure
hardware at my desk but I looked at some boot logs from our test farms
and I also don't see the device ID output by SPL so that may be just how
it currently is implemented generally for AM437* and has nothing to do
with the patch discussed here.
This hwinit-common.c is not used by the AM335x/AM437x parts, hence the 
statement "Applies to all OMAP5 variants" in the commit message. The 
omap4/5 use in the commit header is because the omap4 cpu.h header file 
had to be updated in order to not break omap4 builds (because those 
builds DO use this hwinit-common.c).


Daniel


Madan, please comment/chime-in as needed.


Tested-by: Andreas Dannenberg 

--
Andreas Dannenberg
Texas Instruments Inc



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

[U-Boot] [PATCH] ts4800: update environment to boot with device tree

[Damien Riegel]

This commit updates the environment variables to be able to boot with a
device tree. The expected partition layout on the SD card is:
 - partition 1: type 0xDA, contains u-boot.bin
 - partition 2: type 0xC (fat), contains zImage and device tree
 - partition 3: type 0x83, root filesystem.

Signed-off-by: Damien Riegel 
---
 include/configs/ts4800.h | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/include/configs/ts4800.h b/include/configs/ts4800.h
index fcc9d80..8722797 100644
--- a/include/configs/ts4800.h
+++ b/include/configs/ts4800.h
@@ -102,23 +102,32 @@
 
 #define CONFIG_BOOTDELAY   1
 
-#define CONFIG_LOADADDR0x9100  /* loadaddr env var */
+#define CONFIG_LOADADDR0x90008000  /* loadaddr env var */
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
-   "image=uImage\0" \
+   "image=zImage\0" \
+   "fdt_file=imx51-ts4800.dtb\0" \
+   "fdt_addr=0x9100\0" \
"mmcdev=0\0" \
-   "mmcpart=1\0" \
-   "mmcargs=setenv bootargs root=/dev/mmcblk0p2 rootwait rw\0" \
+   "mmcpart=2\0" \
+   "mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
+   "mmcargs=setenv bootargs root=${mmcroot}\0" \
"addtty=setenv bootargs ${bootargs} console=ttymxc0,${baudrate}\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image};\0" \
+   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs addtty; " \
-"bootm; "
+   "if run loadfdt; then " \
+   "bootz ${loadaddr} - ${fdt_addr}; " \
+   "else " \
+   "echo ERR: cannot load FDT; " \
+   "fi; "
+
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
-- 
2.5.0

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

Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > Update the CPU string output so that the device
> > type is now included as part of the CPU string that
> > is printed as the SPL or u-boot comes up. This update
> > adds a suffix of the form "-GP" or "-HS" for production
> > devices, so that general purpose (GP) and high security
> > (HS) can be distiguished. Applies to all OMAP5 variants.
> 
> When I'm building for AM437x HS and running on the device I don't see
> that output. It seems like there is something funny going on with
> CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> ti_omap4_common.h and ti_omap5_common.h it is not seen by
> preloader_console_init() in spl.c, hence the function that prints the
> chip-type/rev specifics never gets invoked.

So when I run the patches on actual DRA72x HS and DRA74x HS hardware
I'll get the device name/type output by SPL as expected so that piece
works. However this patch's commit message  implies the same should also
work on AM437x HS which it doesn't. I don't have AM437x non-secure
hardware at my desk but I looked at some boot logs from our test farms
and I also don't see the device ID output by SPL so that may be just how
it currently is implemented generally for AM437* and has nothing to do
with the patch discussed here.

Madan, please comment/chime-in as needed.


Tested-by: Andreas Dannenberg 

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ts4800: add CONFIG_SYS_FSL_ERRATUM_ESDHC_A001

[Sebastien Bourdelin]

This commit fixes the MMC data transactions timeout problem on the
TS4800.

The changes introduced in the commit e978a31 on the timeout calculation
for the MMC data transactions has revealed there is something wrong with
the timeout setting of the eSDHC controller used in the IMX51.

The IMX51 seems to be concerned by this erratum and without this change
the MMC driver is unable to do any transactions.

Signed-off-by: Sebastien Bourdelin 
---
 include/configs/ts4800.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/ts4800.h b/include/configs/ts4800.h
index fcc9d80..5e5e4d3 100644
--- a/include/configs/ts4800.h
+++ b/include/configs/ts4800.h
@@ -63,6 +63,8 @@
 #define CONFIG_FSL_ESDHC
 #define CONFIG_SYS_FSL_ESDHC_ADDR  MMC_SDHC1_BASE_ADDR
 
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC_A001
+
 #define CONFIG_MMC
 
 #define CONFIG_CMD_MMC
-- 
2.8.0

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

Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses

[Vincent Siles]

On 21-04-16 15:45:05, york sun wrote:
>I prefer to use void *.
> 
>York

I'm not sure what you mean by "use void *". We need to compute the
address of the registers, so you can't directly use void * as it does not
allow pointer arithmetic. Either you use unsigned char * with full
offset, uint32_t * with offset/sizeof(uint32_t) or the direct mapping
using struct ccsr_scfg * and field access.

Could you elaborate ?

Vincent

> 
>Sent from my phone
> 
> Original Message 
>From: Vincent Siles 
>Sent: Thursday, April 21, 2016 12:53 AM
>To: york sun 
>Subject: Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses
>CC: u-boot@lists.denx.de,Alison Wang 
> 
>Hi !
> 
>On 20-04-16 09:53:32, York Sun wrote:
>> On 04/12/2016 05:28 AM, Vincent Siles wrote:
>> > On the LS102x boards, in order to initialize the ICID values of
>masters,
>> > the dev_stream_id array holds absolute offsets from the base of SCFG.
>> >
>> > In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t
>*
>> > before adding the offset, leading to an invalid address. Casting it to
>> > unsigned char * solves the issue.
>> >
>> > Also minor cosmetic renaming of uint32_t into u32 to be consistent in
>> > the whole file.
>> >
>> > Signed-off-by: Vincent Siles 
>> > ---
>> >
>> >  board/freescale/common/ls102xa_stream_id.c | 6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/board/freescale/common/ls102xa_stream_id.c
>b/board/freescale/common/ls102xa_stream_id.c
>> > index f434269..2a4ef3e 100644
>> > --- a/board/freescale/common/ls102xa_stream_id.c
>> > +++ b/board/freescale/common/ls102xa_stream_id.c
>> > @@ -10,11 +10,11 @@
>> > 
>> >  void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id,
>uint32_t num)
>> >  {
>> > - uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
>> > + unsigned char *scfg = (unsigned char *)CONFIG_SYS_FSL_SCFG_ADDR;
>> >  int i;
>> > 
>> >  for (i = 0; i < num; i++)
>> > - out_be32(scfg + id[i].offset, id[i].stream_id);
>> > + out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
>> >  }
>> > 
>> >  void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int
>size)
>> > @@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct
>liodn_id_table *tbl, int size)
>> >  else
>> >  liodn = tbl[i].id[0];
>> > 
>> > - out_le32((uint32_t *)(tbl[i].reg_offset), liodn);
>> > + out_le32((u32 *)(tbl[i].reg_offset), liodn);
>> >  }
>> >  }
>> >
>>
>> If the size of the pointer is an issue, maybe you ca use "void *"? Can
>you check
>> if "struct ccsr_scfg" should/can be used?
>>
>> York
> 
>By using the 'struct ccsr_scfg' type we won't be able to have the same
>kind of loop. Since the code is board dependent, I'm not sure it really
>matters.
> 
>Here what I would do instead. Tell me which style do you prefer.
> 
>Best,
>Vincent
> 
>---
> 
>diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c
>b/arch/arm/cpu/armv7/ls102xa/soc.c
>index b1b0c71..9c78efc 100644
>--- a/arch/arm/cpu/armv7/ls102xa/soc.c
>+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
>@@ -30,21 +30,21 @@ struct liodn_id_table sec_liodn_tbl[] = {
>SET_SEC_DECO_LIODN_ENTRY(7, 0x10, 0x10),
>};
> 
>-struct smmu_stream_id dev_stream_id[] = {
>- { 0x100, 0x01, "ETSEC MAC1" },
>- { 0x104, 0x02, "ETSEC MAC2" },
>- { 0x108, 0x03, "ETSEC MAC3" },
>- { 0x10c, 0x04, "PEX1" },
>- { 0x110, 0x05, "PEX2" },
>- { 0x114, 0x06, "qDMA" },
>- { 0x118, 0x07, "SATA" },
>- { 0x11c, 0x08, "USB3" },
>- { 0x120, 0x09, "QE" },
>- { 0x124, 0x0a, "eSDHC" },
>- { 0x128, 0x0b, "eMA" },
>- { 0x14c, 0x0c, "2D-ACE" },
>- { 0x150, 0x0d, "USB2" },
>- { 0x18c, 0x0e, "DEBUG" },
>+struct smmu_stream_id dev_stream_id = {
>+ .mac1 = 0x01,
>+ .mac2 = 0x02,
>+ .mac3 = 0x03,
>+ .pex1 = 0x04,
>+ .pex2 = 0x05,
>+ .dma = 0x06,
>+ .sata = 0x07,
>+ .usb3 = 0x08,
>+ .qe = 0x09,
>+ .sdhc = 0x0a,
>+ .adma = 0x0b,
>+ .dcu = 0x0c,
>+ .usb2 = 0x0d,
>+ .debug = 0x0e
>};
> 
>unsigned int get_soc_major_rev(void)
>@@ -131,8 +131,7 @@ int ls102xa_smmu_stream_id_init(void)
>ls1021x_config_caam_stream_id(sec_liodn_tbl,
>  ARRAY_SIZE(sec_liodn_tbl));
> 
>- ls102xa_config_smmu_stream_id(dev_stream_id,
>-   ARRAY_SIZE(dev_stream_id));
>+ ls102xa_config_smmu_stream_id(_stream_id);
> 
>return 0;
>}
>diff --git a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
>b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
>index fa571b3..3815673 100644
>--- 

Re: [U-Boot] [PATCH] pci: tegra: fix DM conversion issues on Tegra20

[Thierry Reding]

On Wed, Apr 20, 2016 at 03:46:50PM -0600, Stephen Warren wrote:
> From: Stephen Warren 
> 
> Tegra20's PCIe controller has a couple of quirks. There are workarounds in
> the driver for these, but they don't work after the DM conversion:
> 
> 1) The PCI_CLASS value is wrong in HW.
> 
> This is worked around in pci_tegra_read_config() by patching up the value
> read from that register. Pre-DM, the PCIe core always read this via a
> 16-bit access to the 16-bit offset 0xa. With DM, 32-bit accesses are used,
> so we need to check for offset 0x8 instead. Mask the offset value back to
> 32-bit alignment to make this work in all cases.
> 
> 2) Accessing devices other than dev 1 causes a data abort.
> 
> Pre-DM, this was worked around in pci_skip_dev(), which the PCIe core code
> called during enumeration while iterating over a bus. The DM PCIe core
> doesn't use this function. Instead, enhance tegra_pcie_conf_address() to
> validate the bdf being accessed, and refuse to access invalid devices.
> Since pci_skip_dev() isn't used, delete it.
> 
> I've also validated that both these WARs are only needed for Tegra20, by
> testing on Tegra30/Cardhu and Tegra124/Jetson TKx. So, compile them in
> conditionally.
> 
> Fixes: e81ca88451cf ("dm: tegra: pci: Convert tegra boards to driver model 
> for PCI")
> Signed-off-by: Stephen Warren 
> ---
>  drivers/pci/pci_tegra.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)

Neat:

Reviewed-by: Thierry Reding 


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

Re: [U-Boot] [PATCH 2/2] video: tegra: refuse to bind to disabled dcs

[Thierry Reding]

On Tue, Apr 19, 2016 at 04:19:30PM -0600, Stephen Warren wrote:
> From: Stephen Warren 
> 
> This prevents the following boot-time message on any board where only the
> first DC is in use, yet the DC's DT node is enabled:
> 
> stdio_add_devices: Video device failed (ret=-22)
> 
> (This happens on at least Harmony, Ventana, and likely any other Tegra20
> board with display enabled other than Seaboard).
> 
> The Tegra DC's DT node represents a display controller. It may itself
> drive an integrated RGB display output, or be used by some other display
> controller such as HDMI. For this reason the DC node itself is not
> enabled/disabled in DT; the DC itself is considered a shared resource, not
> the final (board-specific) display output. The node should instantiate a
> display output driver only if the rgb subnode is enabled. Other output
> drivers are free to use the DC if they are enabled and their DT node
> references the DC's DT node. Adapt the Tegra display drivers' bind()
> routine to only bind to the DC's DT node if the RGB subnode is enabled.
> 
> Now that the display driver does the right thing, remove the workaround
> for this issue from Seaboard's DT file.
> 
> Cc: Thierry Reding 
> Signed-off-by: Stephen Warren 
> ---
> Thierry, I assume this is how the DC nodes are intended to be interpreted?
> It's certainly how the kernel's DT files and driver work, even if by
> accident.

No, it's entirely intentional. The rationale is, as you already hinted
at in the commit message, that the display controllers don't define an
active display output, but rather display outputs (such as RGB) will
request a display controller for use in building the display pipeline.

RGB is a bit of a special case because it's tied to the respective
display controllers (their registers are part of the DC register space)
whereas the other types of output (HDMI, DSI, eDP, ...) can typically
take pixel data from either of the display controllers.

> ---
>  arch/arm/dts/tegra20-seaboard.dts | 4 
>  drivers/video/tegra.c | 7 +++
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/dts/tegra20-seaboard.dts 
> b/arch/arm/dts/tegra20-seaboard.dts
> index eada59073efc..5893d2a3f84e 100644
> --- a/arch/arm/dts/tegra20-seaboard.dts
> +++ b/arch/arm/dts/tegra20-seaboard.dts
> @@ -40,10 +40,6 @@
>   nvidia,panel = <_panel>;
>   };
>   };
> -
> - dc@5424 {
> - status = "disabled";
> - };
>   };
>  
>   /* This is not used in U-Boot, but is expected to be in kernel .dts */
> diff --git a/drivers/video/tegra.c b/drivers/video/tegra.c
> index 7fd10e6af35e..c01809e89e14 100644
> --- a/drivers/video/tegra.c
> +++ b/drivers/video/tegra.c
> @@ -620,6 +620,13 @@ static int tegra_lcd_ofdata_to_platdata(struct udevice 
> *dev)
>  static int tegra_lcd_bind(struct udevice *dev)
>  {
>   struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
> + const void *blob = gd->fdt_blob;
> + int node = dev->of_offset;
> + int rgb;
> +
> + rgb = fdt_subnode_offset(blob, node, "rgb");
> + if ((rgb < 0) || !fdtdec_get_is_enabled(blob, rgb))
> + return -ENODEV;

I'm not intimately familiar with the structure of the display driver in
U-Boot, but it seems like we'd need to conditionalize this depending on
what output the display pipeline uses. I suppose it would be up to its
driver to register a stdio device, while making use of some library code
to configure the display controller. My understanding was from looking
at this a long time ago, that U-Boot only supports RGB output on Tegra20
through Tegra114, and there's a completely separate driver that supports
eDP on Tegra124 (Nyan Big I believe), and presumably that will handle
this entirely differently.

Anyway, this looks like the right fix for RGB outputs (such as on
Seaboard), so:

Acked-by: Thierry Reding 


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

[U-Boot] [PATCH 1/2 v3] powerpc:t4240rdb: Disable the non-existent ethernet ports on T4240RDB

[ying.zhang22455]

From: Ying Zhang 

Disable the non-existent ethernet ports on T4240RDB:FM1_DTSEC5,
FM1_DTSEC6, FM2_DTSEC5 and FM2_DTSEC6.

Signed-off-by: Ying Zhang 
---
[changed from v1]:
--- update the title.
[changed from v2]:
--- update the commit message.

 board/freescale/t4rdb/eth.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/freescale/t4rdb/eth.c b/board/freescale/t4rdb/eth.c
index e563a61..ae2451e 100644
--- a/board/freescale/t4rdb/eth.c
+++ b/board/freescale/t4rdb/eth.c
@@ -77,6 +77,9 @@ int board_eth_init(bd_t *bis)
puts("Invalid SerDes1 protocol for T4240RDB\n");
}
 
+   fm_disable_port(FM1_DTSEC5);
+   fm_disable_port(FM1_DTSEC6);
+
for (i = FM1_DTSEC1; i < FM1_DTSEC1 + CONFIG_SYS_NUM_FM1_DTSEC; i++) {
interface = fm_info_get_enet_if(i);
switch (interface) {
@@ -115,6 +118,8 @@ int board_eth_init(bd_t *bis)
puts("Invalid SerDes2 protocol for T4240RDB\n");
}
 
+   fm_disable_port(FM2_DTSEC5);
+   fm_disable_port(FM2_DTSEC6);
for (i = FM2_DTSEC1; i < FM2_DTSEC1 + CONFIG_SYS_NUM_FM2_DTSEC; i++) {
interface = fm_info_get_enet_if(i);
switch (interface) {
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses

[Vincent Siles]

Hi !

On 20-04-16 09:53:32, York Sun wrote:
> On 04/12/2016 05:28 AM, Vincent Siles wrote:
> > On the LS102x boards, in order to initialize the ICID values of masters,
> > the dev_stream_id array holds absolute offsets from the base of SCFG.
> > 
> > In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t *
> > before adding the offset, leading to an invalid address. Casting it to
> > unsigned char * solves the issue.
> > 
> > Also minor cosmetic renaming of uint32_t into u32 to be consistent in
> > the whole file.
> > 
> > Signed-off-by: Vincent Siles 
> > ---
> > 
> >  board/freescale/common/ls102xa_stream_id.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/board/freescale/common/ls102xa_stream_id.c 
> > b/board/freescale/common/ls102xa_stream_id.c
> > index f434269..2a4ef3e 100644
> > --- a/board/freescale/common/ls102xa_stream_id.c
> > +++ b/board/freescale/common/ls102xa_stream_id.c
> > @@ -10,11 +10,11 @@
> >  
> >  void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num)
> >  {
> > -   uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
> > +   unsigned char *scfg = (unsigned char *)CONFIG_SYS_FSL_SCFG_ADDR;
> > int i;
> >  
> > for (i = 0; i < num; i++)
> > -   out_be32(scfg + id[i].offset, id[i].stream_id);
> > +   out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
> >  }
> >  
> >  void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
> > @@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct liodn_id_table 
> > *tbl, int size)
> > else
> > liodn = tbl[i].id[0];
> >  
> > -   out_le32((uint32_t *)(tbl[i].reg_offset), liodn);
> > +   out_le32((u32 *)(tbl[i].reg_offset), liodn);
> > }
> >  }
> > 
> 
> If the size of the pointer is an issue, maybe you ca use "void *"? Can you 
> check
> if "struct ccsr_scfg" should/can be used?
> 
> York

By using the 'struct ccsr_scfg' type we won't be able to have the same
kind of loop. Since the code is board dependent, I'm not sure it really
matters.

Here what I would do instead. Tell me which style do you prefer.

Best,
Vincent

---

diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c b/arch/arm/cpu/armv7/ls102xa/soc.c
index b1b0c71..9c78efc 100644
--- a/arch/arm/cpu/armv7/ls102xa/soc.c
+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
@@ -30,21 +30,21 @@ struct liodn_id_table sec_liodn_tbl[] = {
SET_SEC_DECO_LIODN_ENTRY(7, 0x10, 0x10),
 };
 
-struct smmu_stream_id dev_stream_id[] = {
-   { 0x100, 0x01, "ETSEC MAC1" },
-   { 0x104, 0x02, "ETSEC MAC2" },
-   { 0x108, 0x03, "ETSEC MAC3" },
-   { 0x10c, 0x04, "PEX1" },
-   { 0x110, 0x05, "PEX2" },
-   { 0x114, 0x06, "qDMA" },
-   { 0x118, 0x07, "SATA" },
-   { 0x11c, 0x08, "USB3" },
-   { 0x120, 0x09, "QE" },
-   { 0x124, 0x0a, "eSDHC" },
-   { 0x128, 0x0b, "eMA" },
-   { 0x14c, 0x0c, "2D-ACE" },
-   { 0x150, 0x0d, "USB2" },
-   { 0x18c, 0x0e, "DEBUG" },
+struct smmu_stream_id dev_stream_id = {
+   .mac1 = 0x01,
+   .mac2 = 0x02,
+   .mac3 = 0x03,
+   .pex1 = 0x04,
+   .pex2 = 0x05,
+   .dma = 0x06,
+   .sata = 0x07,
+   .usb3 = 0x08,
+   .qe = 0x09,
+   .sdhc = 0x0a,
+   .adma = 0x0b,
+   .dcu = 0x0c,
+   .usb2 = 0x0d,
+   .debug = 0x0e
 };
 
 unsigned int get_soc_major_rev(void)
@@ -131,8 +131,7 @@ int ls102xa_smmu_stream_id_init(void)
ls1021x_config_caam_stream_id(sec_liodn_tbl,
  ARRAY_SIZE(sec_liodn_tbl));
 
-   ls102xa_config_smmu_stream_id(dev_stream_id,
- ARRAY_SIZE(dev_stream_id));
+   ls102xa_config_smmu_stream_id(_stream_id);
 
return 0;
 }
diff --git a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h 
b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
index fa571b3..3815673 100644
--- a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
+++ b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
@@ -64,11 +64,22 @@ struct liodn_id_table {
 };
 
 struct smmu_stream_id {
-   uint16_t offset;
-   uint16_t stream_id;
-   char dev_name[32];
+   uint16_t mac1;
+   uint16_t mac2;
+   uint16_t mac3;
+   uint16_t pex1;
+   uint16_t pex2;
+   uint16_t dma;
+   uint16_t sata;
+   uint16_t usb3;
+   uint16_t qe;
+   uint16_t sdhc;
+   uint16_t adma;
+   uint16_t dcu;
+   uint16_t usb2;
+   uint16_t debug;
 };
 
 void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size);
-void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num);
+void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id);
 #endif
diff --git a/board/freescale/common/ls102xa_stream_id.c 
b/board/freescale/common/ls102xa_stream_id.c
index f434269..941f22d 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ 

Re: [U-Boot] [PATCH] x86: qemu: Drop our own ACPI implementation

[Saket Sinha]

Hi Simon,

Do you want me to rework this with DM PCI ?
Regards,
Saket Sinha


On Wed, Apr 20, 2016 at 6:43 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 13 April 2016 at 01:52, Bin Meng  wrote:
>> Our own ACPI implementation (when CONFIG_QEMU_ACPI_TABLE is not set)
>> does not build anymore after x86 has been fully converted to DM PCI.
>> Instead of trying to fix the build errors, given we now have the ACPI
>> support via QEMU's fw_cfg interface, which is a more reliable way to
>> generate correct ACPI tables then by ourselves, hence drop our own
>> ACPI implementation.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> arch/x86/cpu/qemu/Makefile | 3 -
>> arch/x86/cpu/qemu/acpi.c | 176 --
>> arch/x86/cpu/qemu/acpi/cpu-hotplug.asl | 80 ---
>> arch/x86/cpu/qemu/acpi/dbug.asl | 25 --
>> arch/x86/cpu/qemu/acpi/hpet.asl | 31 ---
>> arch/x86/cpu/qemu/acpi/isa.asl | 102 
>> arch/x86/cpu/qemu/acpi/pci-crs.asl | 61 -
>> arch/x86/cpu/qemu/dsdt.asl | 412 -
>> 8 files changed, 890 deletions(-)
>> delete mode 100644 arch/x86/cpu/qemu/acpi.c
>> delete mode 100644 arch/x86/cpu/qemu/acpi/cpu-hotplug.asl
>> delete mode 100644 arch/x86/cpu/qemu/acpi/dbug.asl
>> delete mode 100644 arch/x86/cpu/qemu/acpi/hpet.asl
>> delete mode 100644 arch/x86/cpu/qemu/acpi/isa.asl
>> delete mode 100644 arch/x86/cpu/qemu/acpi/pci-crs.asl
>> delete mode 100644 arch/x86/cpu/qemu/dsdt.asl
>
> Reviewed-by: Simon Glass 
>
> My only concern is that this was supposed to lead to ACPI support for real
> hardware. If you drop this, does it make it harder?
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] U-Boot for Galileo Gen 1 Board

[Pablo Fonovich]

Hi:

I previously worked with u-boot for beaglebone black for booting a custom linux 
system. Now the university got a donnation of some galileo boards, and we want 
to do something similar.

The problem is that we don't know what we need to put into the sd card to make 
the board boot from it... With beaglebone i had to copy the u-boot.img and MLO, 
but is not the same with galileo an we don't know where to find that 
information.


We used galileo_defconfig and instructions in README_x86 for building u-boot, 
but now we do not know how to proceed. Anyone could give me some hints?


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

Re: [U-Boot] [RFC PATCH] gpio: add Tegra186 GPIO driver

[Stephen Warren]

Stephen Warren wrote at Wednesday, April 20, 2016 5:29 PM:
> Tegra186's GPIO controller register layout is significantly different from
> previous chips, so add a new driver for it. In fact, there are two
> different GPIO controllers in Tegra186 that share a similar register
> layout, but very different port mapping. This driver covers both.
> 
> The DT binding is already present in the Linux kernel (FIXME: Validate
> this when submitting).
> FIXME: Add DT binding file to this commit.

Uggh. Ignore this; I formatted the wrong patch to send:-(

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

Re: [U-Boot] U-Boot for Galileo Gen 1 Board

[Pablo Fonovich]

Hi:
Thanks for your answer!
So I must flash the u-boot.Rom in the spi flash, and boot from them, but I 
still can put the rest of the system in the ad and configure u-boot to load 
kernel and device-tree from sd, am I right?
What flashing tool would you recommend me?
Thanks again
Pablo

Enviado desde Outlook Mobile



On Wed, Apr 20, 2016 at 6:01 PM -0700, "Bin Meng" 
> wrote:

Hi Pablo,

On Thu, Apr 21, 2016 at 4:22 AM, Pablo Fonovich  wrote:
> Hi:
>
> I previously worked with u-boot for beaglebone black for booting a custom
> linux system. Now the university got a donnation of some galileo boards, and
> we want to do something similar.
>
> The problem is that we don't know what we need to put into the sd card to
> make the board boot from it... With beaglebone i had to copy the u-boot.img
> and MLO, but is not the same with galileo an we don't know where to find
> that information.
>

You need a SPI flash programmer to burn u-boot.rom into the SPI flash.
Unlike most ARM boards, U-Boot boots directly from reset vector on IA,
thus there is no way to put u-boot.rom on an SD card and let the
processor boot from there.

>
> We used galileo_defconfig and instructions in README_x86 for building
> u-boot, but now we do not know how to proceed. Anyone could give me some
> hints?
>

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

Re: [U-Boot] [PATCH] x86: qemu: Drop our own ACPI implementation

[Saket Sinha]

Hi Stefan/Bin,


>>>
>>> No, the infrastructure is still there. Only the QEMU ASL (manual) part
>>> was removed. I am going to add ACPI support to BayTrail soon
>>> (hopefully).
>>
>>
>> Interesting. This is also on my to-do list. We should definitely
>> coordinate our efforts here. So please keep me updated once you
>> really start here. I'll do the same. :)
>>
>
> Definitely. I plan to ping you before I really start to write anything
> as I remember you did mention ACPI before. I don't want to see any
> duplicated effort :-)
>

 I am planning to resume my ACPI work for Minnowmax and have shared
the Minnowmax ACPI patches (with some issues and which would now be
broken due to DM PCI).

I would need some guidance for this so let me know how we can
co-ordinate on the same.

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

Re: [U-Boot] [PATCH 0/9] Add support for Espresso7420 board

[Alim Akhtar]

Hi Thomas,

On 04/13/2016 04:13 PM, Thomas Abraham wrote:

This patch series add support for Espresso7420 board. This board is
the development/evaluation platform for Exynos7420 SoC. The SoC is
composed of quad Cortex-A57 block, a quad Cortex-A53 block and
various other peripherals. The board includes multiple components
such as the EMMC/Codec and support multiple interconnect interfaces
including HDMI and USB.

The first two patches add Exynos7420 pinctrl driver support which
was initially posted seperatly but now included in this series.
Thanks to Simon Glass and Minkyu Kang for their review. The rest
of the patches add Exynos7420 clock driver support, minor changes
in the S5P serial driver, Exynos7420 SoC support and Espresso7420
board support.

Thomas Abraham (9):
   pinctrl: add the DM_UC_FLAG_SEQ_ALIAS flag for numbering the devices
   pinctrl: Add pinctrl driver support for Exynos7420 SoC
   clk: fixed_rate: allow driver usage prior to relocation
   clk: exynos: add clock driver for Exynos7420 Soc
   serial: s5p: get the port id number from the alias of the device node
   serial: s5p: use clock api to get clock rate
   arm: exynos: realign the code to allow support for newer 64-bit platforms
   arm: exynos: add support for Exynos7420 SoC
   board: samsung: add initial Espresso7420 board support


Thanks for posting this series.
Have tested this series on espresso7420 board.
Feel free to add
Tested-by: Alim Akhtar 


  arch/arm/Kconfig|1 -
  arch/arm/dts/Makefile   |1 +
  arch/arm/dts/exynos7420-espresso7420.dts|   24 +++
  arch/arm/dts/exynos7420.dtsi|   82 ++
  arch/arm/mach-exynos/Kconfig|   25 +++
  arch/arm/mach-exynos/Makefile   |8 +-
  arch/arm/mach-exynos/include/mach/cpu.h |2 +-
  arch/arm/mach-exynos/include/mach/gpio.h|2 +-
  arch/arm/mach-exynos/mmu-arm64.c|   35 
  arch/arm/mach-exynos/soc.c  |   10 ++
  board/samsung/common/board.c|   18 ++-
  board/samsung/espresso7420/Kconfig  |   12 ++
  board/samsung/espresso7420/MAINTAINERS  |5 +
  board/samsung/espresso7420/Makefile |   16 ++
  board/samsung/espresso7420/espresso7420.c   |   16 ++
  configs/espresso7420_defconfig  |8 +
  drivers/clk/Kconfig |1 +
  drivers/clk/Makefile|1 +
  drivers/clk/clk_fixed_rate.c|1 +
  drivers/clk/exynos/Kconfig  |   18 ++
  drivers/clk/exynos/Makefile |9 +
  drivers/clk/exynos/clk-exynos7420.c |  227 +++
  drivers/clk/exynos/clk-pll.c|   35 
  drivers/clk/exynos/clk-pll.h|9 +
  drivers/pinctrl/Kconfig |1 +
  drivers/pinctrl/Makefile|1 +
  drivers/pinctrl/exynos/Kconfig  |   10 ++
  drivers/pinctrl/exynos/Makefile |9 +
  drivers/pinctrl/exynos/pinctrl-exynos.c |  141 +
  drivers/pinctrl/exynos/pinctrl-exynos.h |   77 +
  drivers/pinctrl/exynos/pinctrl-exynos7420.c |  121 ++
  drivers/pinctrl/pinctrl-uclass.c|1 +
  drivers/serial/serial_s5p.c |   17 ++-
  include/configs/espresso7420.h  |   35 
  include/configs/exynos7420-common.h |  117 ++
  include/dt-bindings/clock/exynos7420-clk.h  |  207 
  36 files changed, 1295 insertions(+), 8 deletions(-)
  create mode 100644 arch/arm/dts/exynos7420-espresso7420.dts
  create mode 100644 arch/arm/dts/exynos7420.dtsi
  create mode 100644 arch/arm/mach-exynos/mmu-arm64.c
  create mode 100644 board/samsung/espresso7420/Kconfig
  create mode 100644 board/samsung/espresso7420/MAINTAINERS
  create mode 100644 board/samsung/espresso7420/Makefile
  create mode 100644 board/samsung/espresso7420/espresso7420.c
  create mode 100644 configs/espresso7420_defconfig
  create mode 100644 drivers/clk/exynos/Kconfig
  create mode 100644 drivers/clk/exynos/Makefile
  create mode 100644 drivers/clk/exynos/clk-exynos7420.c
  create mode 100644 drivers/clk/exynos/clk-pll.c
  create mode 100644 drivers/clk/exynos/clk-pll.h
  create mode 100644 drivers/pinctrl/exynos/Kconfig
  create mode 100644 drivers/pinctrl/exynos/Makefile
  create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos.c
  create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos.h
  create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos7420.c
  create mode 100644 include/configs/espresso7420.h
  create mode 100644 include/configs/exynos7420-common.h
  create mode 100644 include/dt-bindings/clock/exynos7420-clk.h





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

[U-Boot] Saving u-boot.env to FAT partition of SDcard

[Adrian Mcgrath]

Hello All

I am in the process of changing U-Boot (v2015.04) to save its environment
variables to the FAT partition of an SDcard instead of saving them to the
boot sector.

I have changed my board header file to:
/* Include the below to write env to fat partition of mmc */
#define CONFIG_ENV_IS_IN_FAT
#if defined(CONFIG_ENV_IS_IN_FAT)
#define CONFIG_ENV_SIZE (8 * 1024)
#define FAT_ENV_INTERFACE   "mmc"
#define FAT_ENV_DEVICE_AND_PART"0:1"
#define FAT_ENV_FILE"uboot.env"
#define CONFIG_FAT_WRITE
#define FAT_ENV_DEVICE 0
#define FAT_ENV_PART 1
#define CONFIG_BOOT_PARTITION_ACCESS
#endif

/* Include the below to write env to mmc (raw) */
/*#define CONFIG_ENV_IS_IN_MMC*/
#if defined(CONFIG_ENV_IS_IN_MMC)
#define CONFIG_ENV_SIZE (8 * 1024)
#define CONFIG_ENV_OFFSET (8 * 64 * 1024)
#endif

U-Boot builds (using Yocto) and runs. I can save the environment and list
the file on the card using "fatls":
=> saveenv
Saving Environment to FAT...
writing uboot.env
done
=> reset
resetting ...

However, on the following boot the file is not read:
U-Boot 2015.04+fslc+g5d9ffd2 (Apr 19 2016 - 11:38:28)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 29C
Reset cause: WDOG
Board: Sw-one
I2C:   ready
DRAM:  1 GiB
Enabling i210
PMIC:  PFUZE100 ID=0x10
NAND:  256 MiB
MMC:   FSL_SDHC: 0
reading uboot.env
Invalid FAT entry
*** Warning - bad CRC, using default environment

  00:01.0 - 16c3:abcd - Bridge device
   01:00.0- 8086:157c - Network controller
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Error: FEC address not set.

Hit any key to stop autoboot:  0
=>

I saw a post reply by Wolfgang (
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/16117) that
suggested formatting the partition using the host machine and then copying
the files back. I have done this (using a Linux host machine) and can
copy/write all the files except u-boot.env which gives me an I/O error.

Given that I can't copy u-boot.env I'm thinking that the binary has not
been created correctly and thus fat_write.c:do_fat_write() needs patching.

I'm sure many users out there have reading/writing the env to FAT partition
working flawlessly, I would welcome any suggestions or a point towards a
relevant patch.

Many thanks

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

Re: [U-Boot] test/py - test OS boot

[Stephen Warren]

On 04/18/2016 07:46 AM, Michal Simek wrote:

Hi Stephen and Simon,

have you thought how to use test/py for testing OS boot?
I am not experienced with python to quickly hack it myself but in
general I think we should support boot till OS (to test OS handoff,
legacy, fit formats, bootm subcommands, go, etc) till certain point and
then do reset and if that pattern is found test should pass.
I was trying to find out a way how to perform reset command and let test
pass.
Is there any way how to do it?


I think you'd want to do something like the following in the test:

try:
orig_to = u_boot_console.p.timeout
# wait_for_prompt=False makes the core code not wait for the U-Boot
# prompt code to be seen, since it won't be on a successful kernel
# boot
u_boot_console.run_command('run bootcmd', wait_for_prompt=False)
u_boot_console.p.timeout = something_long
# You might want to expand wait_for() with options to add extra bad
# patterns which immediately indicate a failed boot, or add a new
# "with object" function u_boot_console.enable_check() that can
# cause extra patterns like the U-Boot console prompt, U-Boot boot
# error messages, kernel boot error messages, etc. to fail the
# wait_for().
u_boot_console.wait_for('login:')
finally:
u_boot_console.p.timeout = orig_to
# This forces the console object to be shutdown, so any subsequent
# test will reset the board back into U-Boot. We want to force this
# no matter whether the kernel boot passed or failed.
u_boot_console.drain_console()
u_boot_console.cleanup_spawn()

You should probably wrap the timeout manipulation into an automatic 
object that you can use with a "with" statement, similar to how 
u_boot_console_base.py's ConsoleDisableCheck class and disable_check() 
function work. That will isolate the logic a bit.


Perhaps the structure of the above logic could be wrapped into a 
function/"with object":


# Shorter variable name just for email wrapping
c = u_boot_console
with c.needs_target_restart_afterwards():
c.run_command('run bootcmd', wait_for_prompt=False)
with c.temporary_timeout(120):
u_boot_console.wait_for('login:')

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

Re: [U-Boot] [PATCH 11/16] spl: build: ti: add support for secure boot images

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:13PM -0500, Daniel Allred wrote:
> Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
> is in use (which it should be when building for secure parts),
> the TI secure development package is used to create a valid
> secure boot image. The u-boot SPL build processes is NOT aware
> of the details of creating the boot image - all of that information
> is encapsulated in the TI secure development package, which is
> available from TI. More info can be found in README.ti-secure
> 
> Right now, two image types are generated, MLO and X-LOADER. The types
> are important, as certain boot modes implemented by the device's ROM
> boot loader require one or the other (they are not equivalent). The
> output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
> u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
> the name that the device ROM bootloader requires for loading from the
> FAT partition of an SD card (same as on non-secure devices).
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Successfully boot-tested the patch on actual DRA72x HS and DRA74x HS
hardware.

Tested-by: Andreas Dannenberg 

--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arc/cache: really do flush_dcache_all() even if IOC exists

[Alexey Brodkin]

Hi,

On Mon, 2016-04-18 at 13:28 +0300, Alexey Brodkin wrote:
> flush_dcache_all() is used in the very end of U-Boot self relocation
> to write back all copied and then patched code and data to their
> new location in the very end of available memory space.
> 
> Since that has nothing to do with IO (i.e. no external DMA happens
> here) IOC won't help here and we need to write back data cache contents
> manually.
> 
> Signed-off-by: Alexey Brodkin 
> ---
>  arch/arc/lib/cache.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arc/lib/cache.c b/arch/arc/lib/cache.c
> index 56988dd..d1fb661 100644
> --- a/arch/arc/lib/cache.c
> +++ b/arch/arc/lib/cache.c
> @@ -430,13 +430,10 @@ void invalidate_dcache_all(void)
>  
>  void flush_dcache_all(void)
>  {
> -#ifdef CONFIG_ISA_ARCV2
> - if (!ioc_exists)
> -#endif
> - __dc_entire_op(OP_FLUSH);
> + __dc_entire_op(OP_FLUSH);
>  
>  #ifdef CONFIG_ISA_ARCV2
> - if (slc_exists && !ioc_exists)
> + if (slc_exists)
>   __slc_entire_op(OP_FLUSH);
>  #endif
>  }

Applied, thanks!

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

[U-Boot] Please pull ARC changes

[Alexey Brodkin]

Hi Tom,

The following changes since commit ee8b25fa354da7cfaafe0e6781e873c74c29bbad:

  Prepare v2016.05-rc2 (2016-04-21 09:37:33 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-arc.git 

for you to fetch changes up to 2a8382c6fe7ddf0e15791b3ffa5f390a674a212b:

  arc/cache: really do flush_dcache_all() even if IOC exists (2016-04-21 
20:09:59 +0300)


Alexey Brodkin (1):
  arc/cache: really do flush_dcache_all() even if IOC exists

 arch/arc/lib/cache.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [RESEND PATCH V3 1/6] dm: gpio: add a default gpio xlate routine

[Stephen Warren]

On 04/20/2016 09:37 AM, Eric Nelson wrote:

Many drivers use a common form of offset + flags for device
tree nodes. e.g.:
< 2 GPIO_ACTIVE_LOW>

This patch adds a common implementation of this type of parsing
and calls it when a gpio driver doesn't supply its' own xlate
routine.

This will allow removal of the driver-specific versions in a
handful of drivers and simplify the addition of new drivers.



diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c



+int gpio_xlate_offs_flags(struct udevice *dev,
+struct gpio_desc *desc,
+struct fdtdec_phandle_args *args)
+{
+   if (args->args_count < 1)
+   return -EINVAL;
+
+   desc->offset = args->args[0];
+
+if (args->args_count < 2)
+   return 0;


Nit: There's an indentation inconsistency there.

Aside from that, the series,
Reviewed-by: Stephen Warren 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 15/60] gpio: tegra: header file split

[Simon Glass]

Hi Stephen,

On 21 April 2016 at 10:40, Stephen Warren  wrote:
> On 04/21/2016 08:11 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 20 April 2016 at 16:01, Stephen Warren  wrote:
>>>
>>> On 04/20/2016 01:26 PM, Simon Glass wrote:


 Hi Stephen,

 On 19 April 2016 at 14:58, Stephen Warren  wrote:
>
>
> From: Stephen Warren 
>
> Tegra's gpio.h contains a mix of private definitions for use inside the
> GPIO driver and custom machine-specific APIs. Move the private
> definitions
> out of the global include directory since nothing should need to access
> them. Move the public definitions to the machine-specific include
> directory .
>>>
>>>
>>>
> diff --git a/drivers/gpio/tegra_gpio_priv.h
> b/drivers/gpio/tegra_gpio_priv.h
>>>
>>>
>>>
> +/*
> + * GPIO registers are split into two chunks; low and high.
> + * On Tegra20, all low chunks appear first, then all high chunks.
> + * In later SoCs, the low and high chunks are interleaved together.
> + */
> +#define GPIO_CTLR_BANK_HIGH_REGS \
> +   uint gpio_masked_config[TEGRA_GPIO_PORTS]; \
> +   uint gpio_masked_dir_out[TEGRA_GPIO_PORTS]; \
> +   uint gpio_masked_out[TEGRA_GPIO_PORTS]; \
> +   uint reserved0[TEGRA_GPIO_PORTS]; \
> +   uint gpio_masked_int_status[TEGRA_GPIO_PORTS]; \
> +   uint gpio_masked_int_enable[TEGRA_GPIO_PORTS]; \
> +   uint gpio_masked_int_level[TEGRA_GPIO_PORTS]; \
> +   uint reserved1[TEGRA_GPIO_PORTS];
> +
> +/* GPIO Controller registers for a single bank */
> +struct gpio_ctlr_bank {
> +   uint gpio_config[TEGRA_GPIO_PORTS];
> +   uint gpio_dir_out[TEGRA_GPIO_PORTS];
> +   uint gpio_out[TEGRA_GPIO_PORTS];
> +   uint gpio_in[TEGRA_GPIO_PORTS];
> +   uint gpio_int_status[TEGRA_GPIO_PORTS];
> +   uint gpio_int_enable[TEGRA_GPIO_PORTS];
> +   uint gpio_int_level[TEGRA_GPIO_PORTS];
> +   uint gpio_int_clear[TEGRA_GPIO_PORTS];
> +#ifndef CONFIG_TEGRA20
> +   GPIO_CTLR_BANK_HIGH_REGS
> +#endif
> +};
> +
> +#ifdef CONFIG_TEGRA20
> +struct gpio_ctlr_bank_high {
> +   GPIO_CTLR_BANK_HIGH_REGS



 This seems a bit ugly. Perhaps you could havestruct
 gpio_ctlr_high_regs and include that here? It adds a level of
 indirection but that doesn't seem very important.
>>>
>>>
>>>
>>> In newer Tegras, there's no differentiation between the two register sets
>>> that were "low" and "high" in Tegra20. I'd rather not saddle the
>>> non-Tegra20
>>> struct layouts with some odd naming/nesting just because the Tegra20
>>> layout
>>> was odd. I don't see any problem with using a #define for this; it
>>> doesn't
>>> seem to make the code complex.
>>
>>
>> OK, well then how about just duplicating the two structs, and dropping
>> the #define?
>>
>> #ifdfef CONFIG_TEGRA20
>> struct gpio_ctlr_bank {
>>
>> };
>> #else
>> struct gpio_ctlr_bank {
>> };
>> #endif
>
>
> Given that the driver doesn't use any registers in the high bank, and indeed
> can't; the driver's reliance on structs rather than register defines means
> that the high bank registers would have to be accessed differently between
> Tegra20 and other SoCs, I propose simply not representing those registers.
> Instead, how about:
>
> struct gpio_ctlr_bank {
> uint gpio_config[TEGRA_GPIO_PORTS];
> uint gpio_dir_out[TEGRA_GPIO_PORTS];
> uint gpio_out[TEGRA_GPIO_PORTS];
> uint gpio_in[TEGRA_GPIO_PORTS];
> uint gpio_int_status[TEGRA_GPIO_PORTS];
> uint gpio_int_enable[TEGRA_GPIO_PORTS];
> uint gpio_int_level[TEGRA_GPIO_PORTS];
> uint gpio_int_clear[TEGRA_GPIO_PORTS];
> #ifndef CONFIG_TEGRA20
> uint unused[TEGRA_GPIO_PORTS * 8];
> #endif
> };
>
> struct gpio_ctlr {
> struct gpio_ctlr_bank gpio_bank[TEGRA_GPIO_BANKS];
> };
>
> That removes all the duplication, without any macros etc.
>
> Does that look reasonable? If I fixup the patch like that, I'll add a brief
> comment describing what the unused registers are, similar to the one in
> patch v1.

SGTM

>
>>> I wonder if we should just convert away from structs for registers
>>> entirely.
>>> Everything in the HW docs is just numbers, matching those to the structs
>>> is
>>> always painful, and if we used #defines instead of structs, representing
>>> this HW difference would end up being much cleaner and avoid using a
>>> macro
>>> to "cut/paste" a register list 2 times; see the way the Linux kernel
>>> driver
>>> handles this.
>>
>>
>> Structs are definitely easier to read and particularly in this case
>> where each struct element is an array.
>
>
> I'm not really sure there's much objective difference between the
> readability of the two. Arrays can easily be abstracted via a macro or
> inline function so 

Re: [U-Boot] [PATCH 15/60] gpio: tegra: header file split

[Stephen Warren]

On 04/21/2016 08:11 AM, Simon Glass wrote:

Hi Stephen,

On 20 April 2016 at 16:01, Stephen Warren  wrote:

On 04/20/2016 01:26 PM, Simon Glass wrote:


Hi Stephen,

On 19 April 2016 at 14:58, Stephen Warren  wrote:


From: Stephen Warren 

Tegra's gpio.h contains a mix of private definitions for use inside the
GPIO driver and custom machine-specific APIs. Move the private
definitions
out of the global include directory since nothing should need to access
them. Move the public definitions to the machine-specific include
directory .




diff --git a/drivers/gpio/tegra_gpio_priv.h
b/drivers/gpio/tegra_gpio_priv.h




+/*
+ * GPIO registers are split into two chunks; low and high.
+ * On Tegra20, all low chunks appear first, then all high chunks.
+ * In later SoCs, the low and high chunks are interleaved together.
+ */
+#define GPIO_CTLR_BANK_HIGH_REGS \
+   uint gpio_masked_config[TEGRA_GPIO_PORTS]; \
+   uint gpio_masked_dir_out[TEGRA_GPIO_PORTS]; \
+   uint gpio_masked_out[TEGRA_GPIO_PORTS]; \
+   uint reserved0[TEGRA_GPIO_PORTS]; \
+   uint gpio_masked_int_status[TEGRA_GPIO_PORTS]; \
+   uint gpio_masked_int_enable[TEGRA_GPIO_PORTS]; \
+   uint gpio_masked_int_level[TEGRA_GPIO_PORTS]; \
+   uint reserved1[TEGRA_GPIO_PORTS];
+
+/* GPIO Controller registers for a single bank */
+struct gpio_ctlr_bank {
+   uint gpio_config[TEGRA_GPIO_PORTS];
+   uint gpio_dir_out[TEGRA_GPIO_PORTS];
+   uint gpio_out[TEGRA_GPIO_PORTS];
+   uint gpio_in[TEGRA_GPIO_PORTS];
+   uint gpio_int_status[TEGRA_GPIO_PORTS];
+   uint gpio_int_enable[TEGRA_GPIO_PORTS];
+   uint gpio_int_level[TEGRA_GPIO_PORTS];
+   uint gpio_int_clear[TEGRA_GPIO_PORTS];
+#ifndef CONFIG_TEGRA20
+   GPIO_CTLR_BANK_HIGH_REGS
+#endif
+};
+
+#ifdef CONFIG_TEGRA20
+struct gpio_ctlr_bank_high {
+   GPIO_CTLR_BANK_HIGH_REGS



This seems a bit ugly. Perhaps you could havestruct
gpio_ctlr_high_regs and include that here? It adds a level of
indirection but that doesn't seem very important.



In newer Tegras, there's no differentiation between the two register sets
that were "low" and "high" in Tegra20. I'd rather not saddle the non-Tegra20
struct layouts with some odd naming/nesting just because the Tegra20 layout
was odd. I don't see any problem with using a #define for this; it doesn't
seem to make the code complex.


OK, well then how about just duplicating the two structs, and dropping
the #define?

#ifdfef CONFIG_TEGRA20
struct gpio_ctlr_bank {

};
#else
struct gpio_ctlr_bank {
};
#endif


Given that the driver doesn't use any registers in the high bank, and 
indeed can't; the driver's reliance on structs rather than register 
defines means that the high bank registers would have to be accessed 
differently between Tegra20 and other SoCs, I propose simply not 
representing those registers. Instead, how about:


struct gpio_ctlr_bank {
uint gpio_config[TEGRA_GPIO_PORTS];
uint gpio_dir_out[TEGRA_GPIO_PORTS];
uint gpio_out[TEGRA_GPIO_PORTS];
uint gpio_in[TEGRA_GPIO_PORTS];
uint gpio_int_status[TEGRA_GPIO_PORTS];
uint gpio_int_enable[TEGRA_GPIO_PORTS];
uint gpio_int_level[TEGRA_GPIO_PORTS];
uint gpio_int_clear[TEGRA_GPIO_PORTS];
#ifndef CONFIG_TEGRA20
uint unused[TEGRA_GPIO_PORTS * 8];
#endif
};

struct gpio_ctlr {
struct gpio_ctlr_bank gpio_bank[TEGRA_GPIO_BANKS];
};

That removes all the duplication, without any macros etc.

Does that look reasonable? If I fixup the patch like that, I'll add a 
brief comment describing what the unused registers are, similar to the 
one in patch v1.



I wonder if we should just convert away from structs for registers entirely.
Everything in the HW docs is just numbers, matching those to the structs is
always painful, and if we used #defines instead of structs, representing
this HW difference would end up being much cleaner and avoid using a macro
to "cut/paste" a register list 2 times; see the way the Linux kernel driver
handles this.


Structs are definitely easier to read and particularly in this case
where each struct element is an array.


I'm not really sure there's much objective difference between the 
readability of the two. Arrays can easily be abstracted via a macro or 
inline function so that the call site looks essentially identical; () vs [].



Why are you worried about code duplication in a header file?


I'm not sure why I would special case my concerns and ignore duplication 
in certain locations yet still care about duplication in general or 
elsewhere?

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

Re: [U-Boot] [PATCH 2/2] armv8: s32v234: Introduce basic support for s32v234evb

[Tom Rini]

On Thu, Apr 21, 2016 at 06:03:26PM +0200, Eddy Petrișor wrote:
> Pe 19 apr. 2016 6:53 p.m., "Tom Rini"  a scris:
> >
> > On Sun, Apr 03, 2016 at 03:10:06AM +0300, Eddy Petrișor wrote:
> >
> > > Add initial support for NXP's S32V234 SoC and S32V234EVB board.
> > >
> > > The S32V230 family is designed to support computation-intensive
> applications
> > > for image processing. The S32V234, as part of the S32V230 family, is a
> > > high-performance automotive processor designed to support safe
> > > computation-intensive applications in the area of vision and sensor
> fusion.
> > >
> > > Code originally writen by:
> > > Original-signed-off-by: Stoica Cosmin-Stefan <
> cosminstefan.sto...@freescale.com>
> > > Original-signed-off-by: Mihaela Martinas  >
> > > Original-signed-off-by: Eddy Petrișor 
> > >
> > > Signed-off-by: Eddy Petrișor 
> >
> > Interesting, thanks for the contribution.
> 
> I am trying to make our vendor branch less divergent from mainline, so most
> of the todo-s and '#if 0'-s are due to squashing of existing old commits
> from our vendor repository, sorry for the unclean code due to this.

Good to know, thanks.

> > Some comments:
> >
> > [snip]
> > > +#ifndef CONFIG_SYS_DCACHE_OFF
> > > +
> > > +#define CONFIG_SYS_FSL_IRAM_BASE0x3e80UL
> > > +#define CONFIG_SYS_FSL_IRAM_SIZE0x80UL
> > > +#define CONFIG_SYS_FSL_DRAM_BASE1   0x8000UL
> > > +#define CONFIG_SYS_FSL_DRAM_SIZE1   0x4000UL
> > > +#define CONFIG_SYS_FSL_DRAM_BASE2   0xC000UL
> > > +#define CONFIG_SYS_FSL_DRAM_SIZE2   0x2000UL
> > > +#define CONFIG_SYS_FSL_PERIPH_BASE  0x4000UL
> > > +#define CONFIG_SYS_FSL_PERIPH_SIZE  0x4000UL
> >
> > We shouldn't use CONFIG_SYS here as it's not a config option.
> 
> What other way of defining these should we use? Should we simply put this
> kind of defines in a board or SoC specific header?

Yes. some SoC header (since this is unlikely to be board specific).

[snip]
> > > +U_BOOT_CMD(clocks, CONFIG_SYS_MAXARGS, 1, do_s32v234_showclocks,
> > > +"display clocks", "");
> >
> > And we're trying to not have commands in places other than cmd/
> 
> OK, I'll look for a matching command it remove it for now. It was only for
> debug purposes added at this stage of the support.

It's also possible to just drop debug things like that :)

[snip]
> > > +void reset_cpu(ulong addr)
> > > +{
> > > +#if 0/* b46902 */
> > > + struct src *src_regs = (struct src *)SRC_BASE_ADDR;
> > > +
> > > + /* Generate a SW reset from SRC SCR register */
> > > + writel(SRC_SCR_SW_RST, _regs->scr);
> > > +
> > > + /* If we get there, we are not in good shape */
> > > + mdelay(1000);
> > > + printf("FATAL: Reset Failed!\n");
> > > + hang();
> > > +#endif
> > > +};
> >
> > Here and elsewhere, we should drop if 0'd code.  Can we not really do a
> > reset?
> 
> The code was added at a later point, so for rebasing and synchronisation
> reasons I prefer to insert it in later patches, too.
> 
> I'll try to see if I can easily cherry pick the code, but I doubt it, since
> there was some major refactoring of the code in our vendor branch when
> support for other boards was added.
> 
> If I can't, I'll put a message there so it says the feature is not yet
> supported. Is that OK, or should I simply leave it empty?

I'm OK with a message as a last resort.

[snip]
> > [snip]
> > > diff --git a/board/freescale/s32v234evb/lpddr2.c
> b/board/freescale/s32v234evb/lpddr2.c
> > > new file mode 100644
> > > index 000..0bd5183
> > > --- /dev/null
> > > +++ b/board/freescale/s32v234evb/lpddr2.c
> >
> > This file, and a few other things too possibly, feel more like SoC
> > specific things rather than board specific things.  Further, especially
> > for the DDR parts, can we leverage arch/arm/cpu/armv7/mx6/ddr.c perhaps
> > here? And move it into drivers/ddr/imx/ ?
> 
> Actually, depending on the board we might use ddr2 or ddr3.
> 
> I don't know how I should refer the armv7 files from this armv8 config. Are
> there any examples in the code where I could see am example?
> 
> Also I'll have to check if i.mx6 code matches what we have on s32v234.

So, if we can (and I suspect we can), we would move the armv7 code out
of arch/arm/cpu/armv7/ and into drivers/dd/imx/ and that would make
access easy for both :)  It will require some research on your end but I
strongly suspect the IP block was updated and re-used so there should be
a great deal of overlap.

[snip]
> > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> > > index ea5f4bf..d564022 100644
> > > --- a/drivers/mmc/fsl_esdhc.c
> > > +++ b/drivers/mmc/fsl_esdhc.c
> > > @@ -182,7 +182,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct
> mmc_data *data)
> > >   int timeout;
> > >   struct fsl_esdhc_cfg *cfg = mmc->priv;
> > >   

Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses

[York Sun]

On 04/21/2016 08:56 AM, Vincent Siles wrote:
> On 21-04-16 15:45:05, york sun wrote:
>>I prefer to use void *.
>>
>>York
> 
> I'm not sure what you mean by "use void *". We need to compute the
> address of the registers, so you can't directly use void * as it does not
> allow pointer arithmetic. Either you use unsigned char * with full
> offset, uint32_t * with offset/sizeof(uint32_t) or the direct mapping
> using struct ccsr_scfg * and field access.
> 
> Could you elaborate ?

The reason of your change is (u32 *) + int doesn't yield the correct offset. So
you fix it with (u8 *) + int. I was suggesting to use (void *) + int. Of course
you need to cast to (u32 *) before using out_be32.

York


> 
> Vincent
> 
>>
>>Sent from my phone
>>
>> Original Message 
>>From: Vincent Siles 
>>Sent: Thursday, April 21, 2016 12:53 AM
>>To: york sun 
>>Subject: Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses
>>CC: u-boot@lists.denx.de,Alison Wang 
>>
>>Hi !
>>
>>On 20-04-16 09:53:32, York Sun wrote:
>>> On 04/12/2016 05:28 AM, Vincent Siles wrote:
>>> > On the LS102x boards, in order to initialize the ICID values of
>>masters,
>>> > the dev_stream_id array holds absolute offsets from the base of SCFG.
>>> >
>>> > In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t
>>*
>>> > before adding the offset, leading to an invalid address. Casting it to
>>> > unsigned char * solves the issue.
>>> >
>>> > Also minor cosmetic renaming of uint32_t into u32 to be consistent in
>>> > the whole file.
>>> >
>>> > Signed-off-by: Vincent Siles 
>>> > ---
>>> >
>>> >  board/freescale/common/ls102xa_stream_id.c | 6 +++---
>>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/board/freescale/common/ls102xa_stream_id.c
>>b/board/freescale/common/ls102xa_stream_id.c
>>> > index f434269..2a4ef3e 100644
>>> > --- a/board/freescale/common/ls102xa_stream_id.c
>>> > +++ b/board/freescale/common/ls102xa_stream_id.c
>>> > @@ -10,11 +10,11 @@
>>> > 
>>> >  void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id,
>>uint32_t num)
>>> >  {
>>> > - uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
>>> > + unsigned char *scfg = (unsigned char *)CONFIG_SYS_FSL_SCFG_ADDR;
>>> >  int i;
>>> > 
>>> >  for (i = 0; i < num; i++)
>>> > - out_be32(scfg + id[i].offset, id[i].stream_id);
>>> > + out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
>>> >  }
>>> > 
>>> >  void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int
>>size)
>>> > @@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct
>>liodn_id_table *tbl, int size)
>>> >  else
>>> >  liodn = tbl[i].id[0];
>>> > 
>>> > - out_le32((uint32_t *)(tbl[i].reg_offset), liodn);
>>> > + out_le32((u32 *)(tbl[i].reg_offset), liodn);
>>> >  }
>>> >  }
>>> >
>>>
>>> If the size of the pointer is an issue, maybe you ca use "void *"? Can
>>you check
>>> if "struct ccsr_scfg" should/can be used?
>>>
>>> York
>>
>>By using the 'struct ccsr_scfg' type we won't be able to have the same
>>kind of loop. Since the code is board dependent, I'm not sure it really
>>matters.
>>
>>Here what I would do instead. Tell me which style do you prefer.
>>
>>Best,
>>Vincent
>>
>>---
>>
>>diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c
>>b/arch/arm/cpu/armv7/ls102xa/soc.c
>>index b1b0c71..9c78efc 100644
>>--- a/arch/arm/cpu/armv7/ls102xa/soc.c
>>+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
>>@@ -30,21 +30,21 @@ struct liodn_id_table sec_liodn_tbl[] = {
>>SET_SEC_DECO_LIODN_ENTRY(7, 0x10, 0x10),
>>};
>>
>>-struct smmu_stream_id dev_stream_id[] = {
>>- { 0x100, 0x01, "ETSEC MAC1" },
>>- { 0x104, 0x02, "ETSEC MAC2" },
>>- { 0x108, 0x03, "ETSEC MAC3" },
>>- { 0x10c, 0x04, "PEX1" },
>>- { 0x110, 0x05, "PEX2" },
>>- { 0x114, 0x06, "qDMA" },
>>- { 0x118, 0x07, "SATA" },
>>- { 0x11c, 0x08, "USB3" },
>>- { 0x120, 0x09, "QE" },
>>- { 0x124, 0x0a, "eSDHC" },
>>- { 0x128, 0x0b, "eMA" },
>>- { 0x14c, 0x0c, "2D-ACE" },
>>- { 0x150, 0x0d, "USB2" },
>>- { 0x18c, 0x0e, "DEBUG" },
>>+struct smmu_stream_id dev_stream_id = {
>>+ .mac1 = 0x01,
>>+ .mac2 = 0x02,
>>+ .mac3 = 0x03,
>>+ .pex1 = 0x04,
>>+ .pex2 = 0x05,
>>+ .dma = 0x06,
>>+ .sata = 0x07,
>>+ .usb3 = 0x08,
>>+ .qe = 0x09,
>>+ .sdhc = 0x0a,
>>+ .adma = 0x0b,
>>+ .dcu = 0x0c,
>>+ .usb2 = 0x0d,
>>+ .debug = 0x0e
>>};
>>
>>unsigned int get_soc_major_rev(void)
>>@@ -131,8 +131,7 @@ int ls102xa_smmu_stream_id_init(void)
>>ls1021x_config_caam_stream_id(sec_liodn_tbl,

Re: [U-Boot] [PATCH] travis: turn off dtc unit address warnings

[Tom Rini]

On Thu, Apr 21, 2016 at 04:11:25PM +0200, Heiko Schocher wrote:
> Hello Tom,
> 
> Am 21.04.2016 um 15:53 schrieb Tom Rini:
> >On Thu, Apr 21, 2016 at 03:50:28PM +0200, Marek Vasut wrote:
> >>On 04/21/2016 03:35 PM, Simon Glass wrote:
> >>>Hi,
> >>>
> >>>On 21 April 2016 at 07:25, Marek Vasut  wrote:
> On 04/21/2016 03:17 PM, Heiko Schocher wrote:
> >Hello Marek,
> >
> >Am 21.04.2016 um 14:51 schrieb Marek Vasut:
> >>On 04/21/2016 02:48 PM, Heiko Schocher wrote:
> >>>suppress a lot of
> >>>"reg or ranges property, but no unit name" warnings,
> >>>through the dtc compiler flag "-Wno-unit_address_vs_reg".
> >>>
> >>>If all DTS are fixed, we can remove this flag again.
> >>>
> >>>Signed-off-by: Heiko Schocher 
> >>>---
> >>>There is also a solution to suppress warnings from
> >>>the dtc compiler by the "-q" flag, but that would
> >>>suppress all warnings. Not realy what I want.
> >>
> >>Yep
> >>
> >>>With this patch and patch:
> >>>http://patchwork.ozlabs.org/patch/609150/
> >>>
> >>>travis build passes, see:
> >>>https://travis-ci.org/hsdenx/u-boot/builds/124723016
> >>>
> >>>
> >>>   arch/arc/dts/Makefile| 2 ++
> >>>   arch/arm/dts/Makefile| 3 ++-
> >>>   arch/microblaze/dts/Makefile | 2 ++
> >>>   arch/mips/dts/Makefile   | 3 ++-
> >>>   arch/nios2/dts/Makefile  | 2 ++
> >>>   arch/powerpc/dts/Makefile| 2 ++
> >>>   arch/sandbox/dts/Makefile| 2 ++
> >>>   arch/x86/dts/Makefile| 2 ++
> >>>   8 files changed, 16 insertions(+), 2 deletions(-)
> >>
> >>Isn't there some common place in scripts/ or so where we can disable
> >>this warning using an one-liner ?
> >
> >I don;t know ... but I prefer to disable this per arch .. so we can
> >enable the check back if one arch is fixed ...
> 
> In my opinion, we should stick to the same behavior Linux does.
> Ccing a few more people.
> >>>
> >>>Wouldn't it be better to fix the problems?
> >>
> >>My impression was that these warnings are just the result of
> >>over-eagerness of DTC, that's why Linux prints them only if you
> >>increase the W= (warning) verbosity. I might be wrong tho.
> >
> >They are minor problems.  For the vast majority of the dts files we
> >have, the fixes will come in via re-syncs with the kernel and in at
> >least some cases it's not just a simple regex but also "oh, lets give
> >things better names".  With respect to dts files that we really do own
> >(ie x86) yes, we should fix them.
> 
> So, this patch from me could be still an option?
> 
> http://patchwork.ozlabs.org/patch/610866/
> 
> (at least for the sandbox fixes?)
> (I have a v2 where I worked in the comments from Bin ...)

Yes, but I want to make sure we think about the renames and aren't
trying to silence the warning.  I'm sorry but the MIPS "fixes" have me
leery of other blind changes.

-- 
Tom


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

Re: [U-Boot] [PATCH] common/dlmalloc.c: Delete content that was moved to malloc.h

[Tom Rini]

On Thu, Apr 21, 2016 at 07:35:55AM -0400, Robert P. J. Day wrote:

> 
> Remove several hundred lines of content surrounded by:
> 
> #if 0  /* Moved to malloc.h */
> ... moved stuff ...
> #endif /* 0 */ /* Moved to malloc.h */
> 
> Signed-off-by: Robert P. J. Day 
> 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 1/3] tests: py: dfu: Add variables to store dfu alt numbers for test and dummy files

[Stephen Warren]

On 04/21/2016 09:40 AM, Lukasz Majewski wrote:

This patch replaces hardcoded (i.e. 0 and 1) values passed to dfu_{read|write}
with variables.


The series,
Acked-by: Stephen Warren 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] armv8: s32v234: Introduce basic support for s32v234evb

[Eddy Petrișor]

Pe 19 apr. 2016 6:53 p.m., "Tom Rini"  a scris:
>
> On Sun, Apr 03, 2016 at 03:10:06AM +0300, Eddy Petrișor wrote:
>
> > Add initial support for NXP's S32V234 SoC and S32V234EVB board.
> >
> > The S32V230 family is designed to support computation-intensive
applications
> > for image processing. The S32V234, as part of the S32V230 family, is a
> > high-performance automotive processor designed to support safe
> > computation-intensive applications in the area of vision and sensor
fusion.
> >
> > Code originally writen by:
> > Original-signed-off-by: Stoica Cosmin-Stefan <
cosminstefan.sto...@freescale.com>
> > Original-signed-off-by: Mihaela Martinas 
> > Original-signed-off-by: Eddy Petrișor 
> >
> > Signed-off-by: Eddy Petrișor 
>
> Interesting, thanks for the contribution.

I am trying to make our vendor branch less divergent from mainline, so most
of the todo-s and '#if 0'-s are due to squashing of existing old commits
from our vendor repository, sorry for the unclean code due to this.

> Some comments:
>
> [snip]
> > +#ifndef CONFIG_SYS_DCACHE_OFF
> > +
> > +#define CONFIG_SYS_FSL_IRAM_BASE0x3e80UL
> > +#define CONFIG_SYS_FSL_IRAM_SIZE0x80UL
> > +#define CONFIG_SYS_FSL_DRAM_BASE1   0x8000UL
> > +#define CONFIG_SYS_FSL_DRAM_SIZE1   0x4000UL
> > +#define CONFIG_SYS_FSL_DRAM_BASE2   0xC000UL
> > +#define CONFIG_SYS_FSL_DRAM_SIZE2   0x2000UL
> > +#define CONFIG_SYS_FSL_PERIPH_BASE  0x4000UL
> > +#define CONFIG_SYS_FSL_PERIPH_SIZE  0x4000UL
>
> We shouldn't use CONFIG_SYS here as it's not a config option.

What other way of defining these should we use? Should we simply put this
kind of defines in a board or SoC specific header?

>
> [snip]
> > +++ b/arch/arm/cpu/armv8/s32v234/generic.c
> [snip]
> > +#ifdef CONFIG_FSL_ESDHC
> > +DECLARE_GLOBAL_DATA_PTR;
> > +#endif
>
> No need to guard this.

OK, will remove the guard, maybe it was a temporary workaround until the SD
support was ready and I failed to pick the clean up, too.

>
> [snip]
> > +/* Dump some core clocks */
> > +int do_s32v234_showclocks(cmd_tbl_t * cmdtp, int flag, int argc,
> > +   char *const argv[])
> > +{
> > +#if 0/* Disable until the clock code
will updated for S32V234 */
>
> We should probably remove this then..

Will do.

> > +U_BOOT_CMD(clocks, CONFIG_SYS_MAXARGS, 1, do_s32v234_showclocks,
> > +"display clocks", "");
>
> And we're trying to not have commands in places other than cmd/

OK, I'll look for a matching command it remove it for now. It was only for
debug purposes added at this stage of the support.

>
> > +#ifdef CONFIG_FEC_MXC
> > +void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
> > +{
> > +#if 0/* b46902 */
> > + struct ocotp_regs *ocotp = (struct
[...]
> > + mac[5] = value;
> > +#endif
> > +}
> > +#endif
>
> If the FEC stuff doesn't work yet, lets just leave it out.

OK.

>
> > +void reset_cpu(ulong addr)
> > +{
> > +#if 0/* b46902 */
> > + struct src *src_regs = (struct src *)SRC_BASE_ADDR;
> > +
> > + /* Generate a SW reset from SRC SCR register */
> > + writel(SRC_SCR_SW_RST, _regs->scr);
> > +
> > + /* If we get there, we are not in good shape */
> > + mdelay(1000);
> > + printf("FATAL: Reset Failed!\n");
> > + hang();
> > +#endif
> > +};
>
> Here and elsewhere, we should drop if 0'd code.  Can we not really do a
> reset?

The code was added at a later point, so for rebasing and synchronisation
reasons I prefer to insert it in later patches, too.

I'll try to see if I can easily cherry pick the code, but I doubt it, since
there was some major refactoring of the code in our vendor branch when
support for other boards was added.

If I can't, I'll put a message there so it says the feature is not yet
supported. Is that OK, or should I simply leave it empty?

>
> > diff --git a/arch/arm/include/asm/arch-s32v234/mc_me_regs.h
b/arch/arm/include/asm/arch-s32v234/mc_me_regs.h
> > new file mode 100644
> > index 000..4313140
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-s32v234/mc_me_regs.h
> > @@ -0,0 +1,212 @@
> > +/*
> > + * Copyright 2015 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
>
> Here and anywhere else that was missed, please use SPDX tags.

Sorry, I missed this, I'll make a script to detect all remaining non-SPDX
copyright headers.

>
> [snip]
> > diff --git a/board/freescale/s32v234evb/lpddr2.c
b/board/freescale/s32v234evb/lpddr2.c
> > new file mode 100644
> > index 000..0bd5183
> > --- /dev/null
> > 

Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses

[york sun]

I prefer to use void *.

York

Sent from my phone


 Original Message 
From: Vincent Siles 
Sent: Thursday, April 21, 2016 12:53 AM
To: york sun 
Subject: Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses
CC: u-boot@lists.denx.de,Alison Wang 


Hi !

On 20-04-16 09:53:32, York Sun wrote:
> On 04/12/2016 05:28 AM, Vincent Siles wrote:
> > On the LS102x boards, in order to initialize the ICID values of masters,
> > the dev_stream_id array holds absolute offsets from the base of SCFG.
> >
> > In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t *
> > before adding the offset, leading to an invalid address. Casting it to
> > unsigned char * solves the issue.
> >
> > Also minor cosmetic renaming of uint32_t into u32 to be consistent in
> > the whole file.
> >
> > Signed-off-by: Vincent Siles 
> > ---
> >
> >  board/freescale/common/ls102xa_stream_id.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/board/freescale/common/ls102xa_stream_id.c 
> > b/board/freescale/common/ls102xa_stream_id.c
> > index f434269..2a4ef3e 100644
> > --- a/board/freescale/common/ls102xa_stream_id.c
> > +++ b/board/freescale/common/ls102xa_stream_id.c
> > @@ -10,11 +10,11 @@
> >
> >  void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num)
> >  {
> > - uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
> > + unsigned char *scfg = (unsigned char *)CONFIG_SYS_FSL_SCFG_ADDR;
> >  int i;
> >
> >  for (i = 0; i < num; i++)
> > - out_be32(scfg + id[i].offset, id[i].stream_id);
> > + out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
> >  }
> >
> >  void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
> > @@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct liodn_id_table 
> > *tbl, int size)
> >  else
> >  liodn = tbl[i].id[0];
> >
> > - out_le32((uint32_t *)(tbl[i].reg_offset), liodn);
> > + out_le32((u32 *)(tbl[i].reg_offset), liodn);
> >  }
> >  }
> >
>
> If the size of the pointer is an issue, maybe you ca use "void *"? Can you 
> check
> if "struct ccsr_scfg" should/can be used?
>
> York

By using the 'struct ccsr_scfg' type we won't be able to have the same
kind of loop. Since the code is board dependent, I'm not sure it really
matters.

Here what I would do instead. Tell me which style do you prefer.

Best,
Vincent

---

diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c b/arch/arm/cpu/armv7/ls102xa/soc.c
index b1b0c71..9c78efc 100644
--- a/arch/arm/cpu/armv7/ls102xa/soc.c
+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
@@ -30,21 +30,21 @@ struct liodn_id_table sec_liodn_tbl[] = {
SET_SEC_DECO_LIODN_ENTRY(7, 0x10, 0x10),
};

-struct smmu_stream_id dev_stream_id[] = {
- { 0x100, 0x01, "ETSEC MAC1" },
- { 0x104, 0x02, "ETSEC MAC2" },
- { 0x108, 0x03, "ETSEC MAC3" },
- { 0x10c, 0x04, "PEX1" },
- { 0x110, 0x05, "PEX2" },
- { 0x114, 0x06, "qDMA" },
- { 0x118, 0x07, "SATA" },
- { 0x11c, 0x08, "USB3" },
- { 0x120, 0x09, "QE" },
- { 0x124, 0x0a, "eSDHC" },
- { 0x128, 0x0b, "eMA" },
- { 0x14c, 0x0c, "2D-ACE" },
- { 0x150, 0x0d, "USB2" },
- { 0x18c, 0x0e, "DEBUG" },
+struct smmu_stream_id dev_stream_id = {
+ .mac1 = 0x01,
+ .mac2 = 0x02,
+ .mac3 = 0x03,
+ .pex1 = 0x04,
+ .pex2 = 0x05,
+ .dma = 0x06,
+ .sata = 0x07,
+ .usb3 = 0x08,
+ .qe = 0x09,
+ .sdhc = 0x0a,
+ .adma = 0x0b,
+ .dcu = 0x0c,
+ .usb2 = 0x0d,
+ .debug = 0x0e
};

unsigned int get_soc_major_rev(void)
@@ -131,8 +131,7 @@ int ls102xa_smmu_stream_id_init(void)
ls1021x_config_caam_stream_id(sec_liodn_tbl,
  ARRAY_SIZE(sec_liodn_tbl));

- ls102xa_config_smmu_stream_id(dev_stream_id,
-   ARRAY_SIZE(dev_stream_id));
+ ls102xa_config_smmu_stream_id(_stream_id);

return 0;
}
diff --git a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h 
b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
index fa571b3..3815673 100644
--- a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
+++ b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
@@ -64,11 +64,22 @@ struct liodn_id_table {
};

struct smmu_stream_id {
- uint16_t offset;
- uint16_t stream_id;
- char dev_name[32];
+ uint16_t mac1;
+ uint16_t mac2;
+ uint16_t mac3;
+ uint16_t pex1;
+ uint16_t pex2;
+ uint16_t dma;
+ uint16_t sata;
+ uint16_t usb3;
+ uint16_t qe;
+ uint16_t sdhc;
+ uint16_t adma;
+ uint16_t dcu;
+ uint16_t usb2;
+ uint16_t debug;
};

void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size);
-void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num);
+void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id);
#endif
diff --git a/board/freescale/common/ls102xa_stream_id.c 
b/board/freescale/common/ls102xa_stream_id.c
index f434269..941f22d 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ b/board/freescale/common/ls102xa_stream_id.c
@@ -7,14 +7,25 @@
#include 
#include 
#include 
+#include 

-void ls102xa_config_smmu_stream_id(struct 

[U-Boot] [PATCH v3 1/3] tests: py: dfu: Add variables to store dfu alt numbers for test and dummy files

[Lukasz Majewski]

This patch replaces hardcoded (i.e. 0 and 1) values passed to dfu_{read|write}
with variables.

Signed-off-by: Lukasz Majewski 
---
Changes for v3:
- Replace per module global variables with ones defined inside a function
Changes for v2:
- None
---
 test/py/tests/test_dfu.py | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py
index 093e8d0..2e6cd7b 100644
--- a/test/py/tests/test_dfu.py
+++ b/test/py/tests/test_dfu.py
@@ -99,6 +99,10 @@ def test_dfu(u_boot_console, env__usb_dev_port, 
env__dfu_config):
 Nothing.
 """
 
+# Default alt settings for test and dummy files
+alt_setting_test_file = 0
+alt_setting_dummy_file = 1
+
 def start_dfu():
 """Start U-Boot's dfu shell command.
 
@@ -229,15 +233,15 @@ def test_dfu(u_boot_console, env__usb_dev_port, 
env__dfu_config):
 
 u_boot_console.log.action('Writing test data to DFU primary ' +
 'altsetting')
-dfu_write(0, test_f.abs_fn)
+dfu_write(alt_setting_test_file, test_f.abs_fn)
 
 u_boot_console.log.action('Writing dummy data to DFU secondary ' +
 'altsetting to clear DFU buffers')
-dfu_write(1, dummy_f.abs_fn)
+dfu_write(alt_setting_dummy_file, dummy_f.abs_fn)
 
 u_boot_console.log.action('Reading DFU primary altsetting for ' +
 'comparison')
-dfu_read(0, readback_fn)
+dfu_read(alt_setting_test_file, readback_fn)
 
 u_boot_console.log.action('Comparing written and read data')
 written_hash = test_f.content_hash
@@ -266,7 +270,7 @@ def test_dfu(u_boot_console, env__usb_dev_port, 
env__dfu_config):
 
 u_boot_console.log.action(
 'Overwriting DFU primary altsetting with dummy data')
-dfu_write(0, dummy_f.abs_fn)
+dfu_write(alt_setting_test_file, dummy_f.abs_fn)
 
 for size in sizes:
 with u_boot_console.log.section('Data size %d' % size):
-- 
2.0.0.rc2

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

[U-Boot] [PATCH v3 3/3] tests: py: dfu: Provide functionality to set test and dummy files alt settings

[Lukasz Majewski]

After concatenation of "dfu_alt_info" variable from "dfu_alt_boot" and
"dfu_alt_system" it may happen that test and dummy files alt settings
are different than default 0 and 1.

This patch provides the ability to set different values for them.

Signed-off-by: Lukasz Majewski 
---
Changes for v3:
- replace variables declarations with ones read from configuration file
- remove not necessary str() conversion at DFU host command generation

Changes for v2:
- generate "alt_info" automatically
- use file names as alt settings instead of numerical values
- extend in-code documentation
---
 test/py/tests/test_dfu.py | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py
index 0442af8..8649d87 100644
--- a/test/py/tests/test_dfu.py
+++ b/test/py/tests/test_dfu.py
@@ -30,6 +30,13 @@ env__usb_dev_ports = (
 },
 )
 
+# Optional entries (required only when "alt_id_test_file" and
+# "alt_id_dummy_file" are specified).
+test_file_name = "/dfu_test.bin"
+dummy_file_name = "/dfu_dummy.bin"
+# Above files are used to generate proper "alt_info" entry
+"alt_info": "/%s ext4 0 2;/%s ext4 0 2" % (test_file_name, dummy_file_name),
+
 env__dfu_configs = (
 # eMMC, partition 1
 {
@@ -52,6 +59,16 @@ env__dfu_configs = (
 # $dfu_alt_info, each time the dfu command is run, by concatenating
 # $dfu_alt_boot and $dfu_alt_system.
 "alt_info_env_name": "dfu_alt_system",
+# This value is optional.
+# For boards which require the "test file" alt setting number other 
than
+# default (0) it is possible to specify exact file name to be used as
+# this parameter.
+"alt_id_test_file": test_file_name,
+# This value is optional.
+# For boards which require the "dummy file" alt setting number other
+# than default (1) it is possible to specify exact file name to be used
+# as this parameter.
+"alt_id_dummy_file": dummy_file_name,
 },
 )
 
@@ -107,10 +124,6 @@ def test_dfu(u_boot_console, env__usb_dev_port, 
env__dfu_config):
 Nothing.
 """
 
-# Default alt settings for test and dummy files
-alt_setting_test_file = 0
-alt_setting_dummy_file = 1
-
 def start_dfu():
 """Start U-Boot's dfu shell command.
 
@@ -188,7 +201,7 @@ def test_dfu(u_boot_console, env__usb_dev_port, 
env__dfu_config):
 Nothing.
 """
 
-cmd = ['dfu-util', '-a', str(alt_setting), up_dn_load_arg, fn]
+cmd = ['dfu-util', '-a', alt_setting, up_dn_load_arg, fn]
 if 'host_usb_port_path' in env__usb_dev_port:
 cmd += ['-p', env__usb_dev_port['host_usb_port_path']]
 u_boot_utils.run_and_log(u_boot_console, cmd)
@@ -276,6 +289,9 @@ def test_dfu(u_boot_console, env__usb_dev_port, 
env__dfu_config):
 dummy_f = u_boot_utils.PersistentRandomFile(u_boot_console,
 'dfu_dummy.bin', 1024)
 
+alt_setting_test_file = env__dfu_config.get('alt_id_test_file', '0')
+alt_setting_dummy_file = env__dfu_config.get('alt_id_dummy_file', '1')
+
 ignore_cleanup_errors = True
 try:
 start_dfu()
-- 
2.0.0.rc2

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

[U-Boot] [PATCH v3 2/3] tests: py: dfu: Add functionality to set different u-boot's dfu env variable

[Lukasz Majewski]

By default (on almost all systems) the dfu env variable, which defines
available alt settings, is named as "dfu_alt_info".

However on some platforms (i.e. Odroid XU3), the 'dfu_alt_info' is concatenated
from other variables - namely 'dfu_alt_boot' and 'dfu_alt_system' at run time
(when one types 'dfu 0 mmc 0' for first time).

'dfu_alt_boot' describes alt settings which depend on boot medium - for example
boot loader's LBA sectors which are different on eMMC and SD card because of 
e.g.
MBR/GPT.

'dfu_alt_system' describes board agnostic alt settings - like rootfs, kernel.
On such system we can only append/modify this env variable.

Because of the above, we must have way to modify other than "dfu_ale_info"
variable to perform tests.

Signed-off-by: Lukasz Majewski 

---
Changes for v3:
- None

Changes for v2:
- Rewrite of "alt_info_env_name" variable description
- Use of get() method on python's dictionary to easily obtain default
  value
---
 test/py/tests/test_dfu.py | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/test/py/tests/test_dfu.py b/test/py/tests/test_dfu.py
index 2e6cd7b..0442af8 100644
--- a/test/py/tests/test_dfu.py
+++ b/test/py/tests/test_dfu.py
@@ -44,6 +44,14 @@ env__dfu_configs = (
 # configurations, but don't want to test every single transfer size
 # on each, to avoid bloating the overall time taken by testing.
 "test_sizes": (63, 64, 65),
+# This value is optional.
+# The name of the environment variable that the the dfu command reads
+# alt info from. If unspecified, this defaults to dfu_alt_info, which 
is
+# valid for most systems. Some systems use a different variable name.
+# One example is the Odroid XU3,  which automatically generates
+# $dfu_alt_info, each time the dfu command is run, by concatenating
+# $dfu_alt_boot and $dfu_alt_system.
+"alt_info_env_name": "dfu_alt_system",
 },
 )
 
@@ -124,7 +132,11 @@ def test_dfu(u_boot_console, env__usb_dev_port, 
env__dfu_config):
 u_boot_console.log.action(
 'Starting long-running U-Boot dfu shell command')
 
-cmd = 'setenv dfu_alt_info "%s"' % env__dfu_config['alt_info']
+dfu_alt_info_env = env__dfu_config.get('alt_info_env_name', \
+  'dfu_alt_info')
+
+cmd = 'setenv "%s" "%s"' % (dfu_alt_info_env,
+env__dfu_config['alt_info'])
 u_boot_console.run_command(cmd)
 
 cmd = 'dfu 0 ' + env__dfu_config['cmd_params']
-- 
2.0.0.rc2

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

Re: [U-Boot] [PATCH] mx6ul_evk: Remove SPL support

[Dennis Gilmore]

On Tuesday, April 19, 2016 10:11:37 PM CDT Stefano Babic wrote:
> Hi Fabio,
> 
> On 19/04/2016 17:19, Fabio Estevam wrote:
> > Currently mx6ul evk fails to boot with some SD cards such as
> > SanDisk microSD HC - 8GB:
> > 
> > U-Boot SPL 2016.05-rc1-28384-g108f841 (Apr 19 2016 - 11:19:11)
> > Trying to boot from MMC1
> > spl: mmc block read error
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
> 
> Well, it does not work because mmc is not working - mmc should be fixed,
> then.
> 
> > As a proper fix for SPL is not available, change to booting via
> > non-SPL mode, so that we can have always have a reliable boot.
> > 
> > Signed-off-by: Fabio Estevam 
> > ---
> > 
> >  board/freescale/mx6ul_14x14_evk/imximage.cfg  |  88 +++
> >  board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 172
> >  -- configs/mx6ul_14x14_evk_defconfig
> >  |   3 +-
> >  3 files changed, 89 insertions(+), 174 deletions(-)
> >  create mode 100644 board/freescale/mx6ul_14x14_evk/imximage.cfg
> > 
> > diff --git a/board/freescale/mx6ul_14x14_evk/imximage.cfg
> > b/board/freescale/mx6ul_14x14_evk/imximage.cfg new file mode 100644
> > index 000..f413753
> > --- /dev/null
> > +++ b/board/freescale/mx6ul_14x14_evk/imximage.cfg
> > @@ -0,0 +1,88 @@
> > +/*
> > + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + *
> > + * Refer docs/README.imxmage for more details about how-to configure
> > + * and create imximage boot image
> > + *
> > + * The syntax is taken as close as possible with the kwbimage
> > + */
> > +
> > +#define __ASSEMBLY__
> > +#include 
> > +
> > +/* image version */
> > +
> > +IMAGE_VERSION 2
> > +
> > +/*
> > + * Boot Device : one of
> > + * spi/sd/nand/onenand, qspi/nor
> > + */
> > +BOOT_FROM  sd
> > +
> > +/* New DDR type MT41K256M16TW-107 */
> > +
> > +/* Enable all clocks */
> > +DATA 4 0x020c4068 0x
> > +DATA 4 0x020c406c 0x
> > +DATA 4 0x020c4070 0x
> > +DATA 4 0x020c4074 0x
> > +DATA 4 0x020c4078 0x
> > +DATA 4 0x020c407c 0x
> > +DATA 4 0x020c4080 0x
> > +
> > +DATA 4 0x020E04B4 0x000C
> > +DATA 4 0x020E04AC 0x
> > +DATA 4 0x020E027C 0x0030
> > +DATA 4 0x020E0250 0x0030
> > +DATA 4 0x020E024C 0x0030
> > +DATA 4 0x020E0490 0x0030
> > +DATA 4 0x020E0288 0x0030
> > +DATA 4 0x020E0270 0x
> > +DATA 4 0x020E0260 0x0030
> > +DATA 4 0x020E0264 0x0030
> > +DATA 4 0x020E04A0 0x0030
> > +DATA 4 0x020E0494 0x0002
> > +DATA 4 0x020E0280 0x0030
> > +DATA 4 0x020E0284 0x0030
> > +DATA 4 0x020E04B0 0x0002
> > +DATA 4 0x020E0498 0x0030
> > +DATA 4 0x020E04A4 0x0030
> > +DATA 4 0x020E0244 0x0030
> > +DATA 4 0x020E0248 0x0030
> > +DATA 4 0x021B001C 0x8000
> > +DATA 4 0x021B0800 0xA1390003
> > +DATA 4 0x021B080C 0x
> > +DATA 4 0x021B083C 0x41570155
> > +DATA 4 0x021B0848 0x4040474A
> > +DATA 4 0x021B0850 0x40405550
> > +DATA 4 0x021B081C 0x
> > +DATA 4 0x021B0820 0x
> > +DATA 4 0x021B082C 0xf333
> > +DATA 4 0x021B0830 0xf333
> > +DATA 4 0x021B08C0 0x00921012
> > +DATA 4 0x021B08b8 0x0800
> > +DATA 4 0x021B0004 0x0002002D
> > +DATA 4 0x021B0008 0x1B333030
> > +DATA 4 0x021B000C 0x676B52F3
> > +DATA 4 0x021B0010 0xB66D0B63
> > +DATA 4 0x021B0014 0x01FF00DB
> > +DATA 4 0x021B0018 0x00201740
> > +DATA 4 0x021B001C 0x8000
> > +DATA 4 0x021B002C 0x26D2
> > +DATA 4 0x021B0030 0x006B1023
> > +DATA 4 0x021B0040 0x004F
> > +DATA 4 0x021B 0x8418
> > +DATA 4 0x021B0890 0x23400A38
> > +DATA 4 0x021B001C 0x02008032
> > +DATA 4 0x021B001C 0x8033
> > +DATA 4 0x021B001C 0x00048031
> > +DATA 4 0x021B001C 0x15208030
> > +DATA 4 0x021B001C 0x04008040
> > +DATA 4 0x021B0020 0x0800
> > +DATA 4 0x021B0818 0x0227
> > +DATA 4 0x021B0004 0x0002552D
> > +DATA 4 0x021B0404 0x00011006
> > +DATA 4 0x021B001C 0x
> > diff --git a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
> > b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c index
> > 88d3fbd..4de5ece 100644
> > --- a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
> > +++ b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
> > @@ -703,175 +703,3 @@ int checkboard(void)
> > 
> > return 0;
> >  
> >  }
> > 
> > -
> > -#ifdef CONFIG_SPL_BUILD
> > -#include 
> > -#include 
> > -#include 
> > -
> > -
> > -static struct mx6ul_iomux_grp_regs mx6_grp_ioregs = {
> > -   .grp_addds = 0x0030,
> > -   .grp_ddrmode_ctl = 0x0002,
> > -   .grp_b0ds = 0x0030,
> > -   .grp_ctlds = 0x0030,
> > -   .grp_b1ds = 0x0030,
> > -   .grp_ddrpke = 0x,
> > -   .grp_ddrmode = 0x0002,
> > -#ifdef CONFIG_TARGET_MX6UL_9X9_EVK
> > -   .grp_ddr_type = 0x0008,
> > -#else
> > -   .grp_ddr_type = 0x000c,
> > -#endif
> > -};
> > -
> > -#ifdef CONFIG_TARGET_MX6UL_9X9_EVK
> > -static struct 

Re: [U-Boot] [PATCHv2] cmd: Kconfig: Add a Kconfig options for a few CMD

[Tom Rini]

On Thu, Apr 21, 2016 at 09:18:59AM -0500, Dinh Nguyen wrote:
> Hi Simon,
> 
> On 04/21/2016 09:13 AM, Simon Glass wrote:
> > Hi Dinh,
> > 
> > On 21 April 2016 at 08:05, Dinh Nguyen  wrote:
> >>
> >> Add the following CMD options to Kconfig:
> >>
> >> CMD_BOOTZ
> >> CMD_ASKENV
> >> CMD_GREPENV
> >> CMD_USB_MASS_STORAGE
> >> CMD_FAT
> >> CMD_MII
> >> CMD_CACHE
> >> CMD_DFU
> >> CMD_EXT2
> >> CMD_EXT4
> >> CMD_EXT4_WRITE
> >> CMD_FS_GENERIC
> >> CMD_MMC
> >>
> >> Signed-off-by: Dinh Nguyen 
> >> ---
> >> v2: remove an extra CMD_DFU
> >> ---
> >>  cmd/Kconfig | 72 
> >> +
> >>  1 file changed, 72 insertions(+)
> > 
> > Can you convert existing users with moveconfig.py?
> > 
> 
> Yes, I started doing the moveconfig, starting with ARM, but I saw Tom's
> message to hold off because it might conflict with his work. I'll be
> happy to do the moveconfig, when I get Tom's OK to move ahead.

The problem with doing moveconfig.py is that it does get conflict happy
so easily.  My intention with this patch at least is to set things up
locally so I can do that and test it here, then push, to make life a bit
easier.

-- 
Tom


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

Re: [U-Boot] [PATCHv2] cmd: Kconfig: Add a Kconfig options for a few CMD

[Dinh Nguyen]

Hi Simon,

On 04/21/2016 09:13 AM, Simon Glass wrote:
> Hi Dinh,
> 
> On 21 April 2016 at 08:05, Dinh Nguyen  wrote:
>>
>> Add the following CMD options to Kconfig:
>>
>> CMD_BOOTZ
>> CMD_ASKENV
>> CMD_GREPENV
>> CMD_USB_MASS_STORAGE
>> CMD_FAT
>> CMD_MII
>> CMD_CACHE
>> CMD_DFU
>> CMD_EXT2
>> CMD_EXT4
>> CMD_EXT4_WRITE
>> CMD_FS_GENERIC
>> CMD_MMC
>>
>> Signed-off-by: Dinh Nguyen 
>> ---
>> v2: remove an extra CMD_DFU
>> ---
>>  cmd/Kconfig | 72 
>> +
>>  1 file changed, 72 insertions(+)
> 
> Can you convert existing users with moveconfig.py?
> 

Yes, I started doing the moveconfig, starting with ARM, but I saw Tom's
message to hold off because it might conflict with his work. I'll be
happy to do the moveconfig, when I get Tom's OK to move ahead.

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

Re: [U-Boot] [PATCH 07/16] ti: AM43xx: Use CONFIG options from SOC Kconfig

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:09PM -0500, Daniel Allred wrote:

> From: Madan Srinivas 
> 
> Updates configs/am43xx_evm.h to use CONFIG options from
> SOC specific Kconfig file for various calculations.
> 
> On AM43x devices, the address of SPL entry point  depends on
> the device type, i.e. whether it is secure or non-secure.
> 
> Further, for non-secure devices, the SPL entry point is different
> between  USB HOST boot mode, other "memory" boot modes (MMC, NAND)
> and "peripheral" boot modes (UART, USB)
> 
> To add to the complexity, on secure devices, in addition to the
> above differences, the SPL entry point can change because of the
> space occupied by other components (other than u-boot or spl)
> that go into a secure boot image.
> 
> To prevent the user from having to modify source files every time
> any component of the secure image changes, the value of
> CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
> is supplied in the am43xx_*_defconfig files
> 
> Using the CONFIG options also enables us to do away with some
> compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
> for different boot modes.
> 
> On QSPI devices, the same problem described above occurs w.r.t. the
> address of the u-boot entry point in flash, when booting secure
> devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
> a Kconfig option and the defconfig files.
> 
> Signed-off-by: Madan Srinivas 
> Signed-off-by: Daniel Allred 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCHv2] cmd: Kconfig: Add a Kconfig options for a few CMD

[Simon Glass]

Hi Dinh,

On 21 April 2016 at 08:05, Dinh Nguyen  wrote:
>
> Add the following CMD options to Kconfig:
>
> CMD_BOOTZ
> CMD_ASKENV
> CMD_GREPENV
> CMD_USB_MASS_STORAGE
> CMD_FAT
> CMD_MII
> CMD_CACHE
> CMD_DFU
> CMD_EXT2
> CMD_EXT4
> CMD_EXT4_WRITE
> CMD_FS_GENERIC
> CMD_MMC
>
> Signed-off-by: Dinh Nguyen 
> ---
> v2: remove an extra CMD_DFU
> ---
>  cmd/Kconfig | 72 
> +
>  1 file changed, 72 insertions(+)

Can you convert existing users with moveconfig.py?

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

Re: [U-Boot] [PATCH 4/9] drivers: nand: implement a NAND uclass

[Simon Glass]

Hi Mugunthan,

On 20 April 2016 at 23:55, Mugunthan V N  wrote:
> On Wednesday 20 April 2016 08:09 PM, Simon Glass wrote:
>> Hi Mugunthan,
>>
>> On 1 April 2016 at 05:29, Mugunthan V N  wrote:
>>> Implement a NAND uclass so that the NAND devices can be
>>> accessed via the DM framework.
>>>
>>> Signed-off-by: Mugunthan V N 
>>> ---
>>>  drivers/mtd/nand/Kconfig   | 10 +++
>>>  drivers/mtd/nand/Makefile  |  2 ++
>>>  drivers/mtd/nand/nand-uclass.c | 62 
>>> ++
>>>  drivers/mtd/nand/nand.c|  6 +++-
>>>  include/dm/uclass-id.h |  1 +
>>>  include/nand.h |  5 
>>>  6 files changed, 85 insertions(+), 1 deletion(-)
>>>  create mode 100644 drivers/mtd/nand/nand-uclass.c
>>>
>>> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
>>> index 7787505..53b57b8 100644
>>> --- a/drivers/mtd/nand/Kconfig
>>> +++ b/drivers/mtd/nand/Kconfig
>>> @@ -8,6 +8,16 @@ menuconfig NAND
>>>
>>>  if NAND
>>>
>>> +config DM_NAND
>>> +   bool "Enable driver model for NAND"
>>> +   depends on NAND && DM
>>> +   help
>>> + Enable driver model for NAND. The NAND interface is then
>>> + implemented by the NAND uclass. Multiple NAND devices can
>>> + be attached and used. The 'nand' command works as normal.
>>> +
>>> + If the NAND drivers doesn't support DM, say N.
>>> +
>>>  config SYS_NAND_SELF_INIT
>>> bool
>>> help
>>> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
>>> index 6fb3718..7745705 100644
>>> --- a/drivers/mtd/nand/Makefile
>>> +++ b/drivers/mtd/nand/Makefile
>>> @@ -39,6 +39,8 @@ endif # not spl
>>>
>>>  ifdef NORMAL_DRIVERS
>>>
>>> +obj-$(CONFIG_DM_NAND) += nand-uclass.o
>>> +
>>>  obj-$(CONFIG_NAND_ECC_BCH) += nand_bch.o
>>>
>>>  obj-$(CONFIG_NAND_ATMEL) += atmel_nand.o
>>> diff --git a/drivers/mtd/nand/nand-uclass.c b/drivers/mtd/nand/nand-uclass.c
>>> new file mode 100644
>>> index 000..d68d357
>>> --- /dev/null
>>> +++ b/drivers/mtd/nand/nand-uclass.c
>>> @@ -0,0 +1,62 @@
>>> +/*
>>> + * NAND uclass driver for NAND bus.
>>> + *
>>> + * (C) Copyright 2012-2016
>>> + * Texas Instruments Incorporated, 
>>> + *
>>> + * SPDX-License-Identifier: GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +#ifdef CONFIG_DM_NAND
>>> +
>>> +nand_info_t *get_nand_dev_by_index(int idx)
>>> +{
>>> +   nand_info_t *nand;
>>> +   struct udevice *dev;
>>> +   int ret;
>>> +
>>> +   ret = uclass_get_device(UCLASS_NAND, idx, );
>>> +   if (ret) {
>>> +   error("NAND device (%d) not found\n", idx);
>>
>> This should return -ENODEV. Also please avoid printf() in drivers. The
>> caller can report the error.
>>
>
> Return type is pointer so returned NULL and NULL denotes no dev.
> Will change this error to debug in v2.

OK, I see that this is the existing API.

>
>>> +   return NULL;
>>> +   }
>>> +
>>> +   nand = (nand_info_t *)dev_get_uclass_priv(dev);
>>> +   if (!nand) {
>>> +   error("Nand device not ready\n");
>>> +   return NULL;
>>> +   }
>>
>> But if the device has been probed ((with uclass_get_device()) then
>> this cannot be NULL.
>
> This check is just a failsafe. ideally it should not fail here.

I cannot get to probe the device without this data, since this would
be a bug in DM. So the check has no value.

[snip]

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

Re: [U-Boot] [PATCH 15/60] gpio: tegra: header file split

[Simon Glass]

Hi Stephen,

On 20 April 2016 at 16:01, Stephen Warren  wrote:
> On 04/20/2016 01:26 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 19 April 2016 at 14:58, Stephen Warren  wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> Tegra's gpio.h contains a mix of private definitions for use inside the
>>> GPIO driver and custom machine-specific APIs. Move the private
>>> definitions
>>> out of the global include directory since nothing should need to access
>>> them. Move the public definitions to the machine-specific include
>>> directory .
>
>
>>> diff --git a/drivers/gpio/tegra_gpio_priv.h
>>> b/drivers/gpio/tegra_gpio_priv.h
>
>
>>> +/*
>>> + * GPIO registers are split into two chunks; low and high.
>>> + * On Tegra20, all low chunks appear first, then all high chunks.
>>> + * In later SoCs, the low and high chunks are interleaved together.
>>> + */
>>> +#define GPIO_CTLR_BANK_HIGH_REGS \
>>> +   uint gpio_masked_config[TEGRA_GPIO_PORTS]; \
>>> +   uint gpio_masked_dir_out[TEGRA_GPIO_PORTS]; \
>>> +   uint gpio_masked_out[TEGRA_GPIO_PORTS]; \
>>> +   uint reserved0[TEGRA_GPIO_PORTS]; \
>>> +   uint gpio_masked_int_status[TEGRA_GPIO_PORTS]; \
>>> +   uint gpio_masked_int_enable[TEGRA_GPIO_PORTS]; \
>>> +   uint gpio_masked_int_level[TEGRA_GPIO_PORTS]; \
>>> +   uint reserved1[TEGRA_GPIO_PORTS];
>>> +
>>> +/* GPIO Controller registers for a single bank */
>>> +struct gpio_ctlr_bank {
>>> +   uint gpio_config[TEGRA_GPIO_PORTS];
>>> +   uint gpio_dir_out[TEGRA_GPIO_PORTS];
>>> +   uint gpio_out[TEGRA_GPIO_PORTS];
>>> +   uint gpio_in[TEGRA_GPIO_PORTS];
>>> +   uint gpio_int_status[TEGRA_GPIO_PORTS];
>>> +   uint gpio_int_enable[TEGRA_GPIO_PORTS];
>>> +   uint gpio_int_level[TEGRA_GPIO_PORTS];
>>> +   uint gpio_int_clear[TEGRA_GPIO_PORTS];
>>> +#ifndef CONFIG_TEGRA20
>>> +   GPIO_CTLR_BANK_HIGH_REGS
>>> +#endif
>>> +};
>>> +
>>> +#ifdef CONFIG_TEGRA20
>>> +struct gpio_ctlr_bank_high {
>>> +   GPIO_CTLR_BANK_HIGH_REGS
>>
>>
>> This seems a bit ugly. Perhaps you could havestruct
>> gpio_ctlr_high_regs and include that here? It adds a level of
>> indirection but that doesn't seem very important.
>
>
> In newer Tegras, there's no differentiation between the two register sets
> that were "low" and "high" in Tegra20. I'd rather not saddle the non-Tegra20
> struct layouts with some odd naming/nesting just because the Tegra20 layout
> was odd. I don't see any problem with using a #define for this; it doesn't
> seem to make the code complex.

OK, well then how about just duplicating the two structs, and dropping
the #define?

#ifdfef CONFIG_TEGRA20
struct gpio_ctlr_bank {

};
#else
struct gpio_ctlr_bank {
};
#endif

> I wonder if we should just convert away from structs for registers entirely.
> Everything in the HW docs is just numbers, matching those to the structs is
> always painful, and if we used #defines instead of structs, representing
> this HW difference would end up being much cleaner and avoid using a macro
> to "cut/paste" a register list 2 times; see the way the Linux kernel driver
> handles this.

Structs are definitely easier to read and particularly in this case
where each struct element is an array.

Why are you worried about code duplication in a header file?

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

Re: [U-Boot] [PATCH] travis: turn off dtc unit address warnings

[Heiko Schocher]

Hello Tom,

Am 21.04.2016 um 15:53 schrieb Tom Rini:

On Thu, Apr 21, 2016 at 03:50:28PM +0200, Marek Vasut wrote:

On 04/21/2016 03:35 PM, Simon Glass wrote:

Hi,

On 21 April 2016 at 07:25, Marek Vasut  wrote:

On 04/21/2016 03:17 PM, Heiko Schocher wrote:

Hello Marek,

Am 21.04.2016 um 14:51 schrieb Marek Vasut:

On 04/21/2016 02:48 PM, Heiko Schocher wrote:

suppress a lot of
"reg or ranges property, but no unit name" warnings,
through the dtc compiler flag "-Wno-unit_address_vs_reg".

If all DTS are fixed, we can remove this flag again.

Signed-off-by: Heiko Schocher 
---
There is also a solution to suppress warnings from
the dtc compiler by the "-q" flag, but that would
suppress all warnings. Not realy what I want.


Yep


With this patch and patch:
http://patchwork.ozlabs.org/patch/609150/

travis build passes, see:
https://travis-ci.org/hsdenx/u-boot/builds/124723016


   arch/arc/dts/Makefile| 2 ++
   arch/arm/dts/Makefile| 3 ++-
   arch/microblaze/dts/Makefile | 2 ++
   arch/mips/dts/Makefile   | 3 ++-
   arch/nios2/dts/Makefile  | 2 ++
   arch/powerpc/dts/Makefile| 2 ++
   arch/sandbox/dts/Makefile| 2 ++
   arch/x86/dts/Makefile| 2 ++
   8 files changed, 16 insertions(+), 2 deletions(-)


Isn't there some common place in scripts/ or so where we can disable
this warning using an one-liner ?


I don;t know ... but I prefer to disable this per arch .. so we can
enable the check back if one arch is fixed ...


In my opinion, we should stick to the same behavior Linux does.
Ccing a few more people.


Wouldn't it be better to fix the problems?


My impression was that these warnings are just the result of
over-eagerness of DTC, that's why Linux prints them only if you
increase the W= (warning) verbosity. I might be wrong tho.


They are minor problems.  For the vast majority of the dts files we
have, the fixes will come in via re-syncs with the kernel and in at
least some cases it's not just a simple regex but also "oh, lets give
things better names".  With respect to dts files that we really do own
(ie x86) yes, we should fix them.


So, this patch from me could be still an option?

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

(at least for the sandbox fixes?)
(I have a v2 where I worked in the comments from Bin ...)

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

[U-Boot] [PATCHv2] cmd: Kconfig: Add a Kconfig options for a few CMD

[Dinh Nguyen]

Add the following CMD options to Kconfig:

CMD_BOOTZ
CMD_ASKENV
CMD_GREPENV
CMD_USB_MASS_STORAGE
CMD_FAT
CMD_MII
CMD_CACHE
CMD_DFU
CMD_EXT2
CMD_EXT4
CMD_EXT4_WRITE
CMD_FS_GENERIC
CMD_MMC

Signed-off-by: Dinh Nguyen 
---
v2: remove an extra CMD_DFU
---
 cmd/Kconfig | 72 +
 1 file changed, 72 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index fe8b4f0..ec7c054 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -160,6 +160,11 @@ config CMD_BOOTM
help
  Boot an application image from the memory.
 
+config CMD_BOOTZ
+   bool "bootz"
+   help
+ Boot the Linux zImage
+
 config CMD_BOOTEFI
bool "bootefi"
depends on EFI_LOADER
@@ -210,6 +215,11 @@ endmenu
 
 menu "Environment commands"
 
+config CMD_ASKENV
+   bool "ask for env variable"
+   help
+ Ask for environment variable
+
 config CMD_EXPORTENV
bool "env export"
default y
@@ -228,6 +238,11 @@ config CMD_EDITENV
help
  Edit environment variable.
 
+config CMD_GREPENV
+   bool "search env"
+   help
+ Allow for searching environment variables
+
 config CMD_SAVEENV
bool "saveenv"
default y
@@ -341,6 +356,11 @@ config CMD_ARMFLASH
help
  ARM Ltd reference designs flash partition access
 
+config CMD_MMC
+   bool "mmc"
+   help
+ MMC memory mapped support.
+
 config CMD_NAND
bool "nand"
help
@@ -366,6 +386,19 @@ config CMD_USB
help
  USB support.
 
+config CMD_DFU
+   depends on CMD_USB
+   bool "dfu"
+   help
+ Enables the command "dfu" which is used to have U-Boot create a DFU
+ class device via USB.
+
+config CMD_USB_MASS_STORAGE
+   depends on CMD_USB
+   bool "UMS usb mass storage"
+   help
+ USB mass storage support
+
 config CMD_FPGA
bool "fpga"
default y
@@ -454,6 +487,11 @@ config CMD_NFS
help
  Boot image via network using NFS protocol.
 
+config CMD_MII
+   bool "mii"
+   help
+ Enable MII utility commands.
+
 config CMD_PING
bool "ping"
help
@@ -508,6 +546,11 @@ config CMD_BLOCK_CACHE
  during development, but also allows the cache to be disabled when
  it might hurt performance (e.g. when using the ums command).
 
+config CMD_CACHE
+   bool "icache or dcache"
+   help
+ Enable the "icache" and "dcache" commands
+
 config CMD_TIME
bool "time"
help
@@ -612,4 +655,33 @@ config CMD_TPM_TEST
 
 endmenu
 
+menu "Filesystem commands"
+config CMD_EXT2
+   bool "ext2 command support"
+   help
+ Enables EXT2 FS command
+
+config CMD_EXT4
+   bool "ext4 command support"
+   help
+ Enables EXT4 FS command
+
+config CMD_EXT4_WRITE
+   depends on CMD_EXT4
+   bool "ext4 write command support"
+   help
+ Enables EXT4 FS write command
+
+config CMD_FAT
+   bool "FAT command support"
+   help
+ Support for the FAT fs
+
+config CMD_FS_GENERIC
+   bool "filesystem commands"
+   help
+ Enables filesystem commands (e.g. load, ls) that work for multiple
+ fs types.
+endmenu
+
 endmenu
-- 
1.9.1.315.g3f09db0

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

Re: [U-Boot] [PATCH 5/7] ARM: hisilicon: hikey: dts: Add pl011 additional clock binding.

[Tom Rini]

On Wed, Apr 20, 2016 at 05:14:01PM +0100, Peter Griffin wrote:

> This is a binding which only exists in U-Boot, but is
> required to get working serial in U-Boot.
> 
> Signed-off-by: Peter Griffin 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] travis: turn off dtc unit address warnings

[Tom Rini]

On Thu, Apr 21, 2016 at 03:50:28PM +0200, Marek Vasut wrote:
> On 04/21/2016 03:35 PM, Simon Glass wrote:
> > Hi,
> > 
> > On 21 April 2016 at 07:25, Marek Vasut  wrote:
> >> On 04/21/2016 03:17 PM, Heiko Schocher wrote:
> >>> Hello Marek,
> >>>
> >>> Am 21.04.2016 um 14:51 schrieb Marek Vasut:
>  On 04/21/2016 02:48 PM, Heiko Schocher wrote:
> > suppress a lot of
> > "reg or ranges property, but no unit name" warnings,
> > through the dtc compiler flag "-Wno-unit_address_vs_reg".
> >
> > If all DTS are fixed, we can remove this flag again.
> >
> > Signed-off-by: Heiko Schocher 
> > ---
> > There is also a solution to suppress warnings from
> > the dtc compiler by the "-q" flag, but that would
> > suppress all warnings. Not realy what I want.
> 
>  Yep
> 
> > With this patch and patch:
> > http://patchwork.ozlabs.org/patch/609150/
> >
> > travis build passes, see:
> > https://travis-ci.org/hsdenx/u-boot/builds/124723016
> >
> >
> >   arch/arc/dts/Makefile| 2 ++
> >   arch/arm/dts/Makefile| 3 ++-
> >   arch/microblaze/dts/Makefile | 2 ++
> >   arch/mips/dts/Makefile   | 3 ++-
> >   arch/nios2/dts/Makefile  | 2 ++
> >   arch/powerpc/dts/Makefile| 2 ++
> >   arch/sandbox/dts/Makefile| 2 ++
> >   arch/x86/dts/Makefile| 2 ++
> >   8 files changed, 16 insertions(+), 2 deletions(-)
> 
>  Isn't there some common place in scripts/ or so where we can disable
>  this warning using an one-liner ?
> >>>
> >>> I don;t know ... but I prefer to disable this per arch .. so we can
> >>> enable the check back if one arch is fixed ...
> >>
> >> In my opinion, we should stick to the same behavior Linux does.
> >> Ccing a few more people.
> > 
> > Wouldn't it be better to fix the problems?
> 
> My impression was that these warnings are just the result of
> over-eagerness of DTC, that's why Linux prints them only if you
> increase the W= (warning) verbosity. I might be wrong tho.

They are minor problems.  For the vast majority of the dts files we
have, the fixes will come in via re-syncs with the kernel and in at
least some cases it's not just a simple regex but also "oh, lets give
things better names".  With respect to dts files that we really do own
(ie x86) yes, we should fix them.

-- 
Tom


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

Re: [U-Boot] [PATCHv2 2/2] arm: socfpga: clean up common config options

[Dinh Nguyen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 04/20/2016 09:21 AM, Tom Rini wrote:
> On Tue, Apr 19, 2016 at 08:41:52PM -0500, Dinh Nguyen wrote:
> 
>> Move common config options like these to socfpga_*_defconfig:
>> 
>> CONFIG_CMD_ASKENV CONFIG_CMD_BOOTZ CONFIG_CMD_CACHE 
>> CONFIG_CMD_DHCP CONFIG_CMD_EXT4 CONFIG_CMD_EXT4_WRITE 
>> CONFIG_CMD_FAT CONFIG_CMD_FS_GENERIC CONFIG_CMD_GREPENV 
>> CONFIG_CMD_MEMTEST CONFIG_CMD_MII CONFIG_CMD_MMC CONFIG_CMD_PING 
>> CONFIG_CMD_SF CONFIG_CMD_SPI CONFIG_CMD_TIME
>> 
>> to avoid defining them in individual SoCFPGA config files.
> 
> So this is the tricky part, yes.  You need to be able to use 
> moveconfig.py to update _everyone_ and this easily conflicts (so
> don't do it right now, I have some stuff to push out that would
> cause it to conflict).  I think I'll see if I can do this part,
> globally instead after applying your 1/2.  Thanks!
> 

Ok, let me resend 1/2 because I noticed that it had a duplicate defconfi
g.

Thanks,
Dinh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJXGNzHAAoJEBmUBAuBoyj08IYP/2K3kfb+cPIfMIEFkb5JugIb
ivUgPb72YB6DqJQVYdPolgYzm7WhMpul9cS7oT9gGBicnQ125RaWmjM5y80zBVqL
99+4o1gxqd62RYutGtptUFsh2muBi8xkGHtFSfBtqiOW9jDWthZ0+igrOo/IvrXB
Gh5hYAyxvyJbVOvBg1yUIZ8sCsiFo22rkTDMjUppjaLqGkX2gQJZOtOr5iIqI/K0
s4mfQNvgz8qcZ86worz3YAp/zpSC5pCIds/lh8osRPHnSW54iBPyW9+MXWYjLjj3
1A9iZFgDVRe0gZ3tjToa+9CMw4Rnm0ysL02FBX8EbNmBSHgX723Tz3Wi2AUwii3G
CArsZhJLUNXIt/Xts2xlJAdGtX497NsnFL9gG9vCg2Ftmdf508+AxCzyoyOuWHTK
IuVabhLKCk0xJUNBqZ6LV1Y6csXFz3U0B6xLrFtOjC1ys5WAkLpzvfKo0pLbDZFW
siJ4wvmMxpJbBTMPiFQ4o0ddoDsGI0k6T0vGuTVxm4DZFeQ9cR+YJ1KTpFkxHiqt
Y4+o/wbMnFSl7XmCEW9AbsFg7l+jpIkOO+YmrKhX2Dawz/0nUupnyW6ka/PIhaIg
NDY5yzBjQz59YKzxbvmEHIr0EmSnYZPG0idvIZf+ufSP/lm1s4vTq9PgGALUleGX
rKsnrB5Az289CWrltLYO
=xfzS
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] travis: turn off dtc unit address warnings

[Marek Vasut]

On 04/21/2016 03:35 PM, Simon Glass wrote:
> Hi,
> 
> On 21 April 2016 at 07:25, Marek Vasut  wrote:
>> On 04/21/2016 03:17 PM, Heiko Schocher wrote:
>>> Hello Marek,
>>>
>>> Am 21.04.2016 um 14:51 schrieb Marek Vasut:
 On 04/21/2016 02:48 PM, Heiko Schocher wrote:
> suppress a lot of
> "reg or ranges property, but no unit name" warnings,
> through the dtc compiler flag "-Wno-unit_address_vs_reg".
>
> If all DTS are fixed, we can remove this flag again.
>
> Signed-off-by: Heiko Schocher 
> ---
> There is also a solution to suppress warnings from
> the dtc compiler by the "-q" flag, but that would
> suppress all warnings. Not realy what I want.

 Yep

> With this patch and patch:
> http://patchwork.ozlabs.org/patch/609150/
>
> travis build passes, see:
> https://travis-ci.org/hsdenx/u-boot/builds/124723016
>
>
>   arch/arc/dts/Makefile| 2 ++
>   arch/arm/dts/Makefile| 3 ++-
>   arch/microblaze/dts/Makefile | 2 ++
>   arch/mips/dts/Makefile   | 3 ++-
>   arch/nios2/dts/Makefile  | 2 ++
>   arch/powerpc/dts/Makefile| 2 ++
>   arch/sandbox/dts/Makefile| 2 ++
>   arch/x86/dts/Makefile| 2 ++
>   8 files changed, 16 insertions(+), 2 deletions(-)

 Isn't there some common place in scripts/ or so where we can disable
 this warning using an one-liner ?
>>>
>>> I don;t know ... but I prefer to disable this per arch .. so we can
>>> enable the check back if one arch is fixed ...
>>
>> In my opinion, we should stick to the same behavior Linux does.
>> Ccing a few more people.
> 
> Wouldn't it be better to fix the problems?

My impression was that these warnings are just the result of
over-eagerness of DTC, that's why Linux prints them only if you
increase the W= (warning) verbosity. I might be wrong tho.

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

Re: [U-Boot] [PATCH 7/9] arm: exynos: realign the code to allow support for newer 64-bit platforms

[Minkyu Kang]

Hi,

On 18/04/16 23:11, Thomas Abraham wrote:
> Hi Mr. Kang,
> 
> On Mon, Apr 18, 2016 at 4:39 PM, Minkyu Kang  wrote:
>> Dear Thomas Abraham,
>>
>> On 13/04/16 19:43, Thomas Abraham wrote:
>>> From: Thomas Abraham 
>>>
>>> The existing Exynos 32-bit platform support needs to be realigned in
>>> order to support newer 64-bit Exynos platforms. The driver model will
>>> be utlized for drivers on the 64-bit Exynos platforms and so some of
>>> the older platform support code would not be required for the newer
>>> 64-bit Exynos platforms.
>>>
>>> Cc: Minkyu Kang 
>>> Signed-off-by: Thomas Abraham 
>>> ---
>>>  arch/arm/Kconfig |1 -
>>>  arch/arm/mach-exynos/Kconfig |   14 ++
>>>  arch/arm/mach-exynos/Makefile|7 +--
>>>  arch/arm/mach-exynos/include/mach/cpu.h  |2 +-
>>>  arch/arm/mach-exynos/include/mach/gpio.h |2 +-
>>>  arch/arm/mach-exynos/soc.c   |2 ++
>>>  6 files changed, 23 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index b82ec18..ee22a3c 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -426,7 +426,6 @@ config TARGET_BCMNSP
>>>
>>>  config ARCH_EXYNOS
>>>   bool "Samsung EXYNOS"
>>> - select CPU_V7
>>>   select DM
>>>   select DM_SPI_FLASH
>>>   select DM_SERIAL
>>> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>>> index a6a7597..acab947 100644
>>> --- a/arch/arm/mach-exynos/Kconfig
>>> +++ b/arch/arm/mach-exynos/Kconfig
>>> @@ -7,30 +7,38 @@ choice
>>>  config TARGET_SMDKV310
>>>   select SUPPORT_SPL
>>>   bool "Exynos4210 SMDKV310 board"
>>> + select CPU_V7
>>>   select OF_CONTROL
>>>
>>>  config TARGET_TRATS
>>>   bool "Exynos4210 Trats board"
>>> + select CPU_V7
>>>
>>>  config TARGET_S5PC210_UNIVERSAL
>>>   bool "EXYNOS4210 Universal C210 board"
>>> + select CPU_V7
>>>
>>>  config TARGET_ORIGEN
>>>   bool "Exynos4412 Origen board"
>>> + select CPU_V7
>>>   select SUPPORT_SPL
>>>
>>>  config TARGET_TRATS2
>>>   bool "Exynos4412 Trat2 board"
>>> + select CPU_V7
>>>
>>>  config TARGET_ODROID
>>>   bool "Exynos4412 Odroid board"
>>> + select CPU_V7
>>>
>>>  config TARGET_ODROID_XU3
>>>   bool "Exynos5422 Odroid board"
>>> + select CPU_V7
>>>   select OF_CONTROL
>>>
>>>  config TARGET_ARNDALE
>>>   bool "Exynos5250 Arndale board"
>>> + select CPU_V7
>>>   select CPU_V7_HAS_NONSEC
>>>   select CPU_V7_HAS_VIRT
>>>   select SUPPORT_SPL
>>> @@ -38,32 +46,38 @@ config TARGET_ARNDALE
>>>
>>>  config TARGET_SMDK5250
>>>   bool "SMDK5250 board"
>>> + select CPU_V7
>>>   select SUPPORT_SPL
>>>   select OF_CONTROL
>>>
>>>  config TARGET_SNOW
>>>   bool "Snow board"
>>> + select CPU_V7
>>>   select SUPPORT_SPL
>>>   select OF_CONTROL
>>>
>>>  config TARGET_SPRING
>>>   bool "Spring board"
>>> + select CPU_V7
>>>   select SUPPORT_SPL
>>>   select OF_CONTROL
>>>   select SPL_DISABLE_OF_CONTROL
>>>
>>>  config TARGET_SMDK5420
>>>   bool "SMDK5420 board"
>>> + select CPU_V7
>>>   select SUPPORT_SPL
>>>   select OF_CONTROL
>>>
>>>  config TARGET_PEACH_PI
>>>   bool "Peach Pi board"
>>> + select CPU_V7
>>>   select SUPPORT_SPL
>>>   select OF_CONTROL
>>>
>>>  config TARGET_PEACH_PIT
>>>   bool "Peach Pit board"
>>> + select CPU_V7
>>>   select SUPPORT_SPL
>>>   select OF_CONTROL
>>
>> I think it's better to split to new architecture type for 64bit exynos 
>> platform - ARCH_EXYNOS64?
>> What do you think?
> 
> I was infact thinking to avoid adding a new ARCH type as much as
> possible and reuse ARCH_EXYNOS for 64-bit as well. Eventually, the
> code in mach-exynos has to move into respective driver folders
> (atleast for ARM64 platforms) and have as little as possible in
> mach-exynos directory.

I understood what you want.
But I think, we can reuse mach-exynos code even if we make new ARCH type.
And the cpu type should have a dependency with ARCH, not boards.
I don't believe that we should add a cpu type to every boards.
Please consider again.

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

Re: [U-Boot] [PATCH 04/16] ti: omap-common: Add Kconfig file for secure device support

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:06PM -0500, Daniel Allred wrote:

> From: Madan Srinivas 
> 
> Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
> when building images for secure devices. This flag is used
> to invoke the secure image creation tools for creating a
> boot image that can be used on secure devices. This flag
> may also be used to conditionally compile code specific
> to secure devices.
> 
> This terminology will be used by all OMAP architecture devices,
> hence introducing to a common location.
> 
> With the creation of Kconfig for omap-common, moved the
> sourcing of the Kconfig files for the omap3/4/5 and am33xx
> devices from arch/arm/KConfig to the omap-common one.
> 
> Signed-off-by: Madan Srinivas 
> Signed-off-by: Daniel Allred 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 08/16] ti: AM43xx: board: Detect AM43xx HS EVM

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:10PM -0500, Daniel Allred wrote:

> From: Madan Srinivas 
> 
> Adds code to detect AM43xx HS EVMS - the string in the
> I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to
> for evm detection, regardless of whether the evm is for
> GP or HS parts, and updates board init to use that.
> 
> Modifies findfdt command to pick up am437x-gp-evm.dtb for
> the HS EVMs also, as the boards are similar except for
> some security specific changes around power supply and
> enclosure protection.
> 
> Signed-off-by: Madan Srinivas 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Andreas Dannenberg 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:

> Update the CPU string output so that the device
> type is now included as part of the CPU string that
> is printed as the SPL or u-boot comes up. This update
> adds a suffix of the form "-GP" or "-HS" for production
> devices, so that general purpose (GP) and high security
> (HS) can be distiguished. Applies to all OMAP5 variants.
[snip]
> diff --git a/arch/arm/include/asm/arch-omap4/cpu.h 
> b/arch/arm/include/asm/arch-omap4/cpu.h
> index f7595ae..34609b9 100644
> --- a/arch/arm/include/asm/arch-omap4/cpu.h
> +++ b/arch/arm/include/asm/arch-omap4/cpu.h
> @@ -59,6 +59,13 @@ struct watchdog {
>  #define TCLR_AR  (0x1 << 1)
>  #define TCLR_PRE (0x1 << 5)
>  
> +/* device type */
> +#define DEVICE_MASK (BIT(8) | BIT(9) | BIT(10))
> +#define TST_DEVICE  0x0
> +#define EMU_DEVICE  0x1
> +#define HS_DEVICE   0x2
> +#define GP_DEVICE   0x3

Lets move these to arch/arm/include/asm/omap_common.h (which someday we
need to re-work using the mach infrastructure or similar).

-- 
Tom


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

Re: [U-Boot] [PATCH 10/16] ti_omap5_common: Update SPL start address on secure parts

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:12PM -0500, Daniel Allred wrote:

> Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
> the start address past secure reserved memory and the size of the
> security certificate that precedes the boot image on secure devices).
> Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
> internal memory actually available on the various device flavors
> (Common minimum internal RAM guaranteed for various flavors of
> DRA7xx/AM57xx is 512KB).
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 
> ---
>  include/configs/ti_omap5_common.h | 32 +++-
>  1 file changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/ti_omap5_common.h 
> b/include/configs/ti_omap5_common.h
> index 202b18c..b2d4a0b 100644
> --- a/include/configs/ti_omap5_common.h
> +++ b/include/configs/ti_omap5_common.h
> @@ -132,13 +132,35 @@
>  
>  /*
>   * SPL related defines.  The Public RAM memory map the ROM defines the
> - * area between 0x4030 and 0x4031E000 as a download area for OMAP5
> - * (dra7xx is larger, but we do not need to be larger at this time).  We
> - * set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and
> + * area between 0x4030 and 0x4031E000 as a download area for OMAP5.
> + * On DRA7xx/AM57XX the download area is between 0x4030 and 0x4037E000.
> + * We set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and
>   * print some information.
>   */
> -#define CONFIG_SPL_TEXT_BASE 0x4030
> -#define CONFIG_SPL_MAX_SIZE  (0x4031E000 - CONFIG_SPL_TEXT_BASE)
> +#ifdef CONFIG_TI_SECURE_DEVICE
> +/*
> + * For memory booting on HS parts, the first 4KB of the internal RAM is
> + * reserved for secure world use and the flash loader image is
> + * preceded by a secure certificate. The SPL will therefore run in internal
> + * RAM from address 0x40301350 (0x4030+0x1000(reserved)+0x350(cert)).
> + */
> +#define CONFIG_SECURE_BOOT_SRAM 0x1000

I don't like setting CONFIG_SECURE_BOOT_SRAM as it's not configurable.
I see it's used later in the series but I think we should toggle that on
CONFIG_TI_SECURE_DEVICE and then reference things like
TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ or whatever makes sense.

-- 
Tom


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

Re: [U-Boot] [PATCH 14/16] ARM: omap5: add ft_board_setup for dra7xx/am57xx

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:16PM -0500, Daniel Allred wrote:

> Adds the board specific ft_board_setup() functions that
> are called when CONFIG_OF_BOARD_SETUP is defined. These functions
> will currently just call the ft_cpu_setup() function.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 11/16] spl: build: ti: add support for secure boot images

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:13PM -0500, Daniel Allred wrote:

> Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
> is in use (which it should be when building for secure parts),
> the TI secure development package is used to create a valid
> secure boot image. The u-boot SPL build processes is NOT aware
> of the details of creating the boot image - all of that information
> is encapsulated in the TI secure development package, which is
> available from TI. More info can be found in README.ti-secure
> 
> Right now, two image types are generated, MLO and X-LOADER. The types
> are important, as certain boot modes implemented by the device's ROM
> boot loader require one or the other (they are not equivalent). The
> output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
> u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
> the name that the device ROM bootloader requires for loading from the
> FAT partition of an SD card (same as on non-secure devices).
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 13/16] ARM: omap5: add hooks for cpu/SoC fdt fixups

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:15PM -0500, Daniel Allred wrote:

> Adds an fdt.c file in that defines the ft_cpu_setup() function,
> which should be called from a board-specific ft_board_setup()).
> This ft_cpu_setup() will currently do nothing for non-secure (GP)
> devices   but contains pertinent updates for booting on secure (HS)
> devices.
> 
> Update the omap5 Makefile to include the fdt.c in the build.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Conceptually fine but will need reworking based on my previous comments.

-- 
Tom


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

Re: [U-Boot] [PATCH v6 2/7] net: zynq_gem: Add the passing of the phy-handle node

[Michal Simek]

On 21.4.2016 13:51, Tom Rini wrote:
> On Thu, Apr 21, 2016 at 07:46:34AM +0200, Michal Simek wrote:
>> On 20.4.2016 21:41, Dan Murphy wrote:
>>> Bump?
>>> On 04/15/2016 07:27 AM, Dan Murphy wrote:
 Add the ability to pass the phy-handle node offset
 to the phy driver.  This allows the phy driver
 to access the DT subnode's data and parse accordingly.

 Signed-off-by: Dan Murphy 
 Tested-by: Michal Simek 
 ---

 v6 - No changes - https://patchwork.ozlabs.org/patch/608769/

  drivers/net/zynq_gem.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)
>>
>>
>> Joe, Tom: Do you want to take this series?
>> I am happy to do so because there is xilinx part.
> 
> If Joe doesn't want to take it, I will.

Ok. Thanks,
Michal


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

Re: [U-Boot] [PATCH 01/16] doc: Add info on using secure devices from TI

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:03PM -0500, Daniel Allred wrote:

> Adds doc/README.ti-secure file to explain in generic terms
> how boot images need to be created for secure devices from
> Texas Instruments.
> 
> Specific details for creating secure boot images for the
> AM43xx, DRA7xx and AM57xx secure devices from Texas
> Instruments are also provided in the README file.
> 
> Secure devices require a security development package (SECDEV)
> package that can be downloaded from:
> 
>   http://www.ti.com/mysecuresoftware
> 
> Login is required and access is granted under appropriate NDA
> and export control restrictions.
> 
> Signed-off-by: Madan Srinivas 
> Signed-off-by: Daniel Allred 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 02/16] arm: am33xx: Kconfig: Add secure device definitions

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:04PM -0500, Daniel Allred wrote:

> From: Madan Srinivas 
> 
> Adds a new Kconfig file for AM33xx class devices. We
> need a common place to define CONFIG parameters
> for these SOCs, especially for adding support
> for secure devices.
> 
> a) Adds a definition for ISW_ENTRY_ADDR. This is the
> address to which the ROM branches when the SOC
> ROM hands off execution to the boot loader.
> CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
> to this value for AM43xx devices.
> 
> b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
> calculate CONFIG_SPL_MAX_SIZE. This value indicates the
> amount of memory needed by the ROM to store data during
> the boot process.
> 
> Currently, these CONFIG options are used only by AM43xx,
> but in future other AM33xx class SOCs will also use them.
> 
> Signed-off-by: Madan Srinivas 
> Signed-off-by: Daniel Allred 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 7/7] ARM: hikey: Simplify README instructions.

[Tom Rini]

On Wed, Apr 20, 2016 at 05:14:03PM +0100, Peter Griffin wrote:

> This patch updates and simplifies the hikey README. The old
> instructions were hard to follow, and convoluted.
> 
> This patch also updates the link to the mcuimage.bin which was outdated.
> 
> Using an outdated mcuimage.bin results in the additional a53 cores
> not coming online when the kernel issues PSCI requests to
> arm trusted firmware (ATF).
> 
> Signed-off-by: Peter Griffin 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [ANN] U-Boot v2016.05-rc2 released

[Tom Rini]

Hey all,

As promised, and only slightly late, here's -rc2.  I've picked up a
bunch of things that were outstanding and I had grabbed in patchwork and
I felt should come in now rather than wait for the next window.  There's
some good work going on in SPL land that I'm going to let wait since we
aren't quite able to make real use of it yet but I'm otherwise happy
with.

I forgot to mention this with -rc1 but I'm going to mention it again now
like I had intended to anyhow.  For ARM platforms, the EFI loader code
is enabled by default.  I'm quite happy to see people turn it off if
they believe their board has no use case for it but as I think this will
help the out of box experience for many end users I'm of the opinion it
should default to on, not off.  Thanks all!

-- 
Tom


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

Re: [U-Boot] [PATCH 06/16] ti: AM43xx: config.mk: Add support for generating secure boot images

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:08PM -0500, Daniel Allred wrote:

> Modifies the config.mk to build secure images when building
> the SPL for secure devices.
> 
> Depending on the boot media, different images are needed
> for secure devices. The build generates u-boot*_HS_* files
> as appropriate for the different boot modes. The same u-boot
> binary file is processed slightly differently to produce a
> different boot image, depending on whether the user wants to
> boot off SPI, QSPI or other boot media.
> 
> Refer to README.ti-secure for more information.
> 
> Signed-off-by: Madan Srinivas 
> Signed-off-by: Daniel Allred 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 05/16] ti: omap-common: Add commands for generating secure SPL images

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:07PM -0500, Daniel Allred wrote:

> Adds a centralized config_secure.mk in omap-common for
> OMAP-style TI secure devices to use for boot image generation
> 
> Depending on the boot media, different images are needed for
> secure devices. These commands generates u-boot*_HS_* files that
> need to be used to boot secure devices.
> 
> Please refer to README.ti-secure for more information.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 6/7] ARM: hisilicon: hikey: Align memory node with upstream kernel

[Tom Rini]

On Wed, Apr 20, 2016 at 05:14:02PM +0100, Peter Griffin wrote:

> The memory node gets automatically generated by U-Boot
> in arch_fixup_fdt(), before passing control to the kernel
> using U-Boots representation of the dram banks.
> 
> However the upstream kernel uses the memory node to carve-out
> regions of RAM for various purposes. To make this work without
> changing arch_fixup_fdt() which will effect many platforms
> we replicate the upstream memory node layout using the dram
> banks.
> 
> Signed-off-by: Peter Griffin 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 4/7] ARM: hisilicon: hikey: Implement reset_cpu() for hikey.

[Tom Rini]

On Wed, Apr 20, 2016 at 05:14:00PM +0100, Peter Griffin wrote:

> This allows the reset command to reset the board from
> u-boot.
> 
> => reset
> resetting ...
> INFO:BL1: 0xf981 - 0xf9818000 [size = 32768]
> NOTICE:  Booting Trusted Firmware
> NOTICE:  BL1: v1.1(debug):7fb9b0e
> NOTICE:  BL1: Built : 17:06:41, Apr 19 2016
> 
> Signed-off-by: Peter Griffin 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/7] MAINTAINERS: Add myself as maintainer for hikey

[Tom Rini]

On Wed, Apr 20, 2016 at 05:13:58PM +0100, Peter Griffin wrote:

> This patch adds myself as maintainer for the hikey
> U-Boot port.
> 
> Signed-off-by: Peter Griffin 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 3/7] ARM: hisilicon: hikey: Enable OF_CONTROL for hikey board.

[Tom Rini]

On Wed, Apr 20, 2016 at 05:13:59PM +0100, Peter Griffin wrote:

> Currently only the serial pl01x driver is using DT,
> and the other drivers still use platform data but
> as more DT lands in the upstream kernel the aim is
> to migrate the other drivers over to DT as well to
> have a fully DT configured hikey u-boot.
> 
> Signed-off-by: Peter Griffin 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts

[Tom Rini]

On Fri, Apr 15, 2016 at 03:28:07PM +0530, Lokesh Vutla wrote:
> 
> 
> On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> > From: Madan Srinivas 
> > 
> > Adds new defconfig files for AM43xx secure devices.
> > These are the same as the non-secure parts, except for
> > CONFIG_TI_SECURE_DEVICE option set to 'y'
> > CONFIG_ISW_ENTRY_ADDR updated for secure images.
> > 
> > Signed-off-by: Daniel Allred 
> > Signed-off-by: Madan Srinivas 
> > ---
> >  configs/am43xx_hs_evm_defconfig  | 12 
> >  configs/am43xx_hs_evm_ethboot_defconfig  | 11 +++
> >  configs/am43xx_hs_evm_qspiboot_defconfig | 10 ++
> >  configs/am43xx_hs_evm_rtconly_defconfig  | 12 
> 
> You do not need this defconfig. Also now only DT enabled configs are
> accepted. Ill let Tom to comment here.

Yes, just like was done for the dra7xa/am57xx HS parts, we need to be
doing DM+DT here too.

-- 
Tom


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

Re: [U-Boot] [PATCH 16/16] defconfig: ti: Add configs for OMAP5-class secure parts

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:18PM -0500, Daniel Allred wrote:

> Adds new defconfig files for DRA7xx and AM57xx secure devices.
> These are the same as the non-secure parts, but with the addition
> of the CONFIG_TI_SECURE_DEVICE option set to 'y'.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/7] ARM: hisilicon: hikey: Add hikey & hi6220 dts from v4.6-rc3.

[Tom Rini]

On Wed, Apr 20, 2016 at 05:13:57PM +0100, Peter Griffin wrote:

> Import the upstream kernel dts into U-Boot. Currently
> only serial is supported, but a lot more DT changes are
> queued for v4.7.
> 
> Signed-off-by: Peter Griffin 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 15/16] ARM: omap5: Add config for board/cpu fdt fixups

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:17PM -0500, Daniel Allred wrote:

> Adds CONFIG_OF_BOARD_SETUP to the config header files
> for dra7xx_evm and am57xx_evm.
> 
> Signed-off-by: Daniel Allred 
> Signed-off-by: Madan Srinivas 

Fold this into the patch that adds the functions, thanks.

-- 
Tom


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