Re: [U-Boot] [PATCH v3] spl: add support to booting with ATF

[Masahiro Yamada]

2017-04-05 14:05 GMT+09:00 Kever Yang :
> ATF(ARM Trusted Firmware) is used by ARM arch64 SoCs, find more infomation
> about ATF at: https://github.com/ARM-software/arm-trusted-firmware
>
> SPL is considered as BL2 in ATF terminology, it needs to load other parts
> of ATF binary like BL31, BL32, SCP-BL30, and BL33(U-Boot). And needs to


SCP-BL30 ?


Dan,

I see BL30 in old documents, but this was deprecated, right?


bl2/bl2_image_load.c implies that:

/*
 * Check for platforms that use obsolete image terminology
 */
#ifdef BL30_BASE
# error "BL30_BASE platform define no longer used - please use SCP_BL2_BASE"
#endif



What is the correct terminology for the SCP firmware
on the latest code base?

SCP_BL2 ?



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

[U-Boot] [PATCH v3 0/1] arm64: enable SPL with ATF support

[Kever Yang]

This patch needs work with some patch for SPL support multi
binary in FIT which is from Andre.

The entry point of bl31 and bl33 is still using hard code because we
still can not get them from the FIT image information.

This patch tested on rk3399 platform.


Changes in v3:
- remove no neccessary Macro definition in header file.
- rename some Macro with 'ATF_' prefix.

Changes in v2:
- Kconfig comment update with Simon's suggestion
- including file ordering,
- update function comment format,
- use 'if' instead of '#ifdef' for bl31_entry
- add ATF Kconfig option depend on ARM64

Changes in v1:
- license update
- split out as separate patch

Kever Yang (1):
  spl: add support to booting with ATF

 common/spl/Kconfig   |  14 
 common/spl/Makefile  |   1 +
 common/spl/spl.c |   3 +
 common/spl/spl_atf.c |  97 +++
 include/atf_common.h | 183 +++
 include/spl.h|   1 +
 6 files changed, 299 insertions(+)
 create mode 100644 common/spl/spl_atf.c
 create mode 100644 include/atf_common.h

-- 
1.9.1

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

[U-Boot] [PATCH v3] spl: add support to booting with ATF

[Kever Yang]

ATF(ARM Trusted Firmware) is used by ARM arch64 SoCs, find more infomation
about ATF at: https://github.com/ARM-software/arm-trusted-firmware

SPL is considered as BL2 in ATF terminology, it needs to load other parts
of ATF binary like BL31, BL32, SCP-BL30, and BL33(U-Boot). And needs to
prepare the parameter for BL31 which including entry and image information
for all other images. Then the SPL handle PC to BL31 with the parameter,
the BL31 will do the rest of work and at last get into U-Boot(BL33).

Signed-off-by: Kever Yang 
---

Changes in v3:
- remove no neccessary Macro definition in header file.
- rename some Macro with 'ATF_' prefix.

Changes in v2:
- Kconfig comment update with Simon's suggestion
- including file ordering,
- update function comment format,
- use 'if' instead of '#ifdef' for bl31_entry
- add ATF Kconfig option depend on ARM64

Changes in v1:
- license update
- split out as separate patch

 common/spl/Kconfig   |  14 
 common/spl/Makefile  |   1 +
 common/spl/spl.c |   3 +
 common/spl/spl_atf.c |  97 +++
 include/atf_common.h | 183 +++
 include/spl.h|   1 +
 6 files changed, 299 insertions(+)
 create mode 100644 common/spl/spl_atf.c
 create mode 100644 include/atf_common.h

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 60ae60c..1b7fb8d 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -670,6 +670,20 @@ config SPL_YMODEM_SUPPORT
  means of transmitting U-Boot over a serial line for using in SPL,
  with a checksum to ensure correctness.
 
+config SPL_ATF_SUPPORT
+   bool "Support ARM Trusted Firmware"
+   depends on SPL && ARM64
+   help
+ ATF(ARM Trusted Firmware) is a component for ARM arch64 which which
+ is loaded by SPL(which is considered as BL2 in ATF terminology).
+ More detail at: https://github.com/ARM-software/arm-trusted-firmware
+
+config SPL_ATF_TEXT_BASE
+   depends on SPL_ATF_SUPPORT
+   hex "ATF TEXT BASE addr"
+   help
+ This is the base address in memory for ATF text and entry point.
+
 config TPL_ENV_SUPPORT
bool "Support an environment"
depends on TPL
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 1933cbd..b3b34d6 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -20,6 +20,7 @@ endif
 obj-$(CONFIG_SPL_UBI) += spl_ubi.o
 obj-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
 obj-$(CONFIG_SPL_MMC_SUPPORT) += spl_mmc.o
+obj-$(CONFIG_SPL_ATF_SUPPORT) += spl_atf.o
 obj-$(CONFIG_SPL_USB_SUPPORT) += spl_usb.o
 obj-$(CONFIG_SPL_FAT_SUPPORT) += spl_fat.o
 obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 26bc9ef..7041e1b 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -374,6 +374,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
  gd->malloc_ptr / 1024);
 #endif
 
+   if (IS_ENABLED(CONFIG_SPL_ATF_SUPPORT))
+   bl31_entry();
+
debug("loaded - jumping to U-Boot...\n");
spl_board_prepare_for_boot();
jump_to_image_no_args(_image);
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
new file mode 100644
index 000..c5a4bf1
--- /dev/null
+++ b/common/spl/spl_atf.c
@@ -0,0 +1,97 @@
+/*
+ * Reference to the ARM TF Project,
+ * plat/arm/common/arm_bl2_setup.c
+ * Portions copyright (c) 2013-2016, ARM Limited and Contributors. All rights
+ * reserved.
+ * Copyright (C) 2016 Rockchip Electronic Co.,Ltd
+ * Written by Kever Yang 
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static struct bl2_to_bl31_params_mem_t bl31_params_mem;
+static struct bl31_params_t *bl2_to_bl31_params;
+
+/**
+ * bl2_plat_get_bl31_params() - prepare params for bl31.
+ *
+ * This function assigns a pointer to the memory that the platform has kept
+ * aside to pass platform specific and trusted firmware related information
+ * to BL31. This memory is allocated by allocating memory to
+ * bl2_to_bl31_params_mem_t structure which is a superset of all the
+ * structure whose information is passed to BL31
+ * NOTE: This function should be called only once and should be done
+ * before generating params to BL31
+ *
+ * @return bl31 params structure pointer
+ */
+struct bl31_params_t *bl2_plat_get_bl31_params(void)
+{
+   struct entry_point_info_t *bl33_ep_info;
+
+   /*
+* Initialise the memory for all the arguments that needs to
+* be passed to BL31
+*/
+   memset(_params_mem, 0, sizeof(struct bl2_to_bl31_params_mem_t));
+
+   /* Assign memory for TF related information */
+   bl2_to_bl31_params = _params_mem.bl31_params;
+   SET_PARAM_HEAD(bl2_to_bl31_params, ATF_PARAM_BL31, ATF_VERSION_1, 0);
+
+   /* Fill BL31 related information */
+   SET_PARAM_HEAD(bl2_to_bl31_params->bl31_image_info,
+  

Re: [U-Boot] [PATCH v2] spl: add support to booting with ATF

[Kever Yang]

Hi,


On 04/01/2017 12:22 PM, Simon Glass wrote:

Hi,

On 28 March 2017 at 08:37, Andre Przywara  wrote:

Hi,

On 28/03/17 15:16, Dan Handley wrote:

Hi Kever


-Original Message-
From: Kever Yang [mailto:kever.y...@rock-chips.com]
Sent: 28 March 2017 08:23

Hi Andre,


On 03/23/2017 05:22 PM, Andre Przywara wrote:

Hi Kever,

I was wondering if we really need to copy in all those ATF definitions.
I think this is really an *interface* between the loader (SPL or BL2)
and the runtime services (BL31), so it's supposed to be stable and we
wouldn't need to pull in all those headers.

Yes, you are right, this is an interface between the loader and bl31,
and it's from ATF, just like android image header if from Android
project, so my idea copy the header definition.

So given that, can't we simply model the data structure, which at the
end of the day is just a bunch of simple data types:

I'm sorry, I don't get your point here, what's the benefit for us to re-
define the header data types?

I guess Andre's point was to copy just the essential data structures,
not all the other baggage in that header file.

Yes, that what my intention.
I just wanted to avoid pasting this pretty big and somewhat foreign code
into U-Boot, when all we need is four simple data structures.


Thanks for the detail explain, yes the data structures are the most 
important,

and other definition could be removed if not necessary.



Whenever this gets changed we are in trouble anyway (because we break
compatibility).

Yes, we hope it won't change, but it depends on ATF not U-Boot, no
matter what kind if data type we using in U-Boot, we can not stop this,
it's the ATF break the compatibility, not U-Boot SPL.

But as mentioned below, ATF can handle multiple versions, so it can keep
compatibility.


So what are the opinions on this? Pull in the ATF source or define our
own and mark it as an ATF copy?

ATF is the one using all these header structure, if they change there
API and break, yes, we need/have to sync again.

Dan in CC is ATF maintainer.

Hi Dan, are you able to provide some information for the header
structure, for example, is it suppose to change/update in the future?


The ARM TF BL31 interface is defined here:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.md#required-cpu-state-when-calling-bl31_entrypoint-during-cold-boot

In summary, the arguments passed to BL31 in X0 and X1 are platform
specific and not used by generic BL31 code. Conventionally, X0 has been
used by TF BL2 to pass a bl31_params structure, which is used by ARM
Limited platforms and possibly others but not necessarily all. This
structure has now been superseded by a new structure called bl_params,
which caters for AArch32 platforms and should be more futureproof. Both
bl31_params and bl_params are prefixed with metadata in a param_header,
which includes a version number. BL31 platform code could potentially
handle both bl31_params and bl_params by checking the version number but
ARM platforms expect one or the other depending on the value of a build
flag (LOAD_IMAGE_V2). It's hard to say what other platforms do but I
guess a lot of them use bl31_params.

Yes, so with the versioning scheme I don't see many problems. A really
versatile BL31 could handle both, so would be compatible.
At the end of the day I think this is a theoretical issue, as you
usually package ATF, SPL and U-Boot together and can make sure that they
match. It's not like people insert their own bl31 into an existing
image. And with everything being open source you can always rebuild anyway.


I suggest that U-Boot SPL mandates that platforms that wish to use TF
BL31 with U-Boot SPL must use the bl_params structure. It may also need
to mandate that this contains BL33 information specific to U-Boot.

That sounds like a good idea.


Alternatively, U-Boot SPL could define its own structure(s) according to
its needs, and mandate that BL31 platforms it wishes to support conform
to this.

Philipp had the idea of using a small device tree blob to convey
information between the SPL (or any other loader, really) and BL31,
similar to what the FIT does. In fact it could even be the FIT image. So
the bl_params structure would just contain a pointer to that DT blob in
memory, and bl31 then parses this to get as many information as it needs
from the loader, without affecting the actual SPL->BL31 interface. Yes,
that is another level of indirection, but I think worth to explore - at
least for the future. This would for instance allow the loader to pass
the address of the device DT to bl31, which could then make use of it -
either for getting information or for inserting nodes (PSCI or other
firmware services) - or for both.

Perhaps this could be future work? For now, I suggest we take this
patch once the header file has been cut down.


I agree, I will send one new patch first which remove some MACRO not
used.

Thanks,
- Kever


Regards,

[U-Boot] [PATCH] armv8: ls2081a: Add serdes2 protocol 0x51 support

[Santan Kumar]

Signed-off-by: Santan Kumar 
Signed-off-by: Priyanka Jain 
---
 arch/arm/cpu/armv8/fsl-layerscape/ls2080a_serdes.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls2080a_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls2080a_serdes.c
index ab83e85..4db3c76 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls2080a_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls2080a_serdes.c
@@ -70,6 +70,7 @@ static struct serdes_config serdes2_cfg_tbl[] = {
SATA2 } },
{0x4A, {SGMII9, SGMII10, SGMII11, SGMII12, PCIE4, PCIE4, SATA1,
SATA2 } },
+   {0x51, {PCIE3, PCIE3, PCIE3, PCIE3, PCIE4, PCIE4, PCIE4, PCIE4 } },
{0x57, {PCIE3, PCIE3, PCIE3, PCIE3, PCIE4, PCIE4, SGMII15, SGMII16 } },
{}
 };
-- 
1.9.1

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

Re: [U-Boot] [PATCH 3/3] binman: Remove hard-coded file name for x86 flash-descriptor & intel-me

[Bin Meng]

Hi Simon,

On Sat, Apr 1, 2017 at 12:22 PM, Simon Glass  wrote:
> Hi,
>
> On 31 March 2017 at 09:45, Bin Meng  wrote:
>> On Thu, Mar 30, 2017 at 6:58 PM, Stefan Roese  wrote:
>>> Now that we have added file names from Kconfig in x86 u-boot.dtsi,
>>> update binman to avoid using hard-coded names.
>>>
>>> Signed-off-by: Stefan Roese 
>>> Cc: Bin Meng 
>>> Cc: Simon Glass 
>>> ---
>>>  tools/binman/etype/intel_descriptor.py | 3 ---
>>>  tools/binman/etype/intel_me.py | 3 ---
>>>  2 files changed, 6 deletions(-)
>>>
>>
>> Reviewed-by: Bin Meng 
>
> Please do check that the tests still work (binman -t).
>

Patch posted @ http://patchwork.ozlabs.org/patch/747091/

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

Re: [U-Boot] [PATCH 3/3] binman: Remove hard-coded file name for x86 flash-descriptor & intel-me

[Bin Meng]

On Fri, Mar 31, 2017 at 11:45 PM, Bin Meng  wrote:
> On Thu, Mar 30, 2017 at 6:58 PM, Stefan Roese  wrote:
>> Now that we have added file names from Kconfig in x86 u-boot.dtsi,
>> update binman to avoid using hard-coded names.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Bin Meng 
>> Cc: Simon Glass 
>> ---
>>  tools/binman/etype/intel_descriptor.py | 3 ---
>>  tools/binman/etype/intel_me.py | 3 ---
>>  2 files changed, 6 deletions(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] x86: bootm: Fix FIT image booting on x86

[Bin Meng]

On Wed, Apr 5, 2017 at 10:38 AM, Bin Meng  wrote:
> On Fri, Mar 31, 2017 at 2:09 PM, Stefan Roese  wrote:
>> Checking 'is_zimage' at this time will always fail and therefore booting
>> a FIT style image will always lead to this error message:
>>
>> "## Kernel loading failed (missing x86 kernel setup) ..."
>>
>> This change now removes this check and booting of FIT images works just
>> fine.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> ---
>>  arch/x86/lib/bootm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] x86: Add file names from Kconfig in descriptor/intel-me nodes in u-boot.dtsi

[Bin Meng]

On Fri, Mar 31, 2017 at 11:45 PM, Bin Meng  wrote:
> On Thu, Mar 30, 2017 at 6:58 PM, Stefan Roese  wrote:
>> Since we now have the file names configurable via Kconfig for the flash
>> descriptor and intel-me files, add these from Kconfig in the corresponding
>> dts nodes.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Bin Meng 
>> Cc: Simon Glass 
>> ---
>>  arch/x86/dts/u-boot.dtsi | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] x86: Kconfig: Add options to configure the descriptor.bin / me.bin filenames

[Bin Meng]

On Fri, Mar 31, 2017 at 11:45 PM, Bin Meng  wrote:
> On Thu, Mar 30, 2017 at 6:58 PM, Stefan Roese  wrote:
>> This introduces two Kconfig options to enable board specific filenames
>> for the Intel binary blobs to be used to generate the SPI flash image.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Bin Meng 
>> Cc: Simon Glass 
>> ---
>>  arch/x86/Kconfig | 16 
>>  1 file changed, 16 insertions(+)
>>
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] tools: binman: Add missing filenames for various x86 rom tests

[Bin Meng]

With recent changes, some x86-specific rom tests of binman fail to
run. Fix it by adding missing filenames in corresponding entries.

Signed-off-by: Bin Meng 
---

 tools/binman/test/30_x86-rom-me-no-desc.dts | 1 +
 tools/binman/test/31_x86-rom-me.dts | 2 ++
 tools/binman/test/32_intel-vga.dts  | 1 +
 tools/binman/test/42_intel-fsp.dts  | 1 +
 tools/binman/test/43_intel-cmc.dts  | 1 +
 5 files changed, 6 insertions(+)

diff --git a/tools/binman/test/30_x86-rom-me-no-desc.dts 
b/tools/binman/test/30_x86-rom-me-no-desc.dts
index 4578f66..68d3ce0 100644
--- a/tools/binman/test/30_x86-rom-me-no-desc.dts
+++ b/tools/binman/test/30_x86-rom-me-no-desc.dts
@@ -9,6 +9,7 @@
end-at-4gb;
size = <16>;
intel-me {
+   filename = "me.bin";
pos-unset;
};
};
diff --git a/tools/binman/test/31_x86-rom-me.dts 
b/tools/binman/test/31_x86-rom-me.dts
index b484ab3..ee3dac8 100644
--- a/tools/binman/test/31_x86-rom-me.dts
+++ b/tools/binman/test/31_x86-rom-me.dts
@@ -9,9 +9,11 @@
end-at-4gb;
size = <0x80>;
intel-descriptor {
+   filename = "descriptor.bin";
};
 
intel-me {
+   filename = "me.bin";
pos-unset;
};
};
diff --git a/tools/binman/test/32_intel-vga.dts 
b/tools/binman/test/32_intel-vga.dts
index 1790833..9c532d0 100644
--- a/tools/binman/test/32_intel-vga.dts
+++ b/tools/binman/test/32_intel-vga.dts
@@ -8,6 +8,7 @@
size = <16>;
 
intel-vga {
+   filename = "vga.bin";
};
};
 };
diff --git a/tools/binman/test/42_intel-fsp.dts 
b/tools/binman/test/42_intel-fsp.dts
index e0a1e76..8a7c889 100644
--- a/tools/binman/test/42_intel-fsp.dts
+++ b/tools/binman/test/42_intel-fsp.dts
@@ -8,6 +8,7 @@
size = <16>;
 
intel-fsp {
+   filename = "fsp.bin";
};
};
 };
diff --git a/tools/binman/test/43_intel-cmc.dts 
b/tools/binman/test/43_intel-cmc.dts
index 26c456d..5a56c7d 100644
--- a/tools/binman/test/43_intel-cmc.dts
+++ b/tools/binman/test/43_intel-cmc.dts
@@ -8,6 +8,7 @@
size = <16>;
 
intel-cmc {
+   filename = "cmc.bin";
};
};
 };
-- 
2.9.2

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

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

[Simon Glass]

Hi Tom,

I think we finally have the problems sorted out with the 'rock' board
so this is included here along with two other derivative boards and
various improvements.


The following changes since commit 11db152246607868f0e74db958947fbf79f28119:

  Prepare v2017.05-rc1 (2017-04-04 17:53:24 -0400)

are available in the git repository at:

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

for you to fetch changes up to 7da8680b260b4598d841d9a8432d95d56cb86d9f:

  rockchip: Add support for MiQi rk3288 board (2017-04-04 20:01:57 -0600)


Eddie Cai (1):
  rockchip: dts: firefly: add usb host power supply node

Heiko Stübner (10):
  rockchip: rk3188: enable TPL_LIBGENERIC for generic memset
  rockchip: rk3188: add README.rockchip paragraph describing sd boot
  rockchip: rk3188: sdram: Set correct sdram base
  rockchip: rk3188: Decode the actual amount of ram
  rockchip: rk3188: Cleanup some SPL/TPL rename leftovers
  rockchip: clk: rk3188: Allow configuration of the armclk
  rockchip: rk3188: Setup the armclk in spl
  rockchip: i2c: Add compatibles for Rockchip Cortex-A9 socs
  rockchip: rk3188: follow THUMB_BUILD Kconfig migration
  rockchip: rk3188: Add Radxa Rock board

Jacob Chen (1):
  rockchip: configs: correct mmc env dev for rk3288 based boards

Jakob Unterwurzacher (1):
  rockchip: spi: rk3399: move CONFIG_SPI and CONFIG_SPI_FLASH to defconfig

Jernej Skrabec (3):
  rockchip: video: Split out HDMI controller code
  rockchip: cosmetic: Sort RK3288 boards
  rockchip: Add support for MiQi rk3288 board

Kever Yang (1):
  rockchip: spl: use spl_early_init() instead of spl_init()

Philipp Tomsich (18):
  rockchip: mkimage: simplify start/size calculation for rc4_encode
  rockchip: mkimage: pad the header to 8-bytes (using a 'nop') for RK3399
  rockchip: spl: RK3399: use boot0 hook to create space for SPL magic
  rockchip: mkimage: update rkimage to support pre-padded payloads
  rockchip: pinctrl: use per-SoC option names for Kconfig
  rockchip: spl: RK3399: add COUNTER_FREQUENCY define to rk3399_common.h
  rockchip: arm64: rk3399: remove unconditional debug message
  rockchip: pinctrl: rk3399: add GMAC (RGMII only) support
  rockchip: clk: rk3399: fix warnings for unused variables in SPL/non-SPL
  rockchip: clk: rk3399: add clocking support for Ethernet
  net: gmac_rockchip: Add support for the RK3399 GMAC
  dts: rk3399: add gmac for the rk3399
  rockchip: clk: rk3399: 24MHz is not a power of 2
  rockchip: rk3399: spl: make SPL boot-order configurable via /chosen
  arm64: rockchip: rk3399-puma: add DDR3-1333 timings
  dts: rk3399-puma: add DTS for RK3399-Q7 (Puma) SoM
  defconfig: puma-rk3399: add defconfig for the RK3399-Q7 (Puma)
  dts: rk3399: move rockchip, vbus-gpio properties into board-specific files

Simon Glass (2):
  Makefile: Correct dependency race condition with TPL
  string: Provide a slimmed-down memset()

 Makefile |3 +-
 arch/arm/dts/Makefile|   15 +-
 arch/arm/dts/rk3188-radxarock.dts|  382 +
 arch/arm/dts/rk3288-firefly.dts  |   10 +
 arch/arm/dts/rk3288-miqi.dts |   46 ++
 arch/arm/dts/rk3288-miqi.dtsi|  423 ++
 arch/arm/dts/rk3399-evb.dts  |2 +
 arch/arm/dts/rk3399-puma.dts |  189 +
 arch/arm/dts/rk3399-sdram-ddr3-1333.dtsi | 1537

 arch/arm/dts/rk3399.dtsi |   57 +-
 arch/arm/include/asm/arch-rockchip/boot0.h   |   18 +
 arch/arm/include/asm/arch-rockchip/cru_rk3188.h  |1 +
 arch/arm/include/asm/arch-rockchip/grf_rk3288.h  |   68 +-
 arch/arm/include/asm/arch-rockchip/grf_rk3399.h  |   84 +-
 arch/arm/include/asm/arch-rockchip/hdmi_rk3288.h |  456 ---
 arch/arm/include/asm/arch-rockchip/periph.h  |1 +
 arch/arm/mach-rockchip/Kconfig   |1 +
 arch/arm/mach-rockchip/rk3188-board-spl.c|   28 +-
 arch/arm/mach-rockchip/rk3188-board-tpl.c|6 +-
 arch/arm/mach-rockchip/rk3188-board.c|   18 +-
 arch/arm/mach-rockchip/rk3188/Kconfig|   14 +
 arch/arm/mach-rockchip/rk3188/sdram_rk3188.c |2 +-
 arch/arm/mach-rockchip/rk3288/Kconfig|  101 +--
 arch/arm/mach-rockchip/rk3399-board-spl.c|  103 ++-
 arch/arm/mach-rockchip/rk3399/rk3399.c   |1 -
 board/mqmaker/miqi_rk3288/Kconfig|   15 +
 board/mqmaker/miqi_rk3288/MAINTAINERS|6 +
 board/mqmaker/miqi_rk3288/Makefile   |7 +
 board/mqmaker/miqi_rk3288/miqi-rk3288.c  |   15 +
 board/radxa/rock/Kconfig |   15 +
 board/radxa/rock/MAINTAINERS |6 +
 

Re: [U-Boot] [PATCH 5/7] Add mipi display support for rk3399 && rk3288

[Jacob Chen]

Hi eric,

2017-04-01 22:42 GMT+08:00  :
> From: "eric.gao" 
>
> Signed-off-by: eric.gao 
> ---
>
>  arch/arm/dts/rk3399-evb.dts  |  33 ++
>  arch/arm/dts/rk3399.dtsi |  72 +
>  arch/arm/include/asm/arch-rockchip/cru_rk3399.h  |   2 +-
>  arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 203 +
>  arch/arm/include/asm/arch-rockchip/vop_rk3288.h  |   1 +
>  configs/evb-rk3399_defconfig |   4 +
>  drivers/video/Kconfig|   2 +
>  drivers/video/rockchip/Kconfig   |  44 +++
>  drivers/video/rockchip/Makefile  |   7 +-
>  drivers/video/rockchip/panel.c   |  81 +
>  drivers/video/rockchip/rk_mipi.c | 371 
> +++
>  drivers/video/rockchip/rk_vop.c  |  12 +-
>  12 files changed, 827 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
>  create mode 100644 drivers/video/rockchip/Kconfig
>  create mode 100644 drivers/video/rockchip/panel.c
>  create mode 100644 drivers/video/rockchip/rk_mipi.c
>
> diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> index 7a889c7..abb00e8 100644
> --- a/arch/arm/dts/rk3399-evb.dts
> +++ b/arch/arm/dts/rk3399-evb.dts
> @@ -52,6 +52,10 @@
> gpio = < 25 GPIO_ACTIVE_HIGH>;
> };
>
> +   panel:panel {
> +   compatible = "BOE,TV080WUM";
> +   status = "disabled";
> +   };
> vccsys: vccsys {
> compatible = "regulator-fixed";
> regulator-name = "vccsys";
> @@ -218,6 +222,35 @@
> };
>  };
>
> + {
> +   backlight_en = < 13 GPIO_ACTIVE_HIGH>;
> +   backlight_pwm = < 18 GPIO_ACTIVE_HIGH>;
> +   power-supply = <_lcd>;
> +   status = "okay";
> +};
> +
> +_dsi {
> +   status = "okay";
> +   display-timings {
> +   timing0 {
> +   bits-per-pixel = <24>;
> +   clock-frequency = <16000>;
> +   hfront-porch = <120>;
> +   hsync-len = <20>;
> +   hback-porch = <21>;
> +   hactive = <1200>;
> +   vfront-porch = <21>;
> +   vsync-len = <3>;
> +   vback-porch = <18>;
> +   vactive = <1920>;
> +   hsync-active = <0>;
> +   vsync-active = <0>;
> +   de-active = <1>;
> +   pixelclk-active = <0>;
> +   };
> +   };
> +};
> +

Evb board can use different screens, so we'd better not hard-code the choice.
And, Please split dts changes to a separate patch.


>   {
> pmic {
> pmic_int_l: pmic-int-l {
> diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
> index 93e3bf4..c82e674 100644
> --- a/arch/arm/dts/rk3399.dtsi
> +++ b/arch/arm/dts/rk3399.dtsi
> @@ -667,6 +667,78 @@
> status = "disabled";
> };
>
> +   vopl: vop@ff8f {
> +   u-boot,dm-pre-reloc;
> +   compatible = "rockchip,rk3399-vop-lit";
> +   reg = <0x0 0xff8f 0x0 0x3efc>;
> +   interrupts = ;
> +   clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
> +   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> +   resets = < SRST_A_VOP1>, < SRST_H_VOP1>, < 
> SRST_D_VOP1>;
> +   reset-names = "axi", "ahb", "dclk";
> +   status = "okay";
> +   vopl_out: port {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   vopl_out_mipi: endpoint@0 {
> +   reg = <3>;
> +   remote-endpoint = <_in_vopl>;
> +   };
> +   };
> +   };
> +
> +   vopb: vop@ff90 {
> +   u-boot,dm-pre-reloc;
> +   compatible = "rockchip,rk3399-vop-big";
> +   reg = <0x0 0xff90 0x0 0x3efc>;
> +   interrupts = ;
> +   clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
> +   #clock-cells = <0>;
> +   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> +   resets = < SRST_A_VOP0>, < SRST_H_VOP0>, < 
> SRST_D_VOP0>;
> +   reset-names = "axi", "ahb", "dclk";
> +   /*power-domains = < RK3399_PD_VOPB>;*/
> +   status = "okay";
> +   vopb_out: port {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   vopb_out_mipi: endpoint@0 {
> +   reg = <3>;
> +   remote-endpoint = <_in_vopb>;
> +   };
> +   };
> +   };
> +
> +   mipi_dsi: mipi@ff96 {
> +   compatible = 

Re: [U-Boot] [PATCH] dm: avoid dropping pin control DT properties in case of SPL_PINCTRL

[Simon Glass]

On 31 March 2017 at 22:22, Simon Glass  wrote:
> On 24 March 2017 at 15:47, Vikas Manocha  wrote:
>> This patch replaces SPL_PINCTRL_FULL with SPL_PINCNTRL. It is to avoid 
>> removal
>> of pin control properties in case of SPL_PINCTRL. No impact in case of
>> SPL_PINCTRL_FULL as it depends on SPL_PINCTRL.
>>
>> Signed-off-by: Vikas Manocha 
>> ---
>>  dts/Kconfig | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4 v4] dm: test: Add test for device removal

[Simon Glass]

On 27 March 2017 at 03:02, Stefan Roese  wrote:
> Add a test for the correct device removal. Currently two different ways
> for device removal are supported:
>
> - Normal device removal via the device_remove() API
> - Removal via selective device driver flags (DM_FLAG_ACTIVE_DMA)
>
> This new test "remove_active_dma" adds tests cases for those both ways
> of removal. This is done by adding a new test driver, which has this
> flag set.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> ---
> v4:
> - Added explicit test that a device without the active DMA flags is not
>   removed upon the active DMA remove call. For this, a new test driver
>   is added (test_act_dma_drv).
>
> v2:
> - New patch in patchset
>
>  test/dm/core.c| 66 
> +++
>  test/dm/test-driver.c | 11 +
>  2 files changed, 77 insertions(+)
>

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4 v2] dm: core: Add flags parameter to device_remove()

[Simon Glass]

On 25 March 2017 at 19:17, Simon Glass  wrote:
> On 20 March 2017 at 05:51, Stefan Roese  wrote:
>> This patch adds the flags parameter to device_remove() and changes all
>> calls to this function to provide the default value of DM_REMOVE_NORMAL
>> for "normal" device removal.
>>
>> This is in preparation for the driver specific pre-OS (e.g. DMA
>> cancelling) remove support.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Simon Glass 
>> ---
>> v2:
>> - Changes DM_FLAG macro as suggested by Simon
>> - Minor comment change as suggested by Simon
>>
>>  arch/x86/cpu/queensbay/tnc.c   |  4 ++--
>>  cmd/cros_ec.c  |  2 +-
>>  cmd/sf.c   |  2 +-
>>  drivers/block/blk-uclass.c |  2 +-
>>  drivers/block/sandbox.c|  2 +-
>>  drivers/core/device-remove.c   |  9 +
>>  drivers/core/device.c  |  2 +-
>>  drivers/core/root.c|  2 +-
>>  drivers/core/uclass.c  |  2 +-
>>  drivers/mmc/mmc-uclass.c   |  2 +-
>>  drivers/mtd/spi/sandbox.c  |  2 +-
>>  drivers/mtd/spi/sf-uclass.c|  2 +-
>>  drivers/spi/spi-uclass.c   |  4 ++--
>>  drivers/usb/emul/sandbox_hub.c |  2 +-
>>  drivers/usb/host/usb-uclass.c  |  4 ++--
>>  include/dm/device-internal.h   |  5 +++--
>>  include/dm/device.h| 26 ++
>>  test/dm/bus.c  |  8 
>>  test/dm/core.c | 16 
>>  test/dm/eth.c  |  2 +-
>>  test/dm/spi.c  |  2 +-
>>  21 files changed, 65 insertions(+), 37 deletions(-)
>>
>
> Acked-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4 v2] arm: bootm: Add dm_remove_devices_flags() call to announce_and_cleanup()

[Simon Glass]

On 20 March 2017 at 05:51, Stefan Roese  wrote:
> This patch adds a call to dm_remove_devices_flags() to
> announce_and_cleanup() so that drivers that have one of the removal flags
> set (e.g. DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may do some
> last-stage cleanup before the OS is started.
>
> Signed-off-by: Stefan Roese 
> Reviewed-by: Simon Glass 
> ---
> v2:
> - Added Simons Reviewed-by
>
>  arch/arm/lib/bootm.c | 9 +
>  1 file changed, 9 insertions(+)
>

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4 v4] dm: core: Add dm_remove_devices_flags() and hook it into device_remove()

[Simon Glass]

On 27 March 2017 at 02:58, Stefan Roese  wrote:
> The new function dm_remove_devices_flags() is intented for driver specific
> last-stage cleanup operations before the OS is started. This patch adds
> this functionality and hooks it into the common device_remove()
> function.
>
> Drivers wanting to use this feature for some last-stage removal calls,
> need to add one of the DM_REMOVE_xx flags to their driver .flags.
>
> Signed-off-by: Stefan Roese 
> Reviewed-by: Simon Glass 
> ---
> v4:
> - Make comparison of flags more explicit by masking the driver flags
>   with the drivers "remove flags" before masking them with the
>   device_remove() removal flags parameter
>
> v3:
> - Add conditional compilation to fix compilation breakage on platforms
>   without DM and DM_DEVICE_REMOVE support. With this change, Travis
>   compiles all targets without any error
>
> v2:
> - Added Simons Reviewed-by
>
> drivers/core/device-remove.c | 17 +
>  drivers/core/root.c  |  9 +
>  include/dm/root.h| 16 
>  3 files changed, 38 insertions(+), 4 deletions(-)
>

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] fdt: allow address translation in case of SPL_OF_TRANSLATE

[Simon Glass]

Hi Vikas,

On 4 April 2017 at 15:59, Vikas Manocha  wrote:
> Address translation is not working at present even if SPL_OF_TRANSLATE is
> enabled which makes this configuration useless. This patch enables address
> translation for SPL U-Boot when SPL_OF_TRANSLATE is selected.
>
> Signed-off-by: Vikas Manocha 
> Reviewed-by: Simon Glass 
> ---
>
> Changes in v3: changed "u-boot" to "U-Boot" in commit message.
> Changes in v2: Added commit message
>
>  lib/fdtdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 81f47ef..a1c4d16 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -112,7 +112,7 @@ fdt_addr_t fdtdec_get_addr_size_fixed(const void *blob, 
> int node,
> return FDT_ADDR_T_NONE;
> }
>
> -#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_LIBFDT)
> +#if defined(CONFIG_SPL_OF_TRANSLATE) || defined(CONFIG_OF_LIBFDT)
> if (translate)
> addr = fdt_translate_address(blob, node, prop_addr);
> else
> --
> 1.9.1
>

Actually I'm a bit unsure about this patch. You already have a patch applied:

5efa1bf libfdt: use CONFIG_IS_ENABLED for OF_LIBFDT

Do you actually want this one else well? If so, please resend it as it
conflicts.

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

Re: [U-Boot] [PATCH] x86: bootm: Fix FIT image booting on x86

[Bin Meng]

On Fri, Mar 31, 2017 at 2:09 PM, Stefan Roese  wrote:
> Checking 'is_zimage' at this time will always fail and therefore booting
> a FIT style image will always lead to this error message:
>
> "## Kernel loading failed (missing x86 kernel setup) ..."
>
> This change now removes this check and booting of FIT images works just
> fine.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Bin Meng 
> ---
>  arch/x86/lib/bootm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

[U-Boot] [PATCH 2/2] imx: mx7ulp: Fix SPLL/APLL clock rate calculation issue

[Peng Fan]

From: Ye Li 

The num/denom is a float value, but in the calculation it is convert
to integer 0, and wrong result.

Signed-off-by: Ye Li 
Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---
 arch/arm/cpu/armv7/mx7ulp/scg.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx7ulp/scg.c b/arch/arm/cpu/armv7/mx7ulp/scg.c
index ca8252d..c117af0 100644
--- a/arch/arm/cpu/armv7/mx7ulp/scg.c
+++ b/arch/arm/cpu/armv7/mx7ulp/scg.c
@@ -504,7 +504,9 @@ u32 decode_pll(enum pll_clocks pll)
num = readl(_regs->spllnum);
denom = readl(_regs->splldenom);
 
-   return (infreq / pre_div) * (mult + num / denom);
+   infreq = infreq / pre_div;
+
+   return infreq * mult + infreq * num / denom;
 
case PLL_A7_APLL:
reg = readl(_regs->apllcsr);
@@ -531,7 +533,9 @@ u32 decode_pll(enum pll_clocks pll)
num = readl(_regs->apllnum);
denom = readl(_regs->aplldenom);
 
-   return (infreq / pre_div) * (mult + num / denom);
+   infreq = infreq / pre_div;
+
+   return infreq * mult + infreq * num / denom;
 
case PLL_USB:
reg = readl(_regs->upllcsr);
-- 
2.6.2

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

[U-Boot] [PATCH 1/2] imx-common: Enable ACTLR.SMP bit for i.MX cortex-a7 platforms

[Peng Fan]

According to the Cortex-A7 TRM, for ACTLR.SMP bit "You must ensure
this bit is set to 1 before the caches and MMU are enabled, or any
cache and TLB maintenance operations are performed".

ROM sets this bit in normal boot flow, but when in serial download
mode, it is not set. Here we add it in u-boot as a common flow for
all i.MX cortex-a7 platforms, including mx7d, mx6ul/ull and mx7ulp.

When cache not enabled in U-Boot, we also need enable the SMP bit.
because kernel does not set this bit, if this bit not enabled, kernel
works as cache disabled.

Signed-off-by: Peng Fan 
Signed-off-by: Ye Li 
Cc: Stefano Babic 
---
 arch/arm/cpu/armv7/mx7/soc.c |  7 ---
 arch/arm/imx-common/cache.c  | 42 ++
 2 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c
index 8422f24..b847cf8 100644
--- a/arch/arm/cpu/armv7/mx7/soc.c
+++ b/arch/arm/cpu/armv7/mx7/soc.c
@@ -446,13 +446,6 @@ int mmc_get_env_dev(void)
 
 void s_init(void)
 {
-#if !defined CONFIG_SPL_BUILD
-   /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
-   asm volatile(
-   "mrc p15, 0, r0, c1, c0, 1\n"
-   "orr r0, r0, #1 << 6\n"
-   "mcr p15, 0, r0, c1, c0, 1\n");
-#endif
/* clock configuration. */
clock_init();
 
diff --git a/arch/arm/imx-common/cache.c b/arch/arm/imx-common/cache.c
index 1c4a9a2..ed17f9e 100644
--- a/arch/arm/imx-common/cache.c
+++ b/arch/arm/imx-common/cache.c
@@ -10,6 +10,34 @@
 #include 
 #include 
 
+static void enable_ca7_smp(void)
+{
+   uint32_t val;
+
+   /* Read MIDR */
+   asm volatile ("mrc p15, 0, %0, c0, c0, 0\r\n" : "=r"(val));
+   val = (val >> 4);
+   val &= 0xfff;
+
+   /* Only set the SMP for Cortex A7 */
+   if (val == 0xC07) {
+   /* Read auxiliary control register */
+   asm volatile ("mrc p15, 0, %0, c1, c0, 1\r\n" : "=r"(val));
+
+   if (val & (1 << 6))
+   return;
+
+   /* Enable SMP */
+   val |= (1 << 6);
+
+   /* Write auxiliary control register */
+   asm volatile ("mcr p15, 0, %0, c1, c0, 1\r\n" : : "r"(val));
+
+   DSB;
+   ISB;
+   }
+}
+
 #ifndef CONFIG_SYS_DCACHE_OFF
 void enable_caches(void)
 {
@@ -18,6 +46,9 @@ void enable_caches(void)
 #else
enum dcache_option option = DCACHE_WRITEBACK;
 #endif
+   /* Set ACTLR.SMP bit for Cortex-A7 */
+   enable_ca7_smp();
+
/* Avoid random hang when download by usb */
invalidate_dcache_all();
 
@@ -32,6 +63,17 @@ void enable_caches(void)
IRAM_SIZE,
option);
 }
+#else
+void enable_caches(void)
+{
+   /*
+* Set ACTLR.SMP bit for Cortex-A7, even the
+* caches not enabled.
+*/
+   enable_ca7_smp();
+
+   puts("WARNING: Caches not enabled\n");
+}
 #endif
 
 #ifndef CONFIG_SYS_L2CACHE_OFF
-- 
2.6.2

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

Re: [U-Boot] usb: dwc2: invalidate the dcache before starting the DMA

[Simon Glass]

Hi,

On 4 April 2017 at 19:26, Kever Yang  wrote:
> Hi Eddie,
>
>
> We should only need to do only one time cache operation for a buffer
>
> ready to do DMA transfer, so you need to remove another cache invalidate
>
> operation for the same buffer in the same function.

I think this is a more general problem and might cause issues with
other drivers. So I have sent this patch:

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

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

Re: [U-Boot] [PATCH] rockchip: Print a message when returning to the bootrom

[Simon Glass]

Hi,

On 4 April 2017 at 20:02, Simon Glass  wrote:
> At present if the return to bootrom fails (e.g. because you are not using
> the Rockchip's bootrom's pointer table in MMC) then the board prints
> SPL message and hangs. Print a message first if we can, to help in
> understanding what happened when it hangs.
>
> Signed-off-by: Simon Glass 
> ---

This is supposed to be an RFC, sorry. Please ignore the firefly
change. I tend to get his with this problem a lot so am thinking some
indication would be useful.


>
>  arch/arm/include/asm/arch-rockchip/bootrom.h |  9 +++--
>  arch/arm/mach-rockchip/Makefile  |  2 ++
>  arch/arm/mach-rockchip/bootrom.c | 16 
>  arch/arm/mach-rockchip/save_boot_param.S |  6 +++---
>  configs/firefly-rk3288_defconfig |  2 +-
>  5 files changed, 29 insertions(+), 6 deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/bootrom.c
>
> diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h 
> b/arch/arm/include/asm/arch-rockchip/bootrom.h
> index 79fb1a07ac..92eb8783a3 100644
> --- a/arch/arm/include/asm/arch-rockchip/bootrom.h
> +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
> @@ -13,10 +13,15 @@
>   */
>  extern u32 SAVE_SP_ADDR;
>
> -/*
> +/**
>   * Hand control back to the bootrom to load another
>   * boot stage.
>   */
> -extern void back_to_bootrom(void);
> +void back_to_bootrom(void);
> +
> +/**
> + * Assembler component for the above (do not call this directly)
> + */
> +void _back_to_bootrom_s(void);
>
>  #endif
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 6b251c7e7e..5caecfb2c0 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -4,6 +4,8 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  #
>
> +obj-y += bootrom.o
> +
>  ifdef CONFIG_TPL_BUILD
>  obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-tpl.o
>  obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += save_boot_param.o
> diff --git a/arch/arm/mach-rockchip/bootrom.c 
> b/arch/arm/mach-rockchip/bootrom.c
> new file mode 100644
> index 00..65f058460e
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/bootrom.c
> @@ -0,0 +1,16 @@
> +/**
> + * Copyright (c) 2017 Google, Inc
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +
> +void back_to_bootrom(void)
> +{
> +#ifdef SPL_LIBGENERIC_SUPPORT
> +   printf("Returning to boot ROM...");
> +#endif
> +   _back_to_bootrom_s();
> +}
> diff --git a/arch/arm/mach-rockchip/save_boot_param.S 
> b/arch/arm/mach-rockchip/save_boot_param.S
> index 85b407b4d3..5e6c8dba13 100644
> --- a/arch/arm/mach-rockchip/save_boot_param.S
> +++ b/arch/arm/mach-rockchip/save_boot_param.S
> @@ -23,10 +23,10 @@ ENTRY(save_boot_params)
>  ENDPROC(save_boot_params)
>
>
> -.globl back_to_bootrom
> -ENTRY(back_to_bootrom)
> +.globl _back_to_bootrom_s
> +ENTRY(_back_to_bootrom_s)
> ldr r0, =SAVE_SP_ADDR
> ldr sp, [r0]
> mov r0, #0
> pop {r1-r12, pc}
> -ENDPROC(back_to_bootrom)
> +ENDPROC(_back_to_bootrom_s)
> diff --git a/configs/firefly-rk3288_defconfig 
> b/configs/firefly-rk3288_defconfig
> index b0741d7bd9..f2e079a378 100644
> --- a/configs/firefly-rk3288_defconfig
> +++ b/configs/firefly-rk3288_defconfig
> @@ -2,7 +2,6 @@ CONFIG_ARM=y
>  CONFIG_ARCH_ROCKCHIP=y
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_ROCKCHIP_RK3288=y
> -CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
>  CONFIG_TARGET_FIREFLY_RK3288=y
>  CONFIG_SPL_STACK_R_ADDR=0x8
>  CONFIG_DEFAULT_DEVICE_TREE="rk3288-firefly"
> @@ -74,3 +73,4 @@ CONFIG_CONSOLE_SCROLL_LINES=10
>  CONFIG_USE_TINY_PRINTF=y
>  CONFIG_CMD_DHRYSTONE=y
>  CONFIG_ERRNO_STR=y
> +CONFIG_SPL_OF_PLATDATA=y
> --
> 2.12.2.715.g7642488e1d-goog
>

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

[U-Boot] [PATCH] rockchip: Print a message when returning to the bootrom

[Simon Glass]

At present if the return to bootrom fails (e.g. because you are not using
the Rockchip's bootrom's pointer table in MMC) then the board prints
SPL message and hangs. Print a message first if we can, to help in
understanding what happened when it hangs.

Signed-off-by: Simon Glass 
---

 arch/arm/include/asm/arch-rockchip/bootrom.h |  9 +++--
 arch/arm/mach-rockchip/Makefile  |  2 ++
 arch/arm/mach-rockchip/bootrom.c | 16 
 arch/arm/mach-rockchip/save_boot_param.S |  6 +++---
 configs/firefly-rk3288_defconfig |  2 +-
 5 files changed, 29 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/mach-rockchip/bootrom.c

diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h 
b/arch/arm/include/asm/arch-rockchip/bootrom.h
index 79fb1a07ac..92eb8783a3 100644
--- a/arch/arm/include/asm/arch-rockchip/bootrom.h
+++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
@@ -13,10 +13,15 @@
  */
 extern u32 SAVE_SP_ADDR;
 
-/*
+/**
  * Hand control back to the bootrom to load another
  * boot stage.
  */
-extern void back_to_bootrom(void);
+void back_to_bootrom(void);
+
+/**
+ * Assembler component for the above (do not call this directly)
+ */
+void _back_to_bootrom_s(void);
 
 #endif
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 6b251c7e7e..5caecfb2c0 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -4,6 +4,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+obj-y += bootrom.o
+
 ifdef CONFIG_TPL_BUILD
 obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-tpl.o
 obj-$(CONFIG_ROCKCHIP_BROM_HELPER) += save_boot_param.o
diff --git a/arch/arm/mach-rockchip/bootrom.c b/arch/arm/mach-rockchip/bootrom.c
new file mode 100644
index 00..65f058460e
--- /dev/null
+++ b/arch/arm/mach-rockchip/bootrom.c
@@ -0,0 +1,16 @@
+/**
+ * Copyright (c) 2017 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+void back_to_bootrom(void)
+{
+#ifdef SPL_LIBGENERIC_SUPPORT
+   printf("Returning to boot ROM...");
+#endif
+   _back_to_bootrom_s();
+}
diff --git a/arch/arm/mach-rockchip/save_boot_param.S 
b/arch/arm/mach-rockchip/save_boot_param.S
index 85b407b4d3..5e6c8dba13 100644
--- a/arch/arm/mach-rockchip/save_boot_param.S
+++ b/arch/arm/mach-rockchip/save_boot_param.S
@@ -23,10 +23,10 @@ ENTRY(save_boot_params)
 ENDPROC(save_boot_params)
 
 
-.globl back_to_bootrom
-ENTRY(back_to_bootrom)
+.globl _back_to_bootrom_s
+ENTRY(_back_to_bootrom_s)
ldr r0, =SAVE_SP_ADDR
ldr sp, [r0]
mov r0, #0
pop {r1-r12, pc}
-ENDPROC(back_to_bootrom)
+ENDPROC(_back_to_bootrom_s)
diff --git a/configs/firefly-rk3288_defconfig b/configs/firefly-rk3288_defconfig
index b0741d7bd9..f2e079a378 100644
--- a/configs/firefly-rk3288_defconfig
+++ b/configs/firefly-rk3288_defconfig
@@ -2,7 +2,6 @@ CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_ROCKCHIP_RK3288=y
-CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
 CONFIG_TARGET_FIREFLY_RK3288=y
 CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3288-firefly"
@@ -74,3 +73,4 @@ CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_SPL_OF_PLATDATA=y
-- 
2.12.2.715.g7642488e1d-goog

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

Re: [U-Boot] usb: dwc2: invalidate the dcache before starting the DMA

[Kever Yang]

Hi Eddie,


We should only need to do only one time cache operation for a buffer

ready to do DMA transfer, so you need to remove another cache invalidate

operation for the same buffer in the same function.


Thanks,
- Kever
On 04/01/2017 02:51 PM, Eddie Cai wrote:

We should invalidate the dcache before starting the DMA. In case there are
any dirty lines from the DMA buffer in the cache, subsequent cache-line
replacements may corrupt the buffer in memory while the DMA is still going on.
Cache-line replacement can happen if the CPU tries to bring some other memory
locations into the cache while the DMA is going on.

Signed-off-by: Eddie Cai 
---
  drivers/usb/host/dwc2.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 5ac602e..a151ba6 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -811,12 +811,17 @@ static int transfer_chunk(struct dwc2_hc_regs *hc_regs, 
void *aligned_buffer,
   (*pid << DWC2_HCTSIZ_PID_OFFSET),
   _regs->hctsiz);
  
-	if (!in && xfer_len) {

-   memcpy(aligned_buffer, buffer, xfer_len);
-
-   flush_dcache_range((unsigned long)aligned_buffer,
-  (unsigned long)aligned_buffer +
-  roundup(xfer_len, ARCH_DMA_MINALIGN));
+   if (xfer_len) {
+   if(in){
+   invalidate_dcache_range((unsigned long)aligned_buffer,
+  (unsigned long)aligned_buffer +
+  roundup(xfer_len, 
ARCH_DMA_MINALIGN));
+   }else{
+   memcpy(aligned_buffer, buffer, xfer_len);
+   flush_dcache_range((unsigned long)aligned_buffer,
+  (unsigned long)aligned_buffer +
+  roundup(xfer_len, 
ARCH_DMA_MINALIGN));
+   }
}
  
  	writel(phys_to_bus((unsigned long)aligned_buffer), _regs->hcdma);



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

[U-Boot] [ANN] U-Boot v2017.05-rc1 released

[Tom Rini]

Hey all,

It's the day after the normal release day for v2017.05-rc1 but it's out
now.  I've been on vacation[1] and my wireless access was less than I
expected so the PRs piled up and I was just on vacation.  The merge
window is now closed and I've updated git and the tarballs are also up
now.

I plan on doing -rc2 on the 17th of April.  I'm sure that my queue is in
need of cleaning and I'll get on that soon.  I'll also be grabbing those
architecture removal patches I did before.

Thanks all!

-- 
Tom

[1]: I too can take blurry fish butt pictures:
http://goo.gl/photos/ehJVmcagZobdeFsT9


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

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

[Tom Rini]

On Tue, Apr 04, 2017 at 10:56:00AM -0700, Tom Warren wrote:

> Tom,
> 
> Please pull u-boot-tegra/master into U-Boot/master. Thanks!
> 
> All Tegra builds are OK, and Stephen's automated test system reports that
> all tests pass.
> 
> The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:
> 
>   Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-tegra.git master
> 
> for you to fetch changes up to ee92194acd3b2b8a6b2a096ec9588e9a7f326e95:
> 
>   apalis-tk1: disable external clock loopback on SDMMC3 (2017-04-01
> 15:45:04 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] dts: rk3399: move rockchip, vbus-gpio properties into board-specific files

[Simon Glass]

On 31 March 2017 at 22:24, Simon Glass  wrote:
> On 29 March 2017 at 13:19, Philipp Tomsich
>  wrote:
>> The (shared) rk3399.dtsi had defined the 'rockchip,vbus-gpio'
>> properties for each USB 3.0 controller.
>>
>> As the GPIO usage will vary (e.g. one of those GPIOs shuts down one of
>> the regulators on the RK3399-Q7) between boards, we move this from the
>> shared dtsi into the device tree file for the EVB board which these
>> GPIO definitions match.
>>
>> Signed-off-by: Philipp Tomsich 
>> ---
>>
>>  arch/arm/dts/rk3399-evb.dts | 2 ++
>>  arch/arm/dts/rk3399.dtsi| 2 --
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] string: Provide a slimmed-down memset()

[Simon Glass]

On 4 April 2017 at 03:38, Heiko Stübner  wrote:
>
> Am Sonntag, 2. April 2017, 09:50:28 CEST schrieb Simon Glass:
> > Most of the time the optimised memset() is what we want. For extreme
> > situations such as TPL it may be too large. For example on the 'rock'
> > board, using a simple loop saves a useful 48 bytes. With gcc 4.9 and
> > the rodata bug, this patch is enough to reduce the TPL image below the
> > limit.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Adjust the option to be SPL-only
> > - Change the option to default to off (name it CONFIG_SPL_TINY_MEMSET)
> >
> >  lib/Kconfig  | 8 
> >  lib/string.c | 6 --
> >  2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index 65c01573e1..58b5717dcd 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -52,6 +52,14 @@ config LIB_RAND
> >   help
> > This library provides pseudo-random number generator functions.
> >
> > +config SPL_TINY_MEMSET
> > + bool "Use a very small memset() in SPL"
> > + help
> > +   The faster memset() is the arch-specific one (if available) enabled
> > +   by CONFIG_USE_ARCH_MEMSET. If that is not enabled, we can still get
> > +   better performance by write a word at a time. Enable this option
> > +   to reduce code size slightly at the cost of some speed.
>
> Wording sounds off, I guess we could do something like
>
> [...better performance by] writing a word at a time. In very size-constrained
> environments even this may be to big though. [Enable this option...]
>
> Otherwise
> Reviewed-by: Heiko Stuebner 

I am going to apply this one now and leave the rest of the series
until it has had a bit more review. But this one is needed for me to
enable the rock board.

Fixed this and:

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

Re: [U-Boot] [PATCH v2 5/6] rockchip: spi: rk3399: move CONFIG_SPI and CONFIG_SPI_FLASH to defconfig

[Simon Glass]

On 31 March 2017 at 22:23, Simon Glass  wrote:
> On 29 March 2017 at 05:31, Philipp Tomsich
>  wrote:
>> From: Jakob Unterwurzacher 
>>
>> On the RK3399-Q7 we need to enable a number of configuration options
>> (e.g. CONFIG_SPI_FLASH_WINBND) dependent on Kconfig seeing CONFIG_SPI
>> and CONFIG_SPI_FLASH active.
>>
>> To allow for these being defined in Kconfig (e.g. via defconfig) and
>> to avoid a warning on having the macro defined multiple times, we
>> remove them from the common header file.
>>
>> Note that the rk3399-evb does not currently have the rk_spi.c driver
>> active (i.e. CONFIG_ROCKCHIP_SPI), so there's no change to the
>> evb-rk3399_defconfig as part of this change.
>>
>> X-AffectedPlatforms: RK3399-Q7
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Jakob Unterwurzacher 
>> ---
>>
>> Changes in v2: None
>>
>>  include/configs/rk3399_common.h | 2 --
>>  1 file changed, 2 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] rockchip: rk3188: Add Radxa Rock board

[Simon Glass]

On 4 April 2017 at 11:06, Heiko Stuebner  wrote:
> Am Dienstag, 4. April 2017, 12:29:53 CEST schrieb Tom Rini:
>> On Fri, Mar 31, 2017 at 10:24:07PM -0600, Simon Glass wrote:
>> > On 26 March 2017 at 16:38, Heiko Stuebner  wrote:
>> > > I've added Tom for comments, executive summary:
>> > > - rk3188-tpl is size limited to 1020 bytes
>> > > - gcc 6.3 produces a rk3188-tpl of 792 bytes
>> > > - gcc 4.9 makes it 1020 bytes
>> > > - buildman seems to always use gcc-4.9
>> > > - rk3188 board does not compile with buildman
>> > >
>> > >
>> > > Isn't holding on to a pretty old compiler for everything somewhat
>> > > strange? ;-)
>> >
>> > Well it's not that old. 4.6 would be old. We do need to be careful not
>> > to drop old toolchains too aggressively, although for new platforms
>> > such as this is doesn't matter. I try to test with older things to
>> > avoid problems applying things to mainline (with Tom's automated
>> > tests, etc.)
>>
>> wrt buildman using certain toolchains, it comes down to the order in
>> which it finds matches for a given arch and then it picks (and I don't
>> recall which off the top of my head) the first or last match.
>>
>> I do agree that gcc-4.9 isn't something we can drop just yet (as for
>> example it's what'll be used in travis-ci today.  But it's getting
>> pretty long in the tooth and we will have to at some point say that
>> "platform X requires gcc-6.x or later" as we start running into hard
>> walls that are solved in 6.x.
>>
>> Finally, I have no objection to adding TPL_USE_ARCH_MEMSET as an option
>> so that in cases like this it can be disabled due to space just as it is
>> on SPL.
>
> The problem wasn't ARCH_MEMSET - which already was way outsize the size
> constraints, but the general memset also being somewhat big, with its
> slight speed optimizations.
>
> But thanks to Simon's recent patches [0] we got a really nice size-
> reduction on the Rock's TPL (from 1020 to 488 bytes) . So with these
> we're really good with all toolchains now.
>
> Heiko
>
>
> [0] https://www.mail-archive.com/u-boot@lists.denx.de/msg243443.html

Well, hopefully for the last time, this patch:

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 3/3] defconfig: puma-rk3399: add defconfig for the RK3399-Q7 (Puma)

[Simon Glass]

On 31 March 2017 at 22:24, Simon Glass  wrote:
> On 28 March 2017 at 10:48, Philipp Tomsich
>  wrote:
>> This commit adds the baseline defconfig for the RK3399-Q7 (Puma) SoM
>> (under the name 'puma-rk3399_defconfig') featuring the Rockchip RK3399
>> in a Qseven compatible module.
>>
>> This subsumes the following changes:
>>  * defconfig: rk3399: migrate 
>> CONFIG_SPL_LIBCOMMON_SUPPORT/CONFIG_SPL_LIBGENERIC_SUPPORT
>>  * defconfig: rk3399-puma: add CONFIG_MMC_DW_ROCKCHIP
>>  * defconfig: rk3399-puma: disable CONFIG_SPL_OF_PLATDATA
>>  * defconfig: rk3399-puma: don't USE_TINY_PRINTF
>>  * defconfig: rk3399-puma: set up CONFIG_SYS_BOARD for the RK3399-Q7
>>  * defconfig: rk3399-puma: enable the multi-image loading via CONFIG_SPL_FIT
>>  * defconfig: rk3399-puma: SPL should be able to boot from MMC/SD card
>>  * defconfig: rk3399-puma: enable GMAC support
>>  * defconfig: rk3399-puma: enable support for SPI and Winbond SPI flash
>>  * defconfig: rk3399-puma: enable SPI as a boot-source in SPL
>>  * defconfig: rk3399-puma: disallow non-FIT images from being loaded
>>  * defconfig: rk3399-puma: rename to puma-rk3399
>>  * rockchip: config: rk3399: update defconfigs and rk3399_common
>>
>> For the RK3399-Q7, we want a default boot-order of SPI -> MMC -> uSD.
>> This both follows how the BootROM probes devices and is a sane default
>> for customers in device-personalisation (e.g. it allows for quick and
>> easy factory programming of unpersonalised devices using an SD card)
>> and field usage (with customer devices expected to have their firmware
>> either in SPI or MMC).
>>
>> However, when probing multiple interfaces (according to the result
>> from the board_boot_order function), we need to ensure that only valid
>> FIT images are considered and disable the fallback to assuming that a
>> raw (binary-only) U-Boot image is loaded (to avoid hangs/crashes from
>> jumping to random content loaded from devices that are probed, but
>> don't contain valid image content).
>>
>> By disabling the SPL_RAW_IMAGE_SUPPORT and SPL_LEGACY_IMAGE_SUPPORT
>> options, we ensure that raw images (indistinguishable from random
>> data) are not considered for booting.
>>
>> Signed-off-by: Philipp Tomsich 
>>
>> ---
>>
>>  configs/evb-rk3399_defconfig|  3 ++
>>  configs/puma-rk3399_defconfig   | 73 
>> +
>>  include/configs/rk3399_common.h |  2 --
>>  3 files changed, 76 insertions(+), 2 deletions(-)
>>  create mode 100644 configs/puma-rk3399_defconfig
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] rockchip: Add support for MiQi rk3288 board

[Simon Glass]

On 31 March 2017 at 22:23, Simon Glass  wrote:
> On 29 March 2017 at 17:23, Jernej Skrabec  wrote:
>> MiQi is rk3288 based development board with 1 or 2 GB SDRAM, 16 GB eMMC,
>> micro SD card interface, 4 USB 2.0 ports, HDMI, gigabit Ethernet and
>> expansion ports.
>>
>> Signed-off-by: Jernej Skrabec 
>> ---
>> Changes in v3:
>> - split out cosmetic changes into a new patch
>>
>> Changes in v2:
>> - change license to SPDX identifier
>> - reorder boards in alphabetical order in Kconfig and Makefile
>>
>>  arch/arm/dts/Makefile   |   1 +
>>  arch/arm/dts/rk3288-miqi.dts|  46 
>>  arch/arm/dts/rk3288-miqi.dtsi   | 423 
>> 
>>  arch/arm/mach-rockchip/rk3288/Kconfig   |  11 +
>>  board/mqmaker/miqi_rk3288/Kconfig   |  15 ++
>>  board/mqmaker/miqi_rk3288/MAINTAINERS   |   6 +
>>  board/mqmaker/miqi_rk3288/Makefile  |   7 +
>>  board/mqmaker/miqi_rk3288/miqi-rk3288.c |  15 ++
>>  configs/miqi-rk3288_defconfig   |  73 ++
>>  doc/README.rockchip |   3 +-
>>  include/configs/miqi_rk3288.h   |  22 ++
>>  11 files changed, 621 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm/dts/rk3288-miqi.dts
>>  create mode 100644 arch/arm/dts/rk3288-miqi.dtsi
>>  create mode 100644 board/mqmaker/miqi_rk3288/Kconfig
>>  create mode 100644 board/mqmaker/miqi_rk3288/MAINTAINERS
>>  create mode 100644 board/mqmaker/miqi_rk3288/Makefile
>>  create mode 100644 board/mqmaker/miqi_rk3288/miqi-rk3288.c
>>  create mode 100644 configs/miqi-rk3288_defconfig
>>  create mode 100644 include/configs/miqi_rk3288.h
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/3] dts: rk3399-puma: add DTS for RK3399-Q7 (Puma) SoM

[Simon Glass]

On 31 March 2017 at 22:23, Simon Glass  wrote:
> On 28 March 2017 at 10:48, Philipp Tomsich
>  wrote:
>> The RK3399-Q7 is a system-on-module featuring the Rockchip RK3399
>> in a Qseven-compatible form-factor.
>>
>> These changes add a device-tree describing the board and its
>> interfaces for basic functionality (e.g. GbE, SPI, eMMC, SD-card).
>>
>> This includes the following changes from the original development:
>>
>>  * dts: rk3399-puma: include DTS for RK3399-Q7 SoM in the Makefile
>>  * dts: rk3399-puma: add gmac for the RK3399-Q7
>>
>> This change enables the Gigabit Ethernet support on the RK3399-Q7.
>>
>>  * dts: rk3399-puma: use serial0 for stdout
>>  * dts: rk3399-puma: prepare the sdmmc node for SPL booting
>>  * dts: rk3399-puma: enable spi1 and spi5, add /spi1/spiflash
>>
>> The RK3399-Q7 (Puma) unsually (this is a build-time option for
>> customised boards) has an on-module SPI-flash connected to SPI1.
>> As of today, this is a Winbond W25Q32DW (32MBit) device.
>>
>> The SPI5 controller is routed to the Q7 edge connector and provides
>> general-purpose SPI connectivity for customer base-boards.
>>
>> With some minor improvements on integration into our outbound tree
>>  - explicitly modelled the SPI flash as 'spiflash' under spi0
>>[dts: rk3399-puma: explicitly model spi-flash under spi1]
>>  - renamed the aliases to spi0 and spi1 to allow easier use of
>>commands and legacy (SPL) infrastructure... i.e. the controllers
>>will be 0 and 1 for 'sf probe', 'sspi', etc.
>>[dts: rk3399-puma: rename aliases to number spi as 0 and 1 for commands]
>>
>>  * dts: rk3399-puma: include SPI in the spl-boot-order property
>>
>> Signed-off-by: Philipp Tomsich 
>> ---
>>
>>  arch/arm/dts/Makefile|   3 +-
>>  arch/arm/dts/rk3399-puma.dts | 189 
>> +++
>>  2 files changed, 191 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm/dts/rk3399-puma.dts
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] rockchip: cosmetic: Sort RK3288 boards

[Simon Glass]

On 31 March 2017 at 22:23, Simon Glass  wrote:
> On 29 March 2017 at 17:23, Jernej Skrabec  wrote:
>> Sort rk3288 boards in alphabetical order.
>>
>> Signed-off-by: Jernej Skrabec 
>> ---
>> Changes in v3:
>> - new patch
>>
>>  arch/arm/dts/Makefile | 10 ++--
>>  arch/arm/mach-rockchip/rk3288/Kconfig | 90 
>> +--
>>  doc/README.rockchip   |  2 +-
>>  3 files changed, 51 insertions(+), 51 deletions(-)
>>
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/3] arm64: rockchip: rk3399-puma: add DDR3-1333 timings

[Simon Glass]

On 31 March 2017 at 22:23, Simon Glass  wrote:
> On 28 March 2017 at 10:48, Philipp Tomsich
>  wrote:
>> For the initial validation of the RK3399-Q7 (Puma), the DDR3 has been
>> clocked at 666MHz (i.e. DDR3-1333) using the same (safe) settings as
>> used in Rockchip's MiniLoader.
>>
>> Signed-off-by: Philipp Tomsich 
>> ---
>>
>>  arch/arm/dts/rk3399-sdram-ddr3-1333.dtsi | 1537 
>> ++
>>  1 file changed, 1537 insertions(+)
>>  create mode 100644 arch/arm/dts/rk3399-sdram-ddr3-1333.dtsi
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1] rockchip: rk3399: spl: make SPL boot-order configurable via /chosen

[Simon Glass]

On 31 March 2017 at 22:23, Simon Glass  wrote:
> On 28 March 2017 at 03:03, Philipp Tomsich
>  wrote:
>> The RK3399 does not have any boot selection pins and the BootROM probes
>> the boot interfaces using the following boot-order:
>> 1. SPI
>> 2. eMMC (sdhci in DTS)
>> 3. SD card (sdmmc in DTS)
>> 4. USB loader
>> For ease of deployment, the SPL stage should mirror the boot order of
>> the ROM and use the same probing order (assuming that valid images can
>> be detected by SPL) unless instructed otherwise.  The boot-order can
>> then be configured via the 'u-boot,spl-boot-order' property in the
>> chosen-node of the DTS.
>>
>> While this approach is easily extensible to other boards, it is only
>> implemented for the RK3399 for now, as the large SRAM on the RK3399
>> makes this easy to fit the needed infrastructure into SPL and our
>> production setup already runs with DM, OF_CONTROL and BLK in SPL.
>>
>> The new boot-order property is expected to be used in conjunction with
>> FIT images (and all legacy image formats disabled via Kconfig).
>>
>> A boot-sequence with probing and fallthroughs from SPI via eMMC to SD
>> card (i.e. , , ) has been validated on the RK3399-Q7.
>>
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Klaus Goger 
>> Tested-by: Philipp Tomsich 
>> ---
>>
>>  arch/arm/mach-rockchip/rk3399-board-spl.c | 99 
>> +++
>>  doc/device-tree-bindings/chosen.txt   | 22 +++
>>  2 files changed, 121 insertions(+)
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5] mmc: gen_atmel_mci: add driver model support for mci

[Yang, Wenyou]

Hi Jaehoon,


On 2017/3/30 12:30, Jaehoon Chung wrote:

Hi Wenyou,

On 03/23/2017 01:48 PM, Wenyou Yang wrote:

Add the driver model support for Atmel mci while retaining the
existing legacy code. This allows the driver to support boards
that have converted to driver model as well as those that have not.

Signed-off-by: Wenyou Yang 

If Andreas is ok, i will pick this. Otherwise, pick this with my ack.
Let me know, plz.


Andreas, are you okay?



Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung


---

Changes in v5:
  - Rebase on v2017.03.

Changes in v4:
  - Remove unneeded #ifdef CONFIG_DM_MMC.

Changes in v3:
  - Use unified #ifdef CONFIG_DM_MMC #else...#endif, instead of #ifndef 
CONFIG_DM_MMC
#else...#endif.

Changes in v2:
  - Change the return type of atmel_mci_setup_cfg() from int to void.
  - Add comments on the features depends on the IP version.
  - Add the error handle path of clock.
  - Fix the missing use priv->bus_clk_rate.
  - Return from mmc_bind() directly, instead of checking its return.

  drivers/mmc/Kconfig |   9 +++
  drivers/mmc/gen_atmel_mci.c | 158 +++-
  2 files changed, 166 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 01d1dbfb1b..cb9937b4eb 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -336,6 +336,15 @@ config MMC_SUNXI
  This selects support for the SD/MMC Host Controller on
  Allwinner sunxi SoCs.
  
+config GENERIC_ATMEL_MCI

+   bool "Atmel Multimedia Card Interface support"
+   depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
+   help
+ This enables support for Atmel High Speed Multimedia Card Interface
+ (HSMCI), which supports the MultiMedia Card (MMC) Specification V4.3,
+ the SD Memory Card Specification V2.0, the SDIO V2.0 specification
+ and CE-ATA V1.1.
+
  endif
  
  endmenu

diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index 7dc4a5de74..c25d9ed96e 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -10,6 +10,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -18,8 +19,11 @@
  #include 
  #include 
  #include 
+#include 
  #include "atmel_mci.h"
  
+DECLARE_GLOBAL_DATA_PTR;

+
  #ifndef CONFIG_SYS_MMC_CLK_OD
  # define CONFIG_SYS_MMC_CLK_OD15
  #endif
@@ -37,6 +41,10 @@ struct atmel_mci_priv {
struct atmel_mci*mci;
unsigned intinitialized:1;
unsigned intcurr_clk;
+#ifdef CONFIG_DM_MMC
+   struct mmc  mmc;
+   ulong   bus_clk_rate;
+#endif
  };
  
  /* Read Atmel MCI IP version */

@@ -58,11 +66,19 @@ static void dump_cmd(u32 cmdr, u32 arg, u32 status, const 
char* msg)
  }
  
  /* Setup for MCI Clock and Block Size */

+#ifdef CONFIG_DM_MMC
+static void mci_set_mode(struct atmel_mci_priv *priv, u32 hz, u32 blklen)
+{
+   struct mmc *mmc = >mmc;
+   u32 bus_hz = priv->bus_clk_rate;
+#else
  static void mci_set_mode(struct mmc *mmc, u32 hz, u32 blklen)
  {
struct atmel_mci_priv *priv = mmc->priv;
-   atmel_mci_t *mci = priv->mci;
u32 bus_hz = get_mci_clk_rate();
+#endif
+
+   atmel_mci_t *mci = priv->mci;
u32 clkdiv = 255;
unsigned int version = atmel_mci_get_version(mci);
u32 clkodd = 0;
@@ -202,10 +218,18 @@ io_fail:
   * Sends a command out on the bus and deals with the block data.
   * Takes the mmc pointer, a command pointer, and an optional data pointer.
   */
+#ifdef CONFIG_DM_MMC
+static int atmel_mci_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
+   struct atmel_mci_priv *priv = dev_get_priv(dev);
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+#else
  static int
  mci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data)
  {
struct atmel_mci_priv *priv = mmc->priv;
+#endif
atmel_mci_t *mci = priv->mci;
u32 cmdr;
u32 error_flags = 0;
@@ -335,17 +359,28 @@ mci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct 
mmc_data *data)
return 0;
  }
  
+#ifdef CONFIG_DM_MMC

+static int atmel_mci_set_ios(struct udevice *dev)
+{
+   struct atmel_mci_priv *priv = dev_get_priv(dev);
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+#else
  /* Entered into mmc structure during driver init */
  static int mci_set_ios(struct mmc *mmc)
  {
struct atmel_mci_priv *priv = mmc->priv;
+#endif
atmel_mci_t *mci = priv->mci;
int bus_width = mmc->bus_width;
unsigned int version = atmel_mci_get_version(mci);
int busw;
  
  	/* Set the clock speed */

+#ifdef CONFIG_DM_MMC
+   mci_set_mode(priv, mmc->clock, MMC_DEFAULT_BLKLEN);
+#else
mci_set_mode(mmc, mmc->clock, MMC_DEFAULT_BLKLEN);
+#endif
  
  	/*

 * set the bus width and select slot for this interface

[U-Boot] [PATCH] ARM: DT: STM32F746: add u-boot, dm-pre-reloc property to sub nodes

[Vikas Manocha]

This patch is required for correct SPL device tree creation by fdtgrep
as fdtgrep looks for u-boot,dm-pre-reloc property of the node to include
it in the spl device tree.

Not adding it in these subnodes ignores the pin muxing of peripherals
which is almost always in the subnodes.

Signed-off-by: Vikas Manocha 
---
 arch/arm/dts/stm32f746-disco.dts | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 2c7fa79..30c92ef 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -96,15 +96,18 @@
 
  {
usart1_pins_a: usart1@0 {
+   u-boot,dm-pre-reloc;
pins1 {
-  pinmux = ;
+   pinmux = ;
bias-disable;
drive-push-pull;
slew-rate = <2>;
+   u-boot,dm-pre-reloc;
};
pins2 {
pinmux = ;
bias-disable;
+   u-boot,dm-pre-reloc;
};
};
 
@@ -136,7 +139,9 @@
};
 
fmc_pins: fmc@0 {
+   u-boot,dm-pre-reloc;
pins {
+   u-boot,dm-pre-reloc;
pinmux = ,
 ,
 ,
@@ -198,6 +203,7 @@
mr-nbanks = <1>;
/* Memory configuration from sdram datasheet MT48LC_4M32_B2B5-6A */
bank1: bank@0 {
+  u-boot,dm-pre-reloc;
   st,sdram-control = /bits/ 8 ;
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 1/2] mx6sabresd: Make SPL DDR configuration to match the DCD table

[Fabio Estevam]

Hi Jagan,

On Tue, Apr 4, 2017 at 2:27 PM, Jagan Teki  wrote:

> No, this isn't issue, just want to understand how you create reg init
> in SPL in mx6q_dcd_table, means did you follow any order. because I'm
> planning move *dl.cfg DCD to SPL

Ok, got it. I thought you were asking about mx6qp sabreauto not booting.

On this patch I just did a 1:1 translation from DCD to SPL code.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3] fdt: allow address translation in case of SPL_OF_TRANSLATE

[Vikas Manocha]

Address translation is not working at present even if SPL_OF_TRANSLATE is
enabled which makes this configuration useless. This patch enables address
translation for SPL U-Boot when SPL_OF_TRANSLATE is selected.

Signed-off-by: Vikas Manocha 
Reviewed-by: Simon Glass 
---

Changes in v3: changed "u-boot" to "U-Boot" in commit message.
Changes in v2: Added commit message 

 lib/fdtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 81f47ef..a1c4d16 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -112,7 +112,7 @@ fdt_addr_t fdtdec_get_addr_size_fixed(const void *blob, int 
node,
return FDT_ADDR_T_NONE;
}
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_LIBFDT)
+#if defined(CONFIG_SPL_OF_TRANSLATE) || defined(CONFIG_OF_LIBFDT)
if (translate)
addr = fdt_translate_address(blob, node, prop_addr);
else
-- 
1.9.1

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

[U-Boot] [PATCH v2] fdt: allow address translation in case of SPL_OF_TRANSLATE

[Vikas Manocha]

Address translation is not working at present even if SPL_OF_TRANSLATE is
enabled which makes this configuration useless. This patch enables address
translation for SPL U-Boot when SPL_OF_TRANSLATE is selected.

Signed-off-by: Vikas Manocha 
Reviewed-by: Simon Glass 
---
Changes in v2: changed "u-boot" to "U-Boot" in commit message.

 lib/fdtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 81f47ef..a1c4d16 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -112,7 +112,7 @@ fdt_addr_t fdtdec_get_addr_size_fixed(const void *blob, int 
node,
return FDT_ADDR_T_NONE;
}
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_LIBFDT)
+#if defined(CONFIG_SPL_OF_TRANSLATE) || defined(CONFIG_OF_LIBFDT)
if (translate)
addr = fdt_translate_address(blob, node, prop_addr);
else
-- 
1.9.1

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

[U-Boot] [PATCH v2 01/18] stm32f7: use clock driver to enable qspi controller clock

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/stm32f746.dtsi |  1 +
 drivers/spi/stm32_qspi.c| 16 +++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index b2b0b5f..883f818 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -78,6 +78,7 @@
reg-names = "QuadSPI", "QuadSPI-memory";
interrupts = <92>;
spi-max-frequency = <10800>;
+   clocks = < 0 65>;
status = "disabled";
};
usart1: serial@40011000 {
diff --git a/drivers/spi/stm32_qspi.c b/drivers/spi/stm32_qspi.c
index 05358eb..f0434a4 100644
--- a/drivers/spi/stm32_qspi.c
+++ b/drivers/spi/stm32_qspi.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -457,7 +458,20 @@ static int stm32_qspi_probe(struct udevice *bus)
 
priv->max_hz = plat->max_hz;
 
-   clock_setup(QSPI_CLOCK_CFG);
+#ifdef CONFIG_CLK
+   int ret;
+   struct clk clk;
+   ret = clk_get_by_index(bus, 0, );
+   if (ret < 0)
+   return ret;
+
+   ret = clk_enable();
+
+   if (ret) {
+   dev_err(bus, "failed to enable clock\n");
+   return ret;
+   }
+#endif
 
setbits_le32(>regs->cr, STM32_QSPI_CR_SSHIFT);
 
-- 
1.9.1

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

[U-Boot] [PATCH v2 06/18] stm32f7: use clock driver to enable sdram controller clock

[Vikas Manocha]

This patch also removes the sdram/fmc clock enable from board specific
code.

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/stm32f746.dtsi|  1 +
 board/st/stm32f746-disco/stm32f746-disco.c |  2 --
 drivers/ram/stm32_sdram.c  | 15 +++
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index 3707550..e9fd6f4 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -74,6 +74,7 @@
fmc: fmc@A000 {
compatible = "st,stm32-fmc";
reg = <0xA000 0x1000>;
+   clocks = < 0 64>;
u-boot,dm-pre-reloc;
};
 
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index e1113a6..370db15 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -51,8 +51,6 @@ int dram_init(void)
if (rv)
return rv;
 
-   clock_setup(FMC_CLOCK_CFG);
-
rv = uclass_get_device(UCLASS_RAM, 0, );
if (rv) {
debug("DRAM init failed: %d\n", rv);
diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 67be61f..67d8855 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -122,6 +123,20 @@ int stm32_sdram_init(void)
 
 static int stm32_fmc_probe(struct udevice *dev)
 {
+#ifdef CONFIG_CLK
+   int ret;
+   struct clk clk;
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0)
+   return ret;
+
+   ret = clk_enable();
+
+   if (ret) {
+   dev_err(dev, "failed to enable clock\n");
+   return ret;
+   }
+#endif
stm32_sdram_init();
return 0;
 }
-- 
1.9.1

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

[U-Boot] [PATCH v2 15/18] stm32f7: increase the max no of pin configuration to 70

[Vikas Manocha]

The number of pins to be configured could be more than 50 e.g. in case
of sdram controller, there are about 56 pins (32 data lines, 12 address
& some control signals).

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

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

diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c
index 378fbaf..8a4bc1c 100644
--- a/drivers/pinctrl/pinctrl_stm32.c
+++ b/drivers/pinctrl/pinctrl_stm32.c
@@ -7,6 +7,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define MAX_PINS_ONE_IP70
 #define MODE_BITS_MASK 3
 #define OSPEED_MASK3
 #define PUPD_MASK  3
@@ -93,7 +94,7 @@ static int prep_gpio_ctl(struct stm32_gpio_ctl *gpio_ctl, u32 
gpio_fn, int node)
 static int stm32_pinctrl_set_state_simple(struct udevice *dev,
  struct udevice *periph)
 {
-   u32 pin_mux[50];
+   u32 pin_mux[MAX_PINS_ONE_IP];
struct fdtdec_phandle_args args;
int rv, len;
 
-- 
1.9.1

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

[U-Boot] [PATCH v2 10/18] stm32f7: use stm32f7 gpio driver supporting driver model

[Vikas Manocha]

With this gpio driver supporting DM, there is no need to enable clocks
for different gpios (for pin muxing) in the board specific code.

Need to increase the allocatable area required before relocation from 0x400 to
0xC00 becuase of 10 new gpio devices(& new gpio class) added in device tree.

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
Reviewed-by: Simon Glass 
---
Changed in v2: None

 arch/arm/include/asm/arch-stm32f7/gpio.h   |  3 +-
 board/st/stm32f746-disco/stm32f746-disco.c | 70 ++
 configs/stm32f746-disco_defconfig  |  4 ++
 drivers/clk/clk_stm32f7.c  | 39 -
 drivers/pinctrl/pinctrl_stm32.c|  9 +++-
 include/configs/stm32f746-disco.h  |  1 -
 6 files changed, 16 insertions(+), 110 deletions(-)

diff --git a/arch/arm/include/asm/arch-stm32f7/gpio.h 
b/arch/arm/include/asm/arch-stm32f7/gpio.h
index 5c0300f..882041d 100644
--- a/arch/arm/include/asm/arch-stm32f7/gpio.h
+++ b/arch/arm/include/asm/arch-stm32f7/gpio.h
@@ -7,6 +7,7 @@
 
 #ifndef _STM32_GPIO_H_
 #define _STM32_GPIO_H_
+#include 
 
 enum stm32_gpio_port {
STM32_GPIO_PORT_A = 0,
@@ -122,7 +123,7 @@ static inline unsigned stm32_gpio_to_pin(unsigned gpio)
return gpio % 16;
 }
 
-int stm32_gpio_config(const struct stm32_gpio_dsc *gpio_dsc,
+int stm32_gpio_config(struct gpio_desc *gpio_dsc,
const struct stm32_gpio_ctl *gpio_ctl);
 int stm32_gpout_set(const struct stm32_gpio_dsc *gpio_dsc, int state);
 
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index 370db15..45a2c47 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -20,37 +20,12 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-const struct stm32_gpio_ctl gpio_ctl_gpout = {
-   .mode = STM32_GPIO_MODE_OUT,
-   .otype = STM32_GPIO_OTYPE_PP,
-   .speed = STM32_GPIO_SPEED_50M,
-   .pupd = STM32_GPIO_PUPD_NO,
-   .af = STM32_GPIO_AF0
-};
-
-static int fmc_setup_gpio(void)
-{
-   clock_setup(GPIO_B_CLOCK_CFG);
-   clock_setup(GPIO_C_CLOCK_CFG);
-   clock_setup(GPIO_D_CLOCK_CFG);
-   clock_setup(GPIO_E_CLOCK_CFG);
-   clock_setup(GPIO_F_CLOCK_CFG);
-   clock_setup(GPIO_G_CLOCK_CFG);
-   clock_setup(GPIO_H_CLOCK_CFG);
-
-   return 0;
-}
-
 int dram_init(void)
 {
struct udevice *dev;
struct ram_info ram;
int rv;
 
-   rv = fmc_setup_gpio();
-   if (rv)
-   return rv;
-
rv = uclass_get_device(UCLASS_RAM, 0, );
if (rv) {
debug("DRAM init failed: %d\n", rv);
@@ -73,37 +48,21 @@ int dram_init(void)
return rv;
 }
 
-int uart_setup_gpio(void)
-{
-   clock_setup(GPIO_A_CLOCK_CFG);
-   clock_setup(GPIO_B_CLOCK_CFG);
-   return 0;
-}
-
 #ifdef CONFIG_ETH_DESIGNWARE
-
 static int stmmac_setup(void)
 {
clock_setup(SYSCFG_CLOCK_CFG);
/* Set >RMII mode */
STM32_SYSCFG->pmc |= SYSCFG_PMC_MII_RMII_SEL;
-
-   clock_setup(GPIO_A_CLOCK_CFG);
-   clock_setup(GPIO_C_CLOCK_CFG);
-   clock_setup(GPIO_G_CLOCK_CFG);
clock_setup(STMMAC_CLOCK_CFG);
 
return 0;
 }
-#endif
 
-#ifdef CONFIG_STM32_QSPI
-
-static int qspi_setup(void)
+int board_early_init_f(void)
 {
-   clock_setup(GPIO_B_CLOCK_CFG);
-   clock_setup(GPIO_D_CLOCK_CFG);
-   clock_setup(GPIO_E_CLOCK_CFG);
+   stmmac_setup();
+
return 0;
 }
 #endif
@@ -113,29 +72,6 @@ u32 get_board_rev(void)
return 0;
 }
 
-int board_early_init_f(void)
-{
-   int res;
-
-   res = uart_setup_gpio();
-   if (res)
-   return res;
-
-#ifdef CONFIG_ETH_DESIGNWARE
-   res = stmmac_setup();
-   if (res)
-   return res;
-#endif
-
-#ifdef CONFIG_STM32_QSPI
-   res = qspi_setup();
-   if (res)
-   return res;
-#endif
-
-   return 0;
-}
-
 int board_init(void)
 {
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
diff --git a/configs/stm32f746-disco_defconfig 
b/configs/stm32f746-disco_defconfig
index 046041a..5e86a76 100644
--- a/configs/stm32f746-disco_defconfig
+++ b/configs/stm32f746-disco_defconfig
@@ -24,6 +24,7 @@ CONFIG_CMD_DNS=y
 CONFIG_CMD_LINK_LOCAL=y
 CONFIG_CMD_TIMER=y
 CONFIG_OF_CONTROL=y
+CONFIG_DM_SEQ_ALIAS=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_NETCONSOLE=y
 # CONFIG_MMC is not set
@@ -45,3 +46,6 @@ CONFIG_PINCTRL=y
 CONFIG_PINCTRL_STM32=y
 CONFIG_RAM=y
 CONFIG_STM32_SDRAM=y
+CONFIG_DM_GPIO=y
+CONFIG_STM32F7_GPIO=y
+CONFIG_SYS_MALLOC_F_LEN=0xC00
diff --git a/drivers/clk/clk_stm32f7.c b/drivers/clk/clk_stm32f7.c
index 0d86395..da3c204 100644
--- a/drivers/clk/clk_stm32f7.c
+++ b/drivers/clk/clk_stm32f7.c
@@ -228,56 +228,17 @@ static int stm32_clk_enable(struct clk *clk)
 void clock_setup(int peripheral)
 {
switch (peripheral) {
-   case GPIO_A_CLOCK_CFG:
-   

[U-Boot] [PATCH v2 14/18] stm32f7: sdram: correct sdram configuration as per micron sdram

[Vikas Manocha]

Actually the sdram memory on stm32f746 discovery board is micron part
MT48LC_4M32_B2B5_6A. This patch does the modification required in the
device tree node & driver for the same.

Also we are passing here all the timing parameters in terms of clock
cycles, so no need to convert time(ns or ms) to cycles.

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/stm32f746-disco.dts | 13 +---
 drivers/ram/stm32_sdram.c| 55 ++--
 include/configs/stm32f746-disco.h|  1 -
 include/dt-bindings/memory/stm32-sdram.h | 15 +
 4 files changed, 33 insertions(+), 51 deletions(-)

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 8e4576b..e720ff1 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -106,12 +106,15 @@
status = "okay";
 
mr-nbanks = <1>;
-   /* sdram memory configuration from sdram datasheet IS42S16400J */
+   /* Memory configuration from sdram datasheet MT48LC_4M32_B2B5-6A */
bank1: bank@0 {
-  st,sdram-control = /bits/ 8 ;
-  st,sdram-timing = /bits/ 8 ;
+  st,sdram-control = /bits/ 8 ;
+  st,sdram-timing = /bits/ 8 ;
+   /* refcount = (64msec/total_row_sdram)*freq - 20 */
+  st,sdram-refcount = < 1542 >;
};
 };
 
diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 5e09f35..48b4979 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -21,6 +21,7 @@ struct stm32_sdram_control {
u8 memory_width;
u8 no_banks;
u8 cas_latency;
+   u8 sdclk;
u8 rd_burst;
u8 rd_pipe_delay;
 };
@@ -31,51 +32,25 @@ struct stm32_sdram_timing {
u8 tras;
u8 trc;
u8 trp;
+   u8 twr;
u8 trcd;
 };
 struct stm32_sdram_params {
u8 no_sdram_banks;
struct stm32_sdram_control sdram_control;
struct stm32_sdram_timing sdram_timing;
+   u32 sdram_ref_count;
 };
-static inline u32 _ns2clk(u32 ns, u32 freq)
-{
-   u32 tmp = freq/100;
-   return (tmp * ns) / 1000;
-}
-
-#define NS2CLK(ns) (_ns2clk(ns, freq))
-
-#define SDRAM_TREF (NS2CLK(6400 / 8192) - 20)
 
 #define SDRAM_MODE_BL_SHIFT0
 #define SDRAM_MODE_CAS_SHIFT   4
 #define SDRAM_MODE_BL  0
-#define SDRAM_MODE_CAS 3
-
-#define SDRAM_TRDL 12
 
 int stm32_sdram_init(struct udevice *dev)
 {
-   u32 freq;
-   u32 sdram_twr;
struct stm32_sdram_params *params = dev_get_platdata(dev);
 
-   /*
-* Get frequency for NS2CLK calculation.
-*/
-   freq = clock_get(CLOCK_AHB) / CONFIG_SYS_RAM_FREQ_DIV;
-   debug("%s, sdram freq = %d\n", __func__, freq);
-
-   /* Last data in to row precharge, need also comply ineq on page 1648 */
-   sdram_twr = max(
-   max(SDRAM_TRDL, params->sdram_timing.tras
-   - params->sdram_timing.trcd),
-   params->sdram_timing.trc - params->sdram_timing.trcd
-   - params->sdram_timing.trp
-  );
-
-   writel(CONFIG_SYS_RAM_FREQ_DIV << FMC_SDCR_SDCLK_SHIFT
+   writel(params->sdram_control.sdclk << FMC_SDCR_SDCLK_SHIFT
| params->sdram_control.cas_latency << FMC_SDCR_CAS_SHIFT
| params->sdram_control.no_banks << FMC_SDCR_NB_SHIFT
| params->sdram_control.memory_width << FMC_SDCR_MWID_SHIFT
@@ -85,13 +60,13 @@ int stm32_sdram_init(struct udevice *dev)
| params->sdram_control.rd_burst << FMC_SDCR_RBURST_SHIFT,
_SDRAM_FMC->sdcr1);
 
-   writel(NS2CLK(params->sdram_timing.trcd) << FMC_SDTR_TRCD_SHIFT
-   | NS2CLK(params->sdram_timing.trp) << FMC_SDTR_TRP_SHIFT
-   | NS2CLK(sdram_twr) << FMC_SDTR_TWR_SHIFT
-   | NS2CLK(params->sdram_timing.trc) << FMC_SDTR_TRC_SHIFT
-   | NS2CLK(params->sdram_timing.tras) << FMC_SDTR_TRAS_SHIFT
-   | NS2CLK(params->sdram_timing.txsr) << FMC_SDTR_TXSR_SHIFT
-   | NS2CLK(params->sdram_timing.tmrd) << FMC_SDTR_TMRD_SHIFT,
+   writel(params->sdram_timing.trcd << FMC_SDTR_TRCD_SHIFT
+   | params->sdram_timing.trp << FMC_SDTR_TRP_SHIFT
+   | params->sdram_timing.twr << FMC_SDTR_TWR_SHIFT
+   | params->sdram_timing.trc << FMC_SDTR_TRC_SHIFT
+   | params->sdram_timing.tras << FMC_SDTR_TRAS_SHIFT
+   | params->sdram_timing.txsr << FMC_SDTR_TXSR_SHIFT
+   | params->sdram_timing.tmrd << FMC_SDTR_TMRD_SHIFT,
_SDRAM_FMC->sdtr1);
 
writel(FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_START_CLOCK,
@@ -110,7 +85,7 @@ int stm32_sdram_init(struct udevice *dev)
FMC_BUSY_WAIT();
 
writel(FMC_SDCMR_BANK_1 | (SDRAM_MODE_BL << 

[U-Boot] [PATCH v2 13/18] stm32f7: enable board info read from device tree

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 include/configs/stm32f746-disco.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/stm32f746-disco.h 
b/include/configs/stm32f746-disco.h
index 3bea513..b6ad8d2 100644
--- a/include/configs/stm32f746-disco.h
+++ b/include/configs/stm32f746-disco.h
@@ -78,4 +78,5 @@
 
 #define CONFIG_CMD_MEM
 #define CONFIG_BOARD_LATE_INIT
+#define CONFIG_DISPLAY_BOARDINFO
 #endif /* __CONFIG_H */
-- 
1.9.1

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

[U-Boot] [PATCH v2 17/18] stm32f7: add support for stm32f769 disco board

[Vikas Manocha]

This board support stm32f7 family device stm32f769-I with 2MB internal Flash &
512KB RAM.
STM32F769 lines offer the performance of the Cortex-M7 core (with double
precision floating point unit) running up to 216 MHz.

To compile for stm32f769 board, use same defconfig as stm32f746-disco,
the only difference is to pass "DEVICE_TREE=stm32f769-disco".

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/Makefile|   3 +-
 arch/arm/dts/stm32f769-disco.dts | 255 +++
 2 files changed, 257 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/stm32f769-disco.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d00651c..5e27413 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -177,7 +177,8 @@ dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
 
 dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb
 
-dtb-$(CONFIG_STM32F7) += stm32f746-disco.dtb
+dtb-$(CONFIG_STM32F7) += stm32f746-disco.dtb \
+   stm32f769-disco.dtb
 
 dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-a1000.dtb \
diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
new file mode 100644
index 000..6591cc8
--- /dev/null
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -0,0 +1,255 @@
+/*
+ * Copyright 2016 - Vikas Manocha 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f746.dtsi"
+#include 
+
+/ {
+   model = "STMicroelectronics STM32F769-DISCO board";
+   compatible = "st,stm32f769-disco", "st,stm32f7";
+
+   chosen {
+   bootargs = "root=/dev/ram rdinit=/linuxrc";
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0xC000 0x100>;
+   };
+
+   aliases {
+   serial0 = 
+   spi0 = 
+   /* Aliases for gpios so as to use sequence */
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   gpio3 = 
+   gpio4 = 
+   gpio5 = 
+   gpio6 = 
+   gpio7 = 
+   gpio8 = 
+   gpio9 = 
+   gpio10 = 
+   };
+
+   led1 {
+   compatible = "st,led1";
+   led-gpio = < 5 0>;
+   };
+
+   button1 {
+   compatible = "st,button1";
+   button-gpio = < 0 0>;
+   };
+};
+
+_hse {
+   clock-frequency = <2500>;
+};
+
+ {
+   usart1_pins_a: usart1@0 {
+   pins1 {
+  pinmux = ;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <2>;
+   };
+   pins2 {
+   pinmux = ;
+   bias-disable;
+   };
+   };
+
+   ethernet_mii: mii@0 {
+ pins {
+ pinmux = ,
+,
+  

[U-Boot] [PATCH v2 16/18] stm32f7: move board specific pin muxing to dts

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/stm32f746-disco.dts | 90 
 arch/arm/dts/stm32f746.dtsi  | 86 --
 2 files changed, 90 insertions(+), 86 deletions(-)

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index e720ff1..2c7fa79 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -94,6 +94,96 @@
clock-frequency = <2500>;
 };
 
+ {
+   usart1_pins_a: usart1@0 {
+   pins1 {
+  pinmux = ;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <2>;
+   };
+   pins2 {
+   pinmux = ;
+   bias-disable;
+   };
+   };
+
+   ethernet_mii: mii@0 {
+ pins {
+ pinmux = ,
+,
+,
+,
+,
+
,
+,
+,
+;
+ slew-rate = <2>;
+ };
+   };
+
+   qspi_pins: qspi@0 {
+   pins {
+   pinmux = ,
+  ,
+  ,
+  ,
+  ,
+  ;
+   slew-rate = <2>;
+   };
+   };
+
+   fmc_pins: fmc@0 {
+   pins {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+
+,
+,
+
+,
+,
+
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+
+,
+,
+,
+,
+,
+;
+ slew-rate = <2>;
+   };
+   };
+};
+
  {
pinctrl-0 = <_pins_a>;
pinctrl-names = "default";
diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index 865d5cf..ac24d98 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -225,92 +225,6 @@
u-boot,dm-pre-reloc;
};
 
-   usart1_pins_a: usart1@0 {
-   pins1 {
-   pinmux = ;
-   bias-disable;
-   drive-push-pull;
-   slew-rate = <2>;
-   };
-   pins2 {
-   pinmux = ;
-   bias-disable;
-   };
-   };
-   ethernet_mii: mii@0 {
-   pins {
-   pinmux = 
,
-
,
-
,
-,
-,
-
,
-
,
-
,
-
;
-   slew-rate = <2>;
-   };
-   };
-   qspi_pins: qspi@0{
-   pins {
-   pinmux = 
,
-
,
-
,
-  

[U-Boot] [PATCH v2 11/18] stm32f746: to switch on user LED1 & read user button

[Vikas Manocha]

All discovery boards have one user button & one user LED. Here we are
just reading the button status & switching ON the user LED.

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/stm32f746-disco.dts   | 10 
 board/st/stm32f746-disco/stm32f746-disco.c | 37 ++
 include/configs/stm32f746-disco.h  |  1 +
 3 files changed, 48 insertions(+)

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index f830aa9..8e4576b 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -78,6 +78,16 @@
gpio9 = 
gpio10 = 
};
+
+   led1 {
+   compatible = "st,led1";
+   led-gpio = < 1 0>;
+   };
+
+   button1 {
+   compatible = "st,button1";
+   button-gpio = < 11 0>;
+   };
 };
 
 _hse {
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index 45a2c47..52c1900 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -72,6 +73,42 @@ u32 get_board_rev(void)
return 0;
 }
 
+int board_late_init(void)
+{
+   struct gpio_desc gpio = {};
+   int node;
+
+   node = fdt_node_offset_by_compatible(gd->fdt_blob, 0, "st,led1");
+   if (node < 0)
+   return -1;
+
+   gpio_request_by_name_nodev(gd->fdt_blob, node, "led-gpio", 0, ,
+  GPIOD_IS_OUT);
+
+   if (dm_gpio_is_valid()) {
+   dm_gpio_set_value(, 0);
+   mdelay(10);
+   dm_gpio_set_value(, 1);
+   }
+
+   /* read button 1*/
+   node = fdt_node_offset_by_compatible(gd->fdt_blob, 0, "st,button1");
+   if (node < 0)
+   return -1;
+
+   gpio_request_by_name_nodev(gd->fdt_blob, node, "button-gpio", 0, ,
+  GPIOD_IS_IN);
+
+   if (dm_gpio_is_valid()) {
+   if (dm_gpio_get_value())
+   puts("usr button is at HIGH LEVEL\n");
+   else
+   puts("usr button is at LOW LEVEL\n");
+   }
+
+   return 0;
+}
+
 int board_init(void)
 {
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
diff --git a/include/configs/stm32f746-disco.h 
b/include/configs/stm32f746-disco.h
index fe3ac34..f5f9f0b 100644
--- a/include/configs/stm32f746-disco.h
+++ b/include/configs/stm32f746-disco.h
@@ -81,4 +81,5 @@
 #define CONFIG_CMDLINE_EDITING
 
 #define CONFIG_CMD_MEM
+#define CONFIG_BOARD_LATE_INIT
 #endif /* __CONFIG_H */
-- 
1.9.1

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

[U-Boot] [PATCH v2 08/18] dm: gpio: Add driver for stm32f7 gpio controller

[Vikas Manocha]

This patch adds gpio driver supporting driver model for stm32f7 gpio.

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---

Changes in v2:
- included files in correct order.
- moved the pinctrl specific routine from gpio driver to pinctrl
- used dev_get_addr() instead of fdtdec_get_addr_size_auto_parent() in
  gpio driver.
- pointed gpio name to bank name in device tree blob rather than copy.

 arch/arm/include/asm/arch-stm32f7/gpio.h |  16 
 drivers/gpio/Kconfig |   9 +++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/stm32f7_gpio.c  | 135 +++
 drivers/pinctrl/pinctrl_stm32.c  |  36 -
 5 files changed, 196 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpio/stm32f7_gpio.c

diff --git a/arch/arm/include/asm/arch-stm32f7/gpio.h 
b/arch/arm/include/asm/arch-stm32f7/gpio.h
index 2942cd9..5c0300f 100644
--- a/arch/arm/include/asm/arch-stm32f7/gpio.h
+++ b/arch/arm/include/asm/arch-stm32f7/gpio.h
@@ -96,6 +96,22 @@ struct stm32_gpio_ctl {
enum stm32_gpio_af  af;
 };
 
+struct stm32_gpio_regs {
+   u32 moder;  /* GPIO port mode */
+   u32 otyper; /* GPIO port output type */
+   u32 ospeedr;/* GPIO port output speed */
+   u32 pupdr;  /* GPIO port pull-up/pull-down */
+   u32 idr;/* GPIO port input data */
+   u32 odr;/* GPIO port output data */
+   u32 bsrr;   /* GPIO port bit set/reset */
+   u32 lckr;   /* GPIO port configuration lock */
+   u32 afr[2]; /* GPIO alternate function */
+};
+
+struct stm32_gpio_priv {
+   struct stm32_gpio_regs *regs;
+};
+
 static inline unsigned stm32_gpio_to_port(unsigned gpio)
 {
return gpio / 16;
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8d9ab52..c8af398 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -151,6 +151,15 @@ config PIC32_GPIO
help
  Say yes here to support Microchip PIC32 GPIOs.
 
+config STM32F7_GPIO
+   bool "ST STM32 GPIO driver"
+   depends on DM_GPIO
+   default y
+   help
+ Device model driver support for STM32 GPIO controller. It should be
+ usable on many stm32 families like stm32f4 & stm32H7.
+ Tested on STM32F7.
+
 config MVEBU_GPIO
bool "Marvell MVEBU GPIO driver"
depends on DM_GPIO && ARCH_MVEBU
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 8939226..9c2a9cc 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -49,6 +49,7 @@ oby-$(CONFIG_SX151X)  += sx151x.o
 obj-$(CONFIG_SUNXI_GPIO)   += sunxi_gpio.o
 obj-$(CONFIG_LPC32XX_GPIO) += lpc32xx_gpio.o
 obj-$(CONFIG_STM32_GPIO)   += stm32_gpio.o
+obj-$(CONFIG_STM32F7_GPIO) += stm32f7_gpio.o
 obj-$(CONFIG_GPIO_UNIPHIER)+= gpio-uniphier.o
 obj-$(CONFIG_ZYNQ_GPIO)+= zynq_gpio.o
 obj-$(CONFIG_VYBRID_GPIO)  += vybrid_gpio.o
diff --git a/drivers/gpio/stm32f7_gpio.c b/drivers/gpio/stm32f7_gpio.c
new file mode 100644
index 000..5ab1c5c
--- /dev/null
+++ b/drivers/gpio/stm32f7_gpio.c
@@ -0,0 +1,135 @@
+/*
+ * (C) Copyright 2017
+ * Vikas Manocha, 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#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);
+   struct stm32_gpio_regs *regs = priv->regs;
+   int bits_index = MODE_BITS(offset);
+   int mask = MODE_BITS_MASK << bits_index;
+
+   clrsetbits_le32(>moder, mask, STM32_GPIO_MODE_IN << bits_index);
+
+   return 0;
+}
+
+static int stm32_gpio_direction_output(struct udevice *dev, unsigned offset,
+  int value)
+{
+   struct stm32_gpio_priv *priv = dev_get_priv(dev);
+   struct stm32_gpio_regs *regs = priv->regs;
+   int bits_index = MODE_BITS(offset);
+   int mask = MODE_BITS_MASK << bits_index;
+
+   clrsetbits_le32(>moder, mask, STM32_GPIO_MODE_OUT << bits_index);
+   mask = IN_OUT_BIT_INDEX(offset);
+   clrsetbits_le32(>odr, mask, value ? mask : 0);
+
+   return 0;
+}
+
+static int stm32_gpio_get_value(struct udevice *dev, unsigned offset)
+{
+   struct stm32_gpio_priv *priv = dev_get_priv(dev);
+   struct stm32_gpio_regs *regs = priv->regs;
+
+   return readl(>idr) & IN_OUT_BIT_INDEX(offset) ? 1 : 0;
+}
+
+static int stm32_gpio_set_value(struct udevice *dev, unsigned offset, int 
value)
+{
+   struct stm32_gpio_priv *priv = 

[U-Boot] [PATCH v2 03/18] stm32f7: dm: add driver model support for sdram

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 drivers/ram/stm32_sdram.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 13f8964..67be61f 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -6,6 +6,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -117,3 +119,32 @@ int stm32_sdram_init(void)
 
return 0;
 }
+
+static int stm32_fmc_probe(struct udevice *dev)
+{
+   stm32_sdram_init();
+   return 0;
+}
+
+static int stm32_fmc_get_info(struct udevice *dev, struct ram_info *info)
+{
+   info->size = CONFIG_SYS_RAM_SIZE;
+   return 0;
+}
+
+static struct ram_ops stm32_fmc_ops = {
+   .get_info = stm32_fmc_get_info,
+};
+
+static const struct udevice_id stm32_fmc_ids[] = {
+   { .compatible = "st,stm32-fmc" },
+   { }
+};
+
+U_BOOT_DRIVER(stm32_fmc) = {
+   .name = "stm32_fmc",
+   .id = UCLASS_RAM,
+   .of_match = stm32_fmc_ids,
+   .ops = _fmc_ops,
+   .probe = stm32_fmc_probe,
+};
-- 
1.9.1

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

[U-Boot] [PATCH v2 09/18] ARM: DT: stm32f7: add gpio device tree nodes

[Vikas Manocha]

Also created alias for gpios for stm32f7 discovery board. Based on these
aliases, it would be possible to get gpio devices by sequence.

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/stm32f746-disco.dts |  12 +
 arch/arm/dts/stm32f746.dtsi  | 111 +++
 2 files changed, 123 insertions(+)

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index f098d2e..f830aa9 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -65,6 +65,18 @@
aliases {
serial0 = 
spi0 = 
+   /* Aliases for gpios so as to use sequence */
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   gpio3 = 
+   gpio4 = 
+   gpio5 = 
+   gpio6 = 
+   gpio7 = 
+   gpio8 = 
+   gpio9 = 
+   gpio10 = 
};
 };
 
diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index e9fd6f4..865d5cf 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -114,6 +114,117 @@
u-boot,dm-pre-reloc;
pins-are-numbered;
 
+   gpioa: gpio@4002 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   compatible = "st,stm32-gpio";
+   reg = <0x0 0x400>;
+   clocks = < 0 0>;
+   st,bank-name = "GPIOA";
+   u-boot,dm-pre-reloc;
+   };
+
+   gpiob: gpio@40020400 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   compatible = "st,stm32-gpio";
+   reg = <0x400 0x400>;
+   clocks = < 0 1>;
+   st,bank-name = "GPIOB";
+   u-boot,dm-pre-reloc;
+   };
+
+
+   gpioc: gpio@40020800 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   compatible = "st,stm32-gpio";
+   reg = <0x800 0x400>;
+   clocks = < 0 2>;
+   st,bank-name = "GPIOC";
+   u-boot,dm-pre-reloc;
+   };
+
+   gpiod: gpio@40020c00 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   compatible = "st,stm32-gpio";
+   reg = <0xc00 0x400>;
+   clocks = < 0 3>;
+   st,bank-name = "GPIOD";
+   u-boot,dm-pre-reloc;
+   };
+
+   gpioe: gpio@40021000 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   compatible = "st,stm32-gpio";
+   reg = <0x1000 0x400>;
+   clocks = < 0 4>;
+   st,bank-name = "GPIOE";
+   u-boot,dm-pre-reloc;
+   };
+
+   gpiof: gpio@40021400 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   compatible = "st,stm32-gpio";
+   reg = <0x1400 0x400>;
+   clocks = < 0 5>;
+   st,bank-name = "GPIOF";
+   u-boot,dm-pre-reloc;
+   };
+
+   gpiog: gpio@40021800 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   compatible = "st,stm32-gpio";
+   reg = <0x1800 0x400>;
+   clocks = < 0 6>;
+   st,bank-name = "GPIOG";
+   u-boot,dm-pre-reloc;
+   };
+
+   gpioh: gpio@40021c00 {
+   gpio-controller;
+   #gpio-cells = <2>;
+   compatible = "st,stm32-gpio";
+   reg = <0x1c00 0x400>;
+   clocks = < 0 7>;
+   st,bank-name = "GPIOH";
+   u-boot,dm-pre-reloc;
+   };
+
+   gpioi: gpio@40022000 {
+  

[U-Boot] [PATCH v2 07/18] stm32f7: sdram: use sdram device tree node to configure sdram controller

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/stm32f746-disco.dts |  10 +++
 drivers/ram/stm32_sdram.c| 144 +++
 include/dt-bindings/memory/stm32-sdram.h |  34 
 3 files changed, 135 insertions(+), 53 deletions(-)
 create mode 100644 include/dt-bindings/memory/stm32-sdram.h

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 5846b0d..f098d2e 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -47,6 +47,7 @@
 
 /dts-v1/;
 #include "stm32f746.dtsi"
+#include 
 
 / {
model = "STMicroelectronics STM32F746-DISCO board";
@@ -81,6 +82,15 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
status = "okay";
+
+   mr-nbanks = <1>;
+   /* sdram memory configuration from sdram datasheet IS42S16400J */
+   bank1: bank@0 {
+  st,sdram-control = /bits/ 8 ;
+  st,sdram-timing = /bits/ 8 ;
+   };
 };
 
  {
diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index 67d8855..eb1ab94 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -13,6 +13,31 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
+struct stm32_sdram_control {
+   u8 no_columns;
+   u8 no_rows;
+   u8 memory_width;
+   u8 no_banks;
+   u8 cas_latency;
+   u8 rd_burst;
+   u8 rd_pipe_delay;
+};
+
+struct stm32_sdram_timing {
+   u8 tmrd;
+   u8 txsr;
+   u8 tras;
+   u8 trc;
+   u8 trp;
+   u8 trcd;
+};
+struct stm32_sdram_params {
+   u8 no_sdram_banks;
+   struct stm32_sdram_control sdram_control;
+   struct stm32_sdram_timing sdram_timing;
+};
 static inline u32 _ns2clk(u32 ns, u32 freq)
 {
u32 tmp = freq/100;
@@ -21,73 +46,53 @@ static inline u32 _ns2clk(u32 ns, u32 freq)
 
 #define NS2CLK(ns) (_ns2clk(ns, freq))
 
-/*
- * Following are timings for IS42S16400J, from corresponding datasheet
- */
-#define SDRAM_CAS  3   /* 3 cycles */
-#define SDRAM_NB   1   /* Number of banks */
-#define SDRAM_MWID 1   /* 16 bit memory */
-
-#define SDRAM_NR   0x1 /* 12-bit row */
-#define SDRAM_NC   0x0 /* 8-bit col */
-#define SDRAM_RBURST   0x1 /* Single read requests always as bursts */
-#define SDRAM_RPIPE0x0 /* No HCLK clock cycle delay */
-
-#define SDRAM_TRRD NS2CLK(12)
-#define SDRAM_TRCD NS2CLK(18)
-#define SDRAM_TRP  NS2CLK(18)
-#define SDRAM_TRAS NS2CLK(42)
-#define SDRAM_TRC  NS2CLK(60)
-#define SDRAM_TRFC NS2CLK(60)
-#define SDRAM_TCDL (1 - 1)
-#define SDRAM_TRDL NS2CLK(12)
-#define SDRAM_TBDL (1 - 1)
 #define SDRAM_TREF (NS2CLK(6400 / 8192) - 20)
-#define SDRAM_TCCD (1 - 1)
-
-#define SDRAM_TXSR SDRAM_TRFC  /* Row cycle time after precharge */
-#define SDRAM_TMRD 1   /* Page 10, Mode Register Set */
-
-
-/* Last data in to row precharge, need also comply ineq on page 1648 */
-#define SDRAM_TWR  max(\
-   (int)max((int)SDRAM_TRDL, (int)(SDRAM_TRAS - SDRAM_TRCD)), \
-   (int)(SDRAM_TRC - SDRAM_TRCD - SDRAM_TRP)\
-   )
-
 
 #define SDRAM_MODE_BL_SHIFT0
 #define SDRAM_MODE_CAS_SHIFT   4
 #define SDRAM_MODE_BL  0
-#define SDRAM_MODE_CAS SDRAM_CAS
+#define SDRAM_MODE_CAS 3
+
+#define SDRAM_TRDL 12
 
-int stm32_sdram_init(void)
+int stm32_sdram_init(struct udevice *dev)
 {
u32 freq;
+   u32 sdram_twr;
+   struct stm32_sdram_params *params = dev_get_platdata(dev);
 
/*
 * Get frequency for NS2CLK calculation.
 */
freq = clock_get(CLOCK_AHB) / CONFIG_SYS_RAM_FREQ_DIV;
+   debug("%s, sdram freq = %d\n", __func__, freq);
+
+   /* Last data in to row precharge, need also comply ineq on page 1648 */
+   sdram_twr = max(
+   max(SDRAM_TRDL, params->sdram_timing.tras
+   - params->sdram_timing.trcd),
+   params->sdram_timing.trc - params->sdram_timing.trcd
+   - params->sdram_timing.trp
+  );
 
writel(CONFIG_SYS_RAM_FREQ_DIV << FMC_SDCR_SDCLK_SHIFT
-   | SDRAM_CAS << FMC_SDCR_CAS_SHIFT
-   | SDRAM_NB << FMC_SDCR_NB_SHIFT
-   | SDRAM_MWID << FMC_SDCR_MWID_SHIFT
-   | SDRAM_NR << FMC_SDCR_NR_SHIFT
-   | SDRAM_NC << FMC_SDCR_NC_SHIFT
-   | SDRAM_RPIPE << FMC_SDCR_RPIPE_SHIFT
-   | SDRAM_RBURST << FMC_SDCR_RBURST_SHIFT,
-   _SDRAM_FMC->sdcr1);
-
-   writel(SDRAM_TRCD << FMC_SDTR_TRCD_SHIFT
-   | SDRAM_TRP << FMC_SDTR_TRP_SHIFT
-   | SDRAM_TWR << FMC_SDTR_TWR_SHIFT
-   | SDRAM_TRC << 

[U-Boot] [PATCH v2 12/18] stm32f7: stm32f746-disco: read memory info from device tree

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 board/st/stm32f746-disco/stm32f746-disco.c | 42 +-
 drivers/ram/stm32_sdram.c  |  1 -
 include/configs/stm32f746-disco.h  |  6 +
 3 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index 52c1900..4b0c7f0 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -21,32 +21,49 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+int get_memory_base_size(fdt_addr_t *mr_base, fdt_addr_t *mr_size)
+{
+   int mr_node;
+
+   mr_node = fdt_path_offset(gd->fdt_blob, "/memory");
+   if (mr_node < 0)
+   return mr_node;
+   *mr_base = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, mr_node,
+ "reg", 0, mr_size, false);
+   debug("mr_base = %lx, mr_size= %lx\n", *mr_base, *mr_size);
+
+   return 0;
+}
 int dram_init(void)
 {
struct udevice *dev;
-   struct ram_info ram;
int rv;
+   fdt_addr_t mr_base, mr_size;
 
rv = uclass_get_device(UCLASS_RAM, 0, );
if (rv) {
debug("DRAM init failed: %d\n", rv);
return rv;
}
-   rv = ram_get_info(dev, );
-   if (rv) {
-   debug("Cannot get DRAM size: %d\n", rv);
+
+   rv = get_memory_base_size(_base, _size);
+   if (rv)
return rv;
-   }
-   debug("SDRAM base=%lx, size=%x\n", ram.base, ram.size);
-   gd->ram_size = ram.size;
+   gd->ram_size = mr_size;
+   gd->ram_top = mr_base;
 
+   return rv;
+}
+
+void dram_init_banksize(void)
+{
+   fdt_addr_t mr_base, mr_size;
+   get_memory_base_size(_base, _size);
/*
 * Fill in global info with description of SRAM configuration
 */
-   gd->bd->bi_dram[0].start = CONFIG_SYS_RAM_BASE;
-   gd->bd->bi_dram[0].size  = ram.size;
-
-   return rv;
+   gd->bd->bi_dram[0].start = mr_base;
+   gd->bd->bi_dram[0].size  = mr_size;
 }
 
 #ifdef CONFIG_ETH_DESIGNWARE
@@ -111,7 +128,6 @@ int board_late_init(void)
 
 int board_init(void)
 {
-   gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
-
+   gd->bd->bi_boot_params = gd->bd->bi_dram[0].start + 0x100;
return 0;
 }
diff --git a/drivers/ram/stm32_sdram.c b/drivers/ram/stm32_sdram.c
index eb1ab94..5e09f35 100644
--- a/drivers/ram/stm32_sdram.c
+++ b/drivers/ram/stm32_sdram.c
@@ -179,7 +179,6 @@ static int stm32_fmc_probe(struct udevice *dev)
 
 static int stm32_fmc_get_info(struct udevice *dev, struct ram_info *info)
 {
-   info->size = CONFIG_SYS_RAM_SIZE;
return 0;
 }
 
diff --git a/include/configs/stm32f746-disco.h 
b/include/configs/stm32f746-disco.h
index f5f9f0b..3bea513 100644
--- a/include/configs/stm32f746-disco.h
+++ b/include/configs/stm32f746-disco.h
@@ -21,11 +21,7 @@
  * Configuration of the external SDRAM memory
  */
 #define CONFIG_NR_DRAM_BANKS   1
-#define CONFIG_SYS_RAM_SIZE(8 * 1024 * 1024)
-#define CONFIG_SYS_RAM_CS  1
-#define CONFIG_SYS_RAM_FREQ_DIV2
-#define CONFIG_SYS_RAM_BASE0xC000
-#define CONFIG_SYS_SDRAM_BASE  CONFIG_SYS_RAM_BASE
+#define CONFIG_SYS_RAM_FREQ_DIV 2
 #define CONFIG_SYS_LOAD_ADDR   0xC040
 #define CONFIG_LOADADDR0xC040
 
-- 
1.9.1

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

[U-Boot] [PATCH v2 18/18] stm32f7: remove not needed configuration from board config

[Vikas Manocha]

This patch removes:
- CONFIG_CMD_MEM: enabled by default
- CONFIG_DESIGNWARE_ETH : not being used anywhere.

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 include/configs/stm32f746-disco.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/configs/stm32f746-disco.h 
b/include/configs/stm32f746-disco.h
index 213bdcc..3771a6a 100644
--- a/include/configs/stm32f746-disco.h
+++ b/include/configs/stm32f746-disco.h
@@ -33,7 +33,6 @@
 #define CONFIG_STM32_FLASH
 #define CONFIG_STM32X7_SERIAL
 
-#define CONFIG_DESIGNWARE_ETH
 #define CONFIG_DW_GMAC_DEFAULT_DMA_PBL (8)
 #define CONFIG_DW_ALTDESCRIPTOR
 #define CONFIG_MII
@@ -75,7 +74,6 @@
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 
-#define CONFIG_CMD_MEM
 #define CONFIG_BOARD_LATE_INIT
 #define CONFIG_DISPLAY_BOARDINFO
 #endif /* __CONFIG_H */
-- 
1.9.1

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

[U-Boot] [PATCH v2 04/18] ARM: DT: stm32f7: add sdram pin contol node

[Vikas Manocha]

Also added DT binding doc for stm32 fmc(flexible memory controller).

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 arch/arm/dts/stm32f746-disco.dts  |  7 
 arch/arm/dts/stm32f746.dtsi   | 56 +++
 doc/device-tree-bindings/ram/st,stm32-fmc.txt | 51 
 3 files changed, 114 insertions(+)
 create mode 100644 doc/device-tree-bindings/ram/st,stm32-fmc.txt

diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 07e0ca7..5846b0d 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -1,5 +1,6 @@
 /*
  * Copyright 2016 - Michael Kurz 
+ * Copyright 2016 - Vikas MANOCHA 
  *
  * Based on:
  * stm32f469-disco.dts from Linux
@@ -76,6 +77,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+};
+
  {
status = "okay";
pinctrl-0 = <_mii>;
diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index 883f818..3707550 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -1,5 +1,6 @@
 /*
  * Copyright 2016 - Michael Kurz 
+ * Copyright 2016 - Vikas MANOCHA 
  *
  * Based on:
  * stm32f429.dtsi from Linux
@@ -70,6 +71,12 @@
status = "disabled";
};
 
+   fmc: fmc@A000 {
+   compatible = "st,stm32-fmc";
+   reg = <0xA000 0x1000>;
+   u-boot,dm-pre-reloc;
+   };
+
qspi: quadspi@A0001000 {
compatible = "st,stm32-qspi";
#address-cells = <1>;
@@ -143,6 +150,55 @@
slew-rate = <2>;
};
};
+
+   fmc_pins: fmc@0 {
+   pins {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+
+,
+,
+
+
,
+
,
+
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+
+,
+,
+
,
+
,
+
,
+;
+   slew-rate = <2>;
+   };
+   };
+
};
};
 };
diff --git a/doc/device-tree-bindings/ram/st,stm32-fmc.txt 
b/doc/device-tree-bindings/ram/st,stm32-fmc.txt
new file mode 100644
index 000..3d1392c
--- /dev/null
+++ b/doc/device-tree-bindings/ram/st,stm32-fmc.txt
@@ -0,0 +1,51 @@
+ST, stm32 flexible memory controller Drive
+Required properties:
+- compatible   : "st,stm32-fmc"
+- reg  : fmc controller base address
+- clocks   : fmc controller clock
+u-boot,dm-pre-reloc: flag to initialize memory before relocation.
+
+on-board sdram memory attributes:
+- st,sdram-control : parameters for sdram configuration, in this order:
+  number of columns
+  number of rows
+  memory width
+  number of intenal banks in memory
+  cas latency
+  read burst enable or disable
+  read pipe delay
+
+- st,sdram-timing: timings for 

[U-Boot] [PATCH v2 05/18] stm32f7: use driver model for sdram initialization

[Vikas Manocha]

As driver model takes care of pin control configuraion, this patch also
removes the sdram/fmc pin configuration.

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 board/st/stm32f746-disco/stm32f746-disco.c | 89 +++---
 1 file changed, 19 insertions(+), 70 deletions(-)

diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index 1569358..e1113a6 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -6,6 +6,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -26,66 +28,8 @@ const struct stm32_gpio_ctl gpio_ctl_gpout = {
.af = STM32_GPIO_AF0
 };
 
-const struct stm32_gpio_ctl gpio_ctl_fmc = {
-   .mode = STM32_GPIO_MODE_AF,
-   .otype = STM32_GPIO_OTYPE_PP,
-   .speed = STM32_GPIO_SPEED_100M,
-   .pupd = STM32_GPIO_PUPD_NO,
-   .af = STM32_GPIO_AF12
-};
-
-static const struct stm32_gpio_dsc ext_ram_fmc_gpio[] = {
-   /* Chip is LQFP144, see DM00077036.pdf for details */
-   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_10}, /* 79, FMC_D15 */
-   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_9},  /* 78, FMC_D14 */
-   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_8},  /* 77, FMC_D13 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_15}, /* 68, FMC_D12 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_14}, /* 67, FMC_D11 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_13}, /* 66, FMC_D10 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_12}, /* 65, FMC_D9 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_11}, /* 64, FMC_D8 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_10}, /* 63, FMC_D7 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_9},  /* 60, FMC_D6 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_8},  /* 59, FMC_D5 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_7},  /* 58, FMC_D4 */
-   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_1},  /* 115, FMC_D3 */
-   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_0},  /* 114, FMC_D2 */
-   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_15}, /* 86, FMC_D1 */
-   {STM32_GPIO_PORT_D, STM32_GPIO_PIN_14}, /* 85, FMC_D0 */
-
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_1},  /* 142, FMC_NBL1 */
-   {STM32_GPIO_PORT_E, STM32_GPIO_PIN_0},  /* 141, FMC_NBL0 */
-
-   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_5},  /* 90, FMC_A15, BA1 */
-   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_4},  /* 89, FMC_A14, BA0 */
-
-   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_1},  /* 57, FMC_A11 */
-   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_0},  /* 56, FMC_A10 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_15}, /* 55, FMC_A9 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_14}, /* 54, FMC_A8 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_13}, /* 53, FMC_A7 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_12}, /* 50, FMC_A6 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_5},  /* 15, FMC_A5 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_4},  /* 14, FMC_A4 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_3},  /* 13, FMC_A3 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_2},  /* 12, FMC_A2 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_1},  /* 11, FMC_A1 */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_0},  /* 10, FMC_A0 */
-
-   {STM32_GPIO_PORT_H, STM32_GPIO_PIN_3},  /* 136, SDRAM_NE */
-   {STM32_GPIO_PORT_F, STM32_GPIO_PIN_11}, /* 49, SDRAM_NRAS */
-   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_15}, /* 132, SDRAM_NCAS */
-   {STM32_GPIO_PORT_H, STM32_GPIO_PIN_5},  /* 26, SDRAM_NWE */
-   {STM32_GPIO_PORT_C, STM32_GPIO_PIN_3},  /* 135, SDRAM_CKE */
-
-   {STM32_GPIO_PORT_G, STM32_GPIO_PIN_8},  /* 93, SDRAM_CLK */
-};
-
 static int fmc_setup_gpio(void)
 {
-   int rv = 0;
-   int i;
-
clock_setup(GPIO_B_CLOCK_CFG);
clock_setup(GPIO_C_CLOCK_CFG);
clock_setup(GPIO_D_CLOCK_CFG);
@@ -94,19 +38,13 @@ static int fmc_setup_gpio(void)
clock_setup(GPIO_G_CLOCK_CFG);
clock_setup(GPIO_H_CLOCK_CFG);
 
-   for (i = 0; i < ARRAY_SIZE(ext_ram_fmc_gpio); i++) {
-   rv = stm32_gpio_config(_ram_fmc_gpio[i],
-   _ctl_fmc);
-   if (rv)
-   goto out;
-   }
-
-out:
-   return rv;
+   return 0;
 }
 
 int dram_init(void)
 {
+   struct udevice *dev;
+   struct ram_info ram;
int rv;
 
rv = fmc_setup_gpio();
@@ -114,15 +52,26 @@ int dram_init(void)
return rv;
 
clock_setup(FMC_CLOCK_CFG);
-   stm32_sdram_init();
+
+   rv = uclass_get_device(UCLASS_RAM, 0, );
+   if (rv) {
+   debug("DRAM init failed: %d\n", rv);
+   return rv;
+   }
+   rv = ram_get_info(dev, );
+   if (rv) {
+   debug("Cannot get DRAM size: %d\n", rv);
+   return rv;
+   }
+   debug("SDRAM base=%lx, size=%x\n", ram.base, ram.size);
+   gd->ram_size = ram.size;
 
/*
 * Fill in global info 

[U-Boot] [PATCH v2 02/18] stm32f7: sdram: move sdram driver code to ram drivers area

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
cc: Christophe KERELLO 
---
Changed in v2: None

 board/st/stm32f746-disco/stm32f746-disco.c | 113 +--
 configs/stm32f746-disco_defconfig  |   2 +
 drivers/ram/Kconfig|   8 ++
 drivers/ram/Makefile   |   1 +
 drivers/ram/stm32_sdram.c  | 119 +
 5 files changed, 131 insertions(+), 112 deletions(-)
 create mode 100644 drivers/ram/stm32_sdram.c

diff --git a/board/st/stm32f746-disco/stm32f746-disco.c 
b/board/st/stm32f746-disco/stm32f746-disco.c
index fdad8d1..1569358 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -106,57 +105,8 @@ out:
return rv;
 }
 
-static inline u32 _ns2clk(u32 ns, u32 freq)
-{
-   u32 tmp = freq/100;
-   return (tmp * ns) / 1000;
-}
-
-#define NS2CLK(ns) (_ns2clk(ns, freq))
-
-/*
- * Following are timings for IS42S16400J, from corresponding datasheet
- */
-#define SDRAM_CAS  3   /* 3 cycles */
-#define SDRAM_NB   1   /* Number of banks */
-#define SDRAM_MWID 1   /* 16 bit memory */
-
-#define SDRAM_NR   0x1 /* 12-bit row */
-#define SDRAM_NC   0x0 /* 8-bit col */
-#define SDRAM_RBURST   0x1 /* Single read requests always as bursts */
-#define SDRAM_RPIPE0x0 /* No HCLK clock cycle delay */
-
-#define SDRAM_TRRD NS2CLK(12)
-#define SDRAM_TRCD NS2CLK(18)
-#define SDRAM_TRP  NS2CLK(18)
-#define SDRAM_TRAS NS2CLK(42)
-#define SDRAM_TRC  NS2CLK(60)
-#define SDRAM_TRFC NS2CLK(60)
-#define SDRAM_TCDL (1 - 1)
-#define SDRAM_TRDL NS2CLK(12)
-#define SDRAM_TBDL (1 - 1)
-#define SDRAM_TREF (NS2CLK(6400 / 8192) - 20)
-#define SDRAM_TCCD (1 - 1)
-
-#define SDRAM_TXSR SDRAM_TRFC  /* Row cycle time after precharge */
-#define SDRAM_TMRD 1   /* Page 10, Mode Register Set */
-
-
-/* Last data in to row precharge, need also comply ineq on page 1648 */
-#define SDRAM_TWR  max(\
-   (int)max((int)SDRAM_TRDL, (int)(SDRAM_TRAS - SDRAM_TRCD)), \
-   (int)(SDRAM_TRC - SDRAM_TRCD - SDRAM_TRP)\
-)
-
-
-#define SDRAM_MODE_BL_SHIFT0
-#define SDRAM_MODE_CAS_SHIFT   4
-#define SDRAM_MODE_BL  0
-#define SDRAM_MODE_CAS SDRAM_CAS
-
 int dram_init(void)
 {
-   u32 freq;
int rv;
 
rv = fmc_setup_gpio();
@@ -164,67 +114,7 @@ int dram_init(void)
return rv;
 
clock_setup(FMC_CLOCK_CFG);
-
-   /*
-* Get frequency for NS2CLK calculation.
-*/
-   freq = clock_get(CLOCK_AHB) / CONFIG_SYS_RAM_FREQ_DIV;
-
-   writel(
-   CONFIG_SYS_RAM_FREQ_DIV << FMC_SDCR_SDCLK_SHIFT
-   | SDRAM_CAS << FMC_SDCR_CAS_SHIFT
-   | SDRAM_NB << FMC_SDCR_NB_SHIFT
-   | SDRAM_MWID << FMC_SDCR_MWID_SHIFT
-   | SDRAM_NR << FMC_SDCR_NR_SHIFT
-   | SDRAM_NC << FMC_SDCR_NC_SHIFT
-   | SDRAM_RPIPE << FMC_SDCR_RPIPE_SHIFT
-   | SDRAM_RBURST << FMC_SDCR_RBURST_SHIFT,
-   _SDRAM_FMC->sdcr1);
-
-   writel(
-   SDRAM_TRCD << FMC_SDTR_TRCD_SHIFT
-   | SDRAM_TRP << FMC_SDTR_TRP_SHIFT
-   | SDRAM_TWR << FMC_SDTR_TWR_SHIFT
-   | SDRAM_TRC << FMC_SDTR_TRC_SHIFT
-   | SDRAM_TRAS << FMC_SDTR_TRAS_SHIFT
-   | SDRAM_TXSR << FMC_SDTR_TXSR_SHIFT
-   | SDRAM_TMRD << FMC_SDTR_TMRD_SHIFT,
-   _SDRAM_FMC->sdtr1);
-
-   writel(FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_START_CLOCK,
-  _SDRAM_FMC->sdcmr);
-
-   udelay(200);/* 200 us delay, page 10, "Power-Up" */
-   FMC_BUSY_WAIT();
-
-   writel(FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_PRECHARGE,
-  _SDRAM_FMC->sdcmr);
-
-   udelay(100);
-   FMC_BUSY_WAIT();
-
-   writel((FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_AUTOREFRESH
-   | 7 << FMC_SDCMR_NRFS_SHIFT), _SDRAM_FMC->sdcmr);
-
-   udelay(100);
-   FMC_BUSY_WAIT();
-
-   writel(FMC_SDCMR_BANK_1 | (SDRAM_MODE_BL << SDRAM_MODE_BL_SHIFT
-   | SDRAM_MODE_CAS << SDRAM_MODE_CAS_SHIFT)
-   << FMC_SDCMR_MODE_REGISTER_SHIFT | FMC_SDCMR_MODE_WRITE_MODE,
-   _SDRAM_FMC->sdcmr);
-
-   udelay(100);
-
-   FMC_BUSY_WAIT();
-
-   writel(FMC_SDCMR_BANK_1 | FMC_SDCMR_MODE_NORMAL,
-  _SDRAM_FMC->sdcmr);
-
-   FMC_BUSY_WAIT();
-
-   /* Refresh timer */
-   writel(SDRAM_TREF, _SDRAM_FMC->sdrtr);
+   stm32_sdram_init();
 
/*
 * Fill in global info with description of SRAM configuration
@@ -233,7 +123,6 @@ int dram_init(void)
gd->bd->bi_dram[0].size  = CONFIG_SYS_RAM_SIZE;
 
gd->ram_size = CONFIG_SYS_RAM_SIZE;
-
return rv;
 }
 
diff 

[U-Boot] [PATCH v2 00/18] stm32f7: add sdram & gpio drivers

[Vikas Manocha]

This patchset :
- adds stm32 sdram driver based on DM
- adds stm32 gpio driver based on DM
- uses clock & pin control drivers to replace board specific
  configurations from code
- corrects sdram parameters as per correct sdram part
- adds support for stm32f769 board

Changed in v2:
- included files in correct order.
- moved the pinctrl specific routine from gpio driver to pinctrl
- used dev_get_addr() instead of fdtdec_get_addr_size_auto_parent() in
  gpio driver.
- pointed gpio name to bank name in device tree blob rather than copy.

Vikas Manocha (18):
  stm32f7: use clock driver to enable qspi controller clock
  stm32f7: sdram: move sdram driver code to ram drivers area
  stm32f7: dm: add driver model support for sdram
  ARM: DT: stm32f7: add sdram pin contol node
  stm32f7: use driver model for sdram initialization
  stm32f7: use clock driver to enable sdram controller clock
  stm32f7: sdram: use sdram device tree node to configure sdram
controller
  dm: gpio: Add driver for stm32f7 gpio controller
  ARM: DT: stm32f7: add gpio device tree nodes
  stm32f7: use stm32f7 gpio driver supporting driver model
  stm32f746: to switch on user LED1 & read user button
  stm32f7: stm32f746-disco: read memory info from device tree
  stm32f7: enable board info read from device tree
  stm32f7: sdram: correct sdram configuration as per micron sdram
  stm32f7: increase the max no of pin configuration to 70
  stm32f7: move board specific pin muxing to dts
  stm32f7: add support for stm32f769 disco board
  stm32f7: remove not needed configuration from board config

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/stm32f746-disco.dts  | 132 +++
 arch/arm/dts/stm32f746.dtsi   | 151 ++---
 arch/arm/dts/stm32f769-disco.dts  | 255 ++
 arch/arm/include/asm/arch-stm32f7/gpio.h  |  19 +-
 board/st/stm32f746-disco/stm32f746-disco.c| 301 ++
 configs/stm32f746-disco_defconfig |   6 +
 doc/device-tree-bindings/ram/st,stm32-fmc.txt |  51 +
 drivers/clk/clk_stm32f7.c |  39 
 drivers/gpio/Kconfig  |   9 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/stm32f7_gpio.c   | 135 
 drivers/pinctrl/pinctrl_stm32.c   |  48 +++-
 drivers/ram/Kconfig   |   8 +
 drivers/ram/Makefile  |   1 +
 drivers/ram/stm32_sdram.c | 179 +++
 drivers/spi/stm32_qspi.c  |  16 +-
 include/configs/stm32f746-disco.h |  10 +-
 include/dt-bindings/memory/stm32-sdram.h  |  37 
 19 files changed, 1075 insertions(+), 326 deletions(-)
 create mode 100644 arch/arm/dts/stm32f769-disco.dts
 create mode 100644 doc/device-tree-bindings/ram/st,stm32-fmc.txt
 create mode 100644 drivers/gpio/stm32f7_gpio.c
 create mode 100644 drivers/ram/stm32_sdram.c
 create mode 100644 include/dt-bindings/memory/stm32-sdram.h

-- 
1.9.1

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

[U-Boot] [PATCH v2 2/3] rsa: Fix deprecated warnings for OpenSSL 1.1.x

[Jelle van der Waa]

ERR_remove_thread_state is deprecated in OpenSSL 1.1.x and does not do
anything anymore. Thread initialisation and deinitialisation is now
handled by the OpenSSL library.

Signed-off-by: Jelle van der Waa 
Reviewed-by: Simon Glass 
---
 lib/rsa/rsa-sign.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index d4e216cc0e..8a73791fed 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -356,9 +356,9 @@ static void rsa_remove(void)
 {
CRYPTO_cleanup_all_ex_data();
ERR_free_strings();
-#ifdef HAVE_ERR_REMOVE_THREAD_STATE
+#if OPENSSL_VERSION_NUMBER >= 0x1000L && OPENSSL_VERSION_NUMBER < 
0x1010L || defined(LIBRESSL_VERSION_NUMBER)
ERR_remove_thread_state(NULL);
-#else
+#elif OPENSSL_VERSION_NUMBER < 0x1000L
ERR_remove_state(0);
 #endif
EVP_cleanup();
-- 
2.12.2

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

[U-Boot] [PATCH v2 3/3] tools: kwbimage fix build with OpenSSL 1.1.x

[Jelle van der Waa]

The rsa_st struct has been made opaque in 1.1.x, add forward compatible
code to access the n, e, d members of rsa_struct.

EVP_MD_CTX_cleanup has been removed in 1.1.x and EVP_MD_CTX_reset should be
called to reinitialise an already created structure.

Signed-off-by: Jelle van der Waa 
---
 tools/kwbimage.c | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 2c637c7446..e07e3cc467 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -22,6 +22,25 @@
 #include 
 #include 
 #include 
+
+#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
+void RSA_get0_key(const RSA *r,
+ const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
+{
+   if (n != NULL)
+   *n = r->n;
+   if (e != NULL)
+   *e = r->e;
+   if (d != NULL)
+   *d = r->d;
+}
+
+#else
+void EVP_MD_CTX_cleanup(EVP_MD_CTX *ctx)
+{
+   EVP_MD_CTX_reset(ctx);
+}
+#endif
 #endif
 
 static struct image_cfg_element *image_cfg;
@@ -470,12 +489,16 @@ static int kwb_export_pubkey(RSA *key, struct 
pubkey_der_v1 *dst, FILE *hashf,
 char *keyname)
 {
int size_exp, size_mod, size_seq;
+   const BIGNUM *key_e, *key_n;
uint8_t *cur;
char *errmsg = "Failed to encode %s\n";
 
-   if (!key || !key->e || !key->n || !dst) {
+   RSA_get0_key(key, NULL, _e, NULL);
+   RSA_get0_key(key, NULL, _n, NULL);
+
+   if (!key || !key_e || !key_n || !dst) {
fprintf(stderr, "export pk failed: (%p, %p, %p, %p)",
-   key, key->e, key->n, dst);
+   key, key_e, key_n, dst);
fprintf(stderr, errmsg, keyname);
return -EINVAL;
}
@@ -490,8 +513,8 @@ static int kwb_export_pubkey(RSA *key, struct pubkey_der_v1 
*dst, FILE *hashf,
 * do the encoding manually.
 */
 
-   size_exp = BN_num_bytes(key->e);
-   size_mod = BN_num_bytes(key->n);
+   size_exp = BN_num_bytes(key_e);
+   size_mod = BN_num_bytes(key_n);
size_seq = 4 + size_mod + 4 + size_exp;
 
if (size_mod > 256) {
@@ -520,14 +543,14 @@ static int kwb_export_pubkey(RSA *key, struct 
pubkey_der_v1 *dst, FILE *hashf,
*cur++ = 0x82;
*cur++ = (size_mod >> 8) & 0xFF;
*cur++ = size_mod & 0xFF;
-   BN_bn2bin(key->n, cur);
+   BN_bn2bin(key_n, cur);
cur += size_mod;
/* Exponent */
*cur++ = 0x02;  /* INTEGER */
*cur++ = 0x82;
*cur++ = (size_exp >> 8) & 0xFF;
*cur++ = size_exp & 0xFF;
-   BN_bn2bin(key->e, cur);
+   BN_bn2bin(key_e, cur);
 
if (hashf) {
struct hash_v1 pk_hash;
-- 
2.12.2

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

[U-Boot] [PATCH v2 1/3] rsa: Fix build with OpenSSL 1.1.x

[Jelle van der Waa]

The rsa_st struct has been made opaque in 1.1.x, add forward compatible
code to access the n, e, d members of rsa_struct.

EVP_MD_CTX_cleanup has been removed in 1.1.x and EVP_MD_CTX_reset should be
called to reinitialise an already created structure.

Tested-by: Peter Robinson 
---
 lib/rsa/rsa-sign.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 8c6637e328..d4e216cc0e 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -20,6 +20,19 @@
 #define HAVE_ERR_REMOVE_THREAD_STATE
 #endif
 
+#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
+void RSA_get0_key(const RSA *r,
+ const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
+{
+   if (n != NULL)
+   *n = r->n;
+   if (e != NULL)
+   *e = r->e;
+   if (d != NULL)
+   *d = r->d;
+}
+#endif
+
 static int rsa_err(const char *msg)
 {
unsigned long sslErr = ERR_get_error();
@@ -409,7 +422,11 @@ static int rsa_sign_with_key(RSA *rsa, struct 
checksum_algo *checksum_algo,
ret = rsa_err("Could not obtain signature");
goto err_sign;
}
-   EVP_MD_CTX_cleanup(context);
+   #if OPENSSL_VERSION_NUMBER < 0x1010L || 
defined(LIBRESSL_VERSION_NUMBER)
+   EVP_MD_CTX_cleanup(context);
+   #else
+   EVP_MD_CTX_reset(context);
+   #endif
EVP_MD_CTX_destroy(context);
EVP_PKEY_free(key);
 
@@ -479,6 +496,7 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
 {
int ret;
BIGNUM *bn_te;
+   const BIGNUM *key_e;
uint64_t te;
 
ret = -EINVAL;
@@ -487,17 +505,18 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
if (!e)
goto cleanup;
 
-   if (BN_num_bits(key->e) > 64)
+   RSA_get0_key(key, NULL, _e, NULL);
+   if (BN_num_bits(key_e) > 64)
goto cleanup;
 
-   *e = BN_get_word(key->e);
+   *e = BN_get_word(key_e);
 
-   if (BN_num_bits(key->e) < 33) {
+   if (BN_num_bits(key_e) < 33) {
ret = 0;
goto cleanup;
}
 
-   bn_te = BN_dup(key->e);
+   bn_te = BN_dup(key_e);
if (!bn_te)
goto cleanup;
 
@@ -527,6 +546,7 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
*n0_invp,
 {
BIGNUM *big1, *big2, *big32, *big2_32;
BIGNUM *n, *r, *r_squared, *tmp;
+   const BIGNUM *key_n;
BN_CTX *bn_ctx = BN_CTX_new();
int ret = 0;
 
@@ -548,7 +568,8 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
*n0_invp,
if (0 != rsa_get_exponent(key, exponent))
ret = -1;
 
-   if (!BN_copy(n, key->n) || !BN_set_word(big1, 1L) ||
+   RSA_get0_key(key, NULL, _n, NULL);
+   if (!BN_copy(n, key_n) || !BN_set_word(big1, 1L) ||
!BN_set_word(big2, 2L) || !BN_set_word(big32, 32L))
ret = -1;
 
-- 
2.12.2

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

Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support

[Stefan Agner]

On 2017-04-04 13:17, Marek Vasut wrote:
> On 04/04/2017 09:45 PM, Stefan Agner wrote:
>> On 2017-04-04 11:38, Marek Vasut wrote:
>>> On 04/04/2017 07:57 PM, Stefan Agner wrote:
 On 2017-04-04 02:22, Marek Vasut wrote:
> On 04/04/2017 02:02 AM, Stefan Agner wrote:
> [...]
> Admitedly, I didn't look at the patch, but if you want to boot ad-hoc
> cores, you can very well also boot secondary cores on the current CPU
> complex with the same command. Why not ?

 Sure, it could be done. I just feel it is not the right design.

 Auxiliary cores have usually a different view to memory, this is why I
 had to add the get_host_mapping callback in the elf loader code to let
 architecture dependent code translate to host addresses. SMP systems
 don't need that.

 Also flush caches is not necessary on some cache coherent CPU's
 (depending on how your cache coherence between I and D cache looks
 like).
>>>
>>> So SMP is just a reduced special-case of this , yes ?
>>
>> Yeah, I guess you can get away with dummy callback implementation and a
>> performance hit due to cash flushes.
>
> Or you can abstract things out ?
>

 There is one callback to arch for translation and one for cache flush,
 what more can I abstract out?
>>>
>>> Well then I don't think I understand your concerns about cache flushing
>>> in SMP .
>>>
>>
>> It makes things unnecessary slower.
> 
> You always have to flush cache if you expect the peripheral to read
> cached memory , so I don't think I understand your remark ...
> 

Which peripheral? The cache coherent CPU is going to read that memory...

 Creating a new command like bootaux comes with very few overhead.
>>>
>>> The overhead is the new command, we already have many ad-hoc commands.
>>>
>>
>> Agreed, and I really wished that this got discussed when that command
>> initially got added. I brought it up back then...
>> https://lists.denx.de/pipermail/u-boot/2016-January/240323.html
>>
>> It seemed to be acceptable to just add this ad hoc command, with some
>> "random binary format" support back then...
>
> Based on that discussion, I only see that noone opposed, but I don't see
> any agreement.
>

 Maybe I need to word my emails a bit stronger, but with that email I
 actually tried to oppose:
 https://lists.denx.de/pipermail/u-boot/2016-January/240989.html
>>>
>>> Well, I do not like adding ad-hoc commands as it's not managable in the
>>> long run.
>>>
>>
>> I argue that a remote core loading command is _much_ more manageable
>> than making the bootm command even more complex by support
>> SMP/remoteproc and whatnot usecases... I would even argue that a bunch
>> of those commands are more manageable than a single ifdef/if hell
> 
> I guess a boot* option to start remote core would do ?
> 
>> That said, I still would push for keeping the image processing code
>> generic, whenever it makes sense.
> 
> Agreed
> 
>> Ok, it is not entirely
>> random, since it is the format of a binary how it ends up in
>> microcontrollers execute in place flash (stack pointer and reset vector
>> are the two first words)
>
> I thought this command was starting the core by loading data to RAM ,
> not flash ?
>

 Ok, maybe I am a bit unclear here:

 bootaux currently supports a Cortex-M specific binary format only. The
 binary format starts with a Cortex-M class vector table. The vector
 tables first vector is the "reset vector".

 In a regular microcontroller, that binary gets flashed on a NOR flash
 which is mapped at 0x0 for the CPU. The CPU has no "boot ROM", the CPU
 starts by calling the reset vector. So when NXP defined how the bootaux
 command should look like, they just took that binary format which was
 laying around and implemented a U-Boot command around it.

 So this is the history of the binary format. And my point here is, that
 the binary format supported by bootaux is _very_ Cortex-M class
 specific.
>>>
>>> Aha, so I now totally don't understand why this command cannot be
>>> fixed/extended to support other/generic cores or SMP systems etc.
>>> But looking at the initial proposal, I think maybe the intention of this
>>> patchset was not to add that support, but to fix the command to
>>> support loading ELF files ? We already have bootelf for that though ...
>>>
>>
>> Yes, that is pretty much it. I would like to teach that command a more
>> generic format, which would be at least a step towards something more
>> generic/standardized.
>>
>> bootelf is really meant for the primary CPU. That would be an entirely
>> different direction: Make all common boot commands "aux core" capable.
>>
>> But I would strongly vote against that. First, those commands have
>> 

Re: [U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on event buffers more robust

[Dr. Philipp Tomsich]

> On 04 Apr 2017, at 22:09, Marek Vasut  wrote:
> 
>> The DWC3 flush expands to a clean+invalidate. It is not wrong, as long as
>> it is used as in my patch:
>> a. before the first time data is expected to be written by the peripheral 
>> (i.e.
>> before the peripheral is started)—to ensure that the cache line is not cached
>> any longer…
> 
> So invalidate() is enough ?

If I had to write this from scratch, I’d got with the paranoid sequence of:

handler():
{
invalidate
do my stuff
clean
}

However, some architectures in U-Boot (e.g. ARMv8) don’t implement the
invalidate verb. Given this, I’d rather stay as close to what’s already there.

Note that using flush (i.e. clean+invalidate) aligns with how caches are
managed throughout various other drivers in U-Boot.

> 
>> b. after the driver modifies any buffers (i.e. anything modified will be 
>> written
>> back) and before it next reads the buffers expecting possibly changed data
>> (i.e. invalidating).
> 
> So flush+invalidate ? Keep in mind this driver may not be used on
> ARMv7/v8 only …

Yes, a clean+invalidate.
The flush_dcache_range(…, …) function in U-Boot implements C+I semantics
at least on arm, arm64, avr32, powerpc, xtensa …

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

Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support

[Marek Vasut]

On 04/04/2017 09:45 PM, Stefan Agner wrote:
> On 2017-04-04 11:38, Marek Vasut wrote:
>> On 04/04/2017 07:57 PM, Stefan Agner wrote:
>>> On 2017-04-04 02:22, Marek Vasut wrote:
 On 04/04/2017 02:02 AM, Stefan Agner wrote:
 [...]
 Admitedly, I didn't look at the patch, but if you want to boot ad-hoc
 cores, you can very well also boot secondary cores on the current CPU
 complex with the same command. Why not ?
>>>
>>> Sure, it could be done. I just feel it is not the right design.
>>>
>>> Auxiliary cores have usually a different view to memory, this is why I
>>> had to add the get_host_mapping callback in the elf loader code to let
>>> architecture dependent code translate to host addresses. SMP systems
>>> don't need that.
>>>
>>> Also flush caches is not necessary on some cache coherent CPU's
>>> (depending on how your cache coherence between I and D cache looks
>>> like).
>>
>> So SMP is just a reduced special-case of this , yes ?
>
> Yeah, I guess you can get away with dummy callback implementation and a
> performance hit due to cash flushes.

 Or you can abstract things out ?

>>>
>>> There is one callback to arch for translation and one for cache flush,
>>> what more can I abstract out?
>>
>> Well then I don't think I understand your concerns about cache flushing
>> in SMP .
>>
> 
> It makes things unnecessary slower.

You always have to flush cache if you expect the peripheral to read
cached memory , so I don't think I understand your remark ...

>>> Creating a new command like bootaux comes with very few overhead.
>>
>> The overhead is the new command, we already have many ad-hoc commands.
>>
>
> Agreed, and I really wished that this got discussed when that command
> initially got added. I brought it up back then...
> https://lists.denx.de/pipermail/u-boot/2016-January/240323.html
>
> It seemed to be acceptable to just add this ad hoc command, with some
> "random binary format" support back then...

 Based on that discussion, I only see that noone opposed, but I don't see
 any agreement.

>>>
>>> Maybe I need to word my emails a bit stronger, but with that email I
>>> actually tried to oppose:
>>> https://lists.denx.de/pipermail/u-boot/2016-January/240989.html
>>
>> Well, I do not like adding ad-hoc commands as it's not managable in the
>> long run.
>>
> 
> I argue that a remote core loading command is _much_ more manageable
> than making the bootm command even more complex by support
> SMP/remoteproc and whatnot usecases... I would even argue that a bunch
> of those commands are more manageable than a single ifdef/if hell

I guess a boot* option to start remote core would do ?

> That said, I still would push for keeping the image processing code
> generic, whenever it makes sense.

Agreed

> Ok, it is not entirely
> random, since it is the format of a binary how it ends up in
> microcontrollers execute in place flash (stack pointer and reset vector
> are the two first words)

 I thought this command was starting the core by loading data to RAM ,
 not flash ?

>>>
>>> Ok, maybe I am a bit unclear here:
>>>
>>> bootaux currently supports a Cortex-M specific binary format only. The
>>> binary format starts with a Cortex-M class vector table. The vector
>>> tables first vector is the "reset vector".
>>>
>>> In a regular microcontroller, that binary gets flashed on a NOR flash
>>> which is mapped at 0x0 for the CPU. The CPU has no "boot ROM", the CPU
>>> starts by calling the reset vector. So when NXP defined how the bootaux
>>> command should look like, they just took that binary format which was
>>> laying around and implemented a U-Boot command around it.
>>>
>>> So this is the history of the binary format. And my point here is, that
>>> the binary format supported by bootaux is _very_ Cortex-M class
>>> specific.
>>
>> Aha, so I now totally don't understand why this command cannot be
>> fixed/extended to support other/generic cores or SMP systems etc.
>> But looking at the initial proposal, I think maybe the intention of this
>> patchset was not to add that support, but to fix the command to
>> support loading ELF files ? We already have bootelf for that though ...
>>
> 
> Yes, that is pretty much it. I would like to teach that command a more
> generic format, which would be at least a step towards something more
> generic/standardized.
> 
> bootelf is really meant for the primary CPU. That would be an entirely
> different direction: Make all common boot commands "aux core" capable.
> 
> But I would strongly vote against that. First, those commands have
> already complex arguments and argument handling (e.g. bootm), and their
> implementation supports use cases which we hardly would ever use on aux
> cores (initramfs..).

That might need some further thinking/consolidation . IMO out of scope

Re: [U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on event buffers more robust

[Marek Vasut]

On 04/04/2017 09:56 PM, Dr. Philipp Tomsich wrote:
> 
>> On 04 Apr 2017, at 21:01, Marek Vasut  wrote:
>>
>>> Good point on the “long”, especially as I just copied this from other 
>>> occurrences and it’s consistently wrong throughout DWC3 in U-Boot:
>>
>> Hrm, I thought the driver was ported over from Linux, so is this broken
>> in Linux too ?
> 
> Apparently, the dwc3_flush_cache calls (and the function itself) have been
> introduced during the porting. There’s no explicit cache-maintenance in DWC3
> for Linux. 

OK

>>> I’ll revise all of these and make a patch-series out of this.
>>
>> Maybe you should check the Linux first and see if there are some fixes
>> already.
>>
>> Thanks
> 
> Given that this seems to have been introduced with the port to U-Boot, there’s
> no applicable fixes there.

OK

>   return evt;
> }
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 1156662..61af71b 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -2668,11 +2668,12 @@ void dwc3_gadget_uboot_handle_interrupt(struct 
> dwc3 *dwc)
>   int i;
>   struct dwc3_event_buffer *evt;
>
> + dwc3_thread_interrupt(0, dwc);
> +
> + /* Clean + Invalidate the buffers after touching them */
>   for (i = 0; i < dwc->num_event_buffers; i++) {
>   evt = dwc->ev_buffs[i];
>   dwc3_flush_cache((long)evt->buf, evt->length);
>   }
> -

 This makes me wonder, don't you need to invalidate the event buffer
 somewhere so that the new data would be fetched from RAM ?
>>>
>>> We flush the event buffer before leaving the function.
>>> So the cache line will not be present in the cache, when we enter this 
>>> function again.
>>
>> Then shouldn't we invalidate it instead ? flush and invalidate are two
>> different things …
> 
> The DWC3 flush expands to a clean+invalidate. It is not wrong, as long as
> it is used as in my patch:
> a. before the first time data is expected to be written by the peripheral 
> (i.e.
> before the peripheral is started)—to ensure that the cache line is not cached
> any longer…

So invalidate() is enough ?

> b. after the driver modifies any buffers (i.e. anything modified will be 
> written
> back) and before it next reads the buffers expecting possibly changed data
> (i.e. invalidating).

So flush+invalidate ? Keep in mind this driver may not be used on
ARMv7/v8 only ...

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

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

[Tom Rini]

On Wed, Mar 29, 2017 at 05:51:04PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> Herewith some fairly minor changes from my patchwork queue.
> 
> 
> The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:
> 
>   Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-dm.git
> 
> for you to fetch changes up to 44d5c371a63e56eb53866b645e75396fa1d95510:
> 
>   Add single register pin controller driver (2017-03-26 13:23:42 -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 3/3] config: am335x_evm: detect BeagleBone Blue using BLA

[Tom Rini]

On Thu, Mar 30, 2017 at 02:29:54PM -0500, Robert Nelson wrote:

> BeagleBone Blue is next grenation of boards from BeagleBoard.org, focusing
> on robotics with a TI wl1835 wireless module for connectivity.
> 
> This board can be indentified by the BLAx value after A335BNLT (BBB)
> in the at24 eeprom:
> BLAx: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 42 4c 41 30 |.U3.A335BNLTBLA2|]
> 
> http://beagleboard.org/blue
> https://github.com/beagleboard/beaglebone-blue
> 
> firmware: 
> https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
> wl18xx mac address: 
> /proc/device-tree/ocp/ethernet@4a10/slave@4a100200/mac-address
> 
> Signed-off-by: Robert Nelson 
> CC: Tom Rini 
> CC: Jason Kridner 
> CC: Will Newton 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/3] config: am335x_evm: detect Green Wireless using GW1

[Tom Rini]

On Thu, Mar 30, 2017 at 02:29:53PM -0500, Robert Nelson wrote:

> SeeedStudio BeagleBone Green Wireless (BBGW) is an expansion of the
> SeeedStudio Green (BBG) with the Ethernet replaced by a TI wl1835
> wireless module.
> 
> This board can be indentified by the GW1x value after A335BNLT (BBB)
> in the at24 eeprom:
> GW1x [aa 55 33 ee 41 33 33 35  42 4e 4c 54 47 57 31 41  |.U3.A335BNLTGW1A|]
> 
> http://beagleboard.org/green-wireless
> http://wiki.seeed.cc/BeagleBone_Green_Wireless/
> 
> firmware: 
> https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
> wl18xx mac address: Stored in at24 eeprom at address 5-16:
> hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom | cut -b 5-16
> 
> Signed-off-by: Robert Nelson 
> CC: Tom Rini 
> CC: Jason Kridner 
> CC: Will Newton 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [GIT PULL] Please pull u-boot-mmc master

[Tom Rini]

On Thu, Mar 30, 2017 at 02:21:39PM +0900, Jaehoon Chung wrote:

> Dear Tom,
> 
> Could pull these patches into u-boot/master?
> 
> The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:
> 
>   Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mmc.git master
> 
> for you to fetch changes up to 17c9a1c121e7d78d820fdb4f7ca070f53e23c29a:
> 
>   mmc: omap_hsmmc: add support for CONFIG_BLK (2017-03-30 14:19:58 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Wed, Mar 29, 2017 at 05:51:04PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> Herewith some fairly minor changes from my patchwork queue.
> 
> 
> The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:
> 
>   Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-dm.git
> 
> for you to fetch changes up to 44d5c371a63e56eb53866b645e75396fa1d95510:
> 
>   Add single register pin controller driver (2017-03-26 13:23:42 -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull ARC changes

[Tom Rini]

On Fri, Mar 31, 2017 at 07:12:18PM +, Alexey Brodkin wrote:

> Hi Tom,
> 
> In this patch-set we add support of new AXS103 firmware as well
> as troubleshoot unexpected execution by multiple cores simultaneously.
> 
> The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:
> 
>   Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arc.git 
> 
> for you to fetch changes up to 6cba327bd96f90818a8beede51405228c54a5251:
> 
>   arcv2: Halt non-master cores (2017-03-31 22:09:36 +0300)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/3] config: am335x_evm: detect Black Wireless using BWA

[Tom Rini]

On Thu, Mar 30, 2017 at 02:29:52PM -0500, Robert Nelson wrote:

> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with
> the Ethernet replaced by a TI wl1835 wireless module.
> 
> This board can be indentified by the BWAx value after A335BNLT (BBB)
> in the at24 eeprom:
> BWAx [aa 55 33 ee 41 33 33 35  42 4e 4c 54 42 57 41 35  |.U3.A335BNLTBWA5|]
> 
> http://beagleboard.org/black-wireless
> https://github.com/beagleboard/beaglebone-black-wireless
> 
> firmware: 
> https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
> wl18xx mac address: 
> /proc/device-tree/ocp/ethernet@4a10/slave@4a100200/mac-address
> 
> Signed-off-by: Robert Nelson 
> CC: Tom Rini 
> CC: Jason Kridner 
> CC: Will Newton 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-marvell/master

[Tom Rini]

On Wed, Mar 29, 2017 at 11:24:23AM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the Marvell mvpp2 patches with the ethernet
> support for the ARMv8 Armada 7k/8k platforms. The
> ethernet patches are all acked by Joe and he is okay with
> me pushing them via the Marvell tree.
> 
> Thanks,
> Stefan
> 
> The following changes since commit 1c694102a56895b7aea636f026955cc5d7ee340d:
> 
>   arc: use timer driver for ARC boards (2017-03-29 07:38:11 +0200)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-marvell.git 
> 
> for you to fetch changes up to 941f7a4b2606ef468f4f3b763261b758eadee861:
> 
>   arm64: mvebu: Enable CONFIG_PHY_MARVELL in Armada7k/8k-DB defconfig 
> (2017-03-29 07:44:50 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-fsl-qoriq master

[Tom Rini]

On Tue, Mar 28, 2017 at 06:02:35PM +, york sun wrote:

> Tom,
> 
> The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:
> 
>Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)
> 
> are available in the git repository at:
> 
>git://git.denx.de/u-boot-fsl-qoriq.git
> 
> for you to fetch changes up to 78be6222b01efa12d9267876ad1d1d0daf38dfa0:
> 
>pcie-layerscape: Fixup iommu-map property of pci node (2017-03-28 
> 10:54:09 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull from u-boot-i2c

[Tom Rini]

On Tue, Mar 28, 2017 at 09:31:54AM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c.git master
> 
> checked this branch on travis, no errors found.
> 
> The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:
> 
>   Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> for you to fetch changes up to e46f8a3309fb2628940d3e2806c954d84f910165:
> 
>   i2c: Set default I2C bus number (2017-03-28 06:27:54 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Pull request: u-boot-net.git master

[Tom Rini]

On Mon, Mar 27, 2017 at 11:50:12AM -0500, Joe Hershberger wrote:

> Hi Tom,
> 
> The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:
> 
>   Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-net.git master
> 
> for you to fetch changes up to db40c1aa1c100d8a9e33206575efd8b3678f31db:
> 
>   drivers/net/phy: add fixed-phy / fixed-link support (2017-03-26 09:58:26 
> -0500)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on event buffers more robust

[Dr. Philipp Tomsich]

> On 04 Apr 2017, at 21:01, Marek Vasut  wrote:
> 
>> Good point on the “long”, especially as I just copied this from other 
>> occurrences and it’s consistently wrong throughout DWC3 in U-Boot:
> 
> Hrm, I thought the driver was ported over from Linux, so is this broken
> in Linux too ?

Apparently, the dwc3_flush_cache calls (and the function itself) have been
introduced during the porting. There’s no explicit cache-maintenance in DWC3
for Linux. 

>> I’ll revise all of these and make a patch-series out of this.
> 
> Maybe you should check the Linux first and see if there are some fixes
> already.
> 
> Thanks

Given that this seems to have been introduced with the port to U-Boot, there’s
no applicable fixes there.

return evt;
 }
 
 diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
 index 1156662..61af71b 100644
 --- a/drivers/usb/dwc3/gadget.c
 +++ b/drivers/usb/dwc3/gadget.c
 @@ -2668,11 +2668,12 @@ void dwc3_gadget_uboot_handle_interrupt(struct 
 dwc3 *dwc)
int i;
struct dwc3_event_buffer *evt;
 
 +  dwc3_thread_interrupt(0, dwc);
 +
 +  /* Clean + Invalidate the buffers after touching them */
for (i = 0; i < dwc->num_event_buffers; i++) {
evt = dwc->ev_buffs[i];
dwc3_flush_cache((long)evt->buf, evt->length);
}
 -
>>> 
>>> This makes me wonder, don't you need to invalidate the event buffer
>>> somewhere so that the new data would be fetched from RAM ?
>> 
>> We flush the event buffer before leaving the function.
>> So the cache line will not be present in the cache, when we enter this 
>> function again.
> 
> Then shouldn't we invalidate it instead ? flush and invalidate are two
> different things …

The DWC3 flush expands to a clean+invalidate. It is not wrong, as long as
it is used as in my patch:
a. before the first time data is expected to be written by the peripheral (i.e.
before the peripheral is started)—to ensure that the cache line is not cached
any longer…
b. after the driver modifies any buffers (i.e. anything modified will be written
back) and before it next reads the buffers expecting possibly changed data
(i.e. invalidating).

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

Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support

[Stefan Agner]

On 2017-04-04 11:38, Marek Vasut wrote:
> On 04/04/2017 07:57 PM, Stefan Agner wrote:
>> On 2017-04-04 02:22, Marek Vasut wrote:
>>> On 04/04/2017 02:02 AM, Stefan Agner wrote:
>>> [...]
>>> Admitedly, I didn't look at the patch, but if you want to boot ad-hoc
>>> cores, you can very well also boot secondary cores on the current CPU
>>> complex with the same command. Why not ?
>>
>> Sure, it could be done. I just feel it is not the right design.
>>
>> Auxiliary cores have usually a different view to memory, this is why I
>> had to add the get_host_mapping callback in the elf loader code to let
>> architecture dependent code translate to host addresses. SMP systems
>> don't need that.
>>
>> Also flush caches is not necessary on some cache coherent CPU's
>> (depending on how your cache coherence between I and D cache looks
>> like).
>
> So SMP is just a reduced special-case of this , yes ?

 Yeah, I guess you can get away with dummy callback implementation and a
 performance hit due to cash flushes.
>>>
>>> Or you can abstract things out ?
>>>
>>
>> There is one callback to arch for translation and one for cache flush,
>> what more can I abstract out?
> 
> Well then I don't think I understand your concerns about cache flushing
> in SMP .
> 

It makes things unnecessary slower.

>> Creating a new command like bootaux comes with very few overhead.
>
> The overhead is the new command, we already have many ad-hoc commands.
>

 Agreed, and I really wished that this got discussed when that command
 initially got added. I brought it up back then...
 https://lists.denx.de/pipermail/u-boot/2016-January/240323.html

 It seemed to be acceptable to just add this ad hoc command, with some
 "random binary format" support back then...
>>>
>>> Based on that discussion, I only see that noone opposed, but I don't see
>>> any agreement.
>>>
>>
>> Maybe I need to word my emails a bit stronger, but with that email I
>> actually tried to oppose:
>> https://lists.denx.de/pipermail/u-boot/2016-January/240989.html
> 
> Well, I do not like adding ad-hoc commands as it's not managable in the
> long run.
> 

I argue that a remote core loading command is _much_ more manageable
than making the bootm command even more complex by support
SMP/remoteproc and whatnot usecases... I would even argue that a bunch
of those commands are more manageable than a single ifdef/if hell

That said, I still would push for keeping the image processing code
generic, whenever it makes sense.

 Ok, it is not entirely
 random, since it is the format of a binary how it ends up in
 microcontrollers execute in place flash (stack pointer and reset vector
 are the two first words)
>>>
>>> I thought this command was starting the core by loading data to RAM ,
>>> not flash ?
>>>
>>
>> Ok, maybe I am a bit unclear here:
>>
>> bootaux currently supports a Cortex-M specific binary format only. The
>> binary format starts with a Cortex-M class vector table. The vector
>> tables first vector is the "reset vector".
>>
>> In a regular microcontroller, that binary gets flashed on a NOR flash
>> which is mapped at 0x0 for the CPU. The CPU has no "boot ROM", the CPU
>> starts by calling the reset vector. So when NXP defined how the bootaux
>> command should look like, they just took that binary format which was
>> laying around and implemented a U-Boot command around it.
>>
>> So this is the history of the binary format. And my point here is, that
>> the binary format supported by bootaux is _very_ Cortex-M class
>> specific.
> 
> Aha, so I now totally don't understand why this command cannot be
> fixed/extended to support other/generic cores or SMP systems etc.
> But looking at the initial proposal, I think maybe the intention of this
> patchset was not to add that support, but to fix the command to
> support loading ELF files ? We already have bootelf for that though ...
> 

Yes, that is pretty much it. I would like to teach that command a more
generic format, which would be at least a step towards something more
generic/standardized.

bootelf is really meant for the primary CPU. That would be an entirely
different direction: Make all common boot commands "aux core" capable.

But I would strongly vote against that. First, those commands have
already complex arguments and argument handling (e.g. bootm), and their
implementation supports use cases which we hardly would ever use on aux
cores (initramfs..).

 However, making this ad hoc command now
 generic really feels weird to me, since we would end up supporting that
 format for A class CPUs etc... bootaux is really suited for auxiliary
 M-class cores on ARM, as it is right now. Maybe we should have named it
 bootm ;-)
>>>
>>> We always try to avoid one-off hacks, so it's not weird. I still don't
>>> quite understand how it is a problem to abstract things out . I 

Re: [U-Boot] __FILE__ usage and and SPL limits for SRAM

[Tom Rini]

On Tue, Mar 28, 2017 at 11:37:45AM +0530, Lokesh Vutla wrote:
> + more folks.
> 
> On Tuesday 28 March 2017 03:14 AM, Nishanth Menon wrote:
> > Hi,
> > 
> > we've kind of run into an interesting situation recently, but might be
> > of interest for various folks trying to reduce the image sizes.
> > 
> > our AM335x device has a limited amount of sram.. and the SPL tries to
> > fit into it (a bit tricky given the restricted space we have on it on
> > certain class of devices).
> > 
> > arch/arm/mach-omap2/am33xx/u-boot-spl.lds is a bit custom tailored
> > around this.
> > 
> > Key in this is:
> > . = ALIGN(4);
> > .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
> > 
> > . = ALIGN(4);
> > .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
> > 
> > 
> > Now, our jenkins build system happens to use a varied build path and
> > uses O= path. to simplify the details:
> > mkdir
> > /tmp//b/cc
> > 
> > mkdir
> > /tmp//b/cc/b
> > 
> > 
> > git clone u-boot
> > cd u-boot
> > 
> > git clean -fdx
> > make CROSS_COMPILE=arm-linux-gnueabihf- O=../b am335x_evm_defconfig
> > make CROSS_COMPILE=arm-linux-gnueabihf- O=../b all
> > 
> > depending on depth of the path, this would fail.. a little bit of
> > headscratching later..
> > when using O= build system uses absolute paths, which translates to
> > __FILE__ being absolute paths as well..
> > 
> > in u-boot, any printf("%s", __FILE__) makes u-boot allocate this file
> > path in rodata.
> > 
> > So, depending on how deep the path is rodata size varies and ends up
> > pushing .data out of sram max range.
> > 
> > we dont really care to put a print of complete absolute path anyways,
> > and I am not really sure of a clean way to resolve this:
> > a) override __FILE__ with something.. -Wbuiltin-macro-redefined kicks in
> > b) replace usage of __FILE__ with something like __FILENAME__ as
> > recommended by [1]
> > 
> > 
> > What is the suggestion we do?
> > 
> > [1] http://stackoverflow.com/questions/8487986/file-macro-shows-full-path
> 
> Any suggestions would be really helpful.

So here's what I've come up with, and it's slightly incomplete:
diff --git a/include/common.h b/include/common.h
index 2cbbd5a60cd3..cdc61ef5b144 100644
--- a/include/common.h
+++ b/include/common.h
@@ -145,20 +145,19 @@ typedef volatile unsigned charvu_char;
  * in any case these failing assertions cannot be fixed with a reset (which
  * may just do the same assertion again).
  */
-void __assert_fail(const char *assertion, const char *file, unsigned line,
-  const char *function);
+void __assert_fail(const char *assertion, unsigned line, const char *function);
 #define assert(x) \
({ if (!(x) && _DEBUG) \
-   __assert_fail(#x, __FILE__, __LINE__, __func__); })
+   __assert_fail(#x, __LINE__, __func__); })
 
 #define error(fmt, args...) do {   \
-   printf("ERROR: " pr_fmt(fmt) "\nat %s:%d/%s()\n",   \
-   ##args, __FILE__, __LINE__, __func__);  \
+   printf("ERROR: " pr_fmt(fmt) "\nat %s():%d\n",  \
+   ##args, __func__, __LINE__);\
 } while (0)
 
 #ifndef BUG
 #define BUG() do { \
-   printf("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, 
__FUNCTION__); \
+   printf("BUG: failure at %s():%d!\n", __FUNCTION__, __LINE__); \
panic("BUG!"); \
 } while (0)
 #define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); } while(0)
diff --git a/include/image.h b/include/image.h
index 237251896029..a52c5355376e 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1218,12 +1218,12 @@ static inline int fit_image_check_target_arch(const 
void *fdt, int node)
 #ifdef CONFIG_FIT_VERBOSE
 #define fit_unsupported(msg)   printf("! %s:%d " \
"FIT images not supported for '%s'\n", \
-   __FILE__, __LINE__, (msg))
+   __func__, __LINE__, (msg))
 
 #define fit_unsupported_reset(msg) printf("! %s:%d " \
"FIT images not supported for '%s' " \
"- must reset board to recover!\n", \
-   __FILE__, __LINE__, (msg))
+   __func__, __LINE__, (msg))
 #else
 #define fit_unsupported(msg)
 #define fit_unsupported_reset(msg)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index a43e4d66983d..db9fcb6d47c2 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -100,14 

Re: [U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on event buffers more robust

[Marek Vasut]

On 04/04/2017 07:46 PM, Dr. Philipp Tomsich wrote:
> 
>> On 04 Apr 2017, at 18:15, Marek Vasut  wrote:
>>
>> On 04/03/2017 07:49 PM, Philipp Tomsich wrote:
>>> Merely using dma_alloc_coherent does not ensure that there is no stale
>>> data left in the caches for the allocated DMA buffer (i.e. that the
>>> affected cacheline may still be dirty).
>>>
>>> The original code was doing the following (on AArch64, which
>>> translates a 'flush' into a 'clean + invalidate'):
>>>  # during initialisation:
>>>  1. allocate buffers via memalign
>>>  => buffers may still be modified (cached, dirty)
>>>  # during interrupt processing
>>>  2. clean + invalidate buffers
>>>  => may commit stale data from a modified cacheline
>>>  3. read from buffers
>>>
>>> This could lead to garbage info being written to buffers before
>>> reading them during even-processing.
>>>
>>> To make the event processing more robust, we use the following sequence
>>> for the cache-maintenance:
>>>  # during initialisation:
>>>  1. allocate buffers via memalign
>>>  2. clean + invalidate buffers
>>>  (we only need the 'invalidate' part, but dwc3_flush_cache()
>>>   always performs a 'clean + invalidate')
>>>  # during interrupt processing
>>>  3. read the buffers
>>>  (we know these lines are not cached, due to the previous
>>>   invalidation and no other code touching them in-between)
>>>  4. clean + invalidate buffers
>>>  => writes back any modification we may have made during event
>>> processing and ensures that the lines are not in the cache
>>> the next time we enter interrupt processing
>>>
>>> Note that with the original sequence, we observe reproducible
>>> (depending on the cache state: i.e. running dhcp/usb start before will
>>> upset caches to get us around this) issues in the event processing (a
>>> fatal synchronous abort in dwc3_gadget_uboot_handle_interrupt on the
>>> first time interrupt handling is invoked) when running USB mass
>>> storage emulation on our RK3399-Q7 with data-caches on.
>>>
>>> Signed-off-by: Philipp Tomsich 
>>>
>>> ---
>>>
>>> drivers/usb/dwc3/core.c   | 2 ++
>>> drivers/usb/dwc3/gadget.c | 5 +++--
>>> 2 files changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index b2c7eb1..f58c7ba 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -125,6 +125,8 @@ static struct dwc3_event_buffer 
>>> *dwc3_alloc_one_event_buffer(struct dwc3 *dwc,
>>> if (!evt->buf)
>>> return ERR_PTR(-ENOMEM);
>>>
>>> +   dwc3_flush_cache((long)evt->buf, evt->length);
>>> +
>>
>> Is the length aligned ? If not, you will get cache alignment warning.
>> Also, address should be uintptr_t to avoid 32/64 bit issues .
> 
> The length is a well-known value and aligned (it expands to PAGE_SIZE in the 
> end).

Uh, the event buffer is 4k ? That's quite big, but OK.

> Good point on the “long”, especially as I just copied this from other 
> occurences and it’s consistently wrong throughout DWC3 in U-Boot:

Hrm, I thought the driver was ported over from Linux, so is this broken
in Linux too ?

>   drivers/usb/dwc3/core.c:dwc3_flush_cache((long)evt->buf, 
> evt->length);
>   drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)buf_dma, len);
>   drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)trb, sizeof(*trb));
>   drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)trb, sizeof(*trb));
>   drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)trb, 
> sizeof(*trb));
>   drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)dwc->ep0_bounce, 
> DWC3_EP0_BOUNCE_SIZE);
>   drivers/usb/dwc3/gadget.c:  
> dwc3_flush_cache((long)req->request.dma, req->request.length);
>   drivers/usb/dwc3/gadget.c:  dwc3_flush_cache((long)dma, length);
>   drivers/usb/dwc3/gadget.c:  dwc3_flush_cache((long)trb, 
> sizeof(*trb));
>   drivers/usb/dwc3/gadget.c:  dwc3_flush_cache((long)trb, 
> sizeof(*trb));
>   drivers/usb/dwc3/gadget.c:  
> dwc3_flush_cache((long)evt->buf, evt->length);
>   drivers/usb/dwc3/io.h:static inline void dwc3_flush_cache(int addr, int 
> length)
> 
> Worst of all: the definition of dwc3_flush_cache in io.h has “int” as a type, 
> which will eat us alive if the DWC3’s physical address is beyond 32-bit.
> 
> I’ll revise all of these and make a patch-series out of this.

Maybe you should check the Linux first and see if there are some fixes
already.

Thanks

>>> return evt;
>>> }
>>>
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 1156662..61af71b 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -2668,11 +2668,12 @@ void dwc3_gadget_uboot_handle_interrupt(struct dwc3 
>>> *dwc)
>>> int i;
>>> 

[U-Boot] [PATCH] dm: core: Ensure DMA regions start up with the cache clean

[Simon Glass]

There is a strange interaction with drivers which use DMA if the cache
starts off in a dirty state. Buffer space which the driver reads (but has
not previously written) can contain zero bytes from alloc_priv(). This can
cause corruption of the memory used by DMA for incoming data.

Fix this and add a comment to explain the problem.

This allows the dwc2 driver to work correctly with driver model, for
example.

Signed-off-by: Simon Glass 
---

 drivers/core/device.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 70fcfc23e0..8c9f5293d0 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -255,8 +255,36 @@ static void *alloc_priv(int size, uint flags)
 
if (flags & DM_FLAG_ALLOC_PRIV_DMA) {
priv = memalign(ARCH_DMA_MINALIGN, size);
-   if (priv)
+   if (priv) {
memset(priv, '\0', size);
+
+   /*
+* Ensure that the zero bytes are flushed to memory.
+* This prevents problems if the driver uses this as
+* both an input and an output buffer:
+*
+* 1. Zeroes written to buffer (here) and sit in the
+*  cache
+* 2. Driver issues a read command to DMA
+* 3. CPU runs out of cache space and evicts some cache
+*  data in the buffer, writing zeroes to RAM from
+*  the memset() above
+* 4. DMA completes
+* 5. Buffer now has some DMA data and some zeroes
+* 6. Data being read is now incorrect
+*
+* To prevent this, ensure that the cache is clean
+* within this range at the start. The driver can then
+* use normal flush-after-write, invalidate-before-read
+* procedures.
+*
+* TODO(s...@chromium.org): Drop this microblaze
+* exception.
+*/
+#ifndef CONFIG_MICROBLAZE
+   flush_dcache_range((ulong)priv, (ulong)priv + size);
+#endif
+   }
} else {
priv = calloc(1, size);
}
-- 
2.12.2.715.g7642488e1d-goog

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

Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support

[Stefan Agner]

On 2017-04-04 01:23, Lukasz Majewski wrote:
> Hi Stefan,
> 
>> Hi Lukasz,
>>
>> On 2017-04-03 04:20, Lukasz Majewski wrote:
>> > Hi Stefan,
>> >
>> > Thanks for your patch. Please allow me to share some ideas for
>> > improvements.
>> >
>> >> From: Stefan Agner 
>> >>
>> >> This patchset enables to boot elf binaries on secondary Cortex-M
>> >> class cores available on i.MX 6SoloX/7Solo/7Dual. This makes
>> >> handling and loading firmwares much more convinient since all
>> >> information where the firmware has to be loaded to is contained in
>> >> the elf headers. A typical usage looks like this:
>> >>
>> >>   Colibri iMX7 # tftp ${loadaddr} firmware.elf && bootaux
>> >> ${loadaddr} Using FEC0 device
>> >>   TFTP from server 192.168.10.1; our IP address is 192.168.10.2
>> >>   Filename 'firmware.elf'.
>> >>   Load address: 0x8080
>> >>   Loading: ##  88.3
>> >> KiB 5.4 MiB/s
>> >>   done
>> >>   Bytes transferred = 90424 (16138 hex)
>> >>   ## Starting auxiliary core at 0x1FFF8311 ...
>> >>   Colibri iMX7 #
>> >
>> > I can find some other platforms (not only IMX), which would benefit
>> > from this code - the generic 'bootaux' command.
>> >
>> > One good example would to allow multiple binaries for different SoC
>> > Cores (e.g. 2x Cortex-A8) to be loaded and started by u-boot.
>> >
>> > Hence, I'm wondering if you could make those patches usable for
>> > other platforms as well?
>>
>> I don't think that this is a good idea. bootaux is meant for auxiliary
>> cores, which often use a different architecture and are not cache
>> coherent (hence the cache flushes).
> 
> I do remember, that I saw similar "tiny" patch to add "just one" ad-hoc
> command to do the same (conceptually) for TI SoC floating on the u-boot
> mailing list.
> 
> Please correct me if I'm wrong, but bootaux is IMX specific and does
> work, which very likely, will be also required by other SoC vendors
> (TI's Sitara is also equipped with Cortex-M4 and PRUSS).

bootaux is currently IMX specific, and its currently supported binary
format is M-class specific.

> 
> Unification of such effort can save us all a lot of trouble in a very
> near future.

In OSS, you do not develop for the future. It gets developed when its
here.

> 
>>
>> On SMP systems the main operating system normally starts the secondary
>> core.
> 
> I think that there are some conceptual similarities between loading code
> to SMP core and Cortex M3. Of course some "tweaks" would be needed.
>

There are conceptual similarities between a car and a truck, still, they
are likely manufactured in a different assembly line, probably by a
different producer.

I guess in the end it really depends on where you draw the line: There
are differences between loading code which will get executed by the
primary code, loading code to execute explicitly on a SMP core, and
loading code to execute on a remote processor.

The first case is already well supported, and we need to keep support
backward compatibility.

The second case, IMHO, is a somewhat silly case: A SMP system usually
gets driven by a single OS image, and that OS makes sure to initialize
the cores (maybe with the help of firmware, such as the PSCI interface
on ARM). There is no need for a boot loader command to execute a image
on a secondary core explicitly...

The third case is probably a case where we could start think about
unification efforts.


>> Otherwise, if you want to run them separately using U-Boot,
>> maybe a new command such as bootsmp would be more suited.
> 
> Hmm - I do think that it would be too much:
> 
> - bootm for generic single core
> - bootaux for IMX
> - bootsmp for SMP (on IMX/TI/RK?)
> - boot?? for ??

There is at least also bootz and bootelf.

> 
> I would like to avoid adding new commands for doing conceptually the
> same work.
> 
> Even better, we could extend bootm to support the "multi binary" case
> too, but IMHO it would be also correct to have "bootaux" to handle
> generic binaries loading.
> 
>>
>> >
>> >>
>> >> Note that the bootaux command retrieved the entry point (PC) from
>> >> the elf binary.
>> >
>> > Could you make this code flexible enough to handle not only elf
>> > binaries, but also other data (e.g. FPGA bitstreams)?
>>
>> The code of bootaux is rather small, I don't see much value into stuff
>> boot code for other peripherals into it.
> 
> But I'm not asking to write support for other vendor's SoC/use cases.
> 
> I'm just wondering if you could write generic command (framework) to
> support this use case and as an example add support for your IMX's
> Cortex-M3/4.
> 

Sure, mv arch/arm/imx-common/imx_bootaux.c cmd/, there is the framework
:-)

But this promotes the M class specific binary format to a generic format
supported for all cores.

> We would kill two birds with one stone - IMX is supported from the very
> beginning and we do have generic code to extend it by other vendors.
> 
>> I don't know how 

Re: [U-Boot] [PATCH] libfdt: fix build with Python 3

[Stefan Agner]

On 2017-04-04 01:53, Stefano Babic wrote:
> Hi Stefan,
> 
> On 03/04/2017 23:02, Stefan Agner wrote:
> 
>> But then, I don't expect that "/usr/bin/env python" is looking at
>> PYTHON.
>>
>> As far as I understand env, it just looks up the current environment to
>> run its COMMAND argument.
> 
> Agree, this is also mz understanding.
> 
>> It is helpful as a shebang, but it does not
>> seem to make any difference to calling "python" directly (since that
>> also just looks up the current environment PATH and executes the first
>> python it finds...
> 
> Agree - so that is disturbing is the fix calls to "python" inside
> Makefile. That means it remains to change:
> 
> tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c
>   LDFLAGS="$(HOSTLDFLAGS)" CFLAGS= python $(srctree)/lib/libfdt/setup.py
> 
> to:
> 
> tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c
>   LDFLAGS="$(HOSTLDFLAGS)" CFLAGS= ${PYTHON} 
> $(srctree)/lib/libfdt/setup.py
> 

On my host

$ echo Python is \"$PYTHON\"
Python is ""

Wouldn't that break regular builds? Probably wouldn't since shebang
kicks in, but is that really what we want?

What I thought OE was doing is adding the native/x86_64 sysroots in your
path at the beginning, which should already make sure that a regular
"python" call executes OE python... But maybe there is more to it,
especially since setup.py even compiles things...

Maybe we need to peek into distutils/setuptools class to understand how
that works for regular Python modules:
https://github.com/openembedded/openembedded/blob/master/classes/setuptools.bbclass
https://github.com/openembedded/openembedded/blob/master/classes/distutils.bbclass

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

Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support

[Marek Vasut]

On 04/04/2017 07:57 PM, Stefan Agner wrote:
> On 2017-04-04 02:22, Marek Vasut wrote:
>> On 04/04/2017 02:02 AM, Stefan Agner wrote:
>> [...]
>> Admitedly, I didn't look at the patch, but if you want to boot ad-hoc
>> cores, you can very well also boot secondary cores on the current CPU
>> complex with the same command. Why not ?
>
> Sure, it could be done. I just feel it is not the right design.
>
> Auxiliary cores have usually a different view to memory, this is why I
> had to add the get_host_mapping callback in the elf loader code to let
> architecture dependent code translate to host addresses. SMP systems
> don't need that.
>
> Also flush caches is not necessary on some cache coherent CPU's
> (depending on how your cache coherence between I and D cache looks
> like).

 So SMP is just a reduced special-case of this , yes ?
>>>
>>> Yeah, I guess you can get away with dummy callback implementation and a
>>> performance hit due to cash flushes.
>>
>> Or you can abstract things out ?
>>
> 
> There is one callback to arch for translation and one for cache flush,
> what more can I abstract out?

Well then I don't think I understand your concerns about cache flushing
in SMP .

> Creating a new command like bootaux comes with very few overhead.

 The overhead is the new command, we already have many ad-hoc commands.

>>>
>>> Agreed, and I really wished that this got discussed when that command
>>> initially got added. I brought it up back then...
>>> https://lists.denx.de/pipermail/u-boot/2016-January/240323.html
>>>
>>> It seemed to be acceptable to just add this ad hoc command, with some
>>> "random binary format" support back then...
>>
>> Based on that discussion, I only see that noone opposed, but I don't see
>> any agreement.
>>
> 
> Maybe I need to word my emails a bit stronger, but with that email I
> actually tried to oppose:
> https://lists.denx.de/pipermail/u-boot/2016-January/240989.html

Well, I do not like adding ad-hoc commands as it's not managable in the
long run.

>>> Ok, it is not entirely
>>> random, since it is the format of a binary how it ends up in
>>> microcontrollers execute in place flash (stack pointer and reset vector
>>> are the two first words)
>>
>> I thought this command was starting the core by loading data to RAM ,
>> not flash ?
>>
> 
> Ok, maybe I am a bit unclear here:
> 
> bootaux currently supports a Cortex-M specific binary format only. The
> binary format starts with a Cortex-M class vector table. The vector
> tables first vector is the "reset vector".
> 
> In a regular microcontroller, that binary gets flashed on a NOR flash
> which is mapped at 0x0 for the CPU. The CPU has no "boot ROM", the CPU
> starts by calling the reset vector. So when NXP defined how the bootaux
> command should look like, they just took that binary format which was
> laying around and implemented a U-Boot command around it.
> 
> So this is the history of the binary format. And my point here is, that
> the binary format supported by bootaux is _very_ Cortex-M class
> specific.

Aha, so I now totally don't understand why this command cannot be
fixed/extended to support other/generic cores or SMP systems etc.
But looking at the initial proposal, I think maybe the intention of this
patchset was not to add that support, but to fix the command to
support loading ELF files ? We already have bootelf for that though ...

>>> However, making this ad hoc command now
>>> generic really feels weird to me, since we would end up supporting that
>>> format for A class CPUs etc... bootaux is really suited for auxiliary
>>> M-class cores on ARM, as it is right now. Maybe we should have named it
>>> bootm ;-)
>>
>> We always try to avoid one-off hacks, so it's not weird. I still don't
>> quite understand how it is a problem to abstract things out . I am not
>> asking you to support CA, but to avoid CM specific implementation which
>> cannot be extended to support CA or even MIPS/Nios2/etc .
>>
> 
> Again, why would you support a Cortex-M class specific file format for
> MIPS/Nios2 etc...?
> 
> bootaux is M4 specific. We can through it away, and start over, but then
> we should call the command differently.

Unless you look very carefully, it is not clear that it is cortex M4
specific at all based on this discussion. I was under the impression
that the goal here was to support all sorts of secondary cores ...

> This are the reasons why I feel creating a new command for a SMP boot
> case makes more sense. We can still reuse functions which are very
> similar by moving them into some common location, where it makes sense.
>
>>
>> Also, I think this might come useful when booting stuff like "Altera
>> Sparrow" ...
>
> I am not familiar with that architecture, what kind of core does it
> provide which needs to be booted by U-Boot?

 The secondary ARM core in the SoCFPGA C-A9 complex 

Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support

[Stefan Agner]

On 2017-04-04 02:22, Marek Vasut wrote:
> On 04/04/2017 02:02 AM, Stefan Agner wrote:
> [...]
> Admitedly, I didn't look at the patch, but if you want to boot ad-hoc
> cores, you can very well also boot secondary cores on the current CPU
> complex with the same command. Why not ?

 Sure, it could be done. I just feel it is not the right design.

 Auxiliary cores have usually a different view to memory, this is why I
 had to add the get_host_mapping callback in the elf loader code to let
 architecture dependent code translate to host addresses. SMP systems
 don't need that.

 Also flush caches is not necessary on some cache coherent CPU's
 (depending on how your cache coherence between I and D cache looks
 like).
>>>
>>> So SMP is just a reduced special-case of this , yes ?
>>
>> Yeah, I guess you can get away with dummy callback implementation and a
>> performance hit due to cash flushes.
> 
> Or you can abstract things out ?
> 

There is one callback to arch for translation and one for cache flush,
what more can I abstract out?

 Creating a new command like bootaux comes with very few overhead.
>>>
>>> The overhead is the new command, we already have many ad-hoc commands.
>>>
>>
>> Agreed, and I really wished that this got discussed when that command
>> initially got added. I brought it up back then...
>> https://lists.denx.de/pipermail/u-boot/2016-January/240323.html
>>
>> It seemed to be acceptable to just add this ad hoc command, with some
>> "random binary format" support back then...
> 
> Based on that discussion, I only see that noone opposed, but I don't see
> any agreement.
> 

Maybe I need to word my emails a bit stronger, but with that email I
actually tried to oppose:
https://lists.denx.de/pipermail/u-boot/2016-January/240989.html

>> Ok, it is not entirely
>> random, since it is the format of a binary how it ends up in
>> microcontrollers execute in place flash (stack pointer and reset vector
>> are the two first words)
> 
> I thought this command was starting the core by loading data to RAM ,
> not flash ?
> 

Ok, maybe I am a bit unclear here:

bootaux currently supports a Cortex-M specific binary format only. The
binary format starts with a Cortex-M class vector table. The vector
tables first vector is the "reset vector".

In a regular microcontroller, that binary gets flashed on a NOR flash
which is mapped at 0x0 for the CPU. The CPU has no "boot ROM", the CPU
starts by calling the reset vector. So when NXP defined how the bootaux
command should look like, they just took that binary format which was
laying around and implemented a U-Boot command around it.

So this is the history of the binary format. And my point here is, that
the binary format supported by bootaux is _very_ Cortex-M class
specific.



>> However, making this ad hoc command now
>> generic really feels weird to me, since we would end up supporting that
>> format for A class CPUs etc... bootaux is really suited for auxiliary
>> M-class cores on ARM, as it is right now. Maybe we should have named it
>> bootm ;-)
> 
> We always try to avoid one-off hacks, so it's not weird. I still don't
> quite understand how it is a problem to abstract things out . I am not
> asking you to support CA, but to avoid CM specific implementation which
> cannot be extended to support CA or even MIPS/Nios2/etc .
> 

Again, why would you support a Cortex-M class specific file format for
MIPS/Nios2 etc...?

bootaux is M4 specific. We can through it away, and start over, but then
we should call the command differently.


 This are the reasons why I feel creating a new command for a SMP boot
 case makes more sense. We can still reuse functions which are very
 similar by moving them into some common location, where it makes sense.

>
> Also, I think this might come useful when booting stuff like "Altera
> Sparrow" ...

 I am not familiar with that architecture, what kind of core does it
 provide which needs to be booted by U-Boot?
>>>
>>> The secondary ARM core in the SoCFPGA C-A9 complex or Nios2 core in the
>>> FPGA.
>>
>> In my thinking, the Nios2 core seems like such a remote processor well
>> suited for the bootaux command. For the secondary A9, I would create a
>> new command.
> 
> Uh, why, that does not make any sense to me. Both the random core in
> FPGA and the secondary CA9 core have almost the same bringup sequence.
> What is so different about this stuff ?
> 

A cache coherent core and a non-cache coherent core remote core
somewhere in the SoC is very much different IMHO.

Lets compare how you bring up a A class CPU, or cache coherent SMP style
CPU in general:

1. Load code into RAM
2. Some cache flushing might be necessary due to I/D-cache incoherency
3. Write entry point into some architecture specific register
4. kick off the CPU by writing another architecture specific register

M class/remote CPU

1. Load code in RAM, depending on 

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

[Tom Warren]

Tom,

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

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

The following changes since commit 5cf618ee60a752d058a767372ca1ecb8d9c09b16:

  Merge git://git.denx.de/u-boot-arc (2017-03-24 08:19:30 -0400)

are available in the git repository at:

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

for you to fetch changes up to ee92194acd3b2b8a6b2a096ec9588e9a7f326e95:

  apalis-tk1: disable external clock loopback on SDMMC3 (2017-04-01
15:45:04 -0700)


Marcel Ziswiler (3):
  arm: tegra: initial support for apalis tk1
  mmc: tegra: allow disabling external clock loopback
  apalis-tk1: disable external clock loopback on SDMMC3

 arch/arm/dts/Makefile  |1 +
 arch/arm/dts/tegra124-apalis.dts   | 2203

 arch/arm/include/asm/arch-tegra/tegra_mmc.h|2 +
 arch/arm/mach-tegra/tegra124/Kconfig   |7 +
 board/toradex/apalis-tk1/Kconfig   |   30 +
 board/toradex/apalis-tk1/MAINTAINERS   |7 +
 board/toradex/apalis-tk1/Makefile  |5 +
 board/toradex/apalis-tk1/apalis-tk1.c  |  175 ++
 board/toradex/apalis-tk1/as3722_init.c |  117 ++
 board/toradex/apalis-tk1/as3722_init.h |   41 +
 .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h  |  287 +++
 configs/apalis-tk1_defconfig   |   47 +
 drivers/mmc/Kconfig|   11 +
 drivers/mmc/tegra_mmc.c|   16 +
 include/configs/apalis-tk1.h   |  176 ++
 15 files changed, 3125 insertions(+)
 create mode 100644 arch/arm/dts/tegra124-apalis.dts
 create mode 100644 board/toradex/apalis-tk1/Kconfig
 create mode 100644 board/toradex/apalis-tk1/MAINTAINERS
 create mode 100644 board/toradex/apalis-tk1/Makefile
 create mode 100644 board/toradex/apalis-tk1/apalis-tk1.c
 create mode 100644 board/toradex/apalis-tk1/as3722_init.c
 create mode 100644 board/toradex/apalis-tk1/as3722_init.h
 create mode 100644 board/toradex/apalis-tk1/pinmux-config-apalis-tk1.h
 create mode 100644 configs/apalis-tk1_defconfig
 create mode 100644 include/configs/apalis-tk1.h
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv2] net: zynq_gem: Do not return -ENOSYS on success

[Joe Hershberger]

On Mon, Apr 3, 2017 at 9:18 AM, Olliver Schinagl  wrote:
>
> The .read_rom_hwaddr net_ops hook does not check the return value, which
> is why it was never caught that we are currently returning 0 if the
> read_rom_hwaddr function return -ENOSYS and -ENOSYS otherwise.
>
> In this case we can simplify this by just returning the result of the
> function.
>
> Signed-off-by: Olliver Schinagl 

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

Re: [U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on event buffers more robust

[Dr. Philipp Tomsich]

> On 04 Apr 2017, at 18:15, Marek Vasut  wrote:
> 
> On 04/03/2017 07:49 PM, Philipp Tomsich wrote:
>> Merely using dma_alloc_coherent does not ensure that there is no stale
>> data left in the caches for the allocated DMA buffer (i.e. that the
>> affected cacheline may still be dirty).
>> 
>> The original code was doing the following (on AArch64, which
>> translates a 'flush' into a 'clean + invalidate'):
>>  # during initialisation:
>>  1. allocate buffers via memalign
>>   => buffers may still be modified (cached, dirty)
>>  # during interrupt processing
>>  2. clean + invalidate buffers
>>   => may commit stale data from a modified cacheline
>>  3. read from buffers
>> 
>> This could lead to garbage info being written to buffers before
>> reading them during even-processing.
>> 
>> To make the event processing more robust, we use the following sequence
>> for the cache-maintenance:
>>  # during initialisation:
>>  1. allocate buffers via memalign
>>  2. clean + invalidate buffers
>>   (we only need the 'invalidate' part, but dwc3_flush_cache()
>>always performs a 'clean + invalidate')
>>  # during interrupt processing
>>  3. read the buffers
>>   (we know these lines are not cached, due to the previous
>>invalidation and no other code touching them in-between)
>>  4. clean + invalidate buffers
>>   => writes back any modification we may have made during event
>>  processing and ensures that the lines are not in the cache
>>  the next time we enter interrupt processing
>> 
>> Note that with the original sequence, we observe reproducible
>> (depending on the cache state: i.e. running dhcp/usb start before will
>> upset caches to get us around this) issues in the event processing (a
>> fatal synchronous abort in dwc3_gadget_uboot_handle_interrupt on the
>> first time interrupt handling is invoked) when running USB mass
>> storage emulation on our RK3399-Q7 with data-caches on.
>> 
>> Signed-off-by: Philipp Tomsich 
>> 
>> ---
>> 
>> drivers/usb/dwc3/core.c   | 2 ++
>> drivers/usb/dwc3/gadget.c | 5 +++--
>> 2 files changed, 5 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index b2c7eb1..f58c7ba 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -125,6 +125,8 @@ static struct dwc3_event_buffer 
>> *dwc3_alloc_one_event_buffer(struct dwc3 *dwc,
>>  if (!evt->buf)
>>  return ERR_PTR(-ENOMEM);
>> 
>> +dwc3_flush_cache((long)evt->buf, evt->length);
>> +
> 
> Is the length aligned ? If not, you will get cache alignment warning.
> Also, address should be uintptr_t to avoid 32/64 bit issues .

The length is a well-known value and aligned (it expands to PAGE_SIZE in the 
end).
Good point on the “long”, especially as I just copied this from other 
occurences and it’s consistently wrong throughout DWC3 in U-Boot:
drivers/usb/dwc3/core.c:dwc3_flush_cache((long)evt->buf, 
evt->length);
drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)buf_dma, len);
drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)trb, sizeof(*trb));
drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)trb, sizeof(*trb));
drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)trb, 
sizeof(*trb));
drivers/usb/dwc3/ep0.c: dwc3_flush_cache((long)dwc->ep0_bounce, 
DWC3_EP0_BOUNCE_SIZE);
drivers/usb/dwc3/gadget.c:  
dwc3_flush_cache((long)req->request.dma, req->request.length);
drivers/usb/dwc3/gadget.c:  dwc3_flush_cache((long)dma, length);
drivers/usb/dwc3/gadget.c:  dwc3_flush_cache((long)trb, 
sizeof(*trb));
drivers/usb/dwc3/gadget.c:  dwc3_flush_cache((long)trb, 
sizeof(*trb));
drivers/usb/dwc3/gadget.c:  
dwc3_flush_cache((long)evt->buf, evt->length);
drivers/usb/dwc3/io.h:static inline void dwc3_flush_cache(int addr, int 
length)

Worst of all: the definition of dwc3_flush_cache in io.h has “int” as a type, 
which will eat us alive if the DWC3’s physical address is beyond 32-bit.

I’ll revise all of these and make a patch-series out of this.

>>  return evt;
>> }
>> 
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 1156662..61af71b 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -2668,11 +2668,12 @@ void dwc3_gadget_uboot_handle_interrupt(struct dwc3 
>> *dwc)
>>  int i;
>>  struct dwc3_event_buffer *evt;
>> 
>> +dwc3_thread_interrupt(0, dwc);
>> +
>> +/* Clean + Invalidate the buffers after touching them */
>>  for (i = 0; i < dwc->num_event_buffers; i++) {
>>  evt = dwc->ev_buffs[i];
>>  dwc3_flush_cache((long)evt->buf, evt->length);
>>  }
>> -
> 
> This 

[U-Boot] [PATCH] core/uclass: Print name of device in uclass_find_device_by_seq()

[Alexandru Gagniuc]

uclass_find_device_by_seq() prints seq and req_seq when debugging is
enabled, but this information is not very useful by itself. Add the
name of he driver to this information. This improves debugging as it
shows which devices are being considered.

Signed-off-by: Alexandru Gagniuc 
---
 drivers/core/uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index 7de3706..fa62800 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -250,7 +250,7 @@ int uclass_find_device_by_seq(enum uclass_id id, int 
seq_or_req_seq,
return ret;
 
list_for_each_entry(dev, >dev_head, uclass_node) {
-   debug("   - %d %d\n", dev->req_seq, dev->seq);
+   debug("   - %d %d '%s'\n", dev->req_seq, dev->seq, dev->name);
if ((find_req_seq ? dev->req_seq : dev->seq) ==
seq_or_req_seq) {
*devp = dev;
-- 
2.9.3

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

[U-Boot] [PATCH 2/2] common/xyzModem.c: Do not use hard-coded address for debug buffer

[Alexandru Gagniuc]

Under the plethora of #ifdefs, the xyzModem code hid this pearl:
static char *zm_out = (char *) 0x0038;
This was only enabled when DEBUG is defined, so it's probably why it
went unnoticed for so long. No idea what platform had memory at that
exact location, but the this approach is extremely hacky.
Use a static buffer instead.

Signed-off-by: Alexandru Gagniuc 
---
 common/xyzModem.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/common/xyzModem.c b/common/xyzModem.c
index 6ded958..a0c5dfe 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -176,16 +176,10 @@ parse_num (char *s, unsigned long *val, char **es, char 
*delim)
 /*
  * Note: this debug setup works by storing the strings in a fixed buffer
  */
-#define FINAL
-#ifdef FINAL
-static char *zm_out = (char *) 0x0038;
-static char *zm_out_start = (char *) 0x0038;
-#else
-static char zm_buf[8192];
-static char *zm_out = zm_buf;
-static char *zm_out_start = zm_buf;
+static char zm_debug_buf[8192];
+static char *zm_out = zm_debug_buf;
+static char *zm_out_start = zm_debug_buf;
 
-#endif
 static int
 zm_dprintf (char *fmt, ...)
 {
-- 
2.9.3

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

[U-Boot] [PATCH 1/2] common/xyzModem.c: unifdef (Remove useless #ifdefs)

[Alexandru Gagniuc]

Signed-off-by: Alexandru Gagniuc 
---
 common/xyzModem.c  | 103 -
 include/xyzModem.h |   7 
 2 files changed, 110 deletions(-)

diff --git a/common/xyzModem.c b/common/xyzModem.c
index e0d87db..6ded958 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -39,25 +39,17 @@
 #define CAN 0x18
 #define EOF 0x1A   /* ^Z for DOS officionados */
 
-#define USE_YMODEM_LENGTH
-
 /* Data & state local to the protocol */
 static struct
 {
-#ifdef REDBOOT
-  hal_virtual_comm_table_t *__chan;
-#else
   int *__chan;
-#endif
   unsigned char pkt[1024], *bufp;
   unsigned char blk, cblk, crc1, crc2;
   unsigned char next_blk;  /* Expected block */
   int len, mode, total_retries;
   int total_SOH, total_STX, total_CAN;
   bool crc_mode, at_eof, tx_ack;
-#ifdef USE_YMODEM_LENGTH
   unsigned long file_length, read_length;
-#endif
 } xyz;
 
 #define xyzModem_CHAR_TIMEOUT2000  /* 2 seconds */
@@ -66,7 +58,6 @@ static struct
 #define xyzModem_CAN_COUNT3/* Wait for 3 CAN before 
quitting */
 
 
-#ifndef REDBOOT/*SB */
 typedef int cyg_int32;
 static int
 CYGACC_COMM_IF_GETC_TIMEOUT (char chan, char *c)
@@ -156,17 +147,7 @@ parse_num (char *s, unsigned long *val, char **es, char 
*delim)
   if (_is_hex (c) && ((digit = _from_hex (c)) < radix))
{
  /* Valid digit */
-#ifdef CYGPKG_HAL_MIPS
- /* FIXME: tx49 compiler generates 0x2539018 for MUL which */
- /* isn't any good. */
- if (16 == radix)
-   result = result << 4;
- else
-   result = 10 * result;
- result += digit;
-#else
  result = (result * radix) + digit;
-#endif
}
   else
{
@@ -190,41 +171,8 @@ parse_num (char *s, unsigned long *val, char **es, char 
*delim)
   return true;
 }
 
-#endif
 
-#define USE_SPRINTF
 #ifdef DEBUG
-#ifndef USE_SPRINTF
-/*
- * Note: this debug setup only works if the target platform has two serial 
ports
- * available so that the other one (currently only port 1) can be used for 
debug
- * messages.
- */
-static int
-zm_dprintf (char *fmt, ...)
-{
-  int cur_console;
-  va_list args;
-
-  va_start (args, fmt);
-#ifdef REDBOOT
-  cur_console =
-CYGACC_CALL_IF_SET_CONSOLE_COMM
-(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);
-  CYGACC_CALL_IF_SET_CONSOLE_COMM (1);
-#endif
-  diag_vprintf (fmt, args);
-#ifdef REDBOOT
-  CYGACC_CALL_IF_SET_CONSOLE_COMM (cur_console);
-#endif
-}
-
-static void
-zm_flush (void)
-{
-}
-
-#else
 /*
  * Note: this debug setup works by storing the strings in a fixed buffer
  */
@@ -253,23 +201,13 @@ zm_dprintf (char *fmt, ...)
 static void
 zm_flush (void)
 {
-#ifdef REDBOOT
-  char *p = zm_out_start;
-  while (*p)
-mon_write_char (*p++);
-#endif
   zm_out = zm_out_start;
 }
-#endif
 
 static void
 zm_dump_buf (void *buf, int len)
 {
-#ifdef REDBOOT
-  diag_vdump_buf_with_offset (zm_dprintf, buf, len, 0);
-#else
 
-#endif
 }
 
 static unsigned char zm_buf[2048];
@@ -476,9 +414,6 @@ xyzModem_get_hdr (void)
 int
 xyzModem_stream_open (connection_info_t * info, int *err)
 {
-#ifdef REDBOOT
-  int console_chan;
-#endif
   int stat = 0;
   int retries = xyzModem_MAX_RETRIES;
   int crc_retries = xyzModem_MAX_RETRIES_WITH_CRC;
@@ -492,29 +427,9 @@ xyzModem_stream_open (connection_info_t * info, int *err)
 }
 #endif
 
-#ifdef REDBOOT
-  /* Set up the I/O channel.  Note: this allows for using a different port in 
the future */
-  console_chan =
-CYGACC_CALL_IF_SET_CONSOLE_COMM
-(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);
-  if (info->chan >= 0)
-{
-  CYGACC_CALL_IF_SET_CONSOLE_COMM (info->chan);
-}
-  else
-{
-  CYGACC_CALL_IF_SET_CONSOLE_COMM (console_chan);
-}
-  xyz.__chan = CYGACC_CALL_IF_CONSOLE_PROCS ();
-
-  CYGACC_CALL_IF_SET_CONSOLE_COMM (console_chan);
-  CYGACC_COMM_IF_CONTROL (*xyz.__chan, __COMMCTL_SET_TIMEOUT,
- xyzModem_CHAR_TIMEOUT);
-#else
 /* TODO: CHECK ! */
   int dummy = 0;
   xyz.__chan = 
-#endif
   xyz.len = 0;
   xyz.crc_mode = true;
   xyz.at_eof = false;
@@ -524,10 +439,8 @@ xyzModem_stream_open (connection_info_t * info, int *err)
   xyz.total_SOH = 0;
   xyz.total_STX = 0;
   xyz.total_CAN = 0;
-#ifdef USE_YMODEM_LENGTH
   xyz.read_length = 0;
   xyz.file_length = 0;
-#endif
 
   CYGACC_COMM_IF_PUTC (*xyz.__chan, (xyz.crc_mode ? 'C' : NAK));
 
@@ -546,12 +459,10 @@ xyzModem_stream_open (connection_info_t * info, int *err)
  /* Y-modem file information header */
  if (xyz.blk == 0)
{
-#ifdef USE_YMODEM_LENGTH
  /* skip filename */
  while (*xyz.bufp++);
  /* get the length */
  parse_num ((char *) xyz.bufp, _length, NULL, " ");
-#endif
  /* The rest of the file name data block quietly discarded */
  xyz.tx_ack = true;
}
@@ -604,13 +515,8 @@ xyzModem_stream_read (char *buf, 

Re: [U-Boot] [PATCH 3/3][v3] [RESEND] arm: ls1046ardb: Add SD secure boot target

[Ruchika Gupta]

> -Original Message-
> From: york sun
> Sent: Tuesday, April 04, 2017 9:29 PM
> To: Ruchika Gupta ; u-boot@lists.denx.de
> Cc: Vini Pillai ; Sumit Garg 
> Subject: Re: [PATCH 3/3][v3] [RESEND] arm: ls1046ardb: Add SD secure boot
> target
> 
> On 04/04/2017 12:06 AM, Ruchika Gupta wrote:
> >> -Original Message-
> >> From: york sun
> >> Sent: Monday, April 03, 2017 9:01 PM
> >> To: Ruchika Gupta ; u-boot@lists.denx.de
> >> Cc: Vini Pillai ; Sumit Garg
> >> 
> >> Subject: Re: [PATCH 3/3][v3] [RESEND] arm: ls1046ardb: Add SD secure
> >> boot target
> >>
> >> On 04/03/2017 12:00 AM, Ruchika Gupta wrote:
> >>>
> >>>
>  -Original Message-
>  From: york sun
>  Sent: Saturday, April 01, 2017 1:44 AM
>  To: Ruchika Gupta ; u-boot@lists.denx.de
>  Cc: Vini Pillai ; Sumit Garg
>  
>  Subject: Re: [PATCH 3/3][v3] [RESEND] arm: ls1046ardb: Add SD
>  secure boot target
> 
>  On 03/29/2017 07:21 AM, Ruchika Gupta wrote:
> > From: Vinitha Pillai-B57223 
> >
> > - Add SD secure boot target for ls1046ardb.
> > - Implement board specific spl_board_init() to setup CAAM stream
> > ID
> >> and
> >   corresponding stream ID in SMMU.
> > - Change the u-boot size defined by a macro for copying the main
> > U-Boot
>  by SPL
> >   to also include the u-boot Secure Boot header size as header is
> > appended
>  to
> >   u-boot image. So header will also be copied from SD to DDR.
> > - CONFIG_MAX_SPL_SIZE is limited to 90K.SPL is copied to OCRAM
> > (128K)
>  where 32K
> >   are reserved for use by boot ROM and 6K for the header
> > - Reduce the size of CAAM driver for SPL. Since the size of spl image
> >   was about 94K, Blobification functions and descriptors, that are
> > not
>  required
> >   at the time of SPL are disabled. Further error code conversion to 
> > strings
> >   is disabled for SPL build. This reduces the spl image size to 92K.
> >
> > Signed-off-by: Vinitha Pillai 
> > Signed-off-by: Sumit Garg 
> > Signed-off-by: Ruchika Gupta 
> > ---
> > Changes from v1:
> > - Rebased patches to latest dependent patch set
> > - With the dependent path set , spl imag size increased to 94K. So
> > - additionally  reduce the spl image size by removing the
> > functions from
> > - CAAM driver that are not required in SPL flow
> >
> 
>  
> 
> > +#if defined(CONFIG_SPL_BUILD)
> > +void spl_board_init(void)
> > +{
> > +#ifdef CONFIG_SECURE_BOOT
> > +   /*
> > +* In case of Secure Boot, the IBR configures the SMMU
> > +* to allow only Secure transactions.
> > +* SMMU must be reset in bypass mode.
> > +* Set the ClientPD bit and Clear the USFCFG Bit
> > +   */
> > +   u32 val;
> > +   val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) &
>  ~(SCR0_USFCFG_MASK);
> > +   out_le32(SMMU_SCR0, val);
> > +   val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) &
>  ~(SCR0_USFCFG_MASK);
> > +   out_le32(SMMU_NSCR0, val);
> > +#endif
> > +}
> 
>  Is this the same as LS1043A? Can we move this function to
>  arch/arm/cpu/armv8/fsl-layerscape/spl.c?
> >>> This is true for LS1043, LS1046, however wouldn't hold good for
> >>> Chassis
> >> gen3 SoC's like LS2088 , LS1088 etc. Is this file
> >> arch/arm/cpu/armv8/fsl- layerscape/spl.c common for the Chassis Gen 3
> SoC's also ?
> >>>
> >>
> >> Yes, it is common for lsch3.
> >>
> > Since it is common for lsh3, please suggest if we should move this
> > configuration under if defined(CONGIF_LS1043) || defined(CONFIG_LS1046) in
> arch/arm/cpu/armv8/fsl-layerscape/spl.c  or leave it in this file.
> >
> 
> I prefer to have it in a common file. It is easier to maintain. Can we use
> CONFIG_FSL_LSCH2 to gate these code? If you have to use SoC name, please
> use CONFIG_ARCH_LS1043A and CONFIG_ARCH_LS1046A.
> 
Next version of patch-set sent with this change. CONFIG_FSL_LSCH2 used to gate 
this code.

Ruchika

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

[U-Boot] [PATCH 3/3][v4] arm: ls1046ardb: Add SD secure boot target

[Ruchika Gupta]

- Add SD secure boot target for ls1046ardb.
- Change the u-boot size defined by a macro for copying the main U-Boot by SPL
  to also include the u-boot Secure Boot header size as header is appended to
  u-boot image. So header will also be copied from SD to DDR.
- CONFIG_MAX_SPL_SIZE is limited to 90K.SPL is copied to OCRAM (128K) where 32K
  are reserved for use by boot ROM and 6K for the header
- Reduce the size of CAAM driver for SPL Blobification functions and 
descriptors,
  that are not required at the time of SPL are disabled. Further error code
  conversion to strings is disabled for SPL build.

Signed-off-by: Vinitha Pillai 
Signed-off-by: Sumit Garg 
Signed-off-by: Ruchika Gupta 
---
Changes in v4:
Removed spl_board_init from board specific file.

Changes in v3:
Resend

Changes in v2:
- Rebased patches to latest dependent patch set
- With the dependent path set , spl imag size increased to 94K. So
- additionally  reduce the spl image size by removing the functions from
- CAAM driver that are not required in SPL flow

Dependent patch set:
SECURE boot target addition for NOR on LS1043, LS1046
https://patchwork.ozlabs.org/patch/742548/
https://patchwork.ozlabs.org/patch/742552/
https://patchwork.ozlabs.org/patch/742549/
https://patchwork.ozlabs.org/patch/742551/
https://patchwork.ozlabs.org/patch/742550/
https://patchwork.ozlabs.org/patch/742553/
https://patchwork.ozlabs.org/patch/742554/

and
SPL size reduction patches
https://patchwork.ozlabs.org/patch/744755/
https://patchwork.ozlabs.org/patch/744756/

 arch/arm/include/asm/fsl_secure_boot.h  |  2 +-
 configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 45 +
 drivers/crypto/fsl/jobdesc.c|  4 +--
 drivers/crypto/fsl/jr.c | 19 ++-
 include/configs/ls1046a_common.h| 17 --
 5 files changed, 72 insertions(+), 15 deletions(-)
 create mode 100644 configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 9ca7abe..97eab64 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -88,7 +88,7 @@
 /* For SD boot address and size are assigned in terms of sector
  * offset and no. of sectors respectively.
  */
-#if defined(CONFIG_LS1043A)
+#if defined(CONFIG_LS1043A) || defined(CONFIG_ARCH_LS1046A)
 #define CONFIG_BS_HDR_ADDR_DEVICE  0x0920
 #else
 #define CONFIG_BS_HDR_ADDR_DEVICE   0x0900
diff --git a/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig 
b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig
new file mode 100644
index 000..a41ec80
--- /dev/null
+++ b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig
@@ -0,0 +1,45 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1046ARDB=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL"
+CONFIG_SECURE_BOOT=y
+CONFIG_SD_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_SPL=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x110
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
+CONFIG_FSL_QSPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_RSA=y
+CONFIG_SPL_RSA=y
+CONFIG_SPL_CRYPTO_SUPPORT=y
+CONFIG_SPL_HASH_SUPPORT=y
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index 6125bbb..375ff9d 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++ b/drivers/crypto/fsl/jobdesc.c
@@ -204,7 +204,7 @@ void inline_cnstr_jobdesc_hash(uint32_t *desc,
append_store(desc, dma_addr_out, storelen,
 LDST_CLASS_2_CCB | LDST_SRCDST_BYTE_CONTEXT);
 }
-
+#ifndef CONFIG_SPL_BUILD
 void inline_cnstr_jobdesc_blob_encap(uint32_t *desc, uint8_t *key_idnfr,
 uint8_t *plain_txt, uint8_t *enc_blob,
 uint32_t in_sz)
@@ -252,7 +252,7 @@ void inline_cnstr_jobdesc_blob_decap(uint32_t *desc, 
uint8_t *key_idnfr,
 
append_operation(desc, OP_TYPE_DECAP_PROTOCOL | OP_PCLID_BLOB);
 }
-
+#endif
 /*
  * Descriptor to instantiate RNG State Handle 0 in normal mode and
  * load the JDKEK, TDKEK and TDSK registers
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 1b88229..163e729 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -342,7 +342,9 @@ static void desc_done(uint32_t status, void *arg)
 {
struct result *x = arg;
 

[U-Boot] [PATCH 2/3][v3] arm: ls1043ardb: Add NAND secure boot target

[Ruchika Gupta]

Add NAND secure boot target for ls1043ardb.

- Change the u-boot size defined by a macro for copying the main
  U-Boot by SPL to also include the u-boot Secure Boot header size as
  header is appended to u-boot image. So header will also be copied from SD to 
DDR.
- MACRO for CONFIG_BOOTSCRIPT_COPY_RAM is enabled to copy Bootscript from NAND 
to
  DDR. Offsets for Bootscript on NAND and DDR have been also defined.

Signed-off-by: Vinitha Pillai 
Signed-off-by: Sumit Garg 
Signed-off-by: Ruchika Gupta 
---
Changes in v3:
Removed changes to ls1043ardb.c

Changes in v2:
- Rebased this patch to the latest dependent patch-set.

Dependent patch set:
SECURE boot target addition for NOR on LS1043, LS1046
https://patchwork.ozlabs.org/patch/742548/
https://patchwork.ozlabs.org/patch/742552/
https://patchwork.ozlabs.org/patch/742549/
https://patchwork.ozlabs.org/patch/742551/
https://patchwork.ozlabs.org/patch/742550/
https://patchwork.ozlabs.org/patch/742553/
https://patchwork.ozlabs.org/patch/742554/

and
SPL size reduction patches
https://patchwork.ozlabs.org/patch/744755/
https://patchwork.ozlabs.org/patch/744756/

 arch/arm/include/asm/fsl_secure_boot.h|  7 +++-
 configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 57 +++
 include/config_fsl_chain_trust.h  |  9 +++--
 include/configs/ls1043a_common.h  | 18 -
 include/configs/ls1043ardb.h  |  2 +-
 5 files changed, 86 insertions(+), 7 deletions(-)
 create mode 100644 configs/ls1043ardb_nand_SECURE_BOOT_defconfig

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 56a6ba0..9ca7abe 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -70,7 +70,7 @@
 /* Copying Bootscript and Header to DDR from NOR for LS2 and for rest, from
  * Non-XIP Memory (Nand/SD)*/
 #if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_FSL_LSCH3) || \
-   defined(CONFIG_SD_BOOT)
+   defined(CONFIG_SD_BOOT) || defined(CONFIG_NAND_BOOT)
 #define CONFIG_BOOTSCRIPT_COPY_RAM
 #endif
 /* The address needs to be modified according to NOR, NAND, SD and
@@ -96,6 +96,11 @@
 #define CONFIG_BS_ADDR_DEVICE  0x0940
 #define CONFIG_BS_HDR_SIZE 0x0010
 #define CONFIG_BS_SIZE 0x0008
+#elif defined(CONFIG_NAND_BOOT)
+#define CONFIG_BS_HDR_ADDR_DEVICE  0x0080
+#define CONFIG_BS_ADDR_DEVICE  0x00802000
+#define CONFIG_BS_HDR_SIZE 0x2000
+#define CONFIG_BS_SIZE 0x1000
 #elif defined(CONFIG_QSPI_BOOT)
 #ifdef CONFIG_ARCH_LS1046A
 #define CONFIG_BS_HDR_ADDR_DEVICE  0x4078
diff --git a/configs/ls1043ardb_nand_SECURE_BOOT_defconfig 
b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig
new file mode 100644
index 000..66c89fa
--- /dev/null
+++ b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig
@@ -0,0 +1,57 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1043ARDB=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_NAND_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-rdb"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,NAND_BOOT"
+CONFIG_NAND_BOOT=y
+CONFIG_SECURE_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_SPL=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xf0
+CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_PXE=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_STORAGE=y
+CONFIG_RSA=y
+CONFIG_SPL_RSA=y
+CONFIG_SPL_CRYPTO_SUPPORT=y
+CONFIG_SPL_HASH_SUPPORT=y
diff --git a/include/config_fsl_chain_trust.h b/include/config_fsl_chain_trust.h
index eb45e98..40d323e 100644
--- a/include/config_fsl_chain_trust.h
+++ b/include/config_fsl_chain_trust.h
@@ -81,17 +81,18 @@
"setenv bs_size " __stringify(CONFIG_BS_SIZE)";"
 
 /* For secure boot flow, default environment used will be used */
-#if defined(CONFIG_SYS_RAMBOOT)
-#if defined(CONFIG_RAMBOOT_NAND)
+#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_NAND_BOOT) || \
+   defined(CONFIG_SD_BOOT)
+#if defined(CONFIG_RAMBOOT_NAND) || defined(CONFIG_NAND_BOOT)
 #define CONFIG_BS_COPY_CMD \
"nand read $bs_hdr_ram $bs_hdr_device $bs_hdr_size 

[U-Boot] [PATCH 1/3][v3] arm: ls1043ardb: Add SD secure boot target

[Ruchika Gupta]

- Add SD secure boot target for ls1043ardb.
- Implement FSL_LSCH2 specific spl_board_init() to setup CAAM stream ID and
  corresponding stream ID in SMMU.
- Change the u-boot size defined by a macro for copying the main U-Boot by SPL
  to also include the u-boot Secure Boot header size as header is appended to
  u-boot image. So header will also be copied from SD to DDR.
- CONFIG_MAX_SPL_SIZE is limited to 90K.SPL is copied to OCRAM (128K) where 32K
  are reserved for use by boot ROM and 6K for secure boto header
- Error messages during SPL boot are limited to error code numbers instead of 
strings
  to reduce the size of SPL image

Signed-off-by: Vinitha Pillai-B57223 
Signed-off-by: Sumit Garg 
Signed-off-by: Ruchika Gupta 
---
Changes in v3:
Moved spl_board_init function to arch/arm/cpu/armv8/fsl-layerscape/spl.c

Changes in v2:
Rebased to latest dependent patches: - No change

Dependent patch set:
SECURE boot target addition for NOR on LS1043, LS1046
https://patchwork.ozlabs.org/patch/742548/
https://patchwork.ozlabs.org/patch/742552/
https://patchwork.ozlabs.org/patch/742549/
https://patchwork.ozlabs.org/patch/742551/
https://patchwork.ozlabs.org/patch/742550/
https://patchwork.ozlabs.org/patch/742553/
https://patchwork.ozlabs.org/patch/742554/

and
SPL size reduction patches
https://patchwork.ozlabs.org/patch/744755/
https://patchwork.ozlabs.org/patch/744756/

 arch/arm/cpu/armv8/fsl-layerscape/spl.c | 18 
 arch/arm/include/asm/fsl_secure_boot.h  |  9 +++-
 board/freescale/common/fsl_validate.c   |  4 ++
 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig | 57 +
 include/configs/ls1043a_common.h| 16 ++-
 5 files changed, 100 insertions(+), 4 deletions(-)
 create mode 100644 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c 
b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
index 73a8680..dfacf98 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
@@ -41,6 +41,24 @@ u32 spl_boot_mode(const u32 boot_device)
 }
 
 #ifdef CONFIG_SPL_BUILD
+
+void spl_board_init(void)
+{
+#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_FSL_LSCH2)
+   /*
+* In case of Secure Boot, the IBR configures the SMMU
+* to allow only Secure transactions.
+* SMMU must be reset in bypass mode.
+* Set the ClientPD bit and Clear the USFCFG Bit
+   */
+   u32 val;
+   val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_SCR0, val);
+   val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_NSCR0, val);
+#endif
+}
+
 void board_init_f(ulong dummy)
 {
/* Clear global data */
diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 423c2c4..56a6ba0 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -27,10 +27,11 @@
 #define CONFIG_SPL_UBOOT_KEY_HASH  NULL
 #endif /* ifdef CONFIG_SPL_BUILD */
 
+#define CONFIG_KEY_REVOCATION
+
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_CMD_BLOB
 #define CONFIG_CMD_HASH
-#define CONFIG_KEY_REVOCATION
 #ifndef CONFIG_SYS_RAMBOOT
 /* The key used for verification of next level images
  * is picked up from an Extension Table which has
@@ -87,7 +88,11 @@
 /* For SD boot address and size are assigned in terms of sector
  * offset and no. of sectors respectively.
  */
-#define CONFIG_BS_HDR_ADDR_DEVICE  0x0900
+#if defined(CONFIG_LS1043A)
+#define CONFIG_BS_HDR_ADDR_DEVICE  0x0920
+#else
+#define CONFIG_BS_HDR_ADDR_DEVICE   0x0900
+#endif
 #define CONFIG_BS_ADDR_DEVICE  0x0940
 #define CONFIG_BS_HDR_SIZE 0x0010
 #define CONFIG_BS_SIZE 0x0008
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 2b723a4..235c6ab 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -356,6 +356,7 @@ static void fsl_secboot_bootscript_parse_failure(void)
  */
 void fsl_secboot_handle_error(int error)
 {
+#ifndef CONFIG_SPL_BUILD
const struct fsl_secboot_errcode *e;
 
for (e = fsl_secboot_errcodes; e->errcode != ERROR_ESBC_CLIENT_MAX;
@@ -363,6 +364,9 @@ void fsl_secboot_handle_error(int error)
if (e->errcode == error)
printf("ERROR :: %x :: %s\n", error, e->name);
}
+#else
+   printf("ERROR :: %x\n", error);
+#endif
 
/* If Boot Mode is secure, transition the SNVS state and issue
 * reset based on type of failure and ITS setting.
diff --git a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig 
b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig
new file mode 100644
index 000..3f35d64
--- /dev/null
+++ 

Re: [U-Boot] [PATCH v3 1/2] mx6sabresd: Make SPL DDR configuration to match the DCD table

[Jagan Teki]

On Tue, Apr 4, 2017 at 9:20 PM, Fabio Estevam  wrote:
> On Tue, Apr 4, 2017 at 12:47 PM, Jagan Teki  wrote:
>> Any help?
>
> Sorry, didn't have time to look at this issue.
>
> At least SPL U-Boot boots fine in this board. Can you also try U-Boot
> from NXP and try to debug it?

No, this isn't issue, just want to understand how you create reg init
in SPL in mx6q_dcd_table, means did you follow any order. because I'm
planning move *dl.cfg DCD to SPL

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