date:20171009

Re: [U-Boot] [PATCH 06/11] efi_loader: implement SetWatchdogTimer

2017-10-09 Thread Alexander Graf



On 09.10.17 08:05, Heinrich Schuchardt wrote:
> On 10/09/2017 06:42 AM, Alexander Graf wrote:
>>
>>
>> On 08.10.17 06:57, Heinrich Schuchardt wrote:
>>> The watchdog is initialized with a 5 minute timeout period.
>>> It can be reset by SetWatchdogTimer.
>>> It is stopped by ExitBoottimeServices.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>  cmd/bootefi.c |  1 +
>>>  include/efi_loader.h  |  4 +++
>>>  lib/efi_loader/Makefile   |  2 +-
>>>  lib/efi_loader/efi_boottime.c | 15 ++-
>>>  lib/efi_loader/efi_watchdog.c | 59 
>>> +++
>>>  5 files changed, 67 insertions(+), 14 deletions(-)
>>>  create mode 100644 lib/efi_loader/efi_watchdog.c
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index b7087e3da8..24958ada46 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -43,6 +43,7 @@ static void efi_init_obj_list(void)
>>>  #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>>> efi_smbios_register();
>>>  #endif
>>> +   efi_watchdog_register();
>>>  
>>> /* Initialize EFI runtime services */
>>> efi_reset_system_init();
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index e1179b7dcd..223d8d8222 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -163,6 +163,8 @@ int efi_disk_register(void);
>>>  int efi_gop_register(void);
>>>  /* Called by bootefi to make the network interface available */
>>>  int efi_net_register(void);
>>> +/* Called by bootefi to make the watchdog available */
>>> +int efi_watchdog_register(void);
>>>  /* Called by bootefi to make SMBIOS tables available */
>>>  void efi_smbios_register(void);
>>>  
>>> @@ -171,6 +173,8 @@ efi_fs_from_path(struct efi_device_path *fp);
>>>  
>>>  /* Called by networking code to memorize the dhcp ack package */
>>>  void efi_net_set_dhcp_ack(void *pkt, int len);
>>> +/* Called by efi_set_watchdog_timer to reset the timer */
>>> +efi_status_t efi_set_watchdog(unsigned long timeout);
>>>  
>>>  /* Called from places to check whether a timer expired */
>>>  void efi_timer_check(void);
>>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>>> index ddb978f650..83d879b686 100644
>>> --- a/lib/efi_loader/Makefile
>>> +++ b/lib/efi_loader/Makefile
>>> @@ -17,7 +17,7 @@ endif
>>>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>>>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>>>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>>> -obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>>> +obj-y += efi_file.o efi_variable.o efi_bootmgr.o efi_watchdog.o
>>>  obj-$(CONFIG_LCD) += efi_gop.o
>>>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>>>  obj-$(CONFIG_PARTITIONS) += efi_disk.o
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index 30577f717e..81e7d818fc 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -155,18 +155,6 @@ void efi_signal_event(struct efi_event *event)
>>> event->is_queued = false;
>>>  }
>>>  
>>> -/*
>>> - * Write a debug message for an EPI API service that is not implemented 
>>> yet.
>>> - *
>>> - * @funcname   function that is not yet implemented
>>> - * @return EFI_UNSUPPORTED
>>> - */
>>> -static efi_status_t efi_unsupported(const char *funcname)
>>> -{
>>> -   debug("EFI: App called into unimplemented function %s\n", funcname);
>>> -   return EFI_EXIT(EFI_UNSUPPORTED);
>>> -}
>>> -
>>>  /*
>>>   * Raise the task priority level.
>>>   *
>>> @@ -1454,6 +1442,7 @@ static efi_status_t EFIAPI 
>>> efi_exit_boot_services(void *image_handle,
>>> bootm_disable_interrupts();
>>>  
>>> /* Give the payload some time to boot */
>>> +   efi_set_watchdog(0);
>>> WATCHDOG_RESET();
>>>  
>>> return EFI_EXIT(EFI_SUCCESS);
>>> @@ -1514,7 +1503,7 @@ static efi_status_t EFIAPI 
>>> efi_set_watchdog_timer(unsigned long timeout,
>>>  {
>>> EFI_ENTRY("%ld, 0x%"PRIx64", %ld, %p", timeout, watchdog_code,
>>>   data_size, watchdog_data);
>>> -   return efi_unsupported(__func__);
>>> +   return EFI_EXIT(efi_set_watchdog(timeout));
>>>  }
>>>  
>>>  /*
>>> diff --git a/lib/efi_loader/efi_watchdog.c b/lib/efi_loader/efi_watchdog.c
>>> new file mode 100644
>>> index 00..50e95290ea
>>> --- /dev/null
>>> +++ b/lib/efi_loader/efi_watchdog.c
>>> @@ -0,0 +1,59 @@
>>> +/*
>>> + *  EFI device path interface
>>
>> Not quite I guess?
>>
>>> + *
>>> + *  Copyright (c) 2017 Heinrich Schuchardt
>>> + *
>>> + *  SPDX-License-Identifier: GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +static struct efi_event *watchdog_timer_event;
>>> +
>>> +static void EFIAPI efi_watchdog_timer_notify(struct efi_event *event,
>>> +void *context)
>>> +{
>>> +   EFI_ENTRY("%p, %p", event, context);
>>> +
>>> +   printf("\nEFI: Watchdog timeout\n");
>>> +   EFI_CALL_VOID(efi_runtime_services.reset_system(EFI_RESET_COLD,
>>> +

Re: [U-Boot] [PATCH] usb: xhci: Add Renesas R-Car xHCI driver

2017-10-09 Thread Bin Meng

Hi Marek,

On Mon, Oct 9, 2017 at 2:34 AM, Marek Vasut  wrote:
> Add firmware V3, firmware loader and XHCI glue for the Renesas R-Car
> Gen3 SoCs XHCI controller. Thus far only the R-Car Gen3 R8A7795 ES2.0+
> and R8A7796 are supported.
>
> Signed-off-by: Marek Vasut 
> Cc: Nobuhiro Iwamatsu 
> ---
>  Licenses/r8a779x_usb3.txt|  26 ++
>  drivers/usb/host/Kconfig |   8 +
>  drivers/usb/host/Makefile|   1 +
>  drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h | 643 
> +++
>  drivers/usb/host/xhci-rcar.c | 161 +++
>  5 files changed, 839 insertions(+)
>  create mode 100644 Licenses/r8a779x_usb3.txt
>  create mode 100644 drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h
>  create mode 100644 drivers/usb/host/xhci-rcar.c
>
> diff --git a/Licenses/r8a779x_usb3.txt b/Licenses/r8a779x_usb3.txt
> new file mode 100644
> index 00..e2afcc9e81
> --- /dev/null
> +++ b/Licenses/r8a779x_usb3.txt
> @@ -0,0 +1,26 @@
> +Copyright (c) 2014, Renesas Electronics Corporation
> +All rights reserved.
> +
> +Redistribution and use in binary form, without modification, are permitted
> +provided that the following conditions are met:
> +
> +1. Redistribution in binary form must reproduce the above copyright notice,
> +   this list of conditions and the following disclaimer in the documentation
> +   and/or other materials provided with the distribution.
> +2. The name of Renesas Electronics Corporation may not be used to endorse or
> +   promote products derived from this software without specific prior written
> +   permission.
> +3. Reverse engineering, decompilation, or disassembly of this software is
> +   not permitted.
> +
> +THIS SOFTWARE IS PROVIDED "AS IS" AND RENESAS ELECTRONICS CORPORATION 
> DISCLAIMS
> +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND
> +NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL RENESAS ELECTRONICS
> +CORPORATION BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
> EXEMPLARY,
> +OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> +POSSIBILITY OF SUCH DAMAGE.

Is there any SPDX form of this license?

> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index f5f19ed775..cad9af6977 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -47,6 +47,14 @@ config USB_XHCI_ROCKCHIP
> help
>   Enables support for the on-chip xHCI controller on Rockchip SoCs.
>
> +config USB_XHCI_RCAR
> +   bool "Renesas RCar USB 3.0 support"
> +   default y
> +   depends on ARCH_RMOBILE
> +   help
> + Choose this option to add support for USB 3.0 driver on Renesas
> + RCar Gen3 SoCs.
> +
>  config USB_XHCI_STI
> bool "Support for STMicroelectronics STiH407 family on-chip xHCI USB 
> controller"
> depends on ARCH_STI
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 83903fcf99..79df888fce 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -59,6 +59,7 @@ obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o
>  obj-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o
>  obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
>  obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
> +obj-$(CONFIG_USB_XHCI_RCAR) += xhci-rcar.o
>  obj-$(CONFIG_USB_XHCI_STI) += dwc3-sti-glue.o
>
>  # designware
> diff --git a/drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h 
> b/drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h
> new file mode 100644
> index 00..f0f48a3354
> --- /dev/null
> +++ b/drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h
> @@ -0,0 +1,643 @@
> +/*
> + * Renesas RCar xHCI controller firmware version 3
> + *
> + * Copyright (c) 2014, Renesas Electronics Corporation
> + * All rights reserved.
> + *
> + * Redistribution and use in binary form, without modification, are permitted
> + * provided that the following conditions are met:
> + *
> + * 1. Redistribution in binary form must reproduce the above copyright 
> notice,
> + *this list of conditions and the following disclaimer in the 
> documentation
> + *and/or other materials provided with the distribution.
> + * 2. The name of Renesas Electronics Corporation may not be used to endorse 
> or
> + *promote products derived from this software without specific prior 
> written
> + *permission.
> + * 3. Reverse engineering, decompilation, or disassembly of this software is
> + *not permitted.
> + *
> + * THIS SOFTWARE IS PROVIDED "AS IS" AND RENESAS ELECTRONICS CORPORATION 
> DISCLAIMS
> + * ANY EXPRESS OR IMPLIED WARRANTI

Re: [U-Boot] [PATCH v3] sun50i: h5: Add NanoPi Neo Plus2 DT initial support

2017-10-09 Thread Maxime Ripard

On Fri, Oct 06, 2017 at 09:11:22AM +, Antony Antony wrote:
> Hi
> 
> Thanks Chen-Yu and Maxime.
> 
> On Tue, Oct 03, 2017 at 10:11:00AM +0800, Chen-Yu Tsai wrote:
> > On Mon, Oct 2, 2017 at 1:34 AM, Antony Antony  wrote:
> > > Hi Maxime,
> > >
> > > sorry for the delayed response.
> > >
> > > On Mon, Sep 25, 2017 at 01:12:23PM +0200, Maxime Ripard wrote:
> > >> On Sat, Sep 23, 2017 at 05:59:15PM +, Antony Antony wrote:
> > >> > Add initial DT for NanoPi NEO Plus2 by FriendlyARM
> > >> > - Allwinner quad core H5 Cortex A53 with an ARM Mali-450MP GPU
> > >> > - 1 GB DDR3 RAM
> > >> > - 8GB eMMC flash (Samsung KLM8G1WEPD-B031)
> > >> > - micro SD card slot
> > >> > - Gigabit Ethernet (external RTL8211E-VB-CG chip)
> > >> > - 802.11 b/g/n WiFi, Bluetooth 4.0 (Ampak AP6212A module)
> > >> > - 2x USB 2.0 host ports
> > >> >
> > >> > Signed-off-by: Antony Antony 
> > >> > ---
> > >> > Changes v1->v2
> > >> >  removed memory {}, compatible ="allwinner,sun5i-a13-mmc"
> > >> >  remove CONFIG_SPL_SPI_FLASH_SUPPORT=y and CONFIG_SPL_SPI_SUNXI=y (no 
> > >> > SPI)
> > >> >  remove CONFIG_SD_BOOT=y
> > >> > Changes v2->v3
> > >> >  removed compatible ="allwinner,sun50i-a64-mmc"
> > >> > ---
> > >> >  arch/arm/dts/Makefile   |   1 +
> > >> >  arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 107 
> > >> > 
> > >> >  configs/nanopi_neo_plus2_defconfig  |  18 +
> > >> >  3 files changed, 126 insertions(+)
> > >> >  create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > >> >  create mode 100644 configs/nanopi_neo_plus2_defconfig
> > >> >
> > >> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > >> > index fee4680..295a675 100644
> > >> > --- a/arch/arm/dts/Makefile
> > >> > +++ b/arch/arm/dts/Makefile
> > >> > @@ -333,6 +333,7 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
> > >> > sun8i-v3s-licheepi-zero.dtb
> > >> >  dtb-$(CONFIG_MACH_SUN50I_H5) += \
> > >> > sun50i-h5-nanopi-neo2.dtb \
> > >> > +   sun50i-h5-nanopi-neo-plus2.dtb \
> > >> > sun50i-h5-orangepi-pc2.dtb \
> > >> > sun50i-h5-orangepi-prime.dtb \
> > >> > sun50i-h5-orangepi-zero-plus2.dtb
> > >> > diff --git a/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts 
> > >> > b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > >> > new file mode 100644
> > >> > index 000..8ac098e
> > >> > --- /dev/null
> > >> > +++ b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > >> > @@ -0,0 +1,107 @@
> > >> > +/*
> > >> > + * Copyright (C) 2017 Antony Antony 
> > >> > + * Copyright (c) 2016 ARM Ltd.
> > >> > + *
> > >> > + * This file is dual-licensed: you can use it either under the terms
> > >> > + * of the GPL or the X11 license, at your option. Note that this dual
> > >> > + * licensing only applies to this file, and not this project as a
> > >> > + * whole.
> > >> > + *
> > >> > + *  a) This library 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.
> > >> > + *
> > >> > + * This library is distributed in the hope that it will be useful,
> > >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > >> > + * GNU General Public License for more details.
> > >> > + *
> > >> > + * Or, alternatively,
> > >> > + *
> > >> > + *  b) Permission is hereby granted, free of charge, to any person
> > >> > + * obtaining a copy of this software and associated documentation
> > >> > + * files (the "Software"), to deal in the Software without
> > >> > + * restriction, including without limitation the rights to use,
> > >> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > >> > + * sell copies of the Software, and to permit persons to whom the
> > >> > + * Software is furnished to do so, subject to the following
> > >> > + * conditions:
> > >> > + *
> > >> > + * The above copyright notice and this permission notice shall be
> > >> > + * included in all copies or substantial portions of the Software.
> > >> > + *
> > >> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > >> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > >> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > >> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > >> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > >> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > >> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > >> > + * OTHER DEALINGS IN THE SOFTWARE.
> > >> > + */
> > >> > +
> > >> > +/dts-v1/;
> > >> > +
> > >> > +#include "sun50i-h5.dtsi"
> > >> > +
> > >>

Re: [U-Boot] [PATCH v3] sun50i: h5: Add NanoPi Neo Plus2 DT initial support

2017-10-09 Thread Antony Antony

On Mon, Oct 09, 2017 at 09:22:03AM +0200, Maxime Ripard wrote:
> On Fri, Oct 06, 2017 at 09:11:22AM +, Antony Antony wrote:
> > Hi
> > 
> > Thanks Chen-Yu and Maxime.
> > 
> > On Tue, Oct 03, 2017 at 10:11:00AM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Oct 2, 2017 at 1:34 AM, Antony Antony  wrote:
> > > > Hi Maxime,
> > > >
> > > > sorry for the delayed response.
> > > >
> > > > On Mon, Sep 25, 2017 at 01:12:23PM +0200, Maxime Ripard wrote:
> > > >> On Sat, Sep 23, 2017 at 05:59:15PM +, Antony Antony wrote:
> > > >> > Add initial DT for NanoPi NEO Plus2 by FriendlyARM
> > > >> > - Allwinner quad core H5 Cortex A53 with an ARM Mali-450MP GPU
> > > >> > - 1 GB DDR3 RAM
> > > >> > - 8GB eMMC flash (Samsung KLM8G1WEPD-B031)
> > > >> > - micro SD card slot
> > > >> > - Gigabit Ethernet (external RTL8211E-VB-CG chip)
> > > >> > - 802.11 b/g/n WiFi, Bluetooth 4.0 (Ampak AP6212A module)
> > > >> > - 2x USB 2.0 host ports
> > > >> >
> > > >> > Signed-off-by: Antony Antony 
> > > >> > ---
> > > >> > Changes v1->v2
> > > >> >  removed memory {}, compatible ="allwinner,sun5i-a13-mmc"
> > > >> >  remove CONFIG_SPL_SPI_FLASH_SUPPORT=y and CONFIG_SPL_SPI_SUNXI=y 
> > > >> > (no SPI)
> > > >> >  remove CONFIG_SD_BOOT=y
> > > >> > Changes v2->v3
> > > >> >  removed compatible ="allwinner,sun50i-a64-mmc"
> > > >> > ---
> > > >> >  arch/arm/dts/Makefile   |   1 +
> > > >> >  arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 107 
> > > >> > 
> > > >> >  configs/nanopi_neo_plus2_defconfig  |  18 +
> > > >> >  3 files changed, 126 insertions(+)
> > > >> >  create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > >> >  create mode 100644 configs/nanopi_neo_plus2_defconfig
> > > >> >
> > > >> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > >> > index fee4680..295a675 100644
> > > >> > --- a/arch/arm/dts/Makefile
> > > >> > +++ b/arch/arm/dts/Makefile
> > > >> > @@ -333,6 +333,7 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
> > > >> > sun8i-v3s-licheepi-zero.dtb
> > > >> >  dtb-$(CONFIG_MACH_SUN50I_H5) += \
> > > >> > sun50i-h5-nanopi-neo2.dtb \
> > > >> > +   sun50i-h5-nanopi-neo-plus2.dtb \
> > > >> > sun50i-h5-orangepi-pc2.dtb \
> > > >> > sun50i-h5-orangepi-prime.dtb \
> > > >> > sun50i-h5-orangepi-zero-plus2.dtb
> > > >> > diff --git a/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts 
> > > >> > b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > >> > new file mode 100644
> > > >> > index 000..8ac098e
> > > >> > --- /dev/null
> > > >> > +++ b/arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts
> > > >> > @@ -0,0 +1,107 @@
> > > >> > +/*
> > > >> > + * Copyright (C) 2017 Antony Antony 
> > > >> > + * Copyright (c) 2016 ARM Ltd.
> > > >> > + *
> > > >> > + * This file is dual-licensed: you can use it either under the terms
> > > >> > + * of the GPL or the X11 license, at your option. Note that this 
> > > >> > dual
> > > >> > + * licensing only applies to this file, and not this project as a
> > > >> > + * whole.
> > > >> > + *
> > > >> > + *  a) This library 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.
> > > >> > + *
> > > >> > + * This library is distributed in the hope that it will be 
> > > >> > useful,
> > > >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty 
> > > >> > of
> > > >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > >> > + * GNU General Public License for more details.
> > > >> > + *
> > > >> > + * Or, alternatively,
> > > >> > + *
> > > >> > + *  b) Permission is hereby granted, free of charge, to any person
> > > >> > + * obtaining a copy of this software and associated 
> > > >> > documentation
> > > >> > + * files (the "Software"), to deal in the Software without
> > > >> > + * restriction, including without limitation the rights to use,
> > > >> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > > >> > + * sell copies of the Software, and to permit persons to whom 
> > > >> > the
> > > >> > + * Software is furnished to do so, subject to the following
> > > >> > + * conditions:
> > > >> > + *
> > > >> > + * The above copyright notice and this permission notice shall 
> > > >> > be
> > > >> > + * included in all copies or substantial portions of the 
> > > >> > Software.
> > > >> > + *
> > > >> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY 
> > > >> > KIND,
> > > >> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE 
> > > >> > WARRANTIES
> > > >> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > > >> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > > >> > + *

[U-Boot] [PATCH v1 1/3] test/py: gpt: update test_gpt

2017-10-09 Thread Patrick Delaunay

- copy the reference gpt binary file as it is modified during the test
  to avoid issue if the test fail: the test always restart with clean file
- update tests to highlight detected issues on gpt swap command
  (offset and size of partition are modified)
- add test for gpt verfiy, gpt read and gpt write

Signed-off-by: Patrick Delaunay 
---

 test/py/tests/test_gpt.py | 79 +++
 1 file changed, 66 insertions(+), 13 deletions(-)

diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py
index ec25fbb..1db65f7 100644
--- a/test/py/tests/test_gpt.py
+++ b/test/py/tests/test_gpt.py
@@ -11,7 +11,8 @@ import u_boot_utils
 
 """
 These tests rely on a 4 MB disk image, which is automatically created by
-the test.
+the test, but as we expect specific content and it is modified by the gpt
+commands executed during the test, it is not safe be reused it directly
 """
 
 class GptTestDiskImage(object):
@@ -28,26 +29,31 @@ class GptTestDiskImage(object):
 """
 
 filename = 'test_gpt_disk_image.bin'
+
 self.path = u_boot_console.config.persistent_data_dir + '/' + filename
+ref_path = u_boot_console.config.persistent_data_dir + '/ref_' + 
filename
 
-if os.path.exists(self.path):
-u_boot_console.log.action('Disk image file ' + self.path +
+if os.path.exists(ref_path):
+u_boot_console.log.action('Disk image file ' + ref_path +
 ' already exists')
 else:
-u_boot_console.log.action('Generating ' + self.path)
-fd = os.open(self.path, os.O_RDWR | os.O_CREAT)
+u_boot_console.log.action('Generating ' + ref_path)
+fd = os.open(ref_path, os.O_RDWR | os.O_CREAT)
 os.ftruncate(fd, 4194304)
 os.close(fd)
 cmd = ('sgdisk', '-U', '375a56f7-d6c9-4e81-b5f0-09d41ca89efe',
-self.path)
+ref_path)
 u_boot_utils.run_and_log(u_boot_console, cmd)
-cmd = ('sgdisk', '--new=1:2048:2560', self.path)
+cmd = ('sgdisk', '--new=1:2048:2560', ref_path)
 u_boot_utils.run_and_log(u_boot_console, cmd)
-cmd = ('sgdisk', '--new=2:4096:4608', self.path)
+cmd = ('sgdisk', '--new=2:4096:4608', ref_path)
 u_boot_utils.run_and_log(u_boot_console, cmd)
-cmd = ('sgdisk', '-l', self.path)
+cmd = ('sgdisk', '-l', ref_path)
 u_boot_utils.run_and_log(u_boot_console, cmd)
 
+cmd = ('cp', ref_path, self.path)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+
 gtdi = None
 @pytest.fixture(scope='function')
 def state_disk_image(u_boot_console):
@@ -64,6 +70,30 @@ def state_disk_image(u_boot_console):
 @pytest.mark.boardspec('sandbox')
 @pytest.mark.buildconfigspec('cmd_gpt')
 @pytest.mark.requiredtool('sgdisk')
+def test_gpt_read(state_disk_image, u_boot_console):
+"""Test the gpt read command."""
+
+u_boot_console.run_command('host bind 0 ' + state_disk_image.path)
+output = u_boot_console.run_command('gpt read host 0')
+assert 'Start 1MiB, size 0MiB' in output
+assert 'Start 2MiB, size 0MiB' in output
+output = u_boot_console.run_command('part list host 0')
+assert '0x0800 0x0a00  ""' in output
+assert '0x1000 0x1200  ""' in output
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_gpt')
+@pytest.mark.requiredtool('sgdisk')
+def test_gpt_verify(state_disk_image, u_boot_console):
+"""Test the gpt verify command."""
+
+u_boot_console.run_command('host bind 0 ' + state_disk_image.path)
+output = u_boot_console.run_command('gpt verify host 0')
+assert 'Verify GPT: success!' in output
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_gpt')
+@pytest.mark.requiredtool('sgdisk')
 def test_gpt_guid(state_disk_image, u_boot_console):
 """Test the gpt guid command."""
 
@@ -98,6 +128,9 @@ def test_gpt_rename_partition(state_disk_image, 
u_boot_console):
 u_boot_console.run_command('gpt rename host 0 2 second')
 output = u_boot_console.run_command('gpt read host 0')
 assert 'name second' in output
+output = u_boot_console.run_command('part list host 0')
+assert '0x0800 0x0a00  "first"' in output
+assert '0x1000 0x1200  "second"' in output
 
 @pytest.mark.boardspec('sandbox')
 @pytest.mark.buildconfigspec('cmd_gpt')
@@ -109,9 +142,29 @@ def test_gpt_swap_partitions(state_disk_image, 
u_boot_console):
 
 u_boot_console.run_command('host bind 0 ' + state_disk_image.path)
 output = u_boot_console.run_command('part list host 0')
-assert '0x07ff "first"' in output
-assert '0x17ff "second"' in output
+assert '0x0800 0x0a00  "first"' in output
+assert '0x1000 0x1200  "second"' in output
 u_boot_console.run_command('gpt swap host 0 first second')
 output = u_boot_console.

[U-Boot] [PATCH v1 2/3] disk: efi: correct the overlap check on GPT header and PTE

2017-10-09 Thread Patrick Delaunay

the partition starting at 0x4400 is refused with overlap error:
  $> gpt write mmc 0 "name=test,start=0x4400,size=0"
  Writing GPT: Partition overlap
  error!

even if the 0x4400 is the first available offset for LBA35 with default
value:
- MBR=LBA1
- GPT header=LBA2
- PTE= 32 LBAs (128 entry), 3 to 34

And the command to have one partition for all the disk failed also :
  $> gpt write mmc 0 "name=test,size=0"

After the patch :

  $> gpt write mmc 0 "name=test,size=0"
  Writing GPT: success!
  $> part list mmc 0

  Partition Map for MMC device 0  --   Partition Type: EFI

  Part  Start LBA   End LBA Name
Attributes
Type GUID
Partition GUID
  1 0x0022  0x01ce9fde  "test"
attrs:  0x
type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
type:   data
guid:   b4b84b8a-04e3-4000-0036-aff5c9c495b1

And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected

Signed-off-by: Patrick Delaunay 
---

 disk/part_efi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 0abf487..2992d9e 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -469,8 +469,8 @@ int gpt_fill_pte(struct blk_desc *dev_desc,
 * If our partition overlaps with either the GPT
 * header, or the partition entry, reject it.
 */
-   if (((start <= hdr_end && hdr_start <= (start + size)) ||
-(start <= pte_end && pte_start <= (start + size {
+   if (((start < hdr_end && hdr_start < (start + size)) ||
+(start < pte_end && pte_start < (start + size {
printf("Partition overlap\n");
return -1;
}
-- 
2.7.4

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

[U-Boot] [PATCH v1 3/3] cmd: gpt: solve issue for swap

2017-10-09 Thread Patrick Delaunay

don't use prettyprint_part_size() in create_gpt_partitions_list()
that avoid to align offset and size to 1 MiB and increase precision for
start and size
This patch avoid the risk to change partition and lost data during swap

Signed-off-by: Patrick Delaunay 
---

 cmd/gpt.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index d4406e3..38d09c6 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -282,14 +282,14 @@ static int create_gpt_partitions_list(int numparts, const 
char *guid,
strcat(partitions_list, "name=");
strncat(partitions_list, (const char *)curr->gpt_part_info.name,
PART_NAME_LEN + 1);
-   strcat(partitions_list, ",start=");
-   prettyprint_part_size(partstr, (unsigned 
long)curr->gpt_part_info.start,
- (unsigned long) 
curr->gpt_part_info.blksz);
+   sprintf(partstr, ",start=0x%llx",
+   (unsigned long long)curr->gpt_part_info.start *
+   curr->gpt_part_info.blksz);
/* one extra byte for NULL */
strncat(partitions_list, partstr, PART_NAME_LEN + 1);
-   strcat(partitions_list, ",size=");
-   prettyprint_part_size(partstr, curr->gpt_part_info.size,
- curr->gpt_part_info.blksz);
+   sprintf(partstr, ",size=0x%llx",
+   (unsigned long long)curr->gpt_part_info.size *
+   curr->gpt_part_info.blksz);
strncat(partitions_list, partstr, PART_NAME_LEN + 1);
 
strcat(partitions_list, ",uuid=");
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/1] rockchip: provide installation instruction for Firefly-RK3399.

2017-10-09 Thread Mark Kettenis

> From: Simon Glass 
> Date: Sun, 8 Oct 2017 22:41:50 -0600
> 
> On 27 September 2017 at 21:35, Heinrich Schuchardt  wrote:
> > Unfortunately installing U-Boot on an SD card for the Firefly-RK3399
> > is not trivial.
> >
> > I could not get U-Boot running with SPL.  So I ended up using the
> > Rockchip miniloader.
> >
> > Adding a README hopefully will give other users an easier start.
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  board/rockchip/firefly_rk3399/README | 55 
> > 
> >  1 file changed, 55 insertions(+)
> >  create mode 100644 board/rockchip/firefly_rk3399/README
> 
> Reviewed-by: Simon Glass 

Hmm,

Do we really want to push people in this direction, using propriatary,
closed-source binaries?

The "pure" U-Boot approach that is currently documented works just
fine.  The only problem is that the firefly-rk3399 by default boots
from eMMC.  And the first-stage bootloader only recognizes SD-cards
with the propriatary loader.  So the trick is to wipe the firmware
stored in eMMC or replace it with U-Boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 011/080] clk: clk-uclass: Fix style violations

2017-10-09 Thread Mario Six

Hi Simon,

On Mon, Oct 9, 2017 at 6:46 AM, Simon Glass  wrote:
> On 29 September 2017 at 06:51, Mario Six  wrote:
>> checkpatch.pl complains that the clk_ops structures used in clk-uclass.c
>> ought to be static, so we mark them as static.
>
> Do you mean static, or const?
>

I meant const; I'll fix the commit message and text in v2.

> Otherwise:
>
> Reviewed-by: Simon Glass 
>

Best regards,

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

Re: [U-Boot] [PATCH] dm: video: make ANSI escape sequence support optional

2017-10-09 Thread Anatolij Gustschin

Hi Rob, Simon,

On Fri, 6 Oct 2017 11:04:24 -0600
Simon Glass s...@chromium.org wrote:
...
> > So I think you should drop/revert this patch  
> 
> Seems reasonable to me.

OK, I dropped it.

Thanks,

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

[U-Boot] Please pull u-boot-video/master

2017-10-09 Thread Anatolij Gustschin

Hi Tom,

The following changes since commit ec4e99a4a24c84069c710df3202ecb1e501ff60f:

  Merge git://git.denx.de/u-boot-mmc (2017-09-28 23:31:11 -0400)

are available in the git repository at:

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

for you to fetch changes up to 40186ee213794d1a6e47e787aa424b3587711289:

  video: test: Add ANSI escape sequence tests (2017-09-29 17:59:58 +0200)


Rob Clark (5):
  dm: video: Fix cache flushes
  dm: video: Add basic ANSI escape sequence support
  dm: video: Add color ANSI escape sequence support
  video: test: Helper for writing strings
  video: test: Add ANSI escape sequence tests

Wenyou Yang (5):
  board: sama5d2_xplained: Convert to CONFIG_DM_VIDEO
  board: sama5d3xek: Convert to CONFIG_DM_VIDEO
  board: sama5d4ek: Convert to CONFIG_DM_VIDEO
  board: sama5d4_xplained: Convert to CONFIG_DM_VIDEO
  board: at91sam9x5ek: Convert to CONFIG_DM_VIDEO

 arch/arm/dts/at91-sama5d2_xplained.dts  |  60 +++
 arch/arm/dts/at91-sama5d4_xplained.dts  |  25 +++
 arch/arm/dts/at91-sama5d4ek.dts |  26 +++
 arch/arm/dts/sama5d2.dtsi   |   7 +
 arch/arm/dts/sama5d36ek_cmp.dts |   1 +
 arch/arm/dts/sama5d3_lcd.dtsi   |  21 +--
 arch/arm/dts/sama5d3xdm.dtsi|  26 +++
 arch/arm/dts/sama5d4.dtsi   |  21 +--
 arch/arm/mach-at91/Kconfig  |   4 +
 board/atmel/at91sam9x5ek/at91sam9x5ek.c | 111 +
 board/atmel/common/video_display.c  |   2 +-
 board/atmel/sama5d2_xplained/sama5d2_xplained.c |  95 +--
 board/atmel/sama5d3xek/sama5d3xek.c |  83 +-
 board/atmel/sama5d4_xplained/sama5d4_xplained.c | 102 +---
 board/atmel/sama5d4ek/sama5d4ek.c   |  97 +--
 configs/at91sam9x5ek_dataflash_defconfig|   3 +-
 configs/at91sam9x5ek_mmc_defconfig  |   3 +-
 configs/at91sam9x5ek_nandflash_defconfig|   3 +-
 configs/at91sam9x5ek_spiflash_defconfig |   3 +-
 configs/sama5d2_xplained_mmc_defconfig  |   2 +
 configs/sama5d2_xplained_spiflash_defconfig |   2 +
 configs/sama5d36ek_cmp_mmc_defconfig|   3 +-
 configs/sama5d36ek_cmp_nandflash_defconfig  |   3 +-
 configs/sama5d36ek_cmp_spiflash_defconfig   |   3 +-
 configs/sama5d3xek_mmc_defconfig|   3 +-
 configs/sama5d3xek_nandflash_defconfig  |   3 +-
 configs/sama5d3xek_spiflash_defconfig   |   3 +-
 configs/sama5d4_xplained_mmc_defconfig  |   2 +
 configs/sama5d4_xplained_nandflash_defconfig|   2 +
 configs/sama5d4_xplained_spiflash_defconfig |   2 +
 configs/sama5d4ek_mmc_defconfig |   3 +-
 configs/sama5d4ek_nandflash_defconfig   |   3 +-
 configs/sama5d4ek_spiflash_defconfig|   3 +-
 drivers/video/Kconfig   |   8 +
 drivers/video/vidconsole-uclass.c   | 205 
 drivers/video/video-uclass.c|   4 +-
 include/configs/at91sam9x5ek.h  |  10 --
 include/configs/sama5d2_xplained.h  |  12 --
 include/configs/sama5d3xek.h|   9 --
 include/configs/sama5d4_xplained.h  |  11 --
 include/configs/sama5d4ek.h |   9 --
 include/video.h |   7 +
 include/video_console.h |  11 ++
 test/dm/video.c |  58 +--
 44 files changed, 495 insertions(+), 579 deletions(-)

Thanks,

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

[U-Boot] [PATCH][v2] driver: fsl-mc: memset pointers after malloc

2017-10-09 Thread Prabhakar Kushwaha

Memory allocated via malloc is not guaranteed to be zeroized.

So explicitly memset the memory allocated via malloc.

Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Replaced malloc/memset with calloc

 drivers/net/fsl-mc/mc.c | 39 +--
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 458c458..05d3358 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -725,9 +725,9 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
 * Initialize the global default MC portal
 * And check that the MC firmware is responding portal commands:
 */
-   root_mc_io = (struct fsl_mc_io *)malloc(sizeof(struct fsl_mc_io));
+   root_mc_io = (struct fsl_mc_io *)calloc(sizeof(struct fsl_mc_io), 1);
if (!root_mc_io) {
-   printf(" No memory: malloc() failed\n");
+   printf(" No memory: calloc() failed\n");
return -ENOMEM;
}
 
@@ -877,11 +877,12 @@ static int dpio_init(void)
struct dpio_cfg dpio_cfg;
int err = 0;
 
-   dflt_dpio = (struct fsl_dpio_obj *)malloc(sizeof(struct fsl_dpio_obj));
+   dflt_dpio = (struct fsl_dpio_obj *)calloc(
+   sizeof(struct fsl_dpio_obj), 1);
if (!dflt_dpio) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
dpio_cfg.channel_mode = DPIO_LOCAL_CHANNEL;
@@ -946,7 +947,7 @@ err_get_attr:
dpio_destroy(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpio->dpio_handle);
 err_create:
free(dflt_dpio);
-err_malloc:
+err_calloc:
return err;
 }
 
@@ -1028,11 +1029,11 @@ static int dprc_init(void)
goto err_create;
}
 
-   dflt_mc_io = (struct fsl_mc_io *)malloc(sizeof(struct fsl_mc_io));
+   dflt_mc_io = (struct fsl_mc_io *)calloc(sizeof(struct fsl_mc_io), 1);
if (!dflt_mc_io) {
err  = -ENOMEM;
-   printf(" No memory: malloc() failed\n");
-   goto err_malloc;
+   printf(" No memory: calloc() failed\n");
+   goto err_calloc;
}
 
child_portal_id = MC_PORTAL_OFFSET_TO_PORTAL_ID(mc_portal_offset);
@@ -1057,7 +1058,7 @@ static int dprc_init(void)
return 0;
 err_child_open:
free(dflt_mc_io);
-err_malloc:
+err_calloc:
dprc_destroy_container(root_mc_io, MC_CMD_NO_FLAGS,
   root_dprc_handle, child_dprc_id);
 err_create:
@@ -1108,11 +1109,12 @@ static int dpbp_init(void)
struct dpbp_attr dpbp_attr;
struct dpbp_cfg dpbp_cfg;
 
-   dflt_dpbp = (struct fsl_dpbp_obj *)malloc(sizeof(struct fsl_dpbp_obj));
+   dflt_dpbp = (struct fsl_dpbp_obj *)calloc(
+   sizeof(struct fsl_dpbp_obj), 1);
if (!dflt_dpbp) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
dpbp_cfg.options = 512;
@@ -1162,7 +1164,7 @@ err_get_attr:
dpbp_close(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpbp->dpbp_handle);
dpbp_destroy(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpbp->dpbp_handle);
 err_create:
-err_malloc:
+err_calloc:
return err;
 }
 
@@ -1204,11 +1206,12 @@ static int dpni_init(void)
struct dpni_extended_cfg dpni_extended_cfg;
struct dpni_cfg dpni_cfg;
 
-   dflt_dpni = (struct fsl_dpni_obj *)malloc(sizeof(struct fsl_dpni_obj));
+   dflt_dpni = (struct fsl_dpni_obj *)calloc(
+   sizeof(struct fsl_dpni_obj), 1);
if (!dflt_dpni) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
memset(&dpni_extended_cfg, 0, sizeof(dpni_extended_cfg));
@@ -1270,7 +1273,7 @@ err_get_attr:
 err_create:
 err_prepare_extended_cfg:
free(dflt_dpni);
-err_malloc:
+err_calloc:
return err;
 }
 
-- 
2.7.4

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

Re: [U-Boot] BUG: Environment is in SPI flash does not even compile (at least for Orange PI PC2

2017-10-09 Thread Jagan Teki

On Wed, Sep 27, 2017 at 12:43 PM,   wrote:
>
> Hi,
>
> I'm trying to compile u-boot with Environment in SPI flash
> (CONFIG_ENV_IS_IN_SPI_FLASH?) for Orange PI PC2.
>
> Compilation ends with an error:
>   CC  env/sf.o
> env/sf.c: In function ‘env_sf_save’:
> env/sf.c:266:6: error: ‘CONFIG_ENV_SECT_SIZE’ undeclared (first use in this
> function); did you mean ‘CONFIG_ENV_SIZE’?

Need to defined SPI_FLASH and respective VENDOR FLASH configs, better
to send a patch for further discussion if any.

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

Re: [U-Boot] [PATCH 015/080] spi: Remove obsolete spi_base_setup_slave_fdt

2017-10-09 Thread Jagan Teki

On Fri, Sep 29, 2017 at 6:21 PM, Mario Six  wrote:
> 0efc024 ("spi_flash: Add spi_flash_probe_fdt() to locate SPI by FDT
> node") added a helper function spi_base_setup_slave_fdt to to set up a
> SPI slave from a given FDT blob. The only user was the exynos SPI
> driver.
>
> But commit 73186c9 ("dm: exynos: Convert SPI to driver model") removed
> the use of this function, hence rendering it obsolete.
>
> Remove this function, as well as the CONFIG_OF_SPI option, which guarded
> only this function.
>
> Signed-off-by: Mario Six 

Reviewed-by: Jagan Teki 

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

Re: [U-Boot] [PATCH 018/080] spi: Remove CONFIG_OF_SPI_FLASH

2017-10-09 Thread Jagan Teki

On Fri, Sep 29, 2017 at 6:21 PM, Mario Six  wrote:
> Previous patches removed the last usages of this config variable, so
> that it is now obsolete.
>
> This patch removes it from the whitelist.
>
> Signed-off-by: Mario Six 

Reviewed-by: Jagan Teki 

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

Re: [U-Boot] [PATCH 016/080] spi: Remove spi_flash_probe_fdt

2017-10-09 Thread Jagan Teki

On Fri, Sep 29, 2017 at 6:21 PM, Mario Six  wrote:
> Commit ba45756 ("dm: x86: spi: Convert ICH SPI driver to driver model")
> removed the last usage of the spi_flash_probe_fdt function, rendering it
> obsolete.
>
> This patch removes the function.
>
> Signed-off-by: Mario Six 
> ---

Reviewed-by: Jagan Teki 

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

[U-Boot] [U-boot INTERNAL REVIEW 2/2] dm: clk: fix PWR_CR3 register's bit 2 name

2017-10-09 Thread patrice.chotard

From: Patrice Chotard 

Fix bit 2 name of PWR_CR3 register to match with the
last STM32H7 reference manual available here :

http://www.st.com/content/st_com/en/support/resources/
resource-selector.html?querycriteria=productId=SS1951$$
resourceCategory=technical_literature$$resourceType=reference_manual

Update also comment about voltage scaling 1 values

Signed-off-by: Patrice Chotard 
---
 drivers/clk/clk_stm32h7.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c
index 9ca497a..ffa902d 100644
--- a/drivers/clk/clk_stm32h7.c
+++ b/drivers/clk/clk_stm32h7.c
@@ -109,7 +109,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #defineQSPISRC_PER_CK  3
 
 #define PWR_CR30x0c
-#define PWR_CR3_SDEN   BIT(2)
+#define PWR_CR3_SCUEN  BIT(2)
 #define PWR_D3CR   0x18
 #define PWR_D3CR_VOS_MASK  GENMASK(15, 14)
 #define PWR_D3CR_VOS_SHIFT 14
@@ -361,11 +361,11 @@ int configure_clocks(struct udevice *dev)
writel(0x0, ®s->d2ccip1r);
writel(0x0, ®s->d2ccip2r);
 
-   /* Set voltage scaling at scale 1 */
+   /* Set voltage scaling at scale 1 (1,15 - 1,26 Volts) */
clrsetbits_le32(pwr_base + PWR_D3CR, PWR_D3CR_VOS_MASK,
VOS_SCALE_1 << PWR_D3CR_VOS_SHIFT);
-   /* disable step down converter */
-   clrbits_le32(pwr_base + PWR_CR3, PWR_CR3_SDEN);
+   /* Lock supply configuration update */
+   clrbits_le32(pwr_base + PWR_CR3, PWR_CR3_SCUEN);
while (!(readl(pwr_base + PWR_D3CR) & PWR_D3CR_VOSREADY))
;
 
-- 
1.9.1

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

[U-Boot] [U-boot INTERNAL REVIEW 0/2] STM32H7 clock fixes

2017-10-09 Thread patrice.chotard

From: Patrice Chotard 

This series updates:
_ some comment and define's name to match STM32H7 Reference manual 
available on www.st.com
_ remove useless macro

There is no functionnal changes.

Patrice Chotard (2):
  dm: clk: remove CLK() macro for clk_stm32h7
  dm: clk: fix PWR_CR3 register's bit 2 name

 drivers/clk/clk_stm32h7.c | 231 ++
 1 file changed, 112 insertions(+), 119 deletions(-)

-- 
1.9.1

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

[U-Boot] [U-boot INTERNAL REVIEW 1/2] dm: clk: remove CLK() macro for clk_stm32h7

2017-10-09 Thread patrice.chotard

From: Patrice Chotard 

CLK() macro is a residue of a previously reworked patch,
remove it.

Signed-off-by: Patrice Chotard 
---
 drivers/clk/clk_stm32h7.c | 223 ++
 1 file changed, 108 insertions(+), 115 deletions(-)

diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c
index fd0e3ab..9ca497a 100644
--- a/drivers/clk/clk_stm32h7.c
+++ b/drivers/clk/clk_stm32h7.c
@@ -195,13 +195,6 @@ struct clk_cfg {
const char *name;
 };
 
-#define CLK(_gate_offset, _bit_idx, _name) \
-{ \
-   .gate_offset = _gate_offset,\
-   .gate_bit_idx = _bit_idx,\
-   .name = _name,\
-}
-
 /*
  * the way all these entries are sorted in this array could seem
  * unlogical, but we are dependant of kernel DT_bindings,
@@ -210,114 +203,114 @@ struct clk_cfg {
  */
 
 static const struct clk_cfg clk_map[] = {
-   CLK(RCC_AHB3ENR,  31, "d1sram1"),   /* peripheral clocks */
-   CLK(RCC_AHB3ENR,  30, "itcm"),
-   CLK(RCC_AHB3ENR,  29, "dtcm2"),
-   CLK(RCC_AHB3ENR,  28, "dtcm1"),
-   CLK(RCC_AHB3ENR,   8, "flitf"),
-   CLK(RCC_AHB3ENR,   5, "jpgdec"),
-   CLK(RCC_AHB3ENR,   4, "dma2d"),
-   CLK(RCC_AHB3ENR,   0, "mdma"),
-   CLK(RCC_AHB1ENR,  28, "usb2ulpi"),
-   CLK(RCC_AHB1ENR,  17, "eth1rx"),
-   CLK(RCC_AHB1ENR,  16, "eth1tx"),
-   CLK(RCC_AHB1ENR,  15, "eth1mac"),
-   CLK(RCC_AHB1ENR,  14, "art"),
-   CLK(RCC_AHB1ENR,  26, "usb1ulpi"),
-   CLK(RCC_AHB1ENR,   1, "dma2"),
-   CLK(RCC_AHB1ENR,   0, "dma1"),
-   CLK(RCC_AHB2ENR,  31, "d2sram3"),
-   CLK(RCC_AHB2ENR,  30, "d2sram2"),
-   CLK(RCC_AHB2ENR,  29, "d2sram1"),
-   CLK(RCC_AHB2ENR,   5, "hash"),
-   CLK(RCC_AHB2ENR,   4, "crypt"),
-   CLK(RCC_AHB2ENR,   0, "camitf"),
-   CLK(RCC_AHB4ENR,  28, "bkpram"),
-   CLK(RCC_AHB4ENR,  25, "hsem"),
-   CLK(RCC_AHB4ENR,  21, "bdma"),
-   CLK(RCC_AHB4ENR,  19, "crc"),
-   CLK(RCC_AHB4ENR,  10, "gpiok"),
-   CLK(RCC_AHB4ENR,   9, "gpioj"),
-   CLK(RCC_AHB4ENR,   8, "gpioi"),
-   CLK(RCC_AHB4ENR,   7, "gpioh"),
-   CLK(RCC_AHB4ENR,   6, "gpiog"),
-   CLK(RCC_AHB4ENR,   5, "gpiof"),
-   CLK(RCC_AHB4ENR,   4, "gpioe"),
-   CLK(RCC_AHB4ENR,   3, "gpiod"),
-   CLK(RCC_AHB4ENR,   2, "gpioc"),
-   CLK(RCC_AHB4ENR,   1, "gpiob"),
-   CLK(RCC_AHB4ENR,   0, "gpioa"),
-   CLK(RCC_APB3ENR,   6, "wwdg1"),
-   CLK(RCC_APB1LENR, 29, "dac12"),
-   CLK(RCC_APB1LENR, 11, "wwdg2"),
-   CLK(RCC_APB1LENR,  8, "tim14"),
-   CLK(RCC_APB1LENR,  7, "tim13"),
-   CLK(RCC_APB1LENR,  6, "tim12"),
-   CLK(RCC_APB1LENR,  5, "tim7"),
-   CLK(RCC_APB1LENR,  4, "tim6"),
-   CLK(RCC_APB1LENR,  3, "tim5"),
-   CLK(RCC_APB1LENR,  2, "tim4"),
-   CLK(RCC_APB1LENR,  1, "tim3"),
-   CLK(RCC_APB1LENR,  0, "tim2"),
-   CLK(RCC_APB1HENR,  5, "mdios"),
-   CLK(RCC_APB1HENR,  4, "opamp"),
-   CLK(RCC_APB1HENR,  1, "crs"),
-   CLK(RCC_APB2ENR,  18, "tim17"),
-   CLK(RCC_APB2ENR,  17, "tim16"),
-   CLK(RCC_APB2ENR,  16, "tim15"),
-   CLK(RCC_APB2ENR,   1, "tim8"),
-   CLK(RCC_APB2ENR,   0, "tim1"),
-   CLK(RCC_APB4ENR,  26, "tmpsens"),
-   CLK(RCC_APB4ENR,  16, "rtcapb"),
-   CLK(RCC_APB4ENR,  15, "vref"),
-   CLK(RCC_APB4ENR,  14, "comp12"),
-   CLK(RCC_APB4ENR,   1, "syscfg"),
-   CLK(RCC_AHB3ENR,  16, "sdmmc1"),/* kernel clocks */
-   CLK(RCC_AHB3ENR,  14, "quadspi"),
-   CLK(RCC_AHB3ENR,  12, "fmc"),
-   CLK(RCC_AHB1ENR,  27, "usb2otg"),
-   CLK(RCC_AHB1ENR,  25, "usb1otg"),
-   CLK(RCC_AHB1ENR,   5, "adc12"),
-   CLK(RCC_AHB2ENR,   9, "sdmmc2"),
-   CLK(RCC_AHB2ENR,   6, "rng"),
-   CLK(RCC_AHB4ENR,  24, "adc3"),
-   CLK(RCC_APB3ENR,   4, "dsi"),
-   CLK(RCC_APB3ENR,   3, "ltdc"),
-   CLK(RCC_APB1LENR, 31, "usart8"),
-   CLK(RCC_APB1LENR, 30, "usart7"),
-   CLK(RCC_APB1LENR, 27, "hdmicec"),
-   CLK(RCC_APB1LENR, 23, "i2c3"),
-   CLK(RCC_APB1LENR, 22, "i2c2"),
-   CLK(RCC_APB1LENR, 21, "i2c1"),
-   CLK(RCC_APB1LENR, 20, "uart5"),
-   CLK(RCC_APB1LENR, 19, "uart4"),
-   CLK(RCC_APB1LENR, 18, "usart3"),
-   CLK(RCC_APB1LENR, 17, "usart2"),
-   CLK(RCC_APB1LENR, 16, "spdifrx"),
-   CLK(RCC_APB1LENR, 15, "spi3"),
-   CLK(RCC_APB1LENR, 14, "spi2"),
-   CLK(RCC_APB1LENR,  9, "lptim1"),
-   CLK(RCC_APB1HENR,  8, "fdcan"),
-   CLK(RCC_APB1HENR,  2, "swp"),
-   CLK(RCC_APB2ENR,  29, "hrtim"),
-   CLK(RCC_APB2ENR,  28, "dfsdm1"),
-   CLK(RCC_APB2ENR,  24, "sai3"),
-   CLK(RCC_APB2ENR,  23, "sai2"),
-   CLK(RCC_APB2ENR,  22, "sai1"),
-   CLK(RCC_APB2ENR,  20, "spi5"),
-   CLK(RCC_APB2ENR,  13, "spi4"),
-   CLK(RCC_APB2ENR,  12, "spi1"),
-   CLK(RCC_APB2ENR,   5, "usart6"),
-   CLK(RCC_APB2ENR,   4, "usart1"),
-   CLK(RCC_APB4ENR,  21, "sai4a"),
-   CLK(RCC_APB4ENR,  21, "sai4b"),
-   CLK(RCC_APB4ENR,  12, "l

Re: [U-Boot] [U-boot INTERNAL REVIEW 0/2] STM32H7 clock fixes

2017-10-09 Thread Patrice CHOTARD

Hi

Sorry, this series was send with the wrong header
Correct one will be sent

Patrice

On 10/09/2017 11:35 AM, patrice.chot...@st.com wrote:
> From: Patrice Chotard 
> 
> This series updates:
>   _ some comment and define's name to match STM32H7 Reference manual 
> available on www.st.com
>   _ remove useless macro
> 
> There is no functionnal changes.
> 
> Patrice Chotard (2):
>dm: clk: remove CLK() macro for clk_stm32h7
>dm: clk: fix PWR_CR3 register's bit 2 name
> 
>   drivers/clk/clk_stm32h7.c | 231 
> ++
>   1 file changed, 112 insertions(+), 119 deletions(-)
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 020/080] spi: spi-uclass: Fix style violations

2017-10-09 Thread Jagan Teki

On Fri, Sep 29, 2017 at 6:21 PM, Mario Six  wrote:
> Remove a superfluous newline, and reduce the scope of a variable.
>
> Signed-off-by: Mario Six 
> ---

Reviewed-by: Jagan Teki 

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

Re: [U-Boot] [PATCH 017/080] spi: Remove spi_setup_slave_fdt

2017-10-09 Thread Jagan Teki

On Fri, Sep 29, 2017 at 6:21 PM, Mario Six  wrote:
> A previous patch removed the spi_flash_probe_fdt function, which
> contained the last call of the spi_setup_slave_fdt function, which is
> now equally obsolete.
>
> This patch removes the function.
>
> Signed-off-by: Mario Six 
> ---

Reviewed-by: Jagan Teki 

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

Re: [U-Boot] [PATCH v4 03/18] rockchip: enable boot0-hook for all Rockchip SoCs

2017-10-09 Thread Andy Yan


Hi Philipp:


On 2017年10月07日 03:28, Philipp Tomsich wrote:

Rockchip SoCs bootrom design is like this:
- First 2KB or 4KB internal memory is for bootrom stack and heap;
- Then the first 4-byte suppose to be a TAG like 'RK33';
- The the following memory address end with '0004' is the first
   instruction load and running by bootrom;

Let's use the boot0 hook to reserve the first 4-byte tag for all
the Rockchip SoCs.

Signed-off-by: Philipp Tomsich 
[Commit message:]


    What's this ?

Signed-off-by: Kever Yang 

Signed-off-by: Philipp Tomsich 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm/Kconfig   | 1 +
  arch/arm/mach-rockchip/Kconfig | 2 --
  2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5d1ce3e..d5050d0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1109,6 +1109,7 @@ config ARCH_ROCKCHIP
select DM_USB if USB
select DM_PWM
select DM_REGULATOR
+   select ENABLE_ARM_SOC_BOOT0_HOOK
imply CMD_FASTBOOT
imply FASTBOOT
imply FAT_WRITE
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index d9b25d5..31e9864 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -74,7 +74,6 @@ config ROCKCHIP_RK3368
imply SPL_SEPARATE_BSS
imply SPL_SERIAL_SUPPORT
imply TPL_SERIAL_SUPPORT
-   select ENABLE_ARM_SOC_BOOT0_HOOK
select DEBUG_UART_BOARD_INIT
select SYS_NS16550
help
@@ -112,7 +111,6 @@ config ROCKCHIP_RK3399
select SPL_SEPARATE_BSS
select SPL_SERIAL_SUPPORT
select SPL_DRIVERS_MISC_SUPPORT
-   select ENABLE_ARM_SOC_BOOT0_HOOK
select DEBUG_UART_BOARD_INIT
help
  The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72



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

[U-Boot] [PATCH 0/2] STM32H7 clock fixes

2017-10-09 Thread patrice.chotard

From: Patrice Chotard 

This series updates:
_ some comment and define's name to match STM32H7 Reference manual 
available on www.st.com
_ remove useless macro

There is no functionnal changes.

Patrice Chotard (2):
  dm: clk: remove CLK() macro for clk_stm32h7
  dm: clk: fix PWR_CR3 register's bit 2 name

 drivers/clk/clk_stm32h7.c | 231 ++
 1 file changed, 112 insertions(+), 119 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH 1/2] dm: clk: remove CLK() macro for clk_stm32h7

2017-10-09 Thread patrice.chotard

From: Patrice Chotard 

CLK() macro is a residue of a previously reworked patch,
remove it.

Signed-off-by: Patrice Chotard 
---
 drivers/clk/clk_stm32h7.c | 223 ++
 1 file changed, 108 insertions(+), 115 deletions(-)

diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c
index fd0e3ab..9ca497a 100644
--- a/drivers/clk/clk_stm32h7.c
+++ b/drivers/clk/clk_stm32h7.c
@@ -195,13 +195,6 @@ struct clk_cfg {
const char *name;
 };
 
-#define CLK(_gate_offset, _bit_idx, _name) \
-{ \
-   .gate_offset = _gate_offset,\
-   .gate_bit_idx = _bit_idx,\
-   .name = _name,\
-}
-
 /*
  * the way all these entries are sorted in this array could seem
  * unlogical, but we are dependant of kernel DT_bindings,
@@ -210,114 +203,114 @@ struct clk_cfg {
  */
 
 static const struct clk_cfg clk_map[] = {
-   CLK(RCC_AHB3ENR,  31, "d1sram1"),   /* peripheral clocks */
-   CLK(RCC_AHB3ENR,  30, "itcm"),
-   CLK(RCC_AHB3ENR,  29, "dtcm2"),
-   CLK(RCC_AHB3ENR,  28, "dtcm1"),
-   CLK(RCC_AHB3ENR,   8, "flitf"),
-   CLK(RCC_AHB3ENR,   5, "jpgdec"),
-   CLK(RCC_AHB3ENR,   4, "dma2d"),
-   CLK(RCC_AHB3ENR,   0, "mdma"),
-   CLK(RCC_AHB1ENR,  28, "usb2ulpi"),
-   CLK(RCC_AHB1ENR,  17, "eth1rx"),
-   CLK(RCC_AHB1ENR,  16, "eth1tx"),
-   CLK(RCC_AHB1ENR,  15, "eth1mac"),
-   CLK(RCC_AHB1ENR,  14, "art"),
-   CLK(RCC_AHB1ENR,  26, "usb1ulpi"),
-   CLK(RCC_AHB1ENR,   1, "dma2"),
-   CLK(RCC_AHB1ENR,   0, "dma1"),
-   CLK(RCC_AHB2ENR,  31, "d2sram3"),
-   CLK(RCC_AHB2ENR,  30, "d2sram2"),
-   CLK(RCC_AHB2ENR,  29, "d2sram1"),
-   CLK(RCC_AHB2ENR,   5, "hash"),
-   CLK(RCC_AHB2ENR,   4, "crypt"),
-   CLK(RCC_AHB2ENR,   0, "camitf"),
-   CLK(RCC_AHB4ENR,  28, "bkpram"),
-   CLK(RCC_AHB4ENR,  25, "hsem"),
-   CLK(RCC_AHB4ENR,  21, "bdma"),
-   CLK(RCC_AHB4ENR,  19, "crc"),
-   CLK(RCC_AHB4ENR,  10, "gpiok"),
-   CLK(RCC_AHB4ENR,   9, "gpioj"),
-   CLK(RCC_AHB4ENR,   8, "gpioi"),
-   CLK(RCC_AHB4ENR,   7, "gpioh"),
-   CLK(RCC_AHB4ENR,   6, "gpiog"),
-   CLK(RCC_AHB4ENR,   5, "gpiof"),
-   CLK(RCC_AHB4ENR,   4, "gpioe"),
-   CLK(RCC_AHB4ENR,   3, "gpiod"),
-   CLK(RCC_AHB4ENR,   2, "gpioc"),
-   CLK(RCC_AHB4ENR,   1, "gpiob"),
-   CLK(RCC_AHB4ENR,   0, "gpioa"),
-   CLK(RCC_APB3ENR,   6, "wwdg1"),
-   CLK(RCC_APB1LENR, 29, "dac12"),
-   CLK(RCC_APB1LENR, 11, "wwdg2"),
-   CLK(RCC_APB1LENR,  8, "tim14"),
-   CLK(RCC_APB1LENR,  7, "tim13"),
-   CLK(RCC_APB1LENR,  6, "tim12"),
-   CLK(RCC_APB1LENR,  5, "tim7"),
-   CLK(RCC_APB1LENR,  4, "tim6"),
-   CLK(RCC_APB1LENR,  3, "tim5"),
-   CLK(RCC_APB1LENR,  2, "tim4"),
-   CLK(RCC_APB1LENR,  1, "tim3"),
-   CLK(RCC_APB1LENR,  0, "tim2"),
-   CLK(RCC_APB1HENR,  5, "mdios"),
-   CLK(RCC_APB1HENR,  4, "opamp"),
-   CLK(RCC_APB1HENR,  1, "crs"),
-   CLK(RCC_APB2ENR,  18, "tim17"),
-   CLK(RCC_APB2ENR,  17, "tim16"),
-   CLK(RCC_APB2ENR,  16, "tim15"),
-   CLK(RCC_APB2ENR,   1, "tim8"),
-   CLK(RCC_APB2ENR,   0, "tim1"),
-   CLK(RCC_APB4ENR,  26, "tmpsens"),
-   CLK(RCC_APB4ENR,  16, "rtcapb"),
-   CLK(RCC_APB4ENR,  15, "vref"),
-   CLK(RCC_APB4ENR,  14, "comp12"),
-   CLK(RCC_APB4ENR,   1, "syscfg"),
-   CLK(RCC_AHB3ENR,  16, "sdmmc1"),/* kernel clocks */
-   CLK(RCC_AHB3ENR,  14, "quadspi"),
-   CLK(RCC_AHB3ENR,  12, "fmc"),
-   CLK(RCC_AHB1ENR,  27, "usb2otg"),
-   CLK(RCC_AHB1ENR,  25, "usb1otg"),
-   CLK(RCC_AHB1ENR,   5, "adc12"),
-   CLK(RCC_AHB2ENR,   9, "sdmmc2"),
-   CLK(RCC_AHB2ENR,   6, "rng"),
-   CLK(RCC_AHB4ENR,  24, "adc3"),
-   CLK(RCC_APB3ENR,   4, "dsi"),
-   CLK(RCC_APB3ENR,   3, "ltdc"),
-   CLK(RCC_APB1LENR, 31, "usart8"),
-   CLK(RCC_APB1LENR, 30, "usart7"),
-   CLK(RCC_APB1LENR, 27, "hdmicec"),
-   CLK(RCC_APB1LENR, 23, "i2c3"),
-   CLK(RCC_APB1LENR, 22, "i2c2"),
-   CLK(RCC_APB1LENR, 21, "i2c1"),
-   CLK(RCC_APB1LENR, 20, "uart5"),
-   CLK(RCC_APB1LENR, 19, "uart4"),
-   CLK(RCC_APB1LENR, 18, "usart3"),
-   CLK(RCC_APB1LENR, 17, "usart2"),
-   CLK(RCC_APB1LENR, 16, "spdifrx"),
-   CLK(RCC_APB1LENR, 15, "spi3"),
-   CLK(RCC_APB1LENR, 14, "spi2"),
-   CLK(RCC_APB1LENR,  9, "lptim1"),
-   CLK(RCC_APB1HENR,  8, "fdcan"),
-   CLK(RCC_APB1HENR,  2, "swp"),
-   CLK(RCC_APB2ENR,  29, "hrtim"),
-   CLK(RCC_APB2ENR,  28, "dfsdm1"),
-   CLK(RCC_APB2ENR,  24, "sai3"),
-   CLK(RCC_APB2ENR,  23, "sai2"),
-   CLK(RCC_APB2ENR,  22, "sai1"),
-   CLK(RCC_APB2ENR,  20, "spi5"),
-   CLK(RCC_APB2ENR,  13, "spi4"),
-   CLK(RCC_APB2ENR,  12, "spi1"),
-   CLK(RCC_APB2ENR,   5, "usart6"),
-   CLK(RCC_APB2ENR,   4, "usart1"),
-   CLK(RCC_APB4ENR,  21, "sai4a"),
-   CLK(RCC_APB4ENR,  21, "sai4b"),
-   CLK(RCC_APB4ENR,  12, "l

[U-Boot] [PATCH 2/2] dm: clk: fix PWR_CR3 register's bit 2 name

2017-10-09 Thread patrice.chotard

From: Patrice Chotard 

Fix bit 2 name of PWR_CR3 register to match with the
last STM32H7 reference manual available here :

http://www.st.com/content/st_com/en/support/resources/
resource-selector.html?querycriteria=productId=SS1951$$
resourceCategory=technical_literature$$resourceType=reference_manual

Update also comment about voltage scaling 1 values

Signed-off-by: Patrice Chotard 
---
 drivers/clk/clk_stm32h7.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c
index 9ca497a..ffa902d 100644
--- a/drivers/clk/clk_stm32h7.c
+++ b/drivers/clk/clk_stm32h7.c
@@ -109,7 +109,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #defineQSPISRC_PER_CK  3
 
 #define PWR_CR30x0c
-#define PWR_CR3_SDEN   BIT(2)
+#define PWR_CR3_SCUEN  BIT(2)
 #define PWR_D3CR   0x18
 #define PWR_D3CR_VOS_MASK  GENMASK(15, 14)
 #define PWR_D3CR_VOS_SHIFT 14
@@ -361,11 +361,11 @@ int configure_clocks(struct udevice *dev)
writel(0x0, ®s->d2ccip1r);
writel(0x0, ®s->d2ccip2r);
 
-   /* Set voltage scaling at scale 1 */
+   /* Set voltage scaling at scale 1 (1,15 - 1,26 Volts) */
clrsetbits_le32(pwr_base + PWR_D3CR, PWR_D3CR_VOS_MASK,
VOS_SCALE_1 << PWR_D3CR_VOS_SHIFT);
-   /* disable step down converter */
-   clrbits_le32(pwr_base + PWR_CR3, PWR_CR3_SDEN);
+   /* Lock supply configuration update */
+   clrbits_le32(pwr_base + PWR_CR3, PWR_CR3_SCUEN);
while (!(readl(pwr_base + PWR_D3CR) & PWR_D3CR_VOSREADY))
;
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH 2/5] mtd: spi_flash: Support clearing status register

2017-10-09 Thread Jagan Teki

On Sun, Oct 1, 2017 at 6:50 AM, Ahmed Samir Khalil
 wrote:
> A function to clear status register-1 after error
> flag(s) being triggered.
>
> Signed-off-by: Ahmed S. Khalil 
> ---
>  drivers/mtd/spi/spi_flash.c | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 34f6888..52dcb84 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -110,6 +110,27 @@ static int write_cr(struct spi_flash *flash, u8 wc)
>
> return 0;
>  }
> +
> +/*
> + * Clear status register-1
> + *
> + * TODO: Check validity for the other flash vendors.
> + */
> +static int clear_sr(struct spi_flash *flash)
> +{
> +   struct spi_slave *spi = flash->spi;
> +   u8 cmd, buf;
> +   int ret;
> +
> +   cmd = CMD_CLEAR_STATUS;
> +   ret = spi_flash_cmd_write(spi, cmd, 1, buf, 1);

This is wrong, we should have clear status value to clear the status,
and why we need this operation? doesn't mentioned on commit message?
and all these 5 patches does same job better to squash as one resend.

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

Re: [U-Boot] [PATCH v1 2/3] disk: efi: correct the overlap check on GPT header and PTE

2017-10-09 Thread Łukasz Majewski


On 10/09/2017 09:47 AM, Patrick Delaunay wrote:

the partition starting at 0x4400 is refused with overlap error:
   $> gpt write mmc 0 "name=test,start=0x4400,size=0"
   Writing GPT: Partition overlap
   error!

even if the 0x4400 is the first available offset for LBA35 with default
value:
- MBR=LBA1
- GPT header=LBA2
- PTE= 32 LBAs (128 entry), 3 to 34

And the command to have one partition for all the disk failed also :
   $> gpt write mmc 0 "name=test,size=0"

After the patch :

   $> gpt write mmc 0 "name=test,size=0"
   Writing GPT: success!
   $> part list mmc 0

   Partition Map for MMC device 0  --   Partition Type: EFI

   Part Start LBA   End LBA Name
Attributes
Type GUID
Partition GUID
   10x0022  0x01ce9fde  "test"
attrs:  0x
type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
type:   data
guid:   b4b84b8a-04e3-4000-0036-aff5c9c495b1

And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected



Reviewed-by: Łukasz Majewski 


Signed-off-by: Patrick Delaunay 
---

  disk/part_efi.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 0abf487..2992d9e 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -469,8 +469,8 @@ int gpt_fill_pte(struct blk_desc *dev_desc,
 * If our partition overlaps with either the GPT
 * header, or the partition entry, reject it.
 */
-   if (((start <= hdr_end && hdr_start <= (start + size)) ||
-(start <= pte_end && pte_start <= (start + size {
+   if (((start < hdr_end && hdr_start < (start + size)) ||
+(start < pte_end && pte_start < (start + size {
printf("Partition overlap\n");
return -1;
}




--
Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: clk: fix N formula for CPUX clocks

2017-10-09 Thread Jagan Teki

On Tue, Sep 26, 2017 at 8:05 PM, Maxime Ripard
 wrote:
> On Tue, Sep 26, 2017 at 02:02:47PM +, Quentin Schulz wrote:
>> As explained in arch/arm/mach-sunxi/clock_sun8i_a83t.c, clk for CPU
>> clusters is computed as clk = 24*n. However, the current formula is clk
>> = 24*(n-1).
>>
>> This results in a clock set to a frequency that isn't specified as
>> possible for CPUs.
>>
>> Let's use the correct formula.
>>
>> Fixes: f542948b1e8c ("sunxi: clk: add basic clocks for A83T")
>> Signed-off-by: Quentin Schulz 
>
> Acked-by: Maxime Ripard 

Applied to u-boot-sunxi/master

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

[U-Boot] [PATCH] power: extend prefix match to regulator-name property

2017-10-09 Thread Felix Brack

This patch extends pmic_bind_children prefix matching. In addition to
the node name the property regulator-name is used while trying to match
prefixes. This allows assigning different drivers to regulator nodes
named regulator@1 and regulator@10 for example.
Signed-off-by: Felix Brack 
---

 drivers/power/pmic/pmic-uclass.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/power/pmic/pmic-uclass.c b/drivers/power/pmic/pmic-uclass.c
index 64964e4..5a034f0 100644
--- a/drivers/power/pmic/pmic-uclass.c
+++ b/drivers/power/pmic/pmic-uclass.c
@@ -26,6 +26,7 @@ int pmic_bind_children(struct udevice *pmic, ofnode parent,
struct driver *drv;
struct udevice *child;
const char *node_name;
+   const char *reg_name;
int bind_count = 0;
ofnode node;
int prefix_len;
@@ -44,8 +45,18 @@ int pmic_bind_children(struct udevice *pmic, ofnode parent,
debug("  - compatible prefix: '%s'\n", info->prefix);
 
prefix_len = strlen(info->prefix);
-   if (strncmp(info->prefix, node_name, prefix_len))
-   continue;
+   if (strncmp(info->prefix, node_name, prefix_len)) {
+   reg_name = ofnode_read_string(node,
+ "regulator-name");
+   if (reg_name) {
+   if (strncmp(info->prefix, reg_name,
+   prefix_len)) {
+   continue;
+   }
+   } else {
+   continue;
+   }
+   }
 
drv = lists_driver_lookup_name(info->driver);
if (!drv) {
-- 
2.7.4

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

[U-Boot] [PATCH][v3] driver: fsl-mc: memset pointers after malloc

2017-10-09 Thread Prabhakar Kushwaha

Memory allocated via malloc is not guaranteed to be zeroized.

So explicitly use calloc instead of malloc.

Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Replaced malloc/memset with calloc
Changes for v3: Updated patch description

 drivers/net/fsl-mc/mc.c | 39 +--
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 458c458..05d3358 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -725,9 +725,9 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
 * Initialize the global default MC portal
 * And check that the MC firmware is responding portal commands:
 */
-   root_mc_io = (struct fsl_mc_io *)malloc(sizeof(struct fsl_mc_io));
+   root_mc_io = (struct fsl_mc_io *)calloc(sizeof(struct fsl_mc_io), 1);
if (!root_mc_io) {
-   printf(" No memory: malloc() failed\n");
+   printf(" No memory: calloc() failed\n");
return -ENOMEM;
}
 
@@ -877,11 +877,12 @@ static int dpio_init(void)
struct dpio_cfg dpio_cfg;
int err = 0;
 
-   dflt_dpio = (struct fsl_dpio_obj *)malloc(sizeof(struct fsl_dpio_obj));
+   dflt_dpio = (struct fsl_dpio_obj *)calloc(
+   sizeof(struct fsl_dpio_obj), 1);
if (!dflt_dpio) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
dpio_cfg.channel_mode = DPIO_LOCAL_CHANNEL;
@@ -946,7 +947,7 @@ err_get_attr:
dpio_destroy(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpio->dpio_handle);
 err_create:
free(dflt_dpio);
-err_malloc:
+err_calloc:
return err;
 }
 
@@ -1028,11 +1029,11 @@ static int dprc_init(void)
goto err_create;
}
 
-   dflt_mc_io = (struct fsl_mc_io *)malloc(sizeof(struct fsl_mc_io));
+   dflt_mc_io = (struct fsl_mc_io *)calloc(sizeof(struct fsl_mc_io), 1);
if (!dflt_mc_io) {
err  = -ENOMEM;
-   printf(" No memory: malloc() failed\n");
-   goto err_malloc;
+   printf(" No memory: calloc() failed\n");
+   goto err_calloc;
}
 
child_portal_id = MC_PORTAL_OFFSET_TO_PORTAL_ID(mc_portal_offset);
@@ -1057,7 +1058,7 @@ static int dprc_init(void)
return 0;
 err_child_open:
free(dflt_mc_io);
-err_malloc:
+err_calloc:
dprc_destroy_container(root_mc_io, MC_CMD_NO_FLAGS,
   root_dprc_handle, child_dprc_id);
 err_create:
@@ -1108,11 +1109,12 @@ static int dpbp_init(void)
struct dpbp_attr dpbp_attr;
struct dpbp_cfg dpbp_cfg;
 
-   dflt_dpbp = (struct fsl_dpbp_obj *)malloc(sizeof(struct fsl_dpbp_obj));
+   dflt_dpbp = (struct fsl_dpbp_obj *)calloc(
+   sizeof(struct fsl_dpbp_obj), 1);
if (!dflt_dpbp) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
dpbp_cfg.options = 512;
@@ -1162,7 +1164,7 @@ err_get_attr:
dpbp_close(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpbp->dpbp_handle);
dpbp_destroy(dflt_mc_io, MC_CMD_NO_FLAGS, dflt_dpbp->dpbp_handle);
 err_create:
-err_malloc:
+err_calloc:
return err;
 }
 
@@ -1204,11 +1206,12 @@ static int dpni_init(void)
struct dpni_extended_cfg dpni_extended_cfg;
struct dpni_cfg dpni_cfg;
 
-   dflt_dpni = (struct fsl_dpni_obj *)malloc(sizeof(struct fsl_dpni_obj));
+   dflt_dpni = (struct fsl_dpni_obj *)calloc(
+   sizeof(struct fsl_dpni_obj), 1);
if (!dflt_dpni) {
-   printf("No memory: malloc() failed\n");
+   printf("No memory: calloc() failed\n");
err = -ENOMEM;
-   goto err_malloc;
+   goto err_calloc;
}
 
memset(&dpni_extended_cfg, 0, sizeof(dpni_extended_cfg));
@@ -1270,7 +1273,7 @@ err_get_attr:
 err_create:
 err_prepare_extended_cfg:
free(dflt_dpni);
-err_malloc:
+err_calloc:
return err;
 }
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 03/18] rockchip: enable boot0-hook for all Rockchip SoCs

2017-10-09 Thread Dr. Philipp Tomsich


> On 9 Oct 2017, at 11:37, Andy Yan  wrote:
> 
> Hi Philipp:
> 
> 
> On 2017年10月07日 03:28, Philipp Tomsich wrote:
>> Rockchip SoCs bootrom design is like this:
>> - First 2KB or 4KB internal memory is for bootrom stack and heap;
>> - Then the first 4-byte suppose to be a TAG like 'RK33';
>> - The the following memory address end with '0004' is the first
>>   instruction load and running by bootrom;
>> 
>> Let's use the boot0 hook to reserve the first 4-byte tag for all
>> the Rockchip SoCs.
>> 
>> Signed-off-by: Philipp Tomsich 
>> [Commit message:]
> 
> What's this ?

This means "I took the commit message from Kever’s original boot0-series,
but the content of the patch was rewritten”.

>> Signed-off-by: Kever Yang 
>> 
>> Signed-off-by: Philipp Tomsich 
>> ---
>> 
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2: None
>> 
>>  arch/arm/Kconfig   | 1 +
>>  arch/arm/mach-rockchip/Kconfig | 2 --
>>  2 files changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 5d1ce3e..d5050d0 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1109,6 +1109,7 @@ config ARCH_ROCKCHIP
>>  select DM_USB if USB
>>  select DM_PWM
>>  select DM_REGULATOR
>> +select ENABLE_ARM_SOC_BOOT0_HOOK
>>  imply CMD_FASTBOOT
>>  imply FASTBOOT
>>  imply FAT_WRITE
>> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
>> index d9b25d5..31e9864 100644
>> --- a/arch/arm/mach-rockchip/Kconfig
>> +++ b/arch/arm/mach-rockchip/Kconfig
>> @@ -74,7 +74,6 @@ config ROCKCHIP_RK3368
>>  imply SPL_SEPARATE_BSS
>>  imply SPL_SERIAL_SUPPORT
>>  imply TPL_SERIAL_SUPPORT
>> -select ENABLE_ARM_SOC_BOOT0_HOOK
>>  select DEBUG_UART_BOARD_INIT
>>  select SYS_NS16550
>>  help
>> @@ -112,7 +111,6 @@ config ROCKCHIP_RK3399
>>  select SPL_SEPARATE_BSS
>>  select SPL_SERIAL_SUPPORT
>>  select SPL_DRIVERS_MISC_SUPPORT
>> -select ENABLE_ARM_SOC_BOOT0_HOOK
>>  select DEBUG_UART_BOARD_INIT
>>  help
>>The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
> 
> 

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

Re: [U-Boot] [PATCH 1/1] rockchip: provide installation instruction for Firefly-RK3399.

2017-10-09 Thread Dr. Philipp Tomsich


> On 9 Oct 2017, at 10:00, Mark Kettenis  wrote:
> 
>> From: Simon Glass 
>> Date: Sun, 8 Oct 2017 22:41:50 -0600
>> 
>> On 27 September 2017 at 21:35, Heinrich Schuchardt  
>> wrote:
>>> Unfortunately installing U-Boot on an SD card for the Firefly-RK3399
>>> is not trivial.
>>> 
>>> I could not get U-Boot running with SPL.  So I ended up using the
>>> Rockchip miniloader.
>>> 
>>> Adding a README hopefully will give other users an easier start.
>>> 
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>> board/rockchip/firefly_rk3399/README | 55 
>>> 
>>> 1 file changed, 55 insertions(+)
>>> create mode 100644 board/rockchip/firefly_rk3399/README
>> 
>> Reviewed-by: Simon Glass 
> 
> Hmm,
> 
> Do we really want to push people in this direction, using propriatary,
> closed-source binaries?

I would rather see people discouraged from going down that road as
well… or to document this as a deprecated approach only.

> The "pure" U-Boot approach that is currently documented works just
> fine.  The only problem is that the firefly-rk3399 by default boots
> from eMMC.  And the first-stage bootloader only recognizes SD-cards
> with the propriatary loader.  So the trick is to wipe the firmware
> stored in eMMC or replace it with U-Boot.

Would you be willing to submit a patch with documentation for this?

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

Re: [U-Boot] [PATCH] imx: serial: Wait for ongoing transmission to finish before serial reset

2017-10-09 Thread Łukasz Majewski


Hi Simon,


Hi Lukasz,

On 3 October 2017 at 03:16, Lukasz Majewski  wrote:

It may happen that the MXC serial IP block is performing some ongoing
transmission (started at e.g. board_init()) when the "initr_serial" is
called.

As a result the serial port IP block is reset, so transmitted data is
corrupted:

I2C:   ready
DRAM:  1 GiB
jSS('HH��SL_SDHC: 04 rev 0x0

This patch prevents from this situation, by waiting for transmission
complete bit set (UART Status Register 2 (UARTx_USR2), bit TXDC):

I2C:   ready
DRAM:  1 GiB
ID:unit type 0x4 rev 0x0

Signed-off-by: Lukasz Majewski 
---

  drivers/serial/serial_mxc.c | 7 +++
  1 file changed, 7 insertions(+)


Is it possible to use driver model to do this in a generic way for all
serial drivers? The pending() method allows you to check if there are
any characters in the output FIFO.


Please correct me if I'm wrong.

Do you mean to define pre_init() callback in serial-uclass.c file, which 
would utilize ->pending callback if available?


In that way we would have the generic facility for above check available 
on all platforms.





Regards,
Simon




--
Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09 Thread Rob Clark

On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
> On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>> This fixes an issue with OpenBSD's bootloader, and I think should also
>> fix a similar issue with grub2 on legacy devices.  In the legacy case
>> we were creating disk objects for the partitions, but not also the
>> parent device.
>>
>> Reported-by: Jonathan Gray 
>> Signed-off-by: Rob Clark 
>
> Thanks for looking into this.  While this lets armv7/bootarm.efi
> boot again on cubox-i and bbb it doesn't help rpi3.
>
> What is the easiest way to get U-Boot to display these paths
> to be able to compare the current behaviour to 2017.09?
>

in grub, there is the lsefi command, not sure if the OpenBSD
bootloader has something similar?

u-boot implements that device-path to text protocol, so it should be
pretty easy to implement something like this if not.

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

Re: [U-Boot] [PATCH 08/11] efi_selftest: allow to select a single test for exexution

2017-10-09 Thread Heinrich Schuchardt

On 10/09/2017 08:57 AM, Alexander Graf wrote:
> 
> 
> On 09.10.17 08:14, Heinrich Schuchardt wrote:
>> On 10/09/2017 06:46 AM, Alexander Graf wrote:
>>>
>>>
>>> On 08.10.17 06:57, Heinrich Schuchardt wrote:
 The second argument of bootefi is passed as a configuration
 table to the selftest application. It is used to select
 a single test to be executed.

 Tests get an on_request property. If this property is set
 the tests are only executed if explicitly requested.

 A new command 'bootefi selftest list' is added that allows to list
 all tests.

 The invocation of efi_selftest is changed to reflect that
 bootefi selftest list will call the Exit bootservice.

 Signed-off-by: Heinrich Schuchardt 
>>>
>>> Wouldn't it make more sense to just pass "bootargs" to the EFI payload
>>> as command line arguments?
>>>
>>> We could then just
>>>
>>>   U-Boot# setenv bootargs list
>>>   U-Boot# bootefi selftest
>>>
>>> to list the available self tests. Same for selecting them.
>>
>> Why bootargs?
>>
> 
> Because bootargs is the variable that "bootm" pushes into a payload as
> command line arguments.
> 
>>>
>>> That way we would also be able to directly load Linux as EFI binary and
>>> pass command line arguments to it without jumping through fdt patching
>>> hoops.
>>
>> Does the Linux EFI stub or grub.efi have a capability to receive the
>> command line?
> 
> Linux does:
> 
> 
> https://github.com/torvalds/linux/blob/master/drivers/firmware/efi/libstub/efi-stub-helper.c#L773
> 
> I don't think grub implements it today, but I don't see why it should.
> Any UEFI application that expects to be executed from the UEFI Shell
> certainly interprets the passed in command line.
> 
> 
> Alex
> 

Thanks for pointing me at fields LoadOptionsSize and LoadOptions in the
EFI_Loaded_Image_Protocol. Yes it makes sense to use this mechanism.

I guess efi_setup_loaded_image would be a good place to set the fields.

We will have to free the associated memory when unloading the image
(efi_unload_image).

We should call efi_unload_image from efi_exit when indicated by the
subsystem and exit code.

I will put these changes into separate patches.

Regards

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

Re: [U-Boot] efi_loader: enough-uefi-for-shell: [PATCH 06/11] efi_loader: implement SetWatchdogTimer

2017-10-09 Thread Rob Clark

On Sun, Oct 8, 2017 at 6:14 PM, Heinrich Schuchardt  wrote:
> On 10/08/2017 06:57 AM, Heinrich Schuchardt wrote:
>> The watchdog is initialized with a 5 minute timeout period.
>> It can be reset by SetWatchdogTimer.
>> It is stopped by ExitBoottimeServices.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  cmd/bootefi.c |  1 +
>>  include/efi_loader.h  |  4 +++
>>  lib/efi_loader/Makefile   |  2 +-
>>  lib/efi_loader/efi_boottime.c | 15 ++-
>>  lib/efi_loader/efi_watchdog.c | 59 
>> +++
>>  5 files changed, 67 insertions(+), 14 deletions(-)
>>  create mode 100644 lib/efi_loader/efi_watchdog.c
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index b7087e3da8..24958ada46 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -43,6 +43,7 @@ static void efi_init_obj_list(void)
>>  #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>>   efi_smbios_register();
>>  #endif
>> + efi_watchdog_register();
>>
>>   /* Initialize EFI runtime services */
>>   efi_reset_system_init();
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index e1179b7dcd..223d8d8222 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -163,6 +163,8 @@ int efi_disk_register(void);
>>  int efi_gop_register(void);
>>  /* Called by bootefi to make the network interface available */
>>  int efi_net_register(void);
>> +/* Called by bootefi to make the watchdog available */
>> +int efi_watchdog_register(void);
>>  /* Called by bootefi to make SMBIOS tables available */
>>  void efi_smbios_register(void);
>>
>> @@ -171,6 +173,8 @@ efi_fs_from_path(struct efi_device_path *fp);
>>
>>  /* Called by networking code to memorize the dhcp ack package */
>>  void efi_net_set_dhcp_ack(void *pkt, int len);
>> +/* Called by efi_set_watchdog_timer to reset the timer */
>> +efi_status_t efi_set_watchdog(unsigned long timeout);
>>
>>  /* Called from places to check whether a timer expired */
>>  void efi_timer_check(void);
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index ddb978f650..83d879b686 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -17,7 +17,7 @@ endif
>>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>> -obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>> +obj-y += efi_file.o efi_variable.o efi_bootmgr.o efi_watchdog.o
>>  obj-$(CONFIG_LCD) += efi_gop.o
>>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>>  obj-$(CONFIG_PARTITIONS) += efi_disk.o
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 30577f717e..81e7d818fc 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -155,18 +155,6 @@ void efi_signal_event(struct efi_event *event)
>>   event->is_queued = false;
>>  }
>>
>> -/*
>> - * Write a debug message for an EPI API service that is not implemented yet.
>> - *
>> - * @funcname function that is not yet implemented
>> - * @return   EFI_UNSUPPORTED
>> - */
>> -static efi_status_t efi_unsupported(const char *funcname)
>> -{
>> - debug("EFI: App called into unimplemented function %s\n", funcname);
>> - return EFI_EXIT(EFI_UNSUPPORTED);
>> -}
>> -
>>  /*
>>   * Raise the task priority level.
>>   *
>> @@ -1454,6 +1442,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
>> *image_handle,
>>   bootm_disable_interrupts();
>>
>>   /* Give the payload some time to boot */
>> + efi_set_watchdog(0);
>>   WATCHDOG_RESET();
>>
>>   return EFI_EXIT(EFI_SUCCESS);
>> @@ -1514,7 +1503,7 @@ static efi_status_t EFIAPI 
>> efi_set_watchdog_timer(unsigned long timeout,
>>  {
>>   EFI_ENTRY("%ld, 0x%"PRIx64", %ld, %p", timeout, watchdog_code,
>> data_size, watchdog_data);
>> - return efi_unsupported(__func__);
>> + return EFI_EXIT(efi_set_watchdog(timeout));
>>  }
>>
>>  /*
>> diff --git a/lib/efi_loader/efi_watchdog.c b/lib/efi_loader/efi_watchdog.c
>> new file mode 100644
>> index 00..50e95290ea
>> --- /dev/null
>> +++ b/lib/efi_loader/efi_watchdog.c
>> @@ -0,0 +1,59 @@
>> +/*
>> + *  EFI device path interface
>> + *
>> + *  Copyright (c) 2017 Heinrich Schuchardt
>> + *
>> + *  SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +static struct efi_event *watchdog_timer_event;
>> +
>> +static void EFIAPI efi_watchdog_timer_notify(struct efi_event *event,
>> +  void *context)
>> +{
>> + EFI_ENTRY("%p, %p", event, context);
>> +
>> + printf("\nEFI: Watchdog timeout\n");
>> + EFI_CALL_VOID(efi_runtime_services.reset_system(EFI_RESET_COLD,
>> + EFI_SUCCESS, 0, NULL));
>
> Hello Rob,
>
> referring to:
> https://github.com/robclark/u-boot/commits/enough-uefi-for-shell
>
> The patch

Re: [U-Boot] [PATCH 08/11] efi_selftest: allow to select a single test for exexution

2017-10-09 Thread Alexander Graf



On 09.10.17 12:54, Heinrich Schuchardt wrote:
> On 10/09/2017 08:57 AM, Alexander Graf wrote:
>>
>>
>> On 09.10.17 08:14, Heinrich Schuchardt wrote:
>>> On 10/09/2017 06:46 AM, Alexander Graf wrote:


 On 08.10.17 06:57, Heinrich Schuchardt wrote:
> The second argument of bootefi is passed as a configuration
> table to the selftest application. It is used to select
> a single test to be executed.
>
> Tests get an on_request property. If this property is set
> the tests are only executed if explicitly requested.
>
> A new command 'bootefi selftest list' is added that allows to list
> all tests.
>
> The invocation of efi_selftest is changed to reflect that
> bootefi selftest list will call the Exit bootservice.
>
> Signed-off-by: Heinrich Schuchardt 

 Wouldn't it make more sense to just pass "bootargs" to the EFI payload
 as command line arguments?

 We could then just

   U-Boot# setenv bootargs list
   U-Boot# bootefi selftest

 to list the available self tests. Same for selecting them.
>>>
>>> Why bootargs?
>>>
>>
>> Because bootargs is the variable that "bootm" pushes into a payload as
>> command line arguments.
>>

 That way we would also be able to directly load Linux as EFI binary and
 pass command line arguments to it without jumping through fdt patching
 hoops.
>>>
>>> Does the Linux EFI stub or grub.efi have a capability to receive the
>>> command line?
>>
>> Linux does:
>>
>>
>> https://github.com/torvalds/linux/blob/master/drivers/firmware/efi/libstub/efi-stub-helper.c#L773
>>
>> I don't think grub implements it today, but I don't see why it should.
>> Any UEFI application that expects to be executed from the UEFI Shell
>> certainly interprets the passed in command line.
>>
>>
>> Alex
>>
> 
> Thanks for pointing me at fields LoadOptionsSize and LoadOptions in the
> EFI_Loaded_Image_Protocol. Yes it makes sense to use this mechanism.
> 
> I guess efi_setup_loaded_image would be a good place to set the fields.

I'm not sure about that. efi_setup_loaded_image gets called from payload
context too. Imagine a bootefi on a UEFI Shell which then runs Linux.
That Linux binary should not see our bootargs arguments.

I think it really belongs in do_bootefi_exec.


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

Re: [U-Boot] Edison's U-Boot Architecture

2017-10-09 Thread Andy Shevchenko

On Mon, 2017-10-09 at 08:10 +0200, Zoran Stojsavljevic wrote:
> Hello Andy,
> 
> Thank you very much for the reply. Instead reply-ing to you in Open
> Source fashion, I'll answer to you in the form of the new @. Easier
> and more clean/clear approach.
> 
> Nevertheless, Edison is cancelled. But since it is already out there,
> and you do it, and using it as the test vehicle  Let me start asking
> in the Edison/Tangier core design light the similar questions, I
> already have asked on this list about U-Boot E3900 and BDW-DX 
> architectures.

I hope you understand that I can't comment much on the internals.

I would point out that Intel Tangier (and basically entire Intel MID
family has beyond the poor documentation available publicly).

> We all know (or I assume U-Boot list knows about Coreboot) and I also
> assume majority of the people heard how x86 does work for Coreboot.
> Quick recap:
> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firm
> ware-support-package/intel-fsp-overview.html
> 
> And we have here in nutshell the following peculiar architecture as
> the result of FSP: FSP/Coreboot inter-mingled with U-Boot as a
> Coreboot's payload!? Practically three boot-loaders to bring x86
> architecture to YOCTO... FSP being binary blob, actually translating
> to three binary blobs in FSP 2.0 spec.
> 
> And we know that U-Boot maintainers do not allow binary blobs in U-
> Boot. Not like this.
> 
> So, what we really want: independent U-Boot on x86, don't we?
> 
> I am curious about the following x86 HW/FW configuration with regards
> to the U-Boot?
> 
> In order to protect INTEL Intellectual Properly (IP), FSP is invented.
> Seems that FSP did NOT solve any of the issues. Furthermore, I have no
> idea how big projects/players are using x86 with U-Boot (example: BMW,
> their Ulm and Munich IT Car depts.) are using YOCTO with x86.
> 
> My best guess is that they have private U-Boot (NOT public one),
> already adjusted to work as two stage boot-loader, with very clean
> division of the layers.

First of all, you have to distinguish ACPI/UEFI enabled platform vs.
non-as-such. Almost all platforms you are talking about are UEFI
compatible and thus no magic here, U-Boot can be just a UEFI
application.

Some of them might not use that approach (own or different BIOS), but
this is beyond my scope.

>  Something like this (in the lieu of Tangier, as an example):
> 
> Edison/Tangier cores -> IFWI -> MBR -> U-Boot -> eLinux/YOCTO ?!

Nope. Intel MID has quite different boot flow.
I can't tell much, but there is much more happened before IFWI, and not
exactly how you put it after.

> Here are some explanations regarding the terms/context:
> 
> IFWI is the Intel FirmWare Interface, a binary blob loaded from the
> eMMC boot partition that executes a secondary loader (in this case U-
> Boot) from the main eMMC. IFWI blobs for the x86 are provided by
> Intel.

That's correct.

> Normal IFWI eMMC boot process
> 
> On-chip boot rom inits eMMC and loads IFWI from the MMC boot
> partitions
> IFWI looks for OSIP header at top of eMMC (MBR boot block)

AFAIU OSIP is a header of DnX protocol (which is in [OTP] ROM) and runs
before IFWI.

On the actual media there is nothing like OSIP headers.

> The header directs IFWI to the start, size, load address, and entry of
> U-Boot in eMMC
> (need clarification) If u-boot is not found, try the alt u-boot image
> at 5MB into the eMMC

Those are just two partitions on eMMC. Look at Edison closer.

U-Boot is used as a chain loader (32-bit application) in similar way as
UEFI app.

> U-Boot is loaded into RAM and executed
> OSIP stands for OS Image Profile, and it is nothing more and less than
> INTEL name for very known old fashion MBR, considering DATA structure.

This is incorrect (except, perhaps, the abbreviation decode of OSIP).

> Andy/Andrej,

Andy is okay :-)

> Question here: Did I get the correct idea how Edison works with U-
> Boot? Could you, please, elaborate how this is done with Edison? 

See above

> (Vopros sdes6: Ja praviljno ugadal kak eto sdelano/rabotaet? Mozno
> bolee dannih kad celaja eta arhitectura rabotaet so Edisonom?)

Ne ugadal :-) Smotri vyshe.

> 
> (I da, esli est6 informacii na Russkom, davaite ih... Rasberus6! Ja
> boltaju Russij jazik tocno kak Russkie rozdennie). ;-)

Nice! Though mailing list is for wider audience. Can't use non-English,
except for swearing like Linus in Finnish :-)

Information on public is so little WRT Intel MID family. The best way to
get something is to read code, comments, and commit messages during
Linux kernel history.

You may try to search on communities.intel.com for Edison forum. This
might shed some light on something.

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/9] LS1012A PFE driver patch series

2017-10-09 Thread Calvin Johnson

Hi,

This patch series introduces U-Boot support for NXP's LS1012A Packet Forwarding
Engine (pfe_eth). LS1012A uses hardware packet forwarding engine to provide
high performance Ethernet interfaces. The device includes two Ethernet ports.

Depends on https://patchwork.ozlabs.org/patch/704305

Regards
Calvin

Calvin Johnson (9):
  drivers: net: pfe_eth: LS1012A PFE driver introduction
  drivers: net: pfe_eth: provide pfe commands
  drivers: net: pfe_eth: LS1012A PFE headers
  board: freescale: ls1012a: enable network support on ls1012a platforms
  armv8: fsl-lsch2: initialize pfe gemac
  armv8: fsl-lsch2: add pfe macros and update ccsr_scfg structure
  armv8: fsl-lsch2: configure pfe's scfg & dcfg registers
  fsl: csu: enable ns access for PFE
  configs: ls1012a: add pfe configuration for LS1012A

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|8 +
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   18 +
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |   38 +-
 .../include/asm/arch-fsl-layerscape/ns_access.h|2 +
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |3 +
 board/freescale/ls1012afrdm/Makefile   |1 +
 board/freescale/ls1012afrdm/eth.c  |   86 ++
 board/freescale/ls1012afrdm/ls1012afrdm.c  |5 -
 board/freescale/ls1012aqds/Makefile|1 +
 board/freescale/ls1012aqds/eth.c   |  263 +
 board/freescale/ls1012aqds/ls1012aqds.c|   97 +-
 board/freescale/ls1012aqds/ls1012aqds_pfe.h|   48 +
 board/freescale/ls1012aqds/ls1012aqds_qixis.h  |2 +-
 board/freescale/ls1012ardb/Makefile|1 +
 board/freescale/ls1012ardb/eth.c   |   70 ++
 board/freescale/ls1012ardb/ls1012ardb.c|4 -
 configs/ls1012afrdm_qspi_defconfig |1 +
 configs/ls1012aqds_qspi_defconfig  |1 +
 configs/ls1012ardb_qspi_defconfig  |1 +
 drivers/net/Kconfig|1 +
 drivers/net/Makefile   |1 +
 drivers/net/pfe_eth/Kconfig|   29 +
 drivers/net/pfe_eth/Makefile   |   11 +
 drivers/net/pfe_eth/pfe.c  | 1161 
 drivers/net/pfe_eth/pfe_cmd.c  |  537 +
 drivers/net/pfe_eth/pfe_driver.c   |  626 +++
 drivers/net/pfe_eth/pfe_eth.c  |  545 +
 drivers/net/pfe_eth/pfe_firmware.c |  230 
 include/configs/ls1012a_common.h   |6 +-
 include/configs/ls1012afrdm.h  |7 +
 include/configs/ls1012aqds.h   |   14 +
 include/configs/ls1012ardb.h   |   13 +
 include/pfe_eth/pfe/cbus.h |   75 ++
 include/pfe_eth/pfe/cbus/bmu.h |   40 +
 include/pfe_eth/pfe/cbus/class_csr.h   |  181 +++
 include/pfe_eth/pfe/cbus/emac.h|  150 +++
 include/pfe_eth/pfe/cbus/gpi.h |   62 ++
 include/pfe_eth/pfe/cbus/hif.h |   68 ++
 include/pfe_eth/pfe/cbus/hif_nocpy.h   |   40 +
 include/pfe_eth/pfe/cbus/tmu_csr.h |  148 +++
 include/pfe_eth/pfe/cbus/util_csr.h|   47 +
 include/pfe_eth/pfe/pfe.h  |  178 +++
 include/pfe_eth/pfe_driver.h   |   55 +
 include/pfe_eth/pfe_eth.h  |  111 ++
 include/pfe_eth/pfe_firmware.h |   17 +
 45 files changed, 4983 insertions(+), 20 deletions(-)
 create mode 100644 board/freescale/ls1012afrdm/eth.c
 create mode 100644 board/freescale/ls1012aqds/eth.c
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds_pfe.h
 create mode 100644 board/freescale/ls1012ardb/eth.c
 create mode 100644 drivers/net/pfe_eth/Kconfig
 create mode 100644 drivers/net/pfe_eth/Makefile
 create mode 100644 drivers/net/pfe_eth/pfe.c
 create mode 100644 drivers/net/pfe_eth/pfe_cmd.c
 create mode 100644 drivers/net/pfe_eth/pfe_driver.c
 create mode 100644 drivers/net/pfe_eth/pfe_eth.c
 create mode 100644 drivers/net/pfe_eth/pfe_firmware.c
 create mode 100644 include/pfe_eth/pfe/cbus.h
 create mode 100644 include/pfe_eth/pfe/cbus/bmu.h
 create mode 100644 include/pfe_eth/pfe/cbus/class_csr.h
 create mode 100644 include/pfe_eth/pfe/cbus/emac.h
 create mode 100644 include/pfe_eth/pfe/cbus/gpi.h
 create mode 100644 include/pfe_eth/pfe/cbus/hif.h
 create mode 100644 include/pfe_eth/pfe/cbus/hif_nocpy.h
 create mode 100644 include/pfe_eth/pfe/cbus/tmu_csr.h
 create mode 100644 include/pfe_eth/pfe/cbus/util_csr.h
 create mode 100644 include/pfe_eth/pfe/pfe.h
 create mode 100644 include/pfe_eth/pfe_driver.h
 create mode 100644 include/pfe_eth/pfe_eth.h
 create mode 100644 include/pfe_eth/pfe_firmware.h

-- 
2.7.4

___
U-Boot mailing li

[U-Boot] [PATCH 1/9] drivers: net: pfe_eth: LS1012A PFE driver introduction

2017-10-09 Thread Calvin Johnson

This patch adds PFE driver into U-Boot.

Following are the main driver files:-
pfe.c: provides low level helper functions to initialize PFE internal
processor engines and other hardware blocks.
pfe_driver.c: provides probe functions, initialization functions
and packet send and receive functions.
pfe_eth.c: provides high level gemac, phy and mdio initialization
functions.
pfe_firmware.c: provides functions to load firmware into PFE
internal processor engines.

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 drivers/net/pfe_eth/Kconfig|8 +
 drivers/net/pfe_eth/Makefile   |   10 +
 drivers/net/pfe_eth/pfe.c  | 1161 
 drivers/net/pfe_eth/pfe_driver.c   |  626 +++
 drivers/net/pfe_eth/pfe_eth.c  |  545 +
 drivers/net/pfe_eth/pfe_firmware.c |  230 +++
 6 files changed, 2580 insertions(+)
 create mode 100644 drivers/net/pfe_eth/Kconfig
 create mode 100644 drivers/net/pfe_eth/Makefile
 create mode 100644 drivers/net/pfe_eth/pfe.c
 create mode 100644 drivers/net/pfe_eth/pfe_driver.c
 create mode 100644 drivers/net/pfe_eth/pfe_eth.c
 create mode 100644 drivers/net/pfe_eth/pfe_firmware.c

diff --git a/drivers/net/pfe_eth/Kconfig b/drivers/net/pfe_eth/Kconfig
new file mode 100644
index 000..b9996df
--- /dev/null
+++ b/drivers/net/pfe_eth/Kconfig
@@ -0,0 +1,8 @@
+config UTIL_PE_DISABLED
+   bool
+   help
+ Disable UTIL processor engine of PFE
+
+config SYS_FSL_PPFE_ADDR
+   hex "PFE base address"
+   default 0x0400
diff --git a/drivers/net/pfe_eth/Makefile b/drivers/net/pfe_eth/Makefile
new file mode 100644
index 000..e78f1bf
--- /dev/null
+++ b/drivers/net/pfe_eth/Makefile
@@ -0,0 +1,10 @@
+# Copyright 2015-2016 Freescale Semiconductor, Inc.
+# Copyright 2017 NXP
+#
+# SPDX-License-Identifier:GPL-2.0+
+
+# Layerscape PFE driver
+obj-y += pfe.o \
+pfe_driver.o   \
+pfe_eth.o  \
+pfe_firmware.o
diff --git a/drivers/net/pfe_eth/pfe.c b/drivers/net/pfe_eth/pfe.c
new file mode 100644
index 000..fc6631e
--- /dev/null
+++ b/drivers/net/pfe_eth/pfe.c
@@ -0,0 +1,1161 @@
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+
+void *ddr_base_addr;
+unsigned long ddr_phys_base_addr;
+static struct pe_info pe[MAX_PE];
+
+/*
+ * Initializes the PFE library.
+ * Must be called before using any of the library functions.
+ *
+ * @param[in] cbus_baseCBUS virtual base address (as mapped in
+ * the host CPU address space)
+ * @param[in] ddr_base DDR virtual base address (as mapped in
+ * the host CPU address space)
+ * @param[in] ddr_phys_baseDDR physical base address (as mapped in
+ * platform)
+ */
+void pfe_lib_init(void *ddr_base, unsigned long ddr_phys_base)
+{
+   ddr_base_addr = ddr_base;
+   ddr_phys_base_addr = ddr_phys_base;
+
+   pe[CLASS0_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(0);
+   pe[CLASS0_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(0);
+   pe[CLASS0_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
+   pe[CLASS0_ID].mem_access_wdata = (void *)CLASS_MEM_ACCESS_WDATA;
+   pe[CLASS0_ID].mem_access_addr = (void *)CLASS_MEM_ACCESS_ADDR;
+   pe[CLASS0_ID].mem_access_rdata = (void *)CLASS_MEM_ACCESS_RDATA;
+
+   pe[CLASS1_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(1);
+   pe[CLASS1_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(1);
+   pe[CLASS1_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
+   pe[CLASS1_ID].mem_access_wdata = (void *)CLASS_MEM_ACCESS_WDATA;
+   pe[CLASS1_ID].mem_access_addr = (void *)CLASS_MEM_ACCESS_ADDR;
+   pe[CLASS1_ID].mem_access_rdata = (void *)CLASS_MEM_ACCESS_RDATA;
+
+   pe[CLASS2_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(2);
+   pe[CLASS2_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(2);
+   pe[CLASS2_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
+   pe[CLASS2_ID].mem_access_wdata = (void *)CLASS_MEM_ACCESS_WDATA;
+   pe[CLASS2_ID].mem_access_addr = (void *)CLASS_MEM_ACCESS_ADDR;
+   pe[CLASS2_ID].mem_access_rdata = (void *)CLASS_MEM_ACCESS_RDATA;
+
+   pe[CLASS3_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(3);
+   pe[CLASS3_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(3);
+   pe[CLASS3_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
+   pe[CLASS3_ID].mem_access_wdata = (void *)CLASS_MEM_ACCESS_WDATA;
+   pe[CLASS3_ID].mem_access_addr = (void *)CLASS_MEM_ACCESS_ADDR;
+   pe[CLASS3_ID].mem_access_rdata = (void *)CLASS_MEM_ACCESS_RDATA;
+
+   pe[CLASS4_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(4);
+   pe[CLASS4_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(4);
+   pe[CLASS4_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
+   pe[CLASS4_ID].mem_access_wdata = (void *)CLASS_MEM_ACCESS_WDATA;
+

[U-Boot] [PATCH 2/9] drivers: net: pfe_eth: provide pfe commands

2017-10-09 Thread Calvin Johnson

pfe_command provides command line support for several features that
support pfe like starting or stopping the pfe, checking the health
of the processor engines and checking status of different unit inside
pfe.

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 drivers/net/pfe_eth/Makefile  |   1 +
 drivers/net/pfe_eth/pfe_cmd.c | 537 ++
 2 files changed, 538 insertions(+)
 create mode 100644 drivers/net/pfe_eth/pfe_cmd.c

diff --git a/drivers/net/pfe_eth/Makefile b/drivers/net/pfe_eth/Makefile
index e78f1bf..3e88e53 100644
--- a/drivers/net/pfe_eth/Makefile
+++ b/drivers/net/pfe_eth/Makefile
@@ -5,6 +5,7 @@
 
 # Layerscape PFE driver
 obj-y += pfe.o \
+pfe_cmd.o  \
 pfe_driver.o   \
 pfe_eth.o  \
 pfe_firmware.o
diff --git a/drivers/net/pfe_eth/pfe_cmd.c b/drivers/net/pfe_eth/pfe_cmd.c
new file mode 100644
index 000..74f7c3d
--- /dev/null
+++ b/drivers/net/pfe_eth/pfe_cmd.c
@@ -0,0 +1,537 @@
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * @file
+ * @brief PFE utility commands
+ */
+
+#include 
+
+static inline void pfe_command_help(void)
+{
+   printf("Usage: pfe [pe | status | expt ] \n");
+}
+
+static void pfe_command_pe(int argc, char * const argv[])
+{
+   if (argc >= 3 && strcmp(argv[2], "pmem") == 0) {
+   if (argc >= 4 && strcmp(argv[3], "read") == 0) {
+   int i;
+   int num;
+   int id;
+   u32 addr;
+   u32 size;
+   u32 val;
+
+   if (argc == 7) {
+   num = simple_strtoul(argv[6], NULL, 0);
+   } else if (argc == 6) {
+   num = 1;
+   } else {
+   printf("Usage: pfe pe pmem read   
[]\n");
+   return;
+   }
+
+   id = simple_strtoul(argv[4], NULL, 0);
+   addr = simple_strtoul(argv[5], NULL, 16);
+   size = 4;
+
+   for (i = 0; i < num; i++, addr += 4) {
+   val = pe_pmem_read(id, addr, size);
+   val = be32_to_cpu(val);
+   if (!(i&3))
+   printf("%08x: ", addr);
+   printf("%08x%s", val, i == num - 1 || (i & 3)
+  == 3 ? "\n" : " ");
+   }
+
+   } else {
+   printf("Usage: pfe pe pmem read \n");
+   }
+   } else if (argc >= 3 && strcmp(argv[2], "dmem") == 0) {
+   if (argc >= 4 && strcmp(argv[3], "read") == 0) {
+   int i;
+   int num;
+   int id;
+   u32 addr;
+   u32 size;
+   u32 val;
+
+   if (argc == 7) {
+   num = simple_strtoul(argv[6], NULL, 0);
+   } else if (argc == 6) {
+   num = 1;
+   } else {
+   printf("Usage: pfe pe dmem read   
[]\n");
+   return;
+   }
+
+   id = simple_strtoul(argv[4], NULL, 0);
+   addr = simple_strtoul(argv[5], NULL, 16);
+   size = 4;
+
+   for (i = 0; i < num; i++, addr += 4) {
+   val = pe_dmem_read(id, addr, size);
+   val = be32_to_cpu(val);
+   if (!(i&3))
+   printf("%08x: ", addr);
+   printf("%08x%s", val, i == num - 1 || (i & 3)
+  == 3 ? "\n" : " ");
+   }
+
+   } else if (argc >= 4 && strcmp(argv[3], "write") == 0) {
+   int id;
+   u32 val;
+   u32 addr;
+   u32 size;
+
+   if (argc != 7) {
+   printf("Usage: pfe pe dmem write   
\n");
+   return;
+   }
+
+   id = simple_strtoul(argv[4], NULL, 0);
+   val = simple_strtoul(argv[5], NULL, 16);
+   val = cpu_to_be32(val);
+   addr = simple_strtoul(argv[6], NULL, 16);
+   size = 4;
+   pe_dmem_write(id, val, addr, size);
+   } else {
+   printf("Usage: pfe pe dmem [read | write] 
\n");
+   }
+

[U-Boot] [PATCH 3/9] drivers: net: pfe_eth: LS1012A PFE headers

2017-10-09 Thread Calvin Johnson

Contains all the pfe header files.

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 include/pfe_eth/pfe/cbus.h   |  75 +++
 include/pfe_eth/pfe/cbus/bmu.h   |  40 
 include/pfe_eth/pfe/cbus/class_csr.h | 181 +++
 include/pfe_eth/pfe/cbus/emac.h  | 150 +
 include/pfe_eth/pfe/cbus/gpi.h   |  62 
 include/pfe_eth/pfe/cbus/hif.h   |  68 +
 include/pfe_eth/pfe/cbus/hif_nocpy.h |  40 
 include/pfe_eth/pfe/cbus/tmu_csr.h   | 148 
 include/pfe_eth/pfe/cbus/util_csr.h  |  47 +
 include/pfe_eth/pfe/pfe.h| 178 ++
 include/pfe_eth/pfe_driver.h |  55 +++
 include/pfe_eth/pfe_eth.h| 111 +
 include/pfe_eth/pfe_firmware.h   |  17 
 13 files changed, 1172 insertions(+)
 create mode 100644 include/pfe_eth/pfe/cbus.h
 create mode 100644 include/pfe_eth/pfe/cbus/bmu.h
 create mode 100644 include/pfe_eth/pfe/cbus/class_csr.h
 create mode 100644 include/pfe_eth/pfe/cbus/emac.h
 create mode 100644 include/pfe_eth/pfe/cbus/gpi.h
 create mode 100644 include/pfe_eth/pfe/cbus/hif.h
 create mode 100644 include/pfe_eth/pfe/cbus/hif_nocpy.h
 create mode 100644 include/pfe_eth/pfe/cbus/tmu_csr.h
 create mode 100644 include/pfe_eth/pfe/cbus/util_csr.h
 create mode 100644 include/pfe_eth/pfe/pfe.h
 create mode 100644 include/pfe_eth/pfe_driver.h
 create mode 100644 include/pfe_eth/pfe_eth.h
 create mode 100644 include/pfe_eth/pfe_firmware.h

diff --git a/include/pfe_eth/pfe/cbus.h b/include/pfe_eth/pfe/cbus.h
new file mode 100644
index 000..ec31481
--- /dev/null
+++ b/include/pfe_eth/pfe/cbus.h
@@ -0,0 +1,75 @@
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _CBUS_H_
+#define _CBUS_H_
+
+#include "cbus/emac.h"
+#include "cbus/gpi.h"
+#include "cbus/bmu.h"
+#include "cbus/hif.h"
+#include "cbus/tmu_csr.h"
+#include "cbus/class_csr.h"
+#include "cbus/hif_nocpy.h"
+#include "cbus/util_csr.h"
+
+#define CBUS_BASE_ADDR ((void *)CONFIG_SYS_FSL_PFE_ADDR)
+
+/* PFE Control and Status Register Desciption */
+#define EMAC1_BASE_ADDR(CBUS_BASE_ADDR + 0x20)
+#define EGPI1_BASE_ADDR(CBUS_BASE_ADDR + 0x21)
+#define EMAC2_BASE_ADDR(CBUS_BASE_ADDR + 0x22)
+#define EGPI2_BASE_ADDR(CBUS_BASE_ADDR + 0x23)
+#define BMU1_BASE_ADDR (CBUS_BASE_ADDR + 0x24)
+#define BMU2_BASE_ADDR (CBUS_BASE_ADDR + 0x25)
+#define ARB_BASE_ADDR  (CBUS_BASE_ADDR + 0x26)
+#define DDR_CONFIG_BASE_ADDR   (CBUS_BASE_ADDR + 0x27)
+#define HIF_BASE_ADDR  (CBUS_BASE_ADDR + 0x28)
+#define HGPI_BASE_ADDR (CBUS_BASE_ADDR + 0x29)
+#define LMEM_BASE_ADDR (CBUS_BASE_ADDR + 0x30)
+#define LMEM_SIZE  0x1
+#define LMEM_END   (LMEM_BASE_ADDR + LMEM_SIZE)
+#define TMU_CSR_BASE_ADDR  (CBUS_BASE_ADDR + 0x31)
+#define CLASS_CSR_BASE_ADDR(CBUS_BASE_ADDR + 0x32)
+#define HIF_NOCPY_BASE_ADDR(CBUS_BASE_ADDR + 0x35)
+#define UTIL_CSR_BASE_ADDR (CBUS_BASE_ADDR + 0x36)
+#define CBUS_GPT_BASE_ADDR (CBUS_BASE_ADDR + 0x37)
+
+/*
+ * defgroup XXX_MEM_ACCESS_ADDR PE memory access through CSR
+ * XXX_MEM_ACCESS_ADDR register bit definitions.
+ */
+/* Internal Memory Write. */
+#define PE_MEM_ACCESS_WRITE(1<<31)
+/* Internal Memory Read. */
+#define PE_MEM_ACCESS_READ (0<<31)
+
+#define PE_MEM_ACCESS_IMEM (1<<15)
+#define PE_MEM_ACCESS_DMEM (1<<16)
+/* Byte Enables of the Internal memory access. These are interpred in BE */
+#define PE_MEM_ACCESS_BYTE_ENABLE(offset, size)(1 << (size)) - 1) 
<< (4 \
+   - (offset) - (size)))\
+   & 0xf) << 24)
+/* PFE cores states */
+#define CORE_DISABLE   0x
+#define CORE_ENABLE0x0001
+#define CORE_SW_RESET  0x0002
+
+/* LMEM defines */
+#define LMEM_HDR_SIZE  0x0010
+#define LMEM_BUF_SIZE_LN2  0x7
+#define LMEM_BUF_SIZE  (1 << LMEM_BUF_SIZE_LN2)
+
+/* DDR defines */
+#define DDR_HDR_SIZE   0x0100
+#define DDR_BUF_SIZE_LN2   0xb
+#define DDR_BUF_SIZE   (1 << DDR_BUF_SIZE_LN2)
+
+/* Clock generation through PLL */
+#define PLL_CLK_EN 1
+
+#endif /* _CBUS_H_ */
diff --git a/include/pfe_eth/pfe/cbus/bmu.h b/include/pfe_eth/pfe/cbus/bmu.h
new file mode 100644
index 000..f707cc3
--- /dev/null
+++ b/include/pfe_eth/pfe/cbus/bmu.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _BMU_H_
+#define _BMU_H_
+
+#define BMU_VERSION

[U-Boot] [PATCH 4/9] board: freescale: ls1012a: enable network support on ls1012a platforms

2017-10-09 Thread Calvin Johnson

Ethernet support on all three LS1012A platforms(FRDM, QDS and RDB) is
enabled with this patch.

eth.c files for all 3 platforms contain board ethernet initialization
function and also function to reset phy.

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 board/freescale/ls1012afrdm/Makefile  |   1 +
 board/freescale/ls1012afrdm/eth.c |  86 +
 board/freescale/ls1012afrdm/ls1012afrdm.c |   5 -
 board/freescale/ls1012aqds/Makefile   |   1 +
 board/freescale/ls1012aqds/eth.c  | 263 ++
 board/freescale/ls1012aqds/ls1012aqds.c   |  97 +-
 board/freescale/ls1012aqds/ls1012aqds_pfe.h   |  48 +
 board/freescale/ls1012aqds/ls1012aqds_qixis.h |   2 +-
 board/freescale/ls1012ardb/Makefile   |   1 +
 board/freescale/ls1012ardb/eth.c  |  70 +++
 board/freescale/ls1012ardb/ls1012ardb.c   |   4 -
 include/configs/ls1012ardb.h  |   5 +
 12 files changed, 568 insertions(+), 15 deletions(-)
 create mode 100644 board/freescale/ls1012afrdm/eth.c
 create mode 100644 board/freescale/ls1012aqds/eth.c
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds_pfe.h
 create mode 100644 board/freescale/ls1012ardb/eth.c

diff --git a/board/freescale/ls1012afrdm/Makefile 
b/board/freescale/ls1012afrdm/Makefile
index dbfa2ce..1364f22 100644
--- a/board/freescale/ls1012afrdm/Makefile
+++ b/board/freescale/ls1012afrdm/Makefile
@@ -5,3 +5,4 @@
 #
 
 obj-y += ls1012afrdm.o
+obj-y += eth.o
diff --git a/board/freescale/ls1012afrdm/eth.c 
b/board/freescale/ls1012afrdm/eth.c
new file mode 100644
index 000..d9583ce
--- /dev/null
+++ b/board/freescale/ls1012afrdm/eth.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define DEFAULT_PFE_MDIO_NAME "PFE_MDIO"
+#define DEFAULT_PFE_MDIO1_NAME "PFE_MDIO1"
+
+#define MASK_ETH_PHY_RST   0x0100
+
+void reset_phy(void)
+{
+   unsigned int val;
+   struct ccsr_gpio *pgpio = (void *)(GPIO1_BASE_ADDR);
+
+   setbits_be32(&pgpio->gpdir, MASK_ETH_PHY_RST);
+
+   val = in_be32(&pgpio->gpdat);
+   setbits_be32(&pgpio->gpdat, val & ~MASK_ETH_PHY_RST);
+   mdelay(10);
+
+   val = in_be32(&pgpio->gpdat);
+   setbits_be32(&pgpio->gpdat, val | MASK_ETH_PHY_RST);
+   mdelay(50);
+}
+
+int board_eth_init(bd_t *bis)
+{
+#ifdef CONFIG_FSL_PFE
+   struct mii_dev *bus;
+   struct mdio_info mac1_mdio_info;
+
+   reset_phy();
+
+   init_pfe_scfg_dcfg_regs();
+
+   mac1_mdio_info.reg_base = (void *)EMAC1_BASE_ADDR;
+   mac1_mdio_info.name = DEFAULT_PFE_MDIO_NAME;
+
+   bus = ls1012a_mdio_init(&mac1_mdio_info);
+   if (!bus) {
+   printf("Failed to register mdio\n");
+   return -1;
+   }
+
+   /* We don't really need this MDIO bus,
+* this is called just to initialize EMAC2 MDIO interface */
+   mac1_mdio_info.reg_base = (void *)0x0422; /*EMAC2_BASE_ADDR*/
+   mac1_mdio_info.name = DEFAULT_PFE_MDIO1_NAME;
+
+   bus = ls1012a_mdio_init(&mac1_mdio_info);
+   if (!bus) {
+   printf("Failed to register mdio\n");
+   return -1;
+   }
+
+   /* MAC1 */
+   ls1012a_set_mdio(0, miiphy_get_dev_by_name(DEFAULT_PFE_MDIO_NAME));
+   ls1012a_set_phy_address_mode(0, EMAC1_PHY_ADDR,
+PHY_INTERFACE_MODE_SGMII);
+
+   /* MAC2 */
+   ls1012a_set_mdio(1, miiphy_get_dev_by_name(DEFAULT_PFE_MDIO_NAME));
+   ls1012a_set_phy_address_mode(1, EMAC2_PHY_ADDR,
+PHY_INTERFACE_MODE_SGMII);
+
+
+   return cpu_eth_init(bis);
+#endif
+}
diff --git a/board/freescale/ls1012afrdm/ls1012afrdm.c 
b/board/freescale/ls1012afrdm/ls1012afrdm.c
index 9afd1c4..0145886 100644
--- a/board/freescale/ls1012afrdm/ls1012afrdm.c
+++ b/board/freescale/ls1012afrdm/ls1012afrdm.c
@@ -57,11 +57,6 @@ int dram_init(void)
return 0;
 }
 
-int board_eth_init(bd_t *bis)
-{
-   return pci_eth_init(bis);
-}
-
 int board_early_init_f(void)
 {
fsl_lsch2_early_init_f();
diff --git a/board/freescale/ls1012aqds/Makefile 
b/board/freescale/ls1012aqds/Makefile
index 0b813f9..b18494a 100644
--- a/board/freescale/ls1012aqds/Makefile
+++ b/board/freescale/ls1012aqds/Makefile
@@ -5,3 +5,4 @@
 #
 
 obj-y += ls1012aqds.o
+obj-y += eth.o
diff --git a/board/freescale/ls1012aqds/eth.c b/board/freescale/ls1012aqds/eth.c
new file mode 100644
index 000..bf916f3
--- /dev/null
+++ b/board/freescale/ls1012aqds/eth.c
@@ -0,0 +1,263 @@
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#

[U-Boot] [PATCH 5/9] armv8: fsl-lsch2: initialize pfe gemac

2017-10-09 Thread Calvin Johnson

Call gemac_initialize to initialize both gemacs of pfe.

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index ef3e300..25cd8d7 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_FSL_PFE
+#include 
+#endif
 #ifdef CONFIG_FSL_ESDHC
 #include 
 #endif
@@ -476,6 +479,11 @@ int cpu_eth_init(bd_t *bis)
 {
int error = 0;
 
+#if defined(CONFIG_FSL_PFE)
+   gemac_initialize(bis, 0 , "pfe_eth0");
+   gemac_initialize(bis, 1 , "pfe_eth1");
+#endif
+
 #if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
error = fsl_mc_ldpaa_init(bis);
 #endif
-- 
2.7.4

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

[U-Boot] [PATCH 6/9] armv8: fsl-lsch2: add pfe macros and update ccsr_scfg structure

2017-10-09 Thread Calvin Johnson

SoC specific PFE macros are defined and structure ccsr_scfg
is updated with members defined for PFE.

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index 0f43832..a395a2f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -398,6 +398,21 @@ struct ccsr_gur {
 #define SCFG_SNPCNFGCR_SATARDSNP   0x0080
 #define SCFG_SNPCNFGCR_SATAWRSNP   0x0040
 
+/* RGMIIPCR bit definitions*/
+#define SCFG_RGMIIPCR_EN_AUTO  (0x0008)
+#define SCFG_RGMIIPCR_SETSP_1000M  (0x0004)
+#define SCFG_RGMIIPCR_SETSP_100M   (0x)
+#define SCFG_RGMIIPCR_SETSP_10M(0x0002)
+#define SCFG_RGMIIPCR_SETFD(0x0001)
+
+/*PFEASBCR bit definitions */
+#define SCFG_PFEASBCR_ARCACHE0 (0x8000)
+#define SCFG_PFEASBCR_AWCACHE0 (0x4000)
+#define SCFG_PFEASBCR_ARCACHE1 (0x2000)
+#define SCFG_PFEASBCR_AWCACHE1 (0x1000)
+#define SCFG_PFEASBCR_ARSNP(0x0800)
+#define SCFG_PFEASBCR_AWSNP(0x0400)
+
 /* Supplemental Configuration Unit */
 struct ccsr_scfg {
u8 res_000[0x100-0x000];
@@ -415,7 +430,12 @@ struct ccsr_scfg {
u8 res_140[0x158-0x140];
u32 altcbar;
u32 qspi_cfg;
-   u8 res_160[0x180-0x160];
+   u8 res_160[0x164-0x160];
+   u32 wr_qos1;
+   u32 wr_qos2;
+   u32 rd_qos1;
+   u32 rd_qos2;
+   u8 res_174[0x180-0x174];
u32 dmamcr;
u8 res_184[0x188-0x184];
u32 gic_align;
@@ -446,7 +466,21 @@ struct ccsr_scfg {
u32 usb_refclk_selcr1;
u32 usb_refclk_selcr2;
u32 usb_refclk_selcr3;
-   u8 res_424[0x600-0x424];
+   u8 res_424[0x434-0x424];
+   u32 rgmiipcr;
+   u32 res_438;
+   u32 rgmiipsr;
+   u32 pfepfcssr1;
+   u32 pfeintencr1;
+   u32 pfepfcssr2;
+   u32 pfeintencr2;
+   u32 pfeerrcr;
+   u32 pfeeerrintencr;
+   u32 pfeasbcr;
+   u32 pfebsbcr;
+   u8 res_460[0x484-0x460];
+   u32 mdioselcr;
+   u8 res_468[0x600-0x488];
u32 scratchrw[4];
u8 res_610[0x680-0x610];
u32 corebcr;
-- 
2.7.4

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

[U-Boot] [PATCH 7/9] armv8: fsl-lsch2: configure pfe's scfg & dcfg registers

2017-10-09 Thread Calvin Johnson

Define init_pfe_scfg_dcfg_regs to configure scfg and dcfg
registers of pfe.

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 18 ++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |  3 +++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 5c429d4..c6815f3 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -577,6 +577,24 @@ int setup_chip_volt(void)
return 0;
 }
 
+#ifdef CONFIG_FSL_PFE
+void init_pfe_scfg_dcfg_regs(void)
+{
+   struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR;
+
+   out_be32(&scfg->pfeasbcr,
+in_be32(&scfg->pfeasbcr) | SCFG_PFEASBCR_AWCACHE0);
+   out_be32(&scfg->pfebsbcr,
+in_be32(&scfg->pfebsbcr) | SCFG_PFEASBCR_AWCACHE0);
+
+   /* CCI-400 QoS settings for PFE */
+   out_be32(&scfg->wr_qos1, 0x0ff0);
+   out_be32(&scfg->rd_qos1, 0x0ff0);
+
+   out_be32((void *)CONFIG_SYS_DCSR_DCFG_ADDR + 0x524, 0x2000);
+}
+#endif
+
 void fsl_lsch2_early_init_f(void)
 {
struct ccsr_cci400 *cci = (struct ccsr_cci400 *)(CONFIG_SYS_IMMR +
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
index 697f072..08a42b9 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -120,6 +120,9 @@ void fsl_lsch2_early_init_f(void);
 int setup_chip_volt(void);
 /* Setup core vdd in unit mV */
 int board_setup_core_volt(u32 vdd);
+#ifdef CONFIG_FSL_PFE
+void init_pfe_scfg_dcfg_regs(void);
+#endif
 #endif
 void ddr_enable_0v9_volt(bool en);
 
-- 
2.7.4

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

[U-Boot] [PATCH 8/9] fsl: csu: enable ns access for PFE

2017-10-09 Thread Calvin Johnson

Enable non-secure access for PFE block.

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 arch/arm/include/asm/arch-fsl-layerscape/ns_access.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/ns_access.h 
b/arch/arm/include/asm/arch-fsl-layerscape/ns_access.h
index f46f1d8..fe97a93 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/ns_access.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/ns_access.h
@@ -26,6 +26,7 @@ enum csu_cslx_ind {
CSU_CSLX_PCIE3_IO,
CSU_CSLX_USB3 = 20,
CSU_CSLX_USB2,
+   CSU_CSLX_PFE = 23,
CSU_CSLX_SERDES = 32,
CSU_CSLX_QDMA,
CSU_CSLX_LPUART2,
@@ -105,6 +106,7 @@ static struct csu_ns_dev ns_dev[] = {
 {CSU_CSLX_PCIE3_IO, CSU_ALL_RW},
 {CSU_CSLX_USB3, CSU_ALL_RW},
 {CSU_CSLX_USB2, CSU_ALL_RW},
+{CSU_CSLX_PFE, CSU_ALL_RW},
 {CSU_CSLX_SERDES, CSU_ALL_RW},
 {CSU_CSLX_QDMA, CSU_ALL_RW},
 {CSU_CSLX_LPUART2, CSU_ALL_RW},
-- 
2.7.4

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

Re: [U-Boot] the boot process breaks.

2017-10-09 Thread nabil efrin



Hello 

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

[U-Boot] [PATCH 9/9] configs: ls1012a: add pfe configuration for LS1012A

2017-10-09 Thread Calvin Johnson

Signed-off-by: Calvin Johnson 
Signed-off-by: Anjaneyulu Jagarlmudi 
---
 configs/ls1012afrdm_qspi_defconfig |  1 +
 configs/ls1012aqds_qspi_defconfig  |  1 +
 configs/ls1012ardb_qspi_defconfig  |  1 +
 drivers/net/Kconfig|  1 +
 drivers/net/Makefile   |  1 +
 drivers/net/pfe_eth/Kconfig| 23 ++-
 include/configs/ls1012a_common.h   |  6 +++---
 include/configs/ls1012afrdm.h  |  7 +++
 include/configs/ls1012aqds.h   | 14 ++
 include/configs/ls1012ardb.h   |  8 
 10 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/configs/ls1012afrdm_qspi_defconfig 
b/configs/ls1012afrdm_qspi_defconfig
index 84b5577..7db7a18 100644
--- a/configs/ls1012afrdm_qspi_defconfig
+++ b/configs/ls1012afrdm_qspi_defconfig
@@ -32,6 +32,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
+CONFIG_FSL_PFE=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
diff --git a/configs/ls1012aqds_qspi_defconfig 
b/configs/ls1012aqds_qspi_defconfig
index 2124273..4b9fdf5 100644
--- a/configs/ls1012aqds_qspi_defconfig
+++ b/configs/ls1012aqds_qspi_defconfig
@@ -37,6 +37,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
+CONFIG_FSL_PFE=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
diff --git a/configs/ls1012ardb_qspi_defconfig 
b/configs/ls1012ardb_qspi_defconfig
index 40349ce..d63e736 100644
--- a/configs/ls1012ardb_qspi_defconfig
+++ b/configs/ls1012ardb_qspi_defconfig
@@ -35,6 +35,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
+CONFIG_FSL_PFE=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 736aab2..c82c63b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -304,4 +304,5 @@ config FEC2_PHY_NORXERR
  The PHY does not have a RXERR line (RMII only).
  (so program the FEC to ignore it).
 
+source "drivers/net/pfe_eth/Kconfig"
 endif # NETDEVICES
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 94a4fd8..0572cde 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -75,3 +75,4 @@ obj-$(CONFIG_FSL_MEMAC) += fm/memac_phy.o
 obj-$(CONFIG_VSC9953) += vsc9953.o
 obj-$(CONFIG_PIC32_ETH) += pic32_mdio.o pic32_eth.o
 obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
+obj-$(CONFIG_FSL_PFE) += pfe_eth/
diff --git a/drivers/net/pfe_eth/Kconfig b/drivers/net/pfe_eth/Kconfig
index b9996df..c05aeda 100644
--- a/drivers/net/pfe_eth/Kconfig
+++ b/drivers/net/pfe_eth/Kconfig
@@ -1,8 +1,29 @@
+menuconfig FSL_PFE
+   bool "Freescale PFE driver"
+   help
+ This driver provides support for Freescale PFE.
+
+if FSL_PFE
+
 config UTIL_PE_DISABLED
bool
help
  Disable UTIL processor engine of PFE
 
-config SYS_FSL_PPFE_ADDR
+config SYS_FSL_PFE_ADDR
hex "PFE base address"
default 0x0400
+
+config SYS_LS_PFE_FW_ADDR
+   hex "Flash address of PFE firmware"
+   default 0x40a0
+
+config DDR_PFE_PHYS_BASEADDR
+   hex "PFE DDR physical base address"
+   default 0x0380
+
+config DDR_PFE_BASEADDR
+   hex "PFE DDR base address"
+   default 0x8380
+
+endif
diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 52c2c3a..3df5586 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -113,9 +113,9 @@
 #define CONFIG_BOOTARGS"console=ttyS0,115200 root=/dev/ram0 " \
"earlycon=uart8250,mmio,0x21c0500 quiet 
lpj=25"
 #undef CONFIG_BOOTCOMMAND
-#define CONFIG_BOOTCOMMAND "sf probe 0:0; sf read $kernel_load "\
-   "$kernel_start $kernel_size && "\
-   "bootm $kernel_load"
+#define CONFIG_BOOTCOMMAND "pfe stop; sf probe 0:0; sf read $kernel_load "\
+   "$kernel_start $kernel_size && "\
+   "bootm $kernel_load"
 
 /* Monitor Command Prompt */
 #define CONFIG_SYS_CBSIZE  512 /* Console I/O Buffer Size */
diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h
index 544dea0..a3f8824 100644
--- a/include/configs/ls1012afrdm.h
+++ b/include/configs/ls1012afrdm.h
@@ -9,6 +9,13 @@
 
 #include "ls1012a_common.h"
 
+#ifdef CONFIG_FSL_PFE
+#define EMAC1_PHY_ADDR  0x2
+#define EMAC2_PHY_ADDR  0x1
+#define CONFIG_PHYLIB
+#define CONFIG_PHY_REALTEK
+#endif
+
 /* DDR */
 #define CONFIG_DIMM_SLOTS_PER_CTLR 1
 #define CONFIG_CHIP_SELECTS_PER_CTRL   1
diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
index 16714bb..9873339 100644
--- a/include/configs/ls1012aqds.h
+++ b/include/configs/ls1012aqds.h
@@ -9,6 +9,20 @@
 
 #include "ls1012a_common.h"
 
+/* PFE Ethernet */
+#ifdef CONFIG_FSL_PFE
+#define EMAC1_PHY_ADDR  0x1e
+#define EMAC2_PHY_ADDR

Re: [U-Boot] [PATCH 1/1] rockchip: provide installation instruction for Firefly-RK3399.

2017-10-09 Thread Mark Kettenis

> From: "Dr. Philipp Tomsich" 
> Date: Mon, 9 Oct 2017 12:31:22 +0200
> 
> > The "pure" U-Boot approach that is currently documented works just
> > fine.  The only problem is that the firefly-rk3399 by default boots
> > from eMMC.  And the first-stage bootloader only recognizes SD-cards
> > with the propriatary loader.  So the trick is to wipe the firmware
> > stored in eMMC or replace it with U-Boot.
> 
> Would you be willing to submit a patch with documentation for this?

I'm still not sure what the right approach is...

Doing what I did (boot into the Ubuntu shipped with the original
firmware and use dd(1) to overwrite the firmware image) almost
certainly isn't.

I suppose the best approach would be to use the "rockusb" mode to
overwrite the eMMC firmware with a "pure" U-Boot image would be the
way to go, but I didn't get that to work using OpenBSD's libusb and I
didn't have a Linux box around.  I plan to come back to that but not
before november :(.

Cheers,

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

Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

2017-10-09 Thread Tom Rini

On Mon, Oct 09, 2017 at 05:19:53PM +1100, Jonathan Gray wrote:
> On Sun, Oct 08, 2017 at 11:12:28PM -0400, Tom Rini wrote:
> > On Sun, Oct 08, 2017 at 10:56:26PM -0300, Fabio Estevam wrote:
> > > On Sun, Oct 8, 2017 at 11:04 AM, Jonathan Gray  wrote:
> > > 
> > > > It turns out to be
> > > >
> > > > commit 2460098cffacd18729262e3ed36656e6943783ed
> > > > Author: Tom Rini 
> > > > Date:   Fri Sep 22 07:37:43 2017 -0400
> > > >
> > > > fs/fat: Reduce stack usage
> > > >
> > > > We have limited stack in SPL builds.  Drop itrblock and move to
> > > > malloc/free of itr to move this off of the stack.  As part of this 
> > > > fix a
> > > > double-free issue in fat_size().
> > > >
> > > > Signed-off-by: Tom Rini 
> > > > ---
> > > > Rework to use malloc/free as moving this to a global overflows some 
> > > > SH
> > > > targets.
> > > >
> > > >  fs/fat/fat.c | 14 ++
> > > >  1 file changed, 10 insertions(+), 4 deletions(-)
> > > >
> > > > With that reverted I just get the efi loader problem, no alignment 
> > > > errors.
> > > 
> > > Thanks for doing the bisect.
> > > 
> > > Tom, can you prepare a fix for this?
> > 
> > No, this is a required fix for other platforms.  Why is this failing in
> > the particular case that it's failing in?
> 
> Switching the malloc calls for malloc_cache_aligned also avoids the problem.

Ah, good one.  Can you please submit this as a proper patch?  Thanks!

> 
> U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47)
> Trying to boot from MMC1
> 
> 
> U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
> 
> CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> CPU:   Extended Commercial temperature grade (-20C to 105C) at 34C
> Reset cause: WDOG
> Board: MX6 Cubox-i
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0
> *** Warning - bad CRC, using default environment
> 
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
> CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
> CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
> CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
> CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
> CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
> CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8
> CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
> CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8
> CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
> CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470
> CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
> CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
> ERR

Re: [U-Boot] [PATCH] usb: xhci: Add Renesas R-Car xHCI driver

2017-10-09 Thread Marek Vasut

On 10/09/2017 09:16 AM, Bin Meng wrote:

[...]

>> +++ b/Licenses/r8a779x_usb3.txt
>> @@ -0,0 +1,26 @@
>> +Copyright (c) 2014, Renesas Electronics Corporation
>> +All rights reserved.
>> +
>> +Redistribution and use in binary form, without modification, are permitted
>> +provided that the following conditions are met:
>> +
>> +1. Redistribution in binary form must reproduce the above copyright notice,
>> +   this list of conditions and the following disclaimer in the documentation
>> +   and/or other materials provided with the distribution.
>> +2. The name of Renesas Electronics Corporation may not be used to endorse or
>> +   promote products derived from this software without specific prior 
>> written
>> +   permission.
>> +3. Reverse engineering, decompilation, or disassembly of this software is
>> +   not permitted.
>> +
>> +THIS SOFTWARE IS PROVIDED "AS IS" AND RENESAS ELECTRONICS CORPORATION 
>> DISCLAIMS
>> +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
>> IMPLIED
>> +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND
>> +NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL RENESAS ELECTRONICS
>> +CORPORATION BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
>> EXEMPLARY,
>> +OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> +SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
>> +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> +ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
>> +POSSIBILITY OF SUCH DAMAGE.
> 
> Is there any SPDX form of this license?

Nope :(

>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index f5f19ed775..cad9af6977 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -47,6 +47,14 @@ config USB_XHCI_ROCKCHIP
>> help
>>   Enables support for the on-chip xHCI controller on Rockchip SoCs.
[...]

>> +/* Register Settings */
>> +/* FW Download Control & Status */
>> +#define RCAR_USB3_DL_CTRL_ENABLE   0x0001
>> +#define RCAR_USB3_DL_CTRL_FW_SUCCESS   0x0010
>> +#define RCAR_USB3_DL_CTRL_FW_SET_DATA0 0x0100
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
> 
> This is not needed.

Removed

>> +struct rcar_xhci_platdata {
>> +   fdt_addr_t  hcd_base;
>> +   struct clk  clk;
>> +};
>> +
>> +/**
>> + * Contains pointers to register base addresses
>> + * for the usb controller.
>> + */
>> +struct rcar_xhci {
>> +   struct xhci_ctrl ctrl;  /* Needs to come first in this struct! */
>> +   struct usb_platdata usb_plat;
>> +   struct xhci_hccr *hcd;
>> +};
>> +
>> +static int xhci_rcar_download_fw(struct rcar_xhci *ctx, const u32 *fw_data,
>> +const size_t fw_array_size)
>> +{
>> +   void __iomem *regs = (void __iomem *)ctx->hcd;
>> +   int i, ret;
>> +
>> +   /* Download R-Car USB3.0 firmware */
>> +   setbits_le32(regs + RCAR_USB3_DL_CTRL, RCAR_USB3_DL_CTRL_ENABLE);
>> +
>> +   for (i = 0; i < fw_array_size; i++) {
>> +   writel(fw_data[i], regs + RCAR_USB3_FW_DATA0);
>> +   setbits_le32(regs + RCAR_USB3_DL_CTRL,
>> +RCAR_USB3_DL_CTRL_FW_SET_DATA0);
>> +
>> +   ret = wait_for_bit("xhci-rcar", regs + RCAR_USB3_DL_CTRL,
>> +  RCAR_USB3_DL_CTRL_FW_SET_DATA0, false,
>> +  10, false);
>> +   if (ret)
>> +   break;
>> +   }
>> +
>> +   clrbits_le32(regs + RCAR_USB3_DL_CTRL, RCAR_USB3_DL_CTRL_ENABLE);
>> +
>> +   ret = wait_for_bit("xhci-rcar", regs + RCAR_USB3_DL_CTRL,
>> +  RCAR_USB3_DL_CTRL_FW_SUCCESS, true,
>> +  10, false);
>> +
>> +   return ret;
>> +}
>> +
>> +static int xhci_rcar_probe(struct udevice *dev)
>> +{
>> +   struct rcar_xhci_platdata *plat = dev_get_platdata(dev);
>> +   struct rcar_xhci *ctx = dev_get_priv(dev);
>> +   struct xhci_hcor *hcor;
>> +   int len, ret;
>> +
>> +   ret = clk_get_by_index(dev, 0, &plat->clk);
>> +   if (ret < 0) {
>> +   dev_err(dev, "Failed to get USB3 clock\n");
>> +   return ret;
>> +   }
>> +
>> +   ret = clk_enable(&plat->clk);
>> +   if (ret) {
>> +   dev_err(dev, "Failed to enable USB3 clock\n");
>> +   goto err_clk;
>> +   }
>> +
>> +   ctx->hcd = (struct xhci_hccr *)plat->hcd_base;
>> +   len = HC_LENGTH(xhci_readl(&ctx->hcd->cr_capbase));
>> +   hcor = (struct xhci_hcor *)((uintptr_t)ctx->hcd + len);
>> +
>> +   ret = xhci_rcar_download_fw(ctx, firmware_r8a779x_usb3_v3,
>> +   ARRAY_SIZE(firmware_r8a779x_usb3_v3));
>> +   if (ret) {
>> +   dev_err(dev, "Failed to download firmware\n");
>> +

[U-Boot] [PATCH v2 0/2] Support for TI bandgap temperature sensor

2017-10-09 Thread Faiz Abbas

Adding support for TI bandgap temperature sensor.
Also add dt support for bandgap sensor in spl.

Faiz Abbas (2):
  thermal: ti-bandgap: Add support for temperature sensor
  ARM: dts: OMAP5+: Add support for bandgap sensor in SPL

 arch/arm/dts/omap5-u-boot.dtsi |   4 +
 common/spl/Kconfig |   8 +
 configs/dra7xx_evm_defconfig   |   3 +
 .../thermal/ti_soc_thermal.txt |  35 
 drivers/Makefile   |   2 +-
 drivers/thermal/Kconfig|   6 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/ti-bandgap.c   | 197 +
 8 files changed, 255 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/thermal/ti_soc_thermal.txt
 create mode 100644 drivers/thermal/ti-bandgap.c

-- 
2.7.4

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

[U-Boot] [PATCH v2 1/2] thermal: ti-bandgap: Add support for temperature sensor

2017-10-09 Thread Faiz Abbas

The dra7xx series of SOCs contain a temperature sensor and an
associated analog-to-digital converter (ADC) which produces
an output which is proportional to the SOC temperature.
Add support for this temperature sensor.

Signed-off-by: Faiz Abbas 
---
v2:
 1. Removed extra elements from ti_bandgap
 2. Changed base address to ulong
 3. Changed to udev to dev to maintain consistency
 4. minor format changes

 common/spl/Kconfig |   8 +
 configs/dra7xx_evm_defconfig   |   3 +
 .../thermal/ti_soc_thermal.txt |  35 
 drivers/Makefile   |   2 +-
 drivers/thermal/Kconfig|   6 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/ti-bandgap.c   | 197 +
 7 files changed, 251 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/thermal/ti_soc_thermal.txt
 create mode 100644 drivers/thermal/ti-bandgap.c

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0bd8370..0bf3ee3 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -604,6 +604,14 @@ config SPL_SPI_SUPPORT
  enable SPI drivers that are needed for other purposes also, such
  as a SPI PMIC.
 
+config SPL_THERMAL
+   bool "Driver support for thermal devices"
+   help
+ Enable support for temperature-sensing devices. Some SoCs have on-chip
+ temperature sensors to permit warnings, speed throttling or even
+ automatic power-off when the temperature gets too high or low. Other
+ devices may be discrete but connected on a suitable bus.
+
 config SPL_USB_HOST_SUPPORT
bool "Support USB host drivers"
help
diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index 468c288..447fb89 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -90,3 +90,6 @@ CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0451
 CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
+CONFIG_SPL_THERMAL=y
+CONFIG_DM_THERMAL=y
+CONFIG_TI_DRA7_THERMAL=y
diff --git a/doc/device-tree-bindings/thermal/ti_soc_thermal.txt 
b/doc/device-tree-bindings/thermal/ti_soc_thermal.txt
new file mode 100644
index 000..b4e88c2
--- /dev/null
+++ b/doc/device-tree-bindings/thermal/ti_soc_thermal.txt
@@ -0,0 +1,35 @@
+* Texas Instrument dra7xx SCM bandgap bindings
+
+In the System Control Module, SoC supplies a voltage reference
+and a temperature sensor feature that are gathered in the band
+gap voltage and temperature sensor (VBGAPTS) module. The band
+gap provides current and voltage reference for its internal
+circuits and other analog IP blocks. The analog-to-digital
+converter (ADC) produces an output value that is proportional
+to the silicon temperature.
+
+Required properties:
+- compatible : Should be:
+  - "ti,dra752-bandgap"
+- interrupts : this entry should indicate which interrupt line
+the talert signal is routed to;
+- regs : this is specific to each bandgap version, because
+the mapping may change from soc to soc, apart from depending
+on available features.
+
+Optional:
+- gpios : this entry should be used to inform which GPIO
+line the tshut signal is routed to. The informed GPIO will
+be treated as an IRQ;
+
+Example:
+bandgap {
+   reg = <0x4a0021e0 0xc
+   0x4a00232c 0xc
+   0x4a002380 0x2c
+   0x4a0023C0 0x3c
+   0x4a002564 0x8
+   0x4a002574 0x50>;
+   compatible = "ti,dra752-bandgap";
+   interrupts = <0 126 4>; /* talert */
+};
diff --git a/drivers/Makefile b/drivers/Makefile
index dab5c18..35510ca 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -50,7 +50,7 @@ obj-$(CONFIG_SPL_SATA_SUPPORT) += ata/ scsi/
 obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
 obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
 obj-$(CONFIG_SPL_FPGA_SUPPORT) += fpga/
-
+obj-$(CONFIG_SPL_THERMAL) += thermal/
 endif
 endif
 
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 886f5fa..a71b9be 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -17,4 +17,10 @@ config IMX_THERMAL
   cpufreq is used as the cooling device to throttle CPUs when the
   passive trip is crossed.
 
+config TI_DRA7_THERMAL
+bool "Temperature sensor driver for TI dra7xx SOCs"
+help
+Enable thermal support for for the Texas Instruments DRA752 SoC family.
+The driver supports reading CPU temperature.
+
 endif # if DM_THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index d768f5e..f6271a5 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,3 +7,4 @@
 
 obj-$(CONFIG_DM_THERMAL) += thermal-uclass.o
 obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_TI_DRA7_THERMAL) += ti-bandgap.o
diff --git a/drivers/thermal/ti-bandgap.c b/drivers/thermal/ti-bandgap.c
new file mode

[U-Boot] [PATCH v2 2/2] ARM: dts: OMAP5+: Add support for bandgap sensor in SPL

2017-10-09 Thread Faiz Abbas

Mark bandgap node as uboot,dm-spl so that it can be accessed in spl

Signed-off-by: Faiz Abbas 
---
 arch/arm/dts/omap5-u-boot.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/omap5-u-boot.dtsi b/arch/arm/dts/omap5-u-boot.dtsi
index fdaa692..bf2684c 100644
--- a/arch/arm/dts/omap5-u-boot.dtsi
+++ b/arch/arm/dts/omap5-u-boot.dtsi
@@ -18,6 +18,10 @@
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp", "simple-bus";
};
+
+   bandgap@4a0021e0 {
+   u-boot,dm-spl;
+   };
};
 };
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09 Thread Jonathan Gray

On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
> >> This fixes an issue with OpenBSD's bootloader, and I think should also
> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
> >> we were creating disk objects for the partitions, but not also the
> >> parent device.
> >>
> >> Reported-by: Jonathan Gray 
> >> Signed-off-by: Rob Clark 
> >
> > Thanks for looking into this.  While this lets armv7/bootarm.efi
> > boot again on cubox-i and bbb it doesn't help rpi3.
> >
> > What is the easiest way to get U-Boot to display these paths
> > to be able to compare the current behaviour to 2017.09?
> >
> 
> in grub, there is the lsefi command, not sure if the OpenBSD
> bootloader has something similar?
> 
> u-boot implements that device-path to text protocol, so it should be
> pretty easy to implement something like this if not.
> 
> BR,
> -R

With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
is no longer seen.  Is it possible having U-Boot on mmc but directing
it to load off usb is somehow involved here?

efi_bootdp obtained from the loaded image protocol

2017.09

Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
78959 bytes read in 76 ms (1013.7 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
Scanning disk usb_mass_storage.lun0...
Found 2 disks
efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 4
depth=0
i=0
efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
i=1
efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>> OpenBSD/arm64 BOOTAA64 0.8
boot> 
booting sd0a:/bsd: 3871708+578596+509352+803952 
[283845+96+451968+239920]=0x82f330

git + patch

Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
Scanning disk usb_mass_storage.lun0...
Found 2 disks
efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 1
efi_device_path_depth looking for type 4 i=1 type 3
efi_device_path_depth looking for type 4 i=2 type 3
efi_device_path_depth looking for type 4 i=3 type 3
efi_device_path_depth no match for type 4
depth=-1
i=0
i=1
i=2
i=3
>> OpenBSD/arm64 BOOTAA64 0.8
boot> 
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] fs/fat: fix unaligned access regression

2017-10-09 Thread Jonathan Gray

Since
2460098cffacd18729262e3ed36656e6943783ed (fs/fat: Reduce stack usage)
Trying to load a file off a FAT fs on i.MX 6 based CuBox-i4Pro fails:

switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
...

Switching the malloc() calls to malloc_cache_aligned() avoids
the alignment errors and allows booting to continue.

Signed-off-by: Jonathan Gray 
---
 fs/fat/fat.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 3d3e17e8fa..d299f317a9 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1038,7 +1038,7 @@ int fat_exists(const char *filename)
fat_itr *itr;
int ret;
 
-   itr = malloc(sizeof(fat_itr));
+   itr = malloc_cache_aligned(sizeof(fat_itr));
ret = fat_itr_root(itr, &fsdata);
if (ret)
return 0;
@@ -1055,7 +1055,7 @@ int fat_size(const char *filename, loff_t *size)
fat_itr *itr;
int ret;
 
-   itr = malloc(sizeof(fat_itr));
+   itr = malloc_cache_aligned(sizeof(fat_itr));
ret = fat_itr_root(itr, &fsdata);
if (ret)
return ret;
@@ -1089,7 +1089,7 @@ int file_fat_read_at(const char *filename, loff_t pos, 
void *buffer,
fat_itr *itr;
int ret;
 
-   itr = malloc(sizeof(fat_itr));
+   itr = malloc_cache_aligned(sizeof(fat_itr));
ret = fat_itr_root(itr, &fsdata);
if (ret)
return ret;
-- 
2.14.2

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

Re: [U-Boot] [PATCH 031/080] serial: ns16550: Fix address translation

2017-10-09 Thread Mario Six

(adding Philipp since he converted lots of drivers to livetree recently)

On Mon, Oct 9, 2017 at 6:48 AM, Simon Glass  wrote:
> Hi Mario,
>
> On 29 September 2017 at 06:51, Mario Six  wrote:
>> The dev_read_addr function does not do any bus translations, and just
>> returns the raw address read from the device tree, which makes the
>> driver not work on systems that need bus translations to get the actual
>> memory address of the device's register space.
>
> Aside from any current functionality, what is the correct thing for
> dev_read_addr() to do? I worry that the two parts (live/flat tree)
> might do different things.
>

I took a closer look, and indeed, the two parts of dev_read_addr behave
differently: dev_read_addr calls dev_read_addr_index, which calls either
ofnode_get_addr_index when live tree is active, or devfdt_get_addr_index when
it's not. devfdt_get_addr_index applies bus translations, but
ofnode_get_addr_index returns the untranslated address using of_read_number
(the else part doesn't run, since we have an active live tree if
ofnode_get_addr_index was called).

We could fix this by running of_translate_address on the value returned by
of_read_number, so that dev_get_addr would then always return a translated
address.

But what I think is strange is that most live tree conversion patches (e.g.
a9d3037 ("usb: dwc2: convert to livetree") or 4aac33f ("dm: mmc: fsl_esdhc:
Update to support livetree")) simply replaced devfdt_get_addr (which does apply
bus translations) with dev_read_addr (which does not apply bus translations in
the live tree case). Shouldn't the converted driver have failed in the live
tree case? Or were all drivers converted until now not depending on any bus
translations?

> In any case, we should not compound the problem if dev_read_addr() is wrong.
>
>>
>> Since the dev_read_addr function is widely used, we refrain from
>> modifying it, and instead read the raw address from the device tree, and
>> apply the bus translations using the recently introduced
>> dev_translate_address function.
>>
>> Signed-off-by: Mario Six 
>> ---
>>  drivers/serial/ns16550.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> REgards,
> Simon

Best regards,

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

Re: [U-Boot] [PATCH 031/080] serial: ns16550: Fix address translation

2017-10-09 Thread Dr. Philipp Tomsich


> On 9 Oct 2017, at 14:45, Mario Six  wrote:
> 
> (adding Philipp since he converted lots of drivers to livetree recently)
> 
> On Mon, Oct 9, 2017 at 6:48 AM, Simon Glass  wrote:
>> Hi Mario,
>> 
>> On 29 September 2017 at 06:51, Mario Six  wrote:
>>> The dev_read_addr function does not do any bus translations, and just
>>> returns the raw address read from the device tree, which makes the
>>> driver not work on systems that need bus translations to get the actual
>>> memory address of the device's register space.
>> 
>> Aside from any current functionality, what is the correct thing for
>> dev_read_addr() to do? I worry that the two parts (live/flat tree)
>> might do different things.
>> 
> 
> I took a closer look, and indeed, the two parts of dev_read_addr behave
> differently: dev_read_addr calls dev_read_addr_index, which calls either
> ofnode_get_addr_index when live tree is active, or devfdt_get_addr_index when
> it's not. devfdt_get_addr_index applies bus translations, but
> ofnode_get_addr_index returns the untranslated address using of_read_number
> (the else part doesn't run, since we have an active live tree if
> ofnode_get_addr_index was called).

Good point. I would expect the livetree case to use translated addresses
during runtime, as dev_read_addr_index calls either ofnode_get_addr_index
or devfdt_get_addr_index.

In other words: are we missing an address translation from ofnode_get_addr_index
or should the address retrieved via ofnode_get_addr_index have been
translated by earlier processing?

> 
> We could fix this by running of_translate_address on the value returned by
> of_read_number, so that dev_get_addr would then always return a translated
> address.
> 
> But what I think is strange is that most live tree conversion patches (e.g.
> a9d3037 ("usb: dwc2: convert to livetree") or 4aac33f ("dm: mmc: fsl_esdhc:
> Update to support livetree")) simply replaced devfdt_get_addr (which does 
> apply
> bus translations) with dev_read_addr (which does not apply bus translations in
> the live tree case). Shouldn't the converted driver have failed in the live
> tree case? Or were all drivers converted until now not depending on any bus
> translations?
> 
>> In any case, we should not compound the problem if dev_read_addr() is wrong.
>> 
>>> 
>>> Since the dev_read_addr function is widely used, we refrain from
>>> modifying it, and instead read the raw address from the device tree, and
>>> apply the bus translations using the recently introduced
>>> dev_translate_address function.
>>> 
>>> Signed-off-by: Mario Six 
>>> ---
>>> drivers/serial/ns16550.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>> 
>> REgards,
>> Simon
> 
> Best regards,
> 
> Mario

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

Re: [U-Boot] [PATCH v5 0/4] Allwinner SimpleFB Kconfig cleanup and DE2 SimpleFB support

2017-10-09 Thread icenowy


在 2017-09-21 00:18，Icenowy Zheng 写道：

This patchset is mainly for Allwinner DE2 HDMI SimpleFB support.

The framebuffer initialized by the Allwinner DE2 driver can be
passed by to the kernel as simplefb, and this can enable the
kernel to display graphics without having full DE2 driver.

Add the suppot of simplefb in DE2 code.

The code to find a simplefb with sunxi extension and a suitable
pipeline is extracted to a new source file in video/sunxi/.

An option is added for device tree simplefb, and furtherly other
simplefb support code should also be converted to it. The
current only user to the CONFIG_VIDEO_DT_SIMPLEFB, Allwinner
DE1 legacy video, has already converted to use the Kconfig
option in this patchset. A cleanup commit is introduced for
this conversion.

Icenowy Zheng (4):
  sunxi: change the DE1 video option to CONFIG_VIDEO_SUNXI
  video: sunxi: extract simplefb match code to a new file
  video: add an option for video simplefb via DT
  sunxi: setup simplefb for Allwinner DE2


Hello Anatolij,

Could you look at this patchset?

I used to think it as a sunxi-only patchset, so I sent it to the
sunxi maintainers. However, Maxime says that he needs feedback
from video maintainers.

Thanks!



 arch/arm/mach-sunxi/Kconfig   | 31 ---
 drivers/video/Kconfig |  8 
 drivers/video/sunxi/Makefile  |  4 +-
 drivers/video/sunxi/simplefb_common.c | 30 +++
 drivers/video/sunxi/simplefb_common.h | 22 +++
 drivers/video/sunxi/sunxi_de2.c   | 72 
+++

 drivers/video/sunxi/sunxi_display.c   | 13 +--
 include/configs/sunxi-common.h|  9 +
 scripts/config_whitelist.txt  |  1 -
 9 files changed, 155 insertions(+), 35 deletions(-)
 create mode 100644 drivers/video/sunxi/simplefb_common.c
 create mode 100644 drivers/video/sunxi/simplefb_common.h

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

Re: [U-Boot] Edison's U-Boot Architecture

2017-10-09 Thread Andy Shevchenko

On Mon, 2017-10-09 at 14:45 +0300, Andy Shevchenko wrote:
> On Mon, 2017-10-09 at 08:10 +0200, Zoran Stojsavljevic wrote:
> > 
> > Andy/Andrej,
> 
> Andy is okay :-)
> 
> > Question here: Did I get the correct idea how Edison works with U-
> > Boot? Could you, please, elaborate how this is done with Edison? 
> 
> See above
> 
> > (Vopros sdes6: Ja praviljno ugadal kak eto sdelano/rabotaet? Mozno
> > bolee dannih kad celaja eta arhitectura rabotaet so Edisonom?)
> 
> Ne ugadal :-) Smotri vyshe.

Btw, I'm going to attend ELC2017 Europe (in Prague), anyone who has
questions, comments, anything to discuss or just have a dinner, are
welcome!

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 031/080] serial: ns16550: Fix address translation

2017-10-09 Thread Simon Glass

Hi,

On 9 October 2017 at 06:55, Dr. Philipp Tomsich
 wrote:
>
>> On 9 Oct 2017, at 14:45, Mario Six  wrote:
>>
>> (adding Philipp since he converted lots of drivers to livetree recently)
>>
>> On Mon, Oct 9, 2017 at 6:48 AM, Simon Glass  wrote:
>>> Hi Mario,
>>>
>>> On 29 September 2017 at 06:51, Mario Six  wrote:
 The dev_read_addr function does not do any bus translations, and just
 returns the raw address read from the device tree, which makes the
 driver not work on systems that need bus translations to get the actual
 memory address of the device's register space.
>>>
>>> Aside from any current functionality, what is the correct thing for
>>> dev_read_addr() to do? I worry that the two parts (live/flat tree)
>>> might do different things.
>>>
>>
>> I took a closer look, and indeed, the two parts of dev_read_addr behave
>> differently: dev_read_addr calls dev_read_addr_index, which calls either
>> ofnode_get_addr_index when live tree is active, or devfdt_get_addr_index when
>> it's not. devfdt_get_addr_index applies bus translations, but
>> ofnode_get_addr_index returns the untranslated address using of_read_number
>> (the else part doesn't run, since we have an active live tree if
>> ofnode_get_addr_index was called).
>
> Good point. I would expect the livetree case to use translated addresses
> during runtime, as dev_read_addr_index calls either ofnode_get_addr_index
> or devfdt_get_addr_index.
>
> In other words: are we missing an address translation from 
> ofnode_get_addr_index
> or should the address retrieved via ofnode_get_addr_index have been
> translated by earlier processing?

Thank you both. Yes it seems like the right answer is to add the
missing translation in. There is a CONFIG_OF_TRANSLATE which enables
this. I think most boards don't use it, which is probably why there
are no problems without it, but I think it is becoming more common as
boards become more complex.

>
>>
>> We could fix this by running of_translate_address on the value returned by
>> of_read_number, so that dev_get_addr would then always return a translated
>> address.
>>
>> But what I think is strange is that most live tree conversion patches (e.g.
>> a9d3037 ("usb: dwc2: convert to livetree") or 4aac33f ("dm: mmc: fsl_esdhc:
>> Update to support livetree")) simply replaced devfdt_get_addr (which does 
>> apply
>> bus translations) with dev_read_addr (which does not apply bus translations 
>> in
>> the live tree case). Shouldn't the converted driver have failed in the live
>> tree case? Or were all drivers converted until now not depending on any bus
>> translations?
>>
>>> In any case, we should not compound the problem if dev_read_addr() is wrong.
>>>

 Since the dev_read_addr function is widely used, we refrain from
 modifying it, and instead read the raw address from the device tree, and
 apply the bus translations using the recently introduced
 dev_translate_address function.

 Signed-off-by: Mario Six 
 ---
 drivers/serial/ns16550.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> REgards,
>>> Simon
>>
>> Best regards,
>>
>> Mario
>

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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09 Thread Rob Clark

On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>> >> This fixes an issue with OpenBSD's bootloader, and I think should also
>> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
>> >> we were creating disk objects for the partitions, but not also the
>> >> parent device.
>> >>
>> >> Reported-by: Jonathan Gray 
>> >> Signed-off-by: Rob Clark 
>> >
>> > Thanks for looking into this.  While this lets armv7/bootarm.efi
>> > boot again on cubox-i and bbb it doesn't help rpi3.
>> >
>> > What is the easiest way to get U-Boot to display these paths
>> > to be able to compare the current behaviour to 2017.09?
>> >
>>
>> in grub, there is the lsefi command, not sure if the OpenBSD
>> bootloader has something similar?
>>
>> u-boot implements that device-path to text protocol, so it should be
>> pretty easy to implement something like this if not.
>>
>> BR,
>> -R
>
> With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> is no longer seen.  Is it possible having U-Boot on mmc but directing
> it to load off usb is somehow involved here?

There is no requirement that efi payload and u-boot are on the same
device.  The distro bootcmd stuff will just look for
/efi/boot/bootxyz.efi on all the devices/partitions until it finds
one.

The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
or legacy boards, in the former case we can construct something more
realistic.  Although the bootloader shouldn't really care.

> efi_bootdp obtained from the loaded image protocol
>
> 2017.09
>
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 76 ms (1013.7 KiB/s)
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 4
> depth=0
> i=0
> efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
> i=1
> efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> booting sd0a:/bsd: 3871708+578596+509352+803952 
> [283845+96+451968+239920]=0x82f330
>
> git + patch


I assume you are referring to this patch?  It should only add
additional per-partion "disk" objects.  (In UEFI terminology each
partition is a "disk" object.)

BR,
-R

> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 86 ms (896.5 KiB/s)
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 1
> efi_device_path_depth looking for type 4 i=1 type 3
> efi_device_path_depth looking for type 4 i=2 type 3
> efi_device_path_depth looking for type 4 i=3 type 3
> efi_device_path_depth no match for type 4
> depth=-1
> i=0
> i=1
> i=2
> i=3
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> cannot open sd0a:/etc/random.seed: Device not configured
> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

2017-10-09 Thread Goldschmidt Simon

Hi Clémént,

> Did you also test the saveenv and sf unlock ?

I did test saveenv and it works. I did not test sf protection.

> Did you get some strange behaviors after a "warm reboot" from linux ?

Indeed, warm reboot fails. When rebooting via "reboot" command from
linux, the last thing I see is SPL writing "Trying to boot from SPI".

I haven't been able to debug this further, yet.

Also, I still can't sf read without disabling the data cache :-(

Regards,
Simon

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

Re: [U-Boot] Broadwell-DE bare metal

2017-10-09 Thread Simon Glass

Hi,

On 3 October 2017 at 08:58, vnktux  wrote:
> Hi all,
>
> For my graduation project my company asked to use U-Boot as bare metal 
> boot-loader on one of their product. The product in an embedded board with a 
> Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist of 
> Coreboot + U-Boot, but of course they want to get rid of Coreboot. I have 
> almost no experience with U-Boot (Just with ARM processor a little bit) and 
> so far I don't even know if it's possible or not to achieve the final goal. 
> What I have understood is that I need the following binary blobs to work: 
> fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is it true? Can 
> somebody point me in the right direction because I am a little bit lost?  
> Plus I don't see many x86 boards implemented in the source code of U-Boot.

The original U-Boot payload support was done with Broadwell-DE (I'm
not sure which one though). It allows U-Boot to boot from EFI.

For what you want, yes you will need to obtain various binary blobs.
Hopefully you can get the FSP from Intel, and with that the work
required in U-Boot is probably not too large. Although I'm sure that
the FSP API will have changed a little.

Regards,
Simon

>
> Best regards,
> Vincenzo
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] mmc: stm32_sdmmc2: increase polling status register delay

2017-10-09 Thread patrice.chotard

From: Christophe Kerello 

MMC commands like MMC_CMD_ALL_SEND_CID or MMC_CMD_SEND_CSD can reach
500 us. This patch increases the polling status register delay to avoid
a timeout on a command.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---
 drivers/mmc/stm32_sdmmc2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
index 0e1f40b..fd49d42 100644
--- a/drivers/mmc/stm32_sdmmc2.c
+++ b/drivers/mmc/stm32_sdmmc2.c
@@ -276,7 +276,7 @@ static int stm32_sdmmc2_end_cmd(struct stm32_sdmmc2_priv 
*priv,
 
/* Polling status register */
ret = readl_poll_timeout(priv->base + SDMMC_STA, status, status & mask,
-300);
+1);
 
if (ret < 0) {
debug("%s: timeout reading SDMMC_STA register\n", __func__);
-- 
1.9.1

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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09 Thread Jonathan Gray

On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
> >> >> This fixes an issue with OpenBSD's bootloader, and I think should also
> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
> >> >> we were creating disk objects for the partitions, but not also the
> >> >> parent device.
> >> >>
> >> >> Reported-by: Jonathan Gray 
> >> >> Signed-off-by: Rob Clark 
> >> >
> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
> >> > boot again on cubox-i and bbb it doesn't help rpi3.
> >> >
> >> > What is the easiest way to get U-Boot to display these paths
> >> > to be able to compare the current behaviour to 2017.09?
> >> >
> >>
> >> in grub, there is the lsefi command, not sure if the OpenBSD
> >> bootloader has something similar?
> >>
> >> u-boot implements that device-path to text protocol, so it should be
> >> pretty easy to implement something like this if not.
> >>
> >> BR,
> >> -R
> >
> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> > is no longer seen.  Is it possible having U-Boot on mmc but directing
> > it to load off usb is somehow involved here?
> 
> There is no requirement that efi payload and u-boot are on the same
> device.  The distro bootcmd stuff will just look for
> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
> one.
> 
> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
> or legacy boards, in the former case we can construct something more
> realistic.  Although the bootloader shouldn't really care.

I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
in master only gives types of 1 (Hardware Device Path) and
3 (Messaging Device Path).

It is DM in this case:

U-Boot> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 simple_bus [ + ]   generic_si  |-- soc
 gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
 serial [ + ]   serial_bcm  |   |-- serial@7e215040
 mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
 blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
 video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
 vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
 usb[ + ]   dwc2_usb|   `-- usb@7e98
 usb_hub[ + ]   usb_hub |   `-- usb_hub
 usb_hub[ + ]   usb_hub |   `-- usb_hub
 eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
 usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
 blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
 simple_bus [   ]   generic_si  `-- clocks

> 
> > efi_bootdp obtained from the loaded image protocol
> >
> > 2017.09
> >
> > Scanning usb 0:1...
> > Found EFI removable media binary efi/boot/bootaa64.efi
> > reading efi/boot/bootaa64.efi
> > 78959 bytes read in 76 ms (1013.7 KiB/s)
> > ## Starting EFI application at 0100 ...
> > Scanning disk sd...@7e30.blk...
> > Scanning disk usb_mass_storage.lun0...
> > Found 2 disks
> > efi_diskprobe
> > efi_device_path_depth looking for type 4 i=0 type 4
> > depth=0
> > i=0
> > efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
> > i=1
> > efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
> >>> OpenBSD/arm64 BOOTAA64 0.8
> > boot>
> > booting sd0a:/bsd: 3871708+578596+509352+803952 
> > [283845+96+451968+239920]=0x82f330
> >
> > git + patch
> 
> 
> I assume you are referring to this patch?  It should only add
> additional per-partion "disk" objects.  (In UEFI terminology each
> partition is a "disk" object.)

Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
The problem seems to be elsewhere as dropping that I still see:

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
Scanning disk usb_mass_storage.lun0...
Found 2 disks
efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 1
efi_device_path_depth looking for type 4 i=1 type 3
efi_device_path_depth looking for type 4 i=2 type 3
efi_device_path_depth looking for type 4 i=3 type 3
efi_device_path_depth no match for type 4
depth=-1
i=0
i=1
i=2
i=3
>> OpenBSD/arm64 BOOTAA64 0.8
boot> 
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
 failed(6). will try /bsd

od1000 (edk2) booting off sata:

INFO:PSCI Power Domain Map:
INFO:  Domain Node : Level 1, parent_node -1, State ON (0x0)
INFO:  Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO:  Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO:  Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO:  CPU Node : MPID

Re: [U-Boot] [PATCH] Powerpc: Make pcie link state judge more specific

2017-10-09 Thread York Sun

On 09/24/2017 08:44 PM, Bao Xiaowei wrote:
> For some special reset times for longer pcie devices, in this case, the
> pcie device may on polling compliance state, the RC considers the pcie
> device is link up, but the pcie device is not link up, only the L0 state
> is link up state. So add the link up status judgement mechanisms.
> 
> Signed-off-by: Bao Xiaowei 
> ---
> v2:
>  - Detailed function module
>  - Adjust the code structure
> 

Xiaowei,

Can you revise the commit message? I don't quite understand it. It is
similar but not the same as the change you made for Layerscape, isn't it?

While you respin this patch, please consider my comments earlier.

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

Re: [U-Boot] [PATCH] armv8: configs: ls1012a: correct the generic timer frequency issue

2017-10-09 Thread York Sun

On 10/08/2017 11:48 PM, andy.t...@nxp.com wrote:
> From: Yuantian Tang 
> 
> Generic Timer frequency should be 25Mhz. Current setting is
> CONFIG_SYS_CLK_FREQ/4 which is about 31Mhz, which is not correct.
> So correct it.
> 
> Signed-off-by: Tang Yuantian 
> ---
>  include/configs/ls1012a_common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/ls1012a_common.h 
> b/include/configs/ls1012a_common.h
> index 096799eb64..a4e78f335f 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -32,7 +32,7 @@
>  #define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL
>  
>  /* Generic Timer Definitions */
> -#define COUNTER_FREQUENCYCONFIG_SYS_CLK_FREQ/4   /* 25MHz */
> +#define COUNTER_FREQUENCY2500/* 25MHz */
>  


Yuantian,

LS1012A use fixed 25MHz clock, doesn't it? If so, that's the reason a
fixed value should be used, not because CONFIG_SYS_CLK_FREQ/4 isn't
correct. It is correct for many other platform. Please update the commit
message.

York


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

Re: [U-Boot] U-Boot sunxi pinctrl

2017-10-09 Thread Dr. Philipp Tomsich

Joonas,

> On 9 Oct 2017, at 17:49, Joonas Kylmälä  wrote:
> 
> I see you have been working on pinctrl for sunxi in U-Boot:
> .
> But I have no idea how old the patches you have send are so I thought to
> ask whether you are still working on this?

These were a complete patch-set against master on the day the patches
were submitted (i.e. please check the mailing-list archive for the details).
Our internal GIT has these changes on 2017.03-rc3 (i.e. not that old) and
I don’t see a reason why these changes should not easily integrate into
today’s code base.

Our in-house U-Boot for our Allwinner boards is frozen, so there’s no active
development on those branches at the moment.  As of now, my team and I
are focussed on our Rockchip boards (I am one of the u-boot-rockchip
custodians days)…

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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09 Thread Rob Clark

On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
>> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>> >> >> This fixes an issue with OpenBSD's bootloader, and I think should also
>> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
>> >> >> we were creating disk objects for the partitions, but not also the
>> >> >> parent device.
>> >> >>
>> >> >> Reported-by: Jonathan Gray 
>> >> >> Signed-off-by: Rob Clark 
>> >> >
>> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
>> >> > boot again on cubox-i and bbb it doesn't help rpi3.
>> >> >
>> >> > What is the easiest way to get U-Boot to display these paths
>> >> > to be able to compare the current behaviour to 2017.09?
>> >> >
>> >>
>> >> in grub, there is the lsefi command, not sure if the OpenBSD
>> >> bootloader has something similar?
>> >>
>> >> u-boot implements that device-path to text protocol, so it should be
>> >> pretty easy to implement something like this if not.
>> >>
>> >> BR,
>> >> -R
>> >
>> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
>> > is no longer seen.  Is it possible having U-Boot on mmc but directing
>> > it to load off usb is somehow involved here?
>>
>> There is no requirement that efi payload and u-boot are on the same
>> device.  The distro bootcmd stuff will just look for
>> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
>> one.
>>
>> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
>> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
>> or legacy boards, in the former case we can construct something more
>> realistic.  Although the bootloader shouldn't really care.
>
> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> in master only gives types of 1 (Hardware Device Path) and
> 3 (Messaging Device Path).
>
> It is DM in this case:

Possibly something weird with your partition table?  In
efi_disk_register() it should create objects for the disk itself
(part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
partition (part>=1, which would have same dp as the disk but
additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).

If part_get_info() fails for part==1 then you won't get any of the
partition devices.  I suppose this could happen if you an unknown
partition table type, or u-boot is not built w/ the correct partition
driver.

BR,
-R


> U-Boot> dm tree
>  Class  Probed  Driver  Name
> 
>  root   [ + ]   root_drive  root_driver
>  simple_bus [ + ]   generic_si  |-- soc
>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>  blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
>  simple_bus [   ]   generic_si  `-- clocks
>
>>
>> > efi_bootdp obtained from the loaded image protocol
>> >
>> > 2017.09
>> >
>> > Scanning usb 0:1...
>> > Found EFI removable media binary efi/boot/bootaa64.efi
>> > reading efi/boot/bootaa64.efi
>> > 78959 bytes read in 76 ms (1013.7 KiB/s)
>> > ## Starting EFI application at 0100 ...
>> > Scanning disk sd...@7e30.blk...
>> > Scanning disk usb_mass_storage.lun0...
>> > Found 2 disks
>> > efi_diskprobe
>> > efi_device_path_depth looking for type 4 i=0 type 4
>> > depth=0
>> > i=0
>> > efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
>> > i=1
>> > efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>> >>> OpenBSD/arm64 BOOTAA64 0.8
>> > boot>
>> > booting sd0a:/bsd: 3871708+578596+509352+803952 
>> > [283845+96+451968+239920]=0x82f330
>> >
>> > git + patch
>>
>>
>> I assume you are referring to this patch?  It should only add
>> additional per-partion "disk" objects.  (In UEFI terminology each
>> partition is a "disk" object.)
>
> Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
> The problem seems to be elsewhere as dropping that I still see:
>
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 1
> efi_device_path_depth looking fo

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09 Thread Heinrich Schuchardt

On 10/09/2017 06:06 PM, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
 On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>> On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>>> This fixes an issue with OpenBSD's bootloader, and I think should also
>>> fix a similar issue with grub2 on legacy devices.  In the legacy case
>>> we were creating disk objects for the partitions, but not also the
>>> parent device.
>>>
>>> Reported-by: Jonathan Gray 
>>> Signed-off-by: Rob Clark 
>>
>> Thanks for looking into this.  While this lets armv7/bootarm.efi
>> boot again on cubox-i and bbb it doesn't help rpi3.
>>
>> What is the easiest way to get U-Boot to display these paths
>> to be able to compare the current behaviour to 2017.09?
>>
>
> in grub, there is the lsefi command, not sure if the OpenBSD
> bootloader has something similar?
>
> u-boot implements that device-path to text protocol, so it should be
> pretty easy to implement something like this if not.
>
> BR,
> -R

 With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
 is no longer seen.  Is it possible having U-Boot on mmc but directing
 it to load off usb is somehow involved here?
>>>
>>> There is no requirement that efi payload and u-boot are on the same
>>> device.  The distro bootcmd stuff will just look for
>>> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
>>> one.
>>>
>>> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
>>> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
>>> or legacy boards, in the former case we can construct something more
>>> realistic.  Although the bootloader shouldn't really care.
>>
>> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>> in master only gives types of 1 (Hardware Device Path) and
>> 3 (Messaging Device Path).
>>
>> It is DM in this case:
> 
> Possibly something weird with your partition table?  In
> efi_disk_register() it should create objects for the disk itself
> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> partition (part>=1, which would have same dp as the disk but
> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> 
> If part_get_info() fails for part==1 then you won't get any of the
> partition devices.  I suppose this could happen if you an unknown
> partition table type, or u-boot is not built w/ the correct partition
> driver.
> 
> BR,
> -R
> 
> 
>> U-Boot> dm tree
>>  Class  Probed  Driver  Name
>> 
>>  root   [ + ]   root_drive  root_driver
>>  simple_bus [ + ]   generic_si  |-- soc
>>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>>  blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
>>  simple_bus [   ]   generic_si  `-- clocks
>>
>>>
 efi_bootdp obtained from the loaded image protocol

 2017.09

 Scanning usb 0:1...
 Found EFI removable media binary efi/boot/bootaa64.efi
 reading efi/boot/bootaa64.efi
 78959 bytes read in 76 ms (1013.7 KiB/s)
 ## Starting EFI application at 0100 ...
 Scanning disk sd...@7e30.blk...
 Scanning disk usb_mass_storage.lun0...
 Found 2 disks
 efi_diskprobe
 efi_device_path_depth looking for type 4 i=0 type 4
 depth=0
 i=0
 efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
 i=1
 efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>> OpenBSD/arm64 BOOTAA64 0.8
 boot>
 booting sd0a:/bsd: 3871708+578596+509352+803952 
 [283845+96+451968+239920]=0x82f330

 git + patch
>>>
>>>
>>> I assume you are referring to this patch?  It should only add
>>> additional per-partion "disk" objects.  (In UEFI terminology each
>>> partition is a "disk" object.)
>>
>> Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
>> The problem seems to be elsewhere as dropping that I still see:
>>
>> ## Starting EFI application at 0100 ...
>> Scanning disk sd...@7e30.blk...
>> Scanning disk usb_mass_storage.lun0...
>> Found 2

Re: [U-Boot] Broadwell-DE bare metal

2017-10-09 Thread Zoran Stojsavljevic

 > It allows U-Boot to boot from EFI.

This is a true art of overkill... Really.

Full EFI (around 1 to 2 million lines of code: SEC, PEI, DXE phases, with
ME HECI involved, altogether) -> U-Boot -> YOCTO. Wow. ;-)

Zoran

On Mon, Oct 9, 2017 at 4:43 PM, Simon Glass  wrote:

> Hi,
>
> On 3 October 2017 at 08:58, vnktux  wrote:
> > Hi all,
> >
> > For my graduation project my company asked to use U-Boot as bare metal
> boot-loader on one of their product. The product in an embedded board with
> a Xeon Broadwell-DE D-1527 Quad Core. The current boot-loader consist of
> Coreboot + U-Boot, but of course they want to get rid of Coreboot. I have
> almost no experience with U-Boot (Just with ARM processor a little bit) and
> so far I don't even know if it's possible or not to achieve the final goal.
> What I have understood is that I need the following binary blobs to work:
> fsp.bin, vga.bin, descriptor.bin, me.bin, microcode.bin. Is it true? Can
> somebody point me in the right direction because I am a little bit lost?
> Plus I don't see many x86 boards implemented in the source code of U-Boot.
>
> The original U-Boot payload support was done with Broadwell-DE (I'm
> not sure which one though). It allows U-Boot to boot from EFI.
>
> For what you want, yes you will need to obtain various binary blobs.
> Hopefully you can get the FSP from Intel, and with that the work
> required in U-Boot is probably not too large. Although I'm sure that
> the FSP API will have changed a little.
>
> Regards,
> Simon
>
> >
> > Best regards,
> > Vincenzo
> >
> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09 Thread Jonathan Gray

On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think should 
> >> >> >> also
> >> >> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
> >> >> >> we were creating disk objects for the partitions, but not also the
> >> >> >> parent device.
> >> >> >>
> >> >> >> Reported-by: Jonathan Gray 
> >> >> >> Signed-off-by: Rob Clark 
> >> >> >
> >> >> > Thanks for looking into this.  While this lets armv7/bootarm.efi
> >> >> > boot again on cubox-i and bbb it doesn't help rpi3.
> >> >> >
> >> >> > What is the easiest way to get U-Boot to display these paths
> >> >> > to be able to compare the current behaviour to 2017.09?
> >> >> >
> >> >>
> >> >> in grub, there is the lsefi command, not sure if the OpenBSD
> >> >> bootloader has something similar?
> >> >>
> >> >> u-boot implements that device-path to text protocol, so it should be
> >> >> pretty easy to implement something like this if not.
> >> >>
> >> >> BR,
> >> >> -R
> >> >
> >> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> >> > is no longer seen.  Is it possible having U-Boot on mmc but directing
> >> > it to load off usb is somehow involved here?
> >>
> >> There is no requirement that efi payload and u-boot are on the same
> >> device.  The distro bootcmd stuff will just look for
> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds
> >> one.
> >>
> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
> >> or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
> >> or legacy boards, in the former case we can construct something more
> >> realistic.  Although the bootloader shouldn't really care.
> >
> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> > in master only gives types of 1 (Hardware Device Path) and
> > 3 (Messaging Device Path).
> >
> > It is DM in this case:
> 
> Possibly something weird with your partition table?  In
> efi_disk_register() it should create objects for the disk itself
> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> partition (part>=1, which would have same dp as the disk but
> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> 
> If part_get_info() fails for part==1 then you won't get any of the
> partition devices.  I suppose this could happen if you an unknown
> partition table type, or u-boot is not built w/ the correct partition
> driver.
> 
> BR,
> -R

It is partitioned mbr style.

U-Boot> part list mmc 0

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 81928192-01 0c Boot
  4 16384   26624   -04 a6
U-Boot> part list usb 0

Partition Map for USB device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 819232768   -01 0c Boot
  4 40960   60021540-04 a6

I changed the part_get_info() debug messages to normal printfs and no
error paths trigger:

U-Boot 2017.11-rc1-00111-g97b86e3342-dirty (Oct 10 2017 - 03:28:40 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e30: 0
## Valid DOS partition found ##
reading uboot.env
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
Type: Removable Hard Disk
Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning usb 0:1...
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Found EFI removable media binary efi/boot/bootaa64.efi
## Valid DOS partition found ##
## Valid DOS partition found ##
reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DO

[U-Boot] [PATCH] ARM: Add documentation for the qemu-arm board

2017-10-09 Thread Tuomas Tynkkynen

Add brief documentation for the recently merged qemu-arm board.

Signed-off-by: Tuomas Tynkkynen 
---
 doc/README.qemu-arm | 54 +
 1 file changed, 54 insertions(+)
 create mode 100644 doc/README.qemu-arm

diff --git a/doc/README.qemu-arm b/doc/README.qemu-arm
new file mode 100644
index 00..2895e3b97f
--- /dev/null
+++ b/doc/README.qemu-arm
@@ -0,0 +1,54 @@
+#
+# Copyright (C) 2017, Tuomas Tynkkynen 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+U-Boot on QEMU's 'virt' machine on ARM
+==
+
+QEMU for ARM supports a special 'virt' machine designed for emulation and
+virtualization purposes. This document describes how to run U-Boot under it.
+
+The 'virt' platform provides the following as the basic functionality:
+
+- A freely configurable amount of CPU cores
+- U-Boot loaded and executing in the emulated flash at address 0x0
+- A generated device tree blob placed at the start of RAM
+- A freely configurable amount of RAM, described by the DTB
+- A PL011 serial port, discoverable via the DTB
+- An ARMv7 architected timer
+- PSCI for rebooting the system
+- A generic ECAM-based PCI host controller, discoverable via the DTB
+
+Additionally, a number of optional peripherals can be added to the PCI bus.
+
+Building U-Boot
+---
+Set the CROSS_COMPILE and ARCH=arm environment variables as usual, and run:
+
+make qemu_arm_defconfig
+make
+
+Running U-Boot
+--
+The minimal QEMU command line to get U-Boot up and running is:
+
+qemu-system-arm -machine virt,highmem=off -bios u-boot.bin
+
+The 'highmem=off' parameter to the 'virt' machine is required for PCI to work
+in U-Boot.
+
+Additional peripherals that have been tested to work in both U-Boot and Linux
+can be enabled with the following command line parameters:
+
+- To add a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.:
+-drive if=none,file=disk.img,id=mydisk -device ich9-ahci,id=ahci -device 
ide-drive,drive=mydisk,bus=ahci.0
+- To add an Intel E1000 network adapter, pass e.g.:
+-netdev user,id=net0 -device e1000,netdev=net0
+- To add an EHCI-compliant USB host controller, pass e.g.:
+-device usb-ehci,id=ehci
+- To add a NVMe disk, pass e.g.:
+-drive if=none,file=disk.img,id=mydisk -device nvme,drive=mydisk,serial=foo
+
+These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well.
-- 
2.14.2

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

Re: [U-Boot] [PATCH 1/2] dm: clk: remove CLK() macro for clk_stm32h7

2017-10-09 Thread Vikas MANOCHA

Hi,

> -Original Message-
> From: Patrice CHOTARD
> Sent: Monday, October 09, 2017 2:41 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; s...@chromium.org; Vikas 
> MANOCHA 
> Cc: Patrice CHOTARD ; Patrick DELAUNAY 
> ; Christophe KERELLO
> 
> Subject: [PATCH 1/2] dm: clk: remove CLK() macro for clk_stm32h7
> 
> From: Patrice Chotard 
> 
> CLK() macro is a residue of a previously reworked patch, remove it.
> 
> Signed-off-by: Patrice Chotard 

Reviewed-by: Vikas Manocha 

Cheers,
Vikas

> ---
>  drivers/clk/clk_stm32h7.c | 223 
> ++
>  1 file changed, 108 insertions(+), 115 deletions(-)
> 
> diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c index 
> fd0e3ab..9ca497a 100644
> --- a/drivers/clk/clk_stm32h7.c
> +++ b/drivers/clk/clk_stm32h7.c
> @@ -195,13 +195,6 @@ struct clk_cfg {
>   const char *name;
>  };
> 
> -#define CLK(_gate_offset, _bit_idx, _name) \ -{ \
> - .gate_offset = _gate_offset,\
> - .gate_bit_idx = _bit_idx,\
> - .name = _name,\
> -}
> -
>  /*
>   * the way all these entries are sorted in this array could seem
>   * unlogical, but we are dependant of kernel DT_bindings, @@ -210,114 
> +203,114 @@ struct clk_cfg {
>   */
> 
>  static const struct clk_cfg clk_map[] = {
> - CLK(RCC_AHB3ENR,  31, "d1sram1"),   /* peripheral clocks */
> - CLK(RCC_AHB3ENR,  30, "itcm"),
> - CLK(RCC_AHB3ENR,  29, "dtcm2"),
> - CLK(RCC_AHB3ENR,  28, "dtcm1"),
> - CLK(RCC_AHB3ENR,   8, "flitf"),
> - CLK(RCC_AHB3ENR,   5, "jpgdec"),
> - CLK(RCC_AHB3ENR,   4, "dma2d"),
> - CLK(RCC_AHB3ENR,   0, "mdma"),
> - CLK(RCC_AHB1ENR,  28, "usb2ulpi"),
> - CLK(RCC_AHB1ENR,  17, "eth1rx"),
> - CLK(RCC_AHB1ENR,  16, "eth1tx"),
> - CLK(RCC_AHB1ENR,  15, "eth1mac"),
> - CLK(RCC_AHB1ENR,  14, "art"),
> - CLK(RCC_AHB1ENR,  26, "usb1ulpi"),
> - CLK(RCC_AHB1ENR,   1, "dma2"),
> - CLK(RCC_AHB1ENR,   0, "dma1"),
> - CLK(RCC_AHB2ENR,  31, "d2sram3"),
> - CLK(RCC_AHB2ENR,  30, "d2sram2"),
> - CLK(RCC_AHB2ENR,  29, "d2sram1"),
> - CLK(RCC_AHB2ENR,   5, "hash"),
> - CLK(RCC_AHB2ENR,   4, "crypt"),
> - CLK(RCC_AHB2ENR,   0, "camitf"),
> - CLK(RCC_AHB4ENR,  28, "bkpram"),
> - CLK(RCC_AHB4ENR,  25, "hsem"),
> - CLK(RCC_AHB4ENR,  21, "bdma"),
> - CLK(RCC_AHB4ENR,  19, "crc"),
> - CLK(RCC_AHB4ENR,  10, "gpiok"),
> - CLK(RCC_AHB4ENR,   9, "gpioj"),
> - CLK(RCC_AHB4ENR,   8, "gpioi"),
> - CLK(RCC_AHB4ENR,   7, "gpioh"),
> - CLK(RCC_AHB4ENR,   6, "gpiog"),
> - CLK(RCC_AHB4ENR,   5, "gpiof"),
> - CLK(RCC_AHB4ENR,   4, "gpioe"),
> - CLK(RCC_AHB4ENR,   3, "gpiod"),
> - CLK(RCC_AHB4ENR,   2, "gpioc"),
> - CLK(RCC_AHB4ENR,   1, "gpiob"),
> - CLK(RCC_AHB4ENR,   0, "gpioa"),
> - CLK(RCC_APB3ENR,   6, "wwdg1"),
> - CLK(RCC_APB1LENR, 29, "dac12"),
> - CLK(RCC_APB1LENR, 11, "wwdg2"),
> - CLK(RCC_APB1LENR,  8, "tim14"),
> - CLK(RCC_APB1LENR,  7, "tim13"),
> - CLK(RCC_APB1LENR,  6, "tim12"),
> - CLK(RCC_APB1LENR,  5, "tim7"),
> - CLK(RCC_APB1LENR,  4, "tim6"),
> - CLK(RCC_APB1LENR,  3, "tim5"),
> - CLK(RCC_APB1LENR,  2, "tim4"),
> - CLK(RCC_APB1LENR,  1, "tim3"),
> - CLK(RCC_APB1LENR,  0, "tim2"),
> - CLK(RCC_APB1HENR,  5, "mdios"),
> - CLK(RCC_APB1HENR,  4, "opamp"),
> - CLK(RCC_APB1HENR,  1, "crs"),
> - CLK(RCC_APB2ENR,  18, "tim17"),
> - CLK(RCC_APB2ENR,  17, "tim16"),
> - CLK(RCC_APB2ENR,  16, "tim15"),
> - CLK(RCC_APB2ENR,   1, "tim8"),
> - CLK(RCC_APB2ENR,   0, "tim1"),
> - CLK(RCC_APB4ENR,  26, "tmpsens"),
> - CLK(RCC_APB4ENR,  16, "rtcapb"),
> - CLK(RCC_APB4ENR,  15, "vref"),
> - CLK(RCC_APB4ENR,  14, "comp12"),
> - CLK(RCC_APB4ENR,   1, "syscfg"),
> - CLK(RCC_AHB3ENR,  16, "sdmmc1"),/* kernel clocks */
> - CLK(RCC_AHB3ENR,  14, "quadspi"),
> - CLK(RCC_AHB3ENR,  12, "fmc"),
> - CLK(RCC_AHB1ENR,  27, "usb2otg"),
> - CLK(RCC_AHB1ENR,  25, "usb1otg"),
> - CLK(RCC_AHB1ENR,   5, "adc12"),
> - CLK(RCC_AHB2ENR,   9, "sdmmc2"),
> - CLK(RCC_AHB2ENR,   6, "rng"),
> - CLK(RCC_AHB4ENR,  24, "adc3"),
> - CLK(RCC_APB3ENR,   4, "dsi"),
> - CLK(RCC_APB3ENR,   3, "ltdc"),
> - CLK(RCC_APB1LENR, 31, "usart8"),
> - CLK(RCC_APB1LENR, 30, "usart7"),
> - CLK(RCC_APB1LENR, 27, "hdmicec"),
> - CLK(RCC_APB1LENR, 23, "i2c3"),
> - CLK(RCC_APB1LENR, 22, "i2c2"),
> - CLK(RCC_APB1LENR, 21, "i2c1"),
> - CLK(RCC_APB1LENR, 20, "uart5"),
> - CLK(RCC_APB1LENR, 19, "uart4"),
> - CLK(RCC_APB1LENR, 18, "usart3"),
> - CLK(RCC_APB1LENR, 17, "usart2"),
> - CLK(RCC_APB1LENR, 16, "spdifrx"),
> - CLK(RCC_APB1LENR, 15, "spi3"),
> - CLK(RCC_APB1LENR, 14, "spi2"),
> - CLK(RCC_APB1LENR,  9, "lptim1"),
> - CLK(RCC_APB1HENR,  8, "fdcan"),
> - CLK(RCC_APB1HENR,  2, "swp"),
> - CLK(RCC_APB2ENR,  29, "hrtim"),
> - CLK(RCC_APB2ENR,  28, "dfsdm1"),

Re: [U-Boot] [PATCH 2/2] dm: clk: fix PWR_CR3 register's bit 2 name

2017-10-09 Thread Vikas MANOCHA

Hi,

> -Original Message-
> From: Patrice CHOTARD
> Sent: Monday, October 09, 2017 2:41 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; s...@chromium.org; Vikas 
> MANOCHA 
> Cc: Patrice CHOTARD ; Patrick DELAUNAY 
> ; Christophe KERELLO
> 
> Subject: [PATCH 2/2] dm: clk: fix PWR_CR3 register's bit 2 name
> 
> From: Patrice Chotard 
> 
> Fix bit 2 name of PWR_CR3 register to match with the last STM32H7 reference 
> manual available here :
> 
> http://www.st.com/content/st_com/en/support/resources/
> resource-selector.html?querycriteria=productId=SS1951$$
> resourceCategory=technical_literature$$resourceType=reference_manual
> 
> Update also comment about voltage scaling 1 values
> 
> Signed-off-by: Patrice Chotard 

Reviewed-by: Vikas Manocha 

Cheers,
Vikas

> ---
>  drivers/clk/clk_stm32h7.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/clk_stm32h7.c b/drivers/clk/clk_stm32h7.c index 
> 9ca497a..ffa902d 100644
> --- a/drivers/clk/clk_stm32h7.c
> +++ b/drivers/clk/clk_stm32h7.c
> @@ -109,7 +109,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define  QSPISRC_PER_CK  3
> 
>  #define PWR_CR3  0x0c
> -#define PWR_CR3_SDEN BIT(2)
> +#define PWR_CR3_SCUENBIT(2)
>  #define PWR_D3CR 0x18
>  #define PWR_D3CR_VOS_MASKGENMASK(15, 14)
>  #define PWR_D3CR_VOS_SHIFT   14
> @@ -361,11 +361,11 @@ int configure_clocks(struct udevice *dev)
>   writel(0x0, ®s->d2ccip1r);
>   writel(0x0, ®s->d2ccip2r);
> 
> - /* Set voltage scaling at scale 1 */
> + /* Set voltage scaling at scale 1 (1,15 - 1,26 Volts) */
>   clrsetbits_le32(pwr_base + PWR_D3CR, PWR_D3CR_VOS_MASK,
>   VOS_SCALE_1 << PWR_D3CR_VOS_SHIFT);
> - /* disable step down converter */
> - clrbits_le32(pwr_base + PWR_CR3, PWR_CR3_SDEN);
> + /* Lock supply configuration update */
> + clrbits_le32(pwr_base + PWR_CR3, PWR_CR3_SCUEN);
>   while (!(readl(pwr_base + PWR_D3CR) & PWR_D3CR_VOSREADY))
>   ;
> 
> --
> 1.9.1

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

Re: [U-Boot] [U-Boot, 1/1] ARMv8: get new GD address from gd->new_gd directly

2017-10-09 Thread Tom Rini

On Fri, Sep 22, 2017 at 02:39:13PM +0800, zijun_hu wrote:

> From: zijun_hu 
> 
> the new GD address is calculated via board data BD currently
> it require the new GD area locates below BD tightly, so a strict
> constraint is imposed on memory layout which maybe make special
> platform unpleasant.
> 
> fix it by getting new GD address from gd->new_gd directly.
> 
> Signed-off-by: zijun_hu 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,1/1] ARMv8: fix error in freeing stack frame

2017-10-09 Thread Tom Rini

On Sat, Sep 23, 2017 at 01:30:58PM +0800, zijun_hu wrote:

> From: zijun_hu 
> 
> relocate_code() allocates 32 bytes stack frame but only 16 bytes are
> freed before return. it will cause errors to possible previous frames
> and doesn't make relocate_code() look like a function.
> 
> fix by freeing 32 bytes stack space
> 
> Signed-off-by: zijun_hu 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v3, 1/3] board: STiH410-B2260: update environment variable

2017-10-09 Thread Tom Rini

On Mon, Sep 25, 2017 at 09:14:18AM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Update environment variable by updating:
>  _ BOOT_TARGET_DEVICE
>  _ CONFIGS_BOOTARGS
>  _ kernel_addr_r, fdtfile, fdt_addr_r, scriptaddr, fdt_high, intird_high
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

2017-10-09 Thread Eugeniy Paltsev

Hi,

Maybe you have any comments or remarks about this patch? And if you don't could 
you please apply it. 

Thanks!

On Tue, 2017-09-26 at 16:10 +0300, Eugeniy Paltsev wrote:
> Add option to set spi controller clock frequency via device tree
> using standard clock bindings.
> Old way of setting spi controller clock frequency (via implementation
> of 'cm_get_spi_controller_clk_hz' function in platform specific code)
> remains supported.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  Resending due to previously sent one was discarded by mailing list.
> 
>  drivers/spi/designware_spi.c | 68 
> +++-
>  1 file changed, 67 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> index 5aa507b..c70697e 100644
> --- a/drivers/spi/designware_spi.c
> +++ b/drivers/spi/designware_spi.c
> @@ -11,6 +11,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -94,6 +95,7 @@ struct dw_spi_priv {
>   void __iomem *regs;
>   unsigned int freq;  /* Default frequency */
>   unsigned int mode;
> + unsigned long bus_clk_rate;
>  
>   int bits_per_word;
>   u8 cs;  /* chip select pin */
> @@ -176,14 +178,78 @@ static void spi_hw_init(struct dw_spi_priv *priv)
>   debug("%s: fifo_len=%d\n", __func__, priv->fifo_len);
>  }
>  
> +/*
> + * cm_get_spi_controller_clk_hz function is old way to set spi controller
> + * frequency. If it isn't implemented and spi controller frequency isn't set 
> via
> + * device tree we will get into next default function.
> + */
> +__weak unsigned int cm_get_spi_controller_clk_hz(void)
> +{
> + error("SPI clock is defined neither via device tree nor via 
> cm_get_spi_controller_clk_hz!");
> +
> + return 0;
> +}
> +
> +static int dw_spi_of_get_clk(struct udevice *bus)
> +{
> +#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK)
> + struct dw_spi_priv *priv = dev_get_priv(bus);
> + unsigned long clk_rate;
> + struct clk clk;
> + int ret;
> +
> + ret = clk_get_by_index(bus, 0, &clk);
> + if (ret)
> + return -EINVAL;
> +
> + ret = clk_enable(&clk);
> + if (ret && ret != -ENOSYS)
> + return ret;
> +
> + clk_rate = clk_get_rate(&clk);
> + if (!clk_rate)
> + return -EINVAL;
> +
> + priv->bus_clk_rate = clk_rate;
> +
> + clk_free(&clk);
> +
> + return 0;
> +#endif
> +
> + return -ENOSYS;
> +}
> +
> +static int dw_spi_get_clk(struct udevice *bus)
> +{
> + struct dw_spi_priv *priv = dev_get_priv(bus);
> +
> + /* Firstly try to get clock frequency from device tree */
> + if (!dw_spi_of_get_clk(bus))
> + return 0;
> +
> + /* In case of failure rollback to cm_get_spi_controller_clk_hz */
> + priv->bus_clk_rate = cm_get_spi_controller_clk_hz();
> +
> + if (!priv->bus_clk_rate)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
>  static int dw_spi_probe(struct udevice *bus)
>  {
>   struct dw_spi_platdata *plat = dev_get_platdata(bus);
>   struct dw_spi_priv *priv = dev_get_priv(bus);
> + int ret;
>  
>   priv->regs = plat->regs;
>   priv->freq = plat->frequency;
>  
> + ret = dw_spi_get_clk(bus);
> + if (ret)
> + return ret;
> +
>   /* Currently only bits_per_word == 8 supported */
>   priv->bits_per_word = 8;
>  
> @@ -369,7 +435,7 @@ static int dw_spi_set_speed(struct udevice *bus, uint 
> speed)
>   spi_enable_chip(priv, 0);
>  
>   /* clk_div doesn't support odd number */
> - clk_div = cm_get_spi_controller_clk_hz() / speed;
> + clk_div = priv->bus_clk_rate / speed;
>   clk_div = (clk_div + 1) & 0xfffe;
>   dw_writel(priv, DW_SPI_BAUDR, clk_div);
>  
-- 
 Eugeniy Paltsev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v1,5/6] serial: stm32x7: add STM32F4 support

2017-10-09 Thread Tom Rini

On Wed, Sep 27, 2017 at 03:44:52PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> stm32f4 doesn't support FIFO and OVERRUN feature.
> The enable bit is not at the same location in CR1
> register than for STM32F7 and STM32H7.
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v3, 3/3] board: STiH410-B2260: set ramdisk_addr_r to 0x48000000

2017-10-09 Thread Tom Rini

On Mon, Sep 25, 2017 at 09:14:20AM +0200, patrice.chot...@st.com wrote:

> From: Lee Jones 
> 
> Add missing ramdisk_addr_r param and set it to 0x4800
> 
> Signed-off-by: Lee Jones 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v1, 4/6] serial: stm32x7: add fifo support for STM32H7

2017-10-09 Thread Tom Rini

On Wed, Sep 27, 2017 at 03:44:51PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Add fifo mode support for rx and tx.
> As only STM32H7 supports this feature, add has_fifo flag
> to uart configuration to use fifo only when possible.
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v3,2/3] board: STiH410-B2260: fix sdram size

2017-10-09 Thread Tom Rini

On Mon, Sep 25, 2017 at 09:14:19AM +0200, patrice.chot...@st.com wrote:

> From: Nicolas Le Bayon 
> 
> 32MB are reserved for TrustZone purpose
> 
> Signed-off-by: Nicolas Le Bayon 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] configs: stm32: update SRAM address for STM32H7 disco and eval

2017-10-09 Thread Tom Rini

On Tue, Oct 03, 2017 at 03:47:59PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> As suggested by Vikas Manocha, update embedded SRAM address
> to use AXI SRAM available on D1 domain instead of using
> AHB SRAM (D2 domain).
> On some STM32H743 SoCs, D2 domain SRAM is accessible even if
> SRAMxEN bit in AHB2ENR bits are not set whereas on others SoCs
> version it's not accessible.
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Vikas Manocha 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 2/7] ARM: DTS: stm32: add SDMMC support fo stm32h743-eval

2017-10-09 Thread Tom Rini

On Tue, Oct 03, 2017 at 03:54:57PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Add pinctrl and sdmmc nodes to add MMC support for
> STM32H743 evaluation board.
> 
> Evaluation board needs a second pinctrl node
> "pinctrl_sdmmc1_level_shifter" to drive a level shifter
> on MMC bus.
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] scripts: Move Kconfig contents to cmd/Kconfig

2017-10-09 Thread Tom Rini

On Thu, Sep 28, 2017 at 12:33:45PM -0700, Sam Protsenko wrote:

> On case-insensitive file systems we have collision between
> scripts/kconfig/ directory and scripts/Kconfig file. This patch moves
> scripts/Kcofnig contents to cmd/Kconfig to fix that.
> 
> Signed-off-by: Sam Protsenko 
> Acked-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v1,1/6] serial: stm32x7: cleanup code

2017-10-09 Thread Tom Rini

On Wed, Sep 27, 2017 at 03:44:48PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Use BIT() macro and GENMASK() macro
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Vikas Manocha 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v1, 2/6] serial: stm32x7: remove stm32f7-usart and stm32h7-usart compatible

2017-10-09 Thread Tom Rini

On Wed, Sep 27, 2017 at 03:44:49PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> This patch remove the extra compatibility string "st,stm32h7-usart"
> and "st,stm32f7-usart" to avoid confusion, save some time & space.
> 
> Signed-off-by: Patrice Chotard 
> Reviewed-by: Vikas Manocha 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v1, 3/6] serial: stm32x7: prepare the ground to STM32F4 support

2017-10-09 Thread Tom Rini

On Wed, Sep 27, 2017 at 03:44:50PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> STM32F4 serial IP is similar to F7 and H7, but registers
> are not located at the same offset and some feature are
> only supported by F7 and H7 version.
> 
> Registers offset must be added for each version and also
> some flags indicated the supported feature.
> 
> Update registers name to match with datasheet (sr to isr,
> rx_dr to rdr and tx_dr to tdr) and remove unused regs
> (cr2, gtpr, rtor, and rqr).
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/1] ARMv8: make master CPU checking logic more clear

2017-10-09 Thread Tom Rini

On Mon, Sep 25, 2017 at 03:28:50PM +0800, zijun_hu wrote:

> From: zijun_hu 
> 
> macro branch_if_master checks master CPU via (Aff3 & (Aff2:Aff1:Aff0))
> it is simple but a little obscure.
> 
> fix by checking Affx fields within MPIDR_EL1 directly.
> 
> Signed-off-by: zijun_hu 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 5/7] configs: stm32h743-disco: enable SDMMC support

2017-10-09 Thread Tom Rini

On Tue, Oct 03, 2017 at 03:55:00PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Enable CMD_MMC, DM_MMC and STM32_SDMMC2 flags
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 1/2] fs/fat: Fix 'CACHE: Misaligned operation at range' warnings

2017-10-09 Thread Tom Rini

On Sun, Oct 01, 2017 at 02:25:21AM +0300, Tuomas Tynkkynen wrote:

> The 'block' field of fat_itr needs to be properly aligned for DMA and
> while it does have '__aligned(ARCH_DMA_MINALIGN)', the fat_itr structure
> itself needs to be properly aligned as well.
> 
> While at it use malloc_cache_aligned() for the other aligned allocations
> in the file as well.
> 
> Fixes: 2460098cffacd1 ("fs/fat: Reduce stack usage")
> Signed-off-by: Tuomas Tynkkynen 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v1, 6/6] serial: stm32x7: remove useless CONFIG_CLK and OF_CONTROL flag

2017-10-09 Thread Tom Rini

On Wed, Sep 27, 2017 at 03:44:53PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> This driver is currently used by STM32F7 and STM32H7 SoCs.
> As CONFIG_CLK and OF_CONTROL flags are set by default for these
> 2 SoCs, this flag becomes useless in this driver, so remove it.
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 2/2] fs/fat: Check malloc return values and fix memory leaks

2017-10-09 Thread Tom Rini

On Sun, Oct 01, 2017 at 02:25:22AM +0300, Tuomas Tynkkynen wrote:

> Check malloc() return values and properly unwind on errors so
> memory allocated for fat_itr structures get freed properly.
> 
> Also fixes a leak of fsdata.fatbuf in fat_size().
> 
> Fixes: 2460098cffacd1 ("fs/fat: Reduce stack usage")
> Reported-by: Coverity (CID: 167225, 167233, 167234)
> Signed-off-by: Tuomas Tynkkynen 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

2017-10-09 Thread Rob Clark

On Mon, Oct 9, 2017 at 12:22 PM, Heinrich Schuchardt  wrote:
> On 10/09/2017 06:06 PM, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>>> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
 On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  wrote:
>>> On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
 This fixes an issue with OpenBSD's bootloader, and I think should also
 fix a similar issue with grub2 on legacy devices.  In the legacy case
 we were creating disk objects for the partitions, but not also the
 parent device.

 Reported-by: Jonathan Gray 
 Signed-off-by: Rob Clark 
>>>
>>> Thanks for looking into this.  While this lets armv7/bootarm.efi
>>> boot again on cubox-i and bbb it doesn't help rpi3.
>>>
>>> What is the easiest way to get U-Boot to display these paths
>>> to be able to compare the current behaviour to 2017.09?
>>>
>>
>> in grub, there is the lsefi command, not sure if the OpenBSD
>> bootloader has something similar?
>>
>> u-boot implements that device-path to text protocol, so it should be
>> pretty easy to implement something like this if not.
>>
>> BR,
>> -R
>
> With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> is no longer seen.  Is it possible having U-Boot on mmc but directing
> it to load off usb is somehow involved here?

 There is no requirement that efi payload and u-boot are on the same
 device.  The distro bootcmd stuff will just look for
 /efi/boot/bootxyz.efi on all the devices/partitions until it finds
 one.

 The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
 or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
 or legacy boards, in the former case we can construct something more
 realistic.  Although the bootloader shouldn't really care.
>>>
>>> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>>> in master only gives types of 1 (Hardware Device Path) and
>>> 3 (Messaging Device Path).
>>>
>>> It is DM in this case:
>>
>> Possibly something weird with your partition table?  In
>> efi_disk_register() it should create objects for the disk itself
>> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>> partition (part>=1, which would have same dp as the disk but
>> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>>
>> If part_get_info() fails for part==1 then you won't get any of the
>> partition devices.  I suppose this could happen if you an unknown
>> partition table type, or u-boot is not built w/ the correct partition
>> driver.
>>
>> BR,
>> -R
>>
>>
>>> U-Boot> dm tree
>>>  Class  Probed  Driver  Name
>>> 
>>>  root   [ + ]   root_drive  root_driver
>>>  simple_bus [ + ]   generic_si  |-- soc
>>>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>>>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>>>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>>>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>>>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>>>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>>>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>>>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>>>  blk[   ]   usb_storag  |   `-- 
>>> usb_mass_storage.lun0
>>>  simple_bus [   ]   generic_si  `-- clocks
>>>

> efi_bootdp obtained from the loaded image protocol
>
> 2017.09
>
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 76 ms (1013.7 KiB/s)
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 4
> depth=0
> i=0
> efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
> i=1
> efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> booting sd0a:/bsd: 3871708+578596+509352+803952 
> [283845+96+451968+239920]=0x82f330
>
> git + patch


 I assume you are referring to this patch?  It should only add
 additional per-partion "disk" objects.  (In UEFI terminology each
 partition is a "disk" object.)
>>>
>>> Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
>>> The problem seems to be

Re: [U-Boot] cmd: Make CMD_LZMA / CMD_UNZIP default y if CMD_BOOTI

2017-10-09 Thread Tom Rini

On Fri, Sep 29, 2017 at 02:32:44PM -0400, Tom Rini wrote:

> In the Linux Kernel on ARM64, the Image.COMPRESSION file is not
> self-extracting in the way that x86 and ARM images are.  So when
> CMD_BOOTI is enabled we should also default to enabling CMD_UNZIP and
> CONFIG_LZMA in order for the user to be able to decompress many of the
> common compressions that will be done to an Image file.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 3/7] dm: mmc: remove DM_MMC_OPS for STM32_SDMMC

2017-10-09 Thread Tom Rini

On Tue, Oct 03, 2017 at 03:54:58PM +0200, patrice.chot...@st.com wrote:

> From: Patrice Chotard 
> 
> Since e7881d85 "dm: mmc: Drop CONFIG_DM_MMC_OPS" DM_MMC_OPS
> is no more used, remove it from STM32_SDMMC2 dependencies
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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

1 2 >

1 - 100 of 142 matches

Mail list logo