[U-Boot] [PATCH v3 0/2] Fix USB and enable ADC on Khadas VIM

2018-07-10 Thread Loic Devulder
This patch series add power supply entry for P212 like meson-gx boards.
It also enable ADC support for Khadas VIM board.

Based on the Neil Armstrong's patches.

Note: it's my first (small!) patch for U-Boot,
I tried to add all needed and useful informations :-)

Changes since v2:
 - change commit message for DTS backport

Changes since v1:
 - remove duplicated lines in configs/khadas-vim_defconfig

Loic Devulder (2):
  ARM64: meson: Add 'usb2_phy0' in P212 DT file
  configs: Update Meson GX configs

 arch/arm/dts/meson-gxl-s905x-p212.dtsi | 7 
 configs/khadas-vim_defconfig   | 3 +++
 2 files changed, 10 insertions(+)

-- 
2.13.7

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


[U-Boot] [[PATCH v3] 1/2] ARM64: meson: Sync DT with Linux 4.17.5

2018-07-10 Thread Loic Devulder
Synchronize the Linux Device Tree for Amlogic Meson GX boards from Linux 4.17.5
(Linux commit 54fb3c180d05e9dfda892a93413514e99f0cbb19).

This will enable HDMI_5V for USB Amlogic Meson GXL P212 based boards.

Signed-off-by: Loic Devulder 
---
 arch/arm/dts/meson-gxl-s905x-p212.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/meson-gxl-s905x-p212.dtsi 
b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
index 0cfd701809..3bd405079b 100644
--- a/arch/arm/dts/meson-gxl-s905x-p212.dtsi
+++ b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
@@ -189,3 +189,10 @@
 &usb0 {
status = "okay";
 };
+
+&usb2_phy0 {
+/*
+ * HDMI_5V is also used as supply for the USB VBUS.
+ */
+phy-supply = <&hdmi_5v>;
+};
-- 
2.13.7

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


[U-Boot] [[PATCH v3] 2/2] configs: Update Meson GX configs

2018-07-10 Thread Loic Devulder
Enable ADC support on the Khadas VIM board.

Signed-off-by: Loic Devulder 
Acked-by: Neil Armstrong 
---
 configs/khadas-vim_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/khadas-vim_defconfig b/configs/khadas-vim_defconfig
index 1eb13df4b4..fd1ec8157b 100644
--- a/configs/khadas-vim_defconfig
+++ b/configs/khadas-vim_defconfig
@@ -13,12 +13,15 @@ CONFIG_OF_BOARD_SETUP=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_IMI is not set
+CONFIG_CMD_ADC=y
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_REGULATOR=y
+CONFIG_ADC=y
+CONFIG_SARADC_MESON=y
 CONFIG_OF_CONTROL=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM_GPIO=y
-- 
2.13.7

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


[U-Boot] [PATCH v4 0/2] Fix USB and enable ADC on Khadas VIM

2018-07-10 Thread Loic Devulder
This patch series add power supply entry for P212 like meson-gx boards.
It also enable ADC support for Khadas VIM board.

Based on the Neil Armstrong's patches.

Note: it's my first (small!) patch for U-Boot,
I tried to add all needed and useful informations :-)

Changes since v3:
 - fix in Subject... sorry!

Changes since v2:
 - change commit message for DTS backport

Changes since v1:
 - remove duplicated lines in configs/khadas-vim_defconfig

Loic Devulder (2):
  ARM64: meson: Add 'usb2_phy0' in P212 DT file
  configs: Update Meson GX configs

 arch/arm/dts/meson-gxl-s905x-p212.dtsi | 7 
 configs/khadas-vim_defconfig   | 3 +++
 2 files changed, 10 insertions(+)

-- 
2.13.7

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


[U-Boot] [PATCH v4 1/2] ARM64: meson: Sync DT with Linux 4.17.5

2018-07-10 Thread Loic Devulder
Synchronize the Linux Device Tree for Amlogic Meson GX boards from Linux 4.17.5
(Linux commit 54fb3c180d05e9dfda892a93413514e99f0cbb19).

This will enable HDMI_5V for USB Amlogic Meson GXL P212 based boards.

Signed-off-by: Loic Devulder 
---
 arch/arm/dts/meson-gxl-s905x-p212.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/meson-gxl-s905x-p212.dtsi 
b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
index 0cfd701809..3bd405079b 100644
--- a/arch/arm/dts/meson-gxl-s905x-p212.dtsi
+++ b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
@@ -189,3 +189,10 @@
 &usb0 {
status = "okay";
 };
+
+&usb2_phy0 {
+/*
+ * HDMI_5V is also used as supply for the USB VBUS.
+ */
+phy-supply = <&hdmi_5v>;
+};
-- 
2.13.7

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


[U-Boot] [PATCH v4 2/2] configs: Update Meson GX configs

2018-07-10 Thread Loic Devulder
Enable ADC support on the Khadas VIM board.

Signed-off-by: Loic Devulder 
Acked-by: Neil Armstrong 
---
 configs/khadas-vim_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/khadas-vim_defconfig b/configs/khadas-vim_defconfig
index 1eb13df4b4..fd1ec8157b 100644
--- a/configs/khadas-vim_defconfig
+++ b/configs/khadas-vim_defconfig
@@ -13,12 +13,15 @@ CONFIG_OF_BOARD_SETUP=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_IMI is not set
+CONFIG_CMD_ADC=y
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_REGULATOR=y
+CONFIG_ADC=y
+CONFIG_SARADC_MESON=y
 CONFIG_OF_CONTROL=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM_GPIO=y
-- 
2.13.7

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


Re: [U-Boot] [ANN] U-Boot v2018.07 released

2018-07-10 Thread Wolfgang Denk
Dear Tom,

In message <20180709143201.GM27264@bill-the-cat> you wrote:
> 
> It's release day, and here we are doing the release.  It's live on git
> and FTP and ACD (along with the PGP sig file).

Release statistics are also on the web site.

Here the short summary:

Processed 1055 csets from 141 developers
27 employers found
A total of 88664 lines added, 54500 removed (delta 34164)

Developers with the most changesets
Marek Vasut 89 (8.4%)
Michal Simek54 (5.1%)
Bin Meng52 (4.9%)
Jagan Teki  51 (4.8%)
Chris Packham   48 (4.5%)
Lukasz Majewski 48 (4.5%)
Heinrich Schuchardt 43 (4.1%)
Miquel Raynal   32 (3.0%)
Simon Glass 28 (2.7%)
Alex Kiernan28 (2.7%)
...

Developers with the most changed lines
Marek Vasut   32311 (27.3%)
Chris Packham 14297 (12.1%)
Eugeniu Rosca 10343 (8.7%)
Igor Opaniuk  8197 (6.9%)
Tom Rini  5556 (4.7%)
Miquel Raynal 3987 (3.4%)
Jagan Teki3308 (2.8%)
Alex Kiernan  2702 (2.3%)
Alexander Graf2190 (1.9%)
Neil Armstrong1978 (1.7%)
...

Developers with the most lines removed
Eugeniu Rosca 8641 (15.9%)
Tom Rini  4271 (7.8%)
Tuomas Tynkkynen  1834 (3.4%)
Jaehoon Chung  314 (0.6%)
Ian Ray102 (0.2%)
Guillaume Gardet98 (0.2%)
Peter Robinson  25 (0.0%)
Sam Protsenko   20 (0.0%)
David Lechner   15 (0.0%)
Maxime Ripard   12 (0.0%)
...

Developers with the most signoffs (total 280)
Stefan Roese68 (24.3%)
Alexander Graf  41 (14.6%)
Michal Simek33 (11.8%)
Patrice Chotard 17 (6.1%)
Tom Warren  13 (4.6%)
Tom Rini12 (4.3%)
Sebastian Reichel8 (2.9%)
Baruch Siach 8 (2.9%)
Bin Meng 6 (2.1%)
Chin Liang See   5 (1.8%)
...

Developers with the most reviews (total 437)
Simon Glass182 (41.6%)
Tom Rini53 (12.1%)
Stefan Roese45 (10.3%)
Jagan Teki  36 (8.2%)
York Sun19 (4.3%)
Daniel Schwierzeck  17 (3.9%)
Bin Meng 9 (2.1%)
Heinrich Schuchardt  9 (2.1%)
Alexander Graf   7 (1.6%)
Masahiro Yamada  7 (1.6%)
...

Developers with the most test credits (total 38)
Michal Simek 6 (15.8%)
Petr Vorel   3 (7.9%)
Jagan Teki   2 (5.3%)
Bin Meng 2 (5.3%)
Fabio Estevam2 (5.3%)
Marek Vasut  2 (5.3%)
Chris Packham2 (5.3%)
Guillaume Gardet 2 (5.3%)
Peter Robinson   2 (5.3%)
Andreas Färber  2 (5.3%)
...

Developers who gave the most tested-by credits (total 38)
Andre Przywara   6 (15.8%)
Lokesh Vutla 5 (13.2%)
Bin Meng 4 (10.5%)
Eugeniu Rosca3 (7.9%)
Rabeeh Khoury3 (7.9%)
Alexander Graf   2 (5.3%)
Nishanth Menon   2 (5.3%)
Michal Simek 1 (2.6%)
Guillaume Gardet 1 (2.6%)
Alex Kiernan 1 (2.6%)
...

Developers with the most report credits (total 13)
Alexander Graf   1 (7.7%)
Simon Glass  1 (7.7%)
Petr Vorel   1 (7.7%)
Marek Vasut  1 (7.7%)
Andreas Färber  1 (7.7%)
Heinrich Schuchardt  1 (7.7%)
Masahiro Yamada  1 (7.7%)
Jaehoon Chung1 (7.7%)
Tuomas Tynkkynen 1 (7.7%)
Fabian Vogt  1 (7.7%)
...

Developers who gave the most report credits (total 13)
Alexander Graf   4 (30.8%)
Heinrich Schuchardt  1 (7.7%)
Masahiro Yamada  1 (7.7%)
Bin Meng 1 (7.7%)
Eugeniu Rosca1 (7.7%)
Michal Simek 1 (7.7%)
Siva Durga Prasad Paladugu1 (7.7%)
Tom Rini 1 (7.7%)
Joe Hershberger  1 (7.7%)
Seung-Woo Kim1 (7.7%)
...

Top lines changed by employer
(Unknown) 78525 (66.4%)
Linaro8424 (7.1%)
Konsulko Group5556 (4.7%)
ST Microelectronics   3345 (2.8%)
Amarula Solutions 3287 (2.8%)
Xilinx3253 (2.8%)
Intel 3172 (2.7%)
DENX Software Engineering 3112 (2.6%)
Novell2190 (1.9%)
Socionext Inc.1576 (1.3%)
...

Employers with the most signoffs (total 280)
DENX Software Engineering   68 (24.3%)
(Unknown)   44 (15.7%)
Novell  41 (14.6%)
Xilinx  33 (11.8%)
ST Microelectronics 24 (8.6%)
NVidia  13 (4.6%)
Konsulko Group 

Re: [U-Boot] [RFC] arm: dts: am33xx: Sync DTS with Linux 4.16.11

2018-07-10 Thread Lokesh Vutla
Hi Felix,

On Thursday 24 May 2018 02:32 PM, Felix Brack wrote:
> Hello,
> 
> I am working on a patch to synchronize the DTS files of the am33xx SoC
> with those from Linux 4.16.11 (current stable).
> 
> After some tiny modifications to the boards am335x-pdu001, am335x-evm,
> am335x-rut, am437x-gp-evm and am43x-epos-evm buildman passes without any
> warnings on the 46 am33xx based boards. This is required but not
> sufficient at all.
> 
> As I'm the maintainer of the am335x-pdu001 board I will use it to
> illustrate a sample problem.
> The am335x-pdu001 board uses the ns16550 driver which reads the property
>  from the DT. This property is required and must be set to a
> value of 2, otherwise it would default to 0.
> The am33xx.dtsi file currently used by U-Boot sets this property
> correctly for all 6 uarts. The am33xx.dtsi file from Linux 4.16.11
> however does not define this property anymore.
> For the am335x-pdu001 board the fix is trivial: just add the property
>  to the board and U-Boot specific am335xx-pdu001-u-boot.dtsi
> file.
> But this has a major drawback: only the am335x-pdu001 board gets fixed.
> What about other boards requiring the  property?

I agree this is a problem. Also not all kernel drivers need this
property as there are separate driver files for some of the compatibles.
And few drivers has this property hard-coded.

> The first idea that would probably come into mind is to put the property
>  into the SoC specific am33xx-u-boot.dtsi file. But this file
> is ignored if a board specific file already exists. Hence this can not
> be done.

One solution I can think of is add a Kconfig entry
CONFIG_SYS_NS16550_REG_SHIFT. A default value of 0 can be assigned for
this and can be updated in as necessary.

So when doing dev_read_u32_default for reg-shift,
CONFIG_SYS_NS16550_REG_SHIFT can be passed as default instead of 0. This
way no DTS files needs to be updated.

Thanks and regards,
Lokesh

> 
> For the patch I'm working on there is the general question about how to
> proceed. Should I just fix the board I'm maintaining and then post the
> patch? This would most certainly break some of the remaining 45 boards
> which I think is a no-go.
> 
> A more specific question dealing with the "missing SoC property"
>  above is about <>-u-boot.dtsi files: would it be possible,
> useful and hazard-free to change the build process to use, for example,
> SoC specific _and_ board specific files? Of course some sort of
> hierarchy would be necessary to make sure that properties defined in the
> board specific dtsi file would overwrite the same properties defined in
> the SoC specific file ect.
> 
> I believe that keeping DT files (especially include files) in sync
> between U-Boot and Linux is of big importance. Maybe there is already a
> standard solution to problems similar to the one depicted above. Anyway,
> I would appreciate any feedback.
> 
> regards, Felix
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] mtd: nand: add new enum for storing ECC algorithm

2018-07-10 Thread Philippe Reynes
From: Rafał Miłecki 

Our nand_ecc_modes_t is already a bit abused by value NAND_ECC_SOFT_BCH.
This enum should store ECC mode only and putting algorithm details there
is a bad idea. It would result in too many values impossible to support
in a sane way.

To solve this problem let's add a new enum. We'll have to modify all
drivers to set it properly but once it's done it'll be possible to drop
NAND_ECC_SOFT_BCH. That will result in a cleaner design and more
possibilities like setting ECC algorithm for hardware ECC mode.

Signed-off-by: Rafał Miłecki 
Signed-off-by: Boris Brezillon 
[Linux commit: b0fcd8ab7b3c89b5da7fff5224d06ed73e7a33cc]
[Philippe Reynes: adapt code to u-boot]
Signed-off-by: Philippe Reynes 
---
 include/linux/mtd/rawnand.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index cdad7b8..9f5dc81 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -143,6 +143,12 @@ typedef enum {
NAND_ECC_SOFT_BCH,
 } nand_ecc_modes_t;
 
+enum nand_ecc_algo {
+   NAND_ECC_UNKNOWN,
+   NAND_ECC_HAMMING,
+   NAND_ECC_BCH,
+};
+
 /*
  * Constants for Hardware ECC
  */
@@ -533,6 +539,7 @@ static const struct nand_ecc_caps __name = {
\
 /**
  * struct nand_ecc_ctrl - Control structure for ECC
  * @mode:  ECC mode
+ * @algo:  ECC algorithm
  * @steps: number of ECC steps per page
  * @size:  data bytes per ECC step
  * @bytes: ECC bytes per step
@@ -583,6 +590,7 @@ static const struct nand_ecc_caps __name = {
\
  */
 struct nand_ecc_ctrl {
nand_ecc_modes_t mode;
+   enum nand_ecc_algo algo;
int steps;
int size;
int bytes;
-- 
2.7.4

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


Re: [U-Boot] [PATCH] doc: Replace DocBook with sphinx-based docs

2018-07-10 Thread Heinrich Schuchardt
On 07/10/2018 08:40 AM, Mario Six wrote:
> The Linux kernel moved to sphinx-based documentation and got rid of the
> DocBook based documentation quite a while ago. Hence, the DocBook
> documentation for U-Boot should be converted as well.
> 
> To achieve this, import the necessary files from Linux v4.17, and
> convert the current DocBook documentation (three files altogether) to
> sphinx/reStructuredText.
> 
> For now, all old DocBook documentation was merged into a single
> handbook, tentatively named "U-Boot Hacker Manual".
> 
> For some source files, the documentation style was changed to comply
> with kernel-doc; no functional changes were applied.
> 

Hello Mario,

in general I am fine with the conversion.

Unfortunately your patch is not applicable to efi-next.

Applying: doc: Replace DocBook with sphinx-based docs
error: patch failed: lib/efi_loader/efi_boottime.c:2373
error: lib/efi_loader/efi_boottime.c: patch does not apply
Patch failed at 0001 doc: Replace DocBook with sphinx-based docs

Please, separate the lib/efi_loader/* related changes from the rest so
that they can be merged separately. The EFI part should be based on the
efi-next tree of https://github.com/agraf/u-boot.

Please, copy
https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt
into our doc tree as a reference.

Best regards

Heinrich

> Signed-off-by: Mario Six 
> ---

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


[U-Boot] [PATCH] ARM: dts: am3517-evm-uboot: Add reg-shift for UART

2018-07-10 Thread Adam Ford
With the resync of the omap3.dtsi file, the reg-shift was removed
so it breaks the UART.  Adding the reg-shift into the
am3517-evm-u-boot.dtsi keeps the reg-shift for U-Boot, but keeps
the dts/dtsi files clean from Linux.

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/am3517-evm-u-boot.dtsi 
b/arch/arm/dts/am3517-evm-u-boot.dtsi
index f049a6452e..59df819f9d 100644
--- a/arch/arm/dts/am3517-evm-u-boot.dtsi
+++ b/arch/arm/dts/am3517-evm-u-boot.dtsi
@@ -9,3 +9,15 @@
stdout-path = &uart3;
};
 };
+
+&uart1 {
+   reg-shift = <2>;
+};
+
+&uart2 {
+   reg-shift = <2>;
+};
+
+&uart3 {
+   reg-shift = <2>;
+};
-- 
2.17.1

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


Re: [U-Boot] [GIT] Pull request: u-boot-dfu (09.07.2018)

2018-07-10 Thread Marek Vasut
On 07/09/2018 04:35 PM, Lukasz Majewski wrote:
> Dear Marek,

Hi,

> The following changes since commit
> 3f0492f20755b9cd3b32ea7253169655489bab63:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-video (2018-07-08
>   18:56:07 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-dfu.git 
> 
> for you to fetch changes up to 45af84b87c521f258109e3d35359837e06036e88:
> 
>   gadget: f_thor: fix hang-up with ctrl-c (2018-07-09 16:32:33 +0200)
Applied, thanks

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


[U-Boot] [PATCH] ARM: DTS: am3517-evm-u-boot: Mark MMC1 with cd-inverted

2018-07-10 Thread Adam Ford
In order to use the device tree for MMC, the card-detect pin
needs to be inverted.  This patch places this into the
am3517-evm-u-boot.dtsi file to keep the main DTS and DTSI files
clean and in-sync with Linux

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/am3517-evm-u-boot.dtsi 
b/arch/arm/dts/am3517-evm-u-boot.dtsi
index 59df819f9d..c02beaad77 100644
--- a/arch/arm/dts/am3517-evm-u-boot.dtsi
+++ b/arch/arm/dts/am3517-evm-u-boot.dtsi
@@ -10,6 +10,10 @@
};
 };
 
+&mmc1 {
+   cd-inverted;
+};
+
 &uart1 {
reg-shift = <2>;
 };
-- 
2.17.1

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


Re: [U-Boot] [PATCH v3 5/7] armv8: ls1046a: initial icid setup support

2018-07-10 Thread Laurentiu Tudor
Hi Bharat,

On 10.07.2018 08:14, Bharat Bhushan wrote:
> 
> 
>> -Original Message-
>> From: Laurentiu Tudor
>> Sent: Monday, July 9, 2018 6:42 PM
>> To: Bharat Bhushan ; York Sun
>> ; Prabhakar Kushwaha
>> ; u-boot@lists.denx.de
>> Subject: Re: [PATCH v3 5/7] armv8: ls1046a: initial icid setup support
>>
>> Hi Bharat,
>>
>> On 09.07.2018 15:13, Bharat Bhushan wrote:
>>>
>>>
 -Original Message-
 From: Laurentiu Tudor [mailto:laurentiu.tu...@nxp.com]
 Sent: Wednesday, July 4, 2018 7:44 PM
 To: York Sun ; Prabhakar Kushwaha
 ; u-boot@lists.denx.de
 Cc: Bharat Bhushan ; Laurentiu Tudor
 
 Subject: [PATCH v3 5/7] armv8: ls1046a: initial icid setup support

 Add infrastructure for ICID setup and device tree fixup on ARM platforms.
 This include basic ICID setup for several devices.

 Signed-off-by: Laurentiu Tudor 
 ---
arch/arm/cpu/armv8/fsl-layerscape/Makefile|   1 +
arch/arm/cpu/armv8/fsl-layerscape/icid.c  | 111
>> ++
.../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c |  29 +
arch/arm/cpu/armv8/fsl-layerscape/soc.c   |   3 +
.../asm/arch-fsl-layerscape/fsl_icid.h|  80 +
board/freescale/ls1046aqds/ls1046aqds.c   |   2 +
board/freescale/ls1046ardb/ls1046ardb.c   |   3 +
7 files changed, 229 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/icid.c
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
create mode 100644
 arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h

 diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
 b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
 index 1e9e4680fe..5d6f68aad6 100644
 --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
 +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
 @@ -37,6 +37,7 @@ endif

ifneq ($(CONFIG_ARCH_LS1046A),)
obj-$(CONFIG_SYS_HAS_SERDES) += ls1046a_serdes.o
 +obj-y += icid.o ls1046_ids.o
endif

ifneq ($(CONFIG_ARCH_LS1088A),)
 diff --git a/arch/arm/cpu/armv8/fsl-layerscape/icid.c
 b/arch/arm/cpu/armv8/fsl-layerscape/icid.c
 new file mode 100644
 index 00..8694bd6fa1
 --- /dev/null
 +++ b/arch/arm/cpu/armv8/fsl-layerscape/icid.c
 @@ -0,0 +1,111 @@
 +// SPDX-License-Identifier: GPL-2.0+
 +/*
 + * Copyright 2018 NXP
 + */
 +
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +#include 
 +#include 
 +
 +static void set_icid(struct icid_id_table *tbl, int size) {
 +  int i;
 +
 +  for (i = 0; i < size; i++)
 +  out_be32((u32 *)(tbl[i].reg_addr), tbl[i].reg); }
 +
 +void set_icids(void)
 +{
 +  /* setup general icid offsets */
 +  set_icid(icid_tbl, icid_tbl_sz);
 +}
 +
 +int fdt_set_iommu_prop(void *blob, int off, int smmu_ph, u32 *ids,
 +int
 +num_ids) {
 +  int i, ret;
 +  u32 prop[8];
 +
 +  for (i = 0; i < num_ids; i++) {
 +  prop[i * 2] = cpu_to_fdt32(smmu_ph);
 +  prop[i * 2 + 1] = cpu_to_fdt32(ids[i]);
 +  }
 +  ret = fdt_setprop(blob, off, "iommus",
 +prop, sizeof(u32) * num_ids * 2);
 +  if (ret > 0) {
 +  printf("WARNING unable to set iommus: %s\n",
 fdt_strerror(off));
 +  return off;
 +  }
 +  ret = fdt_setprop_empty(blob, off, "dma-coherent");
>>>
>>> This forces "dma-coherent" for all SOCs, although there is no current
>> known SOCs which does not support non-coherent but maybe safe not to
>> set from common code.
>>
>> I see your point and will drop this.
>> Now, regarding a replacement solution, I don't have any other idea than
>> updating the device trees directly. Thoughts?
> 
> dma-coherent will be default in device tree and u-boot code should check if 
> dma-coherent already set.

You mean add a check that dma-coherent isn't already there?

> Have another function exposed from generic code which set "dma-coherent" and 
> platforms code will call that function if it is coherent.

Who would call such a function in the current design? Not sure I 
understand where this would fit in the current implementation.

On the other hand, I think that the dma coherency of a device is a hw 
property and it really makes sense to sit in the device tree.

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


[U-Boot] [PATCH] configs: Convert CONFIG_USE_NAND to CONFIG_NAND

2018-07-10 Thread Adam Ford
The DA850-EVM and OMAPL138_LCDK both use checks for CONFIG_USE_NAND.
This patch changes these checks to CONFIG_NAND which is already defined
in Kconfig.  Since the OMAPL138_LCDK already had CONFIG_NAND defined in its
defconfig, it can be deleted from configs/omapl138_lcdk.h.

Signed-off-by: Adam Ford 

diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index ebfdd1c7a3..6690be60b6 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -148,7 +148,7 @@
 /*
  * Flash & Environment
  */
-#ifdef CONFIG_USE_NAND
+#ifdef CONFIG_NAND
 #define CONFIG_NAND_DAVINCI
 #define CONFIG_ENV_OFFSET  0x0 /* Block 0--not used by bootcode */
 #define CONFIG_ENV_SIZE(128 << 10)
@@ -273,12 +273,12 @@
 #define CONFIG_CLOCKS
 #endif
 
-#ifdef CONFIG_USE_NAND
+#ifdef CONFIG_NAND
 #define CONFIG_MTD_DEVICE
 #define CONFIG_MTD_PARTITIONS
 #endif
 
-#if !defined(CONFIG_USE_NAND) && \
+#if !defined(CONFIG_NAND) && \
!defined(CONFIG_USE_NOR) && \
!defined(CONFIG_USE_SPIFLASH)
 #define CONFIG_ENV_SIZE(16 << 10)
diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
index 58624ec581..ee6f866581 100644
--- a/include/configs/omapl138_lcdk.h
+++ b/include/configs/omapl138_lcdk.h
@@ -16,7 +16,6 @@
 #define CONFIG_DRIVER_TI_EMAC
 #undef CONFIG_USE_SPIFLASH
 #undef CONFIG_SYS_USE_NOR
-#defineCONFIG_USE_NAND
 
 /*
 * Disable DM_* for SPL build and can be re-enabled after adding
@@ -142,7 +141,7 @@
 /*
  * Flash & Environment
  */
-#ifdef CONFIG_USE_NAND
+#ifdef CONFIG_NAND
 #define CONFIG_NAND_DAVINCI
 #define CONFIG_ENV_OFFSET  0x0 /* Block 0--not used by bootcode */
 #define CONFIG_ENV_SIZE(128 << 9)
@@ -262,12 +261,12 @@
 #ifndef CONFIG_DRIVER_TI_EMAC
 #endif
 
-#ifdef CONFIG_USE_NAND
+#ifdef CONFIG_NAND
 #define CONFIG_MTD_DEVICE
 #define CONFIG_MTD_PARTITIONS
 #endif
 
-#if !defined(CONFIG_USE_NAND) && \
+#if !defined(CONFIG_NAND) && \
!defined(CONFIG_SYS_USE_NOR) && \
!defined(CONFIG_USE_SPIFLASH)
 #define CONFIG_ENV_SIZE(16 << 10)
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 97e27ae7fe..8ded15c89a 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4418,7 +4418,6 @@ CONFIG_SYS_USE_FLASH
 CONFIG_SYS_USE_MAIN_OSCILLATOR
 CONFIG_SYS_USE_MMC
 CONFIG_SYS_USE_MPC834XSYS_USB_PHY
-CONFIG_SYS_USE_NAND
 CONFIG_SYS_USE_NANDFLASH
 CONFIG_SYS_USE_NOR
 CONFIG_SYS_USE_NORFLASH
-- 
2.17.1

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


[U-Boot] [PATCH] Convert CONFIG_DA8XX_GPIO to Kconfig

2018-07-10 Thread Adam Ford
This converts the following to Kconfig:
   CONFIG_DA8XX_GPIO

Signed-off-by: Adam Ford 

diff --git a/configs/calimain_defconfig b/configs/calimain_defconfig
index 7908cfcc34..bc704ff7bd 100644
--- a/configs/calimain_defconfig
+++ b/configs/calimain_defconfig
@@ -23,6 +23,7 @@ CONFIG_CMD_DIAG=y
 CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_SYS_BOOTCOUNT_ADDR=0x01C23000
+CONFIG_DA8XX_GPIO=y
 # CONFIG_MMC is not set
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/da850_am18xxevm_defconfig 
b/configs/da850_am18xxevm_defconfig
index c76321fb47..3223b44ba5 100644
--- a/configs/da850_am18xxevm_defconfig
+++ b/configs/da850_am18xxevm_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_DIAG=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_DM=y
+CONFIG_DA8XX_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_I2C_COMPAT=y
 CONFIG_DM_SPI_FLASH=y
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index 6a2b7ae670..b6ec087569 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -37,6 +37,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_DM=y
 CONFIG_DM_GPIO=y
+CONFIG_DA8XX_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_I2C_COMPAT=y
 CONFIG_DM_SPI_FLASH=y
diff --git a/configs/da850evm_direct_nor_defconfig 
b/configs/da850evm_direct_nor_defconfig
index f71d351ad3..9d6c47df50 100644
--- a/configs/da850evm_direct_nor_defconfig
+++ b/configs/da850evm_direct_nor_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_DIAG=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_DM=y
+CONFIG_DA8XX_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_I2C_COMPAT=y
 # CONFIG_MMC is not set
diff --git a/configs/ea20_defconfig b/configs/ea20_defconfig
index 497e5515d7..8d0aac700c 100644
--- a/configs/ea20_defconfig
+++ b/configs/ea20_defconfig
@@ -29,6 +29,7 @@ CONFIG_CMD_BMP=y
 CONFIG_CMD_DIAG=y
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_DA8XX_GPIO=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
diff --git a/configs/ipam390_defconfig b/configs/ipam390_defconfig
index 15c4944b3b..4256730e4c 100644
--- a/configs/ipam390_defconfig
+++ b/configs/ipam390_defconfig
@@ -33,5 +33,6 @@ 
CONFIG_MTDPARTS_DEFAULT="mtdparts=davinci_nand.0:128k(u-boot-env),1408k(u-boot),
 CONFIG_CMD_DIAG=y
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_DA8XX_GPIO=y
 # CONFIG_MMC is not set
 CONFIG_SYS_NS16550=y
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 29af22ecc7..9caa87846c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -58,6 +58,11 @@ config ATMEL_PIO4
  may be dedicated as a general purpose I/O or be assigned to
  a function of an embedded peripheral.
 
+config DA8XX_GPIO
+   bool "DA8xx GPIO Driver"
+   help
+ This driver supports the DA8xx GPIO controller
+
 config INTEL_BROADWELL_GPIO
bool "Intel Broadwell GPIO driver"
depends on DM
diff --git a/include/configs/calimain.h b/include/configs/calimain.h
index ab4a9e6ddc..690f605695 100644
--- a/include/configs/calimain.h
+++ b/include/configs/calimain.h
@@ -26,7 +26,6 @@
 #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
 #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
 #define CONFIG_ARCH_CPU_INIT
-#define CONFIG_DA8XX_GPIO
 #define CONFIG_HW_WATCHDOG
 #define CONFIG_SYS_WDTTIMERBASEDAVINCI_TIMER1_BASE
 #define CONFIG_SYS_WDT_PERIOD_LOW \
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 6690be60b6..a8d4894bee 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -226,7 +226,6 @@
 #define CONFIG_MTD_PARTITIONS  /* required for UBI partition support */
 #endif
 
-#define CONFIG_DA8XX_GPIO
 /*
  * U-Boot general configuration
  */
diff --git a/include/configs/ea20.h b/include/configs/ea20.h
index c84cd962d7..5e6f0c23d2 100644
--- a/include/configs/ea20.h
+++ b/include/configs/ea20.h
@@ -28,7 +28,6 @@
 #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
 #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
 #define CONFIG_SKIP_LOWLEVEL_INIT
-#define CONFIG_DA8XX_GPIO
 
 /*
  * Memory Info
diff --git a/include/configs/ipam390.h b/include/configs/ipam390.h
index faf21ddb08..3b13798529 100644
--- a/include/configs/ipam390.h
+++ b/include/configs/ipam390.h
@@ -238,7 +238,6 @@
 #define CONFIG_SYS_SPL_ARGS_ADDR   LINUX_BOOT_PARAM_ADDR
 
 /* GPIO support */
-#define CONFIG_DA8XX_GPIO
 #define CONFIG_IPAM390_GPIO_BOOTMODE   ((16 * 7) + 14)
 
 #define CONFIG_SHOW_BOOT_PROGRESS
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 8ded15c89a..120212c4a6 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -309,7 +309,6 @@ CONFIG_CUSTOMER_BOARD_SUPPORT
 CONFIG_D2NET_V2
 CONFIG_DA850_AM18X_EVM
 CONFIG_DA850_EVM_MAX_CPU_CLK
-CONFIG_DA8XX_GPIO
 CONFIG_DBAU1000
 CONFIG_DBGU
 CONFIG_DBG_MONITOR
-- 
2.17.1

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

Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing

2018-07-10 Thread Jason Rush
On 7/9/2018 3:08 AM, Marek Vasut wrote:
> On 07/07/2018 12:56 AM, Jason Rush wrote:
>> On 7/5/2018 6:10 PM, Marek Vasut wrote:
>>> On 07/06/2018 01:11 AM, Jason Rush wrote:
 On 7/4/2018 2:23 AM, Marek Vasut wrote:
> On 07/04/2018 01:45 AM, Jason Rush wrote:
>> On 7/3/2018 9:08 AM, Marek Vasut wrote:
>>> On 07/03/2018 03:58 PM, Jason Rush wrote:
 On 6/29/2018 10:17 AM, Marek Vasut wrote:
> On 06/29/2018 05:06 PM, Jason Rush wrote:
>> On 6/29/2018 9:52 AM, Marek Vasut wrote:
>>> On 06/29/2018 04:44 PM, Jason Rush wrote:
 On 6/29/2018 9:34 AM, Marek Vasut wrote:
> On 06/29/2018 04:31 PM, Jason Rush wrote:
>> Dinh,
> Hi,
>
>> A while ago, you posted the following patchset for SoCFPGA to 
>> add the PL330
>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to 
>> SDRAM to
>> initialize the ECC bits if ECC was enabled:
>>
>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html
>>
>> I know it's been a long time, so I'll summarize some of the 
>> conversation...
>>
>> At the time, you had a problem with the patchset causing the SPL 
>> to fail to
>> find the MMC.  You had tracked it down to an issue with the 
>> following commit
>> "a78cd8613204 ARM: Rework and correct barrier definitions".  You 
>> and Marek
>> discussed it a bit, but I don't think there was a real 
>> conclusion.  You
>> submitted a second version of the patchset asking for advice on 
>> debugging
>> the issue:
>>
>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html
>>
>> No real conversation came from the second patchset, and that was 
>> the end of
>> the patch.
>>
>> I was hoping we could revisit adding your patchset again. I am 
>> working on a
>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased 
>> your patchset
>> against v2018.05 and it is working on my custom board (although 
>> I don't have
>> an MMC). I also tested it on a SoCKit booting from an MMC (I 
>> forced it to
>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), 
>> and the
>> SoCKit finds the MMC and boots.
>>
>> I don't have any suggestions on why it is working now on my 
>> board and not
>> back when you first submitted the patchset.  Maybe something 
>> else was fixed
>> in the MMC? I was hoping you and Marek could test this patch 
>> again on some
>> different SoCFPGA boards to see if you get the same results.
> Look at this patch
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b
>
> You likely want similar approach, it's faster then the DMA and 
> much simpler.
>
 Thanks Marek.  I'll give it a try.  Would you be interested in a 
 similar patch for the Gen 5?
>>> I don't have any Gen5 board which uses ECC, do you ?
>>> If so, yes, prepare a patch, it should be very similar.
>>>
>>> Make sure to measure how long it takes to scrub the memory and how 
>>> much
>>> memory you have, I'd be interested in the numbers.
>>>
>> Looking at the master branch, it doesn't look like that code is ever 
>> being called?
>> The sdram_init_ecc_bits() function is called from the 
>> ddr_calibration_sequence function(),
>> but I can't find where ddr_calibration_sequence is called().
> git grep for it, it's called from somewhere in the 
> arch/arm/mach-socfpga/
>
>> Either way, I can test it. I have a custom Cyclone V board with ECC, 
>> and the Intel Arria V SoC
>> Dev Kit I can test it on too which I think has ECC.
> Please do.
>
 I implemented a similar memset approach for the gen 5 socfpga.  It's 
 basically the same
 code as in that patch; however, when I performed a single memset the 
 processor would
 reset for some reason.  I changed it to loop over calling memset with 
 a size of 32MB over
 the entire address the address, and that worked as opposed to doing a 
 single memset on
 the RAM.
>>> Can you do grep MEMSET .config in your U-Boot build dir ? The arch
>>> memset is implemented in assembler and doesn't trigger WDT , so if it
>>> takes too long, it could be 

[U-Boot] [PATCH 1/1] Fix README for Khadas VIM board

2018-07-10 Thread Loic Devulder
Fix documentation to be able to cross-compile U-Boot on Khadas VIM board.

Signed-off-by: Loic Devulder 
---
 board/amlogic/khadas-vim/README | 32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/board/amlogic/khadas-vim/README b/board/amlogic/khadas-vim/README
index 7eaca724f8..0f912e9fcd 100644
--- a/board/amlogic/khadas-vim/README
+++ b/board/amlogic/khadas-vim/README
@@ -20,12 +20,19 @@ Currently the u-boot port supports the following devices:
  - serial
  - eMMC, microSD
  - Ethernet
+ - USB
 
 U-Boot compilation
 ==
 
+ > mkdir ~/cross-compile
+ > cd ~/cross-compile
+ > wget -c 
https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-elf/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf.tar.xz
+ > tar xvfJ gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf.tar.xz
+ > export PATH=$PWD/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf:$PATH
+ > cd 
  > export ARCH=arm
- > export CROSS_COMPILE=aarch64-none-elf-
+ > export CROSS_COMPILE=aarch64-elf-
  > make khadas-vim_defconfig
  > make
 
@@ -36,20 +43,31 @@ Amlogic doesn't provide sources for the firmware and for 
tools needed
 to create the bootloader image, so it is necessary to obtain them from
 the git tree published by the board vendor:
 
- > wget 
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
- > wget 
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+To be able to compile the *old* U-Boot (if needed):
+ > Remove the *new* gcc-7.2 from the PATH
+ > cd ~/cross-compile
+ > wget -c 
https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/aarch64-elf/gcc-linaro-4.9.4-2017.01-x86_64_aarch64-elf.tar.xz
  > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ > export PATH=$PWD/gcc-linaro-4.9.4-2017.01-x86_64_aarch64-elf/bin:$PATH
+
+To compile the ATF firmware:
+ > cd ~/cross-compile
+ > wget -c 
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
  > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
- > export 
PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ > export PATH=$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+
+ > cd 
  > git clone https://github.com/khadas/u-boot -b Vim vim-u-boot
  > cd vim-u-boot
+ > export ARCH=arm
+ > export CROSS_COMPILE=aarch64-elf-
  > make kvim_defconfig
  > make
- > export FIPDIR=$PWD/fip
 
 Go back to mainline U-Boot source tree then :
+ > export FIPDIR=$PWD/fip
+ > cd 
  > mkdir fip
-
  > cp $FIPDIR/gxl/bl2.bin fip/
  > cp $FIPDIR/gxl/acs.bin fip/
  > cp $FIPDIR/gxl/bl21.bin fip/
@@ -67,7 +85,7 @@ Go back to mainline U-Boot source tree then :
fip/bl30_new.bin \
bl30
 
- > $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+ > python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
 
  > $FIPDIR/blx_fix.sh \
fip/bl2_acs.bin \
-- 
2.13.7

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


[U-Boot] [PATCH 0/1] Fix README for Khadas VIM board

2018-07-10 Thread Loic Devulder
This patch fix the README file to be able to cross-compile U-Boot on
Khadas VIM board.

Loic Devulder (1):
  Fix README for Khadas VIM board

 board/amlogic/khadas-vim/README | 32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

-- 
2.13.7

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


[U-Boot] [PATCH 0/1] distro_bootcmd: Switch bootefi to use loadaddr by default.

2018-07-10 Thread Kristian Amlie
This patch fixes the issue that CONFIG_LOADADDR is not respected when
booting via distro_bootcmd and bootefi, and follows from the thread
"Thoughts on EFI, CONFIG_LOADADDR and kernel_addr_r". Since there was no
reply, I opted for altering the behavior and providing a fallback.

Kristian Amlie (1):
  distro_bootcmd: Switch bootefi to use loadaddr by default.

 include/config_distro_bootcmd.h | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

-- 
2.7.4

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


[U-Boot] [PATCH 1/1] distro_bootcmd: Switch bootefi to use loadaddr by default.

2018-07-10 Thread Kristian Amlie
loadaddr is configurable in Kconfig using CONFIG_LOADADDR, while
kernel_addr_r is not. Hence, loadaddr is the future. Provide the
existing kernel_addr_r as a fallback if loadaddr is not set.

Signed-off-by: Kristian Amlie 
---
 include/config_distro_bootcmd.h | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index d672e8e..839afcc 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -129,12 +129,15 @@
"else "   \
"bootefi bootmgr ${fdtcontroladdr};"  \
"fi;" \
+   "if test -z \"${loadaddr}\"; then "   \
+   "setenv loadaddr ${kernel_addr_r};"   \
+   "fi;" \
"load ${devtype} ${devnum}:${distro_bootpart} "   \
-   "${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; "  \
+   "${loadaddr} efi/boot/"BOOTEFI_NAME"; "   \
"if fdt addr ${fdt_addr_r}; then "\
-   "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
+   "bootefi ${loadaddr} ${fdt_addr_r};"  \
"else "   \
-   "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
+   "bootefi ${loadaddr} ${fdtcontroladdr};"  \
"fi\0"\
\
"load_efi_dtb="   \
@@ -277,12 +280,15 @@
"setenv efi_old_arch ${bootp_arch};"  \
"setenv bootp_vci " BOOTENV_EFI_PXE_VCI ";"   \
"setenv bootp_arch " BOOTENV_EFI_PXE_ARCH ";" \
-   "if dhcp ${kernel_addr_r}; then " \
+   "if test -z \"${loadaddr}\"; then "   \
+   "setenv loadaddr ${kernel_addr_r};"   \
+   "fi;" \
+   "if dhcp ${loadaddr}; then "  \
"tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};"  \
"if fdt addr ${fdt_addr_r}; then "\
-   "bootefi ${kernel_addr_r} ${fdt_addr_r}; "\
+   "bootefi ${loadaddr} ${fdt_addr_r}; " \
"else "   \
-   "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
+   "bootefi ${loadaddr} ${fdtcontroladdr};"  \
"fi;" \
"fi;" \
"setenv bootp_vci ${efi_old_vci};"\
-- 
2.7.4

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


Re: [U-Boot] [PATCH 5/5] arm: dts: socfpga: stratix10: update pdma

2018-07-10 Thread Dinh Nguyen


On 07/10/2018 08:11 AM, Chee, Tien Fong wrote:
> On Mon, 2018-07-09 at 22:28 +0200, Marek Vasut wrote:
>> On 07/09/2018 08:03 PM, Dinh Nguyen wrote:
>>>
>>>
>>>
>>> On 05/31/2018 03:08 AM, tien.fong.c...@intel.com wrote:

 From: Tien Fong Chee 

 Update pdma properties for Stratix 10

 Signed-off-by: Tien Fong Chee 
 ---
  arch/arm/dts/socfpga_stratix10.dtsi | 20 
  1 file changed, 20 insertions(+)

 diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
 b/arch/arm/dts/socfpga_stratix10.dtsi
 index ccd3f32..311ba09 100644
 --- a/arch/arm/dts/socfpga_stratix10.dtsi
 +++ b/arch/arm/dts/socfpga_stratix10.dtsi
 @@ -82,6 +82,26 @@
    ranges = <0 0 0 0x>;
    u-boot,dm-pre-reloc;
  
 +  amba {
 +  u-boot,dm-pre-reloc;
 +  compatible = "arm,amba-bus";
 +  #address-cells = <1>;
 +  #size-cells = <1>;
 +  ranges;
 +
 +  pdma: pdma@ffda {
 +  u-boot,dm-pre-reloc;
 +  compatible =
 "arm,pl330", "arm,dma330";
>>> I think you got "arm,dma330" binding wrong. I don't see any binding
>>> with
>>> that name.
> Here https://patchwork.ozlabs.org/patch/923234/ .

Oh okay...why do you need to add the additional binding "arm,dma330"?

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


Re: [U-Boot] [PATCH 1/1] Fix README for Khadas VIM board

2018-07-10 Thread Neil Armstrong
Hi Loic,

On 10/07/2018 15:15, Loic Devulder wrote:
> Fix documentation to be able to cross-compile U-Boot on Khadas VIM board.
> 
> Signed-off-by: Loic Devulder 
> ---
>  board/amlogic/khadas-vim/README | 32 +---
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/board/amlogic/khadas-vim/README b/board/amlogic/khadas-vim/README
> index 7eaca724f8..0f912e9fcd 100644
> --- a/board/amlogic/khadas-vim/README
> +++ b/board/amlogic/khadas-vim/README
> @@ -20,12 +20,19 @@ Currently the u-boot port supports the following devices:
>   - serial
>   - eMMC, microSD
>   - Ethernet
> + - USB

This will collide with my previous patch "boards: amlogic: Fix boards README"

>  
>  U-Boot compilation
>  ==
>  
> + > mkdir ~/cross-compile
> + > cd ~/cross-compile
> + > wget -c 
> https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-elf/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf.tar.xz
> + > tar xvfJ gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf.tar.xz
> + > export PATH=$PWD/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf:$PATH
> + > cd 
>   > export ARCH=arm
> - > export CROSS_COMPILE=aarch64-none-elf-
> + > export CROSS_COMPILE=aarch64-elf-
>   > make khadas-vim_defconfig
>   > make
>  
> @@ -36,20 +43,31 @@ Amlogic doesn't provide sources for the firmware and for 
> tools needed
>  to create the bootloader image, so it is necessary to obtain them from
>  the git tree published by the board vendor:
>  
> - > wget 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
> - > wget 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> +To be able to compile the *old* U-Boot (if needed):
> + > Remove the *new* gcc-7.2 from the PATH
> + > cd ~/cross-compile
> + > wget -c 
> https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/aarch64-elf/gcc-linaro-4.9.4-2017.01-x86_64_aarch64-elf.tar.xz
>   > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
> + > export PATH=$PWD/gcc-linaro-4.9.4-2017.01-x86_64_aarch64-elf/bin:$PATH
> +
> +To compile the ATF firmware:
> + > cd ~/cross-compile
> + > wget -c 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
>   > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> - > export 
> PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
> + > export PATH=$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
> +
> + > cd 
>   > git clone https://github.com/khadas/u-boot -b Vim vim-u-boot
>   > cd vim-u-boot
> + > export ARCH=arm
> + > export CROSS_COMPILE=aarch64-elf-
>   > make kvim_defconfig
>   > make
> - > export FIPDIR=$PWD/fip
>  
>  Go back to mainline U-Boot source tree then :
> + > export FIPDIR=$PWD/fip
> + > cd 
>   > mkdir fip
> -
>   > cp $FIPDIR/gxl/bl2.bin fip/
>   > cp $FIPDIR/gxl/acs.bin fip/
>   > cp $FIPDIR/gxl/bl21.bin fip/
> @@ -67,7 +85,7 @@ Go back to mainline U-Boot source tree then :
>   fip/bl30_new.bin \
>   bl30
>  
> - > $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
> + > python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0

Apart this line, I don't see the point of all the other changes ? Can you 
elaborate ?

These instructions are already made to cross-compile U-boot, is there an issue 
with the instructions ?

>  
>   > $FIPDIR/blx_fix.sh \
>   fip/bl2_acs.bin \
> 


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


Re: [U-Boot] [[PATCH v3] 1/2] ARM64: meson: Sync DT with Linux 4.17.5

2018-07-10 Thread Neil Armstrong
On 10/07/2018 09:54, Loic Devulder wrote:
> Synchronize the Linux Device Tree for Amlogic Meson GX boards from Linux 
> 4.17.5
> (Linux commit 54fb3c180d05e9dfda892a93413514e99f0cbb19).
> 
> This will enable HDMI_5V for USB Amlogic Meson GXL P212 based boards.
> 
> Signed-off-by: Loic Devulder 
> ---
>  arch/arm/dts/meson-gxl-s905x-p212.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/dts/meson-gxl-s905x-p212.dtsi 
> b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> index 0cfd701809..3bd405079b 100644
> --- a/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> +++ b/arch/arm/dts/meson-gxl-s905x-p212.dtsi
> @@ -189,3 +189,10 @@
>  &usb0 {
>   status = "okay";
>  };
> +
> +&usb2_phy0 {
> +/*
> + * HDMI_5V is also used as supply for the USB VBUS.
> + */
> +phy-supply = <&hdmi_5v>;
> +};
> 

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


Re: [U-Boot] [ANN] U-Boot v2018.07 released

2018-07-10 Thread Neil Armstrong
Hi Wolfgang,

On 10/07/2018 10:57, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180709143201.GM27264@bill-the-cat> you wrote:
>>
>> It's release day, and here we are doing the release.  It's live on git
>> and FTP and ACD (along with the PGP sig file).
> 
> Release statistics are also on the web site.
> 
> Here the short summary:
> 
> Processed 1055 csets from 141 developers
> 27 employers found
> A total of 88664 lines added, 54500 removed (delta 34164)
> 
> Developers with the most changesets
> Marek Vasut 89 (8.4%)
> Michal Simek54 (5.1%)
> Bin Meng52 (4.9%)
> Jagan Teki  51 (4.8%)
> Chris Packham   48 (4.5%)
> Lukasz Majewski 48 (4.5%)
> Heinrich Schuchardt 43 (4.1%)
> Miquel Raynal   32 (3.0%)
> Simon Glass 28 (2.7%)
> Alex Kiernan28 (2.7%)
> ...
> 
> Developers with the most changed lines
> Marek Vasut   32311 (27.3%)
> Chris Packham 14297 (12.1%)
> Eugeniu Rosca 10343 (8.7%)
> Igor Opaniuk  8197 (6.9%)
> Tom Rini  5556 (4.7%)
> Miquel Raynal 3987 (3.4%)
> Jagan Teki3308 (2.8%)
> Alex Kiernan  2702 (2.3%)
> Alexander Graf2190 (1.9%)
> Neil Armstrong1978 (1.7%)

Can you add all the @baylibre.com e-mails under the BayLibre employer section ?

Thanks,
Neil

> ...
> 
> Developers with the most lines removed
> Eugeniu Rosca 8641 (15.9%)
> Tom Rini  4271 (7.8%)
> Tuomas Tynkkynen  1834 (3.4%)
> Jaehoon Chung  314 (0.6%)
> Ian Ray102 (0.2%)
> Guillaume Gardet98 (0.2%)
> Peter Robinson  25 (0.0%)
> Sam Protsenko   20 (0.0%)
> David Lechner   15 (0.0%)
> Maxime Ripard   12 (0.0%)
> ...
> 
> Developers with the most signoffs (total 280)
> Stefan Roese68 (24.3%)
> Alexander Graf  41 (14.6%)
> Michal Simek33 (11.8%)
> Patrice Chotard 17 (6.1%)
> Tom Warren  13 (4.6%)
> Tom Rini12 (4.3%)
> Sebastian Reichel8 (2.9%)
> Baruch Siach 8 (2.9%)
> Bin Meng 6 (2.1%)
> Chin Liang See   5 (1.8%)
> ...
> 
> Developers with the most reviews (total 437)
> Simon Glass182 (41.6%)
> Tom Rini53 (12.1%)
> Stefan Roese45 (10.3%)
> Jagan Teki  36 (8.2%)
> York Sun19 (4.3%)
> Daniel Schwierzeck  17 (3.9%)
> Bin Meng 9 (2.1%)
> Heinrich Schuchardt  9 (2.1%)
> Alexander Graf   7 (1.6%)
> Masahiro Yamada  7 (1.6%)
> ...
> 
> Developers with the most test credits (total 38)
> Michal Simek 6 (15.8%)
> Petr Vorel   3 (7.9%)
> Jagan Teki   2 (5.3%)
> Bin Meng 2 (5.3%)
> Fabio Estevam2 (5.3%)
> Marek Vasut  2 (5.3%)
> Chris Packham2 (5.3%)
> Guillaume Gardet 2 (5.3%)
> Peter Robinson   2 (5.3%)
> Andreas Färber  2 (5.3%)
> ...
> 
> Developers who gave the most tested-by credits (total 38)
> Andre Przywara   6 (15.8%)
> Lokesh Vutla 5 (13.2%)
> Bin Meng 4 (10.5%)
> Eugeniu Rosca3 (7.9%)
> Rabeeh Khoury3 (7.9%)
> Alexander Graf   2 (5.3%)
> Nishanth Menon   2 (5.3%)
> Michal Simek 1 (2.6%)
> Guillaume Gardet 1 (2.6%)
> Alex Kiernan 1 (2.6%)
> ...
> 
> Developers with the most report credits (total 13)
> Alexander Graf   1 (7.7%)
> Simon Glass  1 (7.7%)
> Petr Vorel   1 (7.7%)
> Marek Vasut  1 (7.7%)
> Andreas Färber  1 (7.7%)
> Heinrich Schuchardt  1 (7.7%)
> Masahiro Yamada  1 (7.7%)
> Jaehoon Chung1 (7.7%)
> Tuomas Tynkkynen 1 (7.7%)
> Fabian Vogt  1 (7.7%)
> ...
> 
> Developers who gave the most report credits (total 13)
> Alexander Graf   4 (30.8%)
> Heinrich Schuchardt  1 (7.7%)
> Masahiro Yamada  1 (7.7%)
> Bin Meng 1 (7.7%)
> Eugeniu Rosca1 (7.7%)
> Michal Simek 1 (7.7%)
> Siva Durga Prasad Paladugu1 (7.7%)
> Tom Rini 1 (7.7%)
> Joe Hershberger  1 (7.7%)
> Seung-Woo Kim1 (7.7%)
> ...
> 
> Top lines changed by employer
> (Unknown) 78525 (66.4%)
> Linaro8424 (7.1%)
> Konsulko Group5556 (4.7%)
> ST Microelectronics   3345 (2.8%)
> Amarula Solutions 3287 (2.8%)
> Xilinx3253 (2.8%)
> Intel

Re: [U-Boot] [U-Boot, v6, 1/5] reset: Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 06:45:19PM +0800, Ley Foon Tan wrote:

> Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET, so can use
> CONFIG_IS_ENABLED(DM_RESET) checking in reset.h later.
> 
> Signed-off-by: Ley Foon Tan 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 2/5] include: reset: Change to use CONFIG_IS_ENABLED(DM_RESET)

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 06:45:20PM +0800, Ley Foon Tan wrote:

> Change to use CONFIG_IS_ENABLED(DM_RESET), so this can work in SPL
> build (CONFIG_SPL_DM_RESET) and U-boot build (CONFIG_DM_RESET).
> 
> Signed-off-by: Ley Foon Tan 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 4/5] serial: ns16550: Add reset ctrl to driver

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 06:45:22PM +0800, Ley Foon Tan wrote:

> Add code to reset all reset signals as in serial DT node. A reset property is 
> an optional feature,
> so do not fail if a reset property is not present.
> 
> If a reset property is discovered, then use it to deassert, thus bringing the
> IP out of reset.
> 
> Signed-off-by: Ley Foon Tan 
> Reviewed-by: Marek Vasut 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 7/9] arm: dts: bubblegum_96: Enable UART5 for serial console

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:37PM +0530, Manivannan Sadhasivam wrote:

> This commit enables UART5 found in S900 SoC for serial console support.
> 
> Signed-off-by: Manivannan Sadhasivam 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 1/9] arm: Add support for Actions Semi OWL SoC family

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:31PM +0530, Manivannan Sadhasivam wrote:

> This commit adds Actions Semi OWL SoC family support with S900 as the
> first target SoC.
> 
> Signed-off-by: Manivannan Sadhasivam 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 5/5] net: designware: Add reset ctrl to driver

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 06:45:23PM +0800, Ley Foon Tan wrote:

> Add code to reset all reset signals as in Ethernet DT node. A reset property 
> is an optional feature,
> so only print out a warning and do not fail if a reset property is not 
> present.
> 
> If a reset property is discovered, then use it to deassert, thus bringing the
> IP out of reset.
> 
> Signed-off-by: Ley Foon Tan 
> Reviewed-by: Simon Glass 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 3/9] dt-bindings: clock: Add S900 CMU register definitions

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:33PM +0530, Manivannan Sadhasivam wrote:

> This commit adds Actions Semi S900 CMU register definitions to clock
> bindings.
> 
> Signed-off-by: Manivannan Sadhasivam 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 5/9] clk: Add Actions Semi OWL clock support

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:35PM +0530, Manivannan Sadhasivam wrote:

> This commit adds Actions Semi OWL family base clock and S900 SoC specific
> clock support. For S900 peripheral clock support, only UART clock has been
> added for now.
> 
> Signed-off-by: Manivannan Sadhasivam 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 2/9] board: Add uCRobotics Bubblegum-96 board support

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:32PM +0530, Manivannan Sadhasivam wrote:

> This commit adds uCRobotics Bubblegum-96 board support. This board is
> one of the 96Boards Consumer Edition platform based on Actions Semi
> S900 SoC.
> 
> Features:
> - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
> - 2GiB RAM
> - 8GiB eMMC, uSD slot
> - WiFi, Bluetooth and GPS module
> - 2x Host, 1x Device USB port
> - HDMI
> - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
> 
> U-Boot will be loaded by ATF at EL2 execution level. Relevant driver
> support will be added in further commits.
> 
> Signed-off-by: Manivannan Sadhasivam 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v6, 3/5] mmc: dwmmc: socfpga: Add reset ctrl to driver

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 06:45:21PM +0800, Ley Foon Tan wrote:

> Add code to reset all reset signals as in mmc DT node. A reset property is an 
> optional feature,
> so only print out a warning and do not fail if a reset property is not 
> present.
> 
> If a reset property is discovered, then use it to deassert, thus bringing the
> IP out of reset.
> 
> Signed-off-by: Ley Foon Tan 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 4/9] arm: dts: s900: Add Clock Management Unit (CMU) nodes

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:34PM +0530, Manivannan Sadhasivam wrote:

> This commit adds Clock Management Unit (CMU) nodes for Actions Semi
> S900 SoC.
> 
> Signed-off-by: Manivannan Sadhasivam 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 9/9] MAINTAINERS: Add entries for Actions Semi OWL family

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:39PM +0530, Manivannan Sadhasivam wrote:

> Add myself as the Maintainer for Actions Semi OWL family and its
> relevant board, drivers.
> 
> Signed-off-by: Manivannan Sadhasivam 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 8/9] serial: Add Actions Semi OWL UART support

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:38PM +0530, Manivannan Sadhasivam wrote:

> This commit adds Actions Semi OWL family UART support. This driver
> relies on baudrate configured by primary bootloaders.
> 
> Signed-off-by: Manivannan Sadhasivam 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v3,6/9] arm: dts: s900: Add UART node

2018-07-10 Thread Tom Rini
On Thu, Jun 14, 2018 at 11:38:36PM +0530, Manivannan Sadhasivam wrote:

> This commit adds UART node for Actions Semi S900 SoC.
> 
> Signed-off-by: Manivannan Sadhasivam 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [ANN] U-Boot v2018.07 released

2018-07-10 Thread Michal Simek
Hi Wolfgang,

On 10.7.2018 10:57, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180709143201.GM27264@bill-the-cat> you wrote:
>>
>> It's release day, and here we are doing the release.  It's live on git
>> and FTP and ACD (along with the PGP sig file).
> 
> Release statistics are also on the web site.
> 
> Here the short summary:

Is this generating script somewhere?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




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


Re: [U-Boot] [ANN] U-Boot v2018.07 released

2018-07-10 Thread Stefano Babic
Hi Michael,

On 10/07/2018 16:13, Michal Simek wrote:
> Hi Wolfgang,
> 
> On 10.7.2018 10:57, Wolfgang Denk wrote:
>> Dear Tom,
>>
>> In message <20180709143201.GM27264@bill-the-cat> you wrote:
>>>
>>> It's release day, and here we are doing the release.  It's live on git
>>> and FTP and ACD (along with the PGP sig file).
>>
>> Release statistics are also on the web site.
>>
>> Here the short summary:
> 
> Is this generating script somewhere?
> 

This is Jonathan Corbet's tool:

git://git.lwn.net/gitdm.git

Regards,
Stefano

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


Re: [U-Boot] [PATCH 1/1] Fix README for Khadas VIM board

2018-07-10 Thread Loic Devulder
Hi Neil,

On 07/10/2018 03:43 PM, Neil Armstrong wrote:
> Hi Loic,
> 
> On 10/07/2018 15:15, Loic Devulder wrote:
>> Fix documentation to be able to cross-compile U-Boot on Khadas VIM board.
>>
>> Signed-off-by: Loic Devulder 
>> ---
>>  board/amlogic/khadas-vim/README | 32 +---
>>  1 file changed, 25 insertions(+), 7 deletions(-)
>>
>> diff --git a/board/amlogic/khadas-vim/README 
>> b/board/amlogic/khadas-vim/README
>> index 7eaca724f8..0f912e9fcd 100644
>> --- a/board/amlogic/khadas-vim/README
>> +++ b/board/amlogic/khadas-vim/README
>> @@ -20,12 +20,19 @@ Currently the u-boot port supports the following devices:
>>   - serial
>>   - eMMC, microSD
>>   - Ethernet
>> + - USB
> 
> This will collide with my previous patch "boards: amlogic: Fix boards README"

I was not aware of it sorry, so yes this can be removed.

> 
>>  
>>  U-Boot compilation
>>  ==
>>  
>> + > mkdir ~/cross-compile
>> + > cd ~/cross-compile
>> + > wget -c 
>> https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-elf/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf.tar.xz
>> + > tar xvfJ gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf.tar.xz
>> + > export PATH=$PWD/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-elf:$PATH
>> + > cd 
>>   > export ARCH=arm
>> - > export CROSS_COMPILE=aarch64-none-elf-
>> + > export CROSS_COMPILE=aarch64-elf-
>>   > make khadas-vim_defconfig
>>   > make
>>  
>> @@ -36,20 +43,31 @@ Amlogic doesn't provide sources for the firmware and for 
>> tools needed
>>  to create the bootloader image, so it is necessary to obtain them from
>>  the git tree published by the board vendor:
>>  
>> - > wget 
>> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
>> - > wget 
>> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
>> +To be able to compile the *old* U-Boot (if needed):
>> + > Remove the *new* gcc-7.2 from the PATH
>> + > cd ~/cross-compile
>> + > wget -c 
>> https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/aarch64-elf/gcc-linaro-4.9.4-2017.01-x86_64_aarch64-elf.tar.xz
>>   > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
>> + > export PATH=$PWD/gcc-linaro-4.9.4-2017.01-x86_64_aarch64-elf/bin:$PATH
>> +
>> +To compile the ATF firmware:
>> + > cd ~/cross-compile
>> + > wget -c 
>> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
>>   > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
>> - > export 
>> PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
>> + > export PATH=$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
>> +
>> + > cd 
>>   > git clone https://github.com/khadas/u-boot -b Vim vim-u-boot
>>   > cd vim-u-boot
>> + > export ARCH=arm
>> + > export CROSS_COMPILE=aarch64-elf-
>>   > make kvim_defconfig
>>   > make
>> - > export FIPDIR=$PWD/fip
>>  
>>  Go back to mainline U-Boot source tree then :
>> + > export FIPDIR=$PWD/fip
>> + > cd 
>>   > mkdir fip
>> -
>>   > cp $FIPDIR/gxl/bl2.bin fip/
>>   > cp $FIPDIR/gxl/acs.bin fip/
>>   > cp $FIPDIR/gxl/bl21.bin fip/
>> @@ -67,7 +85,7 @@ Go back to mainline U-Boot source tree then :
>>  fip/bl30_new.bin \
>>  bl30
>>  
>> - > $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
>> + > python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
> 
> Apart this line, I don't see the point of all the other changes ? Can you 
> elaborate ?
> 
> These instructions are already made to cross-compile U-boot, is there an 
> issue with the instructions ?

I had some issues with the cross compiler, mainly since U-Boot needs or
more recent gcc, that's why I added a section/example with gcc v7.

It took me some times to find the correct configuration, that's why I do
this changes, for people like me :)

But yes the 'python' part is the most important I think, to avoid
failing compilation on some Linux OSes. As for the other changes, if you
think that they are not needed no problem, I can remove them.

> 
>>  
>>   > $FIPDIR/blx_fix.sh \
>>  fip/bl2_acs.bin \
>>
> 
> 
> Neil
> 

-- 
Loic Devulder - Senior QA Engineer
Container & Storage Solutions Quality Assurance team (qa-css)
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB,
21284 (AG Nuernberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC] Make U-Boot log great again

2018-07-10 Thread Tom Rini
On Tue, Jul 10, 2018 at 11:01:14AM +0800, Bin Meng wrote:
> Hello,
> 
> On Fri, Mar 23, 2018 at 1:44 PM, Bin Meng  wrote:
> > Hi,
> >
> > On Sat, Feb 17, 2018 at 3:49 AM, Robert Nelson  
> > wrote:
> >> On Fri, Feb 16, 2018 at 1:01 PM, Sam Protsenko
> >>  wrote:
> >>> Hi guys,
> >>>
> >>> TL;DR This is a suggestion about fixing U-Boot log, which has got
> >>> worse recently.
> >>>
> >>> Right now U-Boot and SPL logs are cluttered with bogus warnings like
> >>> these (on X15 board, but I'm pretty sure it should appear on many
> >>> others):
> >>>
> >>> Loading Environment from FAT...
> >>> *** Warning - bad CRC, using default environment
> >>> Failed (-5)
> >>
> >
> > Do we plan to fix this "Failed (-5)" message? It's very confusing.
> > Like previous U-Boot just printing "*** Warning - bad CRC, using
> > default environment" is enough I think.
> >
> 
> The v2018.07 release still has this "Failed (-5)" message on boot.
> When do we plan to fix this?

I don't mean for this to sound glib, but I was expecting patches to get
posted to change this particular area at least.  I thought it had been
talked to the point where it was understood what the next steps should
look like?  Thanks/sorry!

-- 
Tom


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


Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

2018-07-10 Thread Simon Glass
Hi,

On 8 May 2018 at 04:21, Dr. Philipp Tomsich
 wrote:
> Marty,
>
>> On 8 May 2018, at 02:52, Marty E. Plummer  wrote:
>>
>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>>>
 On 7 May 2018, at 04:34, Marty E. Plummer  wrote:

 On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> Hi Marty,
>
>
> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>
>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
>> is incorrectly detected as 0 Bytes of ram.
>
> I know the root cause for this issue, and I have a local patch for it.
> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
> before
> the max size before return with '<<20'. Sorry for forgot to send it out.
>
>>
>> Signed-off-by: Marty E. Plummer 
>> ---
>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>
>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>> b/arch/arm/mach-rockchip/sdram_common.c
>> index 76dbdc8715..a9c9f970a4 100644
>> --- a/arch/arm/mach-rockchip/sdram_common.c
>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>> @@ -10,6 +10,8 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>> +#include 
>>
>> DECLARE_GLOBAL_DATA_PTR;
>> size_t rockchip_sdram_size(phys_addr_t reg)
>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>   size_t size_mb = 0;
>>   u32 ch;
>>
>> - u32 sys_reg = readl(reg);
>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>> -& SYS_REG_NUM_CH_MASK);
>> + if (!size_mb) {
>
> I don't understand this and follow up changes, we don't really need it,
> isn't it?
> I think don't need the changes before here.
 Yeah, that was just another level of indentation for the if (!size_mb)
 guard, but I've reworked the patch to not do that as it was pointed out
 that since size_mb is initialized to 0 prior.
>> + /*
>> +  * we use the 0x~0xfeff space
>> +  * since 0xff00~0x is soc register space
>> +  * so we reserve it
>> +  */
>> + size_mb = min(size_mb, 0xff00/SZ_1M);
>
> This is what we really need, as Klaus point out, we need to use
> SDRAM_MAX_SIZE
> instead of hard code.
 Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
 build and boot tested on my hardware.
>>>
>>> In that case you just masked the problem but didn???t solve it: assuming 
>>> size_mb
>>> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB 
>>> is 0x1__ )
>>> which overflows to 0x0 when converted to a u32.
>>>
>>> In other words: we need to figure out where the truncation occurs (image 
>>> what
>>> happens if a new 32bit processor with LPAE comes out???).
>>>
>> A very valid point. With the following patch to sdram_common.c and
>> sdram_rk3288.c applied I get the debug output that follows it:
>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>> b/arch/arm/mach-rockchip/sdram_common.c
>> index 232a7fa655..0fe69bf558 100644
>> --- a/arch/arm/mach-rockchip/sdram_common.c
>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>> @@ -4,6 +4,7 @@
>>  * SPDX-License-Identifier: GPL-2.0+
>>  */
>>
>> +#define DEBUG 1
>> #include 
>> #include 
>> #include 
>> @@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>   SYS_REG_ROW_3_4_MASK;
>>
>>   chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
>> + debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__, 
>> chipsize_mb);
>>
>>   if (rank > 1)
>>   chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
>>   if (row_3_4)
>>   chipsize_mb = chipsize_mb * 3 / 4;
>>   size_mb += chipsize_mb;
>> + debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
>>   debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
>> rank, col, bk, cs0_row, bw, row_3_4);
>>   }
>>
>> + debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
>>   size_mb = min(size_mb, SDRAM_MAX_SIZE/SZ_1M);
>>
>>   return (size_t)size_mb << 20;
>> diff --git a/drivers/ram/rockchip/sdram_rk3288.c 
>> b/drivers/ram/rockchip/sdram_rk3288.c
>> index d99bf12476..9738eb088f 100644
>> --- a/drivers/ram/rockchip/sdram_rk3288.c
>> +++ b/drivers/ram/rockchip/sdram_rk3288.c
>> @@ -7,6 +7,7 @@
>>  * Adapted from coreboot.
>>  */
>>
>> +#define DEBUG 1
>> #include 
>> #include 
>> #include 
>>
>> ---
>> U-Boot SPL 2018.05-rc3-02370-g309384e84b-dirty (May 07 2018 - 19:42:15 -0500)
>> Trying to boot from SPI
>>
>>
>> U-Boot 2018.05-rc3-02370-g309384e84b-dirt

Re: [U-Boot] [PATCH] power: regulator: denied disable on always-on regulator

2018-07-10 Thread Patrice CHOTARD
Hi Jaehoon

It's a gentle reminder to not forgot this patch.

Thanks

Patrice

On 05/31/2018 09:57 AM, Patrice Chotard wrote:
> From: Patrick Delaunay 
> 
> Don't disable regulator which are tagged as "regulator-always-on" in DT.
> 
> Signed-off-by: Patrick Delaunay 
> Signed-off-by: Patrice Chotard 
> ---
> 
>   drivers/power/regulator/regulator-uclass.c | 5 +
>   1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/power/regulator/regulator-uclass.c 
> b/drivers/power/regulator/regulator-uclass.c
> index 4da8e43259fc..4511625ff251 100644
> --- a/drivers/power/regulator/regulator-uclass.c
> +++ b/drivers/power/regulator/regulator-uclass.c
> @@ -106,10 +106,15 @@ int regulator_get_enable(struct udevice *dev)
>   int regulator_set_enable(struct udevice *dev, bool enable)
>   {
>   const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
> + struct dm_regulator_uclass_platdata *uc_pdata;
>   
>   if (!ops || !ops->set_enable)
>   return -ENOSYS;
>   
> + uc_pdata = dev_get_uclass_platdata(dev);
> + if (!enable && uc_pdata->always_on)
> + return -EACCES;
> +
>   return ops->set_enable(dev, enable);
>   }
>   
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PULL] efi patch queue 2018-07-10

2018-07-10 Thread Alexander Graf
Hi Tom,

This is my current patch queue for efi.  Please pull.

Alex


The following changes since commit 495c70f9dfad1a5428ec84b52e8667ea4760ecd6:

  net: designware: Add reset ctrl to driver (2018-07-09 15:28:28 -0400)

are available in the git repository at:

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

for you to fetch changes up to e2c6ec921b5a37ac96aba34731c972dfee9943b0:

  MAINTAINERS: assign lib/charset.c (2018-07-10 18:01:08 +0200)


Patch queue for efi - 2018-07-10

Highlights this time:

  - Many small fixes to improve spec compatibility (found by SCT)
  - Almost enough to run with sandbox target
  - GetTime() improvements
  - Enable EFI_LOADER and HYP entry on ARMv7 with NONSEC=y


Alexander Graf (10):
  efi_loader: Use compiler constants for image loader
  efi_loader: Use map_sysmem() in bootefi command
  efi_loader: Allow SMBIOS tables in highmem
  efi_loader: Disable miniapps on sandbox
  efi_loader: Introduce ms abi vararg helpers
  efi_loader: Move to compiler based target architecture determination
  elf: Move x86 reloc defines to common elf.h
  efi_loader: Use common elf.h reloc defines
  efi_loader: Expose U-Boot addresses in memory map for sandbox
  efi_loader: Rename sections to allow for implicit data

Heinrich Schuchardt (29):
  efi_selftest: update .gitignore
  efi_loader: efi_allocate_pages is too restrictive
  efi_loader: check parameters of CreateEvent
  efi_loader: check parameters in memory allocation
  efi_loader: check parameters of GetMemoryMap
  efi_loader: check map_key in ExitBootServices
  fs: fat: cannot write to subdirectories
  efi_selftest: test writing to file
  efi_driver: set DM_FLAG_NAME_ALLOCED flag
  efi_loader: set revision in loaded image protocol
  efi_loader: EFI_SIMPLE_TEXT_INPUT_PROTOCOL.Reset()
  efi_loader: clear screen has to reset cursor position
  efi_loader: specify UEFI spec revision
  efi_loader: correct EFI_RUNTIME_SERVICES_SIGNATURE
  efi_loader: correct headersize EFI tables
  efi_loader: provide firmware revision
  efi_loader: calculate crc32 for EFI tables
  efi_loader: allocate configuration table array
  efi_selftest: test InstallConfigurationTable()
  efi_loader: correct signature of CalculateCrc32()
  efi_loader: update crc32 in InstallConfigurationTable
  efi_selftest: check crc32 for InstallConfigurationTable
  efi_selftest: unit test for CalculateCrc32()
  rtc: remove CONFIG_CMD_DATE dependency
  efi_loader: remove unused efi_get_time_init()
  efi_loader: complete implementation of GetTime()
  efi_selftest: support printing leading zeroes
  efi_selftest: unit test for GetTime()
  MAINTAINERS: assign lib/charset.c

Mark Kettenis (5):
  ARM: HYP/non-sec: migrate stack
  efi_loader: ARM: run EFI payloads non-secure
  efi_loader: ARM: don't attempt to enter non-secure mode twice
  ARM: HYP/non-sec: enable ARMV7_LPAE if HYP mode is supported
  Revert "efi_loader: no support for ARMV7_NONSEC=y"

Simon Glass (5):
  efi: sandbox: Adjust memory usage for sandbox
  vsprintf: Handle NULL with %pU
  efi_selftest: Clean up a few comments and messages
  efi: Tidy up device-tree-size calculation in copy_fdt()
  efi: Drop error return in efi_carve_out_dt_rsv()

 MAINTAINERS  |   1 +
 arch/arm/config.mk   |   4 +-
 arch/arm/cpu/armv7/Kconfig   |   2 +-
 arch/arm/cpu/armv7/nonsec_virt.S |   2 +
 arch/arm/cpu/armv8/u-boot.lds|  24 ++-
 arch/arm/cpu/u-boot.lds  |  36 ++--
 arch/arm/mach-zynq/u-boot.lds|  36 ++--
 arch/riscv/cpu/ax25/u-boot.lds   |  26 ++-
 arch/sandbox/config.mk   |   3 +
 arch/sandbox/cpu/u-boot.lds  |   9 +-
 arch/x86/config.mk   |   2 +-
 arch/x86/cpu/u-boot.lds  |  32 ++--
 arch/x86/include/asm/elf.h   |  45 -
 arch/x86/lib/reloc_ia32_efi.c|   1 -
 arch/x86/lib/reloc_x86_64_efi.c  |   1 -
 board/qualcomm/dragonboard410c/u-boot.lds|  17 +-
 board/qualcomm/dragonboard820c/u-boot.lds|  24 ++-
 board/ti/am335x/u-boot.lds   |  36 ++--
 cmd/bootefi.c|  90 +++--
 doc/README.uefi  |   2 -
 drivers/rtc/at91sam9_rtt.c   |   4 -
 drivers/rtc/davinci.c|   2 -
 drivers/rtc/ds1302.c |   4 -
 drivers/rtc/ds1306.c |   4 -
 drivers/rtc/ds1307.c |   4 -
 drivers/rtc/ds1337.c |   4 -
 drivers/rtc/ds1374.c |

Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line

2018-07-10 Thread Tom Rini
On Mon, Jul 09, 2018 at 11:59:57AM -0500, Joe Hershberger wrote:
> On Mon, Jul 9, 2018 at 9:43 AM, Tom Rini  wrote:
> > On Mon, Jul 09, 2018 at 08:19:44AM +0200, Michal Simek wrote:
> >> On 30.6.2018 06:19, Simon Glass wrote:
> >> > On 27 June 2018 at 07:13, Michal Simek  wrote:
> >> >> On 22.6.2018 14:25, Jean-Jacques Hiblot wrote:
> >> >>> In some cases it can be useful to be able to bind a device to a driver 
> >> >>> from
> >> >>> the command line.
> >> >>> The obvious example is for versatile devices such as USB gadget.
> >> >>> Another use case is when the devices are not yet ready at startup and
> >> >>> require some setup before the drivers are bound (ex: FPGA which 
> >> >>> bitsream is
> >> >>> fetched from a mass storage or ethernet)
> >> >>>
> >> >>> usage example:
> >> >>>
> >> >>> bind usb_dev_generic 0 usb_ether
> >> >>> unbind usb_dev_generic 0 usb_ether
> >> >>> or
> >> >>> unbind eth 1
> >> >>>
> >> >>> bind /ocp/omap_dwc3@4838/usb@4839 usb_ether
> >> >>> unbind /ocp/omap_dwc3@4838/usb@4839
> >> >>>
> >> >>> Signed-off-by: Jean-Jacques Hiblot 
> >> >>>
> >> >>> ---
> >> >>>
> >> >>> Changes in v3:
> >> >>> - factorize code based on comments from ML
> >> >>> - remove the devices before unbinding them
> >> >>> - use device_find_global_by_ofnode() to get a device by its node.
> >> >>> - Added tests
> >> >>>
> >> >>> Changes in v2:
> >> >>> - Make the bind/unbind command generic, not specific to usb device.
> >> >>> - Update the API to be able to bind/unbind based on DTS node path
> >> >>> - Add a Kconfig option to select the bind/unbind commands
> >> >>>
> >> >>>  arch/sandbox/dts/test.dts  |  11 ++
> >> >>>  cmd/Kconfig|   9 ++
> >> >>>  cmd/Makefile   |   1 +
> >> >>>  cmd/bind.c | 255 
> >> >>> +
> >> >>>  configs/sandbox_defconfig  |   1 +
> >> >>>  test/py/tests/test_bind.py | 178 +++
> >> >>>  6 files changed, 455 insertions(+)
> >> >>>  create mode 100644 cmd/bind.c
> >> >>>  create mode 100644 test/py/tests/test_bind.py
> >> >
> >> > Reviewed-by: Simon Glass 
> >> >
> >> > Nice work
> >> >
> >> > [...]
> >> >
> >> >>
> >> >> I have tested bind/unbind with dwc3 on zynqmp for ethernet gadget and it
> >> >> is working fine for me.
> >> >> I have also tried to use bind/unbind for gpio zynqmp driver and it is
> >> >> also working fine.
> >> >>
> >> >> It means
> >> >> Tested-by: Michal Simek 
> >> >>
> >> >> I would prefer if these commands are called as dm bind and dm unbind
> >> >> instead of simply bind/unbind which should also fit to dm command
> >> >> description "dm - Driver model low level access".
> >> >
> >> > Yes i can see the point. But after thinking about it, maybe it is best
> >> > as it is? After all driver model is fundamental to U-Boot and it's not
> >> > clear what else we might bind/unbind.
> >> >
> >> > I'd like to get other opinions here, too.
> >>
> >> Tom/Marek: Any opinion?
> >
> > I think dm bind/unbind makes sense, yes.  "bind" and "unbind" are pretty
> > generic terms and making it clear it's part of working "inside" of DM to
> > hook/unhook things by making it a sub-command of dm sounds good.
> > Thanks!
> 
> I agree with Simon here. I think bind and unbind won't have any
> plausible other meaning in U-Boot and DM is core to U-Boot
> functionality in the new world. I think it would be OK to have "dm
> bind" alias to "bind" if that's a point of confusion, but having it
> top-level seems good to me.

They're still very generic words for something that's part of working
under the dm framework.  That said, looking at test/dm/cmd_dm.c and that
it's supposed to be only for test/debug type work, yes, OK, I'll change
my mind.

-- 
Tom


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


Re: [U-Boot] [ANN] U-Boot v2018.07 released

2018-07-10 Thread Wolfgang Denk
Dear Michal,

In message <9ef1c57c-5bf6-4730-6b67-466709cc0...@monstr.eu> you wrote:
>
> > Here the short summary:
>
> Is this generating script somewhere?

It's a clone of Jonathan Corbet's gitdm script; the U-Boot
configuration can be found at [1].

[1] http://git.denx.de/?p=gitdm.git

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Do not follow where the path may leadgo instead where there is no
path and leave a trail.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing

2018-07-10 Thread Marek Vasut
On 07/10/2018 02:10 PM, Jason Rush wrote:
> On 7/9/2018 3:08 AM, Marek Vasut wrote:
>> On 07/07/2018 12:56 AM, Jason Rush wrote:
>>> On 7/5/2018 6:10 PM, Marek Vasut wrote:
 On 07/06/2018 01:11 AM, Jason Rush wrote:
> On 7/4/2018 2:23 AM, Marek Vasut wrote:
>> On 07/04/2018 01:45 AM, Jason Rush wrote:
>>> On 7/3/2018 9:08 AM, Marek Vasut wrote:
 On 07/03/2018 03:58 PM, Jason Rush wrote:
> On 6/29/2018 10:17 AM, Marek Vasut wrote:
>> On 06/29/2018 05:06 PM, Jason Rush wrote:
>>> On 6/29/2018 9:52 AM, Marek Vasut wrote:
 On 06/29/2018 04:44 PM, Jason Rush wrote:
> On 6/29/2018 9:34 AM, Marek Vasut wrote:
>> On 06/29/2018 04:31 PM, Jason Rush wrote:
>>> Dinh,
>> Hi,
>>
>>> A while ago, you posted the following patchset for SoCFPGA to 
>>> add the PL330
>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros 
>>> to SDRAM to
>>> initialize the ECC bits if ECC was enabled:
>>>
>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html
>>>
>>> I know it's been a long time, so I'll summarize some of the 
>>> conversation...
>>>
>>> At the time, you had a problem with the patchset causing the 
>>> SPL to fail to
>>> find the MMC.  You had tracked it down to an issue with the 
>>> following commit
>>> "a78cd8613204 ARM: Rework and correct barrier definitions".  
>>> You and Marek
>>> discussed it a bit, but I don't think there was a real 
>>> conclusion.  You
>>> submitted a second version of the patchset asking for advice on 
>>> debugging
>>> the issue:
>>>
>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html
>>>
>>> No real conversation came from the second patchset, and that 
>>> was the end of
>>> the patch.
>>>
>>> I was hoping we could revisit adding your patchset again. I am 
>>> working on a
>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased 
>>> your patchset
>>> against v2018.05 and it is working on my custom board (although 
>>> I don't have
>>> an MMC). I also tested it on a SoCKit booting from an MMC (I 
>>> forced it to
>>> scrub the SDRAM on the SoCKit, because it doesn't have ECC 
>>> RAM), and the
>>> SoCKit finds the MMC and boots.
>>>
>>> I don't have any suggestions on why it is working now on my 
>>> board and not
>>> back when you first submitted the patchset.  Maybe something 
>>> else was fixed
>>> in the MMC? I was hoping you and Marek could test this patch 
>>> again on some
>>> different SoCFPGA boards to see if you get the same results.
>> Look at this patch
>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b
>>
>> You likely want similar approach, it's faster then the DMA and 
>> much simpler.
>>
> Thanks Marek.  I'll give it a try.  Would you be interested in a 
> similar patch for the Gen 5?
 I don't have any Gen5 board which uses ECC, do you ?
 If so, yes, prepare a patch, it should be very similar.

 Make sure to measure how long it takes to scrub the memory and how 
 much
 memory you have, I'd be interested in the numbers.

>>> Looking at the master branch, it doesn't look like that code is 
>>> ever being called?
>>> The sdram_init_ecc_bits() function is called from the 
>>> ddr_calibration_sequence function(),
>>> but I can't find where ddr_calibration_sequence is called().
>> git grep for it, it's called from somewhere in the 
>> arch/arm/mach-socfpga/
>>
>>> Either way, I can test it. I have a custom Cyclone V board with 
>>> ECC, and the Intel Arria V SoC
>>> Dev Kit I can test it on too which I think has ECC.
>> Please do.
>>
> I implemented a similar memset approach for the gen 5 socfpga.  It's 
> basically the same
> code as in that patch; however, when I performed a single memset the 
> processor would
> reset for some reason.  I changed it to loop over calling memset with 
> a size of 32MB over
> the entire address the address, and that worked as opposed to doing a 
> single memset on
> the RAM.
 Can you do grep MEMSET .config in y

Re: [U-Boot] [PATCH 5/5] arm: dts: socfpga: stratix10: update pdma

2018-07-10 Thread Marek Vasut
On 07/10/2018 03:11 PM, Chee, Tien Fong wrote:
> On Mon, 2018-07-09 at 22:28 +0200, Marek Vasut wrote:
>> On 07/09/2018 08:03 PM, Dinh Nguyen wrote:
>>>
>>>
>>>
>>> On 05/31/2018 03:08 AM, tien.fong.c...@intel.com wrote:

 From: Tien Fong Chee 

 Update pdma properties for Stratix 10

 Signed-off-by: Tien Fong Chee 
 ---
  arch/arm/dts/socfpga_stratix10.dtsi | 20 
  1 file changed, 20 insertions(+)

 diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
 b/arch/arm/dts/socfpga_stratix10.dtsi
 index ccd3f32..311ba09 100644
 --- a/arch/arm/dts/socfpga_stratix10.dtsi
 +++ b/arch/arm/dts/socfpga_stratix10.dtsi
 @@ -82,6 +82,26 @@
    ranges = <0 0 0 0x>;
    u-boot,dm-pre-reloc;
  
 +  amba {
 +  u-boot,dm-pre-reloc;
 +  compatible = "arm,amba-bus";
 +  #address-cells = <1>;
 +  #size-cells = <1>;
 +  ranges;
 +
 +  pdma: pdma@ffda {
 +  u-boot,dm-pre-reloc;
 +  compatible =
 "arm,pl330", "arm,dma330";
>>> I think you got "arm,dma330" binding wrong. I don't see any binding
>>> with
>>> that name.
> Here https://patchwork.ozlabs.org/patch/923234/ .
>> I think the whole idea of using pl330 to scrub ECC DRAM is wrong. It
>> adds massive amount of code while a CPU can do the same and faster,
>> cfr
>> arria10.
>>
> I just measured the performance of initializing DRAM based on custodian
> arria10_sdmmc, which is around 16sec with 1GB.

Then you're doing something very wrong, it should be around 1 second.
See ie. "SoCFPGA PL330 DMA driver and ECC scrubbing" thread

> Using DMA to init the DDR, which is around 3-4sec for 2GB. I attached
> screenshot for the print out based on arria10_sdmmc custodian.

Well sure, if you do it wrong, it'll take longer for the CPU.

-- 
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

2018-07-10 Thread Tom Rini
On Mon, Jul 09, 2018 at 01:53:43PM -0600, Simon Glass wrote:

> Hi Tom.
> 
> Here are some test-coverage and DM core enhancements. Also it adds a
> way to access the binman definition from U-Boot.
> 
> 
> The following changes since commit 8c5d4fd0ec222701598a27b26ab7265d4cee45a3:
> 
>   Prepare v2018.07 (2018-07-09 10:24:14 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git
> 
> for you to fetch changes up to 16b8d6b76992690c65c58dc8b0591496cc5e46ef:
> 
>   binman: Support updating the device tree with calc'd info
> (2018-07-09 09:11:00 -0600)
> 

Applied to u-boot/master, thanks!

That said, I see that this is a non-fatal error:
Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/

Traceback (most recent call last):
  File "/home/trini/work/u-boot/u-boot/tools/buildman/test.py", line 426, in 
testToolchainDownload
self.toolchains.LocateArchUrl('arm'))
AssertionError: 
'https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_arm-unknown-linux-gnueabi.tar.xz'
 != 
'https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_arm-linux-gnueabi.tar.xz'

Which I think we should fix and make a fatal error.  If it's a test and it
fails and it's not fatal, CI/etc won't catch it.  Thanks!

-- 
Tom


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


Re: [U-Boot] spl: Kconfig: SPL_LOAD_FIT_ADDRESS to Kconfig

2018-07-10 Thread Tom Rini
On Thu, Jun 07, 2018 at 01:29:00PM +0100, Ibai Erkiaga wrote:

> Create a new KConfig entry to define FIT image position for
> SPL RAM mode.
> 
> Signed-off-by: Ibai Erkiaga 
> ---
> 
>  Kconfig  | 7 +++
>  common/spl/spl_ram.c | 4 
>  scripts/config_whitelist.txt | 1 -
>  3 files changed, 7 insertions(+), 5 deletions(-)

There's two problems here.  The first, which I fixed quickly, is that
you need to run moveconfig.py too.  The second, which is harder, is that
we first need a new SPL_RAM_LOAD_ADDRESS option added and used in
common/spl/spl_ram.c as that overloads SPL_FIT_LOAD_ADDRESS and uses it
on platforms (such as all of SoCFPA) which do not set SPL_FIT_LOAD /
SPL_FIT_LOAD_ADDRESS.  Thanks!

-- 
Tom


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


Re: [U-Boot] spl: Weed out CONFIG_SYS_TEXT_BASE usage

2018-07-10 Thread Tom Rini
On Thu, May 31, 2018 at 06:02:24PM +0200, Marek Vasut wrote:

> The SPL loaders assume that the CONFIG_SYS_TEXT_BASE memory location
> is available and can be corrupted by loading ie. uImage or fitImage
> headers there. Sometimes it could be beneficial to load the headers
> elsewhere, ie. if CONFIG_SYS_TEXT_BASE is not yet writable while we
> still want to parse the image headers in some local onchip memory to
> ie. extract firmware from that image.
> 
> Add the possibility to override the location where the headers get
> loaded by introducing new function, spl_get_load_buffer() which takes
> two arguments -- offset from the CONFIG_SYS_TEXT_BASE and size of the
> data that are to be loaded there -- and returns a valid buffer address
> or hangs the system. The default behavior is the same as before, add
> the offset to CONFIG_SYS_TEXT_BASE and return that address. User can
> override the weak spl_get_load_buffer() function though.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 

This adds a number of warnings like:
w+(xilinx_zynqmp_zc1275_revA) common/spl/spl.c: In function 
'spl_get_load_buffer':
w+(xilinx_zynqmp_zc1275_revA) common/spl/spl.c:127:9: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
w+(xilinx_zynqmp_zc1275_revA) common/spl/spl_ram.c: In function 
'spl_ram_load_image':
w+(xilinx_zynqmp_zc1275_revA) common/spl/spl_ram.c:66:33: warning: overflow in 
implicit constant conversion [-Woverflow]
 
-- 
Tom


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


Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

2018-07-10 Thread Dr. Philipp Tomsich
> On 10 Jul 2018, at 16:41, Simon Glass  wrote:
> 
> Hi,
> 
> On 8 May 2018 at 04:21, Dr. Philipp Tomsich
>  > wrote:
>> Marty,
>> 
>>> On 8 May 2018, at 02:52, Marty E. Plummer  wrote:
>>> 
>>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
 
> On 7 May 2018, at 04:34, Marty E. Plummer  wrote:
> 
> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>> Hi Marty,
>> 
>> 
>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>> 
>>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
>>> is incorrectly detected as 0 Bytes of ram.
>> 
>> I know the root cause for this issue, and I have a local patch for it.
>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>> before
>> the max size before return with '<<20'. Sorry for forgot to send it out.
>> 
>>> 
>>> Signed-off-by: Marty E. Plummer 
>>> ---
>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>> 
>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>> b/arch/arm/mach-rockchip/sdram_common.c
>>> index 76dbdc8715..a9c9f970a4 100644
>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>> @@ -10,6 +10,8 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> +#include 
>>> 
>>> DECLARE_GLOBAL_DATA_PTR;
>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>>  size_t size_mb = 0;
>>>  u32 ch;
>>> 
>>> - u32 sys_reg = readl(reg);
>>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>>> -& SYS_REG_NUM_CH_MASK);
>>> + if (!size_mb) {
>> 
>> I don't understand this and follow up changes, we don't really need it,
>> isn't it?
>> I think don't need the changes before here.
> Yeah, that was just another level of indentation for the if (!size_mb)
> guard, but I've reworked the patch to not do that as it was pointed out
> that since size_mb is initialized to 0 prior.
>>> + /*
>>> +  * we use the 0x~0xfeff space
>>> +  * since 0xff00~0x is soc register space
>>> +  * so we reserve it
>>> +  */
>>> + size_mb = min(size_mb, 0xff00/SZ_1M);
>> 
>> This is what we really need, as Klaus point out, we need to use
>> SDRAM_MAX_SIZE
>> instead of hard code.
> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> build and boot tested on my hardware.
 
 In that case you just masked the problem but didn???t solve it: assuming 
 size_mb
 is size_t (I???ll assume this is 64bit, but did not check), then your 4GB 
 is 0x1__ )
 which overflows to 0x0 when converted to a u32.
 
 In other words: we need to figure out where the truncation occurs (image 
 what
 happens if a new 32bit processor with LPAE comes out???).
 
>>> A very valid point. With the following patch to sdram_common.c and
>>> sdram_rk3288.c applied I get the debug output that follows it:
>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>> b/arch/arm/mach-rockchip/sdram_common.c
>>> index 232a7fa655..0fe69bf558 100644
>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>> @@ -4,6 +4,7 @@
>>> * SPDX-License-Identifier: GPL-2.0+
>>> */
>>> 
>>> +#define DEBUG 1
>>> #include 
>>> #include 
>>> #include 
>>> @@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>>  SYS_REG_ROW_3_4_MASK;
>>> 
>>>  chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
>>> + debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__, 
>>> chipsize_mb);
>>> 
>>>  if (rank > 1)
>>>  chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
>>>  if (row_3_4)
>>>  chipsize_mb = chipsize_mb * 3 / 4;
>>>  size_mb += chipsize_mb;
>>> + debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
>>>  debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
>>>rank, col, bk, cs0_row, bw, row_3_4);
>>>  }
>>> 
>>> + debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
>>>  size_mb = min(size_mb, SDRAM_MAX_SIZE/SZ_1M);
>>> 
>>>  return (size_t)size_mb << 20;
>>> diff --git a/drivers/ram/rockchip/sdram_rk3288.c 
>>> b/drivers/ram/rockchip/sdram_rk3288.c
>>> index d99bf12476..9738eb088f 100644
>>> --- a/drivers/ram/rockchip/sdram_rk3288.c
>>> +++ b/drivers/ram/rockchip/sdram_rk3288.c
>>> @@ -7,6 +7,7 @@
>>> * Adapted from coreboot.

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

2018-07-10 Thread Stephen Warren

On 07/10/2018 12:47 PM, Tom Rini wrote:

On Mon, Jul 09, 2018 at 01:53:43PM -0600, Simon Glass wrote:


Hi Tom.

Here are some test-coverage and DM core enhancements. Also it adds a
way to access the binman definition from U-Boot.


The following changes since commit 8c5d4fd0ec222701598a27b26ab7265d4cee45a3:

   Prepare v2018.07 (2018-07-09 10:24:14 -0400)

are available in the Git repository at:

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

for you to fetch changes up to 16b8d6b76992690c65c58dc8b0591496cc5e46ef:

   binman: Support updating the device tree with calc'd info
(2018-07-09 09:11:00 -0600)


This pull has caused intermittent/random build errors on my Jenkins 
system. The log shows:



  LD  spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  COPYspl/u-boot-spl.bin
  BINMAN  u-boot-tegra.bin
  BINMAN  u-boot-nodtb-tegra.bin
  BINMAN  u-boot-dtb-tegra.bin
binman: pylibfdt error -9: FDT_ERR_BADMAGIC
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/Makefile:1244:
 recipe for target 'u-boot-tegra.bin' failed
make[1]: *** [u-boot-tegra.bin] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory 
'/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/build/u-boot/beaver'
Makefile:148: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Leaving directory 
'/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot'


This doesn't happen every time; my Jenkins system builds 25 
Tegra/sandbox boards, yet a varying set of boards fail each time I 
trigger the build: Just beaver the first time, then just colibri_t20 and 
ventana, then just medcom-wide. Note that the system performs 
incremental builds, if that matters.

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


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

2018-07-10 Thread Simon Glass
Hi Stephen,

On 10 July 2018 at 13:53, Stephen Warren  wrote:
> On 07/10/2018 12:47 PM, Tom Rini wrote:
>>
>> On Mon, Jul 09, 2018 at 01:53:43PM -0600, Simon Glass wrote:
>>
>>> Hi Tom.
>>>
>>> Here are some test-coverage and DM core enhancements. Also it adds a
>>> way to access the binman definition from U-Boot.
>>>
>>>
>>> The following changes since commit
>>> 8c5d4fd0ec222701598a27b26ab7265d4cee45a3:
>>>
>>>Prepare v2018.07 (2018-07-09 10:24:14 -0400)
>>>
>>> are available in the Git repository at:
>>>
>>>git://git.denx.de/u-boot-dm.git
>>>
>>> for you to fetch changes up to 16b8d6b76992690c65c58dc8b0591496cc5e46ef:
>>>
>>>binman: Support updating the device tree with calc'd info
>>> (2018-07-09 09:11:00 -0600)
>
>
> This pull has caused intermittent/random build errors on my Jenkins system.
> The log shows:
>
>>   LD  spl/u-boot-spl
>>   OBJCOPY spl/u-boot-spl-nodtb.bin
>>   COPYspl/u-boot-spl.bin
>>   BINMAN  u-boot-tegra.bin
>>   BINMAN  u-boot-nodtb-tegra.bin
>>   BINMAN  u-boot-dtb-tegra.bin
>> binman: pylibfdt error -9: FDT_ERR_BADMAGIC
>>
>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/Makefile:1244:
>> recipe for target 'u-boot-tegra.bin' failed
>> make[1]: *** [u-boot-tegra.bin] Error 1
>> make[1]: *** Waiting for unfinished jobs
>> make[1]: Leaving directory
>> '/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/build/u-boot/beaver'
>> Makefile:148: recipe for target 'sub-make' failed
>> make: *** [sub-make] Error 2
>> make: Leaving directory
>> '/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot'
>
>
> This doesn't happen every time; my Jenkins system builds 25 Tegra/sandbox
> boards, yet a varying set of boards fail each time I trigger the build: Just
> beaver the first time, then just colibri_t20 and ventana, then just
> medcom-wide. Note that the system performs incremental builds, if that
> matters.

That might be the fdt_resize() problem which David Gibson has just
sorted out upstream. If you can run binman -D (to get a stack trace)
that might help. I should be able to do a patch if that is the
problem.

That said, I'm working on getting the real pylibffdt applied upstream,
hopefully will not be too much longer.

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


[U-Boot] raspberrypi compute module3 emmc not usable

2018-07-10 Thread Belisko Marek
Hello,

I'm trying to use u-boot on CM3 (which contains eMMC) to boot kernel.
I'm using u-boot 2018.05 and it can start fine like:
U-Boot 2018.05 (Jul 10 2018 - 20:32:05 +)

DRAM:  948 MiB
RPI Compute Module 3 (0xa220a0)
MMC:   sdhci@7e30: 0
Loading Environment from FAT... unable to select a mode
** No partition table - mmc 0 **
Failed (-5)
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot>
U-Boot>
U-Boot>
U-Boot> mmc info
Device: sdhci@7e30
Manufacturer ID: 15
OEM: 100
Name: 4FPD3
Bus Speed: 5200
Mode : MMC legacy
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 1-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 512 KiB ENH
U-Boot> mmc part
## Unknown partition table type 0
U-Boot> mmc read $loadaddr 0 2

but reading from eMMC fails with:

MMC read: dev # 0, block # 0, count 2 ... 0 blocks read: ERROR

so it looks like eMMC is not properly working with CM3 in this
version? Any ideas what to check to have it working before I dig to
debugging session ;). Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] sandbox: Don't disable ctrlc() on sandbox if in raw mode

2018-07-10 Thread Simon Glass
Hi Joe,

On 9 July 2018 at 13:26, Joe Hershberger  wrote:
> On Sun, Jul 8, 2018 at 9:39 PM, Simon Glass  wrote:
>> Hi Joe,
>>
>> On 2 July 2018 at 18:06, Joe Hershberger  wrote:
>>> In raw mode, handle ctrl-c as normal. This allows normal ctrl-c behavior
>>> such as aborting a command that is timing out without completely
>>> terminating the sandbox executable.
>>>
>>> In [1], Simon disabled this.  His reason for it was that it interferes
>>> with piping test scripts. Piping should be done in cooked mode, so this
>>> change should still not interfere.
>>>
>>> [1] commit 8969ea3e9f2db04a6b3675 ("sandbox: Disable Ctrl-C")
>>>
>>> Signed-off-by: Joe Hershberger 
>>>
>>> ---
>>>
>>>  common/console.c | 2 --
>>>  drivers/serial/sandbox.c | 3 +++
>>>  2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> It is designed so that ctrl-C exits in raw mode. That is the normal
>> behaviour for an application and I don't think sandbox should be any
>> different.
>>
>> How about using cooked mode instead?
>
> That seems backward. Only in raw mode (STATE_TERM_RAW) is the console
> not interfering with keyboard inputs and changing behaviors based on
> interpreting control codes. In raw mode, U-Boot sandbox can handle
> things the way it does in real hardware.
>
> To be clear, this is not the default case (STATE_TERM_RAW_WITH_SIGS)
> where ctrl-C exits. In fully raw mode (STATE_TERM_RAW), ctrl-C does
> absolutely nothing without this patch.
>
> Also, if cooked mode were used, it would once again break the test
> script piping that your previous commit talked about. I'm not sure
> exactly what that applies to (would it affect Travis such that I can
> validate interference?) so I'm not sure I've tested that use-case
> effectively.

Er yes, sorry, I mean raw mode. I misunderstood your commit message I think.

Reviewed-by: Simon Glass 

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


Re: [U-Boot] [PATCH v2 5/8] usb: rockchip: implement K_FW_LBA_ERASE_10 command

2018-07-10 Thread Simon Glass
On 4 July 2018 at 12:47, Alberto Panizzo  wrote:
> This command is part of the write partition sequence performed by
> rkdeveloptool: one partition is first completely erased and
> than wrote.
>
> Signed-off-by: Alberto Panizzo 
> ---
>  arch/arm/include/asm/arch-rockchip/f_rockusb.h |  1 +
>  doc/README.rockusb |  1 +
>  drivers/usb/gadget/f_rockusb.c | 46 
> ++
>  3 files changed, 48 insertions(+)

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


Re: [U-Boot] [PATCH v2 7/8] usb: rockchip: boost up write speed from 4MB/s to 15MB/s

2018-07-10 Thread Simon Glass
On 4 July 2018 at 12:47, Alberto Panizzo  wrote:
> Speedup transfers increasing the max chunk size.
> Buffers are allocated with memalign thus developer is noticed when heap is
> full and in current configuration a buffer allocation of 64K till now
> is safe.
>
> Signed-off-by: Alberto Panizzo 
> ---
>  arch/arm/include/asm/arch-rockchip/f_rockusb.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v2 1/2] rtc: pl031: convert the driver to driver model

2018-07-10 Thread Simon Glass
Hi,

On 8 July 2018 at 18:50, AKASHI Takahiro  wrote:
> On Thu, Jul 05, 2018 at 04:12:59PM +0900, AKASHI Takahiro wrote:
>> On Wed, Jul 04, 2018 at 02:35:19PM +0300, Tuomas Tynkkynen wrote:
>> > Hi Akashi,
>> >
>> > Thank you for the DM conversion.
>> >
>> > On 07/04/2018 10:36 AM, AKASHI Takahiro wrote:
>> > <..snip..>
>> > >diff --git a/include/dm/platform_data/rtc_pl031.h 
>> > >b/include/dm/platform_data/rtc_pl031.h
>> > >new file mode 100644
>> > >index 00..8e4ba1ce69
>> > >--- /dev/null
>> > >+++ b/include/dm/platform_data/rtc_pl031.h
>> > >@@ -0,0 +1,12 @@
>> > >+/* SPDX-License-Identifier: GPL-2.0+ */
>> > >+
>> > >+#ifndef __rtc_pl031_h
>> > >+#define __rtc_pl031_h
>> > >+
>> > >+#include 
>> > >+
>> > >+struct pl031_rtc_platdata {
>> > >+  phys_addr_t base;
>> > >+};
>> > >+
>> > >+#endif
>> > >
>> >
>> > I think this file won't be necessary, the structure can stay private to 
>> > pl031.c.
>> > PL031 is an ARM IP block and U-Boot on ARM uses the device tree to locate 
>> > devices.
>>
>> I think that you are suggesting we would use udevice.priv instead of
>> udevice.platdata, right? That will be fine with device-tree based devices.
>> But don't we have to take care of no-device-tree (probably legacy)
>> devices here?
>
> Does anybody have a comment on this?
> I will be able to go either with priv or platdata once agreed.

There is no need to support legacy (non-DM) options unless there is a
board that doesn't build without it. Even then, the hour is late and
DM conversions should be well underway, so just removing that driver
from the board is probably acceptable until the maintainer gets around
to it.

You should really use platdata to hold info read from the device tree,
so to me what you have looks correct, except that I think the struct
can be private to your driver.

Instead of devfdt_get_addr(), please use dev_read_addr() which is the
livetree version.

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


Re: [U-Boot] [PATCH] sysreset: syscon: update regmap access to syscon

2018-07-10 Thread Simon Glass
Hi Patrick,

On 9 July 2018 at 06:59, Patrick Delaunay  wrote:
> Use new API syscon_node_to_regmap in sysreset_syscon driver
> for compatible "syscon-reboot"; that's avoid the need of explicit
> syscon binding for "regmap" handle.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  drivers/sysreset/sysreset_syscon.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/sysreset/sysreset_syscon.c 
> b/drivers/sysreset/sysreset_syscon.c
> index f19e80e..3450640 100644
> --- a/drivers/sysreset/sysreset_syscon.c
> +++ b/drivers/sysreset/sysreset_syscon.c
> @@ -35,18 +35,20 @@ static struct sysreset_ops syscon_reboot_ops = {
>
>  int syscon_reboot_probe(struct udevice *dev)
>  {
> -   struct udevice *syscon;
> struct syscon_reboot_priv *priv = dev_get_priv(dev);
> int err;
> +   u32 phandle;
> +   ofnode node;
>
> -   err = uclass_get_device_by_phandle(UCLASS_SYSCON, dev,
> -  "regmap", &syscon);
> -   if (err) {
> -   pr_err("unable to find syscon device\n");
> +   err = ofnode_read_u32(dev_ofnode(dev), "regmap", &phandle);
> +   if (err)
> return err;
> -   }
>
> -   priv->regmap = syscon_get_regmap(syscon);
> +   node = ofnode_get_by_phandle(phandle);
> +   if (!ofnode_valid(node))
> +   return -EINVAL;
> +
> +   priv->regmap = syscon_node_to_regmap(node);
> if (!priv->regmap) {
> pr_err("unable to find regmap\n");
> return -ENODEV;

Aren't you just re-implementing uclass_get_device_by_phandle() here?

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


Re: [U-Boot] [RFC 5/8] clk: Add generic_clk_valid

2018-07-10 Thread Simon Glass
On 9 July 2018 at 12:30, Jagan Teki  wrote:
> Add clock validate function for validating
> specific clock to do further clock operations.
>
> Signed-off-by: Jagan Teki 
> ---
>  include/clk-uclass.h | 10 ++
>  1 file changed, 10 insertions(+)

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


Re: [U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save()

2018-07-10 Thread Simon Glass
Hi Nicholas,

On 10 July 2018 at 06:57, Nicholas Faustini
 wrote:
> When called with ENVOP_SAVE, env_get_location() only returns the
> gd->env_load_location variable without actually checking for
> the environment location and priority. This allows saving the
> environment into the same location that has been previously loaded.
>
> This behaviour causes env_save() to fall into an infinite loop when
> the low-level drv->save() call fails.

Why is this? Should it not stop eventually? Do we need a limit on prio?

>
> The env_save() function should not loop through the environment
> location list but it should use the previously discovered
> environment driver once.

What is that? It should be possible to write the env to multiple
places. Also what is the previously discovered environment?

>
> Signed-off-by: Nicholas Faustini 
> ---
>
>  env/env.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/env/env.c b/env/env.c
> index 5c0842a..897d197 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -211,16 +211,16 @@ int env_load(void)
>  int env_save(void)
>  {
> struct env_driver *drv;
> -   int prio;
>
> -   for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE, prio)); prio++) {
> +   drv = env_driver_lookup(ENVOP_SAVE, 0);
> +   if (drv) {
> int ret;
>
> if (!drv->save)
> -   continue;
> +   return -ENODEV;
>
> if (!env_has_inited(drv->location))
> -   continue;
> +   return -ENODEV;
>
> printf("Saving Environment to %s... ", drv->name);
> ret = drv->save();
> --
> 2.7.4
>

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


Re: [U-Boot] [PATCH] test: Add ut_assertnull macro

2018-07-10 Thread Simon Glass
On 21 June 2018 at 08:47, Ramon Fried  wrote:
> Add ut_assertnull macro to include/test/ut.h
> For testing of functions that returns NULL on errors.
>
> Signed-off-by: Ramon Fried 
> ---
>  include/test/ut.h | 12 
>  1 file changed, 12 insertions(+)
>

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


Re: [U-Boot] [PULL] efi patch queue 2018-07-10

2018-07-10 Thread Tom Rini
On Tue, Jul 10, 2018 at 06:06:56PM +0200, Alexander Graf wrote:

> Hi Tom,
> 
> This is my current patch queue for efi.  Please pull.
> 
> Alex
> 
> 
> The following changes since commit 495c70f9dfad1a5428ec84b52e8667ea4760ecd6:
> 
>   net: designware: Add reset ctrl to driver (2018-07-09 15:28:28 -0400)
> 
> are available in the git repository at:
> 
>   git://github.com/agraf/u-boot.git tags/signed-efi-next
> 
> for you to fetch changes up to e2c6ec921b5a37ac96aba34731c972dfee9943b0:
> 
>   MAINTAINERS: assign lib/charset.c (2018-07-10 18:01:08 +0200)
> 

NAK, this totally breaks qemu-x86_64:
Building current source for 1 boards (1 thread, 16 jobs per thread)
100 /1  qemu-x86_64
+u-boot-test-flash qemu-x86_64 na
= test session starts 
=
platform linux2 -- Python 2.7.12, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
rootdir: /, inifile:
collected 127 items
+u-boot-test-reset qemu-x86_64 na
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]

U-Boot SPL 2018.07-00106-gdbe7256f0d42 (Jul 10 2018 - 16:54:23 -0400)
CPU: x86_64, vendor AMD, device 663h
Trying to boot from SPI
Jumping to 64-bit U-Boot: Note many features are missing
 No serial driver found
^C
!! KeyboardInterrupt 
!!
/home/trini/work/u-boot/u-boot/test/py/u_boot_spawn.py:171: KeyboardInterrupt
== 4 tests deselected by '-knot sleep and not efi_selftest' 
===
=== 4 deselected, 1 pytest-warnings in 4.93 seconds 
===


-- 
Tom


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


Re: [U-Boot] [PATCH v2 0/8] test/py: Fixes for python 3.x

2018-07-10 Thread Simon Glass
Hi Paul,

On 14 September 2017 at 15:34, Paul Burton  wrote:
> This series allows test/py to run on python 3.x in addition to the
> already supported python 2.x. With it applied I currently see only one
> failure (test_ut[ut_dm_usb_flash]) which doesn't appear to be python
> related when running with:
>
> $ ./test/py/test.py --bd sandbox --build
>
> Thanks,
> Paul
>
> Paul Burton (8):
>   test/py: Make print statements python 3.x safe
>   test/py: Use range() rather than xrange()
>   test/py: Import 'configparser' lower case to be python 3.x safe
>   test/py: Import StringIO from io module for python 3.x
>   test/py: Encode/decode strings for stdio
>   test/py: fit: Open files as binary files
>   test/py: hush_if_test: Use open() in place of file()
>   test/py: vboot: Remove stderr redirect from openssl command
>
>  test/py/conftest.py| 18 +-
>  test/py/multiplexed_log.py |  4 ++--
>  test/py/test.py|  6 --
>  test/py/tests/test_fit.py  | 14 --
>  test/py/tests/test_hush_if_test.py |  2 +-
>  test/py/tests/test_ut.py   |  2 +-
>  test/py/tests/test_vboot.py|  4 ++--
>  test/py/u_boot_console_sandbox.py  |  4 ++--
>  test/py/u_boot_spawn.py| 12 ++--
>  test/py/u_boot_utils.py|  4 ++--
>  10 files changed, 41 insertions(+), 29 deletions(-)
>
> --
> 2.14.1
>

I never did see a v3 of this but I would like to get these patches applied.

I'll apply the ones that seem cause no problems. If you have time,
please respin these ones:

>   test/py: Import StringIO from io module for python 3.x
>   test/py: Encode/decode strings for stdio

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


Re: [U-Boot] [PATCH v2 1/8] test/py: Make print statements python 3.x safe

2018-07-10 Thread Simon Glass
On 14 September 2017 at 15:34, Paul Burton  wrote:
> In python 3.x print must be called as a function rather than used as a
> statement. Update uses of print to the function call syntax in order to
> be python 3.x safe.
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Stephen Warren 
> ---
>
> Changes in v2: None
>
>  test/py/conftest.py   |  2 +-
>  test/py/test.py   |  6 --
>  test/py/tests/test_fit.py | 12 +++-
>  test/py/u_boot_console_sandbox.py |  2 +-
>  test/py/u_boot_spawn.py   |  2 +-
>  5 files changed, 14 insertions(+), 10 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 v2 6/8] test/py: fit: Open files as binary files

2018-07-10 Thread Simon Glass
On 14 September 2017 at 15:34, Paul Burton  wrote:
> The read_file() function in test_fit is used with files that are not
> text files, as well as some that are. It is never used in a way that
> requires it to decode text files to characters, so open all files in
> binary mode such that read() doesn't attempt to decode characters for
> files which are not text files.
>
> Without this test_fit fails on python 3.x when reading an FDT in
> run_fit_test() with:
>
>   UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd0 in position
>0: invalid continuation byte
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Stephen Warren 
> ---
>
> Changes in v2: None
>
>  test/py/tests/test_fit.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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 v2 7/8] test/py: hush_if_test: Use open() in place of file()

2018-07-10 Thread Simon Glass
On 14 September 2017 at 15:34, Paul Burton  wrote:
> In python 3.x the file() function has been removed. Use open() instead,
> which works on both python 2.x & 3.x, and is described as the preferred
> method of opening a file by python 2.x documentation anyway.
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Stephen Warren 
> ---
>
> Changes in v2: None
>
>  test/py/tests/test_hush_if_test.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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 v2 8/8] test/py: vboot: Remove stderr redirect from openssl command

2018-07-10 Thread Simon Glass
On 14 September 2017 at 15:34, Paul Burton  wrote:
> The openssl command specified in test_with_algo() ultimately ends up
> being run by RunAndLog::run(), which uses it to construct a Popen object
> with the default shell=False. The stderr redirect in the command is
> therefore simply passed to openssl as an argument. With at least openssl
> 1.1.0f this causes openssl, and therefore test_vboot, to fail with:
>
>   genpkey: Use -help for summary.
>   Exit code: 1
>
> Any stderr output ought to be captured & stored in the RunAndLog
> object's output field and returned from run() via run_and_log() to
> test_with_algo() which then ignores it anyway, so we can drop the
> shell-like redirection with no ill effects. With this fix test_vboot now
> passes for me.
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Stephen Warren 
>
> ---
>
> Changes in v2:
> - Place the % operator at the end of the last string line, not the start of 
> the next.
>
>  test/py/tests/test_vboot.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 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 v2 3/8] test/py: Import 'configparser' lower case to be python 3.x safe

2018-07-10 Thread Simon Glass
On 14 September 2017 at 15:34, Paul Burton  wrote:
> In python 3.x the configparser module is named with all lower case.
> Import it as such in order to avoid errors when running on python 3.x,
> and fall back to the CamelCase version in order to keep working with
> python 2.x.
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Stephen Warren 
>
> ---
>
> Changes in v2:
> - Import python 2.x ConfigParser as the python 3.x style configparser, rather 
> than the other way around.
>
>  test/py/conftest.py | 8 ++--
>  1 file changed, 6 insertions(+), 2 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 v2 2/8] test/py: Use range() rather than xrange()

2018-07-10 Thread Simon Glass
On 14 September 2017 at 15:34, Paul Burton  wrote:
> In python 3.x the xrange() function has been removed, and range()
> returns an iterator much like Python 2.x's xrange(). Simply use range()
> in place of xrange() in order to work on both python 2.x & 3.x. This
> will mean a small cost on python 2.x since range() will return a list
> there rather than an iterator, but the cost should be negligible.
>
> Signed-off-by: Paul Burton 
> Reviewed-by: Stephen Warren 
> ---
>
> Changes in v2: None
>
>  test/py/u_boot_console_sandbox.py | 2 +-
>  test/py/u_boot_spawn.py   | 6 +++---
>  test/py/u_boot_utils.py   | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)

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


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

2018-07-10 Thread Simon Glass
Hi Tom,

Here are some Python 3 fixes as mentioned on irc. I've left out the
two which cause problems.

Travis run is here:

https://travis-ci.org/sglass68/u-boot/builds/402281566


The following changes since commit e3396ffd720877976141fa0b76a0b8ee9643d7d1:

  Merge git://git.denx.de/u-boot-dm (2018-07-10 10:29:14 -0400)

are available in the Git repository at:

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

for you to fetch changes up to 8793631ec13ee9e6c7189a7bdca38dde7b4390a8:

  test/py: vboot: Remove stderr redirect from openssl command
(2018-07-10 14:50:50 -0600)


Paul Burton (6):
  test/py: Make print statements python 3.x safe
  test/py: Use range() rather than xrange()
  test/py: Import 'configparser' lower case to be python 3.x safe
  test/py: fit: Open files as binary files
  test/py: hush_if_test: Use open() in place of file()
  test/py: vboot: Remove stderr redirect from openssl command

 test/py/conftest.py| 10 +++---
 test/py/test.py|  6 --
 test/py/tests/test_fit.py  | 14 --
 test/py/tests/test_hush_if_test.py |  2 +-
 test/py/tests/test_vboot.py|  4 ++--
 test/py/u_boot_console_sandbox.py  |  4 ++--
 test/py/u_boot_spawn.py|  8 
 test/py/u_boot_utils.py|  4 ++--
 8 files changed, 30 insertions(+), 22 deletions(-)

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


Re: [U-Boot] [PULL] efi patch queue 2018-07-10

2018-07-10 Thread Alexander Graf


On 10.07.18 22:55, Tom Rini wrote:
> On Tue, Jul 10, 2018 at 06:06:56PM +0200, Alexander Graf wrote:
> 
>> Hi Tom,
>>
>> This is my current patch queue for efi.  Please pull.
>>
>> Alex
>>
>>
>> The following changes since commit 495c70f9dfad1a5428ec84b52e8667ea4760ecd6:
>>
>>   net: designware: Add reset ctrl to driver (2018-07-09 15:28:28 -0400)
>>
>> are available in the git repository at:
>>
>>   git://github.com/agraf/u-boot.git tags/signed-efi-next
>>
>> for you to fetch changes up to e2c6ec921b5a37ac96aba34731c972dfee9943b0:
>>
>>   MAINTAINERS: assign lib/charset.c (2018-07-10 18:01:08 +0200)
>>
> 
> NAK, this totally breaks qemu-x86_64:
> Building current source for 1 boards (1 thread, 16 jobs per thread)
> 100 /1  qemu-x86_64
> +u-boot-test-flash qemu-x86_64 na
> = test session starts 
> =
> platform linux2 -- Python 2.7.12, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
> rootdir: /, inifile:
> collected 127 items
> +u-boot-test-reset qemu-x86_64 na
> warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
> 
> U-Boot SPL 2018.07-00106-gdbe7256f0d42 (Jul 10 2018 - 16:54:23 -0400)
> CPU: x86_64, vendor AMD, device 663h
> Trying to boot from SPI
> Jumping to 64-bit U-Boot: Note many features are missing
>  No serial driver found
> ^C

That was the breakage that I reported to Bin earlier as well. Let me
bisect ...


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


Re: [U-Boot] [PATCH] armv8: layerscape: Enable EHCI access for LS1012A

2018-07-10 Thread York Sun
On 07/02/2018 10:34 PM, Ran Wang wrote:
> Program Central Security Unit (CSU) to grant access
> permission for USB 2.0 controller, otherwiase EHCI funciton will down.
> 
> Signed-off-by: Ran Wang 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c  | 8 
>  arch/arm/include/asm/arch-fsl-layerscape/ns_access.h | 1 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 6a56269..2c4cf7f 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #ifdef CONFIG_LAYERSCAPE_NS_ACCESS
>  #include 
>  #endif
> @@ -668,6 +669,13 @@ void fsl_lsch2_early_init_f(void)
>CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN);
>   }
>  
> + /*
> +  * Program Central Security Unit (CSU) to grant access
> +  * permission for USB 2.0 controller
> +  */
> +#if defined(CONFIG_ARCH_LS1012A) && defined(CONFIG_USB_EHCI_FSL)
> + set_devices_ns_access(CSU_CSLX_USB_2, CSU_ALL_RW);
> +#endif

Is this LS1012A specific?

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


Re: [U-Boot] [PULL] efi patch queue 2018-07-10

2018-07-10 Thread Alexander Graf


On 10.07.18 23:04, Alexander Graf wrote:
> 
> 
> On 10.07.18 22:55, Tom Rini wrote:
>> On Tue, Jul 10, 2018 at 06:06:56PM +0200, Alexander Graf wrote:
>>
>>> Hi Tom,
>>>
>>> This is my current patch queue for efi.  Please pull.
>>>
>>> Alex
>>>
>>>
>>> The following changes since commit 495c70f9dfad1a5428ec84b52e8667ea4760ecd6:
>>>
>>>   net: designware: Add reset ctrl to driver (2018-07-09 15:28:28 -0400)
>>>
>>> are available in the git repository at:
>>>
>>>   git://github.com/agraf/u-boot.git tags/signed-efi-next
>>>
>>> for you to fetch changes up to e2c6ec921b5a37ac96aba34731c972dfee9943b0:
>>>
>>>   MAINTAINERS: assign lib/charset.c (2018-07-10 18:01:08 +0200)
>>>
>>
>> NAK, this totally breaks qemu-x86_64:
>> Building current source for 1 boards (1 thread, 16 jobs per thread)
>> 100 /1  qemu-x86_64
>> +u-boot-test-flash qemu-x86_64 na
>> = test session starts 
>> =
>> platform linux2 -- Python 2.7.12, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
>> rootdir: /, inifile:
>> collected 127 items
>> +u-boot-test-reset qemu-x86_64 na
>> warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
>>
>> U-Boot SPL 2018.07-00106-gdbe7256f0d42 (Jul 10 2018 - 16:54:23 -0400)
>> CPU: x86_64, vendor AMD, device 663h
>> Trying to boot from SPI
>> Jumping to 64-bit U-Boot: Note many features are missing
>>  No serial driver found
>> ^C
> 
> That was the breakage that I reported to Bin earlier as well. Let me
> bisect ...

I think I have an idea ;)

ab1340bf15c9ad7d1a7edbe51ec93c45e11c5c2c is the first bad commit
commit ab1340bf15c9ad7d1a7edbe51ec93c45e11c5c2c
Author: Alexander Graf 
Date:   Tue Jun 12 07:48:37 2018 +0200

efi_loader: Rename sections to allow for implicit data

Some times gcc may generate data that is then used within code that may
be part of an efi runtime section. That data could be jump tables,
constants or strings.

In order to make sure we catch these, we need to ensure that gcc emits
them into a section that we can relocate together with all the other
efi runtime bits. This only works if the -ffunction-sections and
-fdata-sections flags are passed and the efi runtime functions are
in a section that starts with ".text".

Up to now we had all efi runtime bits in sections that did not
interfere with the normal section naming scheme, but this forces
us to do so. Hence we need to move the efi_loader text/data/rodata
sections before the global *(.text*) catch-all section.

With this patch in place, we should hopefully have an easier time
to extend the efi runtime functionality in the future.

Signed-off-by: Alexander Graf 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 7/7] armv8: ls1046a: setup fman ports ICIDs and device tree

2018-07-10 Thread York Sun
On 07/09/2018 05:26 AM, Bharat Bhushan wrote:



>> @@ -74,7 +79,12 @@ void fdt_fixup_icid(void *blob);
>>  CONFIG_SYS_FSL_BMAN_ADDR, \
>>  CONFIG_SYS_FSL_BMAN_ADDR)
>>
>> +#define SET_FMAN_ICID_ENTRY(_port_id, _icid) \
>> +{ .port_id = (_port_id), .icid = (_icid) }
> 
> Same comment as in 6/7 patch applies here also, use "streamed" or "icid" 
> consistent with h/w or devicetree.
> 

Guys,

The discussion is healthy. Please trim the quoted messages to keep only
relevant context to make the comments easy to read. Thanks.

York


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


Re: [U-Boot] [PATCH 1/2 v2] board: freescale: ls1012afrx:Common files to support

2018-07-10 Thread York Sun
On 06/06/2018 04:16 AM, Pramod Kumar wrote:
> LS1012A-FRDM and LS1012A-FRWY board.
> 
> 1-Move all common files applicable for both boards LS1012A-FRDM
>   and LS1012A-FRWY into board directory ls1012afrx.
> 2-Restructure LS1012A-FRDM code. Only board specific files are
>   in LS1012A-FRDM board directory.
> 
> Signed-off-by: Pramod Kumar 
> ---
> Depends on:
> http://patchwork.ozlabs.org/patch/918935/
> http://patchwork.ozlabs.org/patch/918933/
> http://patchwork.ozlabs.org/patch/918932/
> 
> Changes for v2:
>  - Rebased patch to above dependency patches 
> 
>  arch/arm/Kconfig   |  2 +
>  board/freescale/ls1012afrdm/Kconfig| 60 
> --
>  board/freescale/ls1012afrdm/MAINTAINERS| 12 +
>  board/freescale/ls1012afrdm/Makefile   |  4 +-
>  board/freescale/ls1012afrx/Kconfig | 27 ++
>  board/freescale/{ls1012afrdm => ls1012afrx}/eth.c  |  0
>  .../ls1012afrdm.c => ls1012afrx/ls1012afrx.c}  |  0
>  7 files changed, 32 insertions(+), 73 deletions(-)
>  create mode 100644 board/freescale/ls1012afrx/Kconfig
>  rename board/freescale/{ls1012afrdm => ls1012afrx}/eth.c (100%)
>  rename board/freescale/{ls1012afrdm/ls1012afrdm.c => 
> ls1012afrx/ls1012afrx.c} (100%)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 22234cd..190 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1417,6 +1417,8 @@ source "board/freescale/ls1046ardb/Kconfig"
>  source "board/freescale/ls1012aqds/Kconfig"
>  source "board/freescale/ls1012ardb/Kconfig"
>  source "board/freescale/ls1012afrdm/Kconfig"
> +source "board/freescale/ls1012afrx/Kconfig"
> +source "board/freescale/ls1012afrwy/Kconfig"
>  source "board/freescale/mx35pdk/Kconfig"
>  source "board/freescale/s32v234evb/Kconfig"
>  source "board/gdsys/a38x/Kconfig"
> diff --git a/board/freescale/ls1012afrdm/Kconfig 
> b/board/freescale/ls1012afrdm/Kconfig
> index f52a896..58e592d 100644
> --- a/board/freescale/ls1012afrdm/Kconfig
> +++ b/board/freescale/ls1012afrdm/Kconfig
> @@ -21,63 +21,3 @@ config SYS_LS_PPA_FW_ADDR
>   default 0x4040
>  
>  endif
> -
> -if FSL_PFE
> -
> -config BOARD_SPECIFIC_OPTIONS # dummy
> - def_bool y
> - select PHYLIB
> - imply PHY_REALTEK
> - imply PHY_ATHEROS
> -
> -config DDR_PFE_PHYS_BASEADDR
> - hex "PFE DDR physical base address"
> - default 0x0380
> -
> -config DDR_PFE_BASEADDR
> - hex "PFE DDR base address"
> - default 0x8380
> -
> -config PFE_EMAC1_PHY_ADDR
> - hex "PFE DDR base address"
> - default 0x2
> -
> -config PFE_EMAC2_PHY_ADDR
> - hex "PFE DDR base address"
> - default 0x1
> -
> -endif
> -
> -if TARGET_LS1012AFRWY
> -
> -config SYS_BOARD
> - default "ls1012afrdm"
> -
> -config SYS_VENDOR
> - default "freescale"
> -
> -config SYS_SOC
> - default "fsl-layerscape"
> -
> -config SYS_CONFIG_NAME
> - default "ls1012afrwy"
> -
> -config SYS_LS_PFE_FW_ADDR
> - hex "Flash address of PFE firmware"
> - default 0x4002
> -
> -config SYS_LS_PPA_FW_ADDR
> - hex "PPA Firmware Addr"
> - default 0x4006
> -
> -config SYS_LS_PPA_ESBC_ADDR
> - hex "PPA Firmware HDR Addr"
> - default 0x401f4000
> -
> -config SYS_LS_PFE_ESBC_ADDR
> - hex "PFE Firmware HDR Addr"
> - default 0x401f8000
> -
> -endif
> -
> -source "board/freescale/common/Kconfig"

Why do you remove this file, but only add it for ls1012afrx below?
Doesn't ls1012afrdm use the same common file?

Please rebase before sending another version.

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


Re: [U-Boot] spl: Weed out CONFIG_SYS_TEXT_BASE usage

2018-07-10 Thread Marek Vasut
On 07/10/2018 08:47 PM, Tom Rini wrote:
> On Thu, May 31, 2018 at 06:02:24PM +0200, Marek Vasut wrote:
> 
>> The SPL loaders assume that the CONFIG_SYS_TEXT_BASE memory location
>> is available and can be corrupted by loading ie. uImage or fitImage
>> headers there. Sometimes it could be beneficial to load the headers
>> elsewhere, ie. if CONFIG_SYS_TEXT_BASE is not yet writable while we
>> still want to parse the image headers in some local onchip memory to
>> ie. extract firmware from that image.
>>
>> Add the possibility to override the location where the headers get
>> loaded by introducing new function, spl_get_load_buffer() which takes
>> two arguments -- offset from the CONFIG_SYS_TEXT_BASE and size of the
>> data that are to be loaded there -- and returns a valid buffer address
>> or hangs the system. The default behavior is the same as before, add
>> the offset to CONFIG_SYS_TEXT_BASE and return that address. User can
>> override the weak spl_get_load_buffer() function though.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Tom Rini 
> 
> This adds a number of warnings like:
> w+(xilinx_zynqmp_zc1275_revA) common/spl/spl.c: In function 
> 'spl_get_load_buffer':
> w+(xilinx_zynqmp_zc1275_revA) common/spl/spl.c:127:9: warning: cast to 
> pointer from integer of different size [-Wint-to-pointer-cast]
> w+(xilinx_zynqmp_zc1275_revA) common/spl/spl_ram.c: In function 
> 'spl_ram_load_image':
> w+(xilinx_zynqmp_zc1275_revA) common/spl/spl_ram.c:66:33: warning: overflow 
> in implicit constant conversion [-Woverflow]

Well, yes, since that board didn't exist when I sent this patch over a
month ago.

But I'd rather like some feedback on this patch itself.

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


Re: [U-Boot] spl: Weed out CONFIG_SYS_TEXT_BASE usage

2018-07-10 Thread Tom Rini
On Tue, Jul 10, 2018 at 09:33:11PM +0200, Marek Vasut wrote:
> On 07/10/2018 08:47 PM, Tom Rini wrote:
> > On Thu, May 31, 2018 at 06:02:24PM +0200, Marek Vasut wrote:
> > 
> >> The SPL loaders assume that the CONFIG_SYS_TEXT_BASE memory location
> >> is available and can be corrupted by loading ie. uImage or fitImage
> >> headers there. Sometimes it could be beneficial to load the headers
> >> elsewhere, ie. if CONFIG_SYS_TEXT_BASE is not yet writable while we
> >> still want to parse the image headers in some local onchip memory to
> >> ie. extract firmware from that image.
> >>
> >> Add the possibility to override the location where the headers get
> >> loaded by introducing new function, spl_get_load_buffer() which takes
> >> two arguments -- offset from the CONFIG_SYS_TEXT_BASE and size of the
> >> data that are to be loaded there -- and returns a valid buffer address
> >> or hangs the system. The default behavior is the same as before, add
> >> the offset to CONFIG_SYS_TEXT_BASE and return that address. User can
> >> override the weak spl_get_load_buffer() function though.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Tom Rini 
> > 
> > This adds a number of warnings like:
> > w+(xilinx_zynqmp_zc1275_revA) common/spl/spl.c: In function 
> > 'spl_get_load_buffer':
> > w+(xilinx_zynqmp_zc1275_revA) common/spl/spl.c:127:9: warning: cast to 
> > pointer from integer of different size [-Wint-to-pointer-cast]
> > w+(xilinx_zynqmp_zc1275_revA) common/spl/spl_ram.c: In function 
> > 'spl_ram_load_image':
> > w+(xilinx_zynqmp_zc1275_revA) common/spl/spl_ram.c:66:33: warning: overflow 
> > in implicit constant conversion [-Woverflow]
> 
> Well, yes, since that board didn't exist when I sent this patch over a
> month ago.
> 
> But I'd rather like some feedback on this patch itself.

Well, I was going to push it to master, but I can't because it
introduces warnings now and that board has existed since April, FWIW.

-- 
Tom


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


Re: [U-Boot] raspberrypi compute module3 emmc not usable

2018-07-10 Thread Jonathan Gray
On Tue, Jul 10, 2018 at 10:37:19PM +0200, Belisko Marek wrote:
> Hello,
> 
> I'm trying to use u-boot on CM3 (which contains eMMC) to boot kernel.
> I'm using u-boot 2018.05 and it can start fine like:
> U-Boot 2018.05 (Jul 10 2018 - 20:32:05 +)
> 
> DRAM:  948 MiB
> RPI Compute Module 3 (0xa220a0)
> MMC:   sdhci@7e30: 0
> Loading Environment from FAT... unable to select a mode
> ** No partition table - mmc 0 **
> Failed (-5)
> In:serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:   scanning bus 0 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> U-Boot>
> U-Boot>
> U-Boot>
> U-Boot> mmc info
> Device: sdhci@7e30
> Manufacturer ID: 15
> OEM: 100
> Name: 4FPD3
> Bus Speed: 5200
> Mode : MMC legacy
> Rd Block Len: 512
> MMC version 5.0
> High Capacity: Yes
> Capacity: 3.6 GiB
> Bus Width: 1-bit
> Erase Group Size: 512 KiB
> HC WP Group Size: 8 MiB
> User Capacity: 3.6 GiB WRREL
> Boot Capacity: 4 MiB ENH
> RPMB Capacity: 512 KiB ENH
> U-Boot> mmc part
> ## Unknown partition table type 0
> U-Boot> mmc read $loadaddr 0 2
> 
> but reading from eMMC fails with:
> 
> MMC read: dev # 0, block # 0, count 2 ... 0 blocks read: ERROR
> 
> so it looks like eMMC is not properly working with CM3 in this
> version? Any ideas what to check to have it working before I dig to
> debugging session ;). Thanks.

You should give 2018.07 a try, which includes a change for a problem
reported by someone with a CM3.

commit 79fd08f7456c7d12b04ef39e51d84d9981599c3a
Author: Alexander Graf 
Date:   Wed May 23 22:24:51 2018 +0200

mmc: Unirqify bcm2835_sdhost and fix writes

The bcm2835 sdhost driver has a problem with "write multiple" commands.
It seems to boil down to the fact that the controller dislikes its FIFO
to get drained at the end of a block when a write multiple blocks command
is in flight.

The easy fix is to simply get rid of all the IRQ driven logic and make
the driver push as much data into the FIFO as it can. That way we never
drain and we never run into the problem.

Reported-by: Jan Leonhardt 
Signed-off-by: Alexander Graf 

 drivers/mmc/bcm2835_sdhost.c | 265 
++
 1 file changed, 47 insertions(+), 218 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] armv8: layerscape: Enable EHCI access for LS1012A

2018-07-10 Thread Ran Wang
Hi York,

> -Original Message-
> From: York Sun
> Sent: Wednesday, July 11, 2018 05:06
> To: Ran Wang ; Albert Aribaud
> 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] armv8: layerscape: Enable EHCI access for LS1012A
> 
> On 07/02/2018 10:34 PM, Ran Wang wrote:
> > Program Central Security Unit (CSU) to grant access permission for USB
> > 2.0 controller, otherwiase EHCI funciton will down.
> >
> > Signed-off-by: Ran Wang 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c  | 8 
> >  arch/arm/include/asm/arch-fsl-layerscape/ns_access.h | 1 +
> >  2 files changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index 6a56269..2c4cf7f 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #ifdef CONFIG_LAYERSCAPE_NS_ACCESS
> >  #include 
> >  #endif
> > @@ -668,6 +669,13 @@ void fsl_lsch2_early_init_f(void)
> >  CCI400_DVM_MESSAGE_REQ_EN |
> CCI400_SNOOP_REQ_EN);
> > }
> >
> > +   /*
> > +* Program Central Security Unit (CSU) to grant access
> > +* permission for USB 2.0 controller
> > +*/
> > +#if defined(CONFIG_ARCH_LS1012A) && defined(CONFIG_USB_EHCI_FSL)
> > +   set_devices_ns_access(CSU_CSLX_USB_2, CSU_ALL_RW); #endif
> 
> Is this LS1012A specific?
> 
For Layerscape platforms, only LS1012A and LS1021A have USB2.0(EHCI) controller,
Others have USB3.0 controller only. For now I can only verify on LS1012A, so 
didn't
cover LS1021A yet.

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


Re: [U-Boot] [PATCH 5/5] arm: dts: socfpga: stratix10: update pdma

2018-07-10 Thread Chee, Tien Fong
On Tue, 2018-07-10 at 08:37 -0500, Dinh Nguyen wrote:
> 
> On 07/10/2018 08:11 AM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-07-09 at 22:28 +0200, Marek Vasut wrote:
> > > 
> > > On 07/09/2018 08:03 PM, Dinh Nguyen wrote:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On 05/31/2018 03:08 AM, tien.fong.c...@intel.com wrote:
> > > > > 
> > > > > 
> > > > > From: Tien Fong Chee 
> > > > > 
> > > > > Update pdma properties for Stratix 10
> > > > > 
> > > > > Signed-off-by: Tien Fong Chee 
> > > > > ---
> > > > >  arch/arm/dts/socfpga_stratix10.dtsi | 20
> > > > > 
> > > > >  1 file changed, 20 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
> > > > > b/arch/arm/dts/socfpga_stratix10.dtsi
> > > > > index ccd3f32..311ba09 100644
> > > > > --- a/arch/arm/dts/socfpga_stratix10.dtsi
> > > > > +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> > > > > @@ -82,6 +82,26 @@
> > > > >   ranges = <0 0 0 0x>;
> > > > >   u-boot,dm-pre-reloc;
> > > > >  
> > > > > + amba {
> > > > > + u-boot,dm-pre-reloc;
> > > > > + compatible = "arm,amba-bus";
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <1>;
> > > > > + ranges;
> > > > > +
> > > > > + pdma: pdma@ffda {
> > > > > + u-boot,dm-pre-reloc;
> > > > > + compatible =
> > > > > "arm,pl330", "arm,dma330";
> > > > I think you got "arm,dma330" binding wrong. I don't see any
> > > > binding
> > > > with
> > > > that name.
> > Here https://patchwork.ozlabs.org/patch/923234/ .
> Oh okay...why do you need to add the additional binding "arm,dma330"?
pl330 is old name, now arm using dma330.
> 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing

2018-07-10 Thread Jason Rush
On 7/10/2018 11:11 AM, Marek Vasut wrote:
> On 07/10/2018 02:10 PM, Jason Rush wrote:
>> On 7/9/2018 3:08 AM, Marek Vasut wrote:
>>> On 07/07/2018 12:56 AM, Jason Rush wrote:
 On 7/5/2018 6:10 PM, Marek Vasut wrote:
> On 07/06/2018 01:11 AM, Jason Rush wrote:
>> On 7/4/2018 2:23 AM, Marek Vasut wrote:
>>> On 07/04/2018 01:45 AM, Jason Rush wrote:
 On 7/3/2018 9:08 AM, Marek Vasut wrote:
> On 07/03/2018 03:58 PM, Jason Rush wrote:
>> On 6/29/2018 10:17 AM, Marek Vasut wrote:
>>> On 06/29/2018 05:06 PM, Jason Rush wrote:
 On 6/29/2018 9:52 AM, Marek Vasut wrote:
> On 06/29/2018 04:44 PM, Jason Rush wrote:
>> On 6/29/2018 9:34 AM, Marek Vasut wrote:
>>> On 06/29/2018 04:31 PM, Jason Rush wrote:
 Dinh,
>>> Hi,
>>>
 A while ago, you posted the following patchset for SoCFPGA to 
 add the PL330
 DMA driver, and updated the SoCFPGA SDRAM init to write zeros 
 to SDRAM to
 initialize the ECC bits if ECC was enabled:

 https://lists.denx.de/pipermail/u-boot/2016-October/269643.html

 I know it's been a long time, so I'll summarize some of the 
 conversation...

 At the time, you had a problem with the patchset causing the 
 SPL to fail to
 find the MMC.  You had tracked it down to an issue with the 
 following commit
 "a78cd8613204 ARM: Rework and correct barrier definitions".  
 You and Marek
 discussed it a bit, but I don't think there was a real 
 conclusion.  You
 submitted a second version of the patchset asking for advice 
 on debugging
 the issue:

 https://lists.denx.de/pipermail/u-boot/2016-December/275822.html

 No real conversation came from the second patchset, and that 
 was the end of
 the patch.

 I was hoping we could revisit adding your patchset again. I am 
 working on a
 custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased 
 your patchset
 against v2018.05 and it is working on my custom board 
 (although I don't have
 an MMC). I also tested it on a SoCKit booting from an MMC (I 
 forced it to
 scrub the SDRAM on the SoCKit, because it doesn't have ECC 
 RAM), and the
 SoCKit finds the MMC and boots.

 I don't have any suggestions on why it is working now on my 
 board and not
 back when you first submitted the patchset.  Maybe something 
 else was fixed
 in the MMC? I was hoping you and Marek could test this patch 
 again on some
 different SoCFPGA boards to see if you get the same results.
>>> Look at this patch
>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b
>>>
>>> You likely want similar approach, it's faster then the DMA and 
>>> much simpler.
>>>
>> Thanks Marek.  I'll give it a try.  Would you be interested in a 
>> similar patch for the Gen 5?
> I don't have any Gen5 board which uses ECC, do you ?
> If so, yes, prepare a patch, it should be very similar.
>
> Make sure to measure how long it takes to scrub the memory and 
> how much
> memory you have, I'd be interested in the numbers.
>
 Looking at the master branch, it doesn't look like that code is 
 ever being called?
 The sdram_init_ecc_bits() function is called from the 
 ddr_calibration_sequence function(),
 but I can't find where ddr_calibration_sequence is called().
>>> git grep for it, it's called from somewhere in the 
>>> arch/arm/mach-socfpga/
>>>
 Either way, I can test it. I have a custom Cyclone V board with 
 ECC, and the Intel Arria V SoC
 Dev Kit I can test it on too which I think has ECC.
>>> Please do.
>>>
>> I implemented a similar memset approach for the gen 5 socfpga.  It's 
>> basically the same
>> code as in that patch; however, when I performed a single memset the 
>> processor would
>> reset for some reason.  I changed it to loop over calling memset 
>> with a size of 32MB over
>> the entire addres

Re: [U-Boot] raspberrypi compute module3 emmc not usable

2018-07-10 Thread Belisko Marek
Hi Jonathan,

On Wed, Jul 11, 2018 at 3:11 AM Jonathan Gray  wrote:
>
> On Tue, Jul 10, 2018 at 10:37:19PM +0200, Belisko Marek wrote:
> > Hello,
> >
> > I'm trying to use u-boot on CM3 (which contains eMMC) to boot kernel.
> > I'm using u-boot 2018.05 and it can start fine like:
> > U-Boot 2018.05 (Jul 10 2018 - 20:32:05 +)
> >
> > DRAM:  948 MiB
> > RPI Compute Module 3 (0xa220a0)
> > MMC:   sdhci@7e30: 0
> > Loading Environment from FAT... unable to select a mode
> > ** No partition table - mmc 0 **
> > Failed (-5)
> > In:serial
> > Out:   vidconsole
> > Err:   vidconsole
> > Net:   No ethernet found.
> > starting USB...
> > USB0:   scanning bus 0 for devices... 1 USB Device(s) found
> >scanning usb for storage devices... 0 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > U-Boot>
> > U-Boot>
> > U-Boot>
> > U-Boot> mmc info
> > Device: sdhci@7e30
> > Manufacturer ID: 15
> > OEM: 100
> > Name: 4FPD3
> > Bus Speed: 5200
> > Mode : MMC legacy
> > Rd Block Len: 512
> > MMC version 5.0
> > High Capacity: Yes
> > Capacity: 3.6 GiB
> > Bus Width: 1-bit
> > Erase Group Size: 512 KiB
> > HC WP Group Size: 8 MiB
> > User Capacity: 3.6 GiB WRREL
> > Boot Capacity: 4 MiB ENH
> > RPMB Capacity: 512 KiB ENH
> > U-Boot> mmc part
> > ## Unknown partition table type 0
> > U-Boot> mmc read $loadaddr 0 2
> >
> > but reading from eMMC fails with:
> >
> > MMC read: dev # 0, block # 0, count 2 ... 0 blocks read: ERROR
> >
> > so it looks like eMMC is not properly working with CM3 in this
> > version? Any ideas what to check to have it working before I dig to
> > debugging session ;). Thanks.
>
> You should give 2018.07 a try, which includes a change for a problem
> reported by someone with a CM3.
>
> commit 79fd08f7456c7d12b04ef39e51d84d9981599c3a
> Author: Alexander Graf 
> Date:   Wed May 23 22:24:51 2018 +0200
>
> mmc: Unirqify bcm2835_sdhost and fix writes
>
> The bcm2835 sdhost driver has a problem with "write multiple" commands.
> It seems to boil down to the fact that the controller dislikes its FIFO
> to get drained at the end of a block when a write multiple blocks command
> is in flight.
>
> The easy fix is to simply get rid of all the IRQ driven logic and make
> the driver push as much data into the FIFO as it can. That way we never
> drain and we never run into the problem.
>
> Reported-by: Jan Leonhardt 
> Signed-off-by: Alexander Graf 
>
>  drivers/mmc/bcm2835_sdhost.c | 265 
> ++
>  1 file changed, 47 insertions(+), 218 deletions(-)

tried but looks like result is same:
U-Boot 2018.07-dirty (Jul 11 2018 - 03:14:31 +)

DRAM:  948 MiB
RPI Compute Module 3 (0xa220a0)
MMC:   sdhci@7e30: 0
Loading Environment from FAT... ** No partition table - mmc 0 **
Failed (-5)
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot>
U-Boot> mmc dev
unable to select a mode
switch to partitions #0, OK
mmc0(part 0) is current device
U-Boot> mmc info
Device: sdhci@7e30
Manufacturer ID: 15
OEM: 100
Name: 4FPD3
Bus Speed: 5200
Mode : MMC legacy
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 1-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 512 KiB ENH
U-Boot> mmc part
## Unknown partition table type 0
U-Boot> mmc read $loadaddr 0 2

MMC read: dev # 0, block # 0, count 2 ... 0 blocks read: ERROR
U-Boot>

Thanks and BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] U-Boot 2018.07 Still Broken for Allwinner H3 SoCs

2018-07-10 Thread Chen-Yu Tsai
On Tue, Jul 10, 2018 at 2:13 PM, Jagan Teki  wrote:
> On Tue, Jul 10, 2018 at 8:34 AM, Chen-Yu Tsai  wrote:
>> This is on a Libre Computer ALL-H3-CC H3 variant. Still running a
>> bisect, but v2018.07-rc1 is a working version. From the EHCI error
>> messages, I'm thinking it might be related to the USB changes lately.
>> Not sure if any other SoCs (ex. A64) are broken or not at the moment.
>
> I'm able to boot with BPI-M2+, where I changed the configurations
> based on Libre Computer board.
> - remove/disable ehci0, ohci0
> - enable ehci1, 2, 3 and ohci1, 2, 3
> - remove/disable usb_otg node
> - disable MUSB_GADGET

On BPI-M2+, with Sinovoip_BPI_M2_Plus_defconfig,
cross-compiled using gcc version 7.3.0 (Debian 7.3.0-20)

U-Boot SPL 2018.07 (Jul 11 2018 - 10:32:26 +0800)
DRAM: 1024 MiB
Trying to boot from MMC2


U-Boot 2018.07 (Jul 11 2018 - 10:32:26 +0800) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Banana Pi BPI-M2-Plus
DRAM:  1 GiB

MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Unable to use mmc 1:1... Failed (-5)
In:serial
Out:   serial
Err:   serial
Allwinner mUSB OTG (Peripheral)
Net:   phy interface7
eth0: ethernet@1c3
Warning: usb_ether using MAC address from ROM
, eth1: usb_ether
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
494 bytes read in 4 ms (120.1 KiB/s)
## Executing script at 4310
5847064 bytes read in 268 ms (20.8 MiB/s)
16209 bytes read in 5 ms (3.1 MiB/s)
## Flattened Device Tree blob at 4300
   Booting using the fdt blob at 0x4300
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
   Loading Device Tree to 49ff9000, end 4950 ... OK

Starting kernel ...

data abort
pc : [<3f600018>]  lr : [<7df79ed7>]
reloc pc : [<0b687018>]lr : [<4a000ed7>]
sp : 79f53658  ip : 79f59c82 fp : 0400
r10: 7dfc2d70  r9 : 79f58ed8 r8 : 79fb2ca8
r7 :   r6 : 4200 r5 : 49ff9000  r4 : 
r3 : 0006  r2 : 49ff9000 r1 : 0006  r0 : 0006
Flags: nzcv  IRQs off  FIQs off  Mode UK6_32
Code: 00012003 00013003 00014003 00015003 (00016003)
Resetting CPU ...

resetting ...

That PC looks really weird.

ChenYu

> Here is the log:
> U-Boot 2018.07-8-g9b89c61c72-dirty (Jul 10 2018 - 11:37:46 +0530)
> Allwinner Technology
>
> CPU:   Allwinner H3 (SUN8I 1680)
> Model: Banana Pi BPI-M2-Plus
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
> Loading Environment from FAT... Unable to use mmc 1:3... Failed (-5)
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB OHCI 1.0
> USB2:   USB EHCI 1.00
> USB3:   USB OHCI 1.0
> USB4:   USB EHCI 1.00
> USB5:   USB OHCI 1.0
> scanning bus 0 for devices... 1 USB Device(s) found
> scanning bus 2 for devices... 1 USB Device(s) found
> scanning bus 4 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found /extlinux/extlinux.conf
> Retrieving file: /extlinux/extlinux.conf
> 155 bytes read in 3 ms (49.8 KiB/s)
> 1:  linux-4.17.0-rc3
> Retrieving file: /zImage
> 3817968 bytes read in 175 ms (20.8 MiB/s)
> append: console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait
> Retrieving file: /sun8i-h3-bananapi-m2-plus.dtb
> 15691 bytes read in 4 ms (3.7 MiB/s)
> ## Flattened Device Tree blob at 4300
>Booting using the fdt blob at 0x4300
> EHCI failed to shut down host controller.
> EHCI failed to shut down host controller.
> EHCI failed to shut down host controller.
>Loading Device Tree to 49ff9000, end 49fffd4a ... OK
>
> Starting kernel ...
>
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.15.0-rc6-00415-g2f2b41a952de
> (jagan@jagan-XPS-13-9350) (gcc version 6.3.1 20170109 (Linaro GCC
> 6.3-2017.02)) #1 S8
> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save()

2018-07-10 Thread Simon Goldschmidt

Hi,


Pepperl+Fuchs GmbH, Mannheim
Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vors./CEO), 
Werner Guthier, Mehmet Hatiboglu
Vorsitzender des Aufsichtsrats/Chairman of the supervisory board: Michael Fuchs 
sen.
Registergericht/Register Court: AG Mannheim HRB 4713
On 10.07.2018 22:49, Simon Glass wrote:

Hi Nicholas,

On 10 July 2018 at 06:57, Nicholas Faustini
 wrote:

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority. This allows saving the
environment into the same location that has been previously loaded.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.


Why is this? Should it not stop eventually? Do we need a limit on prio?


See my description in this mail:

https://lists.denx.de/pipermail/u-boot/2018-April/324728.html

Unfortunately, I got diverted at that time and could not follow up on 
this. Essentially, the question is raised what 'env save' is supposed to 
do with multiple environments.


Currently, env_save() effectively stores only to the location where the 
env has been loaded from, which is questionable. But storing to all 
locations or the default location might not be correct, either.


Maybe the 'env save' command might need a parameter the tells it where 
to save?


Regards,
Simon (Goldschmidt)





The env_save() function should not loop through the environment
location list but it should use the previously discovered
environment driver once.


What is that? It should be possible to write the env to multiple
places. Also what is the previously discovered environment?



Signed-off-by: Nicholas Faustini 
---

  env/env.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/env/env.c b/env/env.c
index 5c0842a..897d197 100644
--- a/env/env.c
+++ b/env/env.c
@@ -211,16 +211,16 @@ int env_load(void)
  int env_save(void)
  {
 struct env_driver *drv;
-   int prio;

-   for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE, prio)); prio++) {
+   drv = env_driver_lookup(ENVOP_SAVE, 0);
+   if (drv) {
 int ret;

 if (!drv->save)
-   continue;
+   return -ENODEV;

 if (!env_has_inited(drv->location))
-   continue;
+   return -ENODEV;

 printf("Saving Environment to %s... ", drv->name);
 ret = drv->save();
--
2.7.4



Regards,
Simon



Wichtiger Hinweis:
Diese E-Mail einschliesslich ihrer Anhaenge enthaelt vertrauliche und rechtlich geschuetzte Informationen, die nur fuer den Adressaten bestimmt sind. 
Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und loeschen Sie diese Nachricht und ihre Anhaenge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veraenderung der E-Mail ist untersagt. Der Absender haftet nicht fuer Inhalte von veraenderten E-Mails.



Important Information:
This e-mail message including its attachments contains confidential and legally 
protected information solely intended for the addressee. If you are not the 
intended addressee of this message, please contact the addresser immediately 
and delete this message including its attachments. The unauthorized 
dissemination, copying and change of this e-mail are strictly forbidden. The 
addresser shall not be liable for the content of such changed e-mails.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save()

2018-07-10 Thread Simon Goldschmidt


Hi,

sorry for the disclaimer in the last mail. Still don't know why this is 
the default here :-(


Resending without the disclaimer to make possible follow-ups cleaner:

On 10.07.2018 22:49, Simon Glass wrote:

Hi Nicholas,

On 10 July 2018 at 06:57, Nicholas Faustini
 wrote:

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority. This allows saving the
environment into the same location that has been previously loaded.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.


Why is this? Should it not stop eventually? Do we need a limit on prio?


See my description in this mail:

https://lists.denx.de/pipermail/u-boot/2018-April/324728.html

Unfortunately, I got diverted at that time and could not follow up on 
this. Essentially, the question is raised what 'env save' is supposed to 
do with multiple environments.


Currently, env_save() effectively stores only to the location where the 
env has been loaded from, which is questionable. But storing to all 
locations or the default location might not be correct, either.


Maybe the 'env save' command might need a parameter the tells it where 
to save?


Regards,
Simon (Goldschmidt)





The env_save() function should not loop through the environment
location list but it should use the previously discovered
environment driver once.


What is that? It should be possible to write the env to multiple
places. Also what is the previously discovered environment?



Signed-off-by: Nicholas Faustini 
---

  env/env.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/env/env.c b/env/env.c
index 5c0842a..897d197 100644
--- a/env/env.c
+++ b/env/env.c
@@ -211,16 +211,16 @@ int env_load(void)
  int env_save(void)
  {
 struct env_driver *drv;
-   int prio;

-   for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE, prio)); prio++) {
+   drv = env_driver_lookup(ENVOP_SAVE, 0);
+   if (drv) {
 int ret;

 if (!drv->save)
-   continue;
+   return -ENODEV;

 if (!env_has_inited(drv->location))
-   continue;
+   return -ENODEV;

 printf("Saving Environment to %s... ", drv->name);
 ret = drv->save();
--
2.7.4



Regards,
Simon


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


Re: [U-Boot] [PATCH] test: Add ut_assertnull macro

2018-07-10 Thread Ramon Fried
On July 10, 2018 11:49:31 PM GMT+03:00, Simon Glass  wrote:
>On 21 June 2018 at 08:47, Ramon Fried  wrote:
>> Add ut_assertnull macro to include/test/ut.h
>> For testing of functions that returns NULL on errors.
>>
>> Signed-off-by: Ramon Fried 
>> ---
>>  include/test/ut.h | 12 
>>  1 file changed, 12 insertions(+)
>>
>
>Reviewed-by: Simon Glass 
Thanks! 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line

2018-07-10 Thread Michal Simek
On 10.7.2018 18:40, Tom Rini wrote:
> On Mon, Jul 09, 2018 at 11:59:57AM -0500, Joe Hershberger wrote:
>> On Mon, Jul 9, 2018 at 9:43 AM, Tom Rini  wrote:
>>> On Mon, Jul 09, 2018 at 08:19:44AM +0200, Michal Simek wrote:
 On 30.6.2018 06:19, Simon Glass wrote:
> On 27 June 2018 at 07:13, Michal Simek  wrote:
>> On 22.6.2018 14:25, Jean-Jacques Hiblot wrote:
>>> In some cases it can be useful to be able to bind a device to a driver 
>>> from
>>> the command line.
>>> The obvious example is for versatile devices such as USB gadget.
>>> Another use case is when the devices are not yet ready at startup and
>>> require some setup before the drivers are bound (ex: FPGA which 
>>> bitsream is
>>> fetched from a mass storage or ethernet)
>>>
>>> usage example:
>>>
>>> bind usb_dev_generic 0 usb_ether
>>> unbind usb_dev_generic 0 usb_ether
>>> or
>>> unbind eth 1
>>>
>>> bind /ocp/omap_dwc3@4838/usb@4839 usb_ether
>>> unbind /ocp/omap_dwc3@4838/usb@4839
>>>
>>> Signed-off-by: Jean-Jacques Hiblot 
>>>
>>> ---
>>>
>>> Changes in v3:
>>> - factorize code based on comments from ML
>>> - remove the devices before unbinding them
>>> - use device_find_global_by_ofnode() to get a device by its node.
>>> - Added tests
>>>
>>> Changes in v2:
>>> - Make the bind/unbind command generic, not specific to usb device.
>>> - Update the API to be able to bind/unbind based on DTS node path
>>> - Add a Kconfig option to select the bind/unbind commands
>>>
>>>  arch/sandbox/dts/test.dts  |  11 ++
>>>  cmd/Kconfig|   9 ++
>>>  cmd/Makefile   |   1 +
>>>  cmd/bind.c | 255 
>>> +
>>>  configs/sandbox_defconfig  |   1 +
>>>  test/py/tests/test_bind.py | 178 +++
>>>  6 files changed, 455 insertions(+)
>>>  create mode 100644 cmd/bind.c
>>>  create mode 100644 test/py/tests/test_bind.py
>
> Reviewed-by: Simon Glass 
>
> Nice work
>
> [...]
>
>>
>> I have tested bind/unbind with dwc3 on zynqmp for ethernet gadget and it
>> is working fine for me.
>> I have also tried to use bind/unbind for gpio zynqmp driver and it is
>> also working fine.
>>
>> It means
>> Tested-by: Michal Simek 
>>
>> I would prefer if these commands are called as dm bind and dm unbind
>> instead of simply bind/unbind which should also fit to dm command
>> description "dm - Driver model low level access".
>
> Yes i can see the point. But after thinking about it, maybe it is best
> as it is? After all driver model is fundamental to U-Boot and it's not
> clear what else we might bind/unbind.
>
> I'd like to get other opinions here, too.

 Tom/Marek: Any opinion?
>>>
>>> I think dm bind/unbind makes sense, yes.  "bind" and "unbind" are pretty
>>> generic terms and making it clear it's part of working "inside" of DM to
>>> hook/unhook things by making it a sub-command of dm sounds good.
>>> Thanks!
>>
>> I agree with Simon here. I think bind and unbind won't have any
>> plausible other meaning in U-Boot and DM is core to U-Boot
>> functionality in the new world. I think it would be OK to have "dm
>> bind" alias to "bind" if that's a point of confusion, but having it
>> top-level seems good to me.
> 
> They're still very generic words for something that's part of working
> under the dm framework.  That said, looking at test/dm/cmd_dm.c and that
> it's supposed to be only for test/debug type work, yes, OK, I'll change
> my mind.

I would expect that almost everybody will enable CMD_DM where symbol is
in cmd/Kconfig but implementation in test/dm/cmd_dm.c (it is a question
if this is the right place for this file).
When solution with bind and unbind is designed because it is giving you
clear picture what has been binded and probed. You can find paths from
DT but it is not giving you run time information.
At least for xilinx platforms when this functionality is added (which is
great) I am going to make sure that CMD_DM is also enabled because
that's the way how to check status at run time.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




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


[U-Boot] U-Boot release statistics

2018-07-10 Thread Wolfgang Denk
Hi all,

with each release a number of people ask about which tool is used to
generate the statisticcs, and/or how they can be added to the list
of know employer names, here the summary:

The tool used is Jonathan Corbet's gitdm [1] script with a U-Boot
specific configuration, which can be found at [2].  The U-Boot
configuration is in branch "u-boot".

If you have additions or change requests for the domain mapping,
please drop me an e-mail, ideally containing a patch against the 
u-boot-config/domain-map  file.

Thanks.

[1] git://git.lwn.net/gitdm.git
[2] http://git.denx.de/?p=gitdm.git


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Only in our dreams we are free.  The rest of the time we need  wages.
- Terry Pratchett, _Wyrd Sisters_
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] watchdog: dm: Change uclass name to watchdog and enable DM_UC_FLAG_SEQ_ALIAS

2018-07-10 Thread Michal Simek
uclass name is used by dev_read_alias_seq which return seq number when
aliases are used.

Code fragment:
168 int dev_read_alias_seq(struct udevice *dev, int *devnump)
169 {
170 ofnode node = dev_ofnode(dev);
171 const char *uc_name = dev->uclass->uc_drv->name;
172 int ret;
173
174 if (ofnode_is_np(node)) {
175 ret = of_alias_get_id(ofnode_to_np(node), uc_name);

Also this patch enables DM_UC_FLAG_SEQ_ALIAS to be in sync with Linux
which is also using watchdog name for watchdog aliases.

drivers/watchdog/watchdog_core.c:215:
 ret = of_alias_get_id(wdd->parent->of_node, "watchdog");

Signed-off-by: Michal Simek 
---

 drivers/watchdog/wdt-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 4a619f71fe91..f6f2fe3739d3 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -65,5 +65,6 @@ int wdt_expire_now(struct udevice *dev, ulong flags)
 
 UCLASS_DRIVER(wdt) = {
.id = UCLASS_WDT,
-   .name   = "wdt",
+   .name   = "watchdog",
+   .flags  = DM_UC_FLAG_SEQ_ALIAS,
 };
-- 
1.9.1

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


[U-Boot] [PATCH 1/2] arm64: zynqmp: Try to enable the first watchdog via aliases

2018-07-10 Thread Michal Simek
Add support for enabling the first watchdog pointed via aliases.

DT fragment:
aliases {
...
watchdog0 = &watchdog0;
watchdog1 = &watchdog_lpd;
...
};

dm tree fragment for above configuration with patch applied:
ZynqMP> dm tree
 Classindex  Probed  Driver  Name
-
...
 watchdog0  [   ]   cdns_wdt|   |-- watchdog@ff15
 watchdog1  [ + ]   cdns_wdt|   `-- watchdog@fd4d
...

dm uclass fragment:
ZynqMP> dm uclass
...
uclass 75: watchdog
0   watchdog@ff15 @ 7df02f40, seq -1, (req 1)
1 * watchdog@fd4d @ 7df02ff0, seq 0, (req 0)
...

It is visible that index 1 is IP with seq 0 which means that FPD
watchdog (@fd4d) is in DT below LPD watchdog (@ff15).

Till this patch the first watchdog found in DT was used and started
which is not enabling all possible configuration based on user request.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 3d6d00167622..cf9a923bf2af 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -312,12 +312,16 @@ int board_init(void)
 #endif
 
 #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_WDT)
-   if (uclass_get_device(UCLASS_WDT, 0, &watchdog_dev)) {
-   puts("Watchdog: Not found!\n");
-   } else {
-   wdt_start(watchdog_dev, 0, 0);
-   puts("Watchdog: Started\n");
+   if (uclass_get_device_by_seq(UCLASS_WDT, 0, &watchdog_dev)) {
+   debug("Watchdog: Not found by seq!\n");
+   if (uclass_get_device(UCLASS_WDT, 0, &watchdog_dev)) {
+   puts("Watchdog: Not found!\n");
+   return 0;
+   }
}
+
+   wdt_start(watchdog_dev, 0, 0);
+   puts("Watchdog: Started\n");
 #endif
 
return 0;
-- 
1.9.1

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


[U-Boot] [PATCH 2/2] arm: zynq: Try to enable the first watchdog via aliases

2018-07-10 Thread Michal Simek
The same change as was done for zynqmp with this description:

Add support for enabling the first watchdog pointed via aliases.

DT fragment:
aliases {
...
watchdog0= &watchdog0;
watchdog1 = &watchdog_lpd;
...
};



Till this patch the first watchdog found in DT was used and started
which is not enabling all possible configuration based on user request.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynq/board.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 1106f5c2a892..9c005e40e895 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -36,12 +36,16 @@ int board_early_init_f(void)
 int board_init(void)
 {
 #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_WDT)
-   if (uclass_get_device(UCLASS_WDT, 0, &watchdog_dev)) {
-   puts("Watchdog: Not found!\n");
-   } else {
-   wdt_start(watchdog_dev, 0, 0);
-   puts("Watchdog: Started\n");
+   if (uclass_get_device_by_seq(UCLASS_WDT, 0, &watchdog_dev)) {
+   debug("Watchdog: Not found by seq!\n");
+   if (uclass_get_device(UCLASS_WDT, 0, &watchdog_dev)) {
+   puts("Watchdog: Not found!\n");
+   return 0;
+   }
}
+
+   wdt_start(watchdog_dev, 0, 0);
+   puts("Watchdog: Started\n");
 # endif
 
return 0;
-- 
1.9.1

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


Re: [U-Boot] [PATCH 5/8] phy: sun4i-usb: Update PHY#3 rst_mask only for H3_H5

2018-07-10 Thread Vasily Khoruzhick
On Mon, Jul 9, 2018 at 12:17 PM, Jagan Teki  wrote:
> Only H3 and H5 have 4 PHYS so restrict rst_mask only for them.
>
> Signed-off-by: Jagan Teki 
> ---
>  drivers/phy/allwinner/phy-sun4i-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 3096f12c1c..81fcd1f910 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -117,7 +117,7 @@ struct sun4i_usb_phy_info {
> .gpio_vbus = CONFIG_USB3_VBUS_PIN,
> .gpio_vbus_det = NULL,
> .gpio_id_det = NULL,
> -#ifdef CONFIG_MACH_SUN6I
> +#ifdef CONFIG_MACH_SUNXI_H3_H5

It should be handled by compatibles, not ifdefs. Phy driver is proper
DM driver, so you can use .data in device ids array.

> .rst_mask = (CCM_USB_CTRL_PHY3_RST | CCM_USB_CTRL_PHY3_CLK),
>  #endif
> },
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 7/8] usb: musb-new: sunxi: Add proper musb exit support

2018-07-10 Thread Vasily Khoruzhick
On Mon, Jul 9, 2018 at 12:17 PM, Jagan Teki  wrote:
> musb have platform ops to do proper graceful exit,
> so add the exit call and move musb platform exit code
> instead of keeping it in driver remove.
> This make proper shutdown of musb where .remove will
> call disable, exit serially via musb_stop.
>
> Signed-off-by: Jagan Teki 
> ---
>  drivers/usb/musb-new/sunxi.c | 48 +---
>  1 file changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> index aa2880eeb9..9f71b84fd1 100644
> --- a/drivers/usb/musb-new/sunxi.c
> +++ b/drivers/usb/musb-new/sunxi.c
> @@ -326,6 +326,33 @@ static int sunxi_musb_init(struct musb *musb)
> return 0;
>  }
>
> +static int sunxi_musb_exit(struct musb *musb)
> +{
> +   struct sunxi_glue *glue = to_sunxi_glue(musb->controller);
> +   int ret = 0;
> +
> +   if (generic_phy_valid(&glue->phy)) {
> +   ret = generic_phy_exit(&glue->phy);
> +   if (ret) {
> +   dev_err(dev, "failed to power off usb phy\n");
> +   return ret;
> +   }
> +   }
> +
> +#ifdef CONFIG_SUNXI_GEN_SUN6I

Same here, since you're refactoring this code, it would be appropriate
to use compatibles and get rid of this ifdef.

> +   clrbits_le32(&glue->ccm->ahb_reset0_cfg, BIT(AHB_GATE_OFFSET_USB0));
> +   if (glue->cfg->rst_bit)
> +   clrbits_le32(&glue->ccm->ahb_reset0_cfg,
> +BIT(glue->cfg->rst_bit));
> +#endif
> +   clrbits_le32(&glue->ccm->ahb_gate0, BIT(AHB_GATE_OFFSET_USB0));
> +   if (glue->cfg->clkgate_bit)
> +   clrbits_le32(&glue->ccm->ahb_gate0,
> +BIT(glue->cfg->clkgate_bit));
> +
> +   return 0;
> +}
> +
>  static void sunxi_musb_pre_root_reset_end(struct musb *musb)
>  {
> struct sunxi_glue *glue = to_sunxi_glue(musb->controller);
> @@ -342,6 +369,7 @@ static void sunxi_musb_post_root_reset_end(struct musb 
> *musb)
>
>  static const struct musb_platform_ops sunxi_musb_ops = {
> .init   = sunxi_musb_init,
> +   .exit   = sunxi_musb_exit,
> .enable = sunxi_musb_enable,
> .disable= sunxi_musb_disable,
> .pre_root_reset_end = sunxi_musb_pre_root_reset_end,
> @@ -456,29 +484,9 @@ static int musb_usb_remove(struct udevice *dev)
>  {
> struct sunxi_glue *glue = dev_get_priv(dev);
> struct musb_host_data *host = &glue->mdata;
> -   int ret;
> -
> -   if (generic_phy_valid(&glue->phy)) {
> -   ret = generic_phy_exit(&glue->phy);
> -   if (ret) {
> -   pr_err("failed to exit %s USB PHY\n", dev->name);
> -   return ret;
> -   }
> -   }
>
> musb_stop(host->host);
>
> -#ifdef CONFIG_SUNXI_GEN_SUN6I
> -   clrbits_le32(&glue->ccm->ahb_reset0_cfg, BIT(AHB_GATE_OFFSET_USB0));
> -   if (glue->cfg->rst_bit)
> -   clrbits_le32(&glue->ccm->ahb_reset0_cfg,
> -BIT(glue->cfg->rst_bit));
> -#endif
> -   clrbits_le32(&glue->ccm->ahb_gate0, BIT(AHB_GATE_OFFSET_USB0));
> -   if (glue->cfg->clkgate_bit)
> -   clrbits_le32(&glue->ccm->ahb_gate0,
> -BIT(glue->cfg->clkgate_bit));
> -
> free(host->host);
> host->host = NULL;
>
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot