Re: [U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

2018-02-25 Thread Wolfgang Denk
Dear Tom Rini,

In message <20180224215325.GQ4311@bill-the-cat> you wrote:
> 
> > Why do you ignore this NAK, and why do you add this patch so late in
> > the release cycle anyway?
> 
> Sorry, didn't v2 address your concerns?  We don't initialize the device
> because maybe we'll have env there, we initalize mmc because we need to
> check that it is there.  Thanks!

No, it does not.  As is, we initialize MMC in the EXT4 code (in
env_ext4_load()). If we go that route, we would have to add similar
init calls to all other file systemn load routines as well.

This does not make sense to me.  This pollutes the code with
unrelated things - file system code should not depend on any
underlaying driver suport.  It increases code size, makes the code
harder to maintain (if you need to change this, there is good
chances to forget the same change in other file systems), and there
is a good chance that in the end you will initialzie MMC even if you
don't use it.

We should keep the code clean and orthogonal.  Driver init code has
no place in file system code.

If needed, the drivers have to make sure to auto--initialize on
first access.

I hold my NAK on this patch.  It is the wrong thing to do.

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
A meeting is an event at which the minutes are kept and the hours are
lost.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] Interface changes for adding TCP

2018-02-25 Thread Wolfgang Denk
Dear Duncan,

In message <20180224223615.14584-1...@synoia.com> you wrote:
> 
> This code has passed through patman.

Oh, do you really think this is a good description of what this patch
does? You can do better, I bet.

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
Faith may be defined briefly as an illogical belief in the  occurence
of the improbable.- H. L. Mencken
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] core: do not fail in device_probe() when clk set default fail

2018-02-25 Thread Kever Yang
Assigned clocks are widely used in kernel, but not in U-Boot yet,
many U-Boot clock driver do not have the API while dts port from kernel
have "assigned-clocks" node.

Just give a warning now instead of a device probe fail.

Signed-off-by: Kever Yang 
---

 drivers/core/device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 9d58f44..71872e9 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -407,7 +407,7 @@ int device_probe(struct udevice *dev)
/* Process 'assigned-{clocks/clock-parents/clock-rates}' properties */
ret = clk_set_defaults(dev);
if (ret)
-   goto fail;
+   debug("%s clk_set_defaults failed %d\n", ret);
 
if (drv->probe) {
ret = drv->probe(dev);
-- 
1.9.1

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


Re: [U-Boot] [PATCH] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR

2018-02-25 Thread Lukasz Majewski
Hi Tom,

> Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig.  We can
> provide a default for BOOTCOUNT_AM33XX as that's a specific part of
> the RTC in use.  We can also provide a default for ARCH_LS1043A and
> ARCH_LS1021A as they had been previously calculated and their symbols
> are in Kconfig.  In the case of other QE-enabled platforms, they are
> not so we must update the relevant defconfig files.  The previous
> default only applied in some cases, even on a specific SoC family.

Thanks for your patch.

I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig.

Please correct me if I'm wrong, but it shall be applied on top of
Alex's series:

http://patchwork.ozlabs.org/cover/874539/


Reviewed-by: Lukasz Majewski 

> 
> Signed-off-by: Tom Rini 
> ---
>  configs/calimain_defconfig  |  1 +
>  configs/dh_imx6_defconfig   |  1 +
>  configs/ge_b450v3_defconfig |  1 +
>  configs/ge_b650v3_defconfig |  1 +
>  configs/ge_b850v3_defconfig |  1 +
>  configs/highbank_defconfig  |  1 +
>  configs/ids8313_defconfig   |  1 +
>  configs/kmcoge4_defconfig   |  1 +
>  configs/kmcoge5ne_defconfig |  1 +
>  configs/kmeter1_defconfig   |  1 +
>  configs/kmlion1_defconfig   |  1 +
>  configs/kmopti2_defconfig   |  1 +
>  configs/kmsupx5_defconfig   |  1 +
>  configs/kmtegr1_defconfig   |  1 +
>  configs/kmtepr2_defconfig   |  1 +
>  configs/kmvect1_defconfig   |  1 +
>  configs/mx53ppd_defconfig   |  1 +
>  configs/socfpga_is1_defconfig   |  1 +
>  configs/socfpga_sr1500_defconfig|  1 +
>  configs/suvd3_defconfig |  1 +
>  configs/tqma6s_wru4_mmc_defconfig   |  1 +
>  configs/tuge1_defconfig |  1 +
>  configs/tuxx1_defconfig |  1 +
>  configs/x600_defconfig  |  1 +
>  drivers/bootcount/Kconfig   |  6 --
>  drivers/bootcount/bootcount.c   | 16 
>  include/configs/brppt1.h|  3 ---
>  include/configs/calimain.h  |  1 -
>  include/configs/dh_imx6.h   |  1 -
>  include/configs/ge_bx50v3.h |  2 --
>  include/configs/highbank.h  |  1 -
>  include/configs/ids8313.h   |  3 ---
>  include/configs/km/kmp204x-common.h |  3 ---
>  include/configs/socfpga_is1.h   |  2 --
>  include/configs/socfpga_sr1500.h|  2 --
>  include/configs/ti_am335x_common.h  |  7 ---
>  include/configs/tqma6_wru4.h|  1 -
>  include/configs/x600.h  |  4 
>  38 files changed, 28 insertions(+), 48 deletions(-)
> 
> diff --git a/configs/calimain_defconfig b/configs/calimain_defconfig
> index cbb31f6bf321..234b1a593567 100644
> --- a/configs/calimain_defconfig
> +++ b/configs/calimain_defconfig
> @@ -23,6 +23,7 @@ CONFIG_CMD_DIAG=y
>  CONFIG_ENV_IS_IN_FLASH=y
>  CONFIG_BOOTP_DNS=y
>  CONFIG_BOOTCOUNT_LIMIT=y
> +CONFIG_SYS_BOOTCOUNT_ADDR=0x01C23000
>  # CONFIG_MMC is not set
>  CONFIG_MTD_NOR_FLASH=y
>  CONFIG_SYS_NS16550=y
> diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
> index 251fcd01b69a..2b4fe9c2c596 100644
> --- a/configs/dh_imx6_defconfig
> +++ b/configs/dh_imx6_defconfig
> @@ -35,6 +35,7 @@ CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_DWC_AHSATA=y
>  CONFIG_BOOTCOUNT_LIMIT=y
> +CONFIG_SYS_BOOTCOUNT_ADDR=0x0090
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_PHYLIB=y
> diff --git a/configs/ge_b450v3_defconfig b/configs/ge_b450v3_defconfig
> index ee1cc432e0e0..045380b6de8e 100644
> --- a/configs/ge_b450v3_defconfig
> +++ b/configs/ge_b450v3_defconfig
> @@ -29,6 +29,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_BOOTCOUNT_EXT=y
>  CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="1:5"
> +CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_NETDEVICES=y
> diff --git a/configs/ge_b650v3_defconfig b/configs/ge_b650v3_defconfig
> index 27a89b0be782..9d4b8aeebedc 100644
> --- a/configs/ge_b650v3_defconfig
> +++ b/configs/ge_b650v3_defconfig
> @@ -29,6 +29,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_BOOTCOUNT_EXT=y
>  CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="1:5"
> +CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_NETDEVICES=y
> diff --git a/configs/ge_b850v3_defconfig b/configs/ge_b850v3_defconfig
> index af4ba9754331..94785681be7d 100644
> --- a/configs/ge_b850v3_defconfig
> +++ b/configs/ge_b850v3_defconfig
> @@ -29,6 +29,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_BOOTCOUNT_EXT=y
>  CONFIG_SYS_BOOTCOUNT_EXT_DEVPART="1:5"
> +CONFIG_SYS_BOOTCOUNT_ADDR=0x7000A000
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_NETDEVICES=y
> diff --git a/configs/highbank_defconfig b/configs/highbank_defconfig
> index 7b9c0e7d4770..55f83ed1e17c 100644
> --- a/configs/highbank_defconfig
> +++ b/configs/highbank_defconfig
> @@ -17,6 

[U-Boot] [PULL] Please pull u-boot-rockchip/master

2018-02-25 Thread Dr. Philipp Tomsich
Tom,

we have additional fixes ready for you:
* the TPL-build process for the Vyasa board was fixed by Jagan (by 
providing the correct TEXT_BASE)
* a regression on Ethernet for the RK3399 and RK3368 has been resolved 
by adding support for its clocks
* a regression on PMIC probing on the RK399 has been resolved by adding 
support for the assigned-clocks of the PMUCRU

Travis report is at 
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/345699336

Thanks,
Philipp.


The following changes since commit 0bb430c8494e26e8d258cf6957cdd39d2ce4f309:

  Merge git://git.denx.de/u-boot-video (2018-02-24 08:02:17 -0500)

are available in the git repository at:

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

for you to fetch changes up to 434d5a00a4578f826e7e2cef29bf2388dd760a88:

  rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL (2018-02-24 
18:50:03 +0100)


Jagan Teki (2):
  rockchip: rk3288: Add TPL_LDSCRIPT
  rockchip: rk3288: Fix wrong TPL_TEXT_BASE

Philipp Tomsich (3):
  rockchip: clk: rk3399: handle clk_enable requests for GMAC
  rockchip: clk: rk3368: handle clk_enable requests for GMAC
  rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL

 arch/arm/mach-rockchip/Kconfig   | 10 ++
 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++
 configs/vyasa-rk3288_defconfig   |  1 -
 drivers/clk/rockchip/clk_rk3368.c| 19 +++
 drivers/clk/rockchip/clk_rk3399.c| 19 +++
 5 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds

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


Re: [U-Boot] [PATCH] core: do not fail in device_probe() when clk set default fail

2018-02-25 Thread Dr. Philipp Tomsich

> On 25 Feb 2018, at 11:24, Kever Yang  wrote:
> 
> Assigned clocks are widely used in kernel, but not in U-Boot yet,
> many U-Boot clock driver do not have the API while dts port from kernel
> have "assigned-clocks" node.
> 
> Just give a warning now instead of a device probe fail.

I strongly disagree on this one: the only reason this can fail is if 
assigned-clock-rates
can not be set (e.g. because a clock that should be assigned to is not known by 
the
clock driver).  However, this should never be ignored silently.

If the clock subsystem does not know all clocks that are being attempted to 
set, then
commits to shared drivers will eventually break: e.g. commit ba1f96672522
("net: designware: add clock support”) recently broke the GMAC for the RK3368 
and
RK3399 because it iterated over all clocks defined in the “clocks” property of 
the
GMAC node.

As long as various drivers perform an unconditional clk_enable and/or an 
unconditional
clk_set_rate, we should enforce this in the core already.  In consequence, 
dedicated
code from the drivers should now start to slowly disappear, as clock-rates can 
now be
set via the DTS.

> 
> Signed-off-by: Kever Yang 
> ---
> 
> drivers/core/device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 9d58f44..71872e9 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -407,7 +407,7 @@ int device_probe(struct udevice *dev)
>   /* Process 'assigned-{clocks/clock-parents/clock-rates}' properties */
>   ret = clk_set_defaults(dev);
>   if (ret)
> - goto fail;
> + debug("%s clk_set_defaults failed %d\n", ret);

This probably shouldn’t have been a silent failure.
A pr_err() may be more appropriate… I would recommend this to continue failing
though, as it is simple enough to handle the additional clocks in the clock 
drivers
and create a permanent record of “things not needing additional changes, due to
the BROM already having set up things” by returning success.

> 
>   if (drv->probe) {
>   ret = drv->probe(dev);
> -- 
> 1.9.1
> 

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


Re: [U-Boot] Support of kernels > 16 MiB on Raspberry Pi

2018-02-25 Thread Alexander Kurtz
Hi!

Thanks for confirming this! I see four ways how this can be solved:

   1. I can locally adjust the memory locations to make my > 16MiB kernel
  work. The commit mentioned by Jaehoon Chung does this via a custom
  boot.scr, I did this by bumping $scriptaddr and $ramdisk_addr_r
  interactively during bootup and storing the changes to the Micro SD
  card with the "saveenv" command.
   2. I could place a "uEnv.txt on the Micro SD card with those bumped
  values in it. This would make this work-around deployable via
  Puppet, but unfortunately reading "uEnv.txt" on bootup seems to be a
  board-specific feature, and the RPI code currently doesn't seem to
  have this feature. [0]
   3. I could ask Debian to patch the upstream default values for these
  memory locations. After all, a distro bootloader which doesn't boot
  the distro kernel is pretty useless, so I imagine they would
  probably consider this.
   4. U-Boot upstream could adjust the memory locations themselves. I
  would be happy to submit a patch for this, however I want get some
  feedback first: Would you guys accept such a patch, bumping the
  supported kernel size to e.g. 32 MiB or even 64 MiB?

I would prefer 4>3>2>1, what do you think?

Best regards

Alexander Kurtz

[0] https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR

2018-02-25 Thread Tom Rini
On Sun, Feb 25, 2018 at 11:29:30AM +0100, Lukasz Majewski wrote:
> Hi Tom,
> 
> > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig.  We can
> > provide a default for BOOTCOUNT_AM33XX as that's a specific part of
> > the RTC in use.  We can also provide a default for ARCH_LS1043A and
> > ARCH_LS1021A as they had been previously calculated and their symbols
> > are in Kconfig.  In the case of other QE-enabled platforms, they are
> > not so we must update the relevant defconfig files.  The previous
> > default only applied in some cases, even on a specific SoC family.
> 
> Thanks for your patch.
> 
> I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig.
> 
> Please correct me if I'm wrong, but it shall be applied on top of
> Alex's series:
> 
> http://patchwork.ozlabs.org/cover/874539/

Correct.  I tested that and the only part I wasn't 100% confident in
after transition was the addresses.

-- 
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, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

2018-02-25 Thread Tom Rini
On Sun, Feb 25, 2018 at 09:53:10AM +0100, Wolfgang Denk wrote:
> Dear Tom Rini,
> 
> In message <20180224215325.GQ4311@bill-the-cat> you wrote:
> > 
> > > Why do you ignore this NAK, and why do you add this patch so late in
> > > the release cycle anyway?
> > 
> > Sorry, didn't v2 address your concerns?  We don't initialize the device
> > because maybe we'll have env there, we initalize mmc because we need to
> > check that it is there.  Thanks!
> 
> No, it does not.  As is, we initialize MMC in the EXT4 code (in
> env_ext4_load()). If we go that route, we would have to add similar
> init calls to all other file systemn load routines as well.
> 
> This does not make sense to me.  This pollutes the code with
> unrelated things - file system code should not depend on any
> underlaying driver suport.  It increases code size, makes the code
> harder to maintain (if you need to change this, there is good
> chances to forget the same change in other file systems), and there
> is a good chance that in the end you will initialzie MMC even if you
> don't use it.
> 
> We should keep the code clean and orthogonal.  Driver init code has
> no place in file system code.
> 
> If needed, the drivers have to make sure to auto--initialize on
> first access.
> 
> I hold my NAK on this patch.  It is the wrong thing to do.

I think you have this a little bit wrong.  But, it's also where we are
with the DM conversion.  This _is_ the first place we're trying to
access the MMC.  And it's not in the filesystem code, it's in the
environment code.

That said, Faiz, what exactly is the failure sequence (and hardware)?
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, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

2018-02-25 Thread Wolfgang Denk
Dear Tom,

In message <20180225134810.GU4311@bill-the-cat> you wrote:
> 
> > We should keep the code clean and orthogonal.  Driver init code has
> > no place in file system code.
> >
> > If needed, the drivers have to make sure to auto--initialize on
> > first access.
> >
> > I hold my NAK on this patch.  It is the wrong thing to do.
> 
> I think you have this a little bit wrong.  But, it's also where we are
> with the DM conversion.  This _is_ the first place we're trying to
> access the MMC.  And it's not in the filesystem code, it's in the
> environment code.

Maybe I was not really clear.  You are right as this is not generic
file system code.  Instead, it is the EXT4 support code for the
environment handling.

The patch adds mmc_initialize() to env_ext4_load(), so whenever we
try to load the environment from an EXT4 file system, it will
initialize the MMC subsystem.

However - what if we want to load the environment from an EXT4 file
system on any other storage device - say, USB, or SATA, or flash?

In all such cases the initialization of MMC would be plain wrong.


And what if we want to load the environment from any other type of
file system - say, cramfs, zfs, etc. - on SDCard or eMMC?  These do
not initialize MMC, so it would fail?

Yes, we have the same crappy code in env/fat.c, but this is the
wrong thing to do, and must be cleaned up there as well.


This is what I meant when I wrote that the file system (interface)
code and the storage device support code are independent of each
other, and code should be kept orthogonal - storage support like MMC
etc. has no place in code dealing with a specific file system type.

I still think my NAK is reasonable.

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
I had the rare misfortune of being one of the first people to try and
implement a PL/1 compiler. -- T. Cheatham
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

2018-02-25 Thread Lukasz Majewski
Hi Tom, Wolfgang,

> On Sun, Feb 25, 2018 at 09:53:10AM +0100, Wolfgang Denk wrote:
> > Dear Tom Rini,
> > 
> > In message <20180224215325.GQ4311@bill-the-cat> you wrote:  
> > >   
> > > > Why do you ignore this NAK, and why do you add this patch so
> > > > late in the release cycle anyway?  
> > > 
> > > Sorry, didn't v2 address your concerns?  We don't initialize the
> > > device because maybe we'll have env there, we initalize mmc
> > > because we need to check that it is there.  Thanks!  
> > 
> > No, it does not.  As is, we initialize MMC in the EXT4 code (in
> > env_ext4_load()). If we go that route, we would have to add similar
> > init calls to all other file systemn load routines as well.
> > 
> > This does not make sense to me.  This pollutes the code with
> > unrelated things - file system code should not depend on any
> > underlaying driver suport.  It increases code size, makes the code
> > harder to maintain (if you need to change this, there is good
> > chances to forget the same change in other file systems), and there
> > is a good chance that in the end you will initialzie MMC even if you
> > don't use it.
> > 
> > We should keep the code clean and orthogonal.  Driver init code has
> > no place in file system code.
> > 
> > If needed, the drivers have to make sure to auto--initialize on
> > first access.
> > 
> > I hold my NAK on this patch.  It is the wrong thing to do.  
> 
> I think you have this a little bit wrong.  But, it's also where we are
> with the DM conversion.  This _is_ the first place we're trying to
> access the MMC.  And it's not in the filesystem code, it's in the
> environment code.
> 
> That said, Faiz, what exactly is the failure sequence (and hardware)?

As I've read the discussion between Tom and Wolfgang - I'm wondering if
this initialization could be done in the driver model? 

I think that DM is a right place to put such code (ecluding the case
of env in eMMC readed in SPL).

I've added Simon to CC, so maybe he can give us some insights.

> Thanks!
> 


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


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


Re: [U-Boot] [U-Boot, v2, 2/2] rockchip: rk3288: Fix wrong TPL_TEXT_BASE

2018-02-25 Thread Philipp Tomsich
> TPL offset 0xff704004 is unaligned address which is adding nearest
> 8-bytes for next instruction, So  0xff704004 is adding 0x20 for
> proper alignment which is causing the next instruction data
> 0xefff is moved.
> 
> Hexdump with overlaped bytes:
> -
> 000        
> 010        eaff
> 
> So, Fix the TEXT_BASE for proper aligned address 0xff704000
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> ---
> Changes for v2:
> - Update commit message
> 
>  arch/arm/mach-rockchip/Kconfig | 3 +++
>  configs/vyasa-rk3288_defconfig | 1 -
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 

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


Re: [U-Boot] [U-Boot,v2,1/2] rockchip: rk3288: Add TPL_LDSCRIPT

2018-02-25 Thread Philipp Tomsich
> Due to size limitations in SPL by adding falcon mode,
> rk3288 support TPL. In order to not overlap SPL_TEXT_BASE
> add TPL_TEXT_BASE with u-boot-tpl.lds that intern call
> u-boot-spl.lds with proper TEXT_BASE values.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> ---
> Changes for v2:
> - none
> 
>  arch/arm/mach-rockchip/Kconfig   |  7 +++
>  arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++
>  2 files changed, 17 insertions(+)
>  create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
> 

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


Re: [U-Boot] rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL

2018-02-25 Thread Philipp Tomsich
> The device-tree node for the PMU clk controller assigns to its parent
> (i.e. PLL_PPLL) even though this clock currently is set up statically
> by an init-function.
> 
> In order to avoid unexpected failures, a simple implementation of
> set_rate (which accepts requests, but notifies the caller of the
> preset frequency in its return value) and get_rate (which always
> returns the preset frequency) are added.
> 
> Note that this is required for the RK808 PMIC to probe successfully on
> the RK3399-Q7, following the support for the assigned-clocks property.
> 
> References: commit f4fcba5c5baa ("clk: implement clk_set_defaults()")
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 
> ---
> 
>  drivers/clk/rockchip/clk_rk3399.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> 2.1.4
> 

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


Re: [U-Boot] [U-Boot,v2,9/9] rk3288: vyasa: Add eMMC boot support

2018-02-25 Thread Philipp Tomsich
> RK3288 Vyasa has eMMC boot support, with JP4 open.
> 
> Signed-off-by: Jagan Teki 
> ---
> Note:
> Linux patch for this support is in ML.
> 
>  arch/arm/dts/rk3288-vyasa-u-boot.dtsi |  4 
>  arch/arm/dts/rk3288-vyasa.dts | 11 +++
>  board/amarula/vyasa-rk3288/vyasa-rk3288.c |  7 +++
>  3 files changed, 22 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 5/9] ARM: dts: rockchip: Add gmac support for rk3288-vyasa board

2018-02-25 Thread Philipp Tomsich
> Sync gmac dts node from Linux.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 41 +
>  1 file changed, 41 insertions(+)
> 

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


Re: [U-Boot] [U-Boot,v2,9/9] rk3288: vyasa: Add eMMC boot support

2018-02-25 Thread Philipp Tomsich
> RK3288 Vyasa has eMMC boot support, with JP4 open.
> 
> Signed-off-by: Jagan Teki 
> ---
> Note:
> Linux patch for this support is in ML.
> 
>  arch/arm/dts/rk3288-vyasa-u-boot.dtsi |  4 
>  arch/arm/dts/rk3288-vyasa.dts | 11 +++
>  board/amarula/vyasa-rk3288/vyasa-rk3288.c |  7 +++
>  3 files changed, 22 insertions(+)
> 

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


Re: [U-Boot] [PATCH v2 1/2] core: add uclass_get_device_by_phandle_id() api

2018-02-25 Thread Simon Glass
Hi Kever,

On 23 February 2018 at 19:08, Kever Yang  wrote:
> Hi Simon,
>
>
> On 02/12/2018 10:35 PM, Simon Glass wrote:
>> Hi Kever,
>>
>> On 8 February 2018 at 19:56, Kever Yang  wrote:
>>> Add api for who can not get phandle from a device property.
>> Can you please add a motivation to the commit message? It is not
>> obvious to me when this function would be used.
> Here is the example why I need this, see the dts node here:
> lvds@ff2e {
> ...
> rockchip,grf = <&grf>;
> port {
> port@0 {
> endpoint@0 {
> remote-endpoint = <&vopl_out_lvds>;
> }
> }
> }
> }
>
> We can only get 'grf' udevice by uclass_get_device_by_phandle(),
> but we not able to get udevice 'vopl_out_lvds', other driver like
> rockchip pinctrl
> also need to get udevice by a phandle which is not one of direct property of
> another device node.

OK I see. This sort of info is useful in the commit message. It helps
to know two things about a patch:

- why it is needed
- what it does

In this case see rk_display_init() for how it handles the
'remote-endpoint' property. I think it would be better to have
something like:

ofnode ofnode_lookup_phandle(ofnode node, const char *prop_name);

This should meet your needs without needing to decoding the phandle
property in the caller.

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


[U-Boot] [PATCH 1/2] ARM: dts: imx6ul: add wdog3

2018-02-25 Thread Jörg Krause
The i.MX6UL has a WDOG3 located at start address 0x021E in the
AIPS-2 memory region [1].

[1] i.MX 6UltraLite Applications Processor Reference Manual, Rev. 1,
04/2016, Table-2-3 AIPS-2 memory map, p. 166

Signed-off-by: Jörg Krause 
---
 arch/arm/dts/imx6ul.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/imx6ul.dtsi b/arch/arm/dts/imx6ul.dtsi
index 7affab866f..b63f5a53ac 100644
--- a/arch/arm/dts/imx6ul.dtsi
+++ b/arch/arm/dts/imx6ul.dtsi
@@ -881,6 +881,14 @@
status = "disabled";
};
 
+   wdog3: wdog@021e4000 {
+   compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
+   reg = <0x021e4000 0x4000>;
+   interrupts = ;
+   clocks = <&clks IMX6UL_CLK_WDOG3>;
+   status = "disabled";
+   };
+
uart2: serial@021e8000 {
compatible = "fsl,imx6ul-uart",
 "fsl,imx6q-uart";
-- 
2.16.2

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


[U-Boot] [PATCH 2/2] ARM: dts: imx6ull: add wdog3

2018-02-25 Thread Jörg Krause
The i.MX6ULL has a WDOG3 located at start address 0x021E in the
AIPS-2 memory region [1].

[1] i.MX 6ULL Applications Processor Reference Manual, Rev. 1, 11/2017,
Table 2-3. AIPS-2 memory map, p. 178

Signed-off-by: Jörg Krause 
---
 arch/arm/dts/imx6ull.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/imx6ull.dtsi b/arch/arm/dts/imx6ull.dtsi
index 28b8422f31..f8ec649460 100644
--- a/arch/arm/dts/imx6ull.dtsi
+++ b/arch/arm/dts/imx6ull.dtsi
@@ -1026,6 +1026,14 @@
status = "disabled";
};
 
+   wdog3: wdog@021e4000 {
+   compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
+   reg = <0x021e4000 0x4000>;
+   interrupts = ;
+   clocks = <&clks IMX6UL_CLK_WDOG3>;
+   status = "disabled";
+   };
+
uart2: serial@021e8000 {
compatible = "fsl,imx6ul-uart",
 "fsl,imx6q-uart", "fsl,imx21-uart";
-- 
2.16.2

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


Re: [U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

2018-02-25 Thread Wolfgang Denk
Dear Lukasz,

In message <20180225161813.10554012@jawa> you wrote:
>
> As I've read the discussion between Tom and Wolfgang - I'm wondering if
> this initialization could be done in the driver model?

Indeed DM would be a good place for such lazy initialization as
would be useful here.
> 
> I think that DM is a right place to put such code (ecluding the case
> of env in eMMC readed in SPL).

But even there we cannot add code to initialize all kinds of
potential storage devices to all kinds of supported file systems.
This may work with a single fixed configuration (which probably is
what the OP had in mind), but it does not scale, and it is the wrong
thing to do.

> I've added Simon to CC, so maybe he can give us some insights.

Thanks.  Hopefully Simon has a clever idea...

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
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR

2018-02-25 Thread Alex Kiernan
On Sun, Feb 25, 2018 at 1:23 PM, Tom Rini  wrote:
> On Sun, Feb 25, 2018 at 11:29:30AM +0100, Lukasz Majewski wrote:
>> Hi Tom,
>>
>> > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig.  We can
>> > provide a default for BOOTCOUNT_AM33XX as that's a specific part of
>> > the RTC in use.  We can also provide a default for ARCH_LS1043A and
>> > ARCH_LS1021A as they had been previously calculated and their symbols
>> > are in Kconfig.  In the case of other QE-enabled platforms, they are
>> > not so we must update the relevant defconfig files.  The previous
>> > default only applied in some cases, even on a specific SoC family.
>>
>> Thanks for your patch.
>>
>> I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig.
>>
>> Please correct me if I'm wrong, but it shall be applied on top of
>> Alex's series:
>>
>> http://patchwork.ozlabs.org/cover/874539/
>
> Correct.  I tested that and the only part I wasn't 100% confident in
> after transition was the addresses.
>

Having looked at it both ways (migrate CONFIG_SYS_BOOTCOUNT_ADDR into
Kconfig, migrate everything out of the CONFIG_ namespace) they both
seem to have downsides... either you have magic numbers in Kconfig or
you have configuration littered through include files. It feels like
it wants some piece of machinery we don't really have today.

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


Re: [U-Boot] [PATCH] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR

2018-02-25 Thread Alex Kiernan
On Sun, Feb 25, 2018 at 3:50 AM, Tom Rini  wrote:
> Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig.  We can
> provide a default for BOOTCOUNT_AM33XX as that's a specific part of the
> RTC in use.  We can also provide a default for ARCH_LS1043A and
> ARCH_LS1021A as they had been previously calculated and their symbols
> are in Kconfig.  In the case of other QE-enabled platforms, they are not
> so we must update the relevant defconfig files.  The previous default
> only applied in some cases, even on a specific SoC family.
>
> Signed-off-by: Tom Rini 

Reviewed-by: Alex Kiernan 

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


Re: [U-Boot] [U-Boot, v2] env: mmc/fat/ext4: make sure that the MMC sub-system is initialized before using it

2018-02-25 Thread Tom Rini
On Sun, Feb 25, 2018 at 03:50:41PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180225134810.GU4311@bill-the-cat> you wrote:
> > 
> > > We should keep the code clean and orthogonal.  Driver init code has
> > > no place in file system code.
> > >
> > > If needed, the drivers have to make sure to auto--initialize on
> > > first access.
> > >
> > > I hold my NAK on this patch.  It is the wrong thing to do.
> > 
> > I think you have this a little bit wrong.  But, it's also where we are
> > with the DM conversion.  This _is_ the first place we're trying to
> > access the MMC.  And it's not in the filesystem code, it's in the
> > environment code.
> 
> Maybe I was not really clear.  You are right as this is not generic
> file system code.  Instead, it is the EXT4 support code for the
> environment handling.
> 
> The patch adds mmc_initialize() to env_ext4_load(), so whenever we
> try to load the environment from an EXT4 file system, it will
> initialize the MMC subsystem.
> 
> However - what if we want to load the environment from an EXT4 file
> system on any other storage device - say, USB, or SATA, or flash?

Good question, and part of why after re-reading the code, I want to see
just what the combination of hardware Faiz is trying is.  MMC should
already have been initialized.  Unless I'm missing the specific init
path he has.  This does also highlight that env on fat/ext4 as only
likely been tested on MMC devices, even prior to the recent changes.

> In all such cases the initialization of MMC would be plain wrong.

Correct, and we don't try and initialize MMC if we aren't told that the
environment resides on mmc.

> And what if we want to load the environment from any other type of
> file system - say, cramfs, zfs, etc. - on SDCard or eMMC?  These do
> not initialize MMC, so it would fail?
> 
> Yes, we have the same crappy code in env/fat.c, but this is the
> wrong thing to do, and must be cleaned up there as well.

Yes, one of the things I've suggested before is that ENV_IS_IN_FAT and
ENV_IS_IN_EXT should be able to be rewritten to use the generic FS
operation API we have so that zfs, etc, could be automatically
supported.

> This is what I meant when I wrote that the file system (interface)
> code and the storage device support code are independent of each
> other, and code should be kept orthogonal - storage support like MMC
> etc. has no place in code dealing with a specific file system type.

The problem we have today, and I hope we can more cleverly resolve once
more/everything has been migrated to DM is that don't yet have a good
way to say "retry $X later" or "retry $X after $Y".  Because setting
aside the specific issue Faiz ran into, FS+SATA has never worked because
initr_scsi is well after initr_env, and that's why the sata env code
(which uses blocks and not fs) has always had to sata_initialize().

> I still think my NAK is reasonable.

Conceptually, I disagree because we don't yet have a more nicer solution
available yet.  With this specific patch, it might be a problem with the
board code, as mmc_initialize() should already have been called.  So
maybe this needs to come out.

-- 
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] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR

2018-02-25 Thread Tom Rini
On Sun, Feb 25, 2018 at 05:44:42PM +, Alex Kiernan wrote:
> On Sun, Feb 25, 2018 at 1:23 PM, Tom Rini  wrote:
> > On Sun, Feb 25, 2018 at 11:29:30AM +0100, Lukasz Majewski wrote:
> >> Hi Tom,
> >>
> >> > Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig.  We can
> >> > provide a default for BOOTCOUNT_AM33XX as that's a specific part of
> >> > the RTC in use.  We can also provide a default for ARCH_LS1043A and
> >> > ARCH_LS1021A as they had been previously calculated and their symbols
> >> > are in Kconfig.  In the case of other QE-enabled platforms, they are
> >> > not so we must update the relevant defconfig files.  The previous
> >> > default only applied in some cases, even on a specific SoC family.
> >>
> >> Thanks for your patch.
> >>
> >> I suppose, that it is a last puzzle to convert BOOTCOUNT to Kconfig.
> >>
> >> Please correct me if I'm wrong, but it shall be applied on top of
> >> Alex's series:
> >>
> >> http://patchwork.ozlabs.org/cover/874539/
> >
> > Correct.  I tested that and the only part I wasn't 100% confident in
> > after transition was the addresses.
> >
> 
> Having looked at it both ways (migrate CONFIG_SYS_BOOTCOUNT_ADDR into
> Kconfig, migrate everything out of the CONFIG_ namespace) they both
> seem to have downsides... either you have magic numbers in Kconfig or
> you have configuration littered through include files. It feels like
> it wants some piece of machinery we don't really have today.

Long term, I think cases like this should be handled either way default
0xF00 if BAR or yes, we re-work things so it's out of the CONFIG
namespace.  In the case of bootcount_davinci.c we could easily key that
off of CONFIG_AM33XX #elif CONFIG_SOC_DA8XX as we're talking about an
on-chip RTC and that's not going to vary much in location.  But for the
generic driver that really is harder to say.

-- 
Tom


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


Re: [U-Boot] [PATCH v2 0/3] ARM: omap3: beagle, evm: synchronize common setup

2018-02-25 Thread Derald D. Woods
On Sat, Feb 24, 2018 at 01:39:45PM -0600, Derald Woods wrote:
> On Sat, Feb 24, 2018 at 02:12:32PM -0500, Tom Rini wrote:
> > On Sat, Feb 24, 2018 at 09:29:02AM -0600, Derald D. Woods wrote:
> > > On Sat, Feb 24, 2018 at 09:35:43AM -0500, Tom Rini wrote:
> > > > On Sat, Feb 24, 2018 at 08:09:39AM -0600, Derald D. Woods wrote:
> > > >
> > > > > This short series is an attempt to make this set of boards use the 
> > > > > same
> > > > > default configuration items where possible. This was prompted by an
> > > > > investigation into enabling SERIAL_SEARCH_ALL on omap3_evm. This 
> > > > > feature
> > > > > now works for omap3_evm after this series.
> > > > >
> > > > > The series changes the default NAND layout of MTDPARTS_DEFAULT and
> > > > > uses ENV_IS_IN_FAT. More detail is provided with the patches. As most
> > > > > things are configurable now, this should not be an issue. I am trying
> > > > > to get simple defaults that just boot and expose the common core
> > > > > features. This will make future testing and maintenance a bit more
> > > > > predictable, as there will be a very similar comparable set of boards.
> > > >
> > > > I was thinking, wouldn't we want to update the beagle code now to do env
> > > > in NAND on beagleboard and env on FAT on xM?  We could provide a new
> > > > env_get_location() to return the right location based on board.  Thanks!
> > > >
> > >
> > > I thought of that too. xM can never use NAND. So FAT is always right for
> > > it. Regular BeagleBoard(3530) can have the environment in either location.
> > > Configuration can simply handle the user preference. I did not see a
> > > reason to add any more logic into an already heavy board file. The Overo
> > > boards are equally heavy with board type logic. For now, my thinking
> > > was to allow configuration do the work.
> >
> > OK, but on the other hand, xM must have an SD card inserted and vanilla
> > does not require an SD card.  So now those users need to put in an SD
> > card.  Now, I honestly don't know how big a deal that is really, so I
> > won't nak the patches.  But I do think it would be the best user
> > experience to have classic continue to work as-is and xM to finally get
> > functional env.
> >
> 
> I will try to add the 'env_get_location'. So let's hold until I can push a
> 'v3' of the series.
> 
> The possible env locations:
> 
> ENVL_FAT
> ENVL_MMC
> ENVL_NAND
> ENVL_UBI
> 
> If those make sense, 'env_get_location' priority will select one of them.
> 

Using 'env_get_location' is not working with this diff:

---8<--
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 1d55264733..22e6af7bb8 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "beagle.h"
 #include 
 
@@ -332,6 +333,34 @@ static struct musb_hdrc_platform_data musb_plat = {
 };
 #endif
 
+#if defined(CONFIG_SPL_BUILD) && \
+   defined(CONFIG_ENV_IS_IN_NAND) && \
+   defined(CONFIG_ENV_IS_IN_FAT)
+enum env_location env_get_location(enum env_operation op, int prio)
+{
+   switch (prio) {
+   case 0:
+   return ENVL_FAT;
+   case 1:
+   switch (get_board_revision()) {
+   case REVISION_AXBX:
+   case REVISION_CX:
+   case REVISION_C4:
+   return ENVL_NAND;
+   case REVISION_XM_AB:
+   case REVISION_XM_C:
+   default:
+   return ENVL_FAT;
+   }
+   break;
+   default:
+   break;
+   }
+
+   return ENVL_UNKNOWN;
+}
+#endif /* CONFIG_SPL_BUILD && CONFIG_ENV_IS_IN_{NAND,FAT} */
+
 /*
  * Routine: misc_init_r
  * Description: Configure board specific parts
---8<---

Additionally, it will not boot without using '#if defined(CONFIG_SPL_BUILD)'.
When booting on BeagleBoard-xM, I get the following:

---8<---
U-Boot SPL 2018.03-rc3-00033-g881e2514dd-dirty (Feb 25 2018 - 12:26:00 -0600)
Trying to boot from MMC1
spl_load_image_fat_os: error reading image args, err - -2


U-Boot 2018.03-rc3-00033-g881e2514dd-dirty (Feb 25 2018 - 12:26:00 -0600)

OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
Model: TI OMAP3 BeagleBoard xM
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Failed (-5)
Loading Environment from NAND... *** Warning - readenv() failed, using default 
environment

Failed (-5)
Beagle xM Rev C
No EEPROM on expansion board
OMAP die ID: 46da00029ff80168300f15027017
Net:   usb_ether
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
   scanning usb for storage devices... 0 Sto

Re: [U-Boot] [U-Boot, v2, 1/9] ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux

2018-02-25 Thread Philipp Tomsich
> Sync rk3288-vyasa board dts from Linux for proper updates and maintenance
> - rk3288-vyasa.dts: Similar to Linux dts
> - rk3288-vyasa-u-boot.dtsi: u-boot dts changes
> 
> Also updated MAINTAINERS for these dts files.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3288-vyasa-u-boot.dtsi  |  29 +++
>  arch/arm/dts/rk3288-vyasa.dts  | 134 
> ++---
>  board/amarula/vyasa-rk3288/MAINTAINERS |   2 +
>  3 files changed, 105 insertions(+), 60 deletions(-)
>  create mode 100644 arch/arm/dts/rk3288-vyasa-u-boot.dtsi
> 

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


Re: [U-Boot] [U-Boot, v2, 3/9] ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC

2018-02-25 Thread Philipp Tomsich
> rk808, SWITCH_REG1 has configured for sdmmc regulator as vcc_sd,
> so use the same by renaming vcc33_sd to vcc_sd(as per schematic)
> and drop explicit regulator definition from root.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 22 ++
>  1 file changed, 2 insertions(+), 20 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 2/9] ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1

2018-02-25 Thread Philipp Tomsich
> vdd_log, never used on DCDC_REG1 of rk808 from latest schematic so
> remove the same and update the regulator-name as 'vdd_arm' to sync
> with existing rk3288 board dts files.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

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


Re: [U-Boot] [U-Boot, v2, 5/9] ARM: dts: rockchip: Add gmac support for rk3288-vyasa board

2018-02-25 Thread Philipp Tomsich
> Sync gmac dts node from Linux.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Signed-off-by: Jagan Teki 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 41 +
>  1 file changed, 41 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 4/9] ARM: dts: rockchip: Add regulators for rk3288-vyasa

2018-02-25 Thread Philipp Tomsich
> Add supporting regulators for rk3288-vyasa board, dc12_vbat is
> parent regulatorand followed regulators as are child regulators.
> regulator naming conversion followed as per schematic for better
> readability and easy for identification.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 40 
>  1 file changed, 40 insertions(+)
> 

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


Re: [U-Boot] [U-Boot,v2,9/9] rk3288: vyasa: Add eMMC boot support

2018-02-25 Thread Philipp Tomsich
> RK3288 Vyasa has eMMC boot support, with JP4 open.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> Note:
> Linux patch for this support is in ML.
> 
>  arch/arm/dts/rk3288-vyasa-u-boot.dtsi |  4 
>  arch/arm/dts/rk3288-vyasa.dts | 11 +++
>  board/amarula/vyasa-rk3288/vyasa-rk3288.c |  7 +++
>  3 files changed, 22 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 7/9] ARM: dts: rockchip: Add usb host for rk3288-vyasa

2018-02-25 Thread Philipp Tomsich
> Add usb host support for rk3288-vyasa, board support hub power
> through phy_pwr_en and usb2 host power through usb2_pwr_en and
> naming conversion followed as per schematic.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 48 
> +++
>  1 file changed, 48 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 8/9] ARM: dts: rockchip: Add usb otg for rk3288-vyasa

2018-02-25 Thread Philipp Tomsich
> Add usb otg support for rk3288-vyasa, board support usb1 otg
> power through otg_vbus_drv and naming conversion followed
> as per schematic.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
>  arch/arm/dts/rk3288-vyasa.dts | 25 +
>  1 file changed, 25 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v2, 6/9] rockchip: rk3288-vyasa: defconfig: Enable gmac support

2018-02-25 Thread Philipp Tomsich
> Enable gmac support for rk3288-vyasa board.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
>  configs/vyasa-rk3288_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 

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


Re: [U-Boot] [U-Boot, v3, 01/11] Merge CONFIG_BOOTCOUNT and CONFIG_BOOTCOUNT_LIMIT

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:38PM +, Alex Kiernan wrote:

> CONFIG_BOOTCOUNT was only used in mx53ppd, merge it with
> CONFIG_BOOTCOUNT_LIMIT
> 
> Signed-off-by: Alex Kiernan 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Ian Ray 

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/11] Prepare for multiple bootcount drivers

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:39PM +, Alex Kiernan wrote:

> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Alex Kiernan 

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/11] Convert CONFIG_BOOTCOUNT_AM33XX to Kconfig

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:40PM +, Alex Kiernan wrote:

> This converts the following to Kconfig:
>   CONFIG_BOOTCOUNT_AM33XX
> 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Hannes Schmelzer 
> Acked-by: Hannes Schmelzer 
> Signed-off-by: Alex Kiernan 

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/11] Convert CONFIG_BOOTCOUNT_RAM to Kconfig

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:42PM +, Alex Kiernan wrote:

> This converts the following to Kconfig:
>   CONFIG_BOOTCOUNT_RAM
> 
> Signed-off-by: Alex Kiernan 
> Reviewed-by: Lukasz Majewski 

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/11] Convert CONFIG_BOOTCOUNT_ENV to Kconfig

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:41PM +, Alex Kiernan wrote:

> This converts the following to Kconfig:
>   CONFIG_BOOTCOUNT_ENV
> 
> Signed-off-by: Alex Kiernan 
> Reviewed-by: Lukasz Majewski 

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/11] Integrate AT91 bootcount driver

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:45PM +, Alex Kiernan wrote:

> Integrate Boot counter for Atmel AT91SAM9XE into Kconfig
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Alex Kiernan 

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/11] Remove CONFIG_SYS_BOOTCOUNT_SINGLEWORD

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:48PM +, Alex Kiernan wrote:

> Tidy up CONFIG_SYS_BOOTCOUNT_SINGLEWORD from the whitelist as there's
> no remaining uses of it left.
> 
> Signed-off-by: Alex Kiernan 

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/11] Convert CONFIG_BOOTCOUNT_I2C to Kconfig

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:43PM +, Alex Kiernan wrote:

> This converts the following to Kconfig:
>   CONFIG_BOOTCOUNT_I2C
> 
> Signed-off-by: Alex Kiernan 
> Reviewed-by: Lukasz Majewski 

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, 07/11] Convert CONFIG_BOOTCOUNT_EXT to Kconfig

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:44PM +, Alex Kiernan wrote:

> This converts the following to Kconfig:
>   CONFIG_BOOTCOUNT_EXT
> 
> Signed-off-by: Alex Kiernan 

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/11] Migrate generic bootcount to Kconfig

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:46PM +, Alex Kiernan wrote:

> Make generate boot counter selected in the same way as other boot count
> drivers
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Alex Kiernan 

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] bootcount: Migrate CONFIG_SYS_BOOTCOUNT_ADDR

2018-02-25 Thread Tom Rini
On Sat, Feb 24, 2018 at 10:50:19PM -0500, Tom Rini wrote:

> Migrate the users of CONFIG_SYS_BOOTCOUNT_ADDR to Kconfig.  We can
> provide a default for BOOTCOUNT_AM33XX as that's a specific part of the
> RTC in use.  We can also provide a default for ARCH_LS1043A and
> ARCH_LS1021A as they had been previously calculated and their symbols
> are in Kconfig.  In the case of other QE-enabled platforms, they are not
> so we must update the relevant defconfig files.  The previous default
> only applied in some cases, even on a specific SoC family.
> 
> Signed-off-by: Tom Rini 

With R-B's added, 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/11] Migrate CONFIG_BOOTCOUNT_ALEN to Kconfig

2018-02-25 Thread Tom Rini
On Fri, Feb 16, 2018 at 03:50:47PM +, Alex Kiernan wrote:

> Convert CONFIG_BOOTCOUNT_ALEN to Kconfig
> Signed-off-by: Alex Kiernan 

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 v2 2/4] mmc: omap_hsmmc: compile out write support if not needed

2018-02-25 Thread Jaehoon Chung
On 02/23/2018 09:21 PM, Tom Rini wrote:
> On Fri, Feb 23, 2018 at 10:40:17AM +0100, Jean-Jacques Hiblot wrote:
> 
>> This reduces the size of the binary by about 196 bytes.
>>
>> Signed-off-by: Jean-Jacques Hiblot 
> 
> Reviewed-by: Tom Rini 

Applied to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 

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


Re: [U-Boot] [PATCH v2 3/4] mmc: omap_hsmmc: make it possible to compile out ADMA support

2018-02-25 Thread Jaehoon Chung
On 02/23/2018 09:57 PM, Tom Rini wrote:
> On Fri, Feb 23, 2018 at 01:47:36PM +0100, Jean-Jacques Hiblot wrote:
>>
>>
>> On 23/02/2018 13:21, Tom Rini wrote:
>>> On Fri, Feb 23, 2018 at 10:40:18AM +0100, Jean-Jacques Hiblot wrote:
 Some platforms don't have ADMA controllers. For those platforms, compiling
 it out reduces the size of the binary by about 600 bytes.
 Leaving the support in doesn't break things as the driver checks at runtime
 if the ADMA2 controller is present.

 Signed-off-by: Jean-Jacques Hiblot 

 ---

 Changes in v2:
 - Use a Kconfig option to compile out the ADMA support instead of relying
   on the platform architecture

  drivers/mmc/Kconfig  |  9 +
  drivers/mmc/omap_hsmmc.c | 12 ++--
  2 files changed, 15 insertions(+), 6 deletions(-)

 diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
 index f2d8256..88a1359 100644
 --- a/drivers/mmc/Kconfig
 +++ b/drivers/mmc/Kconfig
 @@ -239,6 +239,15 @@ config MMC_OMAP_HS
  If unsure, say N.
 +config MMC_OMAP_HS_ADMA
 +  bool "ADMA support for OMAP HS MMC"
 +  depends on MMC_OMAP_HS && !OMAP34XX
 +  default y if !AM33XX
>>> Is this logic really the right restrictions?  Does it work on some
>>> AM33XX platforms (AM43xx?) and just never OMAP34XX?  Thanks!
>> Starting with platform am33xx there is a way to check if the ADMA controller
>> is present or not by reading a register. This register is not available in
>> OMAP34XX.
>> That being said I don't think that ADMA is available on any variant of
>> am33xx.
> 
> OK, thanks!
> 
> Reviewed-by: Tom Rini 

Applied to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 

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


Re: [U-Boot] [PATCH v2 4/4] mmc: omap_hsmmc: use a default 52MHz max clock rate if none is specified

2018-02-25 Thread Jaehoon Chung
On 02/23/2018 09:21 PM, Tom Rini wrote:
> On Fri, Feb 23, 2018 at 10:40:19AM +0100, Jean-Jacques Hiblot wrote:
> 
>> mmc_of_parse() doesn't set a default value if none is available in DT.
>> In that case, use a default 52MHz clock rate.
>>
>> Signed-off-by: Alex Kiernan 
>> Signed-off-by: Jean-Jacques Hiblot 
>>
> 
> Reviewed-by: Tom Rini 


Applied to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 

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


Re: [U-Boot] [PATCH v2 1/4] mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat

2018-02-25 Thread Jaehoon Chung
On 02/23/2018 09:21 PM, Tom Rini wrote:
> On Fri, Feb 23, 2018 at 10:40:16AM +0100, Jean-Jacques Hiblot wrote:
> 
>> The area for struct mmc can be allocated dynamically. It greatly reduces
>> the size of struct omap_hsmmc_plat. This is useful in cases where the board
>> level code declares one or two struct omap_hsmmc_plat because it doesn't
>> use the Driver Model.
>>
>> This saves around 740 bytes for the am335x_evm SPL.
>>
>> Signed-off-by: Jean-Jacques Hiblot 
> 
> Reviewed-by: Tom Rini 

Applied to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 

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


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

2018-02-25 Thread Jaehoon Chung
Dear Tom,

Could you pull these patches to u-boot/master?

The following changes since commit f0f6917188ad660cf002c10095f46ecf748b8f58:

  Prepare v2018.03-rc3 (2018-02-20 16:51:56 -0500)

are available in the Git repository at:

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

for you to fetch changes up to beac7d33d9131d22ffbdbfbf2786858062b63786:

  mmc: omap_hsmmc: use a default 52MHz max clock rate if none is specified 
(2018-02-26 10:52:15 +0900)


Alexander Kochetkov (1):
  mmc: fix off-by-one bug in mmc_startup_v4()

Faiz Abbas (1):
  mmc: Drop unnecessary case for mmc_probe()

Jaehoon Chung (1):
  mmc: synchronize the sequence with enum bus_mode in mmc.h

Jean-Jacques Hiblot (4):
  mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat
  mmc: omap_hsmmc: compile out write support if not needed
  mmc: omap_hsmmc: make it possible to compile out ADMA support
  mmc: omap_hsmmc: use a default 52MHz max clock rate if none is specified

 arch/arm/include/asm/omap_mmc.h |  2 +-
 drivers/mmc/Kconfig |  9 +
 drivers/mmc/mmc.c   | 20 +---
 drivers/mmc/omap_hsmmc.c| 31 ---
 4 files changed, 35 insertions(+), 27 deletions(-)

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


Re: [U-Boot] [PATCH] core: do not fail in device_probe() when clk set default fail

2018-02-25 Thread Kever Yang


On 02/25/2018 06:52 PM, Dr. Philipp Tomsich wrote:
>> On 25 Feb 2018, at 11:24, Kever Yang  wrote:
>>
>> Assigned clocks are widely used in kernel, but not in U-Boot yet,
>> many U-Boot clock driver do not have the API while dts port from kernel
>> have "assigned-clocks" node.
>>
>> Just give a warning now instead of a device probe fail.
> I strongly disagree on this one: the only reason this can fail is if 
> assigned-clock-rates
> can not be set (e.g. because a clock that should be assigned to is not known 
> by the
> clock driver).  However, this should never be ignored silently.

Whe we search "assigned-clocks" in dts, you can see a lot of result in
different platform,
just as I mentioned in commit message because this is widely used in kernel.
In other hand, when we search "set_parent" in clock driver, only part of
Rockchip SoCs
support it, and only GMAC support this, everything else will get an
error return and
failed in device_probe() which means driver been broken.

I think it's more reasonable to like pinctrl, we can try to set it, but
not fail on error return,
or else too many modules been break before they are ready to support the
new feature.

Or maybe we should not return error if ops->set_parent is empty.

>
> If the clock subsystem does not know all clocks that are being attempted to 
> set, then
> commits to shared drivers will eventually break: e.g. commit ba1f96672522
> ("net: designware: add clock support”) recently broke the GMAC for the RK3368 
> and
> RK3399 because it iterated over all clocks defined in the “clocks” property 
> of the
> GMAC node.
>
> As long as various drivers perform an unconditional clk_enable and/or an 
> unconditional
> clk_set_rate, we should enforce this in the core already.  In consequence, 
> dedicated
> code from the drivers should now start to slowly disappear, as clock-rates 
> can now be
> set via the DTS.

This is an option in kernel for a long time, but not mandatory, so we should
make both(the new feature and drivers already there) work, or clean and
replace
everything in driver already there before enforce to use the new feature
in core.

Thanks,
- Kever
>
>> Signed-off-by: Kever Yang 
>> ---
>>
>> drivers/core/device.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>> index 9d58f44..71872e9 100644
>> --- a/drivers/core/device.c
>> +++ b/drivers/core/device.c
>> @@ -407,7 +407,7 @@ int device_probe(struct udevice *dev)
>>  /* Process 'assigned-{clocks/clock-parents/clock-rates}' properties */
>>  ret = clk_set_defaults(dev);
>>  if (ret)
>> -goto fail;
>> +debug("%s clk_set_defaults failed %d\n", ret);
> This probably shouldn’t have been a silent failure.
> A pr_err() may be more appropriate… I would recommend this to continue failing
> though, as it is simple enough to handle the additional clocks in the clock 
> drivers
> and create a permanent record of “things not needing additional changes, due 
> to
> the BROM already having set up things” by returning success.
>
>>  if (drv->probe) {
>>  ret = drv->probe(dev);
>> -- 
>> 1.9.1
>>
>


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


Re: [U-Boot] [PATCH v2 1/2] core: add uclass_get_device_by_phandle_id() api

2018-02-25 Thread Kever Yang
Hi Simon,


On 02/25/2018 11:54 PM, Simon Glass wrote:
> Hi Kever,
>
> On 23 February 2018 at 19:08, Kever Yang  wrote:
>> Hi Simon,
>>
>>
>> On 02/12/2018 10:35 PM, Simon Glass wrote:
>>> Hi Kever,
>>>
>>> On 8 February 2018 at 19:56, Kever Yang  wrote:
 Add api for who can not get phandle from a device property.
>>> Can you please add a motivation to the commit message? It is not
>>> obvious to me when this function would be used.
>> Here is the example why I need this, see the dts node here:
>> lvds@ff2e {
>> ...
>> rockchip,grf = <&grf>;
>> port {
>> port@0 {
>> endpoint@0 {
>> remote-endpoint = <&vopl_out_lvds>;
>> }
>> }
>> }
>> }
>>
>> We can only get 'grf' udevice by uclass_get_device_by_phandle(),
>> but we not able to get udevice 'vopl_out_lvds', other driver like
>> rockchip pinctrl
>> also need to get udevice by a phandle which is not one of direct property of
>> another device node.
> OK I see. This sort of info is useful in the commit message. It helps
> to know two things about a patch:
>
> - why it is needed
> - what it does
>
> In this case see rk_display_init() for how it handles the
> 'remote-endpoint' property. I think it would be better to have
> something like:
>
> ofnode ofnode_lookup_phandle(ofnode node, const char *prop_name);
Yes, this is enough for "remote-endpoint" case, but not for pinctrl case:
1199 pinctrl: pinctrl {
2095 pwm0
{ 
2096 pwm0_pin: pwm0-pin
{   
2097 rockchip,pins
=
2098 <0 RK_PB7 RK_FUNC_1
&pcfg_pull_none>;  
2099
}; 
2100 };

I think ofnode_lookup_phandle() still not able to find node for
'pcfg_pull_none'.

Thanks,
- Kever
>
> This should meet your needs without needing to decoding the phandle
> property in the caller.
>
> Regards,
> Simon
>


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


Re: [U-Boot] [PULL] Please pull u-boot-imx

2018-02-25 Thread Tom Rini
On Sat, Feb 24, 2018 at 04:58:14PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> some fixes, please pull from u-boot-imx, thanks!
> 
> The following changes since commit 02b0895c215e252cff50d9edf53a972d2bbbfd30:
> 
>   Merge git://git.denx.de/u-boot-sh (2018-02-17 16:06:59 -0500)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 3d409153502f25a1ea3b8b4e9940148b7871273d:
> 
>   imx6q: engicam: Use SPL_LOAD_FIT for MMC boards (2018-02-22 14:51:01
> +0100)
> 

For the updated version, 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] Please pull u-boot-rockchip/master

2018-02-25 Thread Tom Rini
On Sun, Feb 25, 2018 at 11:43:13AM +0100, Dr. Philipp Tomsich wrote:

> Tom,
> 
> we have additional fixes ready for you:
>   * the TPL-build process for the Vyasa board was fixed by Jagan (by 
> providing the correct TEXT_BASE)
>   * a regression on Ethernet for the RK3399 and RK3368 has been resolved 
> by adding support for its clocks
>   * a regression on PMIC probing on the RK399 has been resolved by adding 
> support for the assigned-clocks of the PMUCRU
> 
> Travis report is at 
> https://travis-ci.org/ptomsich/u-boot-rockchip/builds/345699336
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit 0bb430c8494e26e8d258cf6957cdd39d2ce4f309:
> 
>   Merge git://git.denx.de/u-boot-video (2018-02-24 08:02:17 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to 434d5a00a4578f826e7e2cef29bf2388dd760a88:
> 
>   rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL (2018-02-24 
> 18:50:03 +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] Please pull u-boot-rockchip/master

2018-02-25 Thread Jonathan Gray
On Sun, Feb 25, 2018 at 11:43:13AM +0100, Dr. Philipp Tomsich wrote:
> Tom,
> 
> we have additional fixes ready for you:
>   * the TPL-build process for the Vyasa board was fixed by Jagan (by 
> providing the correct TEXT_BASE)
>   * a regression on Ethernet for the RK3399 and RK3368 has been resolved 
> by adding support for its clocks

RK3288 and others share the same regression.

'designware: fix clock enable' fixed it but is not in master yet.

https://patchwork.ozlabs.org/patch/869785/

>   * a regression on PMIC probing on the RK399 has been resolved by adding 
> support for the assigned-clocks of the PMUCRU
> 
> Travis report is at 
> https://travis-ci.org/ptomsich/u-boot-rockchip/builds/345699336
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit 0bb430c8494e26e8d258cf6957cdd39d2ce4f309:
> 
>   Merge git://git.denx.de/u-boot-video (2018-02-24 08:02:17 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to 434d5a00a4578f826e7e2cef29bf2388dd760a88:
> 
>   rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL (2018-02-24 
> 18:50:03 +0100)
> 
> 
> Jagan Teki (2):
>   rockchip: rk3288: Add TPL_LDSCRIPT
>   rockchip: rk3288: Fix wrong TPL_TEXT_BASE
> 
> Philipp Tomsich (3):
>   rockchip: clk: rk3399: handle clk_enable requests for GMAC
>   rockchip: clk: rk3368: handle clk_enable requests for GMAC
>   rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL
> 
>  arch/arm/mach-rockchip/Kconfig   | 10 ++
>  arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++
>  configs/vyasa-rk3288_defconfig   |  1 -
>  drivers/clk/rockchip/clk_rk3368.c| 19 +++
>  drivers/clk/rockchip/clk_rk3399.c| 19 +++
>  5 files changed, 58 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system

2018-02-25 Thread Chee, Tien Fong
On Thu, 2018-02-22 at 15:28 +0100, Marek Vasut wrote:
> On 02/22/2018 09:18 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-02-15 at 15:58 +0100, Marek Vasut wrote:
> > > 
> > > On 02/05/2018 08:06 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > Reviewed-by: Lothar Waßmann 
> > > [...]
> > > 
> > > > 
> > > > 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#ifdef CONFIG_SPL
> > > Are the ifdefs needed ?
> > > 
> > Because spl.h contains some codes have its dependency with SPL. So,
> > Tom
> > adviced to make this part of code depend on CONFIG_SPL.
> > However, only __weak int init_mmc() depend on the codes from spl.h,
> > so
> > user can override their own init_mmc() if SPL is not used.
> You probably dont need those ifdefs around headers.
> 
> > 
> > > 
> > > > 
> > > > +#include 
> > > > +#endif
> > > > +#include 
> > > > +#ifdef CONFIG_CMD_UBIFS
> > > > +#include 
> > > > +#include 
> > > > +#endif
> > > > +#include 
> > > > +
> > > > +struct firmware_priv {
> > > > +   const char *name;   /* Filename */
> > > > +   u32 offset; /* Offset of reading a file
> > > > */
> > > > +};
> > > > +
> > > > +static struct device_location default_locations[] = {
> > > > +   {
> > > > +   .name = "mmc",
> > > > +   .devpart = "0:1",
> > > > +   },
> > > > +   {
> > > > +   .name = "usb",
> > > > +   .devpart = "0:1",
> > > > +   },
> > > > +   {
> > > > +   .name = "sata",
> > > > +   .devpart = "0:1",
> > > > +   },
> > > How can this load from UBI if it's not listed here ?
> Well ?
> 
I can add ".name = ubi" and ".devpart = UBI" .
> [...]
> 
> > 
> > > 
> > > > 
> > > > +#ifdef CONFIG_SATA
> > > > +static int init_storage_sata(void)
> > > > +{
> > > > +   return sata_probe(0);
> > > Shouldn't the sata device number be pulled from devpart in
> > > default_locations table ?
> > > 
> > This may need to add the logic for splitting the device number and
> > partition into integer from the string. Let me think how to do it,
> > may
> > be i can leverage existing code.
> strtok(), strtol() or something ?
> 
yes, plan to use that.
> [...]
> 
> > 
> > > 
> > > > 
> > > > +#ifdef CONFIG_SPL
> > > > +   spl_mmc_find_device(&mmc, spl_boot_device());
> > > > +#else
> > > > +   debug("#define CONFIG_SPL is required or overrriding
> > > > %s\n",
> > > > +     __func__);
> > > This can be a compile-time error, maybe ?
> > > 
> > No compile error. When you open the file, "%s\n" is actually same
> > line
> > with debug(". .
> So what ? This missing macro can be detected at runtime, heck this
> code
> can even depend on CONFIG_SPL in Kconfig.
> 
Oh...I got you, i thought you means syntax error. So, i would remove it
and adding the depend on CONFIG_SPL in Kconfig.
> > 
> > > 
> > > > 
> > > > 
> > > > +   return -ENOENT;
> > > > +#endif
> > > > +
> > > > +   err = mmc_init(mmc);
> > > > +   if (err) {
> > > > +   debug("spl: mmc init failed with error: %d\n",
> > > > err);
> > > > +   return err;
> > > > +   }
> > > > +
> > > > +   return err;
> > > > +}
> > > > +#else
> > > > +__weak int init_mmc(void)
> > > > +{
> > > > +   /* Expect somewhere already initialize MMC */
> > > > +   return 0;
> > > > +}
> > > > +#endif
> > > [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system

2018-02-25 Thread Chee, Tien Fong
On Thu, 2018-02-22 at 10:50 -0500, Tom Rini wrote:
> On Thu, Feb 22, 2018 at 03:28:12PM +0100, Marek Vasut wrote:
> > 
> > On 02/22/2018 09:18 AM, Chee, Tien Fong wrote:
> > > 
> > > On Thu, 2018-02-15 at 15:58 +0100, Marek Vasut wrote:
> > > > 
> > > > On 02/05/2018 08:06 AM, tien.fong.c...@intel.com wrote:
> > > > > 
> > > > > 
> > > > > From: Tien Fong Chee 
> > > > > 
> > > > > This is file system generic loader which can be used to load
> > > > > the file image from the storage into target such as memory.
> > > > > The consumer driver would then use this loader to program
> > > > > whatever,
> > > > > ie. the FPGA device.
> > > > > 
> > > > > Signed-off-by: Tien Fong Chee 
> > > > > Reviewed-by: Lothar Waßmann 
> > > > [...]
> > > > 
> > > > > 
> > > > > 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#ifdef CONFIG_SPL
> > > > Are the ifdefs needed ?
> > > > 
> > > Because spl.h contains some codes have its dependency with SPL.
> > > So, Tom
> > > adviced to make this part of code depend on CONFIG_SPL.
> > > However, only __weak int init_mmc() depend on the codes from
> > > spl.h, so
> > > user can override their own init_mmc() if SPL is not used.
> > You probably dont need those ifdefs around headers.
> In this case, we do.  You can only include  on architectures
> which have SPL support.
> 
> I wouldn't object to a separate patch series that adds a dummy
> asm-generic/spl.h and we go that route, if it also cleans up more of
> the
> code in general.  But I think that's separate from this
> series.  Thanks!
> 
Planning to add the depend on CONFIG_SPL in Kconfig instead of ifdefs .
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system

2018-02-25 Thread Chee, Tien Fong
On Thu, 2018-02-22 at 10:02 +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Mon,  5 Feb 2018 15:06:49 +0800 tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > Reviewed-by: Lothar Waßmann 
> > ---
> >  common/Kconfig |   9 ++
> >  common/Makefile|   1 +
> >  common/fs_loader.c | 320
> > +
> >  doc/README.firmware_loader |  76 +++
> >  include/fs_loader.h|  28 
> >  5 files changed, 434 insertions(+)
> >  create mode 100644 common/fs_loader.c
> >  create mode 100644 doc/README.firmware_loader
> >  create mode 100644 include/fs_loader.h
> > 
> [...]
> > 
> > +#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD)
> > +__weak int init_mmc(void)
> > +{
> > +   /* Just for the case MMC is not yet initialized */
> > +   struct mmc *mmc = NULL;
> > +   int err;
> > +
> > +#ifdef CONFIG_SPL
> > +   spl_mmc_find_device(&mmc, spl_boot_device());
> > +#else
> > +   debug("#define CONFIG_SPL is required or overrriding
> > %s\n",
> > 
> s/overrr/overr/
> 
I would remove it and adding the depend on CONFIG_SPL in Kconfig for
compile-time error checking.
> 
> 
> Lothar Waßmann
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] rockchip: rk3288: Add TPL_LDSCRIPT

2018-02-25 Thread Kever Yang

I prefer to share the TPL script between all Rockchip SoCs,

and put this at arch/arm/mach-rockchip/.

I got one in my local branch, will update it once I clean up everything.


Thanks,
- Kever
On 02/23/2018 03:43 PM, Jagan Teki wrote:
> Due to size limitations in SPL by adding falcon mode,
> rk3288 support TPL. In order to not overlap SPL_TEXT_BASE
> add TPL_TEXT_BASE with u-boot-tpl.lds that intern call
> u-boot-spl.lds with proper TEXT_BASE values.
>
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> ---
> Changes for v2:
> - none
>
>  arch/arm/mach-rockchip/Kconfig   |  7 +++
>  arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++
>  2 files changed, 17 insertions(+)
>  create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 1e5a7bb79b..d9218da64f 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -72,6 +72,13 @@ config ROCKCHIP_RK3288
> and video codec support. Peripherals include Gigabit Ethernet,
> USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs.
>  
> +if ROCKCHIP_RK3288
> +
> +config TPL_LDSCRIPT
> + default "arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds"
> +
> +endif
> +
>  config ROCKCHIP_RK3328
>   bool "Support Rockchip RK3328"
>   select ARM64
> diff --git a/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds 
> b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
> new file mode 100644
> index 00..c7a60929e6
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
> @@ -0,0 +1,10 @@
> +/*
> + * Copyright (C) 2018 Jagan Teki 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#undef CONFIG_SPL_TEXT_BASE
> +#define CONFIG_SPL_TEXT_BASE CONFIG_TPL_TEXT_BASE
> +
> +#include "../../cpu/u-boot-spl.lds"


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


Re: [U-Boot] [PATCH v2 1/2] rockchip: rk3288: Add TPL_LDSCRIPT

2018-02-25 Thread Kever Yang

I prefer to share the TPL script between all Rockchip SoCs,

and put this at arch/arm/mach-rockchip/.

I got one in my local branch, will update it once I clean up everything.


Thanks,
- Kever
On 02/23/2018 03:43 PM, Jagan Teki wrote:
> Due to size limitations in SPL by adding falcon mode,
> rk3288 support TPL. In order to not overlap SPL_TEXT_BASE
> add TPL_TEXT_BASE with u-boot-tpl.lds that intern call
> u-boot-spl.lds with proper TEXT_BASE values.
>
> Signed-off-by: Jagan Teki 
> Acked-by: Philipp Tomsich 
> ---
> Changes for v2:
> - none
>
>  arch/arm/mach-rockchip/Kconfig   |  7 +++
>  arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++
>  2 files changed, 17 insertions(+)
>  create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 1e5a7bb79b..d9218da64f 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -72,6 +72,13 @@ config ROCKCHIP_RK3288
> and video codec support. Peripherals include Gigabit Ethernet,
> USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs.
>  
> +if ROCKCHIP_RK3288
> +
> +config TPL_LDSCRIPT
> + default "arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds"
> +
> +endif
> +
>  config ROCKCHIP_RK3328
>   bool "Support Rockchip RK3328"
>   select ARM64
> diff --git a/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds 
> b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
> new file mode 100644
> index 00..c7a60929e6
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
> @@ -0,0 +1,10 @@
> +/*
> + * Copyright (C) 2018 Jagan Teki 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#undef CONFIG_SPL_TEXT_BASE
> +#define CONFIG_SPL_TEXT_BASE CONFIG_TPL_TEXT_BASE
> +
> +#include "../../cpu/u-boot-spl.lds"


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