Re: [U-Boot] [[PATCH v2] 5/8] sunxi: musb: Enable OTG device clock for H3

2018-01-27 Thread Jagan Teki
On Fri, Jan 5, 2018 at 9:45 PM, Jun Nie  wrote:
> Enable OTG clock and deassert reset
>
> Signed-off-by: Jun Nie 
> ---
>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 1 +
>  drivers/usb/musb-new/sunxi.c  | 6 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index 2c82d0a..624d624 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -279,6 +279,7 @@ struct sunxi_ccm_reg {
>  #define AHB_GATE_OFFSET_USB_EHCI2  26
>  #define AHB_GATE_OFFSET_USB_EHCI1  25
>  #define AHB_GATE_OFFSET_USB_EHCI0  24
> +#define AHB_GATE_OFFSET_OTG_DEVICE 23
>  #else
>  #define AHB_GATE_OFFSET_USB_OHCI1  30
>  #define AHB_GATE_OFFSET_USB_OHCI0  29
> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> index 0005c1e..ce7365b 100644
> --- a/drivers/usb/musb-new/sunxi.c
> +++ b/drivers/usb/musb-new/sunxi.c
> @@ -264,7 +264,10 @@ static int sunxi_musb_init(struct musb *musb)
>
> setbits_le32(>ahb_gate0, 1 << AHB_GATE_OFFSET_USB0);
>  #ifdef CONFIG_SUNXI_GEN_SUN6I
> -   setbits_le32(>ahb_reset0_cfg, 1 << AHB_GATE_OFFSET_USB0);
> +   setbits_le32(>ahb_gate0, BIT(AHB_GATE_OFFSET_OTG_DEVICE));
> +   setbits_le32(>ahb_reset0_cfg,
> +BIT(AHB_GATE_OFFSET_USB0) |
> +BIT(AHB_GATE_OFFSET_OTG_DEVICE));

This can certainly failed for other sun6i, because of no
AHB_GATE_OFFSET_OTG_DEVICE
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/1] efi_loader: add a README.iscsi describing booting via iSCSI

2018-01-27 Thread Alexander Graf


On 26.01.18 20:52, Heinrich Schuchardt wrote:
> The appended README explains how U-Boot and iPXE can be used
> to boot a diskless system from an iSCSI SAN.
> 
> The maintainer for README.efi and README.iscsi is set.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2
>   mention work on TCP and wget
>   remove VLAN drawing
>   fix reference of EFI service used by Grub
> ---
>  MAINTAINERS   |   2 +
>  doc/README.iscsi  | 159 
> ++
>  lib/efi_loader/efi_file.c |   9 +++

I'm quite sure you did not mean to send those changes along as well ;).

>  3 files changed, 170 insertions(+)
>  create mode 100644 doc/README.iscsi
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d459153503..6e94cee5d3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -286,6 +286,8 @@ EFI PAYLOAD
>  M:   Alexander Graf 
>  S:   Maintained
>  T:   git git://github.com/agraf/u-boot.git
> +F:   doc/README.efi

Not sure I want to maintain README.efi in its current state. How about
we just leave this part to your other patch?

> +F:   doc/README.iscsi
>  F:   include/efi*
>  F:   lib/efi*/
>  F:   test/py/tests/test_efi*
> diff --git a/doc/README.iscsi b/doc/README.iscsi
> new file mode 100644
> index 00..a731c06feb
> --- /dev/null
> +++ b/doc/README.iscsi
> @@ -0,0 +1,159 @@
> +# iSCSI booting with U-Boot and iPXE
> +
> +## Motivation
> +
> +U-Boot has only a reduced set of supported network protocols. The focus for
> +network booting has been on UDP based protocols. A TCP stack and HTTP support
> +are expected to be integrated in 2018 together with a wget command.
> +
> +For booting a diskless computer this leaves us with BOOTP or DHCP to get the
> +address of a boot script. TFTP or NFS can be used to load the boot script, 
> the
> +operating system kernel and the initial file system (initrd).
> +
> +These protocols are insecure. The client cannot validate the authenticity
> +of the contacted servers. And the server cannot verify the identity of the
> +client.
> +
> +Furthermore the services providing the operating system loader or kernel are
> +not the ones that the operating system typically will use. Especially in a 
> SAN
> +environment this makes updating the operating system a hassle. After 
> installing
> +a new kernel version the boot files have to be copied to the TFTP server
> +directory.
> +
> +The HTTPS protocol provides certificate based validation of servers. 
> Sensitive
> +data like passwords can be securely transmitted.
> +
> +The iSCSI protocol is used for connecting storage attached networks. It
> +provides mutual authentication using the CHAP protocol. It typically runs on
> +a TCP transport.
> +
> +Thus a better solution than DHCP/TFTP/NFS boot would be to load a boot script
> +via HTTPS and to download any other files needed for booting via iSCSI from 
> the
> +same target where the operating system is installed.
> +
> +An alternative to implementing these protocols in U-Boot is to use an 
> existing
> +software that can run on top of U-Boot. iPXE is the "swiss army knife" of
> +network booting. It supports both HTTPS and iSCSI. It has a scripting engine 
> for
> +fine grained control of the boot process and can provide a command shell.
> +
> +iPXE can be built as an EFI application (named snp.efi) which can be loaded 
> and
> +run by U-Boot.
> +
> +## Boot sequence
> +
> +U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This
> +application has network access via the simple network protocol offered by
> +U-Boot.
> +
> +iPXE executes its internal script. This script may optionally chain load a
> +secondary boot script via HTTPS or open a shell.
> +
> +For the further boot process iPXE connects to the iSCSI server. This includes
> +the mutual authentication using the CHAP protocol. After the authentication 
> iPXE
> +has access to the iSCSI targets.
> +
> +For a selected iSCSI target iPXE sets up a handle with the block IO 
> protocol. It
> +uses the ConnectController boot service of U-Boot to request U-Boot to 
> connect a
> +file system driver. U-Boot reads from the iSCSI drive via the block IO 
> protocol
> +offered by iPXE. It creates the partition handles and installs the simple 
> file
> +protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot 
> uses
> +the block IO protocol offered by iPXE to fulfill the request.
> +
> +Once Grub is started it uses the same block IO protocol to load Linux. Via
> +the EFI stub Linux is called as an EFI application.
> +
> +```
> +   ++  ++
> +   || Runs ||
> +   | U-Boot |=>| iPXE   |
> +   | EFI|  | snp.efi|
> +++ || DHCP ||
> +||<||<=||
> +| DHCP   | || Get IP   ||
> +| Server | || Adress   ||
> +| 

[U-Boot] [PATCH] net: sun8i_emac: Fix PHY initialization

2018-01-27 Thread Samuel Holland
The previous code tried to update the PHY parameters without waiting for
autonegotiation to complete. This caused wrong values to be written to
the EMAC in sun8i_adjust_link(). As a result, any commands that called
eth_start() before autonegotiation completed would find the network
nonfunctional. Fix this by using the correct function to start up the
PHY.

Signed-off-by: Samuel Holland 
---
 drivers/net/sun8i_emac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 3ccc6b0bb6..be43472b1a 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -431,7 +431,7 @@ static int _sun8i_emac_eth_init(struct emac_eth_dev *priv, 
u8 *enetaddr)
tx_descs_init(priv);
 
/* PHY Start Up */
-   genphy_parse_link(priv->phydev);
+   phy_startup(priv->phydev);
 
sun8i_adjust_link(priv, priv->phydev);
 
-- 
2.13.6

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


Re: [U-Boot] [PULL] u-boot-sh/rmobile-mx

2018-01-27 Thread Tom Rini
On Sat, Jan 27, 2018 at 08:40:49PM +0100, Marek Vasut wrote:

> The following changes since commit 16121280188d3daa57b18ad623d08455a90a:
> 
>   Merge git://git.denx.de/u-boot-fsl-qoriq (2018-01-23 21:48:53 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git rmobile-mx
> 
> for you to fetch changes up to 789edf694c63a6eff1188b3672af7d0228a1a0d9:
> 
>   ARM: rmobile: Convert R8A7791 Porter board to DM and DT (2018-01-27
> 20:38:54 +0100)
> 

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-uniphier/master

2018-01-27 Thread Tom Rini
On Sun, Jan 28, 2018 at 06:40:34AM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> Please pull one more patch for -rc1.
> Thanks!
> 
> 
> The following changes since commit 0163c9186b161682a46bd7ae3c2e6ffe275bb1f8:
> 
>   env: sunxi: Enable FAT-based environment support by default
> (2018-01-27 09:23:32 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-uniphier.git master
> 
> for you to fetch changes up to 7d8cca7be615dcd911121b8ebdc2def2cccb6b37:
> 
>   ARM: uniphier: enable HS200 support for uniphier_v8_defconfig
> (2018-01-28 06:32:50 +0900)
> 

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

2018-01-27 Thread Tom Rini
On Sat, Jan 27, 2018 at 08:38:19PM +0100, Marek Vasut wrote:

> The following changes since commit fb4413295c765aa8c013650984dc2d908964c81d:
> 
>   Merge git://git.denx.de/u-boot-mmc (2018-01-24 11:28:44 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 6f7c92db4c7d1e45503fb10e60caa1ec2bb18d10:
> 
>   usb: ehci: mxs: fix swapped argument in ehci_writel() (2018-01-25
> 20:59:20 +0100)
> 

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

2018-01-27 Thread Tom Rini
On Sat, Jan 27, 2018 at 08:37:48PM +0100, Marek Vasut wrote:

> The following changes since commit fb4413295c765aa8c013650984dc2d908964c81d:
> 
>   Merge git://git.denx.de/u-boot-mmc (2018-01-24 11:28:44 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to 92962b3caf17f5e64075601a466b3ac00dbd0a88:
> 
>   ddr: altera: silence PHY calibration unless in debug mode (2018-01-25
> 09:59:37 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] usb: host: Drop unused hcd_name from r8a66597-hcd.c

2018-01-27 Thread Marek Vasut
On 01/27/2018 09:22 PM, Tom Rini wrote:
> The variable hcd_name is unsued, drop.
> 
> Cc: Marek Vasut 
> Cc: Chris Brandt 
> Signed-off-by: Tom Rini 

Applied, thanks


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


Re: [U-Boot] [PATCH] usb: Remove isp116x-hcd support

2018-01-27 Thread Marek Vasut
On 01/27/2018 09:21 PM, Tom Rini wrote:
> The isp116x-hcd driver is extremely long unused, so just remove it.
> 
> Cc: Marek Vasut 
> Signed-off-by: Tom Rini 

Applied, thanks

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


Re: [U-Boot] [PATCH v2 3/4] fs: btrfs: Fix printf format character warning

2018-01-27 Thread Marek Behun
Reviewed-by: Marek Behun 

On Sat, 27 Jan 2018 17:23:21 -0500
Tom Rini  wrote:

> When printing a size_t value we need to use %zu for portability
> between 32bit and 64bit targets.
> 
> Cc: Marek Behún 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - Drop u32 cast, per Marek.
> ---
>  fs/btrfs/super.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 2529c2b3b6a6..7e2528c4fb6f 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -147,8 +147,8 @@ static int btrfs_check_super(struct
> btrfs_super_block *sb) 
>   if (sb->sys_chunk_array_size < sizeof(struct btrfs_key) +
>   sizeof(struct btrfs_chunk)) {
> - printf("%s: system chunk array too small %u <
> %lu\n", __func__,
> -sb->sys_chunk_array_size, (u32) sizeof(struct
> btrfs_key)
> + printf("%s: system chunk array too small %u <
> %zu\n", __func__,
> +sb->sys_chunk_array_size, sizeof(struct
> btrfs_key)
>  + sizeof(struct btrfs_chunk));
>   ret = -1;
>   }

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


[U-Boot] [PATCH v2 3/4] fs: btrfs: Fix printf format character warning

2018-01-27 Thread Tom Rini
When printing a size_t value we need to use %zu for portability between
32bit and 64bit targets.

Cc: Marek Behún 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Drop u32 cast, per Marek.
---
 fs/btrfs/super.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 2529c2b3b6a6..7e2528c4fb6f 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -147,8 +147,8 @@ static int btrfs_check_super(struct btrfs_super_block *sb)
 
if (sb->sys_chunk_array_size < sizeof(struct btrfs_key) +
sizeof(struct btrfs_chunk)) {
-   printf("%s: system chunk array too small %u < %lu\n", __func__,
-  sb->sys_chunk_array_size, (u32) sizeof(struct btrfs_key)
+   printf("%s: system chunk array too small %u < %zu\n", __func__,
+  sb->sys_chunk_array_size, sizeof(struct btrfs_key)
   + sizeof(struct btrfs_chunk));
ret = -1;
}
-- 
2.7.4

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


Re: [U-Boot] [PATCH 3/4] fs: btrfs: Fix printf format character warning

2018-01-27 Thread Marek Behun
shouldn't in that case the (u32) cast be removed?

On Sat, 27 Jan 2018 14:48:10 -0500
Tom Rini  wrote:

> When printing a size_t value we need to use %zu for portability
> between 32bit and 64bit targets.
> 
> Cc: Marek Behún 
> Signed-off-by: Tom Rini 
> ---
>  fs/btrfs/super.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 2529c2b3b6a6..b0a5cffce31e 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -147,7 +147,7 @@ static int btrfs_check_super(struct
> btrfs_super_block *sb) 
>   if (sb->sys_chunk_array_size < sizeof(struct btrfs_key) +
>   sizeof(struct btrfs_chunk)) {
> - printf("%s: system chunk array too small %u <
> %lu\n", __func__,
> + printf("%s: system chunk array too small %u <
> %zu\n", __func__, sb->sys_chunk_array_size, (u32) sizeof(struct
> btrfs_key)
>  + sizeof(struct btrfs_chunk));
>   ret = -1;

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


[U-Boot] u-boot mkimage tool generates wrong-endianness header when run on big endian, resulting in unbootable image

2018-01-27 Thread Justin Hibbits
Hi,

When trying to build a kernel uIimage for PowerPC, on a PoewrPC host,
mkimage generates a header that appears to be in Little-endian, rather
than Big-endian, resulting in an unbootable uImage.

From a correct build (NetBSD's mkubootimage):

: 2705 1956 ae84 7a0b 5a55 38e5 010e d6f8  '..V..z.ZU8.
0010: 03ff ffc0 0400 3000 cf58 6adf 0507 0200  ..0..Xj.
0020: 4672 6565 4253 4420 616d 6967 6136 3400  FreeBSD amiga64.
0030:          

Same image header, from mkimage:

: 5619 0527 92c5 020e 1df5 6c5a f8d6 0e01  V..'..lZ
0010: c0ff ff03 0030 0004 7642 4b26 0507 0200  .0..vBK&
0020:          
0030:          


I checked the mkimage source, but couldn't find anything obviously
wrong, so maybe someone else can see it.

The host system is a PowerPC (PowerMac G5), and the target is a PowerPC e5500.

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


Re: [U-Boot] [PATCH v1] spl: eMMC/SD: Provide one __weak spl_boot_mode() function

2018-01-27 Thread Lukasz Majewski
Hi Marek,

> On 01/27/2018 10:55 PM, Lukasz Majewski wrote:
> > The goal of this patch is to clean up the code related to choosing
> > spl MMC boot mode.
> > 
> > The spl_boot_mode() now is called only in spl_mmc_load_image()
> > function, which is only compiled in if CONFIG_SPL_MMC_SUPPORT is
> > enabled.  
> 
> It always was ;-)

But some way forgotten :-)

> 
> > To achieve the goal, all per mach/arch implementations eligible for
> > unification has been replaced with one __weak implementation.
> > 
> > Signed-off-by: Lukasz Majewski 
> > 
> > ---
> > Comments regarding cleanup (to help maintainers assessment if those
> > changes break anything):  
> 
> You should run it through Travis at least, to detect if something
> stopped building.

https://travis-ci.org/lmajewski/u-boot-dfu

All "green".

> 
> > Implementations necessary to stay as is:
> > 
> > - SW fix for broken ROM boot code
> > arch/arm/mach-uniphier/mmc-boot-mode.c
> > 
> > - Omap specific adjustments:
> > arch/arm/mach-omap2/boot-common.c
> > 
> > Below archs had a bit off-standard approach, but were eligible for
> > using the __weak function:
> > 
> > - at91 -> check if proper configs flags in the weak function are
> > set: arch/arm/mach-at91/spl.c
> > 
> > - zyncmp -> the BOOT_DEVICE_RAM return of spl_boot_mode seems like
> > an error (will hang in spl_mmc_load_image() anyway)
> > arch/arm/cpu/armv8/zynqmp/spl.c
> > 
> > - fsl -> here we had a return of BOOT_DEVICE_NAND, but the
> > spl_boot_mode is eMMC/SD card specific
> > (will hang in spl_mmc_load_image() anyway)
> > 
> > arch/arm/cpu/armv8/fsl-layerscape/spl.c
> > arch/arm/cpu/armv7/ls102xa/spl.c
> > arch/arm/cpu/arm1136/mx35/generic.c
> > 
> > Test HW:
> > 
> > iMX6Q - display5 board  
> Reviewed-by: Marek Vasut 
> 




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


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


Re: [U-Boot] [PATCH v1] spl: eMMC/SD: Provide one __weak spl_boot_mode() function

2018-01-27 Thread Marek Vasut
On 01/27/2018 10:55 PM, Lukasz Majewski wrote:
> The goal of this patch is to clean up the code related to choosing spl
> MMC boot mode.
> 
> The spl_boot_mode() now is called only in spl_mmc_load_image() function,
> which is only compiled in if CONFIG_SPL_MMC_SUPPORT is enabled.

It always was ;-)

> To achieve the goal, all per mach/arch implementations eligible for
> unification has been replaced with one __weak implementation.
> 
> Signed-off-by: Lukasz Majewski 
> 
> ---
> Comments regarding cleanup (to help maintainers assessment if those changes
> break anything):

You should run it through Travis at least, to detect if something
stopped building.

> Implementations necessary to stay as is:
> 
> - SW fix for broken ROM boot code
> arch/arm/mach-uniphier/mmc-boot-mode.c
> 
> - Omap specific adjustments:
> arch/arm/mach-omap2/boot-common.c
> 
> Below archs had a bit off-standard approach, but were eligible for using
> the __weak function:
> 
> - at91 -> check if proper configs flags in the weak function are set:
> arch/arm/mach-at91/spl.c
> 
> - zyncmp -> the BOOT_DEVICE_RAM return of spl_boot_mode seems like an error
> (will hang in spl_mmc_load_image() anyway)
> arch/arm/cpu/armv8/zynqmp/spl.c
> 
> - fsl -> here we had a return of BOOT_DEVICE_NAND, but the spl_boot_mode is
> eMMC/SD card specific
> (will hang in spl_mmc_load_image() anyway)
> 
> arch/arm/cpu/armv8/fsl-layerscape/spl.c
> arch/arm/cpu/armv7/ls102xa/spl.c
> arch/arm/cpu/arm1136/mx35/generic.c
> 
> Test HW:
> 
> iMX6Q - display5 board
Reviewed-by: Marek Vasut 

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


[U-Boot] [PATCH v1] spl: eMMC/SD: Provide one __weak spl_boot_mode() function

2018-01-27 Thread Lukasz Majewski
The goal of this patch is to clean up the code related to choosing spl
MMC boot mode.

The spl_boot_mode() now is called only in spl_mmc_load_image() function,
which is only compiled in if CONFIG_SPL_MMC_SUPPORT is enabled.

To achieve the goal, all per mach/arch implementations eligible for
unification has been replaced with one __weak implementation.

Signed-off-by: Lukasz Majewski 

---
Comments regarding cleanup (to help maintainers assessment if those changes
break anything):

Implementations necessary to stay as is:

- SW fix for broken ROM boot code
arch/arm/mach-uniphier/mmc-boot-mode.c

- Omap specific adjustments:
arch/arm/mach-omap2/boot-common.c

Below archs had a bit off-standard approach, but were eligible for using
the __weak function:

- at91 -> check if proper configs flags in the weak function are set:
arch/arm/mach-at91/spl.c

- zyncmp -> the BOOT_DEVICE_RAM return of spl_boot_mode seems like an error
(will hang in spl_mmc_load_image() anyway)
arch/arm/cpu/armv8/zynqmp/spl.c

- fsl -> here we had a return of BOOT_DEVICE_NAND, but the spl_boot_mode is
eMMC/SD card specific
(will hang in spl_mmc_load_image() anyway)

arch/arm/cpu/armv8/fsl-layerscape/spl.c
arch/arm/cpu/armv7/ls102xa/spl.c
arch/arm/cpu/arm1136/mx35/generic.c

Test HW:

iMX6Q - display5 board

---
 arch/arm/cpu/arm1136/mx35/generic.c   | 21 -
 arch/arm/cpu/armv7/ls102xa/spl.c  | 17 -
 arch/arm/cpu/armv8/fsl-layerscape/spl.c   | 17 -
 arch/arm/cpu/armv8/zynqmp/spl.c   | 14 --
 arch/arm/mach-at91/spl.c  | 15 ---
 arch/arm/mach-davinci/spl.c   |  5 -
 arch/arm/mach-imx/spl.c   | 23 ---
 arch/arm/mach-mvebu/spl.c |  7 ---
 arch/arm/mach-rockchip/rk3188-board-spl.c |  5 -
 arch/arm/mach-rockchip/rk3288-board-spl.c |  5 -
 arch/arm/mach-rockchip/rk3368-board-spl.c |  5 -
 arch/arm/mach-rockchip/rk3399-board-spl.c |  5 -
 arch/arm/mach-socfpga/spl.c   | 11 ---
 arch/arm/mach-sunxi/board.c   |  6 --
 arch/arm/mach-zynq/spl.c  |  7 ---
 common/spl/spl_mmc.c  | 11 +++
 16 files changed, 11 insertions(+), 163 deletions(-)

diff --git a/arch/arm/cpu/arm1136/mx35/generic.c 
b/arch/arm/cpu/arm1136/mx35/generic.c
index 5297d62d00..4dcfc72656 100644
--- a/arch/arm/cpu/arm1136/mx35/generic.c
+++ b/arch/arm/cpu/arm1136/mx35/generic.c
@@ -524,24 +524,3 @@ u32 spl_boot_device(void)
 
return BOOT_DEVICE_NONE;
 }
-
-#ifdef CONFIG_SPL_BUILD
-u32 spl_boot_mode(const u32 boot_device)
-{
-   switch (spl_boot_device()) {
-   case BOOT_DEVICE_MMC1:
-#ifdef CONFIG_SPL_FAT_SUPPORT
-   return MMCSD_MODE_FS;
-#else
-   return MMCSD_MODE_RAW;
-#endif
-   break;
-   case BOOT_DEVICE_NAND:
-   return 0;
-   break;
-   default:
-   puts("spl: ERROR:  unsupported device\n");
-   hang();
-   }
-}
-#endif
diff --git a/arch/arm/cpu/armv7/ls102xa/spl.c b/arch/arm/cpu/armv7/ls102xa/spl.c
index 1246eed2ca..1e4a1641cb 100644
--- a/arch/arm/cpu/armv7/ls102xa/spl.c
+++ b/arch/arm/cpu/armv7/ls102xa/spl.c
@@ -14,20 +14,3 @@ u32 spl_boot_device(void)
 #endif
return BOOT_DEVICE_NAND;
 }
-
-u32 spl_boot_mode(const u32 boot_device)
-{
-   switch (spl_boot_device()) {
-   case BOOT_DEVICE_MMC1:
-#ifdef CONFIG_SPL_FAT_SUPPORT
-   return MMCSD_MODE_FS;
-#else
-   return MMCSD_MODE_RAW;
-#endif
-   case BOOT_DEVICE_NAND:
-   return 0;
-   default:
-   puts("spl: error: unsupported device\n");
-   hang();
-   }
-}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c 
b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
index 4093d15e56..3a74040b97 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
@@ -26,23 +26,6 @@ u32 spl_boot_device(void)
return 0;
 }
 
-u32 spl_boot_mode(const u32 boot_device)
-{
-   switch (spl_boot_device()) {
-   case BOOT_DEVICE_MMC1:
-#ifdef CONFIG_SPL_FAT_SUPPORT
-   return MMCSD_MODE_FS;
-#else
-   return MMCSD_MODE_RAW;
-#endif
-   case BOOT_DEVICE_NAND:
-   return 0;
-   default:
-   puts("spl: error: unsupported device\n");
-   hang();
-   }
-}
-
 #ifdef CONFIG_SPL_BUILD
 
 void spl_board_init(void)
diff --git a/arch/arm/cpu/armv8/zynqmp/spl.c b/arch/arm/cpu/armv8/zynqmp/spl.c
index 41b0070a5e..970ac9b59b 100644
--- a/arch/arm/cpu/armv8/zynqmp/spl.c
+++ b/arch/arm/cpu/armv8/zynqmp/spl.c
@@ -115,20 +115,6 @@ u32 spl_boot_device(void)
return 0;
 }
 
-u32 spl_boot_mode(const u32 boot_device)
-{

Re: [U-Boot] [PATCH] ARM: uniphier: enable HS200 support for uniphier_v8_defconfig

2018-01-27 Thread Masahiro Yamada
2018-01-25 14:10 GMT+09:00 Jaehoon Chung :
> On 01/25/2018 01:43 PM, Masahiro Yamada wrote:
>> Signed-off-by: Masahiro Yamada 
>
> Reviewed-by: Jaehoon Chung 
>
>> ---


Applied to u-boot-uniphier.


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


[U-Boot] [GIT PULL] u-boot-uniphier/master

2018-01-27 Thread Masahiro Yamada
Hi Tom,

Please pull one more patch for -rc1.
Thanks!


The following changes since commit 0163c9186b161682a46bd7ae3c2e6ffe275bb1f8:

  env: sunxi: Enable FAT-based environment support by default
(2018-01-27 09:23:32 -0500)

are available in the git repository at:

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

for you to fetch changes up to 7d8cca7be615dcd911121b8ebdc2def2cccb6b37:

  ARM: uniphier: enable HS200 support for uniphier_v8_defconfig
(2018-01-28 06:32:50 +0900)


Masahiro Yamada (1):
  ARM: uniphier: enable HS200 support for uniphier_v8_defconfig

 configs/uniphier_v8_defconfig | 1 +
 1 file changed, 1 insertion(+)


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


Re: [U-Boot] [PATCH] host-tools: use python2 explicitly for shebang

2018-01-27 Thread Masahiro Yamada
Hi Simon,


2018-01-27 0:27 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 21 January 2018 at 02:34, Masahiro Yamada
>  wrote:
>> All of these host tools are apparently written for Python2,
>> not Python3.
>>
>> Use 'python2' in the shebang line according to PEP 394
>> (https://www.python.org/dev/peps/pep-0394/).
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> I sent some time before figuring out why Patman does not work
>> on my machine.
>>
>> If 'python' points to python3, Patman does not epit any error
>> message, it just stays silent until it consumes all memory
>> on the system.
>>
>>
>>  scripts/dtc/pylibfdt/setup.py | 2 +-
>>  scripts/mailmapper| 2 +-
>>  test/py/test.py   | 2 +-
>>  tools/buildman/buildman.py| 2 +-
>>  tools/dtoc/dtoc.py| 2 +-
>>  tools/microcode-tool.py   | 2 +-
>>  tools/patman/patman.py| 2 +-
>>  tools/rkmux.py| 2 +-
>>  8 files changed, 8 insertions(+), 8 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> I can repeat that problem. There has been some effort to make patman
> (in particular) work with python 3. Should we fix the bug? This change
> will mask it.
>

I do not think this is a bug.

If 'python2' is specified in the shebang line,
users should not run it under python 3.

Python 2 will retire in 2020
(https://pythonclock.org/),
we need to covert our python scripts
to python 3 at some point in the future.
'2to3' tool is useful, but not perfect.
Then, we will need to take a look into problems
during the conversion.

Also, I believe we should use python 2 only for existing tools.
New python scripts should be all written in python 3.
(If they are written in python 2,
should be rejected in the review.)


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


Re: [U-Boot] [PATCH 2/4] usb: gadget: dwc2: Fix warning over 32bit vs 64bit targets

2018-01-27 Thread Marek Vasut
On 01/27/2018 09:17 PM, Dr. Philipp Tomsich wrote:
> 
>> On 27 Jan 2018, at 20:56, Tom Rini  wrote:
>>
>> On Sat, Jan 27, 2018 at 08:52:43PM +0100, Marek Vasut wrote:
>>> On 01/27/2018 08:48 PM, Tom Rini wrote:
 When we have a driver that is used on both 32bit and 64bit targets and
 we are talking about address space we cannot use u64 nor u32 and instead
 need to use phys_addr_t.
>>>
>>> Can someoneone pass in a pointer above 32bit address range ? That might
>>> cause some mess ...
>>
>> On rockchip, where this gets used as well, it comes down to writel and a
>> warning about "cast from pointer to integer of different size”.
> 
> I had submitted a patch to resolve this middle of last year
>   https://patchwork.ozlabs.org/patch/783541/
> and used the rationale that this change would make the truncation explicit.
> 
> I don’t recall why did this didn’t move anywhere, but darkly remember the
> discussion veering towards bounce buffers…

I'll just bounce this to Lukasz, since he maintains the gadget, but the
DWC2 UDC driver looks really dark ... ew ...

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


Re: [U-Boot] [PATCH 1/1] efi_loader: split README.efi into two separate documents

2018-01-27 Thread Alexander Graf


On 26.01.18 21:03, Heinrich Schuchardt wrote:
> README.efi describes two different concepts:
> * U-Boot exposing the UEFI API
> * U-Boot running on top of UEFI.
> 
> This patch splits the document in two.
> Religious references are removed.
> 
> The separation of the concepts makes sense before detailing the internals
> of U-Boot exposing the UEFI API in a future patch.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  MAINTAINERS  |   1 +
>  doc/README.efi   | 275 
> ++-
>  doc/README.u-boot_on_efi | 259 
>  3 files changed, 271 insertions(+), 264 deletions(-)
>  create mode 100644 doc/README.u-boot_on_efi
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6e94cee5d3..bc4f4fcfc7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -288,6 +288,7 @@ S:Maintained
>  T:   git git://github.com/agraf/u-boot.git
>  F:   doc/README.efi
>  F:   doc/README.iscsi
> +F:   doc/README.u-boot_on_efi

I don't want to maintain that file. This is all Bin :)

Apart from that minor nit splitting the file sounds like a great idea.


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


[U-Boot] [PATCH] usb: host: Drop unused hcd_name from r8a66597-hcd.c

2018-01-27 Thread Tom Rini
The variable hcd_name is unsued, drop.

Cc: Marek Vasut 
Cc: Chris Brandt 
Signed-off-by: Tom Rini 
---
 drivers/usb/host/r8a66597-hcd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index e0ca2cb0d4c5..9dbb18343aaa 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -20,7 +20,6 @@
 #define R8A66597_DPRINT(...)
 #endif
 
-static const char hcd_name[] = "r8a66597_hcd";
 static struct r8a66597 gr8a66597;
 
 static void get_hub_data(struct usb_device *dev, u16 *hub_devnum, u16 *hubport)
-- 
2.7.4

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


[U-Boot] [PATCH] usb: Remove isp116x-hcd support

2018-01-27 Thread Tom Rini
The isp116x-hcd driver is extremely long unused, so just remove it.

Cc: Marek Vasut 
Signed-off-by: Tom Rini 
---
 drivers/usb/host/Makefile  |1 -
 drivers/usb/host/isp116x-hcd.c | 1323 
 drivers/usb/host/isp116x.h |  476 ---
 3 files changed, 1800 deletions(-)
 delete mode 100644 drivers/usb/host/isp116x-hcd.c
 delete mode 100644 drivers/usb/host/isp116x.h

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 79df888fcec3..7f9ba24cfe75 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -14,7 +14,6 @@ endif
 obj-$(CONFIG_USB_OHCI_NEW) += ohci-hcd.o
 obj-$(CONFIG_USB_ATMEL) += ohci-at91.o
 obj-$(CONFIG_USB_OHCI_DA8XX) += ohci-da8xx.o
-obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
 obj-$(CONFIG_USB_R8A66597_HCD) += r8a66597-hcd.o
 obj-$(CONFIG_USB_SL811HS) += sl811-hcd.o
 obj-$(CONFIG_USB_OHCI_EP93XX) += ohci-ep93xx.o
diff --git a/drivers/usb/host/isp116x-hcd.c b/drivers/usb/host/isp116x-hcd.c
deleted file mode 100644
index 32874d73de84..
--- a/drivers/usb/host/isp116x-hcd.c
+++ /dev/null
@@ -1,1323 +0,0 @@
-/*
- * ISP116x HCD (Host Controller Driver) for u-boot.
- *
- * Copyright (C) 2006-2007 Rodolfo Giometti 
- * Copyright (C) 2006-2007 Eurotech S.p.A. 
- *
- * SPDX-License-Identifier:GPL-2.0+
- *
- * Derived in part from the SL811 HCD driver "u-boot/drivers/usb/sl811_usb.c"
- * (original copyright message follows):
- *
- *(C) Copyright 2004
- *Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- *This code is based on linux driver for sl811hs chip, source at
- *drivers/usb/host/sl811.c:
- *
- *SL811 Host Controller Interface driver for USB.
- *
- *Copyright (c) 2003/06, Courage Co., Ltd.
- *
- *Based on:
- * 1.uhci.c by Linus Torvalds, Johannes Erdfelt, Randy Dunlap,
- *   Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber,
- *   Adam Richter, Gregory P. Smith;
- * 2.Original SL811 driver (hc_sl811.o) by Pei Liu 
- * 3.Rewrited as sl811.o by Yin Aihua 
- *
- *[[GNU/GPL disclaimer]]
- *
- * and in part from AU1x00 OHCI HCD driver 
"u-boot/arch/mips/cpu/au1x00_usb_ohci.c"
- * (original copyright message follows):
- *
- *URB OHCI HCD (Host Controller Driver) for USB on the AU1x00.
- *
- *(C) Copyright 2003
- *Gary Jennejohn, DENX Software Engineering 
- *
- *[[GNU/GPL disclaimer]]
- *
- *Note: Part of this code has been derived from linux
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/*
- * ISP116x chips require certain delays between accesses to its
- * registers. The following timing options exist.
- *
- * 1. Configure your memory controller (the best)
- * 2. Use ndelay (easiest, poorest). For that, enable the following macro.
- *
- * Value is in microseconds.
- */
-#ifdef ISP116X_HCD_USE_UDELAY
-#define UDELAY 1
-#endif
-
-/*
- * On some (slowly?) machines an extra delay after data packing into
- * controller's FIFOs is required, * otherwise you may get the following
- * error:
- *
- *   uboot> usb start
- *   (Re)start USB...
- *   USB:   scanning bus for devices... isp116x: isp116x_submit_job: 
CTL:TIMEOUT
- *   isp116x: isp116x_submit_job: ** FIFO not ready! **
- *
- * USB device not responding, giving up (status=4)
- * isp116x: isp116x_submit_job: ** FIFO not empty! **
- * isp116x: isp116x_submit_job: ** FIFO not empty! **
- * isp116x: isp116x_submit_job: ** FIFO not empty! **
- * 3 USB Device(s) found
- *scanning bus for storage devices... 0 Storage Device(s) found
- *
- * Value is in milliseconds.
- */
-#ifdef ISP116X_HCD_USE_EXTRA_DELAY
-#define EXTRA_DELAY2
-#endif
-
-/*
- * Enable the following defines if you wish enable debugging messages.
- */
-#undef DEBUG   /* enable debugging messages */
-#undef TRACE   /* enable tracing code */
-#undef VERBOSE /* verbose debugging messages */
-
-#include "isp116x.h"
-
-#define DRIVER_VERSION "08 Jan 2007"
-static const char hcd_name[] = "isp116x-hcd";
-
-struct isp116x isp116x_dev;
-struct isp116x_platform_data isp116x_board;
-static int got_rhsc;   /* root hub status change */
-struct usb_device *devgone;/* device which was disconnected */
-static int rh_devnum;  /* address of Root Hub endpoint */
-
-/* - */
-
-static int isp116x_reset(struct isp116x *isp116x);
-
-/* --- Debugging functions - */
-
-#define isp116x_show_reg(d, r) {   \
-   if ((r) < 0x20) {   \
-   DBG("%-12s[%02x]: %08x", #r,\
-   r, 

Re: [U-Boot] [PATCH 2/4] usb: gadget: dwc2: Fix warning over 32bit vs 64bit targets

2018-01-27 Thread Dr. Philipp Tomsich

> On 27 Jan 2018, at 20:56, Tom Rini  wrote:
> 
> On Sat, Jan 27, 2018 at 08:52:43PM +0100, Marek Vasut wrote:
>> On 01/27/2018 08:48 PM, Tom Rini wrote:
>>> When we have a driver that is used on both 32bit and 64bit targets and
>>> we are talking about address space we cannot use u64 nor u32 and instead
>>> need to use phys_addr_t.
>> 
>> Can someoneone pass in a pointer above 32bit address range ? That might
>> cause some mess ...
> 
> On rockchip, where this gets used as well, it comes down to writel and a
> warning about "cast from pointer to integer of different size”.

I had submitted a patch to resolve this middle of last year
https://patchwork.ozlabs.org/patch/783541/
and used the rationale that this change would make the truncation explicit.

I don’t recall why did this didn’t move anywhere, but darkly remember the
discussion veering towards bounce buffers…

Regards,
Philipp.

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


[U-Boot] [PATCH] x86: quark: Fix unused warnings

2018-01-27 Thread Tom Rini
The variable t_rfc is never used, so drop it.  The variables ddr_wctl
and ddr_wcmd are only used in certain manual instances, so guard their
declaration by the same check as their use.

Cc: Bin Meng 
Signed-off-by: Tom Rini 
---
 arch/x86/cpu/quark/smc.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/x86/cpu/quark/smc.c b/arch/x86/cpu/quark/smc.c
index 3ffe92b67b20..0195b56a52f6 100644
--- a/arch/x86/cpu/quark/smc.c
+++ b/arch/x86/cpu/quark/smc.c
@@ -17,15 +17,6 @@
 #include "hte.h"
 #include "smc.h"
 
-/* t_rfc values (in picoseconds) per density */
-static const uint32_t t_rfc[5] = {
-   9,  /* 512Mb */
-   11, /* 1Gb */
-   16, /* 2Gb */
-   30, /* 4Gb */
-   35, /* 8Gb */
-};
-
 /* t_ck clock period in picoseconds per speed index 800, 1066, 1333 */
 static const uint32_t t_ck[3] = {
2500,
@@ -35,8 +26,12 @@ static const uint32_t t_ck[3] = {
 
 /* Global variables */
 static const uint16_t ddr_wclk[] = {193, 158};
+#ifdef BACKUP_WCTL
 static const uint16_t ddr_wctl[] = {1, 217};
+#endif
+#ifdef BACKUP_WCMD
 static const uint16_t ddr_wcmd[] = {1, 220};
+#endif
 
 #ifdef BACKUP_RCVN
 static const uint16_t ddr_rcvn[] = {129, 498};
-- 
2.7.4

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


Re: [U-Boot] [PATCH] usb: Remove unused hcd_name variable

2018-01-27 Thread Marek Vasut
On 01/27/2018 08:57 PM, Tom Rini wrote:
> Both the isp116x-hcd and r8a66597-hcd drivers have an unused hcd_name
> variable, drop.  isp116x-hcd also defines an unused DRIVER_VERSION, so
> drop that while in here.
> 
> Cc: Marek Vasut  (maintainer:USB)
> Signed-off-by: Tom Rini 
> ---
>  drivers/usb/host/isp116x-hcd.c  | 3 ---
>  drivers/usb/host/r8a66597-hcd.c | 1 -
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/usb/host/isp116x-hcd.c b/drivers/usb/host/isp116x-hcd.c
> index 32874d73de84..d1d2d6bd9599 100644
> --- a/drivers/usb/host/isp116x-hcd.c
> +++ b/drivers/usb/host/isp116x-hcd.c

Does anyone actually use this driver ? I cannot find anyone, so just
remove it.

> @@ -92,9 +92,6 @@
>  
>  #include "isp116x.h"
>  
> -#define DRIVER_VERSION   "08 Jan 2007"
> -static const char hcd_name[] = "isp116x-hcd";
> -
>  struct isp116x isp116x_dev;
>  struct isp116x_platform_data isp116x_board;
>  static int got_rhsc; /* root hub status change */
> diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
> index e0ca2cb0d4c5..9dbb18343aaa 100644
> --- a/drivers/usb/host/r8a66597-hcd.c
> +++ b/drivers/usb/host/r8a66597-hcd.c
> @@ -20,7 +20,6 @@
>  #define R8A66597_DPRINT(...)
>  #endif
>  
> -static const char hcd_name[] = "r8a66597_hcd";
>  static struct r8a66597 gr8a66597;
>  
>  static void get_hub_data(struct usb_device *dev, u16 *hub_devnum, u16 
> *hubport)
> 


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


Re: [U-Boot] [PATCH 2/4] usb: gadget: dwc2: Fix warning over 32bit vs 64bit targets

2018-01-27 Thread Marek Vasut
On 01/27/2018 08:56 PM, Tom Rini wrote:
> On Sat, Jan 27, 2018 at 08:52:43PM +0100, Marek Vasut wrote:
>> On 01/27/2018 08:48 PM, Tom Rini wrote:
>>> When we have a driver that is used on both 32bit and 64bit targets and
>>> we are talking about address space we cannot use u64 nor u32 and instead
>>> need to use phys_addr_t.
>>
>> Can someoneone pass in a pointer above 32bit address range ? That might
>> cause some mess ...
> 
> On rockchip, where this gets used as well, it comes down to writel and a
> warning about "cast from pointer to integer of different size".

My concern is with passing addresses which the core cannot handle to the
core, addresses above 32bit address space. But that's probably not an
issue here.

btw it seems that the common practice in that driver is to cast it to
unsigned long, so I think you should be consistent and do that. Or even
better, adjust drivers/usb/gadget/dwc2_udc_otg_priv.h and change dma_buf
in struct dwc2_ep to phys_addr_t there, then you can probably drop all
the casts all over the dwc2 gadget and host drivers.

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


[U-Boot] [PATCH v2 1/1] efi_loader: Call Exit() on return from payload in StartImage()

2018-01-27 Thread Alexander Graf
When a UEFI payload just returns instead of calling the Exit() callback,
we handle that in efi_do_enter() and call Exit on its behalf, so that
the loaded_image->exit_status value is correct.

We were missing that logic in StartImage(). Call it there too.

Reported-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf 

---

v1 -> v2:

  - Fix subject line typo

---
 lib/efi_loader/efi_boottime.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index f5dae40f06..4a36b62828 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1578,8 +1578,13 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t 
image_handle,
 
ret = EFI_CALL(entry(image_handle, ));
 
-   /* Should usually never get here */
-   return EFI_EXIT(ret);
+   /*
+* Usually UEFI applications call Exit() instead of returning.
+* But because the world doesn not consist of ponies and unicorns,
+* we're happy to emulate that behavior on behalf of a payload
+* that forgot.
+*/
+   return EFI_CALL(systab.boottime->exit(image_handle, ret, 0, NULL));
 }
 
 /*
-- 
2.12.3

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


Re: [U-Boot] Guide to hush shell in u-boot

2018-01-27 Thread Wolfgang Denk
Dear Nathan,

In message 

 you wrote:
>
> Anyone know where a guide to hush shell in u-boot would be?

There is none.  The hush shell was copied from the busybox project
(and I have to admit that I don't know where they got it from).
Bysybox does not document it's use either...

> This email and any files transmitted with it are confidential and
> are intended solely for the use of the individual or entity to
> whom they are addressed...

This is a silly note when posting to a public mailing list,  Please
switch this off.  If this is not possible from the account you are
using, then please consider using a free account without such
nonsense footers when posting to public lists.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Applying computer technology is simply finding the  right  wrench  to
pound in the correct screw.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] usb: Remove unused hcd_name variable

2018-01-27 Thread Tom Rini
Both the isp116x-hcd and r8a66597-hcd drivers have an unused hcd_name
variable, drop.  isp116x-hcd also defines an unused DRIVER_VERSION, so
drop that while in here.

Cc: Marek Vasut  (maintainer:USB)
Signed-off-by: Tom Rini 
---
 drivers/usb/host/isp116x-hcd.c  | 3 ---
 drivers/usb/host/r8a66597-hcd.c | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/usb/host/isp116x-hcd.c b/drivers/usb/host/isp116x-hcd.c
index 32874d73de84..d1d2d6bd9599 100644
--- a/drivers/usb/host/isp116x-hcd.c
+++ b/drivers/usb/host/isp116x-hcd.c
@@ -92,9 +92,6 @@
 
 #include "isp116x.h"
 
-#define DRIVER_VERSION "08 Jan 2007"
-static const char hcd_name[] = "isp116x-hcd";
-
 struct isp116x isp116x_dev;
 struct isp116x_platform_data isp116x_board;
 static int got_rhsc;   /* root hub status change */
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index e0ca2cb0d4c5..9dbb18343aaa 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -20,7 +20,6 @@
 #define R8A66597_DPRINT(...)
 #endif
 
-static const char hcd_name[] = "r8a66597_hcd";
 static struct r8a66597 gr8a66597;
 
 static void get_hub_data(struct usb_device *dev, u16 *hub_devnum, u16 *hubport)
-- 
2.7.4

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


Re: [U-Boot] Manual is out of date, missing commands and information

2018-01-27 Thread Wolfgang Denk
Dear Nathan,

In message 

 you wrote:
> This manual http://www.denx.de/wiki/DULG/Manual
> is out of date and missing a lot of info.
> I have been using it thinking it was the official manual.

It is. And it is organized  in the form of a wiki, where each and
every U-Boot user has the opportnity to contribute, to fix bugs and
to add missing parts.

> But then I learned many commands are not listed there.

Well, maybe you could help and add what you find is missing?

> Please take down the manual so that people don't mistakenly use it thinking 
> it is correct.

This is IMO a stupid request.  Incomplete documentation is still
better than no documentation at all.  Instead of complaining it
would be more helpful if you supporteed the community by adding to
and improving the documentation.

Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If you can't explain it to a six year old, you  don't  understand  it
yourself.   - Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] usb: ehci-mxs: Fix argument order for ehci_writel()

2018-01-27 Thread Tom Rini
On Sat, Jan 27, 2018 at 08:53:34PM +0100, Marek Vasut wrote:
> On 01/27/2018 08:48 PM, Tom Rini wrote:
> > The order of arguments for ehci_writel() is 'dest', 'value' and not
> > 'value', 'dest'.
> > 
> > Cc: Stefano Babic 
> > Cc: Marek Vasut 
> > Signed-off-by: Tom Rini 
> 
> Already fixed and in the current USB PR, see:
> 
> usb: ehci: mxs: fix swapped argument in ehci_writel()

Yup, thanks, disregard.

-- 
Tom


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


Re: [U-Boot] [PATCH 2/4] usb: gadget: dwc2: Fix warning over 32bit vs 64bit targets

2018-01-27 Thread Marek Vasut
On 01/27/2018 08:48 PM, Tom Rini wrote:
> When we have a driver that is used on both 32bit and 64bit targets and
> we are talking about address space we cannot use u64 nor u32 and instead
> need to use phys_addr_t.

Can someoneone pass in a pointer above 32bit address range ? That might
cause some mess ...

> Cc: Lukasz Majewski 
> Cc: Marek Vasut 
> Signed-off-by: Tom Rini 
> ---
>  drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c 
> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> index b6164afa9245..ec4b1e219ed0 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
> @@ -114,7 +114,7 @@ static int setdma_rx(struct dwc2_ep *ep, struct 
> dwc2_request *req)
>   (unsigned long) ep->dma_buf +
>   ROUND(ep->len, CONFIG_SYS_CACHELINE_SIZE));
>  
> - writel((unsigned int) ep->dma_buf, >out_endp[ep_num].doepdma);
> + writel((phys_addr_t) ep->dma_buf, >out_endp[ep_num].doepdma);
>   writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
>  >out_endp[ep_num].doeptsiz);
>   writel(DEPCTL_EPENA|DEPCTL_CNAK|ctrl, >out_endp[ep_num].doepctl);
> 


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


[U-Boot] [PATCH 4/4] usb: ehci-mxs: Fix argument order for ehci_writel()

2018-01-27 Thread Tom Rini
The order of arguments for ehci_writel() is 'dest', 'value' and not
'value', 'dest'.

Cc: Stefano Babic 
Cc: Marek Vasut 
Signed-off-by: Tom Rini 
---
 drivers/usb/host/ehci-mxs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
index 6b8d969bb000..9872415562c2 100644
--- a/drivers/usb/host/ehci-mxs.c
+++ b/drivers/usb/host/ehci-mxs.c
@@ -156,7 +156,7 @@ int ehci_hcd_stop(int index)
 
tmp = ehci_readl(>or_usbcmd);
tmp &= ~CMD_RUN;
-   ehci_writel(tmp, >or_usbcmd);
+   ehci_writel(>or_usbcmd, tmp);
 
/* Disable the PHY */
tmp = USBPHY_PWD_RXPWDRX | USBPHY_PWD_RXPWDDIFF |
-- 
2.7.4

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


[U-Boot] [PATCH 3/4] fs: btrfs: Fix printf format character warning

2018-01-27 Thread Tom Rini
When printing a size_t value we need to use %zu for portability between
32bit and 64bit targets.

Cc: Marek Behún 
Signed-off-by: Tom Rini 
---
 fs/btrfs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 2529c2b3b6a6..b0a5cffce31e 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -147,7 +147,7 @@ static int btrfs_check_super(struct btrfs_super_block *sb)
 
if (sb->sys_chunk_array_size < sizeof(struct btrfs_key) +
sizeof(struct btrfs_chunk)) {
-   printf("%s: system chunk array too small %u < %lu\n", __func__,
+   printf("%s: system chunk array too small %u < %zu\n", __func__,
   sb->sys_chunk_array_size, (u32) sizeof(struct btrfs_key)
   + sizeof(struct btrfs_chunk));
ret = -1;
-- 
2.7.4

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


[U-Boot] [PATCH 2/4] usb: gadget: dwc2: Fix warning over 32bit vs 64bit targets

2018-01-27 Thread Tom Rini
When we have a driver that is used on both 32bit and 64bit targets and
we are talking about address space we cannot use u64 nor u32 and instead
need to use phys_addr_t.

Cc: Lukasz Majewski 
Cc: Marek Vasut 
Signed-off-by: Tom Rini 
---
 drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c 
b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
index b6164afa9245..ec4b1e219ed0 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
@@ -114,7 +114,7 @@ static int setdma_rx(struct dwc2_ep *ep, struct 
dwc2_request *req)
(unsigned long) ep->dma_buf +
ROUND(ep->len, CONFIG_SYS_CACHELINE_SIZE));
 
-   writel((unsigned int) ep->dma_buf, >out_endp[ep_num].doepdma);
+   writel((phys_addr_t) ep->dma_buf, >out_endp[ep_num].doepdma);
writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
   >out_endp[ep_num].doeptsiz);
writel(DEPCTL_EPENA|DEPCTL_CNAK|ctrl, >out_endp[ep_num].doepctl);
-- 
2.7.4

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


[U-Boot] [PATCH 1/4] mvpp2: Fix warning over 32bit vs 64bit targets

2018-01-27 Thread Tom Rini
When we have a driver that is used on both 32bit and 64bit targets and
we are talking about address space we cannot use u64 nor u32 and instead
need to use phys_addr_t.

Fixes: 377883f16d36 ("net: mvpp2x: fix phy connected to wrong mdio issue")
Cc: Stefan Chulski 
Cc: Stefan Roese 
Cc: Joe Hershberger 
Signed-off-by: Tom Rini 
---
 drivers/net/mvpp2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
index 233c98b66c88..e3d31a560d54 100644
--- a/drivers/net/mvpp2.c
+++ b/drivers/net/mvpp2.c
@@ -4722,7 +4722,7 @@ static int phy_info_parse(struct udevice *dev, struct 
mvpp2_port *port)
u32 id;
u32 phyaddr = 0;
int phy_mode = -1;
-   u64 mdio_addr;
+   phys_addr_t mdio_addr;
 
phy_node = fdtdec_lookup_phandle(gd->fdt_blob, port_node, "phy");
 
-- 
2.7.4

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


[U-Boot] [PULL] u-boot-usb/master

2018-01-27 Thread Marek Vasut
The following changes since commit fb4413295c765aa8c013650984dc2d908964c81d:

  Merge git://git.denx.de/u-boot-mmc (2018-01-24 11:28:44 -0500)

are available in the Git repository at:

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

for you to fetch changes up to 6f7c92db4c7d1e45503fb10e60caa1ec2bb18d10:

  usb: ehci: mxs: fix swapped argument in ehci_writel() (2018-01-25
20:59:20 +0100)


Daniel Schwierzeck (1):
  usb: ehci: mxs: fix swapped argument in ehci_writel()

Gustavo A. R. Silva (1):
  usb: xhci: Fix bool initialization in xhci_bulk_tx

 drivers/usb/host/ehci-mxs.c  | 2 +-
 drivers/usb/host/xhci-ring.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PULL] u-boot-sh/rmobile-mx

2018-01-27 Thread Marek Vasut
The following changes since commit 16121280188d3daa57b18ad623d08455a90a:

  Merge git://git.denx.de/u-boot-fsl-qoriq (2018-01-23 21:48:53 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-sh.git rmobile-mx

for you to fetch changes up to 789edf694c63a6eff1188b3672af7d0228a1a0d9:

  ARM: rmobile: Convert R8A7791 Porter board to DM and DT (2018-01-27
20:38:54 +0100)


Chris Brandt (1):
  serial: sh: Add support for R7S72100 (RZ/A1)

Marek Vasut (41):
  ARM: dts: rmobile: Update DTS to match Linux 4.14
  ARM: dts: rmobile: Factor out U-Boot extras
  ARM: rmobile: Convert CONFIG_R8A77xx to Kconfig
  serial: sh: Replace fdtdec_get_addr() with devfdt_get_addr()
  serial: sh: Unify CONFIG_R8A779[01234] as CONFIG_RCAR_GEN2
  clk: renesas: Split RCar Gen3 driver
  clk: renesas: Make clk_ids per-driver
  clk: renesas: Make PLL configurations per-SoC
  clk: renesas: Pull Gen3 specific bits into separate header
  clk: renesas: Split SMSTPCR and RMSTPCR tables
  clk: renesas: Make clock tables Kconfig configurable
  clk: renesas: Split out code shared between Gen2 and Gen3
  clk: renesas: Add DIV6P1 clock type
  clk: renesas: Add Gen2 clock core
  clk: renesas: Import R8A7790 H2 clock tables
  clk: renesas: Import R8A7791/R8A7793 M2 clock tables
  clk: renesas: Import R8A7792 V2H clock tables
  clk: renesas: Import R8A7794 E2 clock tables
  pinctrl: rmobile: Import R8A7790 H2 PFC tables
  pinctrl: rmobile: Import R8A7791/R8A7793 M2 PFC tables
  pinctrl: rmobile: Import R8A7792 V2H PFC tables
  pinctrl: rmobile: Import R8A7794 E2 PFC tables
  gpio: rmobile: Add RCar Gen2 compatible string
  pci: rmobile: Add RCar Gen2 PCIe controller driver
  net: ravb: staticize ravb_start
  net: sh_eth: Unify CONFIG_R8A779[01234] as CONFIG_RCAR_GEN2
  net: sh_eth: Pass sh_eth_dev around
  net: sh_eth: Split sh_eth_recv
  net: sh_eth: Separate out MAC address programming
  net: sh_eth: Split sh_eth_init
  net: sh_eth: Clump legacy functions together
  net: sh_eth: Add DM and DT support
  ARM: dts: rmobile: Import R8A7790 DTS from Linux 4.15-rc8
  ARM: dts: rmobile: Import R8A7791 DTS from Linux 4.15-rc8
  ARM: dts: rmobile: Import R8A7792 DTS from Linux 4.15-rc8
  ARM: dts: rmobile: Import R8A7793 DTS from Linux 4.15-rc8
  ARM: dts: rmobile: Import R8A7794 DTS from Linux 4.15-rc8
  ARM: dts: rmobile: Add rudimentary R8A7790 Stout DT
  ARM: dts: rmobile: Add SoC and board U-Boot DT extras
  ARM: rmobile: Enable OF_CONTROL on RCar Gen2
  ARM: rmobile: Convert R8A7791 Porter board to DM and DT

 arch/arm/dts/r8a7790-lager-u-boot.dts|   10 +
 arch/arm/dts/r8a7790-lager.dts   |  856 +++
 arch/arm/dts/r8a7790-stout-u-boot.dts|   10 +
 arch/arm/dts/r8a7790-stout.dts   |   54 ++
 arch/arm/dts/r8a7790-u-boot.dtsi |   13 +
 arch/arm/dts/r8a7790.dtsi| 1665

 arch/arm/dts/r8a7791-koelsch-u-boot.dts  |   10 +
 arch/arm/dts/r8a7791-koelsch.dts |  840 ++
 arch/arm/dts/r8a7791-porter-u-boot.dts   |   10 +
 arch/arm/dts/r8a7791-porter.dts  |  452 ++
 arch/arm/dts/r8a7791-u-boot.dtsi |   13 +
 arch/arm/dts/r8a7791.dtsi| 1665

 arch/arm/dts/r8a7792-blanche-u-boot.dts  |   10 +
 arch/arm/dts/r8a7792-blanche.dts |  327 +++
 arch/arm/dts/r8a7792-u-boot.dtsi |9 +
 arch/arm/dts/r8a7792.dtsi|  857 +++
 arch/arm/dts/r8a7793-gose-u-boot.dts |   10 +
 arch/arm/dts/r8a7793-gose.dts|  727 
 arch/arm/dts/r8a7793-u-boot.dtsi |   13 +
 arch/arm/dts/r8a7793.dtsi| 1332
+
 arch/arm/dts/r8a7794-alt-u-boot.dts  |   10 +
 arch/arm/dts/r8a7794-alt.dts |  414 +
 arch/arm/dts/r8a7794-silk-u-boot.dts |   10 +
 arch/arm/dts/r8a7794-silk.dts|  460 ++
 arch/arm/dts/r8a7794-u-boot.dtsi |   13 +
 arch/arm/dts/r8a7794.dtsi| 1347
+
 arch/arm/dts/r8a7795-h3ulcb-u-boot.dts   |   10 +
 arch/arm/dts/r8a7795-h3ulcb.dts  |   20 +-
 arch/arm/dts/r8a7795-salvator-x-u-boot.dts   |   10 +
 arch/arm/dts/r8a7795-salvator-x.dts  |6 +-
 arch/arm/dts/r8a7795-u-boot.dtsi |   13 +
 arch/arm/dts/r8a7795.dtsi|  323 ++-
 arch/arm/dts/r8a7796-m3ulcb-u-boot.dts   |   10 +
 arch/arm/dts/r8a7796-m3ulcb.dts  |   18 +-
 arch/arm/dts/r8a7796-salvator-x-u-boot.dts   |   10 +
 arch/arm/dts/r8a7796-salvator-x.dts  |   35 +-
 

[U-Boot] [PULL] u-boot-socfpga/master

2018-01-27 Thread Marek Vasut
The following changes since commit fb4413295c765aa8c013650984dc2d908964c81d:

  Merge git://git.denx.de/u-boot-mmc (2018-01-24 11:28:44 -0500)

are available in the Git repository at:

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

for you to fetch changes up to 92962b3caf17f5e64075601a466b3ac00dbd0a88:

  ddr: altera: silence PHY calibration unless in debug mode (2018-01-25
09:59:37 +0100)


Goldschmidt Simon (1):
  ddr: altera: silence PHY calibration unless in debug mode

Simon Goldschmidt (1):
  arm: socfpga: allow configs without network support

 configs/socfpga_arria10_defconfig  |  1 +
 configs/socfpga_arria5_defconfig   |  1 +
 configs/socfpga_cyclone5_defconfig |  1 +
 configs/socfpga_de0_nano_soc_defconfig |  1 +
 configs/socfpga_de10_nano_defconfig|  1 +
 configs/socfpga_de1_soc_defconfig  |  1 +
 configs/socfpga_is1_defconfig  |  1 +
 configs/socfpga_mcvevk_defconfig   |  1 +
 configs/socfpga_sockit_defconfig   |  1 +
 configs/socfpga_socrates_defconfig |  1 +
 configs/socfpga_sr1500_defconfig   |  1 +
 configs/socfpga_vining_fpga_defconfig  |  1 +
 drivers/ddr/altera/sequencer.c |  8 
 include/configs/socfpga_common.h   | 11 +++
 14 files changed, 23 insertions(+), 8 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v3, 15/15] env: sunxi: Enable FAT-based environment support by default

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:17:04PM +0100, Maxime Ripard wrote:

> Now that we have everything in place to implement the transition scheme,
> let's enable it by default.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 04/15] env: Make the env save message a bit more explicit

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:53PM +0100, Maxime Ripard wrote:

> Since we'll soon have support for multiple environments, the environment
> saving message might end up being printed multiple times if the higher
> priority environment cannot be used.
> 
> That might confuse the user, so let's make it explicit if the operation
> failed or not.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 11/15] env: mmc: depends on the MMC framework

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:17:00PM +0100, Maxime Ripard wrote:

> The raw MMC environment directly calls into the MMC framework. Make sure
> it's enabled before we can select it.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 
> Reviewed-by: Jaehoon Chung 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 12/15] env: Allow to build multiple environments in Kconfig

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:17:01PM +0100, Maxime Ripard wrote:

> Now that we have everything in place in the code, let's allow to build
> multiple environments backend through Kconfig.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 08/15] env: common: Make the debug messages play a little nicer

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:57PM +0100, Maxime Ripard wrote:

> Since we have global messages to indicate what's going on, the custom
> messages in the environment drivers only make the output less readable.
> 
> Make the common code play a little nicer by removing all the extra output
> in the standard case.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 10/15] env: Initialise all the environments

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:59PM +0100, Maxime Ripard wrote:

> Since we want to have multiple environments, we will need to initialise
> all the environments since we don't know at init time what drivers might
> fail when calling load.
> 
> Let's init all of them, and only consider for further operations the ones
> that have not reported any errors at init time.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v3,13/15] env: Mark env_get_location as weak

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:17:02PM +0100, Maxime Ripard wrote:

> Allow boards and architectures to override the default environment lookup
> code by overriding env_get_location.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 14/15] sunxi: Transition from the MMC to a FAT-based environment

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:17:03PM +0100, Maxime Ripard wrote:

> The current environment has been hardcoded to an offset that starts to be
> an issue given the current size of our main U-Boot binary.
> 
> By implementing a custom environment location routine, we can always favor
> the FAT-based environment, and fallback to the MMC if we don't find
> something in the FAT partition. We also implement the same order when
> saving the environment, so that hopefully we can slowly migrate the users
> over to FAT-based environment and away from the raw MMC one.
> 
> Eventually, and hopefully before we reach that limit again, we will have
> most of our users using that setup, and we'll be able to retire the raw
> environment, and gain more room for the U-Boot binary.
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v3,09/15] env: Support multiple environments

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:58PM +0100, Maxime Ripard wrote:

> Now that we have everything in place to support multiple environment, let's
> make sure the current code can use it.
> 
> The priority used between the various environment is the same one that was
> used in the code previously.
> 
> At read / init times, the highest priority environment is going to be
> detected, and we'll use the same one without lookup during writes. This
> should implement the same behaviour than we currently have.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 06/15] env: fat: Make the debug messages play a little nicer

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:55PM +0100, Maxime Ripard wrote:

> Since we have global messages to indicate what's going on, the custom
> messages in the environment drivers only make the output less readable.
> 
> Make FAT play a little nicer by removing all the extra \n and formatting
> that is redundant with the global output.
> 
> Reviewed-by: Andre Przywara 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 05/15] env: Make it explicit where we're loading our environment from

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:54PM +0100, Maxime Ripard wrote:

> Since we can have multiple environments now, it's better to provide a
> decent indication on what environments were tried and which were the one to
> fail and succeed.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 02/15] env: Rename env_driver_lookup_default and env_get_default_location

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:51PM +0100, Maxime Ripard wrote:

> The env_driver_lookup_default and env_get_default_location functions are
> about to get refactored to support loading from multiple environment.
> 
> The name is therefore not really well suited anymore. Drop the default
> part to be a bit more relevant.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 03/15] env: Pass additional parameters to the env lookup function

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:52PM +0100, Maxime Ripard wrote:

> In preparation for the multiple environment support, let's introduce two
> new parameters to the environment driver lookup function: the priority and
> operation.
> 
> The operation parameter is meant to identify, obviously, the operation you
> might want to perform on the environment.
> 
> The priority is a number passed to identify the environment priority you
> want to retrieve. The lowest priority parameter (0) will be the primary
> source.
> 
> Combining the two parameters allow you to support multiple environments
> through different priorities, and to change those priorities between read
> and writes operations.
> 
> This is especially useful to implement migration mechanisms where you want
> to always use the same environment first, be it to read or write, while the
> common case is more likely to use the same environment it has read from to
> write it to.
> 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3, 01/15] cmd: nvedit: Get rid of the env lookup

2018-01-27 Thread Tom Rini
On Tue, Jan 23, 2018 at 09:16:50PM +0100, Maxime Ripard wrote:

> The nvedit command is the only user of env_driver_lookup_default outside of
> the environment code itself, and it uses it only to print the environment
> it's about to save to during env save.
> 
> As we're about to rework the environment to be able to handle multiple
> environment sources, we might not have an idea of what environment backend
> is going to be used before trying (and possibly failing for some).
> 
> Therefore, it makes sense to remove that message and move it to the
> env_save function itself. As a side effect, we also can get rid of the call
> to env_driver_lookup_default that is also about to get refactored.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 

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] [PATCH 1/2] fpga: Resync various CONFIG_FPGA_* symbols

2018-01-27 Thread Tuomas Tynkkynen
These are declared in Kconfig, but some #defines have crept in.

CONFIG_FPGA
CONFIG_FPGA_ALTERA
CONFIG_FPGA_CYCLON2
CONFIG_FPGA_SOCFPGA
CONFIG_FPGA_XILINX
CONFIG_FPGA_ZYNQMPPL

Signed-off-by: Tuomas Tynkkynen 
---
 configs/apf27_defconfig  | 1 +
 configs/astro_mcf5373l_defconfig | 2 ++
 configs/mt_ventoux_defconfig | 1 +
 configs/x600_defconfig   | 1 +
 include/configs/M54455EVB.h  | 1 -
 include/configs/apf27.h  | 4 
 include/configs/astro_mcf5373l.h | 2 --
 include/configs/mt_ventoux.h | 2 --
 include/configs/x600.h   | 2 --
 9 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/configs/apf27_defconfig b/configs/apf27_defconfig
index f09c5a828b..6949b711fd 100644
--- a/configs/apf27_defconfig
+++ b/configs/apf27_defconfig
@@ -31,6 +31,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=mxc_nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=mxc_nand.0:1M(u-boot)ro,512K(env),512K(env2),512K(firmware),512K(dtb),5M(kernel),-(rootfs)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_FPGA_XILINX=y
 CONFIG_MMC_MXC=y
 CONFIG_NAND=y
 CONFIG_NAND_MXC=y
diff --git a/configs/astro_mcf5373l_defconfig b/configs/astro_mcf5373l_defconfig
index cababcf990..1e3708fcb5 100644
--- a/configs/astro_mcf5373l_defconfig
+++ b/configs/astro_mcf5373l_defconfig
@@ -16,4 +16,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_DATE=y
 CONFIG_CMD_JFFS2=y
 CONFIG_FPGA_ALTERA=y
+CONFIG_FPGA_CYCLON2=y
+CONFIG_FPGA_XILINX=y
 CONFIG_MTD_NOR_FLASH=y
diff --git a/configs/mt_ventoux_defconfig b/configs/mt_ventoux_defconfig
index 3dd8adb5ce..c059a49576 100644
--- a/configs/mt_ventoux_defconfig
+++ b/configs/mt_ventoux_defconfig
@@ -31,6 +31,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(MLO),1m(u-boot),256k(env1),256k(env2),8m(ubisystem),-(rootfs)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_FPGA_XILINX=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
diff --git a/configs/x600_defconfig b/configs/x600_defconfig
index 4658f977a4..18720daafc 100644
--- a/configs/x600_defconfig
+++ b/configs/x600_defconfig
@@ -37,6 +37,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand"
 CONFIG_MTDPARTS_DEFAULT="mtdparts=nand:64M(ubi0),64M(ubi1)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_FPGA_XILINX=y
 CONFIG_SYS_I2C_DW=y
 # CONFIG_MMC is not set
 CONFIG_MTD_NOR_FLASH=y
diff --git a/include/configs/M54455EVB.h b/include/configs/M54455EVB.h
index a709fbbf63..c5a0a0371d 100644
--- a/include/configs/M54455EVB.h
+++ b/include/configs/M54455EVB.h
@@ -182,7 +182,6 @@
 
 /* FPGA - Spartan 2 */
 /* experiment
-#define CONFIG_FPGA
 #define CONFIG_FPGA_COUNT  1
 #define CONFIG_SYS_FPGA_PROG_FEEDBACK
 #define CONFIG_SYS_FPGA_CHECK_CTRLC
diff --git a/include/configs/apf27.h b/include/configs/apf27.h
index 24afc84a02..16345ca2b5 100644
--- a/include/configs/apf27.h
+++ b/include/configs/apf27.h
@@ -215,11 +215,7 @@
 /*
  * FPGA
  */
-#ifndef CONFIG_SPL_BUILD
-#define CONFIG_FPGA
-#endif
 #define CONFIG_FPGA_COUNT  1
-#define CONFIG_FPGA_XILINX
 #define CONFIG_FPGA_SPARTAN3
 #define CONFIG_SYS_FPGA_WAIT   250 /* 250 ms */
 #define CONFIG_SYS_FPGA_PROG_FEEDBACK
diff --git a/include/configs/astro_mcf5373l.h b/include/configs/astro_mcf5373l.h
index 540db79a27..c8d5c1bd3d 100644
--- a/include/configs/astro_mcf5373l.h
+++ b/include/configs/astro_mcf5373l.h
@@ -177,9 +177,7 @@
 #define CONFIG_SYS_LONGHELP
 
 #define CONFIG_FPGA_COUNT  1
-#defineCONFIG_FPGA_XILINX
 #defineCONFIG_FPGA_SPARTAN3
-#define CONFIG_FPGA_CYCLON2
 #define CONFIG_SYS_FPGA_PROG_FEEDBACK
 #define CONFIG_SYS_FPGA_WAIT   1000
 
diff --git a/include/configs/mt_ventoux.h b/include/configs/mt_ventoux.h
index 11ba3e752a..bee8ddd4f2 100644
--- a/include/configs/mt_ventoux.h
+++ b/include/configs/mt_ventoux.h
@@ -33,8 +33,6 @@
 /*
  * FPGA
  */
-#define CONFIG_FPGA
-#define CONFIG_FPGA_XILINX
 #define CONFIG_FPGA_SPARTAN3
 #define CONFIG_SYS_FPGA_PROG_FEEDBACK
 #define CONFIG_SYS_FPGA_WAIT   1
diff --git a/include/configs/x600.h b/include/configs/x600.h
index 4aa5a2a924..cd3bd94efb 100644
--- a/include/configs/x600.h
+++ b/include/configs/x600.h
@@ -87,8 +87,6 @@
 #define CONFIG_SYS_I2C_RTC_ADDR0x68
 
 /* FPGA config options */
-#define CONFIG_FPGA
-#define CONFIG_FPGA_XILINX
 #define CONFIG_FPGA_SPARTAN3
 #define CONFIG_FPGA_COUNT  1
 
-- 
2.16.1

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


Re: [U-Boot] [PATCH] sunxi: support fuse cmd to read/write fuse

2018-01-27 Thread André Przywara
On 27/01/18 15:20, Jun Nie wrote:
> Support fuse cmd to read/write fuse. Power supply for fuse
> should be ready, name is VDD_EFUSE in some schematic.

Mmh, in general I am not sure it is a good idea to expose this so easily
to the user. I guess a clueless user can easily brick his board by
typing something at the "fuse write" command. I understand that one has
to manually enable the fuse command first to allow access, but this is
still quite a high risk, especially since a lot of the fuses are not
documented.
Would love to hear opinions from others about that topic.

Also I would have hoped for a bit more documentation.
How do those banks/words from the write command map to the fuses, for
instance? What fuses are available and useful? What are the implications
of writing the secure boot fuse, for instance?

And do we know how access to the fuses is affected by the exception
level / mode we are in? My understanding is that SID access is secure
only, which would make it inaccessible for the 64-bit boards where
U-Boot runs in EL2. But then again at least the A64 does not seem to
care about this (unless the secure boot fuse is set).

More inline ...

> Signed-off-by: Jun Nie 
> ---
>  arch/arm/mach-sunxi/cpu_info.c | 60 
> ++
>  1 file changed, 60 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
> index 25a5ec2..30bc2bf 100644
> --- a/arch/arm/mach-sunxi/cpu_info.c
> +++ b/arch/arm/mach-sunxi/cpu_info.c
> @@ -133,6 +133,30 @@ uint32_t sun8i_efuse_read(uint32_t offset)
>   reg_val = readl(SUNXI_SIDC_BASE + SIDC_RDKEY);
>   return reg_val;
>  }
> +
> +uint32_t sun8i_efuse_write(u32 offset, u32 val)
> +{
> + u32 reg_val;
> +
> + writel(val, SUNXI_SIDC_BASE + SIDC_RDKEY);
> +
> + reg_val = readl(SUNXI_SIDC_BASE + SIDC_PRCTL);
> + reg_val &= ~(((0x1ff) << 16) | 0x3);
> + reg_val |= (offset << 16);

Would be good to put names to those magic values.
I understand this is from the code as I sent you ;-), but still ...

> + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
> +
> + reg_val &= ~(((0xff) << 8) | 0x3);
> + reg_val |= (SIDC_OP_LOCK << 8) | 0x1;
> + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
> +
> + while (readl(SUNXI_SIDC_BASE + SIDC_PRCTL) & 0x1)
> + ;

shall we have a timeout or limited retries here?

> +
> + reg_val &= ~(((0x1ff) << 16) | ((0xff) << 8) | 0x3);
> + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
> +
> + return 0;
> +}
>  #endif
>  
>  int sunxi_get_sid(unsigned int *sid)
> @@ -164,3 +188,39 @@ int sunxi_get_sid(unsigned int *sid)
>   return -ENODEV;
>  #endif
>  }
> +
> +int fuse_read(u32 bank, u32 word, u32 *sid)
> +{
> +#ifdef CONFIG_MACH_SUN8I_H3
> + *sid = sun8i_efuse_read(word);
> +#elif defined SUNXI_SID_BASE
> + *sid = readl((ulong)SUNXI_SID_BASE + word);
> +#else
> + return -ENODEV;
> +#endif
> + return 0;
> +}
> +
> +int fuse_prog(u32 bank, u32 word, u32 val)
> +{

I would feel better if we have the write access protected by a separate
Kconfig symbol. So without this being defined either nothing happens or
the user gets a warning.

> +#ifdef CONFIG_MACH_SUN8I_H3

I guess this applies to more than the H3, namely the A64 and A83T,
possibly also H5 and others?

> + return sun8i_efuse_write(word, val);
> +#elif defined SUNXI_SID_BASE
> + writel(val, (ulong)SUNXI_SID_BASE + word);

Are you sure that works? If I read [1] correctly, you always have to use
a special algorithm to burn a fuse, a simple MMIO write access would not
suffice.
The algorithm seems to be different for older SoCs (pre-H3).

> +#else
> + return -ENODEV;
> +#endif
> + return 0;
> +}
> +
> +int fuse_sense(u32 bank, u32 word, u32 *val)
> +{
> + /* We do not support sensing :-( */

Isn't sense the only thing we actually implement? At least this is my
understanding from reading doc/README.fuse.

Cheers,
Andre.


> + return -EINVAL;
> +}
> +
> +int fuse_override(u32 bank, u32 word, u32 val)
> +{
> + /* We do not support overriding :-( */
> + return -EINVAL;
> +}
> 

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


[U-Boot] [RFC v2] i2c, omap24xx: Fixup High Speed Initialization

2018-01-27 Thread Adam Ford
For devices running I2C over 400KHz, this needs to be in HS mode.
Currently, the code is only running in HS mode when the speed is
equal or greater than 3.4MHz.  At least on the OMAP3630/3730, this
fails when trying to configure at 2.6MHz

Using the Linux kernel setup as a reference, I used much of their
calculation for fsscll, fssclh, hsscll, and hssclh.  However, Linux
uses fclk = clk_get(omap->dev, "fck") and fclk_rate = clk_get_rate(fclk)

When dumping the data of fck, I got 9600.  The U-Boot omap24xx I2C
driver sets the I2C_IP_CLK to SYSTEM_CLOCK_96 and I2C_INTERNAL_SAMPLING_CLK
to 1920 except for arch/arm/include/asm/arch-am33xx/i2c.h which
defines I2C_INTERNAL_SAMPLING_CLK to 1200 and I2C_IP_CLK 4800.

I do not have this hardware, so I cannot test, but I compared the
values of psc=4, scll=4377, sclh=1803 for both U-Boot and Linux
and they match on an OMAP630/3730.

Signed-off-by: Adam Ford 

diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 5d33815..eace748 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -205,8 +205,10 @@ static int __omap24_i2c_setspeed(struct i2c *i2c_base, 
uint speed,
int hsscll = 0, hssclh = 0;
u32 scll = 0, sclh = 0;
 
-   if (speed >= OMAP_I2C_HIGH_SPEED) {
+   if (speed > OMAP_I2C_FAST_MODE) {
/* High speed */
+   unsigned long scl;
+
psc = I2C_IP_CLK / I2C_INTERNAL_SAMPLING_CLK;
psc -= 1;
if (psc < I2C_PSC_MIN) {
@@ -215,12 +217,10 @@ static int __omap24_i2c_setspeed(struct i2c *i2c_base, 
uint speed,
}
 
/* For first phase of HS mode */
-   fsscll = I2C_INTERNAL_SAMPLING_CLK / (2 * speed);
+   scl = I2C_INTERNAL_SAMPLING_CLK / 40;
+   fsscll = scl - (scl / 3) - 7;
+   fssclh = (scl / 3) - 5;
 
-   fssclh = fsscll;
-
-   fsscll -= I2C_HIGHSPEED_PHASE_ONE_SCLL_TRIM;
-   fssclh -= I2C_HIGHSPEED_PHASE_ONE_SCLH_TRIM;
if (((fsscll < 0) || (fssclh < 0)) ||
((fsscll > 255) || (fssclh > 255))) {
puts("Error : I2C initializing first phase clock\n");
@@ -228,10 +228,10 @@ static int __omap24_i2c_setspeed(struct i2c *i2c_base, 
uint speed,
}
 
/* For second phase of HS mode */
-   hsscll = hssclh = I2C_INTERNAL_SAMPLING_CLK / (2 * speed);
+   scl = I2C_IP_CLK / speed;
+   hsscll = scl - (scl / 3) - 7;
+   hssclh = (scl / 3) - 5;
 
-   hsscll -= I2C_HIGHSPEED_PHASE_TWO_SCLL_TRIM;
-   hssclh -= I2C_HIGHSPEED_PHASE_TWO_SCLH_TRIM;
if (((fsscll < 0) || (fssclh < 0)) ||
((fsscll > 255) || (fssclh > 255))) {
puts("Error : I2C initializing second phase clock\n");
@@ -240,7 +240,6 @@ static int __omap24_i2c_setspeed(struct i2c *i2c_base, uint 
speed,
 
scll = (unsigned int)hsscll << 8 | (unsigned int)fsscll;
sclh = (unsigned int)hssclh << 8 | (unsigned int)fssclh;
-
} else {
/* Standard and fast speed */
psc = omap24_i2c_findpsc(, , speed);
-- 
2.7.4

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


[U-Boot] standalone example on mips/ath79/QCA9558/Tp-Link Archer-c7

2018-01-27 Thread Arvid Picciani
HI,

i'm trying the standalone hello_world.bin example on a
mips/ath79/QCA9558/Tp-Link Archer-c7

it just hangs for me:

ap135> tftpboot 0x8020
dup 1 speed 1000
*** Warning: no boot file name; using '6F01A8C0.img'
Using eth1 device
TFTP from server 192.168.1.100; our IP address is 192.168.1.111
Filename '6F01A8C0.img'.
Load address: 0x8020
Loading: #
done

done
Bytes transferred = 1536 (600 hex)
ap135> go 0x8020
## Starting application at 0x8020 ...


nothing happens beyond this point

am i supposed to do anything different here?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] sandbox and spi emulation (err=-19 Invalid bus 0 for spec)

2018-01-27 Thread Славкин Олег
Hello

I'm trying to run u-boot (sandbox) with a spi emulation, but the start
fails with an error (err=-19).

What I did

# clone and compile u-boot
cd ~/
git clone git://git.denx.de/u-boot.git
cd u-boot
git checkout v2017.11
make sandbox_defconfig menuconfig
 "Sandbox architecture" -> "Run sandbox on 32/64-bit host" (32-bit host)
make

# create file for SPI flash
cd ~/u-boot
dd if=/dev/zero of=spi.bin bs=1M count=4

# run
./u-boot --spi_sf 0:0:M25P16:spi.bin
-
U-Boot 2017.11 (Jan 27 2018 - 11:52:29 +0300)

DRAM:  128 MiB
Invalid bus 0 for spec 'M25P16:spi.bin' (err=-19)
initcall sequence 0816b0f8 failed at call 001cf813 (err=-19)
### ERROR ### Please RESET the board ###


My host:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.4 LTS
Release:14.04
Codename:   trusty
$ uname -a
Linux devx86 4.2.0-27-generic #32~14.04.1-Ubuntu SMP Fri Jan 22 15:32:27
UTC 2016 i686 i686 i686 GNU/Linux


What am I doing wrong?

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


[U-Boot] [PATCH] atomic-long: Fix warnings on arm64

2018-01-27 Thread Bradley Bolen
Several inline functions in this file reference undefined functions in
U-Boot.  For example:

atomic-long.h:73:9: warning: implicit declaration of function
'atomic64_sub_and_test'
atomic-long.h:80:9: warning: implicit declaration of function
'atomic64_dec_and_test'
atomic-long.h:87:9: warning: implicit declaration of function
'atomic64_inc_and_test'

Handle this the same as the 32 bit build by wrapping these functions in
a __UBOOT__ check.

Signed-off-by: Bradley Bolen 
---
 include/asm-generic/atomic-long.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/asm-generic/atomic-long.h 
b/include/asm-generic/atomic-long.h
index d0469ef2e3..32f288b706 100644
--- a/include/asm-generic/atomic-long.h
+++ b/include/asm-generic/atomic-long.h
@@ -66,6 +66,7 @@ static inline void atomic_long_sub(long i, atomic_long_t *l)
atomic64_sub(i, v);
 }
 
+#ifndef __UBOOT__
 static inline int atomic_long_sub_and_test(long i, atomic_long_t *l)
 {
atomic64_t *v = (atomic64_t *)l;
@@ -135,6 +136,7 @@ static inline long atomic_long_add_unless(atomic_long_t *l, 
long a, long u)
(atomic64_cmpxchg((atomic64_t *)(l), (old), (new)))
 #define atomic_long_xchg(v, new) \
(atomic64_xchg((atomic64_t *)(v), (new)))
+#endif  /*  __UBOOT__ */
 
 #else  /*  BITS_PER_LONG == 64  */
 
-- 
2.14.1

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


[U-Boot] [PATCH] sunxi: support fuse cmd to read/write fuse

2018-01-27 Thread Jun Nie
Support fuse cmd to read/write fuse. Power supply for fuse
should be ready, name is VDD_EFUSE in some schematic.

Signed-off-by: Jun Nie 
---
 arch/arm/mach-sunxi/cpu_info.c | 60 ++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index 25a5ec2..30bc2bf 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -133,6 +133,30 @@ uint32_t sun8i_efuse_read(uint32_t offset)
reg_val = readl(SUNXI_SIDC_BASE + SIDC_RDKEY);
return reg_val;
 }
+
+uint32_t sun8i_efuse_write(u32 offset, u32 val)
+{
+   u32 reg_val;
+
+   writel(val, SUNXI_SIDC_BASE + SIDC_RDKEY);
+
+   reg_val = readl(SUNXI_SIDC_BASE + SIDC_PRCTL);
+   reg_val &= ~(((0x1ff) << 16) | 0x3);
+   reg_val |= (offset << 16);
+   writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
+
+   reg_val &= ~(((0xff) << 8) | 0x3);
+   reg_val |= (SIDC_OP_LOCK << 8) | 0x1;
+   writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
+
+   while (readl(SUNXI_SIDC_BASE + SIDC_PRCTL) & 0x1)
+   ;
+
+   reg_val &= ~(((0x1ff) << 16) | ((0xff) << 8) | 0x3);
+   writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
+
+   return 0;
+}
 #endif
 
 int sunxi_get_sid(unsigned int *sid)
@@ -164,3 +188,39 @@ int sunxi_get_sid(unsigned int *sid)
return -ENODEV;
 #endif
 }
+
+int fuse_read(u32 bank, u32 word, u32 *sid)
+{
+#ifdef CONFIG_MACH_SUN8I_H3
+   *sid = sun8i_efuse_read(word);
+#elif defined SUNXI_SID_BASE
+   *sid = readl((ulong)SUNXI_SID_BASE + word);
+#else
+   return -ENODEV;
+#endif
+   return 0;
+}
+
+int fuse_prog(u32 bank, u32 word, u32 val)
+{
+#ifdef CONFIG_MACH_SUN8I_H3
+   return sun8i_efuse_write(word, val);
+#elif defined SUNXI_SID_BASE
+   writel(val, (ulong)SUNXI_SID_BASE + word);
+#else
+   return -ENODEV;
+#endif
+   return 0;
+}
+
+int fuse_sense(u32 bank, u32 word, u32 *val)
+{
+   /* We do not support sensing :-( */
+   return -EINVAL;
+}
+
+int fuse_override(u32 bank, u32 word, u32 val)
+{
+   /* We do not support overriding :-( */
+   return -EINVAL;
+}
-- 
1.9.1

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