Re: [U-Boot] [PATCH 1/1] MAINTAINERS: ARM TI: remove invalid paths

[Lokesh Vutla]

On Tuesday 13 March 2018 04:10 AM, Heinrich Schuchardt wrote:
> Remove non-existing paths.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  MAINTAINERS | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 704ee53e0de..50e82d4d245 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -224,8 +224,6 @@ S:Maintained
>  T:   git git://git.denx.de/u-boot-ti.git
>  F:   arch/arm/mach-davinci/
>  F:   arch/arm/mach-keystone/
> -F:   arch/arm/cpu/arm926ejs/omap/
> -F:   arch/arm/cpu/armv7/omap*/

Also, can you add arch/arm/mach-omap2/*

Thanks and regards,
Lokesh

>  F:   arch/arm/include/asm/arch-omap*/
>  F:   arch/arm/include/asm/ti-common/
>  
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Status of Altera Aria 10 in upstream

[Friedrich Daniel]

Hello Jan,

let me quote my mail to Claudio, who asked more or less the same on March 
7th(see mail below). 
Personally, hoped that someone from Intel/Altera has the guts to answer this 
question or at least the Maintainer of the socfpga.
I'm by far not good at u-boot, so it is just hacked together what was needed 
for the project so far.

If any Maintainer reads this, I suggest removing the Arria10 from the current 
master branch as it is unusable(system does not even boot) for any one the way 
it is now.

> Hello Claudio,
>
> I tried it as well and failed. My personal guess is that Altera/Intel never 
> pushed proper support into the official u-boot mainline.
> Even there master-branch 
> (https://github.com/altera-opensource/u-boot-socfpga/tree/master) does not 
> work. For "just a user" it is very frustrating getting a new board abut have 
> to use old software.
> And it seems Intel does not care in providing documentation, up-to-date 
> software or maintaining the released code.
> For example if you look closer into the source code in the 
> socfpga_v2014.10_arria10_bringup-branch there is a module called cff which 
> loads the rbf-file in early release mode.
> I could  not find anything similar in the latest branches(neither from denx 
> not altera). Also the images generated from the latest releases generates not 
> the proper format needed to boot from an Arria10.
>
> So for my needs I used 
> (https://github.com/altera-opensource/u-boot-socfpga/tree/socfpga_v2014.10_arria10_bringup)
>  which is the version used in the Altera/Intel tools But changed it to my 
> needs (loading > rbf-file, kernel and devicetree from EXT, setting u-boot 
> environment to my needs etc.) I compile everything with the toolchain from 
> yocto V2.4. and so far it works good.
> My changes are made public 
> here(https://github.com/nanosurf-ag/u-boot-socfpga) but this might still 
> subject to change.
>
> Hope this helps
> dan


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

Re: [U-Boot] [PATCH][Boards Need to Switch DM] spi: atmel: Full dm conversion

[Wenyou Yang]

On 3/7/2018 1:51 PM, Jagan Teki wrote:

atmel_spi now support dt along with platform data,
respective boards need to switch into dm for the same.

Signed-off-by: Jagan Teki 
---

Indeed.

Acked-by: Wenyou Yang 

Best Regards,
Wenyou Yang

  drivers/spi/atmel_spi.c  | 294 +++
  include/dm/platform_data/spi_atmel.h |  17 ++
  2 files changed, 69 insertions(+), 242 deletions(-)
  create mode 100644 include/dm/platform_data/spi_atmel.h

diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index 8010ab434c..0bd395bb4a 100644
--- a/drivers/spi/atmel_spi.c
+++ b/drivers/spi/atmel_spi.c
@@ -12,240 +12,31 @@
  #include 
  
  #include 

-
  #include 
  #include 
-#ifdef CONFIG_DM_SPI
  #include 
-#endif
-#ifdef CONFIG_DM_GPIO
  #include 
-#endif
+
+#include 
  
  #include "atmel_spi.h"
  
  DECLARE_GLOBAL_DATA_PTR;
  
-#ifndef CONFIG_DM_SPI

-
-static int spi_has_wdrbt(struct atmel_spi_slave *slave)
-{
-   unsigned int ver;
-
-   ver = spi_readl(slave, VERSION);
-
-   return (ATMEL_SPI_VERSION_REV(ver) >= 0x210);
-}
-
-void spi_init()
-{
-
-}
-
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
-   unsigned int max_hz, unsigned int mode)
-{
-   struct atmel_spi_slave  *as;
-   unsigned intscbr;
-   u32 csrx;
-   void*regs;
-
-   if (!spi_cs_is_valid(bus, cs))
-   return NULL;
-
-   switch (bus) {
-   case 0:
-   regs = (void *)ATMEL_BASE_SPI0;
-   break;
-#ifdef ATMEL_BASE_SPI1
-   case 1:
-   regs = (void *)ATMEL_BASE_SPI1;
-   break;
-#endif
-#ifdef ATMEL_BASE_SPI2
-   case 2:
-   regs = (void *)ATMEL_BASE_SPI2;
-   break;
-#endif
-#ifdef ATMEL_BASE_SPI3
-   case 3:
-   regs = (void *)ATMEL_BASE_SPI3;
-   break;
-#endif
-   default:
-   return NULL;
-   }
-
-
-   scbr = (get_spi_clk_rate(bus) + max_hz - 1) / max_hz;
-   if (scbr > ATMEL_SPI_CSRx_SCBR_MAX)
-   /* Too low max SCK rate */
-   return NULL;
-   if (scbr < 1)
-   scbr = 1;
-
-   csrx = ATMEL_SPI_CSRx_SCBR(scbr);
-   csrx |= ATMEL_SPI_CSRx_BITS(ATMEL_SPI_BITS_8);
-   if (!(mode & SPI_CPHA))
-   csrx |= ATMEL_SPI_CSRx_NCPHA;
-   if (mode & SPI_CPOL)
-   csrx |= ATMEL_SPI_CSRx_CPOL;
-
-   as = spi_alloc_slave(struct atmel_spi_slave, bus, cs);
-   if (!as)
-   return NULL;
-
-   as->regs = regs;
-   as->mr = ATMEL_SPI_MR_MSTR | ATMEL_SPI_MR_MODFDIS
-   | ATMEL_SPI_MR_PCS(~(1 << cs) & 0xf);
-   if (spi_has_wdrbt(as))
-   as->mr |= ATMEL_SPI_MR_WDRBT;
-
-   spi_writel(as, CSR(cs), csrx);
-
-   return >slave;
-}
-
-void spi_free_slave(struct spi_slave *slave)
-{
-   struct atmel_spi_slave *as = to_atmel_spi(slave);
-
-   free(as);
-}
-
-int spi_claim_bus(struct spi_slave *slave)
-{
-   struct atmel_spi_slave *as = to_atmel_spi(slave);
-
-   /* Enable the SPI hardware */
-   spi_writel(as, CR, ATMEL_SPI_CR_SPIEN);
-
-   /*
-* Select the slave. This should set SCK to the correct
-* initial state, etc.
-*/
-   spi_writel(as, MR, as->mr);
-
-   return 0;
-}
-
-void spi_release_bus(struct spi_slave *slave)
-{
-   struct atmel_spi_slave *as = to_atmel_spi(slave);
-
-   /* Disable the SPI hardware */
-   spi_writel(as, CR, ATMEL_SPI_CR_SPIDIS);
-}
-
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
-   const void *dout, void *din, unsigned long flags)
-{
-   struct atmel_spi_slave *as = to_atmel_spi(slave);
-   unsigned intlen_tx;
-   unsigned intlen_rx;
-   unsigned intlen;
-   u32 status;
-   const u8*txp = dout;
-   u8  *rxp = din;
-   u8  value;
-
-   if (bitlen == 0)
-   /* Finish any previously submitted transfers */
-   goto out;
-
-   /*
-* TODO: The controller can do non-multiple-of-8 bit
-* transfers, but this driver currently doesn't support it.
-*
-* It's also not clear how such transfers are supposed to be
-* represented as a stream of bytes...this is a limitation of
-* the current SPI interface.
-*/
-   if (bitlen % 8) {
-   /* Errors always terminate an ongoing transfer */
-   flags |= SPI_XFER_END;
-   goto out;
-   }
-
-   len = bitlen / 8;
-
-   /*
-* The controller can do automatic CS control, but it is
-* somewhat quirky, and it doesn't really buy us much anyway
-* in the context of U-Boot.
-*/
-   if (flags & SPI_XFER_BEGIN) {
-   spi_cs_activate(slave);
-

[U-Boot] [PATCH] configs: i.MX6: Move USB Manufacturer, VID, PID to Kconfig

[Jagan Teki]

Define i.MX6 defaults for USB_GADGET_MANUFACTURER|VENDOR_NUM|PRODUCT_NUM
instead of redundant defines in defconfig files.

Signed-off-by: Jagan Teki 
---
 configs/cgtqmx6eval_defconfig  | 2 --
 configs/dh_imx6_defconfig  | 2 --
 configs/dms-ba16-1g_defconfig  | 2 --
 configs/dms-ba16_defconfig | 2 --
 configs/gwventana_emmc_defconfig   | 2 --
 configs/gwventana_gw5904_defconfig | 2 --
 configs/gwventana_nand_defconfig   | 2 --
 configs/mx6memcal_defconfig| 3 ---
 configs/mx6qsabrelite_defconfig| 2 --
 configs/mx6sabreauto_defconfig | 3 ---
 configs/mx6sabresd_defconfig   | 3 ---
 configs/nitrogen6dl2g_defconfig| 2 --
 configs/nitrogen6dl_defconfig  | 2 --
 configs/nitrogen6q2g_defconfig | 2 --
 configs/nitrogen6q_defconfig   | 2 --
 configs/nitrogen6s1g_defconfig | 2 --
 configs/nitrogen6s_defconfig   | 2 --
 configs/opos6uldev_defconfig   | 2 --
 configs/pico-imx6ul_defconfig  | 3 ---
 configs/tbs2910_defconfig  | 2 --
 configs/warp_defconfig | 3 ---
 drivers/usb/gadget/Kconfig | 3 +++
 22 files changed, 3 insertions(+), 47 deletions(-)

diff --git a/configs/cgtqmx6eval_defconfig b/configs/cgtqmx6eval_defconfig
index 2ac0bac0b6..65d96e52e7 100644
--- a/configs/cgtqmx6eval_defconfig
+++ b/configs/cgtqmx6eval_defconfig
@@ -57,8 +57,6 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Congatec"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
index 2b4fe9c2c5..01f805f443 100644
--- a/configs/dh_imx6_defconfig
+++ b/configs/dh_imx6_defconfig
@@ -48,8 +48,6 @@ CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="dh"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/dms-ba16-1g_defconfig b/configs/dms-ba16-1g_defconfig
index 40b317093f..311da5db5f 100644
--- a/configs/dms-ba16-1g_defconfig
+++ b/configs/dms-ba16-1g_defconfig
@@ -40,8 +40,6 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Advantech"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_VIDEO=y
diff --git a/configs/dms-ba16_defconfig b/configs/dms-ba16_defconfig
index 3519c5275c..ca0ac8d7be 100644
--- a/configs/dms-ba16_defconfig
+++ b/configs/dms-ba16_defconfig
@@ -39,8 +39,6 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Advantech"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_VIDEO=y
diff --git a/configs/gwventana_emmc_defconfig b/configs/gwventana_emmc_defconfig
index a6db1040b6..f50f4f83ae 100644
--- a/configs/gwventana_emmc_defconfig
+++ b/configs/gwventana_emmc_defconfig
@@ -66,8 +66,6 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Gateworks"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
diff --git a/configs/gwventana_gw5904_defconfig 
b/configs/gwventana_gw5904_defconfig
index 41b93c8a07..0978086631 100644
--- a/configs/gwventana_gw5904_defconfig
+++ b/configs/gwventana_gw5904_defconfig
@@ -70,8 +70,6 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Gateworks"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
diff --git a/configs/gwventana_nand_defconfig b/configs/gwventana_nand_defconfig
index e513289583..9431f016ff 100644
--- a/configs/gwventana_nand_defconfig
+++ b/configs/gwventana_nand_defconfig
@@ -70,8 +70,6 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Gateworks"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_ETHER=y
diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index fdcef6b65b..3fcb8518c4 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -35,8 +35,5 @@ CONFIG_CMD_CACHE=y
 # CONFIG_MMC is not set
 CONFIG_USB=y
 CONFIG_USB_GADGET=y
-CONFIG_USB_GADGET_MANUFACTURER="FSL"
-CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
 CONFIG_REGEX=y
diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 

[U-Boot] [PATCH] configs: imx6qdl: Remove imx6qdl_icore_nand_defconfig

[Jagan Teki]

imx6qdl_icore_nand_defconfig is no longer used, since
it was the recreated for quad and dl separately.
"imx6q: engicam: Use SPL_LOAD_FIT for MMC boards"
(sha1: 3d409153502f25a1ea3b8b4e9940148b7871273d)

Signed-off-by: Jagan Teki 
---
 configs/imx6qdl_icore_nand_defconfig | 49 
 1 file changed, 49 deletions(-)
 delete mode 100644 configs/imx6qdl_icore_nand_defconfig

diff --git a/configs/imx6qdl_icore_nand_defconfig 
b/configs/imx6qdl_icore_nand_defconfig
deleted file mode 100644
index 5e142272d6..00
--- a/configs/imx6qdl_icore_nand_defconfig
+++ /dev/null
@@ -1,49 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_MX6=y
-CONFIG_SYS_TEXT_BASE=0x1780
-CONFIG_SPL_GPIO_SUPPORT=y
-CONFIG_SPL_LIBCOMMON_SUPPORT=y
-CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_TARGET_MX6Q_ENGICAM=y
-CONFIG_SPL_SERIAL_SUPPORT=y
-CONFIG_SPL_WATCHDOG_SUPPORT=y
-# CONFIG_CMD_BMODE is not set
-CONFIG_DEFAULT_DEVICE_TREE="imx6q-icore"
-CONFIG_FIT=y
-CONFIG_FIT_SIGNATURE=y
-CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
-CONFIG_BOOTDELAY=3
-CONFIG_SUPPORT_RAW_INITRD=y
-CONFIG_SPL=y
-CONFIG_SPL_DMA_SUPPORT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_SYS_PROMPT="icorem6qdl> "
-CONFIG_CMD_MEMTEST=y
-CONFIG_CMD_GPIO=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_MMC=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_CACHE=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
-CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:2m(spl),2m(uboot),1m(env),8m(kernel),1m(dtb),-(rootfs)"
-CONFIG_CMD_UBI=y
-CONFIG_OF_LIST="imx6q-icore imx6dl-icore"
-CONFIG_ENV_IS_IN_NAND=y
-CONFIG_SYS_I2C_MXC=y
-CONFIG_NAND=y
-CONFIG_NAND_MXS=y
-CONFIG_PHYLIB=y
-CONFIG_PHY_SMSC=y
-CONFIG_FEC_MXC=y
-CONFIG_PINCTRL=y
-CONFIG_PINCTRL_IMX6=y
-CONFIG_MXC_UART=y
-CONFIG_IMX_THERMAL=y
-CONFIG_VIDEO=y
-CONFIG_VIDEO_IPUV3=y
-- 
2.14.3

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

Re: [U-Boot] [PATCH] dm: mmc: socfpga: call dwmci_probe()

[Jaehoon Chung]

On 03/10/2018 03:13 AM, Marek Vasut wrote:
> On 03/09/2018 09:24 AM, Jaehoon Chung wrote:
>> Dear Patrick,
>>
>> On 03/09/2018 03:51 PM, Patrick Brünn wrote:
 From: Patrick Brünn
 Sent: Donnerstag, 8. März 2018 06:39
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: Donnerstag, 8. März 2018 04:57
> On 03/08/2018 12:12 PM, Marek Vasut wrote:
>> On 03/08/2018 03:17 AM, Jaehoon Chung wrote:
>>> On 03/06/2018 05:07 PM, linux-kernel-...@beckhoff.com wrote:
 From: Patrick Bruenn 

 On a socfpga_cyclone5 based board the SD card, was never powered
 up.
> For
 other dw_mmc based SoCs dwmci_probe() is called in the platform
> specific
 probe(). It seems this call is missing for socfpga_dw_mmc.

 With this change DWMCI_PWREN is set by dmwci_init().

 Signed-off-by: Patrick Bruenn 
>>>
>>> Reviewed-by: Jaehoon Chung 
>>>
>>> Will apply this patch before releasing v2018.03.
>>> (I have a problem about accessing git.denx.de. After fixing my problem,
> will resend email about applying.)
>>
>> DWMMC works on SoCFPGA for me (tested on rc4), so I don't understand
> what this patch is trying to fix. I'd prefer if you did not hastily apply 
> this.
>
> It's my misunderstanding. When i checked more. I think that Marek is 
> right.
> Thanks Marek for pointing out.
>
 Okay, but do you have any hint what I am doing wrong? My board (cx8100 not
 mainline, yet) is based on socfpga_cyclone5. And on my board "
 dwmci_writel(host, DWMCI_PWREN, 1);" is never called, because
 dwmci_init() is never called.
 As far as I can see with CONFIG_DM_MMC enabled dwmci_init() should be
 called by dwmci_probe().

 exynos  and rockchip do call dwmci_probe() within
 exynos/rockchip_dwmmc_probe().
 but socfpga_dwmmc_probe() is missing this call. So I looked deeper but 
 found
 no place for socfpga platform to call dwmci_probe() or dwmci_init().
 What am I missing?

>>> I got an idea, what might be the difference between my board and your 
>>> boards.
>>> I suspect you use U-BOOT SPL without CONFIG_DM_MMC set, so
>>> dwmci_init() is called indirectly by mmc_start_init().
>>
>> Right, it's difference with CONFIG_DM_MMC. I had checked this.
>>
>>> Now, when your main U-Boot (with CONFIG_DM_MMC) is launched,
>>> everything is already configured and it isn't necessary to call 
>>> dwmci_init() again.
>>> On my board the Altera MPL is used (and I can't replace it).  Which seems to
>>> disable DWMCI_PWREN before launching U-Boot.
>>> If my assumption is correct, I still think it is a U-Boot bug to assume 
>>> code like in
>>> dwmci_init() was already run before U-Boot gets in control.
>>> Besides exynos/rockchip_dw_mmc don't have this precondition requirement.
>>>
>>> Please take your time to look deeper into this issue, before deciding 
>>> anything.
>>> I don't think we need to rush this into the next release, as normal mainline
>>> boards are "accidently" not affected.
>>
>> Sure. I will check this patch. Before applying this, will check more 
>> carefully.
>> I agreed about Marek's opinion "did not hastily apply this."
>> And i think that your approach also is right.
> 
> Please queue for -next , NOT this release.

Yes. I understood what you want. Thanks!

> 
> 
> 

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

Re: [U-Boot] [PATCH v2 00/10] splash screen on the stm32f769 disco board

[Vikas Manocha]

Thanks Patrice,

On 03/12/2018 10:09 AM, Patrice CHOTARD wrote:
> Hi Vikas
> 
> On 03/06/2018 08:44 PM, Vikas Manocha wrote:
>> Hi Patrice/Yannick,
>>
>> On 03/05/2018 11:50 PM, Patrice CHOTARD wrote:
 There seems to be a dependency on patch for 
 include/dt-bindings/mfd/stm32f7-rcc.h
 adding some new macros. Is it also submitted to the list?
>>> Right, needed patches are already on the list
>>> http://patchwork.ozlabs.org/patch/870938/
>>
>> Great addition !
>>
>> Few points:
>> it seems above mentioned patchset also has dependency on another patchset 
>> http://patchwork.ozlabs.org/patch/870283/
>> After applying these two dependency patchsets, it creates conflicts with 
>> pathch "ARM: dts: stm32: Add timer support for STM32F7".
>> I understand you want to get it reviewed without waiting for other patchset 
>> acceptance, it would be good to mention all the dependencies.
>>
>> Also i observe that without applying f769 display patches, f746 display 
>> didn't work.
>> And F769 board display is not working, i see one error log:
>>
>> Board 1:
>> stm32_ltdc_probe: decode display timing error -4
>> & Board 2:
>> stm32_ltdc_probe: decode display timing error -668998023
>>
>> Cheers,
>> Vikas
>>
>>>
>>> Patrice
>>>
> 
> 
> We got a look at this issue with Yannick.
> 
> On my side, i got this problem because i used the 
> stm32f746-disco_defconfig by updating CONFIG_DEFAULT_DEVICE_TREE with 
> the following update, (and i suppose you do the same ;-) ):
> 
> CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco"
> 
> By using the stm32f769-disco_defconfig, everything is working fine.
> That's why Yannick added a dedicated defconfig file for STM32F769.

oh, i was also passing DEVICE_TREE during compilation.
With the stm32f769 config, it still stops after DRAM size.

"
U-Boot SPL 2018.03-rc4-00055-g0d3c012-dirty (Mar 12 2018 - 11:31:20 -0700)
Trying to boot from XIP

U-Boot 2018.03-rc4-00055-g0d3c012-dirty (Mar 12 2018 - 11:31:20 -0700)

Model: STMicroelectronics STM32F769-DISCO board
DRAM:  16 MiB

"

But I don't want to hold on for the series.

Acked-by: Vikas Manocha 

Cheers,
Vikas

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

Re: [U-Boot] [PATCH 1/1] MAINTAINERS: TI SYSTEM SECURITY: remove invalid file

[Andrew F. Davis]

On 03/12/2018 05:58 PM, Heinrich Schuchardt wrote:
> Remove a link to a non-existent file.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---


Looks like that file was removed in 3348e0c0a6 so:

Acked-by: Andrew F. Davis 


>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 50e82d4d245..2414bcced2d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -470,7 +470,6 @@ TI SYSTEM SECURITY
>  M:   Andrew F. Davis 
>  S:   Supported
>  F:   arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
> -F:   arch/arm/mach-omap2/omap5/sec-fxns.c
>  F:   arch/arm/mach-omap2/sec-common.c
>  F:   arch/arm/mach-omap2/config_secure.mk
>  F:   configs/am335x_hs_evm_defconfig
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/8] add inital SF tests

[Liam Beguin]

Hi everyone,

Any new comments on this iteration?

Thanks,
Liam

On Sun, 4 Mar 2018 at 23:22 Liam Beguin  wrote:

> Hi all,
>
> This is the inital step to adding tests for the SF subsystem plus very
> minor fixes. It is based on work I found on the mailing list[1].
> For now, it doesn't do much but I plan on adding code to reset the flash
> to its initial state (based on an env flag) and more code to test the
> `sf protect` subcommand (which is the main goal of this series).
> I'm sending it now to make sure it's headed in the right direction.
>
> Base on Stephen's comment[2], I haven't added the radomized features.
> I'll see how this iteration goes and maybe add it later.
>
> Changes since v1:
>  - remove unnecessary skip flag from environment
>  - move crc32() to u_boot_utils.py and add extra checks
>  - rewrite sf_prepare to return a dict of parameter
>  - use assert instead of pytest.fail
>  - remove verbose from sf_prepare()
>  - update documentation
>  - improve readability
>  - use ' consistently instead of "
>  - use sf_read() in test_sf_read()
>  - rename crc variables
>  - add speed parameter with optional random range
>  - allow `sf read` to write at 0x00
>
> Thanks,
> Liam Beguin
>
> [ 1 ] https://patchwork.ozlabs.org/patch/623061/
> [ 2 ] https://lists.denx.de/pipermail/u-boot/2018-March/321688.html
>
> Liam Beguin (8):
>   spi: spi_flash: do not fail silently on bad user input
>   cmd: sf: fix map_physmem check
>   test/py: README: fix typo
>   test/py: README: add HOSTNAME to PYTHONPATH
>   test/py: do not import pytest multiple times
>   test/py: add generic CRC32 function
>   test/py: add spi_flash tests
>
>  cmd/sf.c|   2 +-
>  drivers/mtd/spi/spi_flash.c |   2 +-
>  test/py/README.md   |   6 +-
>  test/py/tests/test_sf.py| 223
> 
>  test/py/u_boot_utils.py |  24 -
>  5 files changed, 251 insertions(+), 6 deletions(-)
>  create mode 100644 test/py/tests/test_sf.py
>
>
> base-commit: 77bba970e2372b01156c66585db3d6fc751c7178
> Published-As: https://github.com/Liambeguin/u-boot/releases/tag/test_sf-v2
>
> --
> 2.16.1.72.g5be1f00a9a70
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] MAINTAINERS: TI SYSTEM SECURITY: remove invalid file

[Heinrich Schuchardt]

Remove a link to a non-existent file.

Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 50e82d4d245..2414bcced2d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -470,7 +470,6 @@ TI SYSTEM SECURITY
 M: Andrew F. Davis 
 S: Supported
 F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
-F: arch/arm/mach-omap2/omap5/sec-fxns.c
 F: arch/arm/mach-omap2/sec-common.c
 F: arch/arm/mach-omap2/config_secure.mk
 F: configs/am335x_hs_evm_defconfig
-- 
2.16.1

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

[U-Boot] MAINTAINERS: PPC4XX

[Heinrich Schuchardt]

Hello Stefan,

the entry for PPC4XX seems to be outdated:

POWERPC PPC4XX
M:  Stefan Roese 
S:  Maintained
T:  git git://git.denx.de/u-boot-ppc4xx.git
F:  arch/powerpc/cpu/ppc4xx/

This path does not exist because the architecture has been removed.
The git repository has not been updated for the last 17 months.

Could you, please, either remove or update the MAINTAINERS entry.

Best regards

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

[U-Boot] [PATCH 1/1] MAINTAINERS: ARM TI: remove invalid paths

[Heinrich Schuchardt]

Remove non-existing paths.

Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS | 2 --
 1 file changed, 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 704ee53e0de..50e82d4d245 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -224,8 +224,6 @@ S:  Maintained
 T: git git://git.denx.de/u-boot-ti.git
 F: arch/arm/mach-davinci/
 F: arch/arm/mach-keystone/
-F: arch/arm/cpu/arm926ejs/omap/
-F: arch/arm/cpu/armv7/omap*/
 F: arch/arm/include/asm/arch-omap*/
 F: arch/arm/include/asm/ti-common/
 
-- 
2.16.1

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

Re: [U-Boot] [PATCH v3 00/20] Bring NAND support to Nintendo NES Classic

[Scott Wood]

On Wed, 2018-03-07 at 08:57 +0100, Maxime Ripard wrote:
> Hi Scott,
> 
> On Wed, Feb 28, 2018 at 08:51:42PM +0100, Miquel Raynal wrote:
> > This series first adds fixes and enhancements to sunxi NAND drivers (SPL
> > and U-Boot). Once this is done, the SPL NAND driver is converted to use
> > PIO instead of DMA with the goal to support all SoCs with this IP
> > without the need for DMA-related code. Finally, NAND support is added to
> > Nintendo NES Classic through Kconfig and DT additions.
> 
> Should we merge it through the sunxi tree, or do you want to merge
> these changes through yours?

The sunxi tree.  I'm not really involved much with U-Boot these days.

-Scott

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

[U-Boot] MAINTAINERS ARM ZYNQ(MP)

[Heinrich Schuchardt]

Hello Michal,

it seems that the entries for ZYNQ in the MAINTAINERS file of U-Boot are
out of date:

ARM ZYNQ
M:  Michal Simek 
S:  Maintained
F:  arch/arm/cpu/armv7/zynq/
F:  arch/arm/include/asm/arch-zynq/

The paths above do not exist.

ARM ZYNQMP
M:  Michal Simek 
S:  Maintained
F:  arch/arm/cpu/armv8/zynqmp/
F:  arch/arm/include/asm/arch-zynqmp/

The E-Mail addresses do not match but maybe that is on purpose.

A lot of ZYNQ related stuff does not appear:

./board/xilinx/zynq*
./arch/arm/dts/zynq*
./arch/arm/mach-zynq/

Could you, please, have a look at the entries.

Best regards

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

[U-Boot] [PATCH 1/1] MAINTAINERS: ARM SAMSUNG: remove invalid paths

[Heinrich Schuchardt]

Remove non-existing directories.

Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS | 2 --
 1 file changed, 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2177bfc2ef7..704ee53e0de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -173,11 +173,9 @@ ARM SAMSUNG
 M: Minkyu Kang 
 S: Maintained
 T: git git://git.denx.de/u-boot-samsung.git
-F: arch/arm/cpu/arm920t/s3c24x0/
 F: arch/arm/mach-exynos/
 F: arch/arm/mach-s5pc1xx/
 F: arch/arm/cpu/armv7/s5p-common/
-F: arch/arm/include/asm/arch-s3c24x0/
 
 ARM SNAPDRAGON
 M: Mateusz Kulikowski 
-- 
2.16.1

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

[U-Boot] [PATCH 1/1] MAINTAINERS: FLATTENED DEVICE TREE: correct maintained path

[Heinrich Schuchardt]

Change due to commit b08c8c487083 ("libfdt: move headers to
 and ")

Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c80c42f4794..2177bfc2ef7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -306,7 +306,7 @@ T:  git git://git.denx.de/u-boot-fdt.git
 F: lib/fdtdec*
 F: lib/libfdt/
 F: include/fdt*
-F: include/libfdt*
+F: include/linux/libfdt*
 F: cmd/fdt.c
 F: common/fdt_support.c
 
-- 
2.16.1

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

Re: [U-Boot] [PATCH 1/1] MAINTAINERS: ARM FREESCALE IMX: remove invalid path

[Fabio Estevam]

On Mon, Mar 12, 2018 at 6:56 PM, Heinrich Schuchardt  wrote:
> arch/arm/cpu/armv7/mx*/ does not relate to any existing directory.
>
> Signed-off-by: Heinrich Schuchardt 

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

[U-Boot] [PATCH 1/1] MAINTAINERS: ARM HISILICON: correct maintained path

[Heinrich Schuchardt]

Fix an incorrect path.

Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index ba6ff9a0859..c80c42f4794 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -123,7 +123,7 @@ ARM HISILICON
 M: Peter Griffin 
 S: Maintained
 F: arch/arm/cpu/armv8/hisilicon
-F: arm/include/asm/arch-hi6220/
+F: arch/arm/include/asm/arch-hi6220/
 
 ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X
 M: Prafulla Wadaskar 
-- 
2.16.1

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

[U-Boot] [PATCH 1/1] MAINTAINERS: ARM FREESCALE IMX: remove invalid path

[Heinrich Schuchardt]

arch/arm/cpu/armv7/mx*/ does not relate to any existing directory.

Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index d4900e000d2..ba6ff9a0859 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -111,7 +111,6 @@ S:  Maintained
 T: git git://git.denx.de/u-boot-imx.git
 F: arch/arm/cpu/arm1136/mx*/
 F: arch/arm/cpu/arm926ejs/mx*/
-F: arch/arm/cpu/armv7/mx*/
 F: arch/arm/cpu/armv7/vf610/
 F: arch/arm/mach-imx/
 F: arch/arm/include/asm/arch-imx/
-- 
2.16.1

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

[U-Boot] [PATCH v4 1/1] efi: Add a TODO to efi_init_obj_list()

[Heinrich Schuchardt]

From: Simon Glass 

This function repeats data structures provided by driver model. They are
only created once so can be stale if the EFI loader is called twice (e.g.
for testing or on boot failure).

Add a TODO to address this. It should be possible to attach EFI devices
and data structures to driver-model devices and avoid having a parallel
set of data structures.

Signed-off-by: Simon Glass 
[Rebased]
Reviewed-by: Heinrich Schuchardt 
---
v4
rebased
v3
no change
v2
no change
---
 cmd/bootefi.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 6afece10bc1..269cc71d0bd 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -29,7 +29,13 @@ static efi_status_t efi_obj_list_initialized = 
OBJ_LIST_NOT_INITIALIZED;
 static struct efi_device_path *bootefi_image_path;
 static struct efi_device_path *bootefi_device_path;
 
-/* Initialize and populate EFI object list */
+/*
+ * Initialize and populate EFI object list
+ *
+ * TODO(s...@chromium.org): Move this to a dynamic list based on driver model,
+ * so that it does not need to be created before running EFI applications
+ * and updates when devices change.
+ */
 efi_status_t efi_init_obj_list(void)
 {
efi_status_t ret = EFI_SUCCESS;
-- 
2.16.1

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

Re: [U-Boot] [PATCH v3 05/21] efi: Add a TODO to efi_init_obj_list()

[Heinrich Schuchardt]

On 02/19/2018 04:48 PM, Simon Glass wrote:
> This function repeats data structures provided by driver model. They are
> only created once so can be stale if the EFI loader is called twice (e.g.
> for testing or on boot failure).
> 
> Add a TODO to address this. It should be possible to attach EFI devices
> and data structures to driver-model devices and avoid having a parallel
> set of data structures.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  cmd/bootefi.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 259f80a0d8..d670a541eb 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -30,6 +30,10 @@ static struct efi_device_path *bootefi_device_path;
>  /**
>   * efi_init_obj_list() - Initialize and populate EFI object list
>   *
> + * TODO(s...@chromium.org): Move this to a dynamic list based on driver 
> model,
> + * so that it does not need to be created before running EFI applications
> + * and updates when devices change.

This could be implemented by calling the ConnectController and
DisconnectController boot services and adding the necessary EFI drivers
to the EFI uclass (see directory lib/efi_driver/).

Best regards

Heinrich

> + *
>   * @return 0 if OK, -ve on error (in which case it prints a message)
>   */
>  static efi_status_t efi_init_obj_list(void)
> 

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

Re: [U-Boot] [PATCH 3/3] imx: hab: Convert DCD non-NULL error to warning

[Fabio Estevam]

On Fri, Mar 9, 2018 at 10:07 AM, Bryan O'Donoghue
 wrote:
> commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
> to calling HAB authenticate function.") makes the DCD field being NULL a
> dependency.
>
> This change though will break loading and executing of existing pre-signed
> binaries on a u-boot update i.e. if this change is deployed on a board you
> will be forced to redo all images on that board to NULL out the DCD.
>
> There is no prior guidance from NXP that the DCD must be NULL similarly
> public guidance on usage of the HAB doesn't call out this NULL dependency
> (see boundary devices link).
>
> Since later SoCs will reject a non-NULL DCD there's no reason to make a
> NULL DCD a requirement, however if there is an actual dependency for later
> SoCs the appropriate fix would be to do SoC version checking.
>
> Earlier SoCs are capable (and happy) to authenticate images with non-NULL
> DCDs, we should not be forcing this change on downstream users -
> particularly if it means those users now must rewrite their build systems
> and/or redeploy signed images in the field.
>
> Fixes: 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
> to calling HAB authenticate function.")
>
> Signed-off-by: Bryan O'Donoghue 
> Cc: Utkarsh Gupta 
> Cc: Breno Lima 
> Cc: Fabio Estevam 
> Link: https://boundarydevices.com/high-assurance-boot-hab-dummies

In order to avoid regression, better apply this one for v2018.03:

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

Re: [U-Boot] [PATCH 3/3] imx: hab: Convert DCD non-NULL error to warning

[Fabio Estevam]

Hi Tom and Stefano,

On Mon, Mar 12, 2018 at 1:07 PM, Tom Rini  wrote:

>> Anyway, I am facing what we should do with this patch for 2018.03. As I
>> said, I am not forcing anyone and I have just picked up 1/3 and 2/3. But
>> IMHO, if there are not good reason to say that not raising an error
>> breaks a lot of supplied device, this should flow into 2018.03, too. And
>> then we get enough time to better explore this issue.
>
> And I need an answer to this final part, before I can release v2018.03.
> Thanks all!

Bryan's points are valid, so please apply his patch for v2018.03.

Breno and team can then revisit this for v2018.05.

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

Re: [U-Boot] [PATCH 5/5] efi_selftest: unit test for event groups

[Alexander Graf]

On 12.03.18 18:59, Heinrich Schuchardt wrote:
> On 02/18/2018 03:17 PM, Heinrich Schuchardt wrote:
>> Supply a unit test for event groups.
>>
>> Create multiple events in an event group. Signal each event once and check
>> that all events are notified once in each round.
>>
>> Signed-off-by: Heinrich Schuchardt 
> 
> Hello Alex,
> 
> you merged patch 1-4 of this series. Is there a problem with this patch
> providing a unit test?

Not at all, it probably just slipped through :)


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

Re: [U-Boot] [PATCH 3/3] imx: hab: Convert DCD non-NULL error to warning

[Bryan O'Donoghue]

On 12/03/18 16:33, Breno Matheus Lima wrote:


The purpose of hab_rvt_authenticate_image() API function is to
authenticate additional boot images in a post-ROM stage, initial boot
images are supposed to be authenticate only once by the initial ROM
code. The HAB implementation in older devices will process and run DCD
if we provide a DCD pointer. DCD commands are supposed to be executed
only once in an early boot stage,



Breno if that is so, why is there a ROM provided callback "run_dcd" ?

3.4
hab_status_t(* hab_rvt::run_dcd)(const uint8_t *dcd)

It may be the case that you are moving to the DCD being a bootrom only 
interface but that is certainly not the case right now.



re-executing it could lead to an
incorrect authentication boot flow. 


Which is the difference between "the DCD" i.e. the only DCD that can run 
and "a DCD" - meaning the DCD associated with an image.


You've provided APIs to run a DCD, make extensive reference to running 
'a DCD' with a given image.


How can you be so sure that all users of u-boot HAB don't have a DCD 
phase with images after the first phase ?



If we convert DCD non-NULL error
to warning may also break supported devices, not only the new ones.


Which ones ? Can you give some details to back this up ?



We understand Bryan's point based in CST documentation but
unfortunately our documentation is outdated, we are currently working
in a new version.


But Breno - until and unless you publish something that super-cedes the 
current published standard - you are introducing breakage into the 
current HAB layer.


IMO the right thing to do is to publish a description the issue you are 
trying to address, then discuss fixes for it.




As Utkarsh mentioned in commit 8c4037a09a5c ("imx: hab: Ensure the IVT
DCD pointer is Null prior to calling HAB authenticate function."):



"DCD commands should only be present in the initial boot image loaded
by the SoC ROM.


Which is an assertion you are making now, without reference to any 
supporting litreature and proposing that everybody using the HAB 
interface just adopts this change and churns their downstream images.




DCD should not be present in images that will be
verified by software using HAB RVT authentication APIs.


Not according to your latest published standard on HAB. Can you really 
prove that nobody is using DCD specifically "run_dcd()" as provided by 
your own BootROM at this time ?


On what basis are you forcing end-users to rewrite their code-signing 
infrastructure and re-sign all of their binaries - potentially binaries 
in the field ?


I really can't agree with this approach. If you want to force such a 
change on people - you need a reason.


Consider a user with an i.MX6 board who wants to pick up a fix for an 
unrelated issue - USB for agrgument's sake. They then need to re-sign 
all of the binaries u-boot authenticates via HAB for no benefit to that 
user at all.



Newer versions
of HAB will generate an error if a DCD pointer is present in an image
being authenticated by calling the HAB RVT API. 


Then version check it ! Why do existing users need to suck up the change 
for upcoming (unrleased?) HAB implementations ?



Older versions of HAB
will process and run DCD if it is present, and this could lead to an
incorrect authentication boot flow."


Sorry I really don't accept this - you provide a _callback_ called 
"run_dcd()" in your BootROM.


Meaning I provide a pointer to a signed image that includes a DCD phase. 
I can then run the DCD in isolation.


Why is that now broken on older HAB implementations ?

Honestly - I think this change is pretty bogus - we should either revert 
it or as I've proposed her "Warn".


You can then come along and version check on later SoCs once you've 
published _supporting_documentation_ to go with it - that justifies and 
explains (in detail) why it is necessary to restrict this interface on 
new (or existing SoCs).


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

[U-Boot] [PATCH 1/1] efi_selftest: fix device tree unit test

[Heinrich Schuchardt]

Include libfdt.h was moved by commit b08c8c487083 ("libfdt: move headers to
 and ")

Fixes: e236200c7fa6 ("efi_selftest: check installation of the
   device tree")
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/efi_selftest_fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_selftest/efi_selftest_fdt.c 
b/lib/efi_selftest/efi_selftest_fdt.c
index 24db0dcf7d5..e5a8d6a6ae5 100644
--- a/lib/efi_selftest/efi_selftest_fdt.c
+++ b/lib/efi_selftest/efi_selftest_fdt.c
@@ -12,7 +12,7 @@
  */
 
 #include 
-#include 
+#include 
 
 static struct efi_boot_services *boottime;
 static const char *fdt;
-- 
2.16.1

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

Re: [U-Boot] [PATCH 5/5] efi_selftest: unit test for event groups

[Heinrich Schuchardt]

On 02/18/2018 03:17 PM, Heinrich Schuchardt wrote:
> Supply a unit test for event groups.
> 
> Create multiple events in an event group. Signal each event once and check
> that all events are notified once in each round.
> 
> Signed-off-by: Heinrich Schuchardt 

Hello Alex,

you merged patch 1-4 of this series. Is there a problem with this patch
providing a unit test?

Regards

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

Re: [U-Boot] [PATCH v2 00/10] splash screen on the stm32f769 disco board

[Patrice CHOTARD]

Hi Vikas

On 03/06/2018 08:44 PM, Vikas Manocha wrote:
> Hi Patrice/Yannick,
> 
> On 03/05/2018 11:50 PM, Patrice CHOTARD wrote:
>>> There seems to be a dependency on patch for 
>>> include/dt-bindings/mfd/stm32f7-rcc.h
>>> adding some new macros. Is it also submitted to the list?
>> Right, needed patches are already on the list
>> http://patchwork.ozlabs.org/patch/870938/
> 
> Great addition !
> 
> Few points:
> it seems above mentioned patchset also has dependency on another patchset 
> http://patchwork.ozlabs.org/patch/870283/
> After applying these two dependency patchsets, it creates conflicts with 
> pathch "ARM: dts: stm32: Add timer support for STM32F7".
> I understand you want to get it reviewed without waiting for other patchset 
> acceptance, it would be good to mention all the dependencies.
> 
> Also i observe that without applying f769 display patches, f746 display 
> didn't work.
> And F769 board display is not working, i see one error log:
> 
> Board 1:
> stm32_ltdc_probe: decode display timing error -4
> & Board 2:
> stm32_ltdc_probe: decode display timing error -668998023
> 
> Cheers,
> Vikas
> 
>>
>> Patrice
>>


We got a look at this issue with Yannick.

On my side, i got this problem because i used the 
stm32f746-disco_defconfig by updating CONFIG_DEFAULT_DEVICE_TREE with 
the following update, (and i suppose you do the same ;-) ):

CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco"

By using the stm32f769-disco_defconfig, everything is working fine.
That's why Yannick added a dedicated defconfig file for STM32F769.

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

Re: [U-Boot] [PATCH 0/4] common: move startup function prototypes in init.h

[Patrick DELAUNAY]

Hi Tom,

> From: Tom Rini [mailto:tr...@konsulko.com]
> 
> > It is a step for common.h cleanup and I don't add documentation for
> > the moved functions.
> 
> Can you add a 5/4 that merges init_helpers.h into this new init.h file?
> There's just one prototype.  Thanks!

Ok, I will this in a v2 of the the patchset.

> --
> Tom

Patrick

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

Re: [U-Boot] [PATCH 3/3] imx: hab: Convert DCD non-NULL error to warning

[Breno Matheus Lima]

Hi All,

2018-03-12 13:07 GMT-03:00 Tom Rini :
> On Sun, Mar 11, 2018 at 03:36:16PM +0100, Stefano Babic wrote:
>> Hi Everybody,
>>
>> I have applied 1-2 as Fabio suggested. I have a couple of comments for
>> this, too:
>>
>> On 10/03/2018 02:10, Breno Matheus Lima wrote:
>> > Hi Bryan,
>> >
>> > 2018-03-09 10:07 GMT-03:00 Bryan O'Donoghue :
>> >> commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
>> >> to calling HAB authenticate function.") makes the DCD field being NULL a
>> >> dependency.
>> >>
>> >> This change though will break loading and executing of existing pre-signed
>> >> binaries on a u-boot update i.e. if this change is deployed on a board you
>> >> will be forced to redo all images on that board to NULL out the DCD.
>> >>
>> >> There is no prior guidance from NXP that the DCD must be NULL similarly
>> >> public guidance on usage of the HAB doesn't call out this NULL dependency
>> >> (see boundary devices link).
>> >>
>> >> Since later SoCs will reject a non-NULL DCD there's no reason to make a
>> >> NULL DCD a requirement, however if there is an actual dependency for later
>> >> SoCs the appropriate fix would be to do SoC version checking.
>> >>
>> >> Earlier SoCs are capable (and happy) to authenticate images with non-NULL
>> >> DCDs, we should not be forcing this change on downstream users -
>> >> particularly if it means those users now must rewrite their build systems
>> >> and/or redeploy signed images in the field.
>> >>
>> >> Fixes: 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
>> >> to calling HAB authenticate function.")
>> >
>> > We understand the concern being raised however would prefer to leave
>> > this as an error, and selected users relying on images with DCD
>> > pointers can modify the code accordingly. This does not just apply to
>> > new SoC’s but also applies to existing SoC’s.
>>
>> Anyway, this is not so easy to identify. What we current know is that
>> older SOCs have no problem if the pointer is not set to Null. I agree
>> with Brian that if some constraint is coming, it should be defined with
>> a version checking as we currently do for a lot of things (is_soc() to
>> be clear).
>>
>> I am quite lost because I do not know which SOCs are affected and which
>> not. What does it hide under "later SOCSs" ? Or better which new version
>> of HAB ? I know HAB was updated due to other issues - are the
>> corresponding SOC involved ?
>>
>> If a not-null DCD pointer affects just future SOCs, we should fix it
>> when these SOCs will be available. This means both new SOSs (imx8x) as
>> new version of supported SOCs (mx5 / mx6 / mx7).
>>
>> > Users performing such an
>> > update should definitely test the image prior to making an OTA
>> > available.
>>
>> I think this is another topic and not what Brian is trying to address. I
>> hope as you that *any* update is tested before deploying. But this is
>> unrelated.
>>
>> > It has never been intended for DCD to be used in any post
>> > boot image and we realize the lack of documentation is a hindsight by
>> > us, and we are currently addressing that with updated guidance.
>> >
>>
>> ok, thanks for this, very appreciated.
>>
>> Anyway, I am facing what we should do with this patch for 2018.03. As I
>> said, I am not forcing anyone and I have just picked up 1/3 and 2/3. But
>> IMHO, if there are not good reason to say that not raising an error
>> breaks a lot of supplied device, this should flow into 2018.03, too. And
>> then we get enough time to better explore this issue.
>
> And I need an answer to this final part, before I can release v2018.03.
> Thanks all!
>

The purpose of hab_rvt_authenticate_image() API function is to
authenticate additional boot images in a post-ROM stage, initial boot
images are supposed to be authenticate only once by the initial ROM
code. The HAB implementation in older devices will process and run DCD
if we provide a DCD pointer. DCD commands are supposed to be executed
only once in an early boot stage, re-executing it could lead to an
incorrect authentication boot flow. If we convert DCD non-NULL error
to warning may also break supported devices, not only the new ones.

We understand Bryan's point based in CST documentation but
unfortunately our documentation is outdated, we are currently working
in a new version.

As Utkarsh mentioned in commit 8c4037a09a5c ("imx: hab: Ensure the IVT
DCD pointer is Null prior to calling HAB authenticate function."):
"DCD commands should only be present in the initial boot image loaded
by the SoC ROM. DCD should not be present in images that will be
verified by software using HAB RVT authentication APIs. Newer versions
of HAB will generate an error if a DCD pointer is present in an image
being authenticated by calling the HAB RVT API. Older versions of HAB
will process and run DCD if it is present, and this could lead to an
incorrect authentication boot flow."

Thanks,
Breno Lima

Re: [U-Boot] [PATCH 3/3] imx: hab: Convert DCD non-NULL error to warning

[Tom Rini]

On Sun, Mar 11, 2018 at 03:36:16PM +0100, Stefano Babic wrote:
> Hi Everybody,
> 
> I have applied 1-2 as Fabio suggested. I have a couple of comments for
> this, too:
> 
> On 10/03/2018 02:10, Breno Matheus Lima wrote:
> > Hi Bryan,
> > 
> > 2018-03-09 10:07 GMT-03:00 Bryan O'Donoghue :
> >> commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
> >> to calling HAB authenticate function.") makes the DCD field being NULL a
> >> dependency.
> >>
> >> This change though will break loading and executing of existing pre-signed
> >> binaries on a u-boot update i.e. if this change is deployed on a board you
> >> will be forced to redo all images on that board to NULL out the DCD.
> >>
> >> There is no prior guidance from NXP that the DCD must be NULL similarly
> >> public guidance on usage of the HAB doesn't call out this NULL dependency
> >> (see boundary devices link).
> >>
> >> Since later SoCs will reject a non-NULL DCD there's no reason to make a
> >> NULL DCD a requirement, however if there is an actual dependency for later
> >> SoCs the appropriate fix would be to do SoC version checking.
> >>
> >> Earlier SoCs are capable (and happy) to authenticate images with non-NULL
> >> DCDs, we should not be forcing this change on downstream users -
> >> particularly if it means those users now must rewrite their build systems
> >> and/or redeploy signed images in the field.
> >>
> >> Fixes: 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
> >> to calling HAB authenticate function.")
> > 
> > We understand the concern being raised however would prefer to leave
> > this as an error, and selected users relying on images with DCD
> > pointers can modify the code accordingly. This does not just apply to
> > new SoC’s but also applies to existing SoC’s.
> 
> Anyway, this is not so easy to identify. What we current know is that
> older SOCs have no problem if the pointer is not set to Null. I agree
> with Brian that if some constraint is coming, it should be defined with
> a version checking as we currently do for a lot of things (is_soc() to
> be clear).
> 
> I am quite lost because I do not know which SOCs are affected and which
> not. What does it hide under "later SOCSs" ? Or better which new version
> of HAB ? I know HAB was updated due to other issues - are the
> corresponding SOC involved ?
> 
> If a not-null DCD pointer affects just future SOCs, we should fix it
> when these SOCs will be available. This means both new SOSs (imx8x) as
> new version of supported SOCs (mx5 / mx6 / mx7).
> 
> > Users performing such an
> > update should definitely test the image prior to making an OTA
> > available.
> 
> I think this is another topic and not what Brian is trying to address. I
> hope as you that *any* update is tested before deploying. But this is
> unrelated.
> 
> > It has never been intended for DCD to be used in any post
> > boot image and we realize the lack of documentation is a hindsight by
> > us, and we are currently addressing that with updated guidance.
> > 
> 
> ok, thanks for this, very appreciated.
> 
> Anyway, I am facing what we should do with this patch for 2018.03. As I
> said, I am not forcing anyone and I have just picked up 1/3 and 2/3. But
> IMHO, if there are not good reason to say that not raising an error
> breaks a lot of supplied device, this should flow into 2018.03, too. And
> then we get enough time to better explore this issue.

And I need an answer to this final part, before I can release v2018.03.
Thanks all!

-- 
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] iminfo and zImages

[Tom Rini]

On Mon, Mar 12, 2018 at 02:03:54PM +, Andy Rea wrote:

> Is it just not possible for the zImages in RAM to be decoded as per the
> uImages ?

Well, in short, "patches welcome".  Part of the problem is that the
Linux Kernel ARM zImage doesn't contain a ton of info.  That's less true
of say the aarch64 Image format.  And both of these are architecture
specific.  If you can come up with a patch that does something useful
for iminfo for zImage, I don't see a problem in theory with that.
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 0/4] common: move startup function prototypes in init.h

[Tom Rini]

On Mon, Mar 12, 2018 at 09:47:15AM +0100, Patrick Delaunay wrote:

> 
> I push this serie after Masahiro Yamada's comment
> on patch "common: add a prototype for mach_cpu_init()"
> 
> The serie depends on v3 of this patch for the added
> file init.h
> 
> I just moved the function used in:
>  common/board_f.c
>  common/init/board_init.c
>  common/board_r.c
>  common/board_info.c
> and solve the checkpatch issue.
> 
> It is a step for common.h cleanup and I don't add
> documentation for the moved functions.
> 
> I don't know if other functions need to be moved:
>   $(BOARD)/$(BOARD).c ?
>   $(CPU)/start.S ?
> 
> or if the order of the new file init.h is correct.

Can you add a 5/4 that merges init_helpers.h into this new init.h file?
There's just one prototype.  Thanks!

-- 
Tom


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

[U-Boot] iminfo and zImages

[Andy Rea]

Is it just not possible for the zImages in RAM to be decoded as per the
uImages ?

 

If I simply use mkimage to convert the image back as a uImage ( essentially
take off the first 64 bytes ? ) then iminfo will display the kernel info

 

The uImage file is only 64 bytes smaller so hasn't fundamentally been
uncompressed but also offsetting the iminfo by the 64 bytes makes no odds
either

 

Did I miss the point somewhere?!

 

 

 

 

=> tftp 8200 uImage

done

Bytes transferred = 7954944 (796200 hex)

=> iminfo

 

## Checking Image at 8200 ...

   Legacy image found

   Image Name:   Linux kernel

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:7954880 Bytes = 7.6 MiB

   Load Address: 8200

   Entry Point:  8200

   Verifying Checksum ... OK

 

=> tftp 8200 zImage

done

Bytes transferred = 7954880 (7961c0 hex)

## Checking Image at 8200 ...

Unknown image format!

=> iminfo 8240

 

## Checking Image at 8240 ...

Unknown image format!

=>

 



smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v1 1/2] rockchip: pinctrl: rk3399: fix GPIO2B1 and GPIO2B2 shift value

[Klaus Goger]

From: Philipp Tomsich 

The shift values for GPIO2B1 and GPIO2B2 had in fact referred to
GPIO2B0 and GPIO2B1, respectively.  This substitutes the correct
values.

Signed-off-by: Philipp Tomsich 
Signed-off-by: Klaus Goger 
---

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index b541e2caa1..fbcec932b4 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -325,10 +325,10 @@ check_member(rk3399_pmusgrf_regs, slv_secure_con4, 
0xe3d4);
 
 enum {
/* GRF_GPIO2B_IOMUX */
-   GRF_GPIO2B1_SEL_SHIFT   = 0,
+   GRF_GPIO2B1_SEL_SHIFT   = 2,
GRF_GPIO2B1_SEL_MASK= 3 << GRF_GPIO2B1_SEL_SHIFT,
GRF_SPI2TPM_RXD = 1,
-   GRF_GPIO2B2_SEL_SHIFT   = 2,
+   GRF_GPIO2B2_SEL_SHIFT   = 4,
GRF_GPIO2B2_SEL_MASK= 3 << GRF_GPIO2B2_SEL_SHIFT,
GRF_SPI2TPM_TXD = 1,
GRF_GPIO2B3_SEL_SHIFT   = 6,
-- 
2.11.0

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

[U-Boot] [PATCH v1 2/2] rockchip: pinctrl: rk3399: add support for I2C[123467]

[Klaus Goger]

From: Philipp Tomsich 

This adds support for the (to date unsupported) I2C controllers 1~4
and 6~7 (i.e. now all controllers except I2C5, which is not accessible
on the RK3399-Q7, are supported by pinctrl).

Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 

Signed-off-by: Klaus Goger 
---

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 30 
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 61 ++---
 2 files changed, 85 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index fbcec932b4..91e8d2d216 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -324,13 +324,29 @@ struct rk3399_pmusgrf_regs {
 check_member(rk3399_pmusgrf_regs, slv_secure_con4, 0xe3d4);
 
 enum {
+   /* GRF_GPIO2A_IOMUX */
+   GRF_GPIO2A0_SEL_SHIFT   = 0,
+   GRF_GPIO2A0_SEL_MASK= 3 << GRF_GPIO2A0_SEL_SHIFT,
+   GRF_I2C2_SDA= 2,
+   GRF_GPIO2A1_SEL_SHIFT   = 2,
+   GRF_GPIO2A1_SEL_MASK= 3 << GRF_GPIO2A1_SEL_SHIFT,
+   GRF_I2C2_SCL= 2,
+   GRF_GPIO2A7_SEL_SHIFT   = 14,
+   GRF_GPIO2A7_SEL_MASK= 3 << GRF_GPIO2A7_SEL_SHIFT,
+   GRF_I2C7_SDA= 2,
+
/* GRF_GPIO2B_IOMUX */
+   GRF_GPIO2B0_SEL_SHIFT   = 0,
+   GRF_GPIO2B0_SEL_MASK= 3 << GRF_GPIO2B0_SEL_SHIFT,
+   GRF_I2C7_SCL= 2,
GRF_GPIO2B1_SEL_SHIFT   = 2,
GRF_GPIO2B1_SEL_MASK= 3 << GRF_GPIO2B1_SEL_SHIFT,
GRF_SPI2TPM_RXD = 1,
+   GRF_I2C6_SDA= 2,
GRF_GPIO2B2_SEL_SHIFT   = 4,
GRF_GPIO2B2_SEL_MASK= 3 << GRF_GPIO2B2_SEL_SHIFT,
GRF_SPI2TPM_TXD = 1,
+   GRF_I2C6_SCL= 2,
GRF_GPIO2B3_SEL_SHIFT   = 6,
GRF_GPIO2B3_SEL_MASK= 3 << GRF_GPIO2B3_SEL_SHIFT,
GRF_SPI2TPM_CLK = 1,
@@ -414,6 +430,14 @@ enum {
GRF_GPIO3C1_SEL_MASK= 3 << GRF_GPIO3C1_SEL_SHIFT,
GRF_MAC_TXCLK   = 1,
 
+   /* GRF_GPIO4A_IOMUX */
+   GRF_GPIO4A1_SEL_SHIFT   = 2,
+   GRF_GPIO4A1_SEL_MASK= 3 << GRF_GPIO4A1_SEL_SHIFT,
+   GRF_I2C1_SDA= 1,
+   GRF_GPIO4A2_SEL_SHIFT   = 4,
+   GRF_GPIO4A2_SEL_MASK= 3 << GRF_GPIO4A2_SEL_SHIFT,
+   GRF_I2C1_SCL= 1,
+
/* GRF_GPIO4B_IOMUX */
GRF_GPIO4B0_SEL_SHIFT   = 0,
GRF_GPIO4B0_SEL_MASK= 3 << GRF_GPIO4B0_SEL_SHIFT,
@@ -575,6 +599,12 @@ enum {
PMUGRF_GPIO1B2_SEL_SHIFT= 4,
PMUGRF_GPIO1B2_SEL_MASK = 3 << PMUGRF_GPIO1B2_SEL_SHIFT,
PMUGRF_SPI1EC_CSN0  = 2,
+   PMUGRF_GPIO1B3_SEL_SHIFT= 6,
+   PMUGRF_GPIO1B3_SEL_MASK = 3 << PMUGRF_GPIO1B3_SEL_SHIFT,
+   PMUGRF_I2C4_SDA = 1,
+   PMUGRF_GPIO1B4_SEL_SHIFT= 8,
+   PMUGRF_GPIO1B4_SEL_MASK = 3 << PMUGRF_GPIO1B4_SEL_SHIFT,
+   PMUGRF_I2C4_SCL = 1,
PMUGRF_GPIO1B6_SEL_SHIFT= 12,
PMUGRF_GPIO1B6_SEL_MASK = 3 << PMUGRF_GPIO1B6_SEL_SHIFT,
PMUGRF_PWM_3B   = 1,
diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3399.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
index 19a7415522..c7052257aa 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
@@ -70,6 +70,60 @@ static void pinctrl_rk3399_i2c_config(struct rk3399_grf_regs 
*grf,
 PMUGRF_GPIO1C0_SEL_MASK,
 PMUGRF_I2C0PMU_SCL << PMUGRF_GPIO1C0_SEL_SHIFT);
break;
+
+   case PERIPH_ID_I2C1:
+   rk_clrsetreg(>gpio4a_iomux,
+GRF_GPIO4A1_SEL_MASK,
+GRF_I2C1_SDA << GRF_GPIO4A1_SEL_SHIFT);
+   rk_clrsetreg(>gpio4a_iomux,
+GRF_GPIO4A2_SEL_MASK,
+GRF_I2C1_SCL << GRF_GPIO4A2_SEL_SHIFT);
+   break;
+
+   case PERIPH_ID_I2C2:
+   rk_clrsetreg(>gpio2a_iomux,
+GRF_GPIO2A0_SEL_MASK,
+GRF_I2C2_SDA << GRF_GPIO2A0_SEL_SHIFT);
+   rk_clrsetreg(>gpio2a_iomux,
+GRF_GPIO2A1_SEL_MASK,
+GRF_I2C2_SCL << GRF_GPIO2A1_SEL_SHIFT);
+   break;
+   case PERIPH_ID_I2C3:
+   rk_clrsetreg(>gpio4c_iomux,
+GRF_GPIO4C0_SEL_MASK,
+GRF_HDMII2C_SCL << GRF_GPIO4C0_SEL_SHIFT);
+   rk_clrsetreg(>gpio4c_iomux,
+GRF_GPIO4C1_SEL_MASK,
+GRF_HDMII2C_SDA << GRF_GPIO4C1_SEL_SHIFT);
+   break;
+
+   case PERIPH_ID_I2C4:
+   rk_clrsetreg(>gpio1b_iomux,
+   

[U-Boot] [PATCH v1 0/2] Add pinctrl support for RK3399 I2C[123467]

[Klaus Goger]

This patch series adds support for the I2C controller 1-4 and 6-7


Philipp Tomsich (2):
  rockchip: pinctrl: rk3399: fix GPIO2B1 and GPIO2B2 shift value
  rockchip: pinctrl: rk3399: add support for I2C[123467]

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 34 +-
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 61 ++---
 2 files changed, 87 insertions(+), 8 deletions(-)

-- 
2.11.0

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

[U-Boot] [PATCH v2] core: ofnode: Fix translation for #size-cells == 0

[Mario Six]

Commit 286ede6 ("drivers: core: Add translation in live tree case") made
dev_get_addr always use proper bus translations for addresses read from
the device tree. But this leads to problems with certain busses, e.g.
I2C busses, which run into an error during translation, and hence stop
working.

It turns out that of_translate_address() and fdt_translate_address()
stop the address translation with an error when they're asked to
translate addresses for busses where #size-cells == 0 (comment from
drivers/core/of_addr.c):

 * Note: We consider that crossing any level with #size-cells == 0 to mean
 * that translation is impossible (that is we are not dealing with a value
 * that can be mapped to a cpu physical address). This is not really specified
 * that way, but this is traditionally the way IBM at least do things

To fix this case, we check in both the live-tree and non-live tree-case,
whether the bus of the device whose address is about to be translated
has size-cell size zero. If this is the case, we just read the address
as a plain integer and return it, and only apply bus translations if the
size-cell size if greater than zero.

Signed-off-by: Mario Six 
Signed-off-by: Martin Fuzzey 
Reported-by: Martin Fuzzey 
Fixes: 286ede6 ("drivers: core: Add translation in live tree case")
---

v1 -> v2:
* Add unit tests for address translation as suggested by Simon Glass

---
 arch/sandbox/dts/test.dts | 48 +++
 drivers/core/fdtaddr.c| 17 +++--
 drivers/core/ofnode.c |  5 -
 include/dm/uclass-id.h|  1 +
 test/dm/test-fdt.c| 43 ++
 5 files changed, 107 insertions(+), 7 deletions(-)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index b0f0ca8f19..06d0e8ce85 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -27,6 +27,10 @@
testfdt3 = "/b-test";
testfdt5 = "/some-bus/c-test@5";
testfdt8 = "/a-test";
+   fdt_dummy0 = "/translation-test@8000/dev@0,0";
+   fdt_dummy1 = "/translation-test@8000/dev@1,100";
+   fdt_dummy2 = "/translation-test@8000/dev@2,200";
+   fdt_dummy3 = "/translation-test@8000/noxlatebus@3,300/dev@42";
usb0 = _0;
usb1 = _1;
usb2 = _2;
@@ -487,6 +491,50 @@
reg = <9 1>;
};
};
+
+   translation-test@8000 {
+   compatible = "simple-bus";
+   reg = <0x8000 0x4000>;
+
+   #address-cells = <0x2>;
+   #size-cells = <0x1>;
+
+   ranges = <0 0x0 0x8000 0x1000
+ 1 0x100 0x9000 0x1000
+ 2 0x200 0xA000 0x1000
+ 3 0x300 0xB000 0x1000
+>;
+
+   dev@0,0 {
+   compatible = "denx,u-boot-fdt-dummy";
+   reg = <0 0x0 0x1000>;
+   };
+
+   dev@1,100 {
+   compatible = "denx,u-boot-fdt-dummy";
+   reg = <1 0x100 0x1000>;
+
+   };
+
+   dev@2,200 {
+   compatible = "denx,u-boot-fdt-dummy";
+   reg = <2 0x200 0x1000>;
+   };
+
+
+   noxlatebus@3,300 {
+   compatible = "simple-bus";
+   reg = <3 0x300 0x1000>;
+
+   #address-cells = <0x1>;
+   #size-cells = <0x0>;
+
+   dev@42 {
+   compatible = "denx,u-boot-fdt-dummy";
+   reg = <0x42>;
+   };
+   };
+   };
 };

 #include "sandbox_pmic.dtsi"
diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index 3847dd836e..9a3b4c312a 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -49,12 +49,17 @@ fdt_addr_t devfdt_get_addr_index(struct udevice *dev, int 
index)

reg += index * (na + ns);

-   /*
-* Use the full-fledged translate function for complex
-* bus setups.
-*/
-   addr = fdt_translate_address((void *)gd->fdt_blob,
-dev_of_offset(dev), reg);
+   if (ns) {
+   /*
+* Use the full-fledged translate function for complex
+* bus setups.
+*/
+   addr = fdt_translate_address((void *)gd->fdt_blob,
+dev_of_offset(dev), reg);
+   } else {
+   /* Non translatable if #size-cells == 0 */
+   addr = fdt_read_number(reg, na);
+   }
} else 

Re: [U-Boot] [PATCH 3/3] imx: hab: Convert DCD non-NULL error to warning

[Bryan O'Donoghue]

On 10/03/18 01:10, Breno Matheus Lima wrote:

Hi Bryan,

2018-03-09 10:07 GMT-03:00 Bryan O'Donoghue :

commit 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
to calling HAB authenticate function.") makes the DCD field being NULL a
dependency.

This change though will break loading and executing of existing pre-signed
binaries on a u-boot update i.e. if this change is deployed on a board you
will be forced to redo all images on that board to NULL out the DCD.

There is no prior guidance from NXP that the DCD must be NULL similarly
public guidance on usage of the HAB doesn't call out this NULL dependency
(see boundary devices link).

Since later SoCs will reject a non-NULL DCD there's no reason to make a
NULL DCD a requirement, however if there is an actual dependency for later
SoCs the appropriate fix would be to do SoC version checking.

Earlier SoCs are capable (and happy) to authenticate images with non-NULL
DCDs, we should not be forcing this change on downstream users -
particularly if it means those users now must rewrite their build systems
and/or redeploy signed images in the field.

Fixes: 8c4037a09a5c ("imx: hab: Ensure the IVT DCD pointer is Null prior
to calling HAB authenticate function.")


It has never been intended for DCD to be used in any post
boot image 


Breno,

There's extensive documentation from NXP in the CST docs detailing usage 
of the DCD by post 1st-stage images.


High Assurance Boot Version 4 Application Programming Interface 
Reference Manual version 2.3.2 section "3.3 Authenticate Image"


"Purpose:
This function combines _DCD_, CSF and Assert functions in a standard 
sequence in order to authenticate a loaded image. It is intended for use 
by post-ROM boot stage components, via the ROM Vector Table. Support for 
images partially loaded to an initial location is provided

via a callback function"



"Postconditions:
The post-conditions of the functions hab_rvt.check_target(), 
_hab_rvt.run_dcd()_,hab_rvt.run_csf() and hab_rvt.assert() apply also to 
this function. In particular, any audit events logged within the given 
functions have the context field appropriate to that function rather 
than HAB_CTX_AUTHENTICATE. In addition, the side-effects and 
post-conditions of any callback function supplied apply."


More than that - there's even a BootROM API callback "section 3.4 Run DCD"

"3.4
Run DCD

hab_status_t(* hab_rvt::run_dcd)(const uint8_t *dcd)
Execute boot configuration script.

Purpose:
This function configures the IC based upon a Device Configuration Data 
table. It is intended for use by post-ROM boot stage components, via the 
ROM Vector Table.


This function may be invoked as often as required for each boot stage.
The difference between the configuration functionality in this function 
and hab_rvt.run_csf() arises because the Device Configuration Data table 
is not authenticated prior to running the commands. Hence, there is a 
more limited range of commands allowed, and a limited range of 
parameters to allowed commands."


I don't think its reasonable to go forcing people to NULL out the DCD 
(which is work for them - and forces a OTA updates) - let alone reading 
the docs now - people might even be _doing_ DCD things right now.


There's even a callback that allows you to run the DCD from u-boot !

By all means restrict on a per-SoC basis but that should be version 
checked and justified - particularly if there is a derogation from the 
official documentation that comes with the code-signing tools.


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

Re: [U-Boot] [PATCH v3 02/11] efi_loader: return efi_status_t from efi_gop_register

[Alexander Graf]

On 03/12/2018 01:07 PM, Alexander Graf wrote:

On 03/03/2018 03:28 PM, Heinrich Schuchardt wrote:

All initialization routines should return a status code instead of
a boolean.

Signed-off-by: Heinrich Schuchardt 
---
v3
no change
v2
new patch
---
  include/efi_loader.h |  2 +-
  lib/efi_loader/efi_gop.c | 34 ++
  2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 72c83fd503..779b8bde2e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -179,7 +179,7 @@ int efi_disk_create_partitions(efi_handle_t 
parent, struct blk_desc *desc,

 const char *if_typename, int diskid,
 const char *pdevname);
  /* Called by bootefi to make GOP (graphical) interface available */
-int efi_gop_register(void);
+efi_status_t 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 */
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 3caddd5f84..91b0b6a064 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -125,8 +125,13 @@ efi_status_t EFIAPI gop_blt(struct efi_gop 
*this, void *buffer,

  return EFI_EXIT(EFI_SUCCESS);
  }
  -/* This gets called from do_bootefi_exec(). */
-int efi_gop_register(void)
+/*
+ * Install graphical output protocol.
+ *
+ * If no supported video device exists this is not considered as an
+ * error.
+ */
+efi_status_t efi_gop_register(void)
  {
  struct efi_gop_obj *gopobj;
  u32 bpix, col, row;
@@ -136,12 +141,15 @@ int efi_gop_register(void)
#ifdef CONFIG_DM_VIDEO
  struct udevice *vdev;
+struct video_priv *priv;
/* We only support a single video output device for now */
-if (uclass_first_device(UCLASS_VIDEO, ) || !vdev)
-return -1;
+if (uclass_first_device(UCLASS_VIDEO, ) || !vdev) {
+printf("WARNING: No video device\n");


I don't think we should emit a warning, just because someone enabled 
support for DM_VIDEO but doesn't have any device backing it. Imagine 
for example a cross-board U-Boot binary that adapts its device tree 
based on the board it finds. On some, it may use video output, on 
others it might not. Then we would emit a warning here for no good 
reason.



+return EFI_SUCCESS;
+}
  -struct video_priv *priv = dev_get_uclass_priv(vdev);
+priv = dev_get_uclass_priv(vdev);
  bpix = priv->bpix;
  col = video_get_xsize(vdev);
  row = video_get_ysize(vdev);
@@ -170,13 +178,14 @@ int efi_gop_register(void)
  break;
  default:
  /* So far, we only work in 16 or 32 bit mode */
-return -1;
+printf("WARNING: Unsupported video mode\n");


Same here. Maybe convert into debug() prints?


I've just applied it with those prints converted to debug() calls now.


Alex

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

Re: [U-Boot] [PATCH v3 02/11] efi_loader: return efi_status_t from efi_gop_register

[Alexander Graf]

On 03/03/2018 03:28 PM, Heinrich Schuchardt wrote:

All initialization routines should return a status code instead of
a boolean.

Signed-off-by: Heinrich Schuchardt 
---
v3
no change
v2
new patch
---
  include/efi_loader.h |  2 +-
  lib/efi_loader/efi_gop.c | 34 ++
  2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 72c83fd503..779b8bde2e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -179,7 +179,7 @@ int efi_disk_create_partitions(efi_handle_t parent, struct 
blk_desc *desc,
   const char *if_typename, int diskid,
   const char *pdevname);
  /* Called by bootefi to make GOP (graphical) interface available */
-int efi_gop_register(void);
+efi_status_t 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 */
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 3caddd5f84..91b0b6a064 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -125,8 +125,13 @@ efi_status_t EFIAPI gop_blt(struct efi_gop *this, void 
*buffer,
return EFI_EXIT(EFI_SUCCESS);
  }
  
-/* This gets called from do_bootefi_exec(). */

-int efi_gop_register(void)
+/*
+ * Install graphical output protocol.
+ *
+ * If no supported video device exists this is not considered as an
+ * error.
+ */
+efi_status_t efi_gop_register(void)
  {
struct efi_gop_obj *gopobj;
u32 bpix, col, row;
@@ -136,12 +141,15 @@ int efi_gop_register(void)
  
  #ifdef CONFIG_DM_VIDEO

struct udevice *vdev;
+   struct video_priv *priv;
  
  	/* We only support a single video output device for now */

-   if (uclass_first_device(UCLASS_VIDEO, ) || !vdev)
-   return -1;
+   if (uclass_first_device(UCLASS_VIDEO, ) || !vdev) {
+   printf("WARNING: No video device\n");


I don't think we should emit a warning, just because someone enabled 
support for DM_VIDEO but doesn't have any device backing it. Imagine for 
example a cross-board U-Boot binary that adapts its device tree based on 
the board it finds. On some, it may use video output, on others it might 
not. Then we would emit a warning here for no good reason.



+   return EFI_SUCCESS;
+   }
  
-	struct video_priv *priv = dev_get_uclass_priv(vdev);

+   priv = dev_get_uclass_priv(vdev);
bpix = priv->bpix;
col = video_get_xsize(vdev);
row = video_get_ysize(vdev);
@@ -170,13 +178,14 @@ int efi_gop_register(void)
break;
default:
/* So far, we only work in 16 or 32 bit mode */
-   return -1;
+   printf("WARNING: Unsupported video mode\n");


Same here. Maybe convert into debug() prints?


Alex


+   return EFI_SUCCESS;
}
  
  	gopobj = calloc(1, sizeof(*gopobj));

if (!gopobj) {
printf("ERROR: Out of memory\n");
-   return 1;
+   return EFI_OUT_OF_RESOURCES;
}
  
  	/* Hook up to the device list */

@@ -186,8 +195,8 @@ int efi_gop_register(void)
ret = efi_add_protocol(gopobj->parent.handle, _gop_guid,
   >ops);
if (ret != EFI_SUCCESS) {
-   printf("ERROR: Out of memory\n");
-   return 1;
+   printf("ERROR: Failure adding gop protocol\n");
+   return ret;
}
gopobj->ops.query_mode = gop_query_mode;
gopobj->ops.set_mode = gop_set_mode;
@@ -199,10 +208,11 @@ int efi_gop_register(void)
gopobj->mode.info_size = sizeof(gopobj->info);
  
  #ifdef CONFIG_DM_VIDEO

-   if (bpix == VIDEO_BPP32) {
+   if (bpix == VIDEO_BPP32)
  #else
-   if (bpix == LCD_COLOR32) {
+   if (bpix == LCD_COLOR32)
  #endif
+   {
/* With 32bit color space we can directly expose the fb */
gopobj->mode.fb_base = fb_base;
gopobj->mode.fb_size = fb_size;
@@ -217,5 +227,5 @@ int efi_gop_register(void)
gopobj->bpix = bpix;
gopobj->fb = fb;
  
-	return 0;

+   return EFI_SUCCESS;
  }



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

[U-Boot] [PATCH v2 00/15] arm: stm32mp1: add initial support for STM32MP157

[Patrick Delaunay]

This patch-set adds initial support of STMicroelectronics STM32MP157
microprocessor (MPU)
- add new arm arch stm32mp1 (based on armv7)
- support for stm32mp157 SOC (based on Cortex-A7)
- add minimal support for board evaluation board STM32MP157C-ED1

Changes in v2:
 - prototype for mach_cpu_init() removed for the Serie
 - rebase on v2018.03-rc4
 - remove include of "config_distro_defaults.h"

Patrick Delaunay (15):
  tools/mkimage: add support for STM32 image format
  spl: add SPL_RESET_SUPPORT
  arm: armv7: solve issue for timer_rate_hz in arch timer
  dm: gpio: Convert stm32f7 driver to livetree
  gpio: stm32f7_gpio: handle node ngpios
  stm32mp: stm32f7_i2c: use calloc instead of kmalloc
  arm: stm32: add new architecture for STM32MP family
  ram: stm32mp1: add driver
  pmic: add stpmu1 support
  pinctrl: stm32: update pincontrol for stmp32mp157
  reset: stm32: adapt driver for stm32mp1
  clk: add driver for stm32mp1
  clk: stm32mp1: add clock tree initialization
  dts: add device tree for STM32MP157C-ED1 board
  board: st: add generic board for STM32MP1 family

 MAINTAINERS|7 +
 arch/arm/Kconfig   |   25 +-
 arch/arm/Makefile  |1 +
 arch/arm/cpu/armv7/arch_timer.c|   22 +-
 arch/arm/dts/Makefile  |3 +
 arch/arm/dts/stm32mp15-ddr.dtsi|  155 ++
 arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi   |  122 ++
 arch/arm/dts/stm32mp157-u-boot.dtsi|  134 ++
 arch/arm/dts/stm32mp157.dtsi   |  303 
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi   |  133 ++
 arch/arm/dts/stm32mp157c-ed1.dts   |  167 ++
 arch/arm/mach-stm32mp/Kconfig  |   43 +
 arch/arm/mach-stm32mp/Makefile |   10 +
 arch/arm/mach-stm32mp/config.mk|   14 +
 arch/arm/mach-stm32mp/cpu.c|  139 ++
 arch/arm/mach-stm32mp/dram_init.c  |   34 +
 arch/arm/mach-stm32mp/include/mach/ddr.h   |   12 +
 arch/arm/mach-stm32mp/include/mach/gpio.h  |  115 ++
 arch/arm/mach-stm32mp/include/mach/stm32.h |   27 +
 arch/arm/mach-stm32mp/spl.c|   60 +
 board/st/stm32mp1/Kconfig  |   12 +
 board/st/stm32mp1/MAINTAINERS  |7 +
 board/st/stm32mp1/Makefile |   13 +
 board/st/stm32mp1/README   |  191 +++
 board/st/stm32mp1/board.c  |   75 +
 board/st/stm32mp1/spl.c|   33 +
 board/st/stm32mp1/stm32mp1.c   |   27 +
 common/image.c |1 +
 common/spl/Kconfig |9 +
 configs/stm32mp15_basic_defconfig  |   36 +
 doc/device-tree-bindings/clock/st,stm32mp1.txt |  226 +++
 doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt   |  299 
 drivers/Makefile   |1 +
 drivers/clk/Kconfig|8 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk_stm32mp1.c | 1733 
 drivers/gpio/Kconfig   |2 +-
 drivers/gpio/stm32f7_gpio.c|   15 +-
 drivers/i2c/Kconfig|2 +-
 drivers/i2c/stm32f7_i2c.c  |4 +-
 drivers/pinctrl/pinctrl_stm32.c|9 +-
 drivers/power/pmic/Kconfig |8 +
 drivers/power/pmic/Makefile|1 +
 drivers/power/pmic/stpmu1.c|   62 +
 drivers/ram/Kconfig|2 +
 drivers/ram/Makefile   |1 +
 drivers/ram/stm32mp1/Kconfig   |   12 +
 drivers/ram/stm32mp1/Makefile  |8 +
 drivers/ram/stm32mp1/stm32mp1_ddr.c|  496 ++
 drivers/ram/stm32mp1/stm32mp1_ddr.h|  210 +++
 drivers/ram/stm32mp1/stm32mp1_ddr_regs.h   |  365 +
 drivers/ram/stm32mp1/stm32mp1_ram.c|  197 +++
 drivers/reset/Kconfig  |2 +-
 drivers/reset/stm32-reset.c|   36 +-
 drivers/serial/Kconfig |6 +-
 include/configs/stm32mp1.h |   96 ++
 include/dt-bindings/clock/stm32mp1-clks.h  |  243 +++
 include/dt-bindings/clock/stm32mp1-clksrc.h|  284 
 .../dt-bindings/reset-controller/stm32mp1-resets.h |   97 ++
 include/image.h|1 +
 include/power/stpmu1.h |   85 +
 tools/Makefile |1 +
 tools/stm32image.c |  148 ++
 63 

Re: [U-Boot] [PATCH 1/1] efi_loader: efi_allocate_pages is too restrictive

[Alexander Graf]

On 03/09/2018 05:35 PM, Heinrich Schuchardt wrote:

On 03/09/2018 05:19 PM, Alexander Graf wrote:

On 03/09/2018 04:58 PM, Heinrich Schuchardt wrote:

On 03/09/2018 01:48 PM, Alexander Graf wrote:

On 03/03/2018 03:48 PM, Heinrich Schuchardt wrote:

When running on the sandbox the stack is not necessarily at a higher
memory
address than the highest free memory.

There is no reason why the checking of the highest memory address
should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.

Signed-off-by: Heinrich Schuchardt 
---
lib/efi_loader/efi_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index cc271e0709d..0efbb973231 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -294,7 +294,7 @@ efi_status_t efi_allocate_pages(int type, int
memory_type,
switch (type) {
case EFI_ALLOCATE_ANY_PAGES:
/* Any page */
-addr = efi_find_free_memory(len, gd->start_addr_sp);
+addr = efi_find_free_memory(len, (uint64_t)-1);

This will break on systems that do not map high address space into the
linear map (IIRC nvidia systems had that issue).


The memory map is also passed on to the operating system when booting.
If a memory reservation is missing for any board it has to be fixed in
the board or driver files, cf.

sunxi: video: mark framebuffer as EFI reserved memory
https://lists.denx.de/pipermail/u-boot/2018-March/321820.htm

For type = EFI_ALLOCATE_MAX_ADDRESS we don't care about
gd->start_addr_sp. So if the memory map is incomplete the current code
may fail. Keeping things as they are is not a viable option.

Could you, please, identify for which Nvidia system a problem was
reported? Then we can add a call to efi_add_memory_map() for the board.

Git blame points to this commit. I guess -1 should do the same thing
then, true.

Andreas, would you see any reason -1 will not work?

Are we talking about this line:

arch/arm/mach-tegra/board2.c:317:
gd->pci_ram_top = gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size;


pci_ram_top != ram_top, no? :)

I'd rather assume it's this one:

/*
 * Most hardware on 64-bit Tegra is still restricted to DMA to the lower
 * 32-bits of the physical address space. Cap the maximum usable RAM area
 * at 4 GiB to avoid DMA buffers from being allocated beyond the 32-bit
 * boundary that most devices can address. Also, don't let U-Boot use any
 * carve-out, as mentioned above.
 *
 * This function is called before dram_init_banksize(), so we can't simply
 * return gd->bd->bi_dram[1].start + gd->bd->bi_dram[1].size.
 */
ulong board_get_usable_ram_top(ulong total_size)
{
return CONFIG_SYS_SDRAM_BASE + usable_ram_size_below_4g();
}

But the real problem is that ram_top of 0 is perfectly valid for 32bit 
systems.


Also ram_top may be used by platforms (like tegra again) to ensure that 
we don't use addresses >32bit for DMA. I guess the real solution to that 
would be to enable bounce buffers for tegra though. But we should make 
sure we don't regress tegra support, so we need to enable bounce buffers 
first for tegra and then allow the allocation to walk the full address 
space.



Alex

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

[U-Boot] [PATCH v2 01/15] tools/mkimage: add support for STM32 image format

[Patrick Delaunay]

STM32MP157 bootrom needs a specific header for first boot stage.
This patch adds support of this header in mkimage.

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
 - prototype for mach_cpu_init() removed for the Serie
 - rebase on v2018.03-rc4

 common/image.c |   1 +
 include/image.h|   1 +
 tools/Makefile |   1 +
 tools/stm32image.c | 148 +
 4 files changed, 151 insertions(+)
 create mode 100644 tools/stm32image.c

diff --git a/common/image.c b/common/image.c
index 14be3ca..9e850c0 100644
--- a/common/image.c
+++ b/common/image.c
@@ -161,6 +161,7 @@ static const table_entry_t uimage_type[] = {
{   IH_TYPE_TEE,"tee","Trusted Execution 
Environment Image",},
{   IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4 IVT" 
},
{   IH_TYPE_PMMC,"pmmc","TI Power Management 
Micro-Controller Firmware",},
+   {   IH_TYPE_STM32IMAGE, "stm32image", "STMicroelectronics STM32 
Image" },
{   -1, "",   "",   },
 };
 
diff --git a/include/image.h b/include/image.h
index dbdaecb..776f8bf 100644
--- a/include/image.h
+++ b/include/image.h
@@ -272,6 +272,7 @@ enum {
IH_TYPE_TEE,/* Trusted Execution Environment OS Image */
IH_TYPE_FIRMWARE_IVT,   /* Firmware Image with HABv4 IVT */
IH_TYPE_PMMC,/* TI Power Management Micro-Controller 
Firmware */
+   IH_TYPE_STM32IMAGE, /* STMicroelectronics STM32 Image */
 
IH_TYPE_COUNT,  /* Number of image types */
 };
diff --git a/tools/Makefile b/tools/Makefile
index f38f68e..55efb74 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -103,6 +103,7 @@ dumpimage-mkimage-objs := aisimage.o \
pblimage.o \
pbl_crc32.o \
vybridimage.o \
+   stm32image.o \
$(ROCKCHIP_OBS) \
socfpgaimage.o \
lib/sha1.o \
diff --git a/tools/stm32image.c b/tools/stm32image.c
new file mode 100644
index 000..437e384
--- /dev/null
+++ b/tools/stm32image.c
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#include 
+#include "imagetool.h"
+
+/* magic ='S' 'T' 'M' 0x32 */
+#define HEADER_MAGIC be32_to_cpu(0x53544D32)
+#define VER_MAJOR_IDX  2
+#define VER_MINOR_IDX  1
+#define VER_VARIANT_IDX0
+#define HEADER_VERSION_V1  0x1
+/* default option : bit0 => no signature */
+#define HEADER_DEFAULT_OPTION  (cpu_to_le32(0x0001))
+
+struct stm32_header {
+   uint32_t magic_number;
+   uint32_t image_signature[64 / 4];
+   uint32_t image_checksum;
+   uint8_t  header_version[4];
+   uint32_t image_length;
+   uint32_t image_entry_point;
+   uint32_t reserved1;
+   uint32_t load_address;
+   uint32_t reserved2;
+   uint32_t version_number;
+   uint32_t option_flags;
+   uint32_t ecdsa_algorithm;
+   uint32_t ecdsa_public_key[64 / 4];
+   uint32_t padding[84 / 4];
+};
+
+static struct stm32_header stm32image_header;
+
+static void stm32image_default_header(struct stm32_header *ptr)
+{
+   if (!ptr)
+   return;
+
+   ptr->magic_number = HEADER_MAGIC;
+   ptr->header_version[VER_MAJOR_IDX] = HEADER_VERSION_V1;
+   ptr->option_flags = HEADER_DEFAULT_OPTION;
+   ptr->ecdsa_algorithm = 1;
+}
+
+static uint32_t stm32image_checksum(void *start, uint32_t len)
+{
+   uint32_t csum = 0;
+   uint32_t hdr_len = sizeof(struct stm32_header);
+   uint8_t *p;
+
+   if (len < hdr_len)
+   return 0;
+
+   p = start + hdr_len;
+   len -= hdr_len;
+
+   while (len > 0) {
+   csum += *p;
+   p++;
+   len--;
+   }
+
+   return csum;
+}
+
+static int stm32image_check_image_types(uint8_t type)
+{
+   if (type == IH_TYPE_STM32IMAGE)
+   return EXIT_SUCCESS;
+   return EXIT_FAILURE;
+}
+
+static int stm32image_verify_header(unsigned char *ptr, int image_size,
+   struct image_tool_params *params)
+{
+   struct stm32_header *stm32hdr = (struct stm32_header *)ptr;
+   int i;
+
+   if (image_size < sizeof(struct stm32_header))
+   return -1;
+   if (stm32hdr->magic_number != HEADER_MAGIC)
+   return -1;
+   if (stm32hdr->header_version[VER_MAJOR_IDX] != HEADER_VERSION_V1)
+   return -1;
+   if (stm32hdr->reserved1 || stm32hdr->reserved2)
+   return -1;
+   for (i = 0; i < (sizeof(stm32hdr->padding) / 4); i++) {
+   if (stm32hdr->padding[i] != 0)
+   return -1;
+   }
+
+   return 0;
+}
+
+static void 

[U-Boot] [PATCH v2 09/15] pmic: add stpmu1 support

[Patrick Delaunay]

This driver implements register read/write operations for STPMU1.

The STPMU1 PMIC provides 4 BUCKs, 6 LDOs, 1 VREF
and 2 power switches. It is accessed via an I2C interface.
This device is used with STM32MP1 SoCs.

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 drivers/power/pmic/Kconfig  |  8 +
 drivers/power/pmic/Makefile |  1 +
 drivers/power/pmic/stpmu1.c | 62 +
 include/power/stpmu1.h  | 85 +
 4 files changed, 156 insertions(+)
 create mode 100644 drivers/power/pmic/stpmu1.c
 create mode 100644 include/power/stpmu1.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 5d49c93..40ab9f7 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -209,3 +209,11 @@ config DM_PMIC_TPS65910
The TPS65910 is a PMIC containing 3 buck DC-DC converters, one boost
DC-DC converter, 8 LDOs and a RTC. This driver binds the SMPS and LDO
pmic children.
+
+config PMIC_STPMU1
+   bool "Enable support for STMicroelectronics STPMU1 PMIC"
+   depends on DM_PMIC && DM_I2C
+   ---help---
+   The STPMU1 PMIC provides 4 BUCKs, 6 LDOs, 1 VREF and 2 power switches.
+   It is accessed via an I2C interface. The device is used with STM32MP1
+   SoCs. This driver implements register read/write operations.
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index fc19fdc..ad32068 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_DM_PMIC_TPS65910) += pmic_tps65910_dm.o
 obj-$(CONFIG_$(SPL_)PMIC_PALMAS) += palmas.o
 obj-$(CONFIG_$(SPL_)PMIC_LP873X) += lp873x.o
 obj-$(CONFIG_$(SPL_)PMIC_LP87565) += lp87565.o
+obj-$(CONFIG_PMIC_STPMU1) += stpmu1.o
 
 obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
 obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
diff --git a/drivers/power/pmic/stpmu1.c b/drivers/power/pmic/stpmu1.c
new file mode 100644
index 000..4615365
--- /dev/null
+++ b/drivers/power/pmic/stpmu1.c
@@ -0,0 +1,62 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define STMPU1_NUM_OF_REGS 0x100
+
+static int stpmu1_reg_count(struct udevice *dev)
+{
+   return STMPU1_NUM_OF_REGS;
+}
+
+static int stpmu1_write(struct udevice *dev, uint reg, const uint8_t *buff,
+   int len)
+{
+   int ret;
+
+   ret = dm_i2c_write(dev, reg, buff, len);
+   if (ret)
+   dev_err(dev, "%s: failed to write register %#x :%d",
+   __func__, reg, ret);
+
+   return ret;
+}
+
+static int stpmu1_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   int ret;
+
+   ret = dm_i2c_read(dev, reg, buff, len);
+   if (ret)
+   dev_err(dev, "%s: failed to read register %#x : %d",
+   __func__, reg, ret);
+
+   return ret;
+}
+
+static struct dm_pmic_ops stpmu1_ops = {
+   .reg_count = stpmu1_reg_count,
+   .read = stpmu1_read,
+   .write = stpmu1_write,
+};
+
+static const struct udevice_id stpmu1_ids[] = {
+   { .compatible = "st,stpmu1" },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_stpmu1) = {
+   .name = "stpmu1_pmic",
+   .id = UCLASS_PMIC,
+   .of_match = stpmu1_ids,
+   .ops = _ops,
+};
diff --git a/include/power/stpmu1.h b/include/power/stpmu1.h
new file mode 100644
index 000..697e245
--- /dev/null
+++ b/include/power/stpmu1.h
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#ifndef __PMIC_STPMU1_H_
+#define __PMIC_STPMU1_H_
+
+#define STPMU1_MASK_RESET_BUCK 0x18
+#define STPMU1_BUCKX_CTRL_REG(buck)(0x20 + (buck))
+#define STPMU1_VREF_CTRL_REG   0x24
+#define STPMU1_LDOX_CTRL_REG(ldo)  (0x25 + (ldo))
+#define STPMU1_USB_CTRL_REG0x40
+#define STPMU1_NVM_USER_STATUS_REG 0xb8
+#define STPMU1_NVM_USER_CONTROL_REG0xb9
+
+#define STPMU1_MASK_RESET_BUCK3BIT(2)
+
+#define STPMU1_BUCK_EN BIT(0)
+#define STPMU1_BUCK_MODE   BIT(1)
+#define STPMU1_BUCK_OUTPUT_MASKGENMASK(7, 2)
+#define STPMU1_BUCK_OUTPUT_SHIFT   2
+#define STPMU1_BUCK2_120V  (24 << STPMU1_BUCK_OUTPUT_SHIFT)
+#define STPMU1_BUCK2_135V  (30 << STPMU1_BUCK_OUTPUT_SHIFT)
+#define STPMU1_BUCK3_180V  (39 << STPMU1_BUCK_OUTPUT_SHIFT)
+
+#define STPMU1_VREF_EN BIT(0)
+
+#define STPMU1_LDO_EN  BIT(0)
+#define STPMU1_LDO12356_OUTPUT_MASKGENMASK(6, 2)
+#define STPMU1_LDO12356_OUTPUT_SHIFT   2
+#define STPMU1_LDO3_MODE   BIT(7)
+#define STPMU1_LDO3_DDR_SEL31
+#define STPMU1_LDO3_180(9 << 

[U-Boot] [PATCH v2 14/15] dts: add device tree for STM32MP157C-ED1 board

[Patrick Delaunay]

Add minimal devicetree for STM32MP157C-ED1 board,
with only the devices to allow boot from SDCARD:
- RCC for clock and reset
- UART4 for console
- I2C and PMIC
- DDR
- SDMMC0 for SDCard

Waiting Kernel upstream for alignment.

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 arch/arm/dts/Makefile  |   3 +
 arch/arm/dts/stm32mp15-ddr.dtsi| 155 +++
 arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi   | 122 +
 arch/arm/dts/stm32mp157-u-boot.dtsi| 134 +
 arch/arm/dts/stm32mp157.dtsi   | 303 +
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi   | 133 +
 arch/arm/dts/stm32mp157c-ed1.dts   | 167 
 include/dt-bindings/clock/stm32mp1-clks.h  | 243 +
 .../dt-bindings/reset-controller/stm32mp1-resets.h |  97 +++
 9 files changed, 1357 insertions(+)
 create mode 100644 arch/arm/dts/stm32mp15-ddr.dtsi
 create mode 100644 arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi
 create mode 100644 arch/arm/dts/stm32mp157-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157.dtsi
 create mode 100644 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157c-ed1.dts
 create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h
 create mode 100644 include/dt-bindings/reset-controller/stm32mp1-resets.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 20a4c37..0280f4d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -497,6 +497,9 @@ dtb-$(CONFIG_ARCH_ASPEED) += ast2500-evb.dtb
 
 dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
 
+dtb-$(CONFIG_TARGET_STM32MP1) += \
+   stm32mp157c-ed1.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/stm32mp15-ddr.dtsi b/arch/arm/dts/stm32mp15-ddr.dtsi
new file mode 100644
index 000..ddfa079
--- /dev/null
+++ b/arch/arm/dts/stm32mp15-ddr.dtsi
@@ -0,0 +1,155 @@
+/*
+ * Copyright : STMicroelectronics 2018
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+/ {
+   soc {
+   ddr: ddr@0x5A003000{
+   u-boot,dm-pre-reloc;
+
+   compatible = "st,stm32mp1-ddr";
+
+   reg = <0x5A003000 0x550
+  0x5A004000 0x234>;
+
+   clocks = <_clk AXIDCG>,
+<_clk DDRC1>,
+<_clk DDRC2>,
+<_clk DDRPHYC>,
+<_clk DDRCAPB>,
+<_clk DDRPHYCAPB>;
+
+   clock-names = "axidcg",
+ "ddrc1",
+ "ddrc2",
+ "ddrphyc",
+ "ddrcapb",
+ "ddrphycapb";
+
+   st,mem-name = DDR_MEM_NAME;
+   st,mem-speed = ;
+   st,mem-size = ;
+
+   st,ctl-reg = <
+   DDR_MSTR
+   DDR_MRCTRL0
+   DDR_MRCTRL1
+   DDR_DERATEEN
+   DDR_DERATEINT
+   DDR_PWRCTL
+   DDR_PWRTMG
+   DDR_HWLPCTL
+   DDR_RFSHCTL0
+   DDR_RFSHCTL3
+   DDR_CRCPARCTL0
+   DDR_ZQCTL0
+   DDR_DFITMG0
+   DDR_DFITMG1
+   DDR_DFILPCFG0
+   DDR_DFIUPD0
+   DDR_DFIUPD1
+   DDR_DFIUPD2
+   DDR_DFIPHYMSTR
+   DDR_ODTMAP
+   DDR_DBG0
+   DDR_DBG1
+   DDR_DBGCMD
+   DDR_POISONCFG
+   DDR_PCCFG
+   >;
+
+   st,ctl-timing = <
+   DDR_RFSHTMG
+   DDR_DRAMTMG0
+   DDR_DRAMTMG1
+   DDR_DRAMTMG2
+   DDR_DRAMTMG3
+   DDR_DRAMTMG4
+   DDR_DRAMTMG5
+   DDR_DRAMTMG6
+   DDR_DRAMTMG7
+   DDR_DRAMTMG8
+   DDR_DRAMTMG14
+   DDR_ODTCFG
+   >;
+
+   st,ctl-map = <
+   

[U-Boot] [PATCH v2 08/15] ram: stm32mp1: add driver

[Patrick Delaunay]

Add driver and binding for stm32mp1 ddr controller and phy

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 MAINTAINERS  |   1 +
 arch/arm/mach-stm32mp/include/mach/ddr.h |  12 +
 doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt | 299 ++
 drivers/ram/Kconfig  |   2 +
 drivers/ram/Makefile |   1 +
 drivers/ram/stm32mp1/Kconfig |  12 +
 drivers/ram/stm32mp1/Makefile|   8 +
 drivers/ram/stm32mp1/stm32mp1_ddr.c  | 496 +++
 drivers/ram/stm32mp1/stm32mp1_ddr.h  | 210 ++
 drivers/ram/stm32mp1/stm32mp1_ddr_regs.h | 365 +
 drivers/ram/stm32mp1/stm32mp1_ram.c  | 197 +
 11 files changed, 1603 insertions(+)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/ddr.h
 create mode 100644 doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt
 create mode 100644 drivers/ram/stm32mp1/Kconfig
 create mode 100644 drivers/ram/stm32mp1/Makefile
 create mode 100644 drivers/ram/stm32mp1/stm32mp1_ddr.c
 create mode 100644 drivers/ram/stm32mp1/stm32mp1_ddr.h
 create mode 100644 drivers/ram/stm32mp1/stm32mp1_ddr_regs.h
 create mode 100644 drivers/ram/stm32mp1/stm32mp1_ram.c

diff --git a/MAINTAINERS b/MAINTAINERS
index fed523c..4a1c41b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -196,6 +196,7 @@ ARM STM STM32MP
 M: Patrick Delaunay 
 S: Maintained
 F: arch/arm/mach-stm32mp
+F: ram/stm32mp1
 
 ARM STM STV0991
 M: Vikas Manocha 
diff --git a/arch/arm/mach-stm32mp/include/mach/ddr.h 
b/arch/arm/mach-stm32mp/include/mach/ddr.h
new file mode 100644
index 000..b635001
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/ddr.h
@@ -0,0 +1,12 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#ifndef __MACH_STM32MP_DDR_H_
+#define __MACH_STM32MP_DDR_H_
+
+int board_ddr_power_init(void);
+
+#endif
diff --git a/doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt 
b/doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt
new file mode 100644
index 000..3028636
--- /dev/null
+++ b/doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt
@@ -0,0 +1,299 @@
+ST,stm32mp1 DDR3/LPDDR2/LPDDR3 Controller (DDRCTRL and DDRPHYC)
+
+
+Required properties:
+
+- compatible   : Should be "st,stm32mp1-ddr"
+- reg  : controleur (DDRCTRL) and phy (DDRPHYC) base address
+- clocks   : controller clocks handle
+- clock-names  : associated controller clock names
+ the "ddrphyc" clock is used to check the DDR frequency
+ at phy level according the expected value in "mem-speed" field
+
+the next attributes are DDR parameters, they are generated by DDR tools
+included in STM32 Cube tool
+
+info attributes:
+
+- st,mem-name  : name for DDR configuration, simple string for information
+- st,mem-speed : DDR expected speed for the setting in MHz
+- st,mem-size  : DDR mem size in byte
+
+
+controlleur attributes:
+---
+- st,ctl-reg   : controleur values depending of the DDR type
+ (DDR3/LPDDR2/LPDDR3)
+   for STM32MP15x: 25 values are requested in this order
+   MSTR
+   MRCTRL0
+   MRCTRL1
+   DERATEEN
+   DERATEINT
+   PWRCTL
+   PWRTMG
+   HWLPCTL
+   RFSHCTL0
+   RFSHCTL3
+   CRCPARCTL0
+   ZQCTL0
+   DFITMG0
+   DFITMG1
+   DFILPCFG0
+   DFIUPD0
+   DFIUPD1
+   DFIUPD2
+   DFIPHYMSTR
+   ODTMAP
+   DBG0
+   DBG1
+   DBGCMD
+   POISONCFG
+   PCCFG
+
+- st,ctl-timing: controleur values depending of frequency and timing 
parameter
+ of DDR
+   for STM32MP15x: 12 values are requested in this order
+   RFSHTMG
+   DRAMTMG0
+   DRAMTMG1
+   DRAMTMG2
+   DRAMTMG3
+   DRAMTMG4
+   DRAMTMG5
+   DRAMTMG6
+   DRAMTMG7
+   DRAMTMG8
+   DRAMTMG14
+   ODTCFG
+
+- st,ctl-map   : controleur values depending of address mapping
+   for STM32MP15x: 9 values are requested in this order
+   ADDRMAP1
+   ADDRMAP2
+   ADDRMAP3
+   ADDRMAP4
+   ADDRMAP5
+   ADDRMAP6
+   ADDRMAP9
+   ADDRMAP10
+   ADDRMAP11
+
+- st,ctl-perf  : controleur values depending of performance and scheduling
+   for STM32MP15x: 17 values are requested in this order
+  

[U-Boot] [PATCH v2 10/15] pinctrl: stm32: update pincontrol for stmp32mp157

[Patrick Delaunay]

- add the 2 new compatible used by STM32MP157
"st,stm32mp157-pinctrl"
"st,stm32mp157-z-pinctrl"
- update the mask for the port

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 drivers/pinctrl/pinctrl_stm32.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c
index 2066e11..31285cd 100644
--- a/drivers/pinctrl/pinctrl_stm32.c
+++ b/drivers/pinctrl/pinctrl_stm32.c
@@ -41,9 +41,10 @@ static int stm32_gpio_config(struct gpio_desc *desc,
 
return 0;
 }
+
 static int prep_gpio_dsc(struct stm32_gpio_dsc *gpio_dsc, u32 port_pin)
 {
-   gpio_dsc->port = (port_pin & 0xF000) >> 12;
+   gpio_dsc->port = (port_pin & 0x1F000) >> 12;
gpio_dsc->pin = (port_pin & 0x0F00) >> 8;
debug("%s: GPIO:port= %d, pin= %d\n", __func__, gpio_dsc->port,
  gpio_dsc->pin);
@@ -115,11 +116,13 @@ static int stm32_pinctrl_config(int offset)
return -EINVAL;
for (i = 0; i < len; i++) {
struct gpio_desc desc;
+
debug("%s: pinmux = %x\n", __func__, *(pin_mux + i));
prep_gpio_dsc(_dsc, *(pin_mux + i));
prep_gpio_ctl(_ctl, *(pin_mux + i), offset);
rv = uclass_get_device_by_seq(UCLASS_GPIO,
- gpio_dsc.port, );
+ gpio_dsc.port,
+ );
if (rv)
return rv;
desc.offset = gpio_dsc.pin;
@@ -186,6 +189,8 @@ static const struct udevice_id stm32_pinctrl_ids[] = {
{ .compatible = "st,stm32f469-pinctrl" },
{ .compatible = "st,stm32f746-pinctrl" },
{ .compatible = "st,stm32h743-pinctrl" },
+   { .compatible = "st,stm32mp157-pinctrl" },
+   { .compatible = "st,stm32mp157-z-pinctrl" },
{ }
 };
 
-- 
2.7.4

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

[U-Boot] [PATCH v2 15/15] board: st: add generic board for STM32MP1 family

[Patrick Delaunay]

Add first support for STM32MP157C-ED1 board with "Basic" boot chain
1/ Boot Rom: load SPL with STM32 image header in SYSRAM
2/ SPL: power up and initialize the DDR and load U-Boot image
from SDCARD in DDR
3/ U-Boot: search and load extlinux.conf in SDCARD
   (DISTRO activated)

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
 - remove include of "config_distro_defaults.h"

 arch/arm/mach-stm32mp/Kconfig |   2 +
 board/st/stm32mp1/Kconfig |  12 +++
 board/st/stm32mp1/MAINTAINERS |   7 ++
 board/st/stm32mp1/Makefile|  13 +++
 board/st/stm32mp1/README  | 191 ++
 board/st/stm32mp1/board.c |  75 +++
 board/st/stm32mp1/spl.c   |  33 +++
 board/st/stm32mp1/stm32mp1.c  |  27 ++
 configs/stm32mp15_basic_defconfig |  36 +++
 include/configs/stm32mp1.h|  96 +++
 10 files changed, 492 insertions(+)
 create mode 100644 board/st/stm32mp1/Kconfig
 create mode 100644 board/st/stm32mp1/MAINTAINERS
 create mode 100644 board/st/stm32mp1/Makefile
 create mode 100644 board/st/stm32mp1/README
 create mode 100644 board/st/stm32mp1/board.c
 create mode 100644 board/st/stm32mp1/spl.c
 create mode 100644 board/st/stm32mp1/stm32mp1.c
 create mode 100644 configs/stm32mp15_basic_defconfig
 create mode 100644 include/configs/stm32mp1.h

diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index ab94879..8c755f8 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -38,4 +38,6 @@ config SYS_TEXT_BASE
when DDR driver is used:
  DDR + 1MB (0xC010)
 
+source "board/st/stm32mp1/Kconfig"
+
 endif
diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
new file mode 100644
index 000..5ab9415
--- /dev/null
+++ b/board/st/stm32mp1/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_STM32MP1
+
+config SYS_BOARD
+   default "stm32mp1"
+
+config SYS_VENDOR
+   default "st"
+
+config SYS_CONFIG_NAME
+   default "stm32mp1"
+
+endif
diff --git a/board/st/stm32mp1/MAINTAINERS b/board/st/stm32mp1/MAINTAINERS
new file mode 100644
index 000..65266bc
--- /dev/null
+++ b/board/st/stm32mp1/MAINTAINERS
@@ -0,0 +1,7 @@
+STM32MP1 BOARD
+M: Patrick Delaunay 
+S: Maintained
+F: board/st/stm32mp1
+F: include/configs/stm32mp1.h
+F: configs/stm32mp15_basic_defconfig
+F: arch/arm/dts/stm32mp157*
diff --git a/board/st/stm32mp1/Makefile b/board/st/stm32mp1/Makefile
new file mode 100644
index 000..eaf45b7
--- /dev/null
+++ b/board/st/stm32mp1/Makefile
@@ -0,0 +1,13 @@
+#
+# Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+#
+# SPDX-License-Identifier: GPL-2.0+BSD-3-Clause
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y += spl.o
+else
+obj-y += stm32mp1.o
+endif
+
+obj-y += board.o
diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README
new file mode 100644
index 000..4adc978
--- /dev/null
+++ b/board/st/stm32mp1/README
@@ -0,0 +1,191 @@
+#
+# Copyright (C) 2018 STMicroelectronics - All Rights Reserved
+#
+# SPDX-License-Identifier: GPL-2.0+BSD-3-Clause
+#
+
+U-Boot on STMicroelectronics STM32MP1
+==
+
+1. Summary
+==
+This is a quick instruction for setup stm32mp1 boards.
+
+2. Supported devices
+
+U-Boot supports one STMP32MP1 SoCs: STM32MP157
+
+The STM32MP157 is a Cortex-A MPU aimed at various applications.
+It features:
+- Dual core Cortex-A7 application core
+- 2D/3D image composition with GPU
+- Standard memories interface support
+- Standard connectivity, widely inherited from the STM32 MCU family
+- Comprehensive security support
+
+Everything is supported in Linux but U-Boot is limited to:
+1. UART
+2. SDCard/MMC controller (SDMMC)
+
+And the necessary drivers
+1. I2C
+2. STPMU1
+3. Clock, Reset
+
+Currently the following boards are supported:
++ stm32mp157c-ed1
+
+3. Boot Sequences
+=
+
+BootRom => FSBL in SYSRAM => SSBL in DDR => OS (Linux Kernel)
+
+with FSBL = First Stage Bootloader
+ SSBL = Second Stage Bootloader
+
+One boot configuration is supported:
+
+   The "Basic" boot chain (defconfig_file : stm32mp15_basic_defconfig)
+   BootRom => FSBL = U-Boot SPL => SSBL = U-Boot
+   SPL has limited security initialisation
+   U-Boot is running in secure mode and provide a secure monitor to the kernel
+   with only PSCI support (Power State Coordination Interface defined by ARM)
+
+All the STM32MP1 board supported by U-Boot use the same generic board
+stm32mp1 which support all the bootable devices.
+
+Each board is configurated only with the associated device tree.
+
+4. Device Tree Selection
+
+
+You need to select the appropriate device tree for your board,
+the supported device trees for stm32mp157 are:
+
++ ed1: daughter board with pmic stpmu1
+  dts: stm32mp157c-ed1
+
+5. Build 

[U-Boot] [PATCH v2 11/15] reset: stm32: adapt driver for stm32mp1

[Patrick Delaunay]

- move to livetree and allow to get address to parent
- add stm32mp1 compatible for probe

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 drivers/reset/Kconfig   |  2 +-
 drivers/reset/stm32-reset.c | 36 ++--
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 3964b9e..71a786b 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -30,7 +30,7 @@ config STI_RESET
 
 config STM32_RESET
bool "Enable the STM32 reset"
-   depends on STM32
+   depends on STM32 || ARCH_STM32MP
help
  Support for reset controllers on STMicroelectronics STM32 family SoCs.
  This resset driver is compatible with STM32 F4/F7 and H7 SoCs.
diff --git a/drivers/reset/stm32-reset.c b/drivers/reset/stm32-reset.c
index b266f46..e98f34b 100644
--- a/drivers/reset/stm32-reset.c
+++ b/drivers/reset/stm32-reset.c
@@ -11,7 +11,13 @@
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
+/* reset clear offset for STM32MP RCC */
+#define RCC_CL 0x4
+
+enum rcc_type {
+   RCC_STM32 = 0,
+   RCC_STM32MP,
+};
 
 struct stm32_reset_priv {
fdt_addr_t base;
@@ -35,7 +41,11 @@ static int stm32_reset_assert(struct reset_ctl *reset_ctl)
debug("%s: reset id = %ld bank = %d offset = %d)\n", __func__,
  reset_ctl->id, bank, offset);
 
-   setbits_le32(priv->base + bank, BIT(offset));
+   if (dev_get_driver_data(reset_ctl->dev) == RCC_STM32MP)
+   /* reset assert is done in rcc set register */
+   writel(BIT(offset), priv->base + bank);
+   else
+   setbits_le32(priv->base + bank, BIT(offset));
 
return 0;
 }
@@ -48,7 +58,11 @@ static int stm32_reset_deassert(struct reset_ctl *reset_ctl)
debug("%s: reset id = %ld bank = %d offset = %d)\n", __func__,
  reset_ctl->id, bank, offset);
 
-   clrbits_le32(priv->base + bank, BIT(offset));
+   if (dev_get_driver_data(reset_ctl->dev) == RCC_STM32MP)
+   /* reset deassert is done in rcc clr register */
+   writel(BIT(offset), priv->base + bank + RCC_CL);
+   else
+   clrbits_le32(priv->base + bank, BIT(offset));
 
return 0;
 }
@@ -64,16 +78,26 @@ static int stm32_reset_probe(struct udevice *dev)
 {
struct stm32_reset_priv *priv = dev_get_priv(dev);
 
-   priv->base = devfdt_get_addr(dev);
-   if (priv->base == FDT_ADDR_T_NONE)
-   return -EINVAL;
+   priv->base = dev_read_addr(dev);
+   if (priv->base == FDT_ADDR_T_NONE) {
+   /* for MFD, get address of parent */
+   priv->base = dev_read_addr(dev->parent);
+   if (priv->base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+   }
 
return 0;
 }
 
+static const struct udevice_id stm32_reset_ids[] = {
+   { .compatible = "st,stm32mp1-rcc-rst", .data = RCC_STM32MP },
+   { }
+};
+
 U_BOOT_DRIVER(stm32_rcc_reset) = {
.name   = "stm32_rcc_reset",
.id = UCLASS_RESET,
+   .of_match   = stm32_reset_ids,
.probe  = stm32_reset_probe,
.priv_auto_alloc_size   = sizeof(struct stm32_reset_priv),
.ops= _reset_ops,
-- 
2.7.4

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

[U-Boot] [PATCH v2 07/15] arm: stm32: add new architecture for STM32MP family

[Patrick Delaunay]

- add new arch stm32mp for STM32 MPU/Soc based on Cortex A
- support for stm32mp157 SOC
- SPL is used as first boot stage loader
- using driver model for all the drivers, even in SPL
- all security feature are deactivated (ETZC and TZC)
- reused STM32 MCU drivers when it is possible

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 MAINTAINERS|   5 ++
 arch/arm/Kconfig   |  25 +-
 arch/arm/Makefile  |   1 +
 arch/arm/mach-stm32mp/Kconfig  |  41 +
 arch/arm/mach-stm32mp/Makefile |  10 +++
 arch/arm/mach-stm32mp/config.mk|  14 +++
 arch/arm/mach-stm32mp/cpu.c| 139 +
 arch/arm/mach-stm32mp/dram_init.c  |  34 +++
 arch/arm/mach-stm32mp/include/mach/gpio.h  | 115 
 arch/arm/mach-stm32mp/include/mach/stm32.h |  27 ++
 arch/arm/mach-stm32mp/spl.c|  60 +
 drivers/gpio/Kconfig   |   2 +-
 drivers/i2c/Kconfig|   2 +-
 drivers/serial/Kconfig |   6 +-
 14 files changed, 475 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/mach-stm32mp/Kconfig
 create mode 100644 arch/arm/mach-stm32mp/Makefile
 create mode 100644 arch/arm/mach-stm32mp/config.mk
 create mode 100644 arch/arm/mach-stm32mp/cpu.c
 create mode 100644 arch/arm/mach-stm32mp/dram_init.c
 create mode 100644 arch/arm/mach-stm32mp/include/mach/gpio.h
 create mode 100644 arch/arm/mach-stm32mp/include/mach/stm32.h
 create mode 100644 arch/arm/mach-stm32mp/spl.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f42cb22..fed523c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -192,6 +192,11 @@ T: git git://git.denx.de/u-boot-stm.git
 F: arch/arm/cpu/arm926ejs/spear/
 F: arch/arm/include/asm/arch-spear/
 
+ARM STM STM32MP
+M: Patrick Delaunay 
+S: Maintained
+F: arch/arm/mach-stm32mp
+
 ARM STM STV0991
 M: Vikas Manocha 
 S: Maintained
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c52ff0..14c13b4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1130,7 +1130,7 @@ config ARCH_UNIPHIER
  (formerly, System LSI Business Division of Panasonic Corporation)
 
 config STM32
-   bool "Support STM32"
+   bool "Support STMicroelectronics STM32 MCU with cortex M"
select CPU_V7M
select DM
select DM_SERIAL
@@ -1148,6 +1148,27 @@ config ARCH_STI
  Support for STMicroelectronics STiH407/10 SoC family.
  This SoC is used on Linaro 96Board STiH410-B2260
 
+config ARCH_STM32MP
+   bool "Support STMicroelectronics STM32MP Socs with cortex A"
+   select BOARD_LATE_INIT
+   select CLK
+   select DM
+   select DM_GPIO
+   select DM_RESET
+   select DM_SERIAL
+   select OF_CONTROL
+   select OF_LIBFDT
+   select PINCTRL
+   select REGMAP
+   select SUPPORT_SPL
+   select SYSCON
+   select SYS_THUMB_BUILD
+   help
+ Support for STM32MP SoC family developed by STMicroelectronics,
+ MPUs based on ARM cortex A core
+ U-BOOT is running in DDR and SPL support is the unsecure First Stage
+ BootLoader (FSBL)
+
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
select OF_CONTROL
@@ -1260,6 +1281,8 @@ source "arch/arm/mach-sti/Kconfig"
 
 source "arch/arm/mach-stm32/Kconfig"
 
+source "arch/arm/mach-stm32mp/Kconfig"
+
 source "arch/arm/mach-sunxi/Kconfig"
 
 source "arch/arm/mach-tegra/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5881fdc..4fa8b38 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -72,6 +72,7 @@ machine-$(CONFIG_ARCH_SOCFPGA)+= socfpga
 machine-$(CONFIG_ARCH_RMOBILE) += rmobile
 machine-$(CONFIG_ARCH_ROCKCHIP)+= rockchip
 machine-$(CONFIG_STM32)+= stm32
+machine-$(CONFIG_ARCH_STM32MP) += stm32mp
 machine-$(CONFIG_TEGRA)+= tegra
 machine-$(CONFIG_ARCH_UNIPHIER)+= uniphier
 machine-$(CONFIG_ARCH_ZYNQ)+= zynq
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
new file mode 100644
index 000..ab94879
--- /dev/null
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -0,0 +1,41 @@
+if ARCH_STM32MP
+
+config SPL
+   select SPL_BOARD_INIT
+   select SPL_CLK
+   select SPL_DM
+   select SPL_DM_SEQ_ALIAS
+   select SPL_FRAMEWORK
+   select SPL_GPIO_SUPPORT
+   select SPL_LIBCOMMON_SUPPORT
+   select SPL_LIBGENERIC_SUPPORT
+   select SPL_OF_CONTROL
+   select SPL_OF_TRANSLATE
+   select SPL_PINCTRL
+   select SPL_REGMAP
+   select SPL_RESET_SUPPORT
+   select SPL_SERIAL_SUPPORT
+   select SPL_SYSCON
+   imply SPL_LIBDISK_SUPPORT
+
+config SYS_SOC
+   default "stm32mp"
+
+config 

[U-Boot] [PATCH v2 12/15] clk: add driver for stm32mp1

[Patrick Delaunay]

add RCC clock driver for STMP32MP157
- base on driver model = UCLASS_CLK
- support ops to enable, disable and get rate
  of all SOC clock needed by U-Boot

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 MAINTAINERS|1 +
 drivers/clk/Kconfig|8 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk_stm32mp1.c | 1157 
 4 files changed, 1167 insertions(+)
 create mode 100644 drivers/clk/clk_stm32mp1.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4a1c41b..2aa534f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -196,6 +196,7 @@ ARM STM STM32MP
 M: Patrick Delaunay 
 S: Maintained
 F: arch/arm/mach-stm32mp
+F: clk/clk_stm32mp1.c
 F: ram/stm32mp1
 
 ARM STM STV0991
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index cdfa052..c382e88 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -75,6 +75,14 @@ config CLK_ZYNQMP
  This clock driver adds support for clock realted settings for
  ZynqMP platform.
 
+config CLK_STM32MP1
+   bool "Enable RCC clock driver for STM32MP1"
+   depends on ARCH_STM32MP && CLK
+   default y
+   help
+ Enable the STM32 clock (RCC) driver. Enable support for
+ manipulating STM32MP1's on-SoC clocks.
+
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
 source "drivers/clk/exynos/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index dab106a..e05c607 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_CLK_EXYNOS) += exynos/
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
 obj-$(CONFIG_CLK_RENESAS) += renesas/
 obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
+obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
 obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
 obj-$(CONFIG_CLK_ZYNQ) += clk_zynq.o
 obj-$(CONFIG_CLK_ZYNQMP) += clk_zynqmp.o
diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
new file mode 100644
index 000..0ea2035
--- /dev/null
+++ b/drivers/clk/clk_stm32mp1.c
@@ -0,0 +1,1157 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_HSI_HZ 6400
+
+/* RCC registers */
+#define RCC_OCENSETR   0x0C
+#define RCC_OCENCLRR   0x10
+#define RCC_HSICFGR0x18
+#define RCC_MPCKSELR   0x20
+#define RCC_ASSCKSELR  0x24
+#define RCC_RCK12SELR  0x28
+#define RCC_MPCKDIVR   0x2C
+#define RCC_AXIDIVR0x30
+#define RCC_APB4DIVR   0x3C
+#define RCC_APB5DIVR   0x40
+#define RCC_RTCDIVR0x44
+#define RCC_MSSCKSELR  0x48
+#define RCC_PLL1CR 0x80
+#define RCC_PLL1CFGR1  0x84
+#define RCC_PLL1CFGR2  0x88
+#define RCC_PLL1FRACR  0x8C
+#define RCC_PLL1CSGR   0x90
+#define RCC_PLL2CR 0x94
+#define RCC_PLL2CFGR1  0x98
+#define RCC_PLL2CFGR2  0x9C
+#define RCC_PLL2FRACR  0xA0
+#define RCC_PLL2CSGR   0xA4
+#define RCC_I2C46CKSELR0xC0
+#define RCC_CPERCKSELR 0xD0
+#define RCC_STGENCKSELR0xD4
+#define RCC_DDRITFCR   0xD8
+#define RCC_BDCR   0x140
+#define RCC_RDLSICR0x144
+#define RCC_MP_APB4ENSETR  0x200
+#define RCC_MP_APB5ENSETR  0x208
+#define RCC_MP_AHB5ENSETR  0x210
+#define RCC_MP_AHB6ENSETR  0x218
+#define RCC_OCRDYR 0x808
+#define RCC_DBGCFGR0x80C
+#define RCC_RCK3SELR   0x820
+#define RCC_RCK4SELR   0x824
+#define RCC_MCUDIVR0x830
+#define RCC_APB1DIVR   0x834
+#define RCC_APB2DIVR   0x838
+#define RCC_APB3DIVR   0x83C
+#define RCC_PLL3CR 0x880
+#define RCC_PLL3CFGR1  0x884
+#define RCC_PLL3CFGR2  0x888
+#define RCC_PLL3FRACR  0x88C
+#define RCC_PLL3CSGR   0x890
+#define RCC_PLL4CR 0x894
+#define RCC_PLL4CFGR1  0x898
+#define RCC_PLL4CFGR2  0x89C
+#define RCC_PLL4FRACR  0x8A0
+#define RCC_PLL4CSGR   0x8A4
+#define RCC_I2C12CKSELR0x8C0
+#define RCC_I2C35CKSELR0x8C4
+#define RCC_UART6CKSELR0x8E4
+#define RCC_UART24CKSELR   0x8E8
+#define RCC_UART35CKSELR   0x8EC
+#define RCC_UART78CKSELR   0x8F0
+#define RCC_SDMMC12CKSELR  0x8F4
+#define RCC_SDMMC3CKSELR   0x8F8
+#define RCC_ETHCKSELR  0x8FC
+#define RCC_QSPICKSELR 0x900
+#define RCC_FMCCKSELR  0x904
+#define RCC_USBCKSELR  0x91C
+#define RCC_MP_APB1ENSETR  0xA00
+#define RCC_MP_APB2ENSETR  0XA08
+#define RCC_MP_AHB2ENSETR  0xA18
+#define RCC_MP_AHB4ENSETR  0xA28
+
+/* used for most of SELR 

[U-Boot] [PATCH v2 06/15] stm32mp: stm32f7_i2c: use calloc instead of kmalloc

[Patrick Delaunay]

Kmalloc is using memalign allocation function. It is not necessary to
align this structure so to save bytes, we move to calloc.

And kmalloc function can't be used in SPL early stage (in board_init_f())

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 drivers/i2c/stm32f7_i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 8662487..81f061a 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -533,7 +533,7 @@ static int stm32_i2c_compute_solutions(struct 
stm32_i2c_setup *setup,
if (((sdadel >= sdadel_min) &&
 (sdadel <= sdadel_max)) &&
(p != p_prev)) {
-   v = kmalloc(sizeof(*v), GFP_KERNEL);
+   v = calloc(1, sizeof(*v));
if (!v)
return -ENOMEM;
 
@@ -689,7 +689,7 @@ exit:
/* Release list and memory */
list_for_each_entry_safe(v, _v, , node) {
list_del(>node);
-   kfree(v);
+   free(v);
}
 
return ret;
-- 
2.7.4

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

[U-Boot] [PATCH v2 13/15] clk: stm32mp1: add clock tree initialization

[Patrick Delaunay]

add binding and code for clock tree initialization from device tree

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 doc/device-tree-bindings/clock/st,stm32mp1.txt | 226 ++
 drivers/clk/clk_stm32mp1.c | 576 +
 include/dt-bindings/clock/stm32mp1-clksrc.h| 284 
 3 files changed, 1086 insertions(+)
 create mode 100644 doc/device-tree-bindings/clock/st,stm32mp1.txt
 create mode 100644 include/dt-bindings/clock/stm32mp1-clksrc.h

diff --git a/doc/device-tree-bindings/clock/st,stm32mp1.txt 
b/doc/device-tree-bindings/clock/st,stm32mp1.txt
new file mode 100644
index 000..c29d90f
--- /dev/null
+++ b/doc/device-tree-bindings/clock/st,stm32mp1.txt
@@ -0,0 +1,226 @@
+STMicroelectronics STM32MP1 clock tree initialization
+=
+
+The STM32MP clock tree initialization is based on device tree information
+for RCC IP and on fixed clocks.
+
+---
+RCC CLOCK = st,stm32mp1-rcc-clk
+---
+
+The RCC IP is both a reset and a clock controller but this documentation only
+describes the fields added for clock tree initialization which are not present
+in Linux binding.
+
+Please refer to ../mfd/st,stm32-rcc.txt for all the other properties common
+with Linux.
+
+Required properties:
+
+- compatible: Should be "st,stm32mp1-rcc-clk"
+
+- st,clksrc : The clock source in this order
+
+   for STM32MP15x: 9 clock sources are requested
+   MPU AXI MCU PLL12 PLL3 PLL4 RTC MCO1 MCO2
+
+   with value equals to RCC clock specifier as defined in
+   dt-bindings/clock/stm32mp1-clksrc.h: CLK__
+
+- st,clkdiv : The div parameters in this order
+   for STM32MP15x: 11 dividers value are requested
+   MPU AXI MCU APB1 APB2 APB3 APB4 APB5 RTC MCO1 MCO2
+
+   with DIV coding defined in RCC associated register RCC_xxxDIVR
+
+   most the case, it is:
+   0x0: not divided
+   0x1: division by 2
+   0x2: division by 4
+   0x3: division by 8
+   ...
+
+   but for RTC MCO1 MCO2, the coding is different:
+   0x0: not divided
+   0x1: division by 2
+   0x2: division by 3
+   0x3: division by 4
+   ...
+
+Optional Properties:
+- st,pll
+PLL children node for PLL1 to PLL4 : (see ref manual for details)
+with associated index 0 to 3 (st,pll@0 to st,pll@4)
+PLLx is off when the associated node is absent
+
+- Sub-nodes:
+
+   - cfg:  The parameters for PLL configuration in this order:
+   DIVM DIVN DIVP DIVQ DIVR Output
+
+   with DIV value as defined in RCC spec:
+   0x0: bypass (division by 1)
+   0x1: division by 2
+   0x2: division by 3
+   0x3: division by 4
+   ...
+
+   and Output = bitfield for each output value = 1:ON/0:OFF
+   BIT(0) => output P : DIVPEN
+   BIT(1) => output Q : DIVQEN
+   BIT(2) => output R : DIVREN
+ NB : macro PQR(p,q,r) can be used to build this value
+  with p,p,r = 0 or 1
+
+   - frac : Fractional part of the multiplication factor
+   (optional, PLL is in integer mode when absent)
+
+   - csg : Clock Spreading Generator (optional)
+   with parameters in this order:
+   MOD_PER INC_STEP SSCG_MODE
+
+   * MOD_PER: Modulation Period Adjustment
+   * INC_STEP: Modulation Depth Adjustment
+   * SSCG_MODE: Spread spectrum clock generator mode
+ you can use associated defines from stm32mp1-clksrc.h
+ * SSCG_MODE_CENTER_SPREAD = 0
+ * SSCG_MODE_DOWN_SPREAD = 1
+
+
+- st,pkcs : used to configure the peripherals kernel clock selection
+  containing a list of peripheral kernel clock source identifier as defined
+  in the file dt-bindings/clock/stm32mp1-clksrc.h
+
+  Example:
+
+   rcc: rcc@5000 {
+   compatible = "syscon", "simple-mfd";
+
+   reg = <0x5000 0x1000>;
+
+   rcc_clk: rcc-clk@5000 {
+   #clock-cells = <1>;
+   compatible = "st,stm32mp1-rcc-clk";
+
+   st,clksrc = <   CLK_MPU_PLL1P
+   CLK_AXI_PLL2P
+   CLK_MCU_HSI
+   CLK_PLL12_HSE
+   CLK_PLL3_HSE
+   CLK_PLL4_HSE
+   CLK_RTC_HSE
+   CLK_MCO1_DISABLED
+   CLK_MCO2_DISABLED
+   >;
+
+   st,clkdiv 

[U-Boot] [PATCH v2 03/15] arm: armv7: solve issue for timer_rate_hz in arch timer

[Patrick Delaunay]

The current value timer_rate_hz causes a problem with function
timer_get_us() from lib time and then an issue with
readx_poll_timeout() function.

With corrected value for tbclk() = timer_rate_hz = CONFIG_SYS_HZ_CLOCK
the weak functions in lib timer can be used:
- get_timer()
- __udelay()
So the specific function in this file are removed.

Signed-off-by: Patrick Delaunay 
---
this patch avoid issue in driver with readl_poll_timeout()

Following source code has been used to demonstrate the issue
(with CONFIG_SYS_HZ_CLOCK = 64 MHz)

printf("Tick= %llx us=%lx boot us=%lx\n",
   get_ticks(), timer_get_us(), timer_get_boot_us());
mdelay(1000);
printf("Tick= %llx us=%lx boot us=%lx\n",
   get_ticks(), timer_get_us(), timer_get_boot_us());

Result:

Tick= 36fad40 us=35b0f45f boot us=dbeb8
Tick= 743b21e us=7181c02e boot us=1d0ecb

=> 1000ms : 0x1d0ecb-0xdbeb8 = 0xF5013
for timer_get_boot_us = 100 us
=> timer_get_boot_us is OK
=> 1000ms : 0x7181c02e-0x35b0f45f = 0x3BD0CBCF = 1.000.000.000 us
   for timer_get_us() which gives a invalid value
   (based on CONFIG_SYS_HZ and get_tbclk())

This patch resolves the issue.


Changes in v2: None

 arch/arm/cpu/armv7/arch_timer.c | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/cpu/armv7/arch_timer.c b/arch/arm/cpu/armv7/arch_timer.c
index 30915d2..545c518 100644
--- a/arch/arm/cpu/armv7/arch_timer.c
+++ b/arch/arm/cpu/armv7/arch_timer.c
@@ -17,7 +17,7 @@ int timer_init(void)
gd->arch.tbl = 0;
gd->arch.tbu = 0;
 
-   gd->arch.timer_rate_hz = CONFIG_SYS_HZ_CLOCK / CONFIG_SYS_HZ;
+   gd->arch.timer_rate_hz = CONFIG_SYS_HZ_CLOCK;
return 0;
 }
 
@@ -34,27 +34,9 @@ unsigned long long get_ticks(void)
 }
 
 
-ulong get_timer(ulong base)
-{
-   return lldiv(get_ticks(), gd->arch.timer_rate_hz) - base;
-}
-
 ulong timer_get_boot_us(void)
 {
-   return lldiv(get_ticks(), CONFIG_SYS_HZ_CLOCK / (CONFIG_SYS_HZ * 1000));
-}
-
-void __udelay(unsigned long usec)
-{
-   unsigned long long endtime;
-
-   endtime = lldiv((unsigned long long)usec * gd->arch.timer_rate_hz,
-   1000UL);
-
-   endtime += get_ticks();
-
-   while (get_ticks() < endtime)
-   ;
+   return lldiv(get_ticks(), CONFIG_SYS_HZ_CLOCK / 100);
 }
 
 ulong get_tbclk(void)
-- 
2.7.4

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

[U-Boot] [PATCH v2 02/15] spl: add SPL_RESET_SUPPORT

[Patrick Delaunay]

Add option to include RESET driver and uclass in SPL.
That can be useful to handle IP reset with same driver
in U-Boot and in SPL.

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 common/spl/Kconfig | 9 +
 drivers/Makefile   | 1 +
 2 files changed, 10 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 9609fce..b9b9e0f 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -568,6 +568,15 @@ config SPL_POST_MEM_SUPPORT
  performed before booting. This enables the drivers in post/drivers
  as part of an SPL build.
 
+config SPL_RESET_SUPPORT
+   bool "Support reset drivers"
+   depends on SPL
+   help
+ Enable support for reset control in SPL.
+ That can be useful in SPL to handle IP reset in driver, as in U-Boot,
+ by using the generic reset API provided by driver model.
+ This enables the drivers in drivers/reset as part of an SPL build.
+
 config SPL_POWER_SUPPORT
bool "Support power drivers"
help
diff --git a/drivers/Makefile b/drivers/Makefile
index 2673428..6846d18 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_ARMADA_XP) += ddr/marvell/axp/
 obj-$(CONFIG_ALTERA_SDRAM) += ddr/altera/
 obj-$(CONFIG_SPL_POWER_SUPPORT) += power/ power/pmic/
 obj-$(CONFIG_SPL_POWER_SUPPORT) += power/regulator/
+obj-$(CONFIG_SPL_RESET_SUPPORT) += reset/
 obj-$(CONFIG_SPL_MTD_SUPPORT) += mtd/
 obj-$(CONFIG_SPL_ONENAND_SUPPORT) += mtd/onenand/
 obj-$(CONFIG_SPL_UBI) += mtd/ubispl/
-- 
2.7.4

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

[U-Boot] [PATCH v2 05/15] gpio: stm32f7_gpio: handle node ngpios

[Patrick Delaunay]

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 drivers/gpio/stm32f7_gpio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/stm32f7_gpio.c b/drivers/gpio/stm32f7_gpio.c
index 11bc66d..376e86c 100644
--- a/drivers/gpio/stm32f7_gpio.c
+++ b/drivers/gpio/stm32f7_gpio.c
@@ -90,7 +90,8 @@ static int gpio_stm32_probe(struct udevice *dev)
if (!name)
return -EINVAL;
uc_priv->bank_name = name;
-   uc_priv->gpio_count = STM32_GPIOS_PER_BANK;
+   uc_priv->gpio_count = dev_read_u32_default(dev, "ngpios",
+  STM32_GPIOS_PER_BANK);
debug("%s, addr = 0x%p, bank_name = %s\n", __func__, (u32 *)priv->regs,
  uc_priv->bank_name);
 
-- 
2.7.4

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

[U-Boot] [PATCH v2 04/15] dm: gpio: Convert stm32f7 driver to livetree

[Patrick Delaunay]

Update the GPIO driver to support a live device tree.

Reviewed-by: Simon Glass 
Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 drivers/gpio/stm32f7_gpio.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpio/stm32f7_gpio.c b/drivers/gpio/stm32f7_gpio.c
index a7cfb8c..11bc66d 100644
--- a/drivers/gpio/stm32f7_gpio.c
+++ b/drivers/gpio/stm32f7_gpio.c
@@ -16,14 +16,11 @@
 #include 
 #include 
 
-#define MAX_SIZE_BANK_NAME 5
 #define STM32_GPIOS_PER_BANK   16
 #define MODE_BITS(gpio_pin)(gpio_pin * 2)
 #define MODE_BITS_MASK 3
 #define IN_OUT_BIT_INDEX(gpio_pin) (1UL << (gpio_pin))
 
-DECLARE_GLOBAL_DATA_PTR;
-
 static int stm32_gpio_direction_input(struct udevice *dev, unsigned offset)
 {
struct stm32_gpio_priv *priv = dev_get_priv(dev);
@@ -82,17 +79,14 @@ static int gpio_stm32_probe(struct udevice *dev)
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
struct stm32_gpio_priv *priv = dev_get_priv(dev);
fdt_addr_t addr;
-   char *name;
+   const char *name;
 
-   addr = devfdt_get_addr(dev);
+   addr = dev_read_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
 
priv->regs = (struct stm32_gpio_regs *)addr;
-   name = (char *)fdtdec_locate_byte_array(gd->fdt_blob,
-   dev_of_offset(dev),
-   "st,bank-name",
-   MAX_SIZE_BANK_NAME);
+   name = dev_read_string(dev, "st,bank-name");
if (!name)
return -EINVAL;
uc_priv->bank_name = name;
-- 
2.7.4

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

[U-Boot] [PATCH 4/4] common: move board_info.c prototypes in init.h

[Patrick Delaunay]

Move function prototype for common/init/board_init.c
from common.h to init.h

Signed-off-by: Patrick Delaunay 
---

 include/common.h | 3 +--
 include/init.h   | 3 +++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/common.h b/include/common.h
index 7d181da..a0633f3 100644
--- a/include/common.h
+++ b/include/common.h
@@ -66,6 +66,7 @@ typedef void (interrupt_handler_t)(void *);
  * common/board_f.c
  * common/init/board_init.c
  * common/board_r.c
+ * common/board_info.c
  */
 #include 
 
@@ -96,8 +97,6 @@ int run_command_repeatable(const char *cmd, int flag);
  */
 int run_command_list(const char *cmd, int len, int flag);
 
-int checkboard(void);
-int show_board_info(void);
 int checkflash(void);
 int checkdram(void);
 extern u8 __dtb_dt_begin[];/* embedded device tree blob */
diff --git a/include/init.h b/include/init.h
index 89e48f2..d54d519 100644
--- a/include/init.h
+++ b/include/init.h
@@ -163,6 +163,9 @@ int misc_init_r(void);
 int init_func_vid(void);
 #endif
 
+/* common/board_info.c */
+int checkboard(void);
+int show_board_info(void);
 
 #endif /* __ASSEMBLY__ */
 /* Put only stuff here that the assembler can digest */
-- 
2.7.4

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

[U-Boot] [PATCH 2/4] common: move board_init.c prototypes in init.h

[Patrick Delaunay]

Move function prototypes for common/init/board_init.c
from common.h to init.h

Signed-off-by: Patrick Delaunay 
---

 include/common.h | 38 +-
 include/init.h   | 39 +++
 2 files changed, 40 insertions(+), 37 deletions(-)

diff --git a/include/common.h b/include/common.h
index 6176195..62630db 100644
--- a/include/common.h
+++ b/include/common.h
@@ -64,6 +64,7 @@ typedef void (interrupt_handler_t)(void *);
 
 /* startup functions, used in:
  * common/board_f.c
+ * common/init/board_init.c
  */
 #include 
 
@@ -97,48 +98,11 @@ int run_command_list(const char *cmd, int len, int flag);
 /* arch/$(ARCH)/lib/board.c */
 void board_init_r(gd_t *, ulong) __attribute__ ((noreturn));
 
-/**
- * ulong board_init_f_alloc_reserve - allocate reserved area
- *
- * This function is called by each architecture very early in the start-up
- * code to allow the C runtime to reserve space on the stack for writable
- * 'globals' such as GD and the malloc arena.
- *
- * @top:   top of the reserve area, growing down.
- * @return:bottom of reserved area
- */
-ulong board_init_f_alloc_reserve(ulong top);
-
-/**
- * board_init_f_init_reserve - initialize the reserved area(s)
- *
- * This function is called once the C runtime has allocated the reserved
- * area on the stack. It must initialize the GD at the base of that area.
- *
- * @base:  top from which reservation was done
- */
-void board_init_f_init_reserve(ulong base);
-
-/**
- * arch_setup_gd() - Set up the global_data pointer
- *
- * This pointer is special in some architectures and cannot easily be assigned
- * to. For example on x86 it is implemented by adding a specific record to its
- * Global Descriptor Table! So we we provide a function to carry out this task.
- * For most architectures this can simply be:
- *
- *gd = gd_ptr;
- *
- * @gd_ptr:Pointer to global data
- */
-void arch_setup_gd(gd_t *gd_ptr);
-
 int checkboard(void);
 int show_board_info(void);
 int checkflash(void);
 int checkdram(void);
 int last_stage_init(void);
-extern ulong monitor_flash_len;
 int mac_read_from_eeprom(void);
 extern u8 __dtb_dt_begin[];/* embedded device tree blob */
 extern u8 __dtb_dt_spl_begin[];/* embedded device tree blob for 
SPL/TPL */
diff --git a/include/init.h b/include/init.h
index f57a438..f952602 100644
--- a/include/init.h
+++ b/include/init.h
@@ -109,6 +109,45 @@ int misc_init_f(void);
 int embedded_dtb_select(void);
 #endif
 
+/* common/init/board_init.c */
+extern ulong monitor_flash_len;
+
+/**
+ * ulong board_init_f_alloc_reserve - allocate reserved area
+ *
+ * This function is called by each architecture very early in the start-up
+ * code to allow the C runtime to reserve space on the stack for writable
+ * 'globals' such as GD and the malloc arena.
+ *
+ * @top:   top of the reserve area, growing down.
+ * @return:bottom of reserved area
+ */
+ulong board_init_f_alloc_reserve(ulong top);
+
+/**
+ * board_init_f_init_reserve - initialize the reserved area(s)
+ *
+ * This function is called once the C runtime has allocated the reserved
+ * area on the stack. It must initialize the GD at the base of that area.
+ *
+ * @base:  top from which reservation was done
+ */
+void board_init_f_init_reserve(ulong base);
+
+/**
+ * arch_setup_gd() - Set up the global_data pointer
+ *
+ * This pointer is special in some architectures and cannot easily be assigned
+ * to. For example on x86 it is implemented by adding a specific record to its
+ * Global Descriptor Table! So we we provide a function to carry out this task.
+ * For most architectures this can simply be:
+ *
+ *gd = gd_ptr;
+ *
+ * @gd_ptr:Pointer to global data
+ */
+void arch_setup_gd(gd_t *gd_ptr);
+
 /* common/board_r.c */
 
 #endif /* __ASSEMBLY__ */
-- 
2.7.4

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

[U-Boot] [PATCH 3/4] common: move board_r.c prototypes in init.h

[Patrick Delaunay]

Move function prototypes used in common/board_r.c
from common.h to init.h

Signed-off-by: Patrick Delaunay 
---

 include/common.h | 17 +
 include/init.h   | 14 ++
 2 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/include/common.h b/include/common.h
index 62630db..7d181da 100644
--- a/include/common.h
+++ b/include/common.h
@@ -65,6 +65,7 @@ typedef void (interrupt_handler_t)(void *);
 /* startup functions, used in:
  * common/board_f.c
  * common/init/board_init.c
+ * common/board_r.c
  */
 #include 
 
@@ -95,21 +96,13 @@ int run_command_repeatable(const char *cmd, int flag);
  */
 int run_command_list(const char *cmd, int len, int flag);
 
-/* arch/$(ARCH)/lib/board.c */
-void board_init_r(gd_t *, ulong) __attribute__ ((noreturn));
-
 int checkboard(void);
 int show_board_info(void);
 int checkflash(void);
 int checkdram(void);
-int last_stage_init(void);
-int mac_read_from_eeprom(void);
 extern u8 __dtb_dt_begin[];/* embedded device tree blob */
 extern u8 __dtb_dt_spl_begin[];/* embedded device tree blob for 
SPL/TPL */
-int set_cpu_clk_info(void);
 int mdm_init(void);
-int update_flash_size(int flash_size);
-int arch_early_init_r(void);
 
 /*
  * setup_board_extra() - Fill in extra details in the bd_t structure
@@ -263,14 +256,8 @@ int env_complete(char *var, int maxv, char *cmdv[], int 
maxsz, char *buf);
 #endif
 int get_env_id (void);
 
-void   pci_init  (void);
 void   pci_init_board(void);
 
-intmisc_init_r   (void);
-#if defined(CONFIG_VID)
-intinit_func_vid(void);
-#endif
-
 /* common/exports.c */
 void   jumptable_init(void);
 
@@ -396,8 +383,6 @@ int get_clocks (void);
 ulong  get_bus_freq  (ulong);
 int get_serial_clock(void);
 
-intcpu_init_r(void);
-
 /* $(CPU)/interrupts.c */
 intinterrupt_init (void);
 void   timer_interrupt(struct pt_regs *);
diff --git a/include/init.h b/include/init.h
index f952602..89e48f2 100644
--- a/include/init.h
+++ b/include/init.h
@@ -149,6 +149,20 @@ void board_init_f_init_reserve(ulong base);
 void arch_setup_gd(gd_t *gd_ptr);
 
 /* common/board_r.c */
+void board_init_r(gd_t *id, ulong dest_addr) __attribute__ ((noreturn));
+
+int cpu_init_r(void);
+int last_stage_init(void);
+int mac_read_from_eeprom(void);
+int set_cpu_clk_info(void);
+int update_flash_size(int flash_size);
+int arch_early_init_r(void);
+void pci_init(void);
+int misc_init_r(void);
+#if defined(CONFIG_VID)
+int init_func_vid(void);
+#endif
+
 
 #endif /* __ASSEMBLY__ */
 /* Put only stuff here that the assembler can digest */
-- 
2.7.4

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

[U-Boot] [PATCH 1/4] common: move board_f.c prototypes in init.h

[Patrick Delaunay]

Move prototypes for function used in common/board_f.c
from common.h to init.h
Remove weak for arch_reserve_stacks (checkpatch issue)

Signed-off-by: Patrick Delaunay 
---

 include/common.h | 70 +++-
 include/init.h   | 66 
 2 files changed, 69 insertions(+), 67 deletions(-)

diff --git a/include/common.h b/include/common.h
index 11e5459..6176195 100644
--- a/include/common.h
+++ b/include/common.h
@@ -62,34 +62,16 @@ typedef void (interrupt_handler_t)(void *);
 #defineTOTAL_MALLOC_LENCONFIG_SYS_MALLOC_LEN
 #endif
 
-/* startup functions */
+/* startup functions, used in:
+ * common/board_f.c
+ */
 #include 
 
 /*
  * Function Prototypes
  */
-int dram_init(void);
-
-/**
- * dram_init_banksize() - Set up DRAM bank sizes
- *
- * This can be implemented by boards to set up the DRAM bank information in
- * gd->bd->bi_dram(). It is called just before relocation, after dram_init()
- * is called.
- *
- * If this is not provided, a default implementation will try to set up a
- * single bank. It will do this if CONFIG_NR_DRAM_BANKS and
- * CONFIG_SYS_SDRAM_BASE are set. The bank will have a start address of
- * CONFIG_SYS_SDRAM_BASE and the size will be determined by a call to
- * get_effective_memsize().
- *
- * @return 0 if OK, -ve on error
- */
-int dram_init_banksize(void);
-
 void   hang(void) __attribute__ ((noreturn));
 
-inttimer_init(void);
 intcpu_init(void);
 
 #include 
@@ -113,7 +95,6 @@ int run_command_repeatable(const char *cmd, int flag);
 int run_command_list(const char *cmd, int len, int flag);
 
 /* arch/$(ARCH)/lib/board.c */
-void board_init_f(ulong);
 void board_init_r(gd_t *, ulong) __attribute__ ((noreturn));
 
 /**
@@ -163,7 +144,6 @@ extern u8 __dtb_dt_begin[]; /* embedded device tree blob */
 extern u8 __dtb_dt_spl_begin[];/* embedded device tree blob for 
SPL/TPL */
 int set_cpu_clk_info(void);
 int mdm_init(void);
-int print_cpuinfo(void);
 int update_flash_size(int flash_size);
 int arch_early_init_r(void);
 
@@ -175,44 +155,6 @@ int arch_early_init_r(void);
 int setup_board_extra(void);
 
 /**
- * arch_fsp_init() - perform firmware support package init
- *
- * Where U-Boot relies on binary blobs to handle part of the system init, this
- * function can be used to set up the blobs. This is used on some Intel
- * platforms.
- */
-int arch_fsp_init(void);
-
-/**
- * arch_cpu_init_dm() - init CPU after driver model is available
- *
- * This is called immediately after driver model is available before
- * relocation. This is similar to arch_cpu_init() but is able to reference
- * devices
- *
- * @return 0 if OK, -ve on error
- */
-int arch_cpu_init_dm(void);
-
-/**
- * Reserve all necessary stacks
- *
- * This is used in generic board init sequence in common/board_f.c. Each
- * architecture could provide this function to tailor the required stacks.
- *
- * On entry gd->start_addr_sp is pointing to the suggested top of the stack.
- * The callee ensures gd->start_add_sp is 16-byte aligned, so architectures
- * require only this can leave it untouched.
- *
- * On exit gd->start_addr_sp and gd->irq_sp should be set to the respective
- * positions of the stack. The stack pointer(s) will be set to this later.
- * gd->irq_sp is only required, if the architecture needs it.
- *
- * @return 0 if no error
- */
-__weak int arch_reserve_stacks(void);
-
-/**
  * Show the DRAM size in a board-specific way
  *
  * This is used by boards to display DRAM information in their own way.
@@ -231,7 +173,6 @@ void board_show_dram(phys_size_t size);
  */
 int arch_fixup_fdt(void *blob);
 
-int reserve_mmu(void);
 /* common/flash.c */
 void flash_perror (int);
 
@@ -361,11 +302,6 @@ int get_env_id (void);
 void   pci_init  (void);
 void   pci_init_board(void);
 
-#if defined(CONFIG_DTB_RESELECT)
-intembedded_dtb_select(void);
-#endif
-
-intmisc_init_f   (void);
 intmisc_init_r   (void);
 #if defined(CONFIG_VID)
 intinit_func_vid(void);
diff --git a/include/init.h b/include/init.h
index 324fbe0..f57a438 100644
--- a/include/init.h
+++ b/include/init.h
@@ -18,6 +18,7 @@
  */
 
 /* common/board_f.c */
+void board_init_f(ulong dummy);
 
 /**
  * arch_cpu_init() - basic cpu-dependent setup for an architecture
@@ -32,6 +33,17 @@
 int arch_cpu_init(void);
 
 /**
+ * arch_cpu_init_dm() - init CPU after driver model is available
+ *
+ * This is called immediately after driver model is available before
+ * relocation. This is similar to arch_cpu_init() but is able to reference
+ * devices
+ *
+ * @return 0 if OK, -ve on error
+ */
+int arch_cpu_init_dm(void);
+
+/**
  * mach_cpu_init() - SoC/machine dependent CPU setup
  *
  * This is called after arch_cpu_init(). It should handle any
@@ -43,6 +55,60 @@ int arch_cpu_init(void);
  */
 int mach_cpu_init(void);
 
+/**
+ * arch_fsp_init() - perform firmware support package init
+ *
+ * 

[U-Boot] [PATCH 0/4] common: move startup function prototypes in init.h

[Patrick Delaunay]

I push this serie after Masahiro Yamada's comment
on patch "common: add a prototype for mach_cpu_init()"

The serie depends on v3 of this patch for the added
file init.h

I just moved the function used in:
 common/board_f.c
 common/init/board_init.c
 common/board_r.c
 common/board_info.c
and solve the checkpatch issue.

It is a step for common.h cleanup and I don't add
documentation for the moved functions.

I don't know if other functions need to be moved:
  $(BOARD)/$(BOARD).c ?
  $(CPU)/start.S ?

or if the order of the new file init.h is correct.



Patrick Delaunay (4):
  common: move board_f.c prototypes in init.h
  common: move board_init.c prototypes in init.h
  common: move board_r.c prototypes in init.h
  common: move board_info.c prototypes in init.h

 include/common.h | 128 +++
 include/init.h   | 122 
 2 files changed, 128 insertions(+), 122 deletions(-)

-- 
2.7.4

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

[U-Boot] [PATCH] post: remove reference to power functions

[Patrick Delaunay]

The 2 functions board_power_mode and board_poweroff
are no more existing in U-Boot code (check with grep)
This patch updates the documentation and removes
the unnecessary prototypes.

Signed-off-by: Patrick Delaunay 
---

 doc/README.POST  | 11 ---
 include/common.h |  1 -
 2 files changed, 12 deletions(-)

diff --git a/doc/README.POST b/doc/README.POST
index a9335f4..43f424f 100644
--- a/doc/README.POST
+++ b/doc/README.POST
@@ -159,17 +159,6 @@ The POST layer will export the following interface 
routines:
 Also, the following board-specific routines will be called from the
 U-Boot common code:
 
-  o) int board_power_mode(void)
-
- This routine will return the mode the system is running in
- (POST_POWERON, POST_NORMAL or POST_SHUTDOWN).
-
-  o) void board_poweroff(void)
-
- This routine will turn off the power supply of the board. It
- will be called on power-fail booting after running all POST
- tests.
-
   o) int post_hotkeys_pressed(gd_t *gd)
 
  This routine will scan the keyboard to detect if a magic key
diff --git a/include/common.h b/include/common.h
index 0fe9439..537dd04 100644
--- a/include/common.h
+++ b/include/common.h
@@ -422,7 +422,6 @@ int board_fix_fdt (void *rw_fdt_blob); /* manipulate the 
U-Boot fdt before its r
 int board_late_init (void);
 int board_postclk_init (void); /* after clocks/timebase, before env/serial */
 int board_early_init_r (void);
-void board_poweroff (void);
 
 #if defined(CONFIG_SYS_DRAM_TEST)
 int testdram(void);
-- 
2.7.4

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

[U-Boot] [PATCH] common: remove unused prototypes

[Patrick Delaunay]

Remove the prototypes for 4 functions no more existing
in U-Boot code (checked by grep):
- checkflash
- checkdram
- mdm_init
- setup_board_extra

Signed-off-by: Patrick Delaunay 
---

 include/common.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/include/common.h b/include/common.h
index 0fe9439..0728aa6 100644
--- a/include/common.h
+++ b/include/common.h
@@ -151,26 +151,16 @@ void arch_setup_gd(gd_t *gd_ptr);
 
 int checkboard(void);
 int show_board_info(void);
-int checkflash(void);
-int checkdram(void);
 int last_stage_init(void);
 extern ulong monitor_flash_len;
 int mac_read_from_eeprom(void);
 extern u8 __dtb_dt_begin[];/* embedded device tree blob */
 extern u8 __dtb_dt_spl_begin[];/* embedded device tree blob for 
SPL/TPL */
 int set_cpu_clk_info(void);
-int mdm_init(void);
 int print_cpuinfo(void);
 int update_flash_size(int flash_size);
 int arch_early_init_r(void);
 
-/*
- * setup_board_extra() - Fill in extra details in the bd_t structure
- *
- * @return 0 if OK, -ve on error
- */
-int setup_board_extra(void);
-
 /**
  * arch_fsp_init() - perform firmware support package init
  *
-- 
2.7.4

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

Re: [U-Boot] hardware versions to Kernel

[Chris Packham]

On Sat, Mar 10, 2018 at 6:34 AM, Andy Rea  wrote:
> I have an ARM CPU on a board that has 3 optional sub boards plugged into it,
> all of which have 3 hardware rev bits connected to the CPU
>
>
>
> Rather than getting the CPU to do mmap type stuff or sys/class/gpio stuff to
> read those versions in the kernel, is there a way for u-boot to push that
> information ( even it's a U32 or a string ) into the kernel somewhere that
> can be parsed?  I tried some code in the board startup to create env vars to
> append into the bootargs but they aren't evaluated each boot properly (
> boards are optional and revs can change )  so cat /proc/cmdlne stayed the
> same value all the time
>
>
>
> Is there a better way to do this?

I've done something similar in the past by having u-boot manipulate
the device-tree passed to the kernel with a few calls to
fdt_setprop(). It's practical when you have a few tweaks to make. I've
used it for telling the kernel to disable bits of hardware on
prototype boards.

For more substantial configurations you could use a FIT image[1]. I've
also used this for having u-boot tell the kernel about plug-in boards.
Ultimately we ended up switching to device-tree overlays once the
kernel support caught up so that we could support hot-plugging boards.

[1] - 
http://git.denx.de/?p=u-boot.git;a=blob_plain;f=doc/uImage.FIT/howto.txt;hb=HEAD
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot