[U-Boot] [PATCH 1/1] scripts/get_maintainer.pl: enable find_maintainer_files

[Heinrich Schuchardt]

Many MAINTAINERS files are in subdirectories.
We should enable searching these.

Reported-by: Walt Feasel 
Signed-off-by: Heinrich Schuchardt 
---
 scripts/get_maintainer.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 8b6037b73f..07800e62d1 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -59,7 +59,7 @@ my $from_filename = 0;
 my $pattern_depth = 0;
 my $version = 0;
 my $help = 0;
-my $find_maintainer_files = 0;
+my $find_maintainer_files = 1;
 
 my $vcs_used = 0;
 
-- 
2.14.1

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

Re: [U-Boot] [U-Boot, 1/1] scripts/get_maintainer.pl: update to current version

[Heinrich Schuchardt]

On 10/28/2017 05:44 AM, waltfea...@gmail.com wrote:
> Heinrich,
> 
> I ran across a problem with not getting a maintainer for a correction I
> was putting together. I tracked it down to the line:
> 
> "+my $find_maintainer_files = 0;"
> 
> When I changed the "0" to a "1" I was able to get the maintainer as
> intended.
> 
> My error was as follows:
> 
> $ perl scripts/get_maintainer.pl -m -r -l -f board/Marvell/dreamplug/
> Bad divisor in main::vcs_assign: 0
> "GitAuthor: Walt Feasel"  (authored:2/1=100%)
> u-boot@lists.denx.de (open list)

Hello Walt,

I am not able to reproduce your problem with perl v5.4.21 on Debian Stretch:

$ scripts/get_maintainer.pl -f board/Marvell/dreamplug/
u-boot@lists.denx.de (open list)
$ perl scripts/get_maintainer.pl -m -r -l -f board/Marvell/dreamplug/
u-boot@lists.denx.de (open list)
$

I wonder why you are calling perl with -m -r -l.

The get_maintainer.pl script is maintained in the Linux kernel source
tree. So if you find any problem, please, send a mail

TO: Joe Perches  (maintainer:GET_MAINTAINER SCRIPT)
CC: linux-ker...@vger.kernel.org (open list)

As we have many MAINTAINERS files in subdirectories you are right in
that we should enable finding these. I will submit a patch.

Best regards

Heinrich

> 
> When I changed from the "0" to the "1" as stated above I get:
> 
> $ perl scripts/get_maintainer.pl -m -r -l -f board/Marvell/dreamplug/
> Jason Cooper  (maintainer:DREAMPLUG BOARD)
> u-boot@lists.denx.de (open list)
> 
> As I would expect and believe is intended.
> 
> 
> I have included below the text of your e-mail to the u-boot list as a
> reference.
> 
> I do not know if this is the proper fix for it or if it may cause
> issues with your intentions so I will leave it to you and or Tom to
> decide what to do.
> 
> Also, I am currently not subscribed to the mailing list so unable to
> post there.
> 
> Sincerely,
> 
> Walt Feasel
> 
> 
> ORIGINAL POST ON MAILING LIST BELOW
> 
> 
> Update the script to version 0.26 (as of Linux v4.14-rc1)
> Keep our "penguin_chief".
> Keep our top_of_kernel_tree.
> 
> The negative forms of the command line parameters are described
> when using --help.
> 
> New options are
> 
>  --git-blame-signatures => when used with --git-blame,
>    also include all commit signers
>  --r => include reviewer(s) if any
>  --letters => print all matching 'letter' types
>   from all matching sections
> 
> File .get_maintainer.ignore can be used to specify
> email addressees that shall be ignored.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  scripts/get_maintainer.pl | 202 +++---
> 
>  1 file changed, 156 insertions(+), 46 deletions(-)
> 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 83a4e5bad2..8b6037b73f 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -1,4 +1,4 @@
> -#!/usr/bin/perl -w
> +#!/usr/bin/env perl
>  # (c) 2007, Joe Perches 
>  #   created from checkpatch.pl
>  #
> @@ -10,18 +10,22 @@
>  #
>  # Licensed under the terms of the GNU GPL License version 2
>  
> +use warnings;
>  use strict;
>  
>  my $P = $0;
>  my $V = '0.26';
>  
>  use Getopt::Long qw(:config no_auto_abbrev);
> +use Cwd;
>  use File::Find;
>  
> +my $cur_path = fastgetcwd() . '/';
>  my $lk_path = "./";
>  my $email = 1;
>  my $email_usename = 1;
>  my $email_maintainer = 1;
> +my $email_reviewer = 1;
>  my $email_list = 1;
>  my $email_subscriber_list = 0;
>  my $email_git_penguin_chiefs = 0;
> @@ -42,10 +46,12 @@ my $output_multiline = 1;
>  my $output_separator = ", ";
>  my $output_roles = 0;
>  my $output_rolestats = 1;
> +my $output_section_maxlen = 50;
>  my $scm = 0;
>  my $web = 0;
>  my $subsystem = 0;
>  my $status = 0;
> +my $letters = "";
>  my $keywords = 1;
>  my $sections = 0;
>  my $file_emails = 0;
> @@ -53,6 +59,7 @@ my $from_filename = 0;
>  my $pattern_depth = 0;
>  my $version = 0;
>  my $help = 0;
> +my $find_maintainer_files = 0;
>  
>  my $vcs_used = 0;
>  
> @@ -128,6 +135,7 @@ my %VCS_cmds_git = (
>  "author_pattern" => "^GitAuthor: (.*)",
>  "subject_pattern" => "^GitSubject: (.*)",
>  "stat_pattern" => "^(\\d+)\\t(\\d+)\\t\$file\$",
> +"file_exists_cmd" => "git ls-files \$file",
>  );
>  
>  my %VCS_cmds_hg = (
> @@ -156,6 +164,7 @@ my %VCS_cmds_hg = (
>  "author_pattern" => "^HgAuthor: (.*)",
>  "subject_pattern" => "^HgSubject: (.*)",
>  "stat_pattern" => "^(\\d+)\t(\\d+)\t\$file\$",
> +"file_exists_cmd" => "hg files \$file",
>  );
>  
>  my $conf = which_conf(".get_maintainer.conf");
> @@ -184,6 +193,27 @@ if (-f $conf) {
>  unshift(@ARGV, @conf_args) if @conf_args;
>  }
>  
> +my @ignore_emails = ();
> +my $ignore_file = which_conf(".get_maintainer.ignore");
> +if (-f $ignore_file) {
> +open(my $ignore, '<', "$ignore_file")
> + or warn "$P: Can't find a readable .get_maintainer.ignore 

Re: [U-Boot] [U-Boot,10/16] exynos: remove CONFIG_CORE_COUNT

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:25PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Minkyu Kang 

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, 09/16] omap4: sdp4430: match the #endif comment to #ifdef

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:24PM +0900, Masahiro Yamada wrote:

> This comment creates a wrong entry in config_whitelist.txt.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,11/16] MX28: remove CONFIG_DEFAULT_SPI_CS

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:26PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,07/16] ARC: remove CONFIG_ARC_UART_BASE

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:22PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,15/16] exynos: remove CONFIG_LCD_MENU_BOARD

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:30PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Minkyu Kang 

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, 16/16] AT91: remove CONFIG_PMECC_INDEX_TABLE_OFFSET

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:31PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,14/16] net: remove CONFIG_NET_MULTI

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:29PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: York Sun 

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,12/16] AM33XX: etamin: remove CONFIG_DFU_MTD

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:27PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,04/16] omap4: sdp4430: remove CONFIG_4430SDP

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:19PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,08/16] SOCFPGA: remove CONFIG_AUTONEG_TIMEOUT

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:23PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 13/16] mpc85xx: xpedite550x: remove CONFIG_FDT_FIXUP_PCI_IRQ

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:28PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,03/16] IMX: novena: remove CONFIG_I2C_MXC

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:18PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Heiko Schocher

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, 05/16] mpc85xx: freescale: remove CONFIG_ADDR_STREAMING

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:20PM +0900, Masahiro Yamada wrote:

> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: York Sun 

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,06/16] sh7734: remove CONFIG_553MHZ_MODE

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:21PM +0900, Masahiro Yamada wrote:

> This macro only appears in commented-out lines.  It is not referenced
> by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 02/16] i2c: fti2c010: remove unused/unmaintained driver

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:17PM +0900, Masahiro Yamada wrote:

> CONFIG_SYS_I2C_FTI2C010 is not enabled by anyone.
> 
> Commit 2852709676c8 ("dm: i2c: Add a note to I2C drivers which need
> conversion") prompted to convert this driver to DM before June 2017,
> but not converted yet.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Heiko Schocher 

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] Please pull u-boot-x86

[Tom Rini]

On Fri, Oct 27, 2017 at 03:18:55PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This fixes a bunch of x86 breakages.
> 
> The following changes since commit 4c7a211046a3956058b512edd8533f7df031cc4a:
> 
>   Kconfig: add CONFIG_BROKEN (2017-10-23 17:28:18 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to 411898dc87c09d0cd103a4243c8cb4a72b115c51:
> 
>   x86: acpi: Put sleepstates.asl to the common place (2017-10-27 15:13:47 
> +0800)
> 

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, 01/16] i2c: adi_i2c: remove left-over Blackfin I2C driver

[Tom Rini]

On Thu, Oct 26, 2017 at 09:24:16PM +0900, Masahiro Yamada wrote:

> This driver was used by Blackfin boards, but Blackfin support is
> gone.  There is no user of this driver.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Heiko Schocher 

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] [GIT PULL] u-boot-sunxi/master

[Tom Rini]

On Thu, Oct 26, 2017 at 05:19:21PM +0200, Maxime Ripard wrote:

> Hi Tom,
> 
> Here are a few changes that would be great to merge.
> 
> It's basically a few fixes for CPU frequencies that were underclocked,
> fastboot that was broken on a NAND-based device (the CHIP Pro, and it
> also moves the fastboot NAND option to Kconfig in the process), some
> missing options, one board, and the size check and size reduction
> patches that we discussed at length.
> 
> Thanks!
> Maxime
> 
> The following changes since commit 4c7a211046a3956058b512edd8533f7df031cc4a:
> 
>   Kconfig: add CONFIG_BROKEN (2017-10-23 17:28:18 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-sunxi master
> 
> for you to fetch changes up to 819f1e081c527d2d02cdaeec0027384688cf5de0:
> 
>   sunxi: binman: Add U-Boot binary size check (2017-10-25 10:05:06 +0200)
> 

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

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

[York Sun]

Tom,

The following changes since commit ce0dea889a01d06bdc2d845fd03e90bcf8b49fec:

  Merge git://git.denx.de/u-boot-uniphier (2017-10-22 19:21:04 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-fsl-qoriq.git

for you to fetch changes up to 9b3f40ad092ff2633eefa7e8a4a713f71c9cb8cb:

  armv8: sec_firmware: Add support for loadables in FIT (2017-10-27
08:47:14 -0700)


Ashish Kumar (2):
  armv8: ls1088: Move CONFIG_ENV_IS_IN_SPI_FLASH to defconfig
  armv8: ls1088aqds: Change phy mode to PHY_INTERFACE_MODE_RGMII_ID

Prabhakar Kushwaha (1):
  driver: fsl-mc: use calloc instead malloc

Ran Wang (5):
  arm64: layerscape: Move CONFIG_HAS_FSL_XHCI_USB to Kconfig
  usb: host: Move CONFIG_XHCI_FSL to Kconfig
  arm: layerscape: Remove CONFIG_USB_MAX_CONTROLLER_COUNT
  armv8: ls1088ardb: Enable USB command RDB qspi-boot
  armv8: ls1088aqds: Enable USB command on QDS for qspi-boot

Sumit Garg (2):
  armv8: layerscape: Allocate 66 MB DDR for secure memory
  armv8: sec_firmware: Add support for loadables in FIT

York Sun (1):
  powerpc: mpc85xx: Implement CPU erratum A-007907 for secondary cores

Yuantian Tang (1):
  armv8: configs: ls1012a: correct the generic timer frequency

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig |  7 ++
 arch/arm/cpu/armv8/fsl-layerscape/ppa.c   | 16 +++-
 arch/arm/cpu/armv8/sec_firmware.c | 92
++-
 arch/arm/dts/fsl-ls1088a.dtsi | 14 
 arch/arm/include/asm/arch-fsl-layerscape/config.h |  2 +-
 arch/arm/include/asm/armv8/sec_firmware.h |  4 +-
 arch/powerpc/cpu/mpc85xx/release.S|  6 ++
 board/freescale/ls1088a/eth_ls1088aqds.c  |  1 +
 configs/ls1088aqds_qspi_defconfig |  9 +++
 configs/ls1088ardb_qspi_defconfig |  9 +++
 drivers/net/fsl-mc/mc.c   | 39 +-
 drivers/net/ldpaa_eth/ls1088a.c   |  4 +-
 drivers/usb/host/Kconfig  |  6 ++
 include/configs/ls1012a_common.h  |  2 +-
 include/configs/ls1012afrdm.h | 10 ---
 include/configs/ls1012aqds.h  |  8 --
 include/configs/ls1012ardb.h  |  9 ---
 include/configs/ls1021aiot.h  |  8 --
 include/configs/ls1021aqds.h  |  8 --
 include/configs/ls1021atwr.h  |  8 --
 include/configs/ls1043aqds.h  |  7 --
 include/configs/ls1043ardb.h  |  9 ---
 include/configs/ls1046aqds.h  |  7 --
 include/configs/ls1046ardb.h  |  9 ---
 include/configs/ls1088aqds.h  |  1 -
 include/configs/ls1088ardb.h  |  1 -
 include/configs/ls2080aqds.h  |  7 --
 include/configs/ls2080ardb.h  |  7 --
 include/linux/usb/xhci-fsl.h  |  2 +-
 scripts/config_whitelist.txt  |  2 -
 30 files changed, 182 insertions(+), 132 deletions(-)

Thanks.

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

Re: [U-Boot] [PATCH 5/7] bootcount: add support for bootcounter on EXT filesystem

[Calvin Johnson]

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Martyn
> Welch
> Sent: Thursday, October 26, 2017 8:18 PM

> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index 5ee1601..b9580b9 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -175,6 +175,7 @@ CONFIG_BOOTCOMMAND
>  CONFIG_BOOTCOUNT_ALEN
>  CONFIG_BOOTCOUNT_AM33XX
>  CONFIG_BOOTCOUNT_ENV
> +CONFIG_BOOTCOUNT_EXT
>  CONFIG_BOOTCOUNT_I2C
>  CONFIG_BOOTCOUNT_LIMIT
>  CONFIG_BOOTCOUNT_RAM
> @@ -2368,6 +2369,9 @@ CONFIG_SYS_BOARD_VERSION
>  CONFIG_SYS_BOOK3E_HV
>  CONFIG_SYS_BOOTCOUNT_ADDR
>  CONFIG_SYS_BOOTCOUNT_BE
> +CONFIG_SYS_BOOTCOUNT_EXT_DEVPART
> +CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE
> +CONFIG_SYS_BOOTCOUNT_EXT_NAME
>  CONFIG_SYS_BOOTCOUNT_LE
>  CONFIG_SYS_BOOTCOUNT_SINGLEWORD
>  CONFIG_SYS_BOOTFILE_PREFIX

I think you have add these new configs to Kconfig instead of 
config_whitelist.txt.

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

[U-Boot] [PATCH] test/py: add timestamps to log

[Stephen Warren]

From: Stephen Warren 

It can be useful to record how long tests take; this can help debug slow
running test systems or track changes in performance over time. Enhance
the test system to record timestamps while running test:
- Whenever a new log file section is started.
- After U-Boot is started and communication has been established.
- After each host or U-Boot command is executed.

Signed-off-by: Stephen Warren 
---
 test/py/multiplexed_log.css|  4 
 test/py/multiplexed_log.py | 37 +
 test/py/u_boot_console_base.py |  3 +++
 3 files changed, 44 insertions(+)

diff --git a/test/py/multiplexed_log.css b/test/py/multiplexed_log.css
index f135b10a24c9..9b7c44fe4de0 100644
--- a/test/py/multiplexed_log.css
+++ b/test/py/multiplexed_log.css
@@ -62,6 +62,10 @@ pre {
 color: #8080ff
 }
 
+.timestamp {
+color: #8080ff
+}
+
 .status-pass {
 color: #00ff00
 }
diff --git a/test/py/multiplexed_log.py b/test/py/multiplexed_log.py
index 5bc1bc49d4de..8ca515319ce9 100644
--- a/test/py/multiplexed_log.py
+++ b/test/py/multiplexed_log.py
@@ -7,6 +7,7 @@
 # each represented in a well-delineated/-structured fashion.
 
 import cgi
+import datetime
 import os.path
 import shutil
 import subprocess
@@ -164,6 +165,7 @@ class RunAndLog(object):
 self.logfile.write(self, output)
 if self.chained_file:
 self.chained_file.write(output)
+self.logfile.timestamp()
 
 # Store the output so it can be accessed if we raise an exception.
 self.output = output
@@ -219,6 +221,9 @@ class Logfile(object):
 self.blocks = []
 self.cur_evt = 1
 self.anchor = 0
+self.timestamp_start = self._get_time()
+self.timestamp_prev = self.timestamp_start
+self.timestamp_blocks = []
 
 shutil.copy(mod_dir + '/multiplexed_log.css', os.path.dirname(fn))
 self.f.write('''\
@@ -388,6 +393,7 @@ $(document).ready(function () {
 
 self._terminate_stream()
 self.blocks.append(marker)
+self.timestamp_blocks.append(self._get_time())
 if not anchor:
 self.anchor += 1
 anchor = str(self.anchor)
@@ -396,6 +402,7 @@ $(document).ready(function () {
 self.f.write('Section: ' +
  blk_path + '\n')
 self.f.write('\n')
+self.timestamp()
 
 return anchor
 
@@ -416,6 +423,11 @@ $(document).ready(function () {
 raise Exception('Block nesting mismatch: "%s" "%s"' %
 (marker, '/'.join(self.blocks)))
 self._terminate_stream()
+timestamp_now = self._get_time()
+timestamp_section_start = self.timestamp_blocks.pop()
+delta_section = timestamp_now - timestamp_section_start
+self._note("timestamp",
+"TIME: SINCE-SECTION: " + str(delta_section))
 blk_path = '/'.join(self.blocks)
 self.f.write('' +
  'End section: ' + blk_path + '\n')
@@ -492,6 +504,31 @@ $(document).ready(function () {
 
 self._note("action", msg)
 
+def _get_time(self):
+return datetime.datetime.now()
+
+def timestamp(self):
+"""Write a timestamp to the log file.
+
+Args:
+None
+
+Returns:
+Nothing.
+"""
+
+timestamp_now = self._get_time()
+delta_prev = timestamp_now - self.timestamp_prev
+delta_start = timestamp_now - self.timestamp_start
+self.timestamp_prev = timestamp_now
+
+self._note("timestamp",
+"TIME: NOW: " + timestamp_now.strftime("%Y/%m/%d %H:%M:%S.%f"))
+self._note("timestamp",
+"TIME: SINCE-PREV: " + str(delta_prev))
+self._note("timestamp",
+"TIME: SINCE-START: " + str(delta_start))
+
 def status_pass(self, msg, anchor=None):
 """Write a note to the log file describing test(s) which passed.
 
diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index eedf73f85831..4bccd72050b7 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -215,6 +215,8 @@ class ConsoleBase(object):
 self.log.error(str(ex))
 self.cleanup_spawn()
 raise
+finally:
+self.log.timestamp()
 
 def run_command_list(self, cmds):
 """Run a list of commands.
@@ -370,6 +372,7 @@ class ConsoleBase(object):
 self.cleanup_spawn()
 raise
 finally:
+self.log.timestamp()
 self.log.end_section('Starting U-Boot')
 
 def cleanup_spawn(self):
-- 
2.14.2

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

Re: [U-Boot] [PATCH v2] net: phy: marvell: Add functions to read PHY's extended registers

[York Sun]

On 10/27/2017 08:23 AM, Lukasz Majewski wrote:
> On Fri, 27 Oct 2017 15:06:37 +
> York Sun  wrote:
> 
>> On 10/27/2017 02:12 AM, Lukasz Majewski wrote:
>>> This commit allows extended Marvell registers to be read with:
>>>
>>> foo > mdio rx FEC 3.10
>>> Reading from bus FEC
>>> PHY at address 0:
>>> 3.16 - 0x1063
>>> foo > mdio wx FEC 3.10 0x1011
>>>
>>> The above code changes the way ETH connector LEDs blink.
>>>
>>> Signed-off-by: Lukasz Majewski 
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Provide the readext and writeext callbacks to other marvell ETH
>>> PHY devices
>>>
>>>  drivers/net/phy/marvell.c | 47
>>> +++ 1 file changed, 47
>>> insertions(+)
>>>
>>> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
>>> index b7f300e..19f451d 100644
>>> --- a/drivers/net/phy/marvell.c
>>> +++ b/drivers/net/phy/marvell.c
>>> @@ -104,6 +104,31 @@
>>>  #define MIIM_88E151x_MODE_SGMII1
>>>  #define MIIM_88E151x_RESET_OFFS15
>>>  
>>> +static int m88e1xxx_phy_extread(struct phy_device *phydev, int
>>> addr,
>>> +   int devaddr, int regnum)
>>> +{
>>> +   int oldpage = phy_read(phydev, MDIO_DEVAD_NONE,
>>> MII_MARVELL_PHY_PAGE);
>>> +   int val;
>>> +
>>> +   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE,
>>> devaddr);

For register 30 and 31, the page register is 29, not 22.

>>> +   val = phy_read(phydev, MDIO_DEVAD_NONE, regnum);
>>> +   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE,
>>> oldpage); +
>>> +   return val;
>>> +}
>>> +
>>> +static int m88e1xxx_phy_extwrite(struct phy_device *phydev, int
>>> addr,
>>> +int devaddr, int regnum, u16 val)
>>> +{
>>> +   int oldpage = phy_read(phydev, MDIO_DEVAD_NONE,
>>> MII_MARVELL_PHY_PAGE); +
>>> +   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE,
>>> devaddr);
>>> +   phy_write(phydev, MDIO_DEVAD_NONE, regnum, val);
>>> +   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE,
>>> oldpage); +
>>> +   return 0;
>>> +}
>>> +
>>>  /* Marvell 88E1011S */
>>>  static int m88e1011s_config(struct phy_device *phydev)
>>>  {
>>> @@ -599,6 +624,8 @@ static struct phy_driver M88E1011S_driver = {
>>> .config = _config,
>>> .startup = _startup,
>>> .shutdown = _shutdown,
>>> +   .readext = _phy_extread,
>>> +   .writeext = _phy_extwrite,
>>>  };
>>>  
>>
>> Lukasz,
>>
>> This seems wrong. 88E1011S doesn't have the page register.
> 
> Ok. I will remove this one from v3.
> 
>> I can only
>> confirm 88E and 88E1145 have pages. 
> 
> I do know that it works on 88E151x
> 
> The 88E1318 and 88E1618 seems to be unknown.
> 
>> I don't have other part's
>> datasheet to check.
> 

I suggest only to enable the parts you can confirm on hardware,
datasheet, or from the source code (where the page register is used).

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

Re: [U-Boot] [PATCH v2] net: phy: marvell: Add functions to read PHY's extended registers

[Lukasz Majewski]

On Fri, 27 Oct 2017 15:06:37 +
York Sun  wrote:

> On 10/27/2017 02:12 AM, Lukasz Majewski wrote:
> > This commit allows extended Marvell registers to be read with:
> > 
> > foo > mdio rx FEC 3.10
> > Reading from bus FEC
> > PHY at address 0:
> > 3.16 - 0x1063
> > foo > mdio wx FEC 3.10 0x1011
> > 
> > The above code changes the way ETH connector LEDs blink.
> > 
> > Signed-off-by: Lukasz Majewski 
> > 
> > ---
> > 
> > Changes in v2:
> > - Provide the readext and writeext callbacks to other marvell ETH
> > PHY devices
> > 
> >  drivers/net/phy/marvell.c | 47
> > +++ 1 file changed, 47
> > insertions(+)
> > 
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index b7f300e..19f451d 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -104,6 +104,31 @@
> >  #define MIIM_88E151x_MODE_SGMII1
> >  #define MIIM_88E151x_RESET_OFFS15
> >  
> > +static int m88e1xxx_phy_extread(struct phy_device *phydev, int
> > addr,
> > +   int devaddr, int regnum)
> > +{
> > +   int oldpage = phy_read(phydev, MDIO_DEVAD_NONE,
> > MII_MARVELL_PHY_PAGE);
> > +   int val;
> > +
> > +   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE,
> > devaddr);
> > +   val = phy_read(phydev, MDIO_DEVAD_NONE, regnum);
> > +   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE,
> > oldpage); +
> > +   return val;
> > +}
> > +
> > +static int m88e1xxx_phy_extwrite(struct phy_device *phydev, int
> > addr,
> > +int devaddr, int regnum, u16 val)
> > +{
> > +   int oldpage = phy_read(phydev, MDIO_DEVAD_NONE,
> > MII_MARVELL_PHY_PAGE); +
> > +   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE,
> > devaddr);
> > +   phy_write(phydev, MDIO_DEVAD_NONE, regnum, val);
> > +   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE,
> > oldpage); +
> > +   return 0;
> > +}
> > +
> >  /* Marvell 88E1011S */
> >  static int m88e1011s_config(struct phy_device *phydev)
> >  {
> > @@ -599,6 +624,8 @@ static struct phy_driver M88E1011S_driver = {
> > .config = _config,
> > .startup = _startup,
> > .shutdown = _shutdown,
> > +   .readext = _phy_extread,
> > +   .writeext = _phy_extwrite,
> >  };
> >  
> 
> Lukasz,
> 
> This seems wrong. 88E1011S doesn't have the page register.

Ok. I will remove this one from v3.

> I can only
> confirm 88E and 88E1145 have pages. 

I do know that it works on 88E151x

The 88E1318 and 88E1618 seems to be unknown.

>I don't have other part's
> datasheet to check.

> 
> York



Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH v2] net: phy: marvell: Add functions to read PHY's extended registers

[York Sun]

On 10/27/2017 02:12 AM, Lukasz Majewski wrote:
> This commit allows extended Marvell registers to be read with:
> 
> foo > mdio rx FEC 3.10
> Reading from bus FEC
> PHY at address 0:
> 3.16 - 0x1063
> foo > mdio wx FEC 3.10 0x1011
> 
> The above code changes the way ETH connector LEDs blink.
> 
> Signed-off-by: Lukasz Majewski 
> 
> ---
> 
> Changes in v2:
> - Provide the readext and writeext callbacks to other marvell ETH PHY
> devices
> 
>  drivers/net/phy/marvell.c | 47 
> +++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index b7f300e..19f451d 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -104,6 +104,31 @@
>  #define MIIM_88E151x_MODE_SGMII  1
>  #define MIIM_88E151x_RESET_OFFS  15
>  
> +static int m88e1xxx_phy_extread(struct phy_device *phydev, int addr,
> + int devaddr, int regnum)
> +{
> + int oldpage = phy_read(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE);
> + int val;
> +
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE, devaddr);
> + val = phy_read(phydev, MDIO_DEVAD_NONE, regnum);
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE, oldpage);
> +
> + return val;
> +}
> +
> +static int m88e1xxx_phy_extwrite(struct phy_device *phydev, int addr,
> +  int devaddr, int regnum, u16 val)
> +{
> + int oldpage = phy_read(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE);
> +
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE, devaddr);
> + phy_write(phydev, MDIO_DEVAD_NONE, regnum, val);
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE, oldpage);
> +
> + return 0;
> +}
> +
>  /* Marvell 88E1011S */
>  static int m88e1011s_config(struct phy_device *phydev)
>  {
> @@ -599,6 +624,8 @@ static struct phy_driver M88E1011S_driver = {
>   .config = _config,
>   .startup = _startup,
>   .shutdown = _shutdown,
> + .readext = _phy_extread,
> + .writeext = _phy_extwrite,
>  };
>  

Lukasz,

This seems wrong. 88E1011S doesn't have the page register. I can only
confirm 88E and 88E1145 have pages. I don't have other part's
datasheet to check.

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

Re: [U-Boot] [PATCH] sunxi: call fdt_fixup_ethernet again to set macaddr for more aliases

[Maxime Ripard]

On Fri, Oct 27, 2017 at 05:34:39PM +0800, Icenowy Zheng wrote:
> Sometimes some ethernet aliases do not exist in U-Boot FDT but they
> exist in the FDT used to boot the system.

I'd rather not end up in this situation in the first place. If things
get broken, then it might actually be a good symptom that you need to
sync the DTs.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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] dm: serial: Add .pre_probe() function to to wait for previous transmission end

[Lukasz Majewski]

Hi Philipp,

> Hi Lukasz,
> 
> > On 27 Oct 2017, at 00:51, Lukasz Majewski  wrote:
> >> 
> >>> On 27 Oct 2017, at 00:13, Lukasz Majewski  wrote:
> >>> 
> >>> It may happen that the serial IP block is performing some ongoing
> >>> transmission (started at e.g. board_init()) when the serial
> >>> "probe" is called.
> >>> 
> >>> As a result the serial port IP block is reset, so transmitted data
> >>> is corrupted:
> >>> 
> >>>   I2C:   ready
> >>>   DRAM:  1 GiB
> >>>   jSS('HH��SL_SDHC: 04 rev 0x0
> >>> 
> >>> This patch prevents from this situation, by defining pre_probe()
> >>> callback in which we wait till the TX buffer is empty (from
> >>> previous transmission):
> >>> 
> >>>   I2C:   ready
> >>>   DRAM:  1 GiB
> >>>   ID:unit type 0x4 rev 0x0
> >>> 
> >>> All defined ->pending callbacks at ./drivers/serial are non
> >>> blocking
> >>> - just simple reading from registers and testing flags. Hence, it
> >>> should be enough to not use any timeout from timer.
> >>> One shall also note that we enable console very early - not all
> >>> timers may be ready for work - adding timeout here would impose
> >>> implicit dependency that timers are setup before serial.
> >> 
> >> Given that this is effectively a busy polling loop, why can’t this
> >> be done from the probe-function of serial drivers that require this
> >> functionality?
> > 
> > That would be one of the options. 
> > 
> > Originally, this code was placed at iMX specific function - namely
> > _mxc_serial_init() [1]. 
> > 
> > However, Simon suggested to solve this problem globally via DM's
> > serial-uclass, which offers pre_probe() callback for such purpose.
> > 
> > The problem here is the polling loop. I've checked and ->pending on
> > real SoCs is just a read from the register - which should not block
> > (a similar approach is used in Linux kernel).
> > 
> > Having timeout from timer would impose dependency on timer init'ed
> > first - before serial.
> 
> I worry a bit about the pending-callback being called prior to a
> probe. As of today, the pending function can assume that probe() has
> run and initialised the private structures accordingly—with this
> change, that assumption is invalidated.

Yes. I agree.

Other issue is that we may need timer based timeout for some SoCs. And
this also implies to have timer initialized before the console.

> 
> If we go down this path, then we need to clearly indicate that the
> pending function can not rely on probe() to have initialised the
> device state or private data structures.  If we keep this check
> within the probe()-function, it should be obvious what is set up and
> what isn’t.

Those are valid arguments.

I would even go further and leave this patch as it was in the first
version [1] - since:

- It is similar to what Linux does
- for iMX it uses check on HW bit which is guarantee to be cleared in
  some point of time (of course if HW is not broken).

However, lets wait for input from Simon - how he would like to tackle
this issue.

> 
> > 
> > [1] - https://patchwork.ozlabs.org/patch/820824/
> > 
> >> 
> >>> 
> >>> 
> >>> Signed-off-by: Lukasz Majewski 
> >>> ---
> >>> 
> >>> drivers/serial/serial-uclass.c | 20 
> >>> 1 file changed, 20 insertions(+)
> >>> 
> >>> diff --git a/drivers/serial/serial-uclass.c
> >>> b/drivers/serial/serial-uclass.c index 2e5116f..5e6964d 100644
> >>> --- a/drivers/serial/serial-uclass.c
> >>> +++ b/drivers/serial/serial-uclass.c
> >>> @@ -420,10 +420,30 @@ static int serial_pre_remove(struct udevice
> >>> *dev) return 0;
> >>> }
> >>> 
> >>> +static int serial_pre_probe(struct udevice *dev)
> >>> +{
> >>> + struct dm_serial_ops *ops = serial_get_ops(dev);
> >>> + int ret = 0;
> >>> +
> >>> + /*
> >>> +  * Wait for any ongoing transmission to finish - for
> >>> example
> >>> +  * from pre-relocation enabled UART
> >>> +  */
> >>> + if (ops && ops->pending)
> >>> + do {
> >>> + ret = ops->pending(dev, false);
> >>> + if (ret < 0)
> >>> + break;
> >>> + } while (ret > 0);
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> UCLASS_DRIVER(serial) = {
> >>>   .id = UCLASS_SERIAL,
> >>>   .name   = "serial",
> >>>   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> >>> + .pre_probe  = serial_pre_probe,
> >>>   .post_probe = serial_post_probe,
> >>>   .pre_remove = serial_pre_remove,
> >>>   .per_device_auto_alloc_size = sizeof(struct
> >>> serial_dev_priv), -- 
> >>> 2.1.4
> >>> 
> >> 
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > w...@denx.de
> 



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 

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

[Eugeniy Paltsev]

On Tue, 2017-10-24 at 15:22 +0530, Jagan Teki wrote:
> On Tue, Oct 24, 2017 at 11:38 AM, Marek Vasut  wrote:
> > On 10/23/2017 01:43 PM, Eugeniy Paltsev wrote:
> > > On Thu, 2017-10-19 at 13:20 -0500, Dinh Nguyen wrote:
> > > > 
> > > > On 10/19/2017 10:51 AM, Marek Vasut wrote:
> > > > > On 10/19/2017 05:36 PM, Eugeniy Paltsev wrote:
> > > > > > On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote:
> > > > > > > On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin
> > > > > > >  wrote:
> > > > > > > > Hi Jagan,
> > > > > > > > 
> > > > > > > > > -Original Message-
> > > > > > > > > From: Eugeniy Paltsev [mailto:palt...@synopsys.com]
> > > > > > > > > Sent: Tuesday, October 17, 2017 4:33 PM
> > > > > > > > > To: jagannadh.t...@gmail.com
> > > > > > > > > Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com
> > > > > > > > > Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock 
> > > > > > > > > value from Device Tree
> > > > > > > > > > 
> > > > > > > > > > How hard it is to make others to use clock manager? do you 
> > > > > > > > > > have any list?
> > > > > > > > > 
> > > > > > > > > clock_manager.h is an old (and non-generic) way to deal with 
> > > > > > > > > different clocks.
> > > > > > > > > For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 
> > > > > > > > > clock_manager.h provides
> > > > > > > > > cm_get_spi_controller_clk_hz function to deal with spi 
> > > > > > > > > controller clock.
> > > > > > > > > 
> > > > > > > > > But today we have another, linux-like alternative: to bind 
> > > > > > > > > clocks via device tree
> > > > > > > > > and manipulate with clocks via generic functions provided by 
> > > > > > > > > clk.h
> > > > > > > > > 
> > > > > > > > > In this patch I added option to get clock via device tree 
> > > > > > > > > using standard bindings
> > > > > > > > > and restrict clock_manager.h functions usage only to targets 
> > > > > > > > > which still use it,
> > > > > > > > > so new targets can simply bind clock via device tree and they 
> > > > > > > > > do not need to
> > > > > > > > > implement/define something in clock_manager.h
> > > > > > > > > 
> > > > > > > > > So we don't need to make others to use clock manager :)
> > > > > > > > 
> > > > > > > > Maybe it worth trying the other way around and think about 
> > > > > > > > switching SOCFPGA platforms to
> > > > > > > > generic clk framework?
> > > > > > > 
> > > > > > > Yes, ie what exactly I thought of, thanks!
> > > > > > 
> > > > > > I checked cm_get_spi_controller_clk_hz implementation in 
> > > > > > SOCFPGA_GEN5 and
> > > > > > SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" 
> > > > > > driver as it
> > > > > > manipulate with real hardware.
> > > > > > The only way to do it is to replace SOCFPGA* clock manager 
> > > > > > functions by real
> > > > > > clock driver.
> > > > > > 
> > > > > > And given I don't have mentioned hardware so I barely can help with
> > > > > > those improvements on SOCFPGA. That said if there're no short-term 
> > > > > > plans to
> > > > > > switch SOCFPGA to clk framework maybe we'll be OK with my 
> > > > > > workaround with #ifdefs?
> > > > > 
> > > > > Wait for Dinh's reply ...
> > > > > 
> > > > 
> > > > Honestly, I don't have too much time to work on this right now. So I
> > > > really don't when it can get done. But it'll go on my to-do list.
> > > > 
> > > > Dinh
> > > 
> > > Yep, thanks for your comments.
> > > 
> > > So, Jagan,
> > > given Dinh's reply, could you please apply this patch?
> > 
> > I'd really hate it to start seeing soc-specific ifdefs in drivers,
> > that's IMO not acceptable. A __weak override might be a temporary
> > solution I'd be willing to live with though.
> 
> I would rather like to see some check on clock manager itself whether
> CONFIG_IS_ENABLED(CLK) is using or not? this can tends not to use
> __weak as well soc #ifdefs in driver.
> 

Actually I don't understand what do you mean.
Even if I add any #ifdefs to the clock_manager.h I still need to wrap 
clock_manager.h
include with #ifdefs as clock_manager.h is defined only for two 
targets - SOCFPGA_GEN5 and SOCFPGA_ARRIA10.

#if defined(CONFIG_TARGET_SOCFPGA_GEN5) || 
defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
#include 
#endif

And I think it is better to add this #ifdef in driver than create empty 
clock_manager.h file for every new target which uses this driver.
-- 
 Eugeniy Paltsev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] dm: serial: Add .pre_probe() function to to wait for previous transmission end

[Dr. Philipp Tomsich]

Hi Lukasz,

> On 27 Oct 2017, at 00:51, Lukasz Majewski  wrote:
>> 
>>> On 27 Oct 2017, at 00:13, Lukasz Majewski  wrote:
>>> 
>>> It may happen that the serial IP block is performing some ongoing
>>> transmission (started at e.g. board_init()) when the serial "probe"
>>> is called.
>>> 
>>> As a result the serial port IP block is reset, so transmitted data
>>> is corrupted:
>>> 
>>>   I2C:   ready
>>>   DRAM:  1 GiB
>>>   jSS('HH��SL_SDHC: 04 rev 0x0
>>> 
>>> This patch prevents from this situation, by defining pre_probe()
>>> callback in which we wait till the TX buffer is empty (from
>>> previous transmission):
>>> 
>>>   I2C:   ready
>>>   DRAM:  1 GiB
>>>   ID:unit type 0x4 rev 0x0
>>> 
>>> All defined ->pending callbacks at ./drivers/serial are non blocking
>>> - just simple reading from registers and testing flags. Hence, it
>>> should be enough to not use any timeout from timer.
>>> One shall also note that we enable console very early - not all
>>> timers may be ready for work - adding timeout here would impose
>>> implicit dependency that timers are setup before serial.
>> 
>> Given that this is effectively a busy polling loop, why can’t this be
>> done from the probe-function of serial drivers that require this
>> functionality?
> 
> That would be one of the options. 
> 
> Originally, this code was placed at iMX specific function - namely
> _mxc_serial_init() [1]. 
> 
> However, Simon suggested to solve this problem globally via DM's
> serial-uclass, which offers pre_probe() callback for such purpose.
> 
> The problem here is the polling loop. I've checked and ->pending on
> real SoCs is just a read from the register - which should not block (a
> similar approach is used in Linux kernel).
> 
> Having timeout from timer would impose dependency on timer init'ed
> first - before serial.

I worry a bit about the pending-callback being called prior to a probe.
As of today, the pending function can assume that probe() has run
and initialised the private structures accordingly—with this change,
that assumption is invalidated.

If we go down this path, then we need to clearly indicate that the
pending function can not rely on probe() to have initialised the device
state or private data structures.  If we keep this check within the
probe()-function, it should be obvious what is set up and what isn’t.

> 
> [1] - https://patchwork.ozlabs.org/patch/820824/
> 
>> 
>>> 
>>> 
>>> Signed-off-by: Lukasz Majewski 
>>> ---
>>> 
>>> drivers/serial/serial-uclass.c | 20 
>>> 1 file changed, 20 insertions(+)
>>> 
>>> diff --git a/drivers/serial/serial-uclass.c
>>> b/drivers/serial/serial-uclass.c index 2e5116f..5e6964d 100644
>>> --- a/drivers/serial/serial-uclass.c
>>> +++ b/drivers/serial/serial-uclass.c
>>> @@ -420,10 +420,30 @@ static int serial_pre_remove(struct udevice
>>> *dev) return 0;
>>> }
>>> 
>>> +static int serial_pre_probe(struct udevice *dev)
>>> +{
>>> +   struct dm_serial_ops *ops = serial_get_ops(dev);
>>> +   int ret = 0;
>>> +
>>> +   /*
>>> +* Wait for any ongoing transmission to finish - for
>>> example
>>> +* from pre-relocation enabled UART
>>> +*/
>>> +   if (ops && ops->pending)
>>> +   do {
>>> +   ret = ops->pending(dev, false);
>>> +   if (ret < 0)
>>> +   break;
>>> +   } while (ret > 0);
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> UCLASS_DRIVER(serial) = {
>>> .id = UCLASS_SERIAL,
>>> .name   = "serial",
>>> .flags  = DM_UC_FLAG_SEQ_ALIAS,
>>> +   .pre_probe  = serial_pre_probe,
>>> .post_probe = serial_post_probe,
>>> .pre_remove = serial_pre_remove,
>>> .per_device_auto_alloc_size = sizeof(struct
>>> serial_dev_priv), -- 
>>> 2.1.4
>>> 
>> 
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de

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

[U-Boot] [PATCH] video/da8xx-fb: Cache-align memory allocations

[Niko Mauno]

Resort to malloc_cache_aligned() rather than malloc() which also removes
'CACHE: Misaligned operation at range' warnings.

Signed-off-by: Niko Mauno 
---
 drivers/video/da8xx-fb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index bbd384df5e..6ec4f89e34 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -14,7 +14,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -924,7 +924,7 @@ void *video_hw_init(void)
  da8xx_lcd_cfg->bpp);
 
size = sizeof(struct fb_info) + sizeof(struct da8xx_fb_par);
-   da8xx_fb_info = malloc(size);
+   da8xx_fb_info = malloc_cache_aligned(size);
debug("da8xx_fb_info at %x\n", (unsigned int)da8xx_fb_info);
 
if (!da8xx_fb_info) {
@@ -949,7 +949,7 @@ void *video_hw_init(void)
da8xx_lcd_cfg->bpp;
par->vram_size = par->vram_size * LCD_NUM_BUFFERS / 8;
 
-   par->vram_virt = malloc(par->vram_size);
+   par->vram_virt = malloc_cache_aligned(par->vram_size);
 
par->vram_phys = (dma_addr_t) par->vram_virt;
debug("Requesting 0x%x bytes for framebuffer at 0x%x\n",
@@ -972,7 +972,7 @@ void *video_hw_init(void)
da8xx_fb_fix.line_length - 1;
 
/* allocate palette buffer */
-   par->v_palette_base = malloc(PALETTE_SIZE);
+   par->v_palette_base = malloc_cache_aligned(PALETTE_SIZE);
if (!par->v_palette_base) {
printf("GLCD: malloc for palette buffer failed\n");
goto err_release_fb_mem;
-- 
2.11.0

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

Re: [U-Boot] dwc2: usb: Unable to clear channel error

[Minas Harutyunyan]

On 10/24/2017 3:23 AM, Dinh Nguyen wrote:
> 
> 
> On 10/23/2017 09:03 AM, Minas Harutyunyan wrote:
>> On 10/19/2017 5:35 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 10/19/2017 06:55 AM, Grigor Tovmasyan wrote:
 On 10/18/2017 6:07 PM, Marek Vasut wrote:
> On 10/18/2017 04:05 PM, Dinh Nguyen wrote:
>> Hi,
>>
>> I'm trying to bringup the DWC2 USB IP version 330A on a new Stratix10
>> SoC and have encountered this error in both Linux and U-Boot:
>>
>> U-Boot(version v2017.09)
>>
>> # usb start
>> starting USB...
>> USB0:   Core Release: 3.30a
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>>
>> Linux(kernel v4.13)
>>
>> [1.299891] dwc2 ffb0.usb: DWC OTG Controller
>> [1.304628] dwc2 ffb0.usb: new USB bus registered, assigned bus
>> number 1
>> [1.311698] dwc2 ffb0.usb: irq 13, io mem 0xffb0
>> [1.318309] dwc2 ffb0.usb: Unable to clear enable on channel 0
>> [1.325749] dwc2 ffb0.usb: Unable to clear enable on channel 1
>> [1.333187] dwc2 ffb0.usb: Unable to clear enable on channel 2
>> [1.340626] dwc2 ffb0.usb: Unable to clear enable on channel 3
>> [1.348064] dwc2 ffb0.usb: Unable to clear enable on channel 4
>> [1.355503] dwc2 ffb0.usb: Unable to clear enable on channel 5
>> [1.362941] dwc2 ffb0.usb: Unable to clear enable on channel 6
>> [1.370379] dwc2 ffb0.usb: Unable to clear enable on channel 7
>> [1.377818] dwc2 ffb0.usb: Unable to clear enable on channel 8
>> [1.385256] dwc2 ffb0.usb: Unable to clear enable on channel 9
>> [1.392694] dwc2 ffb0.usb: Unable to clear enable on channel 10
>> [1.400218] dwc2 ffb0.usb: Unable to clear enable on channel 11
>> [1.407743] dwc2 ffb0.usb: Unable to clear enable on channel 12
>> [1.415269] dwc2 ffb0.usb: Unable to clear enable on channel 13
>> [1.422794] dwc2 ffb0.usb: Unable to clear enable on channel 14
>>
>> Just wondering if anyone might have an idea on what could be causing
>> this error?
>
> Maybe some clock are not enabled ?
>

 Hi ,

 Are you following board/hisilicon/hikey/README file instructions when
 using U-Boot? Specially paragraph FLASHING point 4, where discussed
 "dwc_otg_core_host_init: Timeout!" message.

>>>
>>> I saw that, but I don't know how that applies to a Stratix10 platform?
>>>
>>> Dinh
>>>
>>>
>> Hi,
>>
>> Did you able to resolve this issue? If not, please provide verbose debug
>> log and register dump.
>>
> 
> I double-checked the clocks and it looks like all of the necessary
> clocks are enabled. Here are the log and register dump for U-Boot, I'll
> follow-up with the Linux log shortly.
> 
> For U-Boot:
> 
> SOCFPGA_STRATIX10 # usb start
> starting USB...
> USB0:   Core Release: 3.30a
> dwc_otg_core_host_init: Timeout (reg=ffb00500 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00520 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00540 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00560 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00580 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb005a0 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb005c0 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb005e0 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00600 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00620 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00640 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00660 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb00680 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb006a0 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout (reg=ffb006c0 mask=8000
> wait_set=0)
> dwc_otg_core_host_init: Timeout!
> scanning bus 0 for devices... dwc2_submit_control_msg:
> dev='usb@ffb0', udev=3fa50380, udev->dev='usb@ffb0',
> portnr=0
> dwc2_submit_control_msg: dev='usb@ffb0', udev=3fa50380,
> udev->dev='usb@ffb0', portnr=0

Re: [U-Boot] Commands to use U-boot in fpga

[Ammu Lakshmy]

Architecture is LEON2 and is supported by U-Boot.
But the steps involved in my work are

*1. Implement LEON2 processor in FPGA(Spartan3E or any other fpga)*
*2. Deploy OS in that processor.*
*3. Implement a router on that processor with OS.*

First step is possible as I have the HDL code of LEON2. I can implement it
on spartan3E.
Are the next 2 steps possible with U-Boot?

On Fri, Oct 27, 2017 at 4:28 PM, Lukasz Majewski  wrote:

> Hi Ammu,
>
> > Hi,
> >
> > I am new to U-Boot and I want to use it for dumping linux to a sparc
> > processor (leon2) which I have implemented in Spartan 3E fpga. Is it
> > possible?
>
> First you need to check if the architecture on which you run u-boot is
> supported (sparc?).
>
> There are some IP soft cores supported in u-boot:
> arch/nios2/
> arch/microblaze/
>
>
> Regarding SPARC:
>
> http://git.denx.de/?p=u-boot/u-boot-sparc.git;a=summary
>
> But if I remember correctly it has been removed recently.
>
> However, if you want to re-add it for your platform -> patches are as
> always welcome :-)
>
> >
> > This is to implement a router code in my processor.
> >
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>



-- 
Thanks & Regards,
Ammu Lakshmy R.
M.Tech. VLSI Design
VNIT, Nagpur
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] video/da8xx-fb: Cache-align memory allocations

[Anatolij Gustschin]

On Fri, 27 Oct 2017 14:52:08 +0300
Niko Mauno niko.ma...@vaisala.com wrote:

> Resort to malloc_cache_aligned() rather than malloc() which also removes
> 'CACHE: Misaligned operation at range' warnings.
> 
> Signed-off-by: Niko Mauno 
> ---
>  drivers/video/da8xx-fb.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Anatolij Gustschin 

--
Anatolij

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

Re: [U-Boot] [PATCH] Kconfig: BOOTCOMMAND: Define default set of boot commands in Kconfig

[Lukasz Majewski]

Hi Tom,

> On Sat, Sep 30, 2017 at 10:20:47PM +0200, Łukasz Majewski wrote:
> > On 09/14/2017 04:55 PM, Tom Rini wrote:
> > >On Mon, Sep 11, 2017 at 10:53:51PM +0200, Łukasz Majewski wrote:
> > >>On 09/11/2017 07:31 PM, Tom Rini wrote:
> > >>>On Sun, Sep 10, 2017 at 08:25:02PM +0200, Lukasz Majewski wrote:
> > >>>
> > This patch gives an opportunity to override the defined
> > CONFIG_BOOTCOMMAND (at  files) with set of
> > commands defined in board _defconfig file.
> > 
> > Rationale: This change allows having two different u-boot
> > builds - one for production and one (far more larger) for
> > factory setup.
> > 
> > Signed-off-by: Lukasz Majewski 
> > >>>
> > >>>I don't get it, sorry.  We need to move CONFIG_BOOTCOMMAND into
> > >>>Kconfig with some other logic so that distro_bootcmd stuff works.
> > >>>
> > >>
> > >>The state of the art:
> > >>-
> > >>
> > >>Many boards use CONFIG_BOOTCOMMAND as a set of commands to be
> > >>executed at boot time:
> > >>
> > >>bootcmd=CONFIG_BOOTCOMMAND
> > >>
> > >>One notable user of it is config_distro_bootcmd.h
> > >
> > >Right.
> > >
> > >>Rationale:
> > >>--
> > >>
> > >>With this patch I can:
> > >>
> > >>1. Setup one set of commands to be executed by default - e.g.:
> > >>
> > >>bootcmd="run boot_mmc"
> > >>
> > >>and
> > >>
> > >>2. Have other defconfig - e.g. _factory_defconfig, which
> > >>enables some extra stuff (like USB, gadget, gpt write, etc) and is
> > >>used solely for factory flashing.
> > >>
> > >>By having the opportunity to override CONFIG_BOOTCOMMAND in
> > >>Kconfig, I can use the same code base and just adjust Kconfig for
> > >>board.
> > >>
> > >>
> > >>What do you mean by "some other logic"?
> > >
> > >Well, CONFIG_BOOTCOMMAND needs to be moved to Kconfig itself.
> > >Figuring out some of the "how" will take a little work.  And a
> > >little re-organization.  But that needs doing.
> >
> > 
> > Cannot we start with the approach proposed by this commit?
> > 
> > How would you see the rework done?
> 
> I'd like to see something that tries to move CONFIG_BOOTCOMMAND
> around. Move the distro boot things into include/environment/ and use
> the post-processed command as value in configs/*_defconfig as fits,
> or put things into something else in include/environment/ for other
> repeated but not distro boot commands.
> 

I've not received any reply from you regarding following argument for
this patch:

The proposed above changes are orthogonal to this patch.

This patch _only_ gives the opportunity to override current BOOTCOMMAND 
settings.
This functionality allows the same code base for two distinct u-boot 
builds - namely factory (for flashing) and production one.

Such approach is very convenient with OE builds.



The whole discussion can be find at:
https://patchwork.ozlabs.org/patch/812174/


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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

Re: [U-Boot] Commands to use U-boot in fpga

[Lukasz Majewski]

On Fri, 27 Oct 2017 16:45:16 +0530
Ammu Lakshmy  wrote:

> Architecture is LEON2 and is supported by U-Boot.
> But the steps involved in my work are
> 
> *1. Implement LEON2 processor in FPGA(Spartan3E or any other fpga)*

Ok.

> *2. Deploy OS in that processor.*

When you have working soft core of LEON2 - then you would need:

- U-boot ported to it (and this is not the problem - since you say that
  it is supported in U-Boot)

- Linux mainline kernel, which can run on this processor.

U-boot is only a bootloader, which means that its main purpose is to
setup environment (like initialize DRAM, load OS from persistent
storage) for pass execution flow to OS (Linux)

> *3. Implement a router on that processor with OS.*

If you have Linux running on the soft core and enough number of ETH phy
devices you can configure Linux box to work as a router (with proper
iproute[2] rules).

TO sum up:

You need 3 things:

- U-boot running on your soft core
- Linux running on your soft core
- Number of working ETH phys to connect network cables.

> 
> First step is possible as I have the HDL code of LEON2. I can
> implement it on spartan3E.
> Are the next 2 steps possible with U-Boot?
> 
> On Fri, Oct 27, 2017 at 4:28 PM, Lukasz Majewski 
> wrote:
> 
> > Hi Ammu,
> >
> > > Hi,
> > >
> > > I am new to U-Boot and I want to use it for dumping linux to a
> > > sparc processor (leon2) which I have implemented in Spartan 3E
> > > fpga. Is it possible?
> >
> > First you need to check if the architecture on which you run u-boot
> > is supported (sparc?).
> >
> > There are some IP soft cores supported in u-boot:
> > arch/nios2/
> > arch/microblaze/
> >
> >
> > Regarding SPARC:
> >
> > http://git.denx.de/?p=u-boot/u-boot-sparc.git;a=summary
> >
> > But if I remember correctly it has been removed recently.
> >
> > However, if you want to re-add it for your platform -> patches are
> > as always welcome :-)
> >
> > >
> > > This is to implement a router code in my processor.
> > >
> >
> >
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > w...@denx.de
> >
> 
> 
> 




Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH v4 12/18] efi_selftest: allow to select a single test for exexution

[Heinrich Schuchardt]

On 10/18/2017 06:13 PM, Heinrich Schuchardt wrote:

The numbering in the title should have been
[PATCH v4 11/18] efi_selftest: allow to select a single test for exexution

> Environment variable efi_selftest is passed as load options
> to the selftest application. It is used to select a single
> test to be executed.
> 
> The load options are an UTF8 string. Yet I decided to keep
> the name propertiy of the tests as char[] to reduce code
> size.
> 
> Special value 'list' displays a list of all available tests.
> 
> Tests get an on_request property. If this property is set
> the tests are only executed if explicitly requested.
> 
> The invocation of efi_selftest is changed to reflect that
> bootefi selftest with efi_selftest = 'list' will call the
> Exit bootservice.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v4
>   remove superfluous definitions
> v3
>   split off unrelated changes to separate patches
> v2
>   use an environment variable to choose a test
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-boot changes to bringup boot and secondary CPUs in HYP mode

[Lukasz Majewski]

Hi Jayadev,

> Hello all,
> 
> I am currently trying to bring up Xen on OMAP5432. When I try to boot
> the board it shows
> 
> 
> 
> 
> 
> 
> 
> 
> *Starting kernel ...- UART enabled -- CPU  booting -- Xen
> must be entered in NS Hyp mode -- Please update the bootloader --
> Boot failed -* After applying the below patch , the boot CPU started
> loading.
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
> b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
> index 86c0e42..696da4b 100644
> --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
> +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
> @@ -19,7 +19,20 @@
>   ENTRY(save_boot_params)
>   ldrr1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
>   strr0, [r1]
> +/*
> + * Turn on hypervisor mode on CPU#0
> + */
> +#ifdef CONFIG_DRA7XX_HYPERVISOR_ON
> +movr0, lr@ This is a great place to switch into hyp
> mode
> +@ only the r0 was needed from _start and is now
> +@ free; all other general purpose registers were
> +@ already free.
> +ldrr12, =0x102@ Set PL310 control register - value in R0
> +.word0xe1600070@ SMC #0 - hand assembled because
> -march=armv5
> +@ call ROM Code API to set control register
> +#else
>   bxlr
> +#endif /* CONFIG_DRA7XX_HYPERVISOR_ON */
>   ENDPROC(save_boot_params)
>ENTRY(set_pl310_ctrl_reg)
> 
> However now the secondary CPUs fail to load;
> 
> 
> 
> 
> 
> 
> 
> *(XEN) Bringing up CPU1- CPU 0001 booting -- Xen must be entered
> in NS Hyp mode -- Please update the bootloader -- Boot failed -*
> Can someone provide the proper U-boot changes required to load the
> CPUs in HYP mode

Maybe between your patch (at the very beginning of boot up) and the time
XEN wants to re-enable second CPU there is a switch from HYP to SVC mode?

Please keep in mind that u-boot works with single core - and this
single core execution mode is passed to XEN.

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




Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] Commands to use U-boot in fpga

[Lukasz Majewski]

Hi Ammu,

> Hi,
> 
> I am new to U-Boot and I want to use it for dumping linux to a sparc
> processor (leon2) which I have implemented in Spartan 3E fpga. Is it
> possible?

First you need to check if the architecture on which you run u-boot is
supported (sparc?).

There are some IP soft cores supported in u-boot:
arch/nios2/
arch/microblaze/


Regarding SPARC:

http://git.denx.de/?p=u-boot/u-boot-sparc.git;a=summary

But if I remember correctly it has been removed recently.

However, if you want to re-add it for your platform -> patches are as
always welcome :-)

> 
> This is to implement a router code in my processor.
> 




Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH] tools: env: allow to print U-Boot version

[Lukasz Majewski]

On Thu, 26 Oct 2017 14:57:53 +0200
Stefan Agner  wrote:

> From: Stefan Agner 
> 
> The fw_env utility family has a default environment compiled in
> which ties it quite strongly to the U-Boot source/config it has
> been built with. Allow to display the U-Boot version it has been
> built with using the -v/--version argument.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  tools/env/fw_env_main.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/env/fw_env_main.c b/tools/env/fw_env_main.c
> index 6e278ca80b..0b9063742c 100644
> --- a/tools/env/fw_env_main.c
> +++ b/tools/env/fw_env_main.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "fw_env_private.h"
>  #include "fw_env.h"
>  
> @@ -48,6 +49,7 @@ static struct option long_options[] = {
>   {"script", required_argument, NULL, 's'},
>   {"noheader", required_argument, NULL, 'n'},
>   {"lock", required_argument, NULL, 'l'},
> + {"version", no_argument, NULL, 'v'},
>   {NULL, 0, NULL, 0}
>  };
>  
> @@ -67,6 +69,7 @@ void usage_printenv(void)
>   "Print variables from U-Boot environment\n"
>   "\n"
>   " -h, --help   print this help.\n"
> + " -v, --versiondisplay version\n"
>  #ifdef CONFIG_ENV_AES
>   " -a, --aesaes key to access
> environment\n" #endif
> @@ -85,6 +88,7 @@ void usage_env_set(void)
>   "Modify variables in U-Boot environment\n"
>   "\n"
>   " -h, --help   print this help.\n"
> + " -v, --versiondisplay version\n"
>  #ifdef CONFIG_ENV_AES
>   " -a, --aesaes key to access
> environment\n" #endif
> @@ -123,7 +127,7 @@ static void parse_common_args(int argc, char
> *argv[]) env_opts.config_file = CONFIG_FILE;
>  #endif
>  
> - while ((c = getopt_long(argc, argv, ":a:c:l:h",
> long_options, NULL)) !=
> + while ((c = getopt_long(argc, argv, ":a:c:l:h:v",
> long_options, NULL)) != EOF) {
>   switch (c) {
>   case 'a':
> @@ -145,6 +149,10 @@ static void parse_common_args(int argc, char
> *argv[]) do_printenv ? usage_printenv() : usage_env_set();
>   exit(EXIT_SUCCESS);
>   break;
> + case 'v':
> + fprintf(stderr, "Compiled with "
> U_BOOT_VERSION "\n");
> + exit(EXIT_SUCCESS);
> + break;
>   default:
>   /* ignore unknown options */
>   break;
> @@ -162,7 +170,7 @@ int parse_printenv_args(int argc, char *argv[])
>  
>   parse_common_args(argc, argv);
>  
> - while ((c = getopt_long(argc, argv, "a:c:ns:l:h",
> long_options, NULL))
> + while ((c = getopt_long(argc, argv, "a:c:ns:l:h:v",
> long_options, NULL)) != EOF) {
>   switch (c) {
>   case 'n':
> @@ -189,7 +197,7 @@ int parse_setenv_args(int argc, char *argv[])
>  
>   parse_common_args(argc, argv);
>  
> - while ((c = getopt_long(argc, argv, "a:c:ns:l:h",
> long_options, NULL))
> + while ((c = getopt_long(argc, argv, "a:c:ns:l:h:v",
> long_options, NULL)) != EOF) {
>   switch (c) {
>   case 's':

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH v3 06/20] common: Generic firmware loader for file system

[Lukasz Majewski]

Hi Tien Fong,

> On Kha, 2017-10-26 at 14:51 +0200, Lukasz Majewski wrote:
> > Tien Fong,
> > 
> > > 
> > > On Isn, 2017-10-16 at 16:41 +0200, Marek Vasut wrote:
> > > > 
> > > > On 10/16/2017 04:08 PM, Dinh Nguyen wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > > 
> > > > > > Generic firmware loader framework contains some common
> > > > > > functionality
> > > > > > which is reusable by any specific file system firmware
> > > > > > loader.
> > > > > > 
> > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > ---
> > > > > >  common/Makefile   |   2 +
> > > > > >  common/load_fs.c  | 163
> > > > > > ++
> > > > > >  include/load_fs.h |  40 ++
> > > > > >  3 files changed, 205 insertions(+)
> > > > > >  create mode 100644 common/load_fs.c
> > > > > >  create mode 100644 include/load_fs.h
> > > > > There is alot of change here and the commit message doesn't
> > > > > tell
> > > > > me anything! Please describe, in detail, what your patch is
> > > > > doing.
> > > > > 
> > > > > Also you need to include more people in the review path for
> > > > > this
> > > > > patch.
> > > These are the code factored out from splash loader, contains some
> > > common functions which can be used by other file system loader
> > > such as
> > > fpga loadfs.
> > Would it be possible to provide ./doc entry to explain how one can
> > use
> > this set of tools (splash/loadfs loaders) ?
> > 
> Sure. I will provide a./doc or comment in next version. Basically, the
> idea is factoring out the common code which specific handlle image in
> file format loading from flash to target(memory/device) between splash
> loader and fpga loadfs. So, you will see i have declared a few weak
> functions, which is used for defined speficic handling algorithm such
> as get_file, and fs_loading.
> 
> Initially, my plan is creating a more generic function name and
> geneirc file name, then replacing those splash_loader fs at separate
> patch set.
> 
> Now, i am working directly on splash loader. Anyway, i also like more
> discussion and good comments while i am working on it.

I've asked for a documentation, since I do have one idea in the back of
my head.

I'm wondering if other SoCs could benefit from this solution? For
example when we treat the FPGA as a DSP processor which needs to have
bitstream ( or better firmware ) loaded to some physical address. I'm
also wondering if your work would allow for start/stop of the code
execution?

It would be best to have some kind of common code and extensions per
soc/architecture.

I cannot help much with review/design phase since I know very little on
this particular Altera (up.. sorry Intel) solution.

Please add me to CC for your further work.

> 
> Thanks.
>  
> > > 
> > > Okay, i will include more peoples.
> > > > 
> > > > And pull it out of the series and convert the splash loader to
> > > > use
> > > > this.
> > > > It seems my comment about factoring out code from the splash
> > > > loader
> > > > was
> > > > ignored, sigh ...
> > > > 
> > > I didn't ignore your comment, i factored out the common code from
> > > splash loader and put in more generic function name and file name.
> > > Then, i will replace these generic fs loader with splash fs loader
> > > at
> > > different patchset.
> > > > 
> > > > > 
> > > > > 
> > > > > Dinh
> > > > > 
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > w...@denx.de



Best regards,

Lukasz Majewski

--

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

[U-Boot] [PATCH] gpt: Use cache aligned buffers for gpt_h and gpt_e

[Lukasz Majewski]

Before this patch one could receive following errors when executing
"gpt write" command on machine with cache enabled:

display5 factory > gpt write mmc ${mmcdev} ${partitions}
Writing GPT:
CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0]
CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8]
CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8]
CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0]
success!

To alleviate this problem - the calloc()s have been replaced with
malloc_cache_aligned() and memset().

After those changes the buffers are properly aligned (with both start
address and size) to SoC cache line.

Signed-off-by: Lukasz Majewski 
---

 disk/part_efi.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index 7862bee..f6f5bee 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -622,25 +622,27 @@ int gpt_fill_header(struct blk_desc *dev_desc, gpt_header 
*gpt_h,
 int gpt_restore(struct blk_desc *dev_desc, char *str_disk_guid,
disk_partition_t *partitions, int parts_count)
 {
-   int ret;
-
-   gpt_header *gpt_h = calloc(1, PAD_TO_BLOCKSIZE(sizeof(gpt_header),
-  dev_desc));
+   gpt_header *gpt_h;
gpt_entry *gpt_e;
+   int ret, size;
 
+   size = PAD_TO_BLOCKSIZE(sizeof(gpt_header), dev_desc);
+   gpt_h = malloc_cache_aligned(size);
if (gpt_h == NULL) {
printf("%s: calloc failed!\n", __func__);
return -1;
}
+   memset(gpt_h, 0, size);
 
-   gpt_e = calloc(1, PAD_TO_BLOCKSIZE(GPT_ENTRY_NUMBERS
-  * sizeof(gpt_entry),
-  dev_desc));
+   size = PAD_TO_BLOCKSIZE(GPT_ENTRY_NUMBERS * sizeof(gpt_entry),
+   dev_desc);
+   gpt_e = malloc_cache_aligned(size);
if (gpt_e == NULL) {
printf("%s: calloc failed!\n", __func__);
free(gpt_h);
return -1;
}
+   memset(gpt_e, 0, size);
 
/* Generate Primary GPT header (LBA1) */
ret = gpt_fill_header(dev_desc, gpt_h, str_disk_guid, parts_count);
-- 
2.1.4

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

[U-Boot] U-boot changes to bringup boot and secondary CPUs in HYP mode

[Jayadev Kumaran]

Hello all,

I am currently trying to bring up Xen on OMAP5432. When I try to boot the
board it shows








*Starting kernel ...- UART enabled -- CPU  booting -- Xen must be
entered in NS Hyp mode -- Please update the bootloader -- Boot failed -*
After applying the below patch , the boot CPU started loading.

diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 86c0e42..696da4b 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -19,7 +19,20 @@
  ENTRY(save_boot_params)
  ldrr1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
  strr0, [r1]
+/*
+ * Turn on hypervisor mode on CPU#0
+ */
+#ifdef CONFIG_DRA7XX_HYPERVISOR_ON
+movr0, lr@ This is a great place to switch into hyp mode
+@ only the r0 was needed from _start and is now
+@ free; all other general purpose registers were
+@ already free.
+ldrr12, =0x102@ Set PL310 control register - value in R0
+.word0xe1600070@ SMC #0 - hand assembled because -march=armv5
+@ call ROM Code API to set control register
+#else
  bxlr
+#endif /* CONFIG_DRA7XX_HYPERVISOR_ON */
  ENDPROC(save_boot_params)
   ENTRY(set_pl310_ctrl_reg)

However now the secondary CPUs fail to load;







*(XEN) Bringing up CPU1- CPU 0001 booting -- Xen must be entered in NS
Hyp mode -- Please update the bootloader -- Boot failed -*
Can someone provide the proper U-boot changes required to load the CPUs in
HYP mode

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

[U-Boot] Commands to use U-boot in fpga

[Ammu Lakshmy]

Hi,

I am new to U-Boot and I want to use it for dumping linux to a sparc
processor (leon2) which I have implemented in Spartan 3E fpga. Is it
possible?

This is to implement a router code in my processor.

-- 
Thanks & Regards,
Ammu Lakshmy R.
M.Tech. VLSI Design
VNIT, Nagpur
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RESEND] drivers/usb/ehci: Use platform-specific accessors

[Vladimir Boroda]

This patch should have been rejected.  It no longer breaks the build, but it 
break the functionality on big-endian systems. The readl() and writel() macros 
already do the endian conversion assuming the port is in little-endian format.  
So after this patch the EHCI registers are now read incorrectly, at least on 
PPC.  

You should remove the le32_to_cpu() macros if using the readl() and writel() 
accessors.  
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 5/5] sunxi: video: add LCD support to DE2 driver

[Anatolij Gustschin]

On Thu, 26 Oct 2017 21:51:52 -0700
Vasily Khoruzhick anars...@gmail.com wrote:

> Extend DE2 driver with LCD support. Tested on Pinebook which is based
> on A64 and has ANX6345 eDP bridge with eDP panel connected to it.
> 
> Signed-off-by: Vasily Khoruzhick 
> ---
> v4: - adapted to v4 changes in patch 4/5
> v3: - rebased and fixed checkpatch errors/warnings
> 
> v2: - drop redundant clock_set_pll10() call
> - fallback to timings from DT if reading EDID from bridge failed
> - read panel_bpp from DT
>  arch/arm/mach-sunxi/Kconfig |   2 +-
>  drivers/video/sunxi/Makefile|   2 +-
>  drivers/video/sunxi/sunxi_de2.c |  17 +
>  drivers/video/sunxi/sunxi_lcd.c | 152 
> 
>  4 files changed, 171 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/video/sunxi/sunxi_lcd.c

Applied to u-boot-video/master, thanks!

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

Re: [U-Boot] [PATCH v4 4/5] sunxi: video: split out PLL configuration code

[Anatolij Gustschin]

On Thu, 26 Oct 2017 21:51:51 -0700
Vasily Khoruzhick anars...@gmail.com wrote:

> It will be reused in new DM LCD driver.
> 
> Signed-off-by: Vasily Khoruzhick 
> ---
> v2-v3: no changes
> v4: - fix compilation for boards that use sunxi_display.c
> - rebased and fixed checkpatch errors
> 
>  arch/arm/include/asm/arch-sunxi/lcdc.h |   3 +
>  drivers/video/sunxi/lcdc.c | 122 +++-
>  drivers/video/sunxi/sunxi_display.c| 123 
> +++--
>  3 files changed, 132 insertions(+), 116 deletions(-)

Applied to u-boot-video/master, thanks!

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

Re: [U-Boot] [PATCH v3 3/5] video: add anx6345 DM driver

[Anatolij Gustschin]

On Thu, 26 Oct 2017 18:29:39 +0200
Anatolij Gustschin ag...@denx.de wrote:

> From: Vasily Khoruzhick 
> 
> This is a eDP bridge similar to ANX9804, it allows to connect eDP panels
> to the chips that can output only parallel signal
> 
> Signed-off-by: Vasily Khoruzhick 
> Signed-off-by: Anatolij Gustschin 
> ---
> v3: - fixed checkpatch errors/warnings
> v2: - no changes
> 
>  drivers/video/bridge/Kconfig   |   8 +
>  drivers/video/bridge/Makefile  |   1 +
>  drivers/video/bridge/anx6345.c | 426 
> +
>  3 files changed, 435 insertions(+)
>  create mode 100644 drivers/video/bridge/anx6345.c

Applied to u-boot-video/master, thanks!

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

Re: [U-Boot] [PATCH v3 2/5] video: anx9804: split out registers definitions into a separate header

[Anatolij Gustschin]

On Thu, 26 Oct 2017 18:26:43 +0200
Anatolij Gustschin ag...@denx.de wrote:

> From: Vasily Khoruzhick 
> 
> This header will be used in anx6345 driver
> 
> Signed-off-by: Vasily Khoruzhick 
> Signed-off-by: Anatolij Gustschin 
> ---
> v3: - moved header to drivers/video
> v2: - no changes
> 
>  drivers/video/anx9804.c | 54 +
>  drivers/video/anx98xx-edp.h | 98 
> +
>  2 files changed, 99 insertions(+), 53 deletions(-)
>  create mode 100644 drivers/video/anx98xx-edp.h

Applied to u-boot-video/master, thanks!

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

[U-Boot] [PATCH] sunxi: call fdt_fixup_ethernet again to set macaddr for more aliases

[Icenowy Zheng]

Sometimes some ethernet aliases do not exist in U-Boot FDT but they
exist in the FDT used to boot the system. In this situation
setup_environment is called again in ft_board_setup to generate macaddr
environment variable for them. However now the call to
fdt_fixup_ethernet is moved before the call of ft_board_setup.

Call fdt_fixup_ethernet again to add MAC addresses for the extra
ethernet aliases.

Signed-off-by: Icenowy Zheng 
---
 board/sunxi/board.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 6e13ee32c1..616a5f77f0 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -745,10 +745,12 @@ int ft_board_setup(void *blob, bd_t *bd)
int __maybe_unused r;
 
/*
-* Call setup_environment again in case the boot fdt has
-* ethernet aliases the u-boot copy does not have.
+* Call setup_environment and fdt_fixup_ethernet again
+* in case the boot fdt has ethernet aliases the u-boot
+* copy does not have.
 */
setup_environment(blob);
+   fdt_fixup_ethernet(blob);
 
 #ifdef CONFIG_VIDEO_DT_SIMPLEFB
r = sunxi_simplefb_setup(blob);
-- 
2.13.6

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

Re: [U-Boot] [PATCH v3 06/20] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Kha, 2017-10-26 at 14:51 +0200, Lukasz Majewski wrote:
> Tien Fong,
> 
> > 
> > On Isn, 2017-10-16 at 16:41 +0200, Marek Vasut wrote:
> > > 
> > > On 10/16/2017 04:08 PM, Dinh Nguyen wrote:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On 10/13/2017 03:08 AM, tien.fong.c...@intel.com wrote:
> > > > > 
> > > > > 
> > > > > From: Tien Fong Chee 
> > > > > 
> > > > > Generic firmware loader framework contains some common
> > > > > functionality
> > > > > which is reusable by any specific file system firmware
> > > > > loader.
> > > > > 
> > > > > Signed-off-by: Tien Fong Chee 
> > > > > ---
> > > > >  common/Makefile   |   2 +
> > > > >  common/load_fs.c  | 163
> > > > > ++
> > > > >  include/load_fs.h |  40 ++
> > > > >  3 files changed, 205 insertions(+)
> > > > >  create mode 100644 common/load_fs.c
> > > > >  create mode 100644 include/load_fs.h
> > > > There is alot of change here and the commit message doesn't
> > > > tell
> > > > me anything! Please describe, in detail, what your patch is
> > > > doing.
> > > > 
> > > > Also you need to include more people in the review path for
> > > > this
> > > > patch.
> > These are the code factored out from splash loader, contains some
> > common functions which can be used by other file system loader such
> > as
> > fpga loadfs.
> Would it be possible to provide ./doc entry to explain how one can
> use
> this set of tools (splash/loadfs loaders) ?
> 
Sure. I will provide a./doc or comment in next version. Basically, the
idea is factoring out the common code which specific handlle image in
file format loading from flash to target(memory/device) between splash
loader and fpga loadfs. So, you will see i have declared a few weak
functions, which is used for defined speficic handling algorithm such
as get_file, and fs_loading.

Initially, my plan is creating a more generic function name and geneirc
file name, then replacing those splash_loader fs at separate patch set.

Now, i am working directly on splash loader. Anyway, i also like more
discussion and good comments while i am working on it.

Thanks.
 
> > 
> > Okay, i will include more peoples.
> > > 
> > > And pull it out of the series and convert the splash loader to
> > > use
> > > this.
> > > It seems my comment about factoring out code from the splash
> > > loader
> > > was
> > > ignored, sigh ...
> > > 
> > I didn't ignore your comment, i factored out the common code from
> > splash loader and put in more generic function name and file name.
> > Then, i will replace these generic fs loader with splash fs loader
> > at
> > different patchset.
> > > 
> > > > 
> > > > 
> > > > Dinh
> > > > 
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] net: phy: marvell: Add functions to read PHY's extended registers

[Lukasz Majewski]

This commit allows extended Marvell registers to be read with:

foo > mdio rx FEC 3.10
Reading from bus FEC
PHY at address 0:
3.16 - 0x1063
foo > mdio wx FEC 3.10 0x1011

The above code changes the way ETH connector LEDs blink.

Signed-off-by: Lukasz Majewski 

---

Changes in v2:
- Provide the readext and writeext callbacks to other marvell ETH PHY
devices

 drivers/net/phy/marvell.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index b7f300e..19f451d 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -104,6 +104,31 @@
 #define MIIM_88E151x_MODE_SGMII1
 #define MIIM_88E151x_RESET_OFFS15
 
+static int m88e1xxx_phy_extread(struct phy_device *phydev, int addr,
+   int devaddr, int regnum)
+{
+   int oldpage = phy_read(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE);
+   int val;
+
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE, devaddr);
+   val = phy_read(phydev, MDIO_DEVAD_NONE, regnum);
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE, oldpage);
+
+   return val;
+}
+
+static int m88e1xxx_phy_extwrite(struct phy_device *phydev, int addr,
+int devaddr, int regnum, u16 val)
+{
+   int oldpage = phy_read(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE);
+
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE, devaddr);
+   phy_write(phydev, MDIO_DEVAD_NONE, regnum, val);
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_MARVELL_PHY_PAGE, oldpage);
+
+   return 0;
+}
+
 /* Marvell 88E1011S */
 static int m88e1011s_config(struct phy_device *phydev)
 {
@@ -599,6 +624,8 @@ static struct phy_driver M88E1011S_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88ES_driver = {
@@ -609,6 +636,8 @@ static struct phy_driver M88ES_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88E1118_driver = {
@@ -619,6 +648,8 @@ static struct phy_driver M88E1118_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88E1118R_driver = {
@@ -629,6 +660,8 @@ static struct phy_driver M88E1118R_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88E1121R_driver = {
@@ -639,6 +672,8 @@ static struct phy_driver M88E1121R_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88E1145_driver = {
@@ -649,6 +684,8 @@ static struct phy_driver M88E1145_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88E1149S_driver = {
@@ -659,6 +696,8 @@ static struct phy_driver M88E1149S_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88E1510_driver = {
@@ -669,6 +708,8 @@ static struct phy_driver M88E1510_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 /*
@@ -684,6 +725,8 @@ static struct phy_driver M88E1518_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88E1310_driver = {
@@ -694,6 +737,8 @@ static struct phy_driver M88E1310_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 static struct phy_driver M88E1680_driver = {
@@ -704,6 +749,8 @@ static struct phy_driver M88E1680_driver = {
.config = _config,
.startup = _startup,
.shutdown = _shutdown,
+   .readext = _phy_extread,
+   .writeext = _phy_extwrite,
 };
 
 int phy_marvell_init(void)
-- 
2.1.4

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

Re: [U-Boot] [PATCH 15/16] exynos: remove CONFIG_LCD_MENU_BOARD

[Minkyu Kang]

On 26/10/17 21:24, Masahiro Yamada wrote:
> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  include/configs/s5pc210_universal.h | 1 -
>  include/configs/trats.h | 1 -
>  include/configs/trats2.h| 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/include/configs/s5pc210_universal.h 
> b/include/configs/s5pc210_universal.h
> index 9859f30..7ecaefb 100644
> --- a/include/configs/s5pc210_universal.h
> +++ b/include/configs/s5pc210_universal.h
> @@ -170,7 +170,6 @@ int universal_spi_read(void);
>  
>  /* Download menu - Samsung common */
>  #define CONFIG_LCD_MENU
> -#define CONFIG_LCD_MENU_BOARD
>  
>  /* Download menu - definitions for check keys */
>  #ifndef __ASSEMBLY__
> diff --git a/include/configs/trats.h b/include/configs/trats.h
> index 5b33a3b..a34c349 100644
> --- a/include/configs/trats.h
> +++ b/include/configs/trats.h
> @@ -180,7 +180,6 @@
>  
>  /* Download menu - Samsung common */
>  #define CONFIG_LCD_MENU
> -#define CONFIG_LCD_MENU_BOARD
>  
>  /* Download menu - definitions for check keys */
>  #ifndef __ASSEMBLY__
> diff --git a/include/configs/trats2.h b/include/configs/trats2.h
> index 95c011f..6b371f4 100644
> --- a/include/configs/trats2.h
> +++ b/include/configs/trats2.h
> @@ -162,7 +162,6 @@
>  
>  /* Download menu - Samsung common */
>  #define CONFIG_LCD_MENU
> -#define CONFIG_LCD_MENU_BOARD
>  
>  /* Download menu - definitions for check keys */
>  #ifndef __ASSEMBLY__
> 


Acked-by: Minkyu Kang 

Thanks,
Minkyu Kang.

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

Re: [U-Boot] [PATCH 10/16] exynos: remove CONFIG_CORE_COUNT

[Minkyu Kang]

On 26/10/17 21:24, Masahiro Yamada wrote:
> This macro is defined, but not referenced by anyone.
> 
> I did not touch config_whitelist.txt - the CONFIG will be dropped
> by the next re-sync.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  include/configs/exynos5420-common.h | 5 -
>  include/configs/exynos7420-common.h | 3 ---
>  2 files changed, 8 deletions(-)
> 
> diff --git a/include/configs/exynos5420-common.h 
> b/include/configs/exynos5420-common.h
> index 79e6d13..ae9ead5 100644
> --- a/include/configs/exynos5420-common.h
> +++ b/include/configs/exynos5420-common.h
> @@ -43,11 +43,6 @@
>  #define CONFIG_LOWPOWER_FLAG 0x02020028
>  #define CONFIG_LOWPOWER_ADDR 0x0202002C
>  
> -/*
> - * Number of CPUs available
> - */
> -#define CONFIG_CORE_COUNT0x8
> -
>  #define CONFIG_USB_XHCI_EXYNOS
>  
>  #endif   /* __CONFIG_EXYNOS5420_H */
> diff --git a/include/configs/exynos7420-common.h 
> b/include/configs/exynos7420-common.h
> index 0aeec39..4e10471 100644
> --- a/include/configs/exynos7420-common.h
> +++ b/include/configs/exynos7420-common.h
> @@ -43,9 +43,6 @@
>  #define CONFIG_IRAM_END  (CONFIG_IRAM_BASE + 
> CONFIG_IRAM_SIZE)
>  #define CPU_RELEASE_ADDR secondary_boot_addr
>  
> -/* Number of CPUs available */
> -#define CONFIG_CORE_COUNT0x8
> -
>  /* select serial console configuration */
>  
>  #define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + 0x3E0)
> 

Acked-by: Minkyu Kang 

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

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

[Bin Meng]

Hi Tom,

This fixes a bunch of x86 breakages.

The following changes since commit 4c7a211046a3956058b512edd8533f7df031cc4a:

  Kconfig: add CONFIG_BROKEN (2017-10-23 17:28:18 -0400)

are available in the git repository at:

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

for you to fetch changes up to 411898dc87c09d0cd103a4243c8cb4a72b115c51:

  x86: acpi: Put sleepstates.asl to the common place (2017-10-27 15:13:47 +0800)


Bin Meng (9):
  x86: galileo: Fix boot failure
  x86: braswell: Fix unexpected crash during Linux kernel boot
  env: x86: braswell: Set ENV_IS_IN_SPI_FLASH as default
  x86: Fix ACPI resume dependency to MRC cache
  Revert "x86: fsp: Configure SPI opcode registers before SPI is
locked down"
  spi: ich: Lock down controller settings if required
  x86: braswell: cherryhill: Update dts for SPI lock down
  x86: fsp: graphics: Add some notes about the graphics info hob
  x86: acpi: Put sleepstates.asl to the common place

 arch/x86/Kconfig  |  10 +
 arch/x86/cpu/braswell/Kconfig |   5 ---
 arch/x86/cpu/braswell/Makefile|   2 +-
 arch/x86/cpu/braswell/cpu.c   | 170

 arch/x86/dts/cherryhill.dts   |  10 ++---
 arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl |   0
 arch/x86/include/asm/arch-baytrail/acpi/platform.asl  |   2 +-
 arch/x86/include/asm/arch-quark/acpi/platform.asl |   2 +-
 arch/x86/include/asm/arch-quark/acpi/sleepstates.asl  |  10 -
 arch/x86/lib/fsp/fsp_common.c |  24

 arch/x86/lib/fsp/fsp_graphics.c   |   4 ++
 configs/galileo_defconfig |   3 --
 drivers/spi/ich.c |  22 +++
 drivers/spi/ich.h |   1 +
 env/Kconfig   |   1 +
 15 files changed, 37 insertions(+), 229 deletions(-)
 delete mode 100644 arch/x86/cpu/braswell/cpu.c
 rename arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl (100%)
 delete mode 100644 arch/x86/include/asm/arch-quark/acpi/sleepstates.asl

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

Re: [U-Boot] [PATCH 5/9] Revert "x86: fsp: Configure SPI opcode registers before SPI is locked down"

[Bin Meng]

On Thu, Oct 19, 2017 at 9:20 AM, Bin Meng  wrote:
> This reverts commit 1e6ebee667da47fd3a87839a239a7574c66f5659.
>
> It's not appropriate to call the Intel SPI driver specific stuff in
> the FSP codes. We may add a simple DTS property "intel,spi-lock-down"
> and let the Intel SPI driver call these stuff instead.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/Kconfig  |  9 -
>  arch/x86/lib/fsp/fsp_common.c | 24 
>  2 files changed, 33 deletions(-)
>

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

Re: [U-Boot] [PATCH 7/9] x86: braswell: cherryhill: Update dts for SPI lock down

[Bin Meng]

On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass  wrote:
> On 19 October 2017 at 03:20, Bin Meng  wrote:
>> Intel Braswell FSP requires SPI controller settings to be locked down,
>> let's do this in the chrryhill.dts and remove previous Kconfig option.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/cpu/braswell/Kconfig | 4 
>>  arch/x86/dts/cherryhill.dts   | 1 +
>>  2 files changed, 1 insertion(+), 4 deletions(-)
>
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 9/9] x86: acpi: Put sleepstates.asl to the common place

[Bin Meng]

On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass  wrote:
> On 19 October 2017 at 03:21, Bin Meng  wrote:
>> The supported sleep states are generic on Intel processors. Move the
>> ASL definition to the common place.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl |  0
>>  arch/x86/include/asm/arch-baytrail/acpi/platform.asl  |  2 +-
>>  arch/x86/include/asm/arch-quark/acpi/platform.asl |  2 +-
>>  arch/x86/include/asm/arch-quark/acpi/sleepstates.asl  | 10 
>> --
>>  4 files changed, 2 insertions(+), 12 deletions(-)
>>  rename arch/x86/include/asm/{arch-baytrail => }/acpi/sleepstates.asl (100%)
>>  delete mode 100644 arch/x86/include/asm/arch-quark/acpi/sleepstates.asl
>
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 4/9] x86: Fix ACPI resume dependency to MRC cache

[Bin Meng]

On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass  wrote:
> On 19 October 2017 at 03:20, Bin Meng  wrote:
>> In an S3 resume path, MRC cache is mandatory. Enforce the dependency
>> in the Kconfig.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 8/9] x86: fsp: graphics: Add some notes about the graphics info hob

[Bin Meng]

On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass  wrote:
> On 19 October 2017 at 03:20, Bin Meng  wrote:
>> On some platforms (eg: Braswell), the FSP will not produce the
>> graphics info HOB unless you plug some cables to the display
>> interface (eg: HDMI) on the board. Add such notes in the FSP
>> video driver.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/lib/fsp/fsp_graphics.c | 4 
>>  1 file changed, 4 insertions(+)
>
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 6/9] spi: ich: Lock down controller settings if required

[Bin Meng]

On Mon, Oct 23, 2017 at 9:32 AM, Bin Meng  wrote:
> Hi Simon,
>
> On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass  wrote:
>> On 19 October 2017 at 03:20, Bin Meng  wrote:
>>> Some Intel FSP (like Braswell) does SPI lock-down during the call
>>> to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done,
>>> it's bootloader's responsibility to configure the SPI controller's
>>> opcode registers properly otherwise SPI controller driver doesn't
>>> know how to communicate with the SPI flash device.
>>>
>>> Rather than passively doing the opcode configuration, let's add a
>>> simple DTS property "intel,spi-lock-down" and let the driver call
>>> the opcode configuration function if required by such FSP.
>>>
>>> Signed-off-by: Bin Meng 
>>> ---
>>>
>>>  drivers/spi/ich.c | 22 ++
>>>  drivers/spi/ich.h |  1 +
>>>  2 files changed, 23 insertions(+)
>>
>> Does this go in a binding file somewhere?
>>
>
> Looks there is no binding file for Intel SPI controller driver. We
> will need create one.
>
>> Reviewed-by: Simon Glass 
>

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

Re: [U-Boot] [PATCH 2/9] x86: braswell: Fix unexpected crash during Linux kernel boot

[Bin Meng]

On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass  wrote:
> On 19 October 2017 at 03:20, Bin Meng  wrote:
>> It was observed that when booting Linux kernel on Intel Cherry Hill
>> board, unexpected crash happens quite randomly. Sometimes kernel
>> just oops, while sometimes kernel throws MCE errors and hangs:
>>
>>   mce: [Hardware Error]: Machine check events logged
>>   mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: c4010151
>>   mce: [Hardware Error]: TSC 0 ADDR 130f3f2c0
>>   mce: [Hardware Error]: PROCESSOR 0:406c3 TIME 1508160686 SOCKET 0 APIC 0 
>> microcode 363
>>
>> This looks like a hardware error per mcelog. After debugging, it
>> seems turning off turbo mode on the processor does not expose this
>> behavior, although U-Boot runs OK with turbo mode on. Suspect it is
>> related to an errata of Braswell processor.
>>
>> To fix this, remove the Braswell cpu driver which does the turbo
>> mode configuration, and switch to use the generic cpu-x86 driver.
>> Also there is a configuration option in the FSP that turns on the
>> turbo mode and that has been turned off too.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/cpu/braswell/Makefile |   2 +-
>>  arch/x86/cpu/braswell/cpu.c| 170 
>> -
>>  arch/x86/dts/cherryhill.dts|   9 +--
>>  3 files changed, 5 insertions(+), 176 deletions(-)
>>  delete mode 100644 arch/x86/cpu/braswell/cpu.c
>
> Oh dear, what a sad patch.
>
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 3/9] env: x86: braswell: Set ENV_IS_IN_SPI_FLASH as default

[Bin Meng]

On Sun, Oct 22, 2017 at 10:36 PM, Simon Glass  wrote:
> On 19 October 2017 at 03:20, Bin Meng  wrote:
>> Imply does not work for a Kconfig choice. Update ENV_IS_IN_SPI_FLASH
>> to be the default one for Intel Braswell.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/cpu/braswell/Kconfig | 1 -
>>  env/Kconfig   | 1 +
>>  2 files changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 1/9] x86: galileo: Fix boot failure

[Bin Meng]

On Thu, Oct 19, 2017 at 9:20 AM, Bin Meng  wrote:
> With latest codes on mainstream master, Intel Galileo board does not
> boot unfortunately. Git biset leads to b383d6c0 "bootstage: Convert
> to use malloc()".
>
> Disable bootstage support to make it boot again. The root cause needs
> to be investigated however.
>
> Fixes: b383d6c0 ("bootstage: Convert to use malloc()")
> Signed-off-by: Bin Meng 
> ---
>
>  configs/galileo_defconfig | 3 ---
>  1 file changed, 3 deletions(-)
>

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

[U-Boot] [PATCH 1/2] tools: image: allow to sign image nodes without -K option

[Masahiro Yamada]

If -K option is missing when you sign image nodes, it fails with
an unclear error message:

  tools/mkimage Can't add hashes to FIT blob: -1

It is hard to figure out the cause of the failure.

In contrast, when you sign configuration nodes, -K is optional because
fit_config_process_sig() returns successfully if keydest is unset.
Probably this is a preferred behavior when you want to update FIT with
the same key; you do not have to update the public key in this case.

So, this commit changes fit_image_process_sig() to continue signing
without keydest.  If ->add_verify_data() fails, show a clearer error
message, which has been borrowed from fit_config_process_sig().

Signed-off-by: Masahiro Yamada 
---

 tools/image-host.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/image-host.c b/tools/image-host.c
index ad9a73a..d42c1ca 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -242,18 +242,19 @@ static int fit_image_process_sig(const char *keydir, void 
*keydest,
/* Get keyname again, as FDT has changed and invalidated our pointer */
info.keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);
 
-   if (keydest)
-   ret = info.crypto->add_verify_data(, keydest);
-   else
-   return -1;
-
/*
 * Write the public key into the supplied FDT file; this might fail
 * several times, since we try signing with successively increasing
 * size values
 */
-   if (keydest && ret)
-   return ret;
+   if (keydest) {
+   ret = info.crypto->add_verify_data(, keydest);
+   if (ret) {
+   printf("Failed to add verification data for '%s' 
signature node in '%s' image node\n",
+  node_name, image_name);
+   return ret;
+   }
+   }
 
return 0;
 }
-- 
2.7.4

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

[U-Boot] [PATCH 2/2] tools: image: fix message when fail to add verification data for config

[Masahiro Yamada]

This function is called when signing configuration nodes.  Adjust
the error message.

I do not know why we do not need to show the error message in case of
ENOSPC.  Remove the if-conditional that seems unnecessary.

Signed-off-by: Masahiro Yamada 
---

 tools/image-host.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/image-host.c b/tools/image-host.c
index d42c1ca..2c0030b 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -626,10 +626,8 @@ static int fit_config_process_sig(const char *keydir, void 
*keydest,
/* Write the public key into the supplied FDT file */
if (keydest) {
ret = info.crypto->add_verify_data(, keydest);
-   if (ret == -ENOSPC)
-   return -ENOSPC;
if (ret) {
-   printf("Failed to add verification data for '%s' 
signature node in '%s' image node\n",
+   printf("Failed to add verification data for '%s' 
signature node in '%s' configuration node\n",
   node_name, conf_name);
}
return ret;
-- 
2.7.4

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