[U-Boot] [PATCH v5 0/3] arm: tegra: apalis-tk1 and ext clock loopback

[Marcel Ziswiler]

This series adds support for the Toradex Apalis TK1 and introduces a new
option to disable the external clock loopback on SDMMC3.

The whole series is also available here:

http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v5:
- Re-enabled EFI loader support after discussion with Alexander.
- Added Jaehoon's acked-by.

Changes in v4:
- Re-based.
- Drop patches 2 and 3:
mmc: tegra: move CONFIG_TEGRA_MMC from headers to defconfigs
mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig
  in favor of commit 1d2c0506d31a9997e5ffc22e90942902f673b107
mmc: move more driver config options to Kconfig
  from Masahiro.
- Meld patch 6
apalis-tk1: clean-up defconfig
  into first one.
- Add distro boot fallback.
- Enable FIT and device tree overlay support.
- Explicitly drop EFI loader support.
- Re-based.

Changes in v3:
- Changes involved now dropped patches.

Changes in v2:
- Added Simon's reviewed-by.
- Added Simon's reviewed-by.
- Added TODO(email) as suggested by Simon so it is clear this is
  temporary and will be moved to device tree controlled approach once
  proper kernel integration made it mainline.

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

 arch/arm/dts/Makefile  |1 +
 arch/arm/dts/tegra124-apalis.dts   | 2203 
 arch/arm/include/asm/arch-tegra/tegra_mmc.h|2 +
 arch/arm/mach-tegra/tegra124/Kconfig   |7 +
 board/toradex/apalis-tk1/Kconfig   |   30 +
 board/toradex/apalis-tk1/MAINTAINERS   |7 +
 board/toradex/apalis-tk1/Makefile  |5 +
 board/toradex/apalis-tk1/apalis-tk1.c  |  175 ++
 board/toradex/apalis-tk1/as3722_init.c |  117 ++
 board/toradex/apalis-tk1/as3722_init.h |   41 +
 .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h  |  287 +++
 configs/apalis-tk1_defconfig   |   47 +
 drivers/mmc/Kconfig|   11 +
 drivers/mmc/tegra_mmc.c|   16 +
 include/configs/apalis-tk1.h   |  176 ++
 15 files changed, 3125 insertions(+)
 create mode 100644 arch/arm/dts/tegra124-apalis.dts
 create mode 100644 board/toradex/apalis-tk1/Kconfig
 create mode 100644 board/toradex/apalis-tk1/MAINTAINERS
 create mode 100644 board/toradex/apalis-tk1/Makefile
 create mode 100644 board/toradex/apalis-tk1/apalis-tk1.c
 create mode 100644 board/toradex/apalis-tk1/as3722_init.c
 create mode 100644 board/toradex/apalis-tk1/as3722_init.h
 create mode 100644 board/toradex/apalis-tk1/pinmux-config-apalis-tk1.h
 create mode 100644 configs/apalis-tk1_defconfig
 create mode 100644 include/configs/apalis-tk1.h

-- 
2.9.3

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

[U-Boot] [PATCH v5 2/3] mmc: tegra: allow disabling external clock loopback

[Marcel Ziswiler]

From: Marcel Ziswiler 

Introduce CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK to disable the external clock
loopback and use the internal one on SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0
register's SDMMC_SPARE1 bits being set to 0xfffd according to the TRM.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Simon Glass 
Acked-by: Jaehoon Chung 

Signed-off-by: Marcel Ziswiler 
---

Changes in v5:
- Added Jaehoon's acked-by.

Changes in v4:
- Re-based.

Changes in v3: None
Changes in v2:
- Added Simon's reviewed-by.
- Added TODO(email) as suggested by Simon so it is clear this is
  temporary and will be moved to device tree controlled approach once
  proper kernel integration made it mainline.

 arch/arm/include/asm/arch-tegra/tegra_mmc.h |  2 ++
 drivers/mmc/Kconfig | 11 +++
 drivers/mmc/tegra_mmc.c | 16 
 3 files changed, 29 insertions(+)

diff --git a/arch/arm/include/asm/arch-tegra/tegra_mmc.h 
b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
index 64c848a..c40599a 100644
--- a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
+++ b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
@@ -108,6 +108,8 @@ struct tegra_mmc {
 #define TEGRA_MMC_CLKCON_SDCLK_FREQ_SEL_SHIFT  8
 #define TEGRA_MMC_CLKCON_SDCLK_FREQ_SEL_MASK   (0xff << 8)
 
+#define TEGRA_MMC_MISCON_ENABLE_EXT_LOOPBACK   (1 << 17)
+
 #define TEGRA_MMC_SWRST_SW_RESET_FOR_ALL   (1 << 0)
 #define TEGRA_MMC_SWRST_SW_RESET_FOR_CMD_LINE  (1 << 1)
 #define TEGRA_MMC_SWRST_SW_RESET_FOR_DAT_LINE  (1 << 2)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 05e0b10..560391f 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -367,6 +367,17 @@ config MMC_SUNXI
 
 endif
 
+config TEGRA124_MMC_DISABLE_EXT_LOOPBACK
+   bool "Disable external clock loopback"
+   depends on MMC_SDHCI_TEGRA && TEGRA124
+   help
+ Disable the external clock loopback and use the internal one on SDMMC3
+ as per the SDMMC_VENDOR_MISC_CNTRL_0 register's SDMMC_SPARE1 bits
+ being set to 0xfffd according to the TRM.
+
+ TODO(marcel.ziswi...@toradex.com): Move to device tree controlled
+ approach once proper kernel integration made it mainline.
+
 endmenu
 
 config SYS_FSL_ERRATUM_ESDHC111
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
index 0df74ef..6c6affb 100644
--- a/drivers/mmc/tegra_mmc.c
+++ b/drivers/mmc/tegra_mmc.c
@@ -513,6 +513,22 @@ static int tegra_mmc_init(struct mmc *mmc)
 
tegra_mmc_reset(priv, mmc);
 
+#if defined(CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK)
+   /*
+* Disable the external clock loopback and use the internal one on
+* SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0 register's SDMMC_SPARE1
+* bits being set to 0xfffd according to the TRM.
+*
+* TODO(marcel.ziswi...@toradex.com): Move to device tree controlled
+* approach once proper kernel integration made it mainline.
+*/
+   if (priv->reg == (void *)0x700b0400) {
+   mask = readl(>reg->venmiscctl);
+   mask &= ~TEGRA_MMC_MISCON_ENABLE_EXT_LOOPBACK;
+   writel(mask, >reg->venmiscctl);
+   }
+#endif
+
priv->version = readw(>reg->hcver);
debug("host version = %x\n", priv->version);
 
-- 
2.9.3

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

[U-Boot] [PATCH v5 3/3] apalis-tk1: disable external clock loopback on SDMMC3

[Marcel Ziswiler]

From: Marcel Ziswiler 

Actually make use of that shiny new CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK.

Signed-off-by: Marcel Ziswiler 
Signed-off-by: Marcel Ziswiler 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 configs/apalis-tk1_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/apalis-tk1_defconfig b/configs/apalis-tk1_defconfig
index 7264aee..10862e5 100644
--- a/configs/apalis-tk1_defconfig
+++ b/configs/apalis-tk1_defconfig
@@ -28,6 +28,7 @@ CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK=y
 CONFIG_E1000=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
-- 
2.9.3

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

Re: [U-Boot] [PATCH v4 0/3] arm: tegra: apalis-tk1 and ext clock loopback

[Marcel Ziswiler]

On Fri, 2017-03-24 at 23:40 +0100, Alexander Graf wrote:
> 
> On 24/03/2017 23:22, Marcel Ziswiler wrote:
> > Hi Alexander
> > 
> > On Tue, 2017-03-21 at 14:50 +0100, Alexander Graf wrote:
> > > 
> > > On 21/03/2017 14:37, Marcel Ziswiler wrote:
> > > > Hi Alex
> > > > 
> > > > On Tue, 2017-03-21 at 10:46 +0100, Alexander Graf wrote:
> > > > > 
> > > > > On 21/03/2017 10:29, Marcel Ziswiler wrote:
> > > > > > This series adds support for the Toradex Apalis TK1 and
> > > > > > introduces
> > > > > > a new
> > > > > > option to disable the external clock loopback on SDMMC3.
> > > > > > 
> > > > > > The whole series is also available here:
> > > > > > 
> > > > > > http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-n
> > > > > > ext
> > > > > > 
> > > > > > Changes in v4:
> > > > > > - Re-based.
> > > > > > - Drop patches 2 and 3:
> > > > > > mmc: tegra: move CONFIG_TEGRA_MMC from headers to
> > > > > > defconfigs
> > > > > > mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig
> > > > > >   in favor of commit
> > > > > > 1d2c0506d31a9997e5ffc22e90942902f673b107
> > > > > > mmc: move more driver config options to Kconfig
> > > > > >   from Masahiro.
> > > > > > - Meld patch 6
> > > > > > apalis-tk1: clean-up defconfig
> > > > > >   into first one.
> > > > > > - Add distro boot fallback.
> > > > > > - Enable FIT and device tree overlay support.
> > > > > > - Explicitly drop EFI loader support.
> > > > > 
> > > > > Any particular reason for this?
> > > > 
> > > > Yes, a waste of 20K which on some of our modules is rather
> > > > crucial.
> > > > I
> > > > personally think force enabling EFI for everything was not too
> > > > smart an
> > > > idea but whatever.
> > > 
> > > Well, it's enabled by default for a good reason: Compatibility.
> > 
> > While I do agree about compatibility I don't quite see what this
> > has to
> > do with EFI. I personally don't believe the BIOS/EFI disaster of
> > the
> > x86 world is worth copying to ARM, sorry. Other distributions like
> > Fedora e.g. achieve the same with distro boot isn't it? After all
> > isn't
> 
> Fedora uses extlinux for 32bit ARM and UEFI for 64bit ARM. The main 
> reason they're using extlinux is that at the point in time when they 
> standardized on it as their preferred booting method, the UEFI 
> implementation didn't exist yet.

It probably also will never work across all 32-bit ARM variants
available out there.

> > the device tree the agreed upon hardware description in the ARM
> > world?
> 
> Yes, device tree is very much agree upon as hardware description!
> And 
> with UEFI nothing changes in that regard. We still use device tree
> by 
> default and unless you're really into shooting yourself into your
> own 
> feet I don't see why you'd want to do it any differently.
> 
> This is not an ACPI vs DT discussion. It's really just about the 
> question which entity controls selection and handover into the
> kernel.
> 
> With UEFI it's much easier to implement snapshot booting for
> example, 
> because you can move all of that logic into a platform agnostic piece
> of 
> code. It's the only supported way to have KASLR work on arm64. It
> allows 
> for boot selection logic (A/B fallback for example) in something
> outside 
> of a boot script or your boot loader sources, so that code stays
> reusable.

Another area which probably will never generically work across all
hardware just because there are simply too many hardware variants out
there in the 32-bit ARM world.

> Take a look at my video at ELC for some rationale behind it:
> 
>    https://www.youtube.com/watch?v=qJAkJ3nmWgM

Yes, I have seen that one before and we were shaking our heads. But
maybe it really is the way to go just like systemd is now ruling the
world (;-p).

> > > I want to move to a world where people can just take a random
> > > distribution and expect it to work, rather than waste weeks over
> > > weeks on fiddling around with random BSPs that nobody really
> > > wants
> > > only to realize 2 years down the road that their security
> > > footprint
> > > is en par with a swiss cheese.
> > 
> > Hey, nothing against Swiss cheese! And BTW the term Swiss cheese is
> > about as nonsense as the term Linux. There is really a huge
> > collection
> > of different Swiss cheeses... Sorry, I just do get upset at times
> > if
> > certain countries gastronomy people do ask whether I want my
> > sandwich
> > with Swiss cheese wondering what they mean by that. But I guess
> > those
> > chaps now do have their very own issues (;-p).
> 
> :)
> 
> > 
> > > It's also the preferred option to boot BSD for example.
> > > 
> > > So how bad are the 20k for you? In fact, I'm surprised it's 20k
> > > at
> > > all -
> > > it used to be 10k. The overhead of DM should be much higher and I
> > > doubt
> > > you want to disable that ;). Usually a full U-Boot build is
> > > ~500k,
> > > so
> > > even at 20k we're talking about 4% - less than a compiler update
> > > usually
> > > gets you.
> > > 

Re: [U-Boot] [PATCH v4 0/3] arm: tegra: apalis-tk1 and ext clock loopback

[Alexander Graf]

On 24/03/2017 23:22, Marcel Ziswiler wrote:

Hi Alexander

On Tue, 2017-03-21 at 14:50 +0100, Alexander Graf wrote:


On 21/03/2017 14:37, Marcel Ziswiler wrote:

Hi Alex

On Tue, 2017-03-21 at 10:46 +0100, Alexander Graf wrote:


On 21/03/2017 10:29, Marcel Ziswiler wrote:

This series adds support for the Toradex Apalis TK1 and
introduces
a new
option to disable the external clock loopback on SDMMC3.

The whole series is also available here:

http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v4:
- Re-based.
- Drop patches 2 and 3:
mmc: tegra: move CONFIG_TEGRA_MMC from headers to
defconfigs
mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig
  in favor of commit 1d2c0506d31a9997e5ffc22e90942902f673b107
mmc: move more driver config options to Kconfig
  from Masahiro.
- Meld patch 6
apalis-tk1: clean-up defconfig
  into first one.
- Add distro boot fallback.
- Enable FIT and device tree overlay support.
- Explicitly drop EFI loader support.


Any particular reason for this?


Yes, a waste of 20K which on some of our modules is rather crucial.
I
personally think force enabling EFI for everything was not too
smart an
idea but whatever.


Well, it's enabled by default for a good reason: Compatibility.


While I do agree about compatibility I don't quite see what this has to
do with EFI. I personally don't believe the BIOS/EFI disaster of the
x86 world is worth copying to ARM, sorry. Other distributions like
Fedora e.g. achieve the same with distro boot isn't it? After all isn't


Fedora uses extlinux for 32bit ARM and UEFI for 64bit ARM. The main 
reason they're using extlinux is that at the point in time when they 
standardized on it as their preferred booting method, the UEFI 
implementation didn't exist yet.



the device tree the agreed upon hardware description in the ARM world?


Yes, device tree is very much agree upon as hardware description! And 
with UEFI nothing changes in that regard. We still use device tree by 
default and unless you're really into shooting yourself into your own 
feet I don't see why you'd want to do it any differently.


This is not an ACPI vs DT discussion. It's really just about the 
question which entity controls selection and handover into the kernel.


With UEFI it's much easier to implement snapshot booting for example, 
because you can move all of that logic into a platform agnostic piece of 
code. It's the only supported way to have KASLR work on arm64. It allows 
for boot selection logic (A/B fallback for example) in something outside 
of a boot script or your boot loader sources, so that code stays reusable.


Take a look at my video at ELC for some rationale behind it:

  https://www.youtube.com/watch?v=qJAkJ3nmWgM


I want to move to a world where people can just take a random
distribution and expect it to work, rather than waste weeks over
weeks on fiddling around with random BSPs that nobody really wants
only to realize 2 years down the road that their security footprint
is en par with a swiss cheese.


Hey, nothing against Swiss cheese! And BTW the term Swiss cheese is
about as nonsense as the term Linux. There is really a huge collection
of different Swiss cheeses... Sorry, I just do get upset at times if
certain countries gastronomy people do ask whether I want my sandwich
with Swiss cheese wondering what they mean by that. But I guess those
chaps now do have their very own issues (;-p).


:)




It's also the preferred option to boot BSD for example.

So how bad are the 20k for you? In fact, I'm surprised it's 20k at
all -
it used to be 10k. The overhead of DM should be much higher and I
doubt
you want to disable that ;). Usually a full U-Boot build is ~500k,
so
even at 20k we're talking about 4% - less than a compiler update
usually
gets you.

If size really is such a big concern, moving to THUMB code is going
to
buy you much more in storage savings than dropping (quite useful)
UEFI
support.

If however there are real technical issues with it, I'm happy to
hear
them and fix them as far as possible.


The technical issue is that I still don't quite see why U-Boot needs
EFI. I stopped using SuSE more than 15 years ago and never regretted


For 32bit ARM it doesn't really "need" it. If you feel terribly strongly 
about it, I don't have hard feelings with leaving it out. But if it's 
really just a matter of taste rather than technical merit, I'd rather 
prefer to have the option available for users. The same reason you 
usually want to have distro boot support enabled and not just a 
hardcoded bootcmd line.



it, no pun intended.

But if it is really agreed upon mandatory to enable it I am happy to do
so as I would love to finally get that thing in after an almost 4
months endeavour.


I'm not nacking this patch set, even with EFI_LOADER disabled. But I 
think that if there's no good reason to disable the feature, we should 
leave it enabled.


And if you really are size constrained with today's configuration, 
please 

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

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
---
 lib/fdtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

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

Re: [U-Boot] [PATCH v4 0/3] arm: tegra: apalis-tk1 and ext clock loopback

[Marcel Ziswiler]

Hi Alexander

On Tue, 2017-03-21 at 14:50 +0100, Alexander Graf wrote:
> 
> On 21/03/2017 14:37, Marcel Ziswiler wrote:
> > Hi Alex
> > 
> > On Tue, 2017-03-21 at 10:46 +0100, Alexander Graf wrote:
> > > 
> > > On 21/03/2017 10:29, Marcel Ziswiler wrote:
> > > > This series adds support for the Toradex Apalis TK1 and
> > > > introduces
> > > > a new
> > > > option to disable the external clock loopback on SDMMC3.
> > > > 
> > > > The whole series is also available here:
> > > > 
> > > > http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next
> > > > 
> > > > Changes in v4:
> > > > - Re-based.
> > > > - Drop patches 2 and 3:
> > > > mmc: tegra: move CONFIG_TEGRA_MMC from headers to
> > > > defconfigs
> > > > mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig
> > > >   in favor of commit 1d2c0506d31a9997e5ffc22e90942902f673b107
> > > > mmc: move more driver config options to Kconfig
> > > >   from Masahiro.
> > > > - Meld patch 6
> > > > apalis-tk1: clean-up defconfig
> > > >   into first one.
> > > > - Add distro boot fallback.
> > > > - Enable FIT and device tree overlay support.
> > > > - Explicitly drop EFI loader support.
> > > 
> > > Any particular reason for this?
> > 
> > Yes, a waste of 20K which on some of our modules is rather crucial.
> > I
> > personally think force enabling EFI for everything was not too
> > smart an
> > idea but whatever.
> 
> Well, it's enabled by default for a good reason: Compatibility.

While I do agree about compatibility I don't quite see what this has to
do with EFI. I personally don't believe the BIOS/EFI disaster of the
x86 world is worth copying to ARM, sorry. Other distributions like
Fedora e.g. achieve the same with distro boot isn't it? After all isn't
the device tree the agreed upon hardware description in the ARM world?

> I want to move to a world where people can just take a random
> distribution and expect it to work, rather than waste weeks over
> weeks on fiddling around with random BSPs that nobody really wants
> only to realize 2 years down the road that their security footprint
> is en par with a swiss cheese.

Hey, nothing against Swiss cheese! And BTW the term Swiss cheese is
about as nonsense as the term Linux. There is really a huge collection
of different Swiss cheeses... Sorry, I just do get upset at times if
certain countries gastronomy people do ask whether I want my sandwich
with Swiss cheese wondering what they mean by that. But I guess those
chaps now do have their very own issues (;-p).

> It's also the preferred option to boot BSD for example.
> 
> So how bad are the 20k for you? In fact, I'm surprised it's 20k at
> all - 
> it used to be 10k. The overhead of DM should be much higher and I
> doubt 
> you want to disable that ;). Usually a full U-Boot build is ~500k,
> so 
> even at 20k we're talking about 4% - less than a compiler update
> usually 
> gets you.
> 
> If size really is such a big concern, moving to THUMB code is going
> to 
> buy you much more in storage savings than dropping (quite useful)
> UEFI 
> support.
> 
> If however there are real technical issues with it, I'm happy to
> hear 
> them and fix them as far as possible.

The technical issue is that I still don't quite see why U-Boot needs
EFI. I stopped using SuSE more than 15 years ago and never regretted
it, no pun intended.

But if it is really agreed upon mandatory to enable it I am happy to do
so as I would love to finally get that thing in after an almost 4
months endeavour.

> Alex

Cheers

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

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

[Vikas Manocha]

This patch replaces SPL_PINCTRL_FULL with SPL_PINCNTRL. It is to avoid removal
of pin control properties in case of SPL_PINCTRL. No impact in case of
SPL_PINCTRL_FULL as it depends on SPL_PINCTRL.

Signed-off-by: Vikas Manocha 
---
 dts/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dts/Kconfig b/dts/Kconfig
index 4b7d8b1..2374e62 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -73,8 +73,8 @@ config OF_LIST
 config OF_SPL_REMOVE_PROPS
string "List of device tree properties to drop for SPL"
depends on SPL_OF_CONTROL
-   default "interrupt-parent" if SPL_PINCTRL_FULL && SPL_CLK
-   default "clocks clock-names interrupt-parent" if SPL_PINCTRL_FULL
+   default "interrupt-parent" if SPL_PINCTRL && SPL_CLK
+   default "clocks clock-names interrupt-parent" if SPL_PINCTRL
default "pinctrl-0 pinctrl-names interrupt-parent" if SPL_CLK
default "pinctrl-0 pinctrl-names clocks clock-names interrupt-parent"
help
-- 
1.9.1

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

Re: [U-Boot] [PATCH] imx: i.mx6q: add the initial support for LogicPD i.MX6Q SOM

[Adam Ford]

On Wed, Mar 22, 2017 at 7:27 PM, Tom Rini  wrote:
> On Wed, Mar 22, 2017 at 05:07:02PM -0500, Adam Ford wrote:
>
>> Logic PD has an i.MX6Q system on module (SOM) with a development kit.
>> This have been verified to boot the i.MX6Q version over either SD
>> on the development kit or NAND built into the SOM.
>>

[snip]

>
>> + "fdt_high=0x\0"   \
>> + "initrd_high=0x\0" \
>
> I'm really really not a fan of disabling these relocations, please use
> bootm_size to tell U-Boot where to make sure everything resides without
> overlap.  Also, distro boot?

If I remove "initrd_high" then the booting with a RAM Disk fails even
when I define bootm_size.  I have looked at several i.MX6 boards, and
it seems like the ones with RAM Disk options have this parameter.

I am sure what distro boot is.  Can you elaborate?
>
> [snip]
>> +# define MTDPARTS_DEFAULT"mtdparts=gpmi-nand:4m(uboot)," \
>> + "1m(env),8m(kernel),1m(dtb),-(fs)"
>
> Are you really sure all of these sizes are what you can live with for a
> long long time?  That kernel size feels small.

I defined the kernel to 8m based on the vast majority of the other
i.MX6 boards, but I can see your point.  I think I will just aim high
and go for 16.  This has plenty of NAND.

>
> Thanks!
>
Thank you for the feedback.

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

[U-Boot] [PATCH] rockchip: clk: rk3399: 24MHz is not a power of 2

[Philipp Tomsich]

The clock driver for the RK3399 mistakenly used (24 * 2^20) where it
should have used (24 * 10^6) in a few calculations.

This commits fixes this.

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3399.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 1ac4ff4..ff3cc37 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -667,7 +667,7 @@ static ulong rk3399_mmc_get_clk(struct rk3399_cru *cru, 
uint clk_id)
 
if ((con & CLK_EMMC_PLL_MASK) >> CLK_EMMC_PLL_SHIFT
== CLK_EMMC_PLL_SEL_24M)
-   return DIV_TO_RATE(24*1024*1024, div);
+   return DIV_TO_RATE(24*1000*1000, div);
else
return DIV_TO_RATE(GPLL_HZ, div);
 }
@@ -685,7 +685,7 @@ static ulong rk3399_mmc_set_clk(struct rk3399_cru *cru,
 
if (src_clk_div > 127) {
/* use 24MHz source for 400KHz clock */
-   src_clk_div = 24*1024*1024 / set_rate;
+   src_clk_div = 24*1000*1000 / set_rate;
rk_clrsetreg(>clksel_con[16],
 CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
 CLK_EMMC_PLL_SEL_24M << CLK_EMMC_PLL_SHIFT 
|
-- 
1.9.1

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

Re: [U-Boot] [U-Boot,v2] Add support for Microchip LAN78xx

[Yuiko.Oshino]

From: Yuiko Oshino 
>-Original Message-
>From: Tom Rini [mailto:tr...@konsulko.com]
>Sent: Thursday, March 16, 2017 5:12 PM
>To: Yuiko Oshino - C18177
>Cc: u-boot@lists.denx.de; ma...@denx.de
>Subject: Re: [U-Boot,v2] Add support for Microchip LAN78xx
>
>On Fri, Mar 10, 2017 at 06:38:10PM +, yuiko.osh...@microchip.com
>wrote:
>
>> From: Yuiko Oshino 
>>
>> Add support for Microchip LAN7800 and 7850, USB to 10/100/1000 Ethernet
>Controllers
>>
>> Signed-off-by: Yuiko Oshino 
>> Cc: Marek Vasut 
>> ---
>> Changes for v2:
>>- lan78xx.c header comment cleanup
>>
>>  drivers/usb/eth/Makefile |1 +
>>  drivers/usb/eth/lan78xx.c| 1319
>++
>>  drivers/usb/eth/usb_ether.c  |7 +
>>  include/usb_ether.h  |6 +
>>  scripts/config_whitelist.txt |1 +
>
>NAK.  You don't add to the whitelist, you start adding to Kconfig.
>Thanks!
>
>--
>Tom

Hi Tom,
There is no Kconfig in the drivers/usb/eth. Should I add a new Kconfig file in 
there?
Please advise.
Thank you in advance.

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

Re: [U-Boot] [PATCH v2] Add support for Microchip LAN78xx

[Marek Vasut]

On 03/24/2017 07:25 PM, yuiko.osh...@microchip.com wrote:
> From: Yuiko Oshino 
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Friday, March 10, 2017 2:19 PM
>> To: Yuiko Oshino - C18177; u-boot@lists.denx.de
>> Subject: Re: [PATCH v2] Add support for Microchip LAN78xx
>>
>> On 03/10/2017 07:38 PM, yuiko.osh...@microchip.com wrote:
>>> From: Yuiko Oshino 
>>>
>>> Add support for Microchip LAN7800 and 7850, USB to 10/100/1000
>>> Ethernet Controllers
>>>
>>> Signed-off-by: Yuiko Oshino 
>>> Cc: Marek Vasut 
>>> ---
>>> Changes for v2:
>>>- lan78xx.c header comment cleanup
>>>
> 
> [...]
> 
>>
>> Why does a lot of this stuff look like the SMSC95xx driver ?
>> Do we even need a separate driver or can the SMSC95xx driver be updated to
>> support the LAN78xx ?
>>
> 
> Marek,
> Thank you so much for your review.
> The LAN78xx's register addresses and bit definitions are not compatible to 
> our old part LAN95xx (==SMSC95xx).
> The new devices LAN78xx and LAN75xx device have similarities. I plan to 
> support these two devices in this driver.
> I will take care of all your comments and will submit a new PATCH with a file 
> name change to lan7x.c.
> 

Is the rename really mandatory ?

Then again, I looked into Linux and that one has two separate drivers .
So I wonder if it's really a good idea. Maybe we can share some common
code and have the rest separate ?

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

[U-Boot] [PATCH 5/6] dts: rk3399: add gmac for the rk3399

[Philipp Tomsich]

This change adds the gmac node (i.e. the GMAC Ethernet controller) as
defined in the Linux DTS.

Signed-off-by: Philipp Tomsich 
---

 arch/arm/dts/rk3399.dtsi | 55 
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 456fdb6..754d34a 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -600,6 +600,25 @@
interrupts = ;
};
 
+gmac: eth@fe30 {
+compatible = "rockchip,rk3399-gmac";
+reg = <0x0 0xfe30 0x0 0x1>;
+rockchip,grf = <>;
+interrupts = ;
+interrupt-names = "macirq";
+clocks = < SCLK_MAC>, < SCLK_MAC_RX>,
+ < SCLK_MAC_TX>, < SCLK_MACREF>,
+ < SCLK_MACREF_OUT>, < ACLK_GMAC>,
+ < PCLK_GMAC>;
+clock-names = "stmmaceth", "mac_clk_rx",
+  "mac_clk_tx", "clk_mac_ref",
+  "clk_mac_refout", "aclk_mac",
+  "pclk_mac";
+resets = < SRST_A_GMAC>;
+reset-names = "stmmaceth";
+status = "disabled";
+};
+
spdif: spdif@ff87 {
compatible = "rockchip,rk3399-spdif";
reg = <0x0 0xff87 0x0 0x1000>;
@@ -865,6 +884,42 @@
};
};
 
+   gmac {
+   rgmii_pins: rgmii-pins {
+   rockchip,pins =
+   /* mac_txclk */
+   <3 17 RK_FUNC_1 _pull_none_13ma>,
+   /* mac_rxclk */
+   <3 14 RK_FUNC_1 _pull_none>,
+   /* mac_mdio */
+   <3 13 RK_FUNC_1 _pull_none>,
+   /* mac_txen */
+   <3 12 RK_FUNC_1 _pull_none_13ma>,
+   /* mac_clk */
+   <3 11 RK_FUNC_1 _pull_none>,
+   /* mac_rxdv */
+   <3 9 RK_FUNC_1 _pull_none>,
+   /* mac_mdc */
+   <3 8 RK_FUNC_1 _pull_none>,
+   /* mac_rxd1 */
+   <3 7 RK_FUNC_1 _pull_none>,
+   /* mac_rxd0 */
+   <3 6 RK_FUNC_1 _pull_none>,
+   /* mac_txd1 */
+   <3 5 RK_FUNC_1 _pull_none_13ma>,
+   /* mac_txd0 */
+   <3 4 RK_FUNC_1 _pull_none_13ma>,
+   /* mac_rxd3 */
+   <3 3 RK_FUNC_1 _pull_none>,
+   /* mac_rxd2 */
+   <3 2 RK_FUNC_1 _pull_none>,
+   /* mac_txd3 */
+   <3 1 RK_FUNC_1 _pull_none_13ma>,
+   /* mac_txd2 */
+   <3 0 RK_FUNC_1 _pull_none_13ma>;
+   };
+   };
+
sdmmc {
sdmmc_bus1: sdmmc-bus1 {
rockchip,pins =
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2] Add support for Microchip LAN78xx

[Yuiko.Oshino]

From: Yuiko Oshino 
>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Friday, March 10, 2017 2:19 PM
>To: Yuiko Oshino - C18177; u-boot@lists.denx.de
>Subject: Re: [PATCH v2] Add support for Microchip LAN78xx
>
>On 03/10/2017 07:38 PM, yuiko.osh...@microchip.com wrote:
>> From: Yuiko Oshino 
>>
>> Add support for Microchip LAN7800 and 7850, USB to 10/100/1000
>> Ethernet Controllers
>>
>> Signed-off-by: Yuiko Oshino 
>> Cc: Marek Vasut 
>> ---
>> Changes for v2:
>>- lan78xx.c header comment cleanup
>>

[...]

>
>Why does a lot of this stuff look like the SMSC95xx driver ?
>Do we even need a separate driver or can the SMSC95xx driver be updated to
>support the LAN78xx ?
>

Marek,
Thank you so much for your review.
The LAN78xx's register addresses and bit definitions are not compatible to our 
old part LAN95xx (==SMSC95xx).
The new devices LAN78xx and LAN75xx device have similarities. I plan to support 
these two devices in this driver.
I will take care of all your comments and will submit a new PATCH with a file 
name change to lan7x.c.

Best Regards,
Yuiko

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

[U-Boot] [PATCH 6/6] dts: rk3399-puma: add gmac for the RK3399-Q7

[Philipp Tomsich]

This change enables the Gigabit Ethernet support on the RK3399-Q7.

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich 
---

 arch/arm/dts/rk3399-puma.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/dts/rk3399-puma.dts b/arch/arm/dts/rk3399-puma.dts
index 31f9c3d..01cb3fa 100644
--- a/arch/arm/dts/rk3399-puma.dts
+++ b/arch/arm/dts/rk3399-puma.dts
@@ -50,6 +50,20 @@
regulator-name = "vcc5v0_host";
gpio = < 25 GPIO_ACTIVE_HIGH>;
};
+
+   clkin_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "clkin_gmac";
+   #clock-cells = <0>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
 };
 
 _phy {
@@ -122,3 +136,19 @@
};
};
 };
+
+ {
+phy-supply = <_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = < 16 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = < SCLK_RMII_SRC>;
+   assigned-clock-parents = <_gmac>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   tx_delay = <0x10>;
+   rx_delay = <0x10>;
+   status = "okay";
+};
-- 
1.9.1

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

[U-Boot] [PATCH 3/6] rockchip: clk: rk3399: add clocking support for Ethernet

[Philipp Tomsich]

The Ethernet driver for the RK3288/3399 GMAC makes sure that the clock
is ungated through a call to clk_set_rate(...). Even though nothing
needs to be done on the RK3399 (the clock gates are open and the clock
is external), we need to implement enough support to at least return
success to enable driver probing.

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3399.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 453c6dd..1ac4ff4 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -802,6 +802,10 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
case SCLK_EMMC:
ret = rk3399_mmc_set_clk(priv->cru, clk->id, rate);
break;
+   case SCLK_MAC:
+   /* nothing to do, as this is an external clock */
+   ret = rate;
+   break;
case SCLK_I2C1:
case SCLK_I2C2:
case SCLK_I2C3:
-- 
1.9.1

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

[U-Boot] [PATCH 4/6] net: gmac_rockchip: Add support for the RK3399 GMAC

[Philipp Tomsich]

The GMAC in the RK3399 is very similar to the RK3288 variant (i.e. it
is a Designware GMAC core and requires similar configuration as the
RK3288 to switch it to RGMII and set up the TX/RX delays for Gigabit).
The key difference is that the register offsets (within the GRF block)
and bit-offsets (within those registers) used to hold the configuration
differ between the various RK32/33 CPUs.

This change refactors the gmac_rockchip.c driver to use a function
table (selected via driver_data) to factor our these differences. Each
function's implementation then matches the underlying processor.

Some collateral changes are needed in the definitions describing the
bits and offsets in the GRF are needed to prefix each set of symbolic
constants with the SoC name to avoid name clashes... and in doing so,
the shifts for masks and constants have been moved into the header
files for readability (and to make it easier to stay below 80 chars).

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 

---

 arch/arm/include/asm/arch-rockchip/grf_rk3288.h |  68 ++--
 arch/arm/include/asm/arch-rockchip/grf_rk3399.h |  47 +++-
 drivers/net/gmac_rockchip.c | 140 +++-
 3 files changed, 193 insertions(+), 62 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3288.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3288.h
index aaffd19..1a7c819 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3288.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3288.h
@@ -720,20 +720,20 @@ enum {
 
 /* GRF_SOC_CON1 */
 enum {
-   RMII_MODE_SHIFT = 0xe,
-   RMII_MODE_MASK = 1,
-   RMII_MODE = 1,
+   RK3288_RMII_MODE_SHIFT = 14,
+   RK3288_RMII_MODE_MASK  = (1 << RK3288_RMII_MODE_SHIFT),
+   RK3288_RMII_MODE   = (1 << RK3288_RMII_MODE_SHIFT),
 
-   GMAC_CLK_SEL_SHIFT  = 0xc,
-   GMAC_CLK_SEL_MASK   = 3,
-   GMAC_CLK_SEL_125M   = 0,
-   GMAC_CLK_SEL_25M= 0x3,
-   GMAC_CLK_SEL_2_5M   = 0x2,
+   RK3288_GMAC_CLK_SEL_SHIFT = 12,
+   RK3288_GMAC_CLK_SEL_MASK  = (3 << RK3288_GMAC_CLK_SEL_SHIFT),
+   RK3288_GMAC_CLK_SEL_125M  = (0 << RK3288_GMAC_CLK_SEL_SHIFT),
+   RK3288_GMAC_CLK_SEL_25M   = (3 << RK3288_GMAC_CLK_SEL_SHIFT),
+   RK3288_GMAC_CLK_SEL_2_5M  = (2 << RK3288_GMAC_CLK_SEL_SHIFT),
 
-   RMII_CLK_SEL_SHIFT  = 0xb,
-   RMII_CLK_SEL_MASK   = 1,
-   RMII_CLK_SEL_2_5M   = 0,
-   RMII_CLK_SEL_25M,
+   RK3288_RMII_CLK_SEL_SHIFT = 11,
+   RK3288_RMII_CLK_SEL_MASK  = (1 << RK3288_RMII_CLK_SEL_SHIFT),
+   RK3288_RMII_CLK_SEL_2_5M  = (0 << RK3288_RMII_CLK_SEL_SHIFT),
+   RK3288_RMII_CLK_SEL_25M   = (1 << RK3288_RMII_CLK_SEL_SHIFT),
 
GMAC_SPEED_SHIFT= 0xa,
GMAC_SPEED_MASK = 1,
@@ -743,10 +743,10 @@ enum {
GMAC_FLOWCTRL_SHIFT = 0x9,
GMAC_FLOWCTRL_MASK  = 1,
 
-   GMAC_PHY_INTF_SEL_SHIFT = 0x6,
-   GMAC_PHY_INTF_SEL_MASK  = 0x7,
-   GMAC_PHY_INTF_SEL_RGMII = 0x1,
-   GMAC_PHY_INTF_SEL_RMII  = 0x4,
+   RK3288_GMAC_PHY_INTF_SEL_SHIFT = 6,
+   RK3288_GMAC_PHY_INTF_SEL_MASK  = (7 << RK3288_GMAC_PHY_INTF_SEL_SHIFT),
+   RK3288_GMAC_PHY_INTF_SEL_RGMII = (1 << RK3288_GMAC_PHY_INTF_SEL_SHIFT),
+   RK3288_GMAC_PHY_INTF_SEL_RMII  = (4 << RK3288_GMAC_PHY_INTF_SEL_SHIFT),
 
HOST_REMAP_SHIFT= 0x5,
HOST_REMAP_MASK = 1
@@ -801,21 +801,27 @@ enum {
 
 /* GRF_SOC_CON3 */
 enum {
-   RXCLK_DLY_ENA_GMAC_SHIFT= 0xf,
-   RXCLK_DLY_ENA_GMAC_MASK = 1,
-   RXCLK_DLY_ENA_GMAC_DISABLE  = 0,
-   RXCLK_DLY_ENA_GMAC_ENABLE,
-
-   TXCLK_DLY_ENA_GMAC_SHIFT= 0xe,
-   TXCLK_DLY_ENA_GMAC_MASK = 1,
-   TXCLK_DLY_ENA_GMAC_DISABLE  = 0,
-   TXCLK_DLY_ENA_GMAC_ENABLE,
-
-   CLK_RX_DL_CFG_GMAC_SHIFT= 0x7,
-   CLK_RX_DL_CFG_GMAC_MASK = 0x7f,
-
-   CLK_TX_DL_CFG_GMAC_SHIFT= 0x0,
-   CLK_TX_DL_CFG_GMAC_MASK = 0x7f,
+   RK3288_RXCLK_DLY_ENA_GMAC_SHIFT = 0xf,
+   RK3288_RXCLK_DLY_ENA_GMAC_MASK =
+   (1 << RK3288_RXCLK_DLY_ENA_GMAC_SHIFT),
+   RK3288_RXCLK_DLY_ENA_GMAC_DISABLE = 0,
+   RK3288_RXCLK_DLY_ENA_GMAC_ENABLE =
+   (1 << RK3288_RXCLK_DLY_ENA_GMAC_SHIFT),
+
+   RK3288_TXCLK_DLY_ENA_GMAC_SHIFT = 0xe,
+   RK3288_TXCLK_DLY_ENA_GMAC_MASK =
+   (1 << RK3288_TXCLK_DLY_ENA_GMAC_SHIFT),
+   RK3288_TXCLK_DLY_ENA_GMAC_DISABLE = 0,
+   RK3288_TXCLK_DLY_ENA_GMAC_ENABLE =
+   (1 << RK3288_RXCLK_DLY_ENA_GMAC_SHIFT),
+
+   RK3288_CLK_RX_DL_CFG_GMAC_SHIFT = 0x7,
+   RK3288_CLK_RX_DL_CFG_GMAC_MASK =
+   (0x7f << RK3288_CLK_RX_DL_CFG_GMAC_SHIFT),
+
+   RK3288_CLK_TX_DL_CFG_GMAC_SHIFT = 0x0,
+   RK3288_CLK_TX_DL_CFG_GMAC_MASK =
+   (0x7f << 

[U-Boot] [PATCH 2/6] rockchip: clk: rk3399: fix warnings for unused variables in SPL/non-SPL

[Philipp Tomsich]

Due to differences in the code paths for SPL and non-SPL, some static
constant structures remain unused in each build variant. This raises
warnings with recent GCC versions (we currently use GCC-6.3).

The warnings addressed in this commit (by matching #if conditions for
the variable definition with their uses) are:

* for the SPL build:
drivers/clk/rockchip/clk_rk3399.c:53:29: warning: 'cpll_init_cfg' defined 
but not used [-Wunused-const-variable=]
 static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 2, 2);
 ^
drivers/clk/rockchip/clk_rk3399.c:52:29: warning: 'gpll_init_cfg' defined 
but not used [-Wunused-const-variable=]
 static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 2, 2, 1);
 ^
* for the non-SPL build:
drivers/clk/rockchip/clk_rk3399.c:54:29: warning: 'ppll_init_cfg' defined 
but not used [-Wunused-const-variable=]
 static const struct pll_div ppll_init_cfg = PLL_DIVISORS(PPLL_HZ, 2, 2, 1);
 ^

Signed-off-by: Philipp Tomsich 
---

 drivers/clk/rockchip/clk_rk3399.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 922ce7e..453c6dd 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -47,9 +47,12 @@ struct pll_div {
.fbdiv = (u32)((u64)hz * _refdiv * _postdiv1 * _postdiv2 / OSC_HZ),\
.postdiv1 = _postdiv1, .postdiv2 = _postdiv2};
 
+#if defined(CONFIG_SPL_BUILD)
 static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 2, 2, 1);
 static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 2, 2);
+#else
 static const struct pll_div ppll_init_cfg = PLL_DIVISORS(PPLL_HZ, 2, 2, 1);
+#endif
 
 static const struct pll_div apll_l_1600_cfg = PLL_DIVISORS(1600*MHz, 3, 1, 1);
 static const struct pll_div apll_l_600_cfg = PLL_DIVISORS(600*MHz, 1, 2, 1);
@@ -1009,7 +1012,9 @@ static void pmuclk_init(struct rk3399_pmucru *pmucru)
 
 static int rk3399_pmuclk_probe(struct udevice *dev)
 {
+#if CONFIG_IS_ENABLED(OF_PLATDATA) || !defined(CONFIG_SPL_BUILD)
struct rk3399_pmuclk_priv *priv = dev_get_priv(dev);
+#endif
 
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
struct rk3399_pmuclk_plat *plat = dev_get_platdata(dev);
-- 
1.9.1

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

[U-Boot] [PATCH 1/6] rockchip: pinctrl: rk3399: add GMAC (RGMII only) support

[Philipp Tomsich]

To add GMAC (Gigabit Ethernet) support (limited to RGMII only at this
point), we need support for additional pin-configuration.  This commit
adds the pinctrl support for GMAC in RGMII signalling mode:
 * adds a PERIPH_ID_GMAC and the mapping from IRQ number to PERIPH_ID
 * adds the required defines (in the GRF support) for configuring the
   GPIOC pins for RGMII
 * configures the RGMII pins (in GPIOC) when requested via pinctrl

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 37 ++
 arch/arm/include/asm/arch-rockchip/periph.h |  1 +
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 42 +
 3 files changed, 80 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index 4701cfb..8e20533 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -342,23 +342,60 @@ enum {
GRF_UART0BT_SOUT= 1,
 
/* GRF_GPIO3A_IOMUX */
+   GRF_GPIO3A0_SEL_SHIFT   = 0,
+   GRF_GPIO3A0_SEL_MASK= 3 << GRF_GPIO3A0_SEL_SHIFT,
+   GRF_MAC_TXD2= 1,
+   GRF_GPIO3A1_SEL_SHIFT   = 2,
+   GRF_GPIO3A1_SEL_MASK= 3 << GRF_GPIO3A1_SEL_SHIFT,
+   GRF_MAC_TXD3= 1,
+   GRF_GPIO3A2_SEL_SHIFT   = 4,
+   GRF_GPIO3A2_SEL_MASK= 3 << GRF_GPIO3A2_SEL_SHIFT,
+   GRF_MAC_RXD2= 1,
+   GRF_GPIO3A3_SEL_SHIFT   = 6,
+   GRF_GPIO3A3_SEL_MASK= 3 << GRF_GPIO3A3_SEL_SHIFT,
+   GRF_MAC_RXD3= 1,
GRF_GPIO3A4_SEL_SHIFT   = 8,
GRF_GPIO3A4_SEL_MASK= 3 << GRF_GPIO3A4_SEL_SHIFT,
+   GRF_MAC_TXD0= 1,
GRF_SPI0NORCODEC_RXD= 2,
GRF_GPIO3A5_SEL_SHIFT   = 10,
GRF_GPIO3A5_SEL_MASK= 3 << GRF_GPIO3A5_SEL_SHIFT,
+   GRF_MAC_TXD1= 1,
GRF_SPI0NORCODEC_TXD= 2,
GRF_GPIO3A6_SEL_SHIFT   = 12,
GRF_GPIO3A6_SEL_MASK= 3 << GRF_GPIO3A6_SEL_SHIFT,
+   GRF_MAC_RXD0= 1,
GRF_SPI0NORCODEC_CLK= 2,
GRF_GPIO3A7_SEL_SHIFT   = 14,
GRF_GPIO3A7_SEL_MASK= 3 << GRF_GPIO3A7_SEL_SHIFT,
+   GRF_MAC_RXD1= 1,
GRF_SPI0NORCODEC_CSN0   = 2,
 
/* GRF_GPIO3B_IOMUX */
GRF_GPIO3B0_SEL_SHIFT   = 0,
GRF_GPIO3B0_SEL_MASK= 3 << GRF_GPIO3B0_SEL_SHIFT,
+   GRF_MAC_MDC = 1,
GRF_SPI0NORCODEC_CSN1   = 2,
+   GRF_GPIO3B1_SEL_SHIFT   = 2,
+   GRF_GPIO3B1_SEL_MASK= 3 << GRF_GPIO3B1_SEL_SHIFT,
+   GRF_MAC_RXDV= 1,
+   GRF_GPIO3B3_SEL_SHIFT   = 6,
+   GRF_GPIO3B3_SEL_MASK= 3 << GRF_GPIO3B3_SEL_SHIFT,
+   GRF_MAC_CLK = 1,
+   GRF_GPIO3B4_SEL_SHIFT   = 8,
+   GRF_GPIO3B4_SEL_MASK= 3 << GRF_GPIO3B4_SEL_SHIFT,
+   GRF_MAC_TXEN= 1,
+   GRF_GPIO3B5_SEL_SHIFT   = 10,
+   GRF_GPIO3B5_SEL_MASK= 3 << GRF_GPIO3B5_SEL_SHIFT,
+   GRF_MAC_MDIO= 1,
+   GRF_GPIO3B6_SEL_SHIFT   = 12,
+   GRF_GPIO3B6_SEL_MASK= 3 << GRF_GPIO3B6_SEL_SHIFT,
+   GRF_MAC_RXCLK   = 1,
+
+   /* GRF_GPIO3C_IOMUX */
+   GRF_GPIO3C1_SEL_SHIFT   = 2,
+   GRF_GPIO3C1_SEL_MASK= 3 << GRF_GPIO3C1_SEL_SHIFT,
+   GRF_MAC_TXCLK   = 1,
 
/* GRF_GPIO4B_IOMUX */
GRF_GPIO4B0_SEL_SHIFT   = 0,
diff --git a/arch/arm/include/asm/arch-rockchip/periph.h 
b/arch/arm/include/asm/arch-rockchip/periph.h
index fa6069b..239a274 100644
--- a/arch/arm/include/asm/arch-rockchip/periph.h
+++ b/arch/arm/include/asm/arch-rockchip/periph.h
@@ -38,6 +38,7 @@ enum periph_id {
PERIPH_ID_SDMMC1,
PERIPH_ID_SDMMC2,
PERIPH_ID_HDMI,
+   PERIPH_ID_GMAC,
 
PERIPH_ID_COUNT,
 
diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3399.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
index a74793a..507bec4 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
@@ -202,6 +202,39 @@ static void pinctrl_rk3399_sdmmc_config(struct 
rk3399_grf_regs *grf, int mmc_id)
}
 }
 
+#if CONFIG_IS_ENABLED(GMAC_ROCKCHIP)
+static void pinctrl_rk3399_gmac_config(struct rk3399_grf_regs *grf, int mmc_id)
+{
+   rk_clrsetreg(>gpio3a_iomux,
+GRF_GPIO3A0_SEL_MASK | GRF_GPIO3A1_SEL_MASK |
+GRF_GPIO3A2_SEL_MASK | GRF_GPIO3A3_SEL_MASK |
+GRF_GPIO3A4_SEL_MASK | GRF_GPIO3A5_SEL_MASK |
+GRF_GPIO3A6_SEL_MASK | GRF_GPIO3A7_SEL_MASK,
+GRF_MAC_TXD2 << GRF_GPIO3A0_SEL_SHIFT |
+GRF_MAC_TXD3 << GRF_GPIO3A1_SEL_SHIFT |
+GRF_MAC_RXD2 << GRF_GPIO3A2_SEL_SHIFT |
+GRF_MAC_RXD3 << GRF_GPIO3A3_SEL_SHIFT |
+GRF_MAC_TXD0 << GRF_GPIO3A4_SEL_SHIFT |
+

[U-Boot] [PATCH 0/6] rockchip: rk3399: GMAC support for the RK3399 SoC

[Philipp Tomsich]

The RK3399 includes the Designware Gigabit Ethernet controller IP and
requires similar configuration as the RK3288. However, the configuration
register offsets (within GRF) and bit offsets (within the registers)
differ.

This changeset refactors the gmac_rockchip.c driver to handle both
RK3288 and RK3399 devices. It further adds the necessary pinctrl
and clock support for GMAC capability on the RK3399.

Tested with a RK3399-Q7 (on-module KSZ9031 PHY) at 100MBit and 1GBit.


Philipp Tomsich (6):
  rockchip: pinctrl: rk3399: add GMAC (RGMII only) support
  rockchip: clk: rk3399: fix warnings for unused variables in
SPL/non-SPL
  rockchip: clk: rk3399: add clocking support for Ethernet
  net: gmac_rockchip: Add support for the RK3399 GMAC
  dts: rk3399: add gmac for the rk3399
  dts: rk3399-puma: add gmac for the RK3399-Q7

 arch/arm/dts/rk3399-puma.dts|  30 +
 arch/arm/dts/rk3399.dtsi|  55 ++
 arch/arm/include/asm/arch-rockchip/grf_rk3288.h |  68 ++--
 arch/arm/include/asm/arch-rockchip/grf_rk3399.h |  84 +-
 arch/arm/include/asm/arch-rockchip/periph.h |   1 +
 drivers/clk/rockchip/clk_rk3399.c   |   9 ++
 drivers/net/gmac_rockchip.c | 140 +++-
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   |  42 +++
 8 files changed, 367 insertions(+), 62 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH] rockchip: arm64: rk3399: remove unconditional debug message

[Philipp Tomsich]

An earlier upstream change contained an unconditional debug message
which would show up as a message similar to the following in the
U-Boot startup (after the ATF and before the U-Boot banner):
  time 159f019, 0

This commit removes this message (instead of making if conditional on
being a debug-build), as it doesn't pertain to any initialisation done
in this file.

Signed-off-by: Philipp Tomsich 

---

 arch/arm/mach-rockchip/rk3399/rk3399.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index cbfd3fa..8bb950e 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -40,6 +40,5 @@ int arch_cpu_init(void)
/* Emmc clock generator: disable the clock multipilier */
rk_clrreg(GRF_EMMCCORE_CON11, 0x0ff);
 
-   printf("time %x, %x\n", readl(0xff8680a8), readl(0xff8680ac));
return 0;
 }
-- 
1.9.1

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

[U-Boot] [PATCH] ARMv8: add GOT sections to the list of sections copied

[Philipp Tomsich]

Recent Linux distributions (e.g. Debian 9) include cross-compilers for
AArch64, but only for the aarch64-linux-gnu triplet only. It can thus
be expected that users will attempt to use the system cross-compiler
(instead of an aarch64-elf variant) to compile U-Boot for their ARMv8
target systems.

One key differences between an aarch64-linux-gnu and an aarch64-elf
compiler are the default settings regarding position-independent: with
the aarch64-linux-gnu compiler, the default will create and use the
global offset table.

This change-set adjusts the list of sections copied on ARMv8 to include
the GOT sections. With this added, the list matches the previous setup
for AArch32 closely.

Note that this is not an 'academic' issue, but was in fact encountered
by our QA during testing of the RK3399-Q7 BSP and resulted in an
early failure of the SPL stage during FDT setup.

Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 

---

 arch/arm/config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 08d7d1b..907c693 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -120,7 +120,7 @@ endif
 # limit ourselves to the sections we want in the .bin.
 ifdef CONFIG_ARM64
 OBJCOPYFLAGS += -j .text -j .secure_text -j .secure_data -j .rodata -j .data \
-   -j .u_boot_list -j .rela.dyn
+   -j .u_boot_list -j .rela.dyn -j .got -j .got.plt
 else
 OBJCOPYFLAGS += -j .text -j .secure_text -j .secure_data -j .rodata -j .hash \
-j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn
-- 
1.9.1

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

Re: [U-Boot] Please pull ARC changes

[Tom Rini]

On Fri, Mar 24, 2017 at 11:53:43AM +, Alexey Brodkin wrote:

> Hi Tom,
> 
> Please pull changes which introduce ARC built-in timer
> support in U-Boot. This replaces legacy arch/arc/lib/timer.c implementation
> and allows us to describe ARC Timers in Device Tree. Among other things
> that way we may properly inherit Timer's clock from CPU's clock s they
> really run synchronously.
> 
> The following changes since commit d0ffda8ed208ff2957cd09ccc37e2d6dff81523e:
> 
>   Merge git://git.denx.de/u-boot-dm (2017-03-23 12:19:07 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arc.git 
> 
> for you to fetch changes up to 3daa7c7b831ddeed0e490a899710a58691ee20c3:
> 
>   arc: use timer driver for ARC boards (2017-03-24 14:47:52 +0300)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Fri, Mar 24, 2017 at 06:58:18AM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following Marvell patches mainly adding
> support for some new boards, like the ARMv8 community
> boards MACCHIATOBin and ESPRESSBin.
> 
> Thanks,
> Stefan
> 
> The following changes since commit 5877d8f398de26617be6f1f57bc30c49e9f90ebb:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-mmc (2017-03-21 14:10:15 
> -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-marvell.git 
> 
> for you to fetch changes up to 60083261a1b33b492ddb5335c125f1223087068b:
> 
>   arm: mvebu: Add gdsys ControlCenter-Compact board (2017-03-23 15:48:28 
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 4/7] sunxi: Add clock support for DE2/HDMI/TCON on newer SoCs

[Jernej Škrabec]

Dne petek, 24. marec 2017 ob 16:53:07 CET je Maxime Ripard napisal(a):
> On Wed, Mar 22, 2017 at 06:19:12PM +0100, Jernej Škrabec wrote:
> > Hi,
> > 
> > Dne sreda, 22. marec 2017 ob 08:45:48 CET je Maxime Ripard napisal(a):
> > > On Tue, Mar 21, 2017 at 11:26:46PM +0100, Jernej Škrabec wrote:
> > > > Hi,
> > > > 
> > > > Dne torek, 21. marec 2017 ob 20:34:33 CET je Maxime Ripard napisal(a):
> > > > > Hi,
> > > > > 
> > > > > On Mon, Mar 20, 2017 at 11:01:25PM +0100, Jernej Skrabec wrote:
> > > > > > diff --git a/include/configs/sun50i.h b/include/configs/sun50i.h
> > > > > > index 1b7bfb6c22..146f7f4e1b 100644
> > > > > > --- a/include/configs/sun50i.h
> > > > > > +++ b/include/configs/sun50i.h
> > > > > > @@ -21,6 +21,8 @@
> > > > > > 
> > > > > >  #define GICD_BASE  0x1c81000
> > > > > >  #define GICC_BASE  0x1c82000
> > > > > > 
> > > > > > +#define CONFIG_SUNXI_DE2
> > > > > > +
> > > > > > 
> > > > > >  /*
> > > > > >  
> > > > > >   * Include common sunxi configuration where most the settings are
> > > > > >   */
> > > > > > 
> > > > > > diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
> > > > > > index a4c3fb69e4..c42b901107 100644
> > > > > > --- a/include/configs/sun8i.h
> > > > > > +++ b/include/configs/sun8i.h
> > > > > > @@ -25,6 +25,10 @@
> > > > > > 
> > > > > > #define CONFIG_SUNXI_USB_PHYS   2
> > > > > >  
> > > > > >  #endif
> > > > > > 
> > > > > > +#ifdef CONFIG_MACH_SUNXI_H3_H5
> > > > > > +#define CONFIG_SUNXI_DE2
> > > > > > +#endif
> > > > > > +
> > > > > > 
> > > > > >  /*
> > > > > >  
> > > > > >   * Include common sunxi configuration where most the settings are
> > > > > >   */
> > > > > > 
> > > > > > diff --git a/scripts/config_whitelist.txt
> > > > > > b/scripts/config_whitelist.txt
> > > > > > index 8e5dc36fa7..ba0eb12665 100644
> > > > > > --- a/scripts/config_whitelist.txt
> > > > > > +++ b/scripts/config_whitelist.txt
> > > > > > @@ -3102,6 +3102,7 @@ CONFIG_STV0991_HZ_CLOCK
> > > > > > 
> > > > > >  CONFIG_ST_SMI
> > > > > >  CONFIG_SUN4
> > > > > >  CONFIG_SUNXI_AHCI
> > > > > > 
> > > > > > +CONFIG_SUNXI_DE2
> > > > > > 
> > > > > >  CONFIG_SUNXI_EMAC
> > > > > >  CONFIG_SUNXI_GMAC
> > > > > >  CONFIG_SUNXI_GPIO
> > > > > 
> > > > > This should be a Kconfig option.
> > > > 
> > > > So hidden option in board/sunxi/Kconfig will probably be the best
> > > > then?
> > > 
> > > Yes, I guess, but I'm not entirely sure why you need two different
> > > options there?
> > 
> > I used define for CONFIG_SUNXI_DE2 here because SoC has or has not DE2 IP
> > block and that is not a choice. Option in patch 5 is configurable and
> > gives opportunity to build video driver or skip it, whithout influencing
> > clock structure.
> > 
> > I could make only one option, but then it would have to be configurable,
> > which doesn't really make sense from patch 4 perspective, because, as I
> > already stated before, this is property of the SoC.
> > 
> > Which solution do you prefer? One option, define and option (as it is now)
> > or two options?
> > 
> > Frankly, none of them is ideal. Best solution would be to convert clocks
> > to
> > use driver model framework.
> 
> I guess you could make a hidden Kconfig option selected by the
> relevant MACH_ options.
> 
> As a general basis, we move away from the old-style config options, so
> adding any new !Kconfig options isn't really an option.

Ok.

Do you mind if I switch from 16 BPP to 32 BPP in patch 5? efifb linux driver 
doesn't work well with 16 BPP.

Regards,
Jernej

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

Re: [U-Boot] [PATCH 0/8] rockchip: rk3188: fixups and armclk speedup

[Heiko Stuebner]

Am Donnerstag, 23. März 2017, 21:28:01 CET schrieb Simon Glass:
> Hi Heiko,
> 
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
> > The ARMCLK starts at 24MHz on the rk3188 which makes u-boot startup
> > unnecessary slow. We can easily switch to 600MHz without involving
> > the pmic and thus do this in the SPL to also make the rc4-decoding
> > of the U-Boot image faster.
> >
> > Some smaller fixes also turned up while adding the ARMCLK-support.
> >
> > It's currently based on Simon's spl-working branch and Kever's
> > spl_early_init patch, as that includes the last missing rk3188
> > patches and also keeps uboot starting on rk3188.
> 
> This should be in mainline now so can you also please test against that?

yep, all good.

As stated in my fixup series yesterday, this should of course go on
top of the final radxarock addition.


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

Re: [U-Boot] [PATCH v2 4/7] sunxi: Add clock support for DE2/HDMI/TCON on newer SoCs

[Maxime Ripard]

On Wed, Mar 22, 2017 at 06:19:12PM +0100, Jernej Škrabec wrote:
> Hi,
> 
> Dne sreda, 22. marec 2017 ob 08:45:48 CET je Maxime Ripard napisal(a):
> > On Tue, Mar 21, 2017 at 11:26:46PM +0100, Jernej Škrabec wrote:
> > > Hi,
> > > 
> > > Dne torek, 21. marec 2017 ob 20:34:33 CET je Maxime Ripard napisal(a):
> > > > Hi,
> > > > 
> > > > On Mon, Mar 20, 2017 at 11:01:25PM +0100, Jernej Skrabec wrote:
> > > > > diff --git a/include/configs/sun50i.h b/include/configs/sun50i.h
> > > > > index 1b7bfb6c22..146f7f4e1b 100644
> > > > > --- a/include/configs/sun50i.h
> > > > > +++ b/include/configs/sun50i.h
> > > > > @@ -21,6 +21,8 @@
> > > > > 
> > > > >  #define GICD_BASE0x1c81000
> > > > >  #define GICC_BASE0x1c82000
> > > > > 
> > > > > +#define CONFIG_SUNXI_DE2
> > > > > +
> > > > > 
> > > > >  /*
> > > > >  
> > > > >   * Include common sunxi configuration where most the settings are
> > > > >   */
> > > > > 
> > > > > diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
> > > > > index a4c3fb69e4..c42b901107 100644
> > > > > --- a/include/configs/sun8i.h
> > > > > +++ b/include/configs/sun8i.h
> > > > > @@ -25,6 +25,10 @@
> > > > > 
> > > > >   #define CONFIG_SUNXI_USB_PHYS   2
> > > > >  
> > > > >  #endif
> > > > > 
> > > > > +#ifdef CONFIG_MACH_SUNXI_H3_H5
> > > > > +#define CONFIG_SUNXI_DE2
> > > > > +#endif
> > > > > +
> > > > > 
> > > > >  /*
> > > > >  
> > > > >   * Include common sunxi configuration where most the settings are
> > > > >   */
> > > > > 
> > > > > diff --git a/scripts/config_whitelist.txt
> > > > > b/scripts/config_whitelist.txt
> > > > > index 8e5dc36fa7..ba0eb12665 100644
> > > > > --- a/scripts/config_whitelist.txt
> > > > > +++ b/scripts/config_whitelist.txt
> > > > > @@ -3102,6 +3102,7 @@ CONFIG_STV0991_HZ_CLOCK
> > > > > 
> > > > >  CONFIG_ST_SMI
> > > > >  CONFIG_SUN4
> > > > >  CONFIG_SUNXI_AHCI
> > > > > 
> > > > > +CONFIG_SUNXI_DE2
> > > > > 
> > > > >  CONFIG_SUNXI_EMAC
> > > > >  CONFIG_SUNXI_GMAC
> > > > >  CONFIG_SUNXI_GPIO
> > > > 
> > > > This should be a Kconfig option.
> > > 
> > > So hidden option in board/sunxi/Kconfig will probably be the best
> > > then?
> > 
> > Yes, I guess, but I'm not entirely sure why you need two different
> > options there?
> 
> I used define for CONFIG_SUNXI_DE2 here because SoC has or has not DE2 IP 
> block 
> and that is not a choice. Option in patch 5 is configurable and gives 
> opportunity to build video driver or skip it, whithout influencing clock 
> structure.
> 
> I could make only one option, but then it would have to be configurable, 
> which 
> doesn't really make sense from patch 4 perspective, because, as I already 
> stated before, this is property of the SoC.
> 
> Which solution do you prefer? One option, define and option (as it is now) or 
> two options?
> 
> Frankly, none of them is ideal. Best solution would be to convert clocks to 
> use driver model framework.

I guess you could make a hidden Kconfig option selected by the
relevant MACH_ options.

As a general basis, we move away from the old-style config options, so
adding any new !Kconfig options isn't really an option.

Maxime

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


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

[U-Boot] [PATCH 2/2] sunxi: Display: Mark sunxi_rgb2yuv_coef array as const

[Priit Laes]

sunxi_rgb2yuv_coef is readonly and never modified.

Signed-off-by: Priit Laes 
---
 drivers/video/sunxi_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index bcd33dd..a12c4c3 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -457,7 +457,7 @@ static void sunxi_composer_init(void)
setbits_le32(_be->mode, SUNXI_DE_BE_MODE_ENABLE);
 }
 
-static u32 sunxi_rgb2yuv_coef[12] = {
+static const u32 sunxi_rgb2yuv_coef[12] = {
0x0107, 0x0204, 0x0064, 0x0108,
0x3f69, 0x3ed6, 0x01c1, 0x0808,
0x01c1, 0x3e88, 0x3fb8, 0x0808
-- 
2.9.3

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

[U-Boot] [PATCH 1/2] sunxi: Display: Add some comments about unimplemented LVDS features

[Priit Laes]

Following LVDS features might be supported (according to BSP), but are
unimplemented due to lack of proper hardware:
 - dual channel LVDS
 - choosing between NS or JEIDA mode
 - cross-polarity support

Add at least some comments about them.

Signed-off-by: Priit Laes 
---
 drivers/video/sunxi_display.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 6f8ee01..bcd33dd 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -829,8 +829,20 @@ static void sunxi_lcdc_tcon0_mode_set(const struct 
ctfb_res_modes *mode,
 #endif
 #ifdef CONFIG_VIDEO_LCD_IF_LVDS
val = (sunxi_display.depth == 18) ? 1 : 0;
+   /*
+* TODO: LVDS features (from BSP, no hardware):
+* BIT(30) - LVDS single/dual channel (single - 0, dual - 1)
+* BIT(29) - 0
+* BIT(28) - 0
+* BIT(27) - LVDS mode (NS - 0, JEIDA - 1)
+* BIT(23) - 0
+*/
writel(SUNXI_LCDC_TCON0_LVDS_INTF_BITWIDTH(val) |
   SUNXI_LCDC_TCON0_LVDS_CLK_SEL_TCON0, >tcon0_lvds_intf);
+   /*
+* TODO: LVDS cross-polarity support (from BSP, no hardware):
+* set bits (0x1f << 21) | (0x1f << 5) for lvds_ana1 register
+*/
 #endif
 
if (sunxi_display.depth == 18 || sunxi_display.depth == 16) {
-- 
2.9.3

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

Re: [U-Boot] [patch v3] armv8: ls1043a/ls1046aqds: fix the offsets of MTD partitions on Nor flash

[york sun]

On 03/24/2017 03:20 AM, Wenbin song wrote:
> Fix the offsets of MTD partitions on Nor flash on ls1043ardb, ls1043aqds
> and ls1046aqds boards.
> Delete the rcw, uboot env and fman partitions.
> Add user partitions for general usage.
>
> Signed-off-by: Wenbin Song 
> ---
> Changes for v1:
>   Delete the rcw, uboot env and fman partitions.
>   Add user partitions for general usage.
> ---
>  include/configs/ls1043a_common.h | 14 --
>  include/configs/ls1046aqds.h | 14 --
>  2 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/include/configs/ls1043a_common.h 
> b/include/configs/ls1043a_common.h
> index 9a01e48..d5d1388 100644
> --- a/include/configs/ls1043a_common.h
> +++ b/include/configs/ls1043a_common.h
> @@ -188,12 +188,14 @@
>  #define MTDPARTS_DEFAULT "mtdparts=spi0.0:1m(uboot)," \
>   "5m(kernel),1m(dtb),9m(file_system)"
>  #else
> -#define MTDPARTS_DEFAULT "mtdparts=6000.nor:1m(nor_bank0_rcw)," \
> - "1m(nor_bank0_uboot),1m(nor_bank0_uboot_env)," \
> - "1m(nor_bank0_fman_uconde),40m(nor_bank0_fit)," \
> - "1m(nor_bank4_rcw),1m(nor_bank4_uboot)," \
> - "1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode)," \
> - "40m(nor_bank4_fit);7e80.flash:" \
> +#define MTDPARTS_DEFAULT "mtdparts=6000.nor:" \
> + "2m@0x10(nor_bank0_uboot),"\
> + "40m@0x110(nor_bank0_fit)," \
> + "7m(nor_bank0_user)," \
> + "2m@0x410(nor_bank4_uboot)," \
> + "40m@0x510(nor_bank4_fit),"\
> + "-(nor_bank4_user);" \
> + "7e80.flash:" \
>   "1m(nand_uboot),1m(nand_uboot_env)," \
>   "20m(nand_fit);spi0.0:1m(uboot)," \
>   "5m(kernel),1m(dtb),9m(file_system)"
> diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h
> index 4b3b21e..476387d 100644
> --- a/include/configs/ls1046aqds.h
> +++ b/include/configs/ls1046aqds.h
> @@ -485,12 +485,14 @@ unsigned long get_board_ddr_clk(void);
>  #define MTDPARTS_DEFAULT "mtdparts=155.quadspi:2m(uboot)," \
>   "14m(free)"
>  #else
> -#define MTDPARTS_DEFAULT "mtdparts=6000.nor:1m(nor_bank0_rcw)," \
> - "1m(nor_bank0_uboot),1m(nor_bank0_uboot_env)," \
> - "1m(nor_bank0_fman_uconde),40m(nor_bank0_fit)," \
> - "1m(nor_bank4_rcw),1m(nor_bank4_uboot)," \
> - "1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode)," \
> - "40m(nor_bank4_fit);7e80.flash:" \
> +#define MTDPARTS_DEFAULT "mtdparts=6000.nor:" \
> + "2m@0x10(nor_bank0_uboot),"\
> + "40m@0x110(nor_bank0_fit)," \
> + "7m(nor_bank0_user)," \
> + "2m@0x410(nor_bank4_uboot)," \
> + "40m@0x510(nor_bank4_fit),"\
> + "-(nor_bank4_user);" \
> + "7e80.flash:" \
>   "4m(nand_uboot),36m(nand_kernel)," \
>   "472m(nand_free);spi0.0:2m(uboot)," \
>   "14m(free)"
>

Thanks. This looks better.

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

[U-Boot] [LVDS dual channel] TCON0_LVDS_IF_REG seem have undocumented bit 30 ?

[far5893]

I try to read BSP code  for enabling dual channel LVDS (for more than 768 
Vertical lines),in BSP code :



#define LCDC_LVDS_OFF (0x084) /* LVDS registers offset */


LCDC_WUINT32(sel, LCDC_LVDS_OFF,(info->lcd_lvds_ch << 30)
| (0 << 29) | (0 << 28)
| (info->lcd_lvds_mode << 27)
|(info->lcd_lvds_bitwidth << 26) | (0 << 23));


there is a lcd_lvds_ch parameter from fex file that set bit30

but in documentation only bit 31 28 27 26 23  of TCON0_LVDS_IF_REG(0x084) are 
documented,

i'm reading wrong documentation or is really undocumented ?

I'm trying to enable lvds dual channel on A10/A20 SOC.




Thanks

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

Re: [U-Boot] [PATCH v2] ARM: socfpga: add fpga build and bsp handoff instructions to readme

[Marek Vasut]

On 03/24/2017 02:58 AM, Stephen Arnold wrote:
> This patch adds the steps to manually (re)build a Quartus FPGA project,
> generate the required BSP glue, and update u-boot handoff files for
> mainline SPL support. Requires Quartus toolchain and current U-Boot.
> 
> Signed-off-by: Steve Arnold 
> Cc: Dinh Nguyen 
> Cc: Stefan Roese 
> Cc: Marek Vasut 
> ---
> Changes for v2:
>- Addressed comments by marex
>- Added some clarification
>- Made formatting a bit more rst-ish
> 
>  doc/README.socfpga | 141 
> +++--
>  1 file changed, 136 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/README.socfpga b/doc/README.socfpga
> index cb805cfd3a..cae0ef1a21 100644
> --- a/doc/README.socfpga
> +++ b/doc/README.socfpga
> @@ -1,18 +1,149 @@
> -
> -
> +
>  SOCFPGA Documentation for U-Boot and SPL
> -
> +
>  
>  This README is about U-Boot and SPL support for Altera's ARM Cortex-A9MPCore
>  based SOCFPGA. To know more about the hardware itself, please refer to
>  www.altera.com.
>  
>  
> -
>  socfpga_dw_mmc
> -
> +--
> +
>  Here are macro and detailed configuration required to enable DesignWare SDMMC
>  controller support within SOCFPGA
>  
>  #define CONFIG_SYS_MMC_MAX_BLK_COUNT 256
>  -> Using smaller max blk cnt to avoid flooding the limited stack in OCRAM
> +
> +--
> +Generating the handoff header files for U-Boot SPL
> +--
> +
> +This text is assuming quartus 16.1, but newer versions will probably work 
> just fine too;
> +verified with DE1_SOC_Linux_FB demo project 
> (https://github.com/VCTLabs/DE1_SOC_Linux_FB).
> +Updated/working projects should build using either process below.
> +
> +Note: it *should* work from Quartus 14.0.200 onwards, however, the current 
> vendor demo
> +projects must have the IP cores updated as shown below.
> +
> +Rebuilding your Quartus project
> +---
> +
> +Choose one of the follwing methods, either command line or GUI.
> +
> +Using the comaand line
> +~~
> +
> +First run the embedded command shell, using your path to the Quartus install:
> +
> +  $ /path/to/intelFPGA/16.1/embedded/embedded_command_shell.sh
> +
> +Then (if necessary) update the IP cores in the project, generate HDL code, 
> and
> +build the project:
> +
> +  $ cd path/to/project/dir
> +  $ qsys-generate soc_system.qsys --upgrade-ip-cores
> +  $ qsys-generate soc_system.qsys --synthesis=[VERILOG|VHDL]
> +  $ quartus_sh --flow compile 
> +
> +Convert the resulting .sof file (SRAM object file) to .rbf file (Raw bit 
> file):
> +
> +  $ quartus_cpf -c .sof soc_system.rbf
> +
> +
> +Generate BSP handoff files
> +~~
> +
> +You can run the bsp editor GUI below, or run the following command from the
> +project directory:
> +
> +  $ /path/to/bsb/tools/bsp-create-settings --type spl --bsp-dir build \
> +  --preloader-settings-dir hps_isw_handoff/soc_system_hps_0/ \
> +  --settings build/settings.bsp
> +
> +You should use the bsp "build" directory above (ie, where the settings.bsp 
> file is)
> +in the following u-boot command to update the board headers.  Once these 
> headers
> +are updated for a given project build, u-boot should be configured for the
> +project board (eg, de0-nano-sockit) and then build the normal spl build.
   ^^^
   just soc , not sockit .

Fixed and 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] imx: i.mx6q: add the initial support for LogicPD i.MX6Q SOM

[Adam Ford]

On Fri, Mar 24, 2017 at 6:09 AM, Stefano Babic  wrote:
> Hi Adam,
>
> On 22/03/2017 23:07, Adam Ford wrote:
>> Logic PD has an i.MX6Q system on module (SOM) with a development kit.
>> This have been verified to boot the i.MX6Q version over either SD
>> on the development kit or NAND built into the SOM.
>
> A short list of supported peripherals (Ethernet,..) will help. See
> commits of other i.MX6 boards.
>
>>
>> Signed-off-by: Adam Ford 
>>
>> diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
>> index 190e5c6..059d905 100644
>> --- a/arch/arm/cpu/armv7/mx6/Kconfig
>> +++ b/arch/arm/cpu/armv7/mx6/Kconfig
>> @@ -367,6 +367,13 @@ config TARGET_ZC5601
>>   select DM
>>   select DM_THERMAL
>>
>> +config TARGET_MX6LOGICPD
>> + bool "mx6logicpd"
>> + select BOARD_LATE_INIT
>> + select DM
>> + select DM_THERMAL
>> + select BOARD_EARLY_INIT_F
>> +
>>  endchoice
>>
>>  config SYS_SOC
>> @@ -415,5 +422,6 @@ source "board/udoo/Kconfig"
>>  source "board/udoo/neo/Kconfig"
>>  source "board/wandboard/Kconfig"
>>  source "board/warp/Kconfig"
>> +source "board/logicpd/imx6/Kconfig"
>>
>>  endif
>> diff --git a/board/logicpd/imx6/Kconfig b/board/logicpd/imx6/Kconfig
>> new file mode 100644
>> index 000..f5e2f58
>> --- /dev/null
>> +++ b/board/logicpd/imx6/Kconfig
>> @@ -0,0 +1,12 @@
>> +if TARGET_MX6LOGICPD
>> +
>> +config SYS_BOARD
>> +   default "imx6"
>> +
>> +config SYS_VENDOR
>> +   default "logicpd"
>> +
>> +config SYS_CONFIG_NAME
>> +   default "imx6_logic"
>> +
>> +endif
>> diff --git a/board/logicpd/imx6/MAINTAINERS b/board/logicpd/imx6/MAINTAINERS
>> new file mode 100644
>> index 000..5db7d2c
>> --- /dev/null
>> +++ b/board/logicpd/imx6/MAINTAINERS
>> @@ -0,0 +1,6 @@
>> +MX6LOGICPD BOARD
>> +M: Adam Ford 
>> +S: Maintained
>> +F: board/logicpd/imx6/
>> +F: include/configs/imx6_logic.h
>> +F: configs/imx6q_logic_defconfig
>> diff --git a/board/logicpd/imx6/Makefile b/board/logicpd/imx6/Makefile
>> new file mode 100644
>> index 000..397bc5e
>> --- /dev/null
>> +++ b/board/logicpd/imx6/Makefile
>> @@ -0,0 +1,11 @@
>> +#
>> +# Copyright (C) 2007, Guennadi Liakhovetski 
>> +#
>> +# (C) Copyright 2011 Freescale Semiconductor, Inc.
>> +#
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +
>> +obj-y  := imx6logic.o
>> +obj-$(CONFIG_POWER_PFUZE100)   += ../../freescale/common/pfuze.o
>> +
>> diff --git a/board/logicpd/imx6/README b/board/logicpd/imx6/README
>> new file mode 100644
>> index 000..5814b9d
>> --- /dev/null
>> +++ b/board/logicpd/imx6/README
>> @@ -0,0 +1,103 @@
>> +How to use and build U-Boot on mx6sabresd:
>> +--
>> +
>> +Currently there are three methods for booting mx6sabresd boards:
>> +
>
> We already know how to boot sabresd - what about your board ?
>
> I do not see support for SPL.
>
> You should also add explanation how to install U-Boot into the NAND.
>
>> +1. Booting via Normal U-Boot (u-boot.imx)
>> +
>> +2. Booting via SPL (SPL and u-boot.img)
>> +
>> +3. Booting via Falcon mode (SPL launches the kernel directly)
>> +
>> +
>> +1. Booting via Normal U-Boot
>> +
>> +
>> +$ make mx6qsabresd_defconfig (If you want to build for mx6qsabresd)
>> +
>> +or
>> +
>> +$ make mx6dlsabresd_defconfig (If you want to build for mx6dlsabresd)
>> +
>> +$ make
>> +
>> +This will generate the image called u-boot.imx.
>> +
>> +- Flash the u-boot.imx binary into the SD card:
>> +
>> +$ sudo dd if=u-boot.imx of=/dev/sdb bs=1K seek=1 && sync
>> +
>> +
>> +2. Booting via SPL
>> +--
>> +
>> +Other method for building U-Boot on mx6qsabresd and mx6qpsabresd is
>> +through SPL. In order to do so:
>> +
>> +$ make mx6sabresd_spl_defconfig
>> +$ make
>> +
>> +This will generate the SPL image called SPL and the u-boot.img.
>> +
>> +- Flash the SPL image into the SD card:
>> +
>> +$ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 && sync
>> +
>> +- Flash the u-boot.img image into the SD card:
>> +
>> +$ sudo dd if=u-boot.img of=/dev/sdbbs=1K seek=69 && sync
>> +
>> +
>> +3. Booting via Falcon mode
>> +--
>> +
>> +$ make mx6sabresd_spl_defconfig
>> +$ make
>> +
>> +This will generate the SPL image called SPL and the u-boot.img.
>> +
>> +- Flash the SPL image into the SD card:
>> +
>> +$ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 oflag=sync status=none && sync
>> +
>> +- Flash the u-boot.img image into the SD card:
>> +
>> +$ sudo dd if=u-boot.img of=/dev/sdbbs=1K seek=69 oflag=sync status=none && 
>> sync
>> +
>> +Create a partition for root file system and extract it there:
>> +
>> +$ sudo tar xvf rootfs.tar.gz -C /media/root
>> +
>> +The SD card must have enough space for raw "args" and "kernel".
>> +To configure Falcon mode for the first time, on U-Boot do the following 
>> commands:
>> +
>> +- Setup the IP server:
>> +
>> +# setenv serverip 
>> +
>> +- Download dtb 

Re: [U-Boot] [EXT] Re: [PATCH 7/7] scsi: dts: a3700: add scsi node

[Stefan Roese]

Hi Ken,

btw, regarding the max-lun and max-id you could perhaps take
a look at this recent patch, also dealing with these parameters:

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

I've not looked too close into this, just wanted to point it
out to you.

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

Re: [U-Boot] [EXT] Re: [PATCH 7/7] scsi: dts: a3700: add scsi node

[Stefan Roese]

Hi Ken,

On 24.03.2017 05:11, Ken Ma wrote:




b/arch/arm/dts/armada-3720-db.dts index 85761af..9fc60f6 100644



--- a/arch/arm/dts/armada-3720-db.dts



+++ b/arch/arm/dts/armada-3720-db.dts



@@ -89,6 +89,10 @@



status = "okay";



 };







+ {



+   status = "okay";



+};



+



 /* CON3 */



  {



status = "okay";



diff --git a/arch/arm/dts/armada-37xx.dtsi



b/arch/arm/dts/armada-37xx.dtsi index 062f2a6..de5d3a1 100644



--- a/arch/arm/dts/armada-37xx.dtsi



+++ b/arch/arm/dts/armada-37xx.dtsi



@@ -149,11 +149,19 @@



  status = "disabled";



};







-   sata: sata@e {



- compatible = "marvell,armada-3700-ahci";



- reg = <0xe 0x2000>;



- interrupts = ;



+   scsi: scsi {



+ compatible = "marvell,mvebu-scsi";



+ #address-cells = <1>;



+ #size-cells = <1>;



+ max-id = <1>;



+ max-lun = <1>;



  status = "disabled";



+ sata: sata@e {



+   compatible = "marvell,armada-3700-ahci";



+   reg = <0xe 0x2000>;



+   interrupts = ;



+   status = "disabled";



+ };



};







gic: interrupt-controller@1d0 {








I see that you introduce a "scsi" DT node and move the SATA controller
one "level up". I'm not sure if such a change is acceptable as we try to
re-use the DT from Linux. Or thinking more about this, I'm pretty sure
that such a change is not acceptable in general.



Can't you use the existing DT layout and use the
"marvell,armada-3700-ahci" (and other perhaps?) compatible property
instead for driver probing? Not sure how to handle the "max-id" and
"max-lun" properties though. We definitely can't just add some ad-hoc
properties here in U-Boot which have no chance for Linux upstream
acceptance.



[Ken] Because scsi is a bus, for example, if there are 2 scsi buses,
each bus has some scsi device controllers connected as below.


Scsi ID 0 Scsi ID 1 Scsi ID 2 Scsi ID 3



HDD0  HDD1   tape0  cd-rom0

||||||||

===

SCSI BUS1



HDD2  HDD3   tape1  cd-rom2

||||||||

===

SCSI BUS2



As far as I understand, you are looking at this from the external point
of view (SCSI devices connected to the board). But the DT describes
the hardware / interfaces from the CPU / SoC point of view. The
SCSI bus topology can change, depending on which and how the "user"
connects the multiple SCSI devices to the different controllers.
This is definitely not what we can describe in the DT for the
board. Here only the view of the internal controllers / interfaces
is described (UART controller at 0x..., SPI controller at 0x..,
AHCI controller at 0x..., etc).


Then in my opinion, since now scsi has its own class id and its
compatible string, then the scsi device controllers dts node should be
above the scsi node.


As mentioned before, we are not "free" to insert "virtual" controllers
in the DT. Only real hardware interfaces can be described.


If we keep existing DT layout and keep "marvell,armada-3700-ahci"’s
uclass id as UCLASS_AHCI(there are no scsi nodes but only ahci nodes),
then scsi_scan() can not find a3700’s sata at all since there are no
UCLASS_SCSI devices;


I've attached the small patch that I've send you a few weeks ago.
Didn't this work at all? IIRC, then the devices connected to the
SATA ports cuold be detected this way.


If we keep existing DT layout and set scsi devices’ uclass id to be
UCLASS_SCSI, how can we know that hdd0 and hdd1 are in scsi bus1 but
hdd2 and hdd3 are in scsi bus2?  For each scsi bus, its max id should be
4; but now how to set each scsi device’ scsi id?


Not sure if I understand you correctly here. Could you please
describe the problem that you are facing, using an example? That
would be clearer, at least to me.


So I think we should move scsi devices “level up” on the scsio bus.


Might be that I misunderstand you, but I think you are still
viewing this scenario from the external point of view and not
the internal one (as mentioned before). This is not, what the
DT is supposed to describe though.

Thanks,
Stefan
>From 0c071f4815ad76ed9eb64e4261066856062ba115 Mon Sep 17 00:00:00 2001
From: Stefan Roese 
Date: Fri, 13 Jan 2017 12:53:20 +0100
Subject: [PATCH] ahci: Add DM based support for the Marvell MVEBU SATA
 controller

This 

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

[Marek Vasut]

On 03/24/2017 12:08 PM, Alexey Brodkin wrote:
> Hi Marek,
> 
> On Sun, 2017-03-05 at 02:09 +0100, Marek Vasut wrote:
>> On 03/03/2017 02:22 PM, Alexey Brodkin wrote:
>>>
>>> Hi Marek,
>>>
>>> On Fri, 2017-03-03 at 00:57 +0100, Marek Vasut wrote:

 On 03/01/2017 01:52 PM, Alexey Brodkin wrote:
>
>
> Hi Marek,
>
> On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote:
>>
>>
>> On 02/10/2017 09:23 PM, Alexey Brodkin wrote:
>>>
>>>
>>>
>>> Current implementation doesn't allow utilization of platform-specific
>>> reads and writes.
>>>
>>> But some arches or platforms may want to use their accessors that do
>>> some extra work like adding barriers for data serialization etc.
>>>
>>> Interesting enough OHCI accessors already do that so just aligning
>>> EHCI to it now.
>>>
>>> Signed-off-by: Alexey Brodkin 
>>> Cc: Marek Vasut 
>>> Cc: Simon Glass 
>>> Cc: Mateusz Kulikowski 
>>
>> IMO looks OK,
>>
>> Acked-by: Marek Vasut 
>>
>> I'd like to have a few more reviews of this before applying it for
>> 2017.05 . Also CCing Wills, it'd be great to get a test on atheros
>> MIPS .
>
> It's been quite some time since your request to try the patch
> on other systems and so far nobody answered. May we consider that
> one for application then?
>
> Essentially I'm not talking about current Tom's master branch
> but would be good if the patch lands somewhere and once 2017.03
> gets cut is merged in the main branch?

 Yeah, it's not happening for 2017.03, it'll go into the next one.

 Can you just rebase and repost the patch please ? I'll get to it next
 week, I'm traveling until the 10th.
>>>
>>> I just tried and the same .mbox applies cleanly on top of today's
>>> U-Boot master so I believe there's no point in resending it.
>>>
>>> Are you OK to just grab existing one?
>>
>> I no longer have the patch in my mailbox, which is why I asked you to 
>> resend it. Moreover, did you just test that it applies or did you 
>> actually build-test and retest the patch on real hardware too ?
> 
> I did test it on my boards again on top of today's master branch and
> everything seem to work perfectly fine so please consider applying this one.
> 
> You may use mbox from here http://patchwork.ozlabs.org/patch/726714/mbox/
> Al least it worked for me this way:
> ->8---
> curl http://patchwork.ozlabs.org/patch/726714/mbox/ | git am
> ->8---

Thank you for NOT resending the patch and making my life harder. Applied.

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

[U-Boot] [PATCH 5/7] dm: scsi: ahci: fill max_lun and max_id members of scsi_platdata

[Jean-Jacques Hiblot]

Those 2 values are required for proper operation of the DM_SCSI version of
scsi_scan().

Signed-off-by: Jean-Jacques Hiblot 
---
 drivers/block/ahci.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 3fa14a7..3c5359f 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -971,7 +971,9 @@ void scsi_low_level_init(int busdevfunc)
 {
int i;
u32 linkmap;
-
+#ifdef CONFIG_DM_SCSI
+   struct scsi_platdata *plat = dev_get_platdata(dev);
+#endif
 #ifndef CONFIG_SCSI_AHCI_PLAT
 # if defined(CONFIG_DM_PCI)
struct udevice *dev;
@@ -990,6 +992,13 @@ void scsi_low_level_init(int busdevfunc)
 
linkmap = probe_ent->link_port_map;
 
+#ifdef CONFIG_DM_SCSI
+   if (plat) {
+   plat->max_lun = 1;
+   plat->max_id = ffs(linkmap);
+   }
+#endif
+
for (i = 0; i < CONFIG_SYS_SCSI_MAX_SCSI_ID; i++) {
if (((linkmap >> i) & 0x01)) {
if (ahci_port_start((u8) i)) {
@@ -1047,6 +1056,7 @@ err_out:
 
 void __weak scsi_init(void)
 {
+   printf("AHCI\n");
 }
 
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH 0/7] OMAP: Move SATA to use block driver model

[Jean-Jacques Hiblot]

This series adds support for SATA using the driver model on omap platforms.
It is based on the work of Mugunthan V N  in Feb 2016

The first 3 patches are preparatory work.
The 4th patch adds the actual driver.
The 5th and 6th patches are fixes related to the scsi_scan logic when DM is
used.
The last patch enables the DM sata by default for the dra7 platforms.

This series depends on the series "mmc: omap_hsmmc: add support for CONFIG_BLK"
posted a few days ago to add support for CONFIG_BLK in the omap_hsmmc driver.

Tested on DRA72 evm. buildman has been run on am33, dra7, am43, omap5 and am57

Jean-Jacques Hiblot (3):
  dm: scsi: ahci: fill max_lun and max_id members of scsi_platdata
  dm: scsi: fix scan
  defconfig: dra7xx_evm: enable CONFIG_BLK and disk driver model for
SCSI

Mugunthan V N (4):
  arm: omap: sata: move enable sata clocks to enable_basic_clocks()
  arm: omap: sata: compile out sata init apis when CONFIG_DM_SCSI is
defined
  arm: omap-common: sata: prepare driver for DM conversion
  drivers: block: dwc_ahci: Implement a driver for Synopsys DWC sata
device

 arch/arm/mach-omap2/omap5/hw_data.c | 12 ++
 arch/arm/mach-omap2/sata.c  | 38 ++
 common/scsi.c   | 35 +---
 configs/dra7xx_evm_defconfig|  4 ++
 configs/dra7xx_hs_evm_defconfig |  4 ++
 drivers/block/Kconfig   |  9 +
 drivers/block/Makefile  |  1 +
 drivers/block/ahci.c| 12 +-
 drivers/block/dwc_ahci.c| 79 +
 include/sata.h  |  2 +
 10 files changed, 162 insertions(+), 34 deletions(-)
 create mode 100644 drivers/block/dwc_ahci.c

-- 
1.9.1

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

[U-Boot] [PATCH 6/7] dm: scsi: fix scan

[Jean-Jacques Hiblot]

With DM_SCSI enabled, scsi scan suffers 2 problems:
* blk_create_devicef is called with blkz = 0, leading to a divide-by-0
  exception
* new blk devices are created at each scan.

To fix this we start by removing all known SCSI devices at the beginning
of the scan. Then a detection process is started for each possible
device only to get the blksz and lba of the device (no call to part_init() yet).
If a device is found, we can call blk_create_devicef() with the right
parameters and continue the process.

Signed-off-by: Jean-Jacques Hiblot 
---
 common/scsi.c | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/common/scsi.c b/common/scsi.c
index fb5b407..3385cc2 100644
--- a/common/scsi.c
+++ b/common/scsi.c
@@ -480,7 +480,7 @@ static void scsi_init_dev_desc(struct blk_desc *dev_desc, 
int devnum)
  *
  * Return: 0 on success, error value otherwise
  */
-static int scsi_detect_dev(int target, struct blk_desc *dev_desc)
+static int scsi_detect_dev(int target, struct blk_desc *dev_desc, int 
init_part)
 {
unsigned char perq, modi;
lbaint_t capacity;
@@ -539,7 +539,8 @@ static int scsi_detect_dev(int target, struct blk_desc 
*dev_desc)
dev_desc->blksz = blksz;
dev_desc->log2blksz = LOG2(dev_desc->blksz);
dev_desc->type = perq;
-   part_init(_desc[0]);
+   if (init_part)
+   part_init(_desc[0]);
 removable:
return 0;
 }
@@ -565,6 +566,9 @@ int scsi_scan(int mode)
if (ret)
return ret;
 
+   /* remove all SCSI interfaces since we're going to (re)create them */
+   blk_unbind_all(IF_TYPE_SCSI);
+
uclass_foreach_dev(dev, uc) {
struct scsi_platdata *plat; /* scsi controller platdata */
 
@@ -580,9 +584,20 @@ int scsi_scan(int mode)
for (lun = 0; lun < plat->max_lun; lun++) {
struct udevice *bdev; /* block device */
/* block device description */
+   struct blk_desc _bd;
struct blk_desc *bdesc;
char str[10];
 
+   scsi_init_dev_desc_priv(&_bd);
+   _bd.lun = lun;
+   ret = scsi_detect_dev(i, &_bd, 0);
+   if (ret)
+   /*
+* no device detected?
+* check the next lun.
+*/
+   continue;
+
/*
 * Create only one block device and do detection
 * to make sure that there won't be a lot of
@@ -590,17 +605,25 @@ int scsi_scan(int mode)
 */
snprintf(str, sizeof(str), "id%dlun%d", i, lun);
ret = blk_create_devicef(dev, "scsi_blk",
- str, IF_TYPE_SCSI,
- -1, 0, 0, );
+   str, IF_TYPE_SCSI,
+   -1,
+   _bd.blksz,
+   _bd.blksz * _bd.lba,
+   );
if (ret) {
debug("Can't create device\n");
return ret;
}
bdesc = dev_get_uclass_platdata(bdev);
 
+   /*
+* perform the detection once more but this
+* time, let's initialize do the initialization
+* of the partitions
+*/
scsi_init_dev_desc_priv(bdesc);
bdesc->lun = lun;
-   ret = scsi_detect_dev(i, bdesc);
+   ret = scsi_detect_dev(i, bdesc, 1);
if (ret) {
device_unbind(bdev);
continue;
@@ -631,7 +654,7 @@ int scsi_scan(int mode)
for (i = 0; i < CONFIG_SYS_SCSI_MAX_SCSI_ID; i++) {
for (lun = 0; lun < CONFIG_SYS_SCSI_MAX_LUN; lun++) {
scsi_dev_desc[scsi_max_devs].lun = lun;
-   ret = scsi_detect_dev(i, _dev_desc[scsi_max_devs]);
+   ret = scsi_detect_dev(i, _dev_desc[scsi_max_devs], 
1);
if (ret)
continue;
 
-- 
1.9.1

[U-Boot] [PATCH 4/7] drivers: block: dwc_ahci: Implement a driver for Synopsys DWC sata device

[Jean-Jacques Hiblot]

From: Mugunthan V N 

Implement a sata driver for Synopsys DWC sata device based on
U-boot driver model.

Signed-off-by: Mugunthan V N 
Signed-off-by: Jean-Jacques Hiblot 
---
 drivers/block/Kconfig|  9 ++
 drivers/block/Makefile   |  1 +
 drivers/block/dwc_ahci.c | 79 
 3 files changed, 89 insertions(+)
 create mode 100644 drivers/block/dwc_ahci.c

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 88e66e2..0aecb6b 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -48,4 +48,13 @@ config SATA_CEVA
  ZynqMP. Support up to 2 external devices. Complient with SATA 3.1 and
  AHCI 1.3 specifications with hot-plug detect feature.
 
+
+config DWC_AHCI
+   bool "Enable Synopsys DWC AHCI driver support"
+   select SCSI_AHCI
+   depends on DM_SCSI
+   help
+ Enable this driver to support Sata devices through
+ Synopsys DWC AHCI module.
+
 endmenu
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index a72feec..cffe498 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -11,6 +11,7 @@ ifndef CONFIG_BLK
 obj-y += blk_legacy.o
 endif
 
+obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o
 obj-$(CONFIG_AHCI) += ahci-uclass.o
 obj-$(CONFIG_DM_SCSI) += scsi-uclass.o
 obj-$(CONFIG_SCSI_AHCI) += ahci.o
diff --git a/drivers/block/dwc_ahci.c b/drivers/block/dwc_ahci.c
new file mode 100644
index 000..939e57d
--- /dev/null
+++ b/drivers/block/dwc_ahci.c
@@ -0,0 +1,79 @@
+/*
+ * DWC SATA platform driver
+ *
+ * (C) Copyright 2016
+ * Texas Instruments Incorporated, 
+ *
+ * Author: Mugunthan V N 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dwc_ahci_priv {
+   void *base;
+   void *wrapper_base;
+};
+
+static int dwc_ahci_ofdata_to_platdata(struct udevice *dev)
+{
+   struct dwc_ahci_priv *priv = dev_get_priv(dev);
+   fdt_addr_t addr;
+
+   priv->base = map_physmem(dev_get_addr(dev), sizeof(void *),
+MAP_NOCACHE);
+
+   addr = dev_get_addr_index(dev, 1);
+   if (addr != FDT_ADDR_T_NONE) {
+   priv->wrapper_base = map_physmem(addr, sizeof(void *),
+MAP_NOCACHE);
+   } else {
+   priv->wrapper_base = NULL;
+   }
+
+   return 0;
+}
+
+static int dwc_ahci_probe(struct udevice *dev)
+{
+   struct dwc_ahci_priv *priv = dev_get_priv(dev);
+   int ret;
+
+   if (priv->wrapper_base) {
+   u32 val = TI_SATA_IDLE_NO | TI_SATA_STANDBY_NO;
+
+   /* Enable SATA module, No Idle, No Standby */
+   writel(val, priv->wrapper_base + TI_SATA_SYSCONFIG);
+   }
+
+   ret = enable_sata_phy();
+   if (ret) {
+   error("Sata phy enable failed\n");
+   return ret;
+   }
+
+   return ahci_init(priv->base);
+}
+
+static const struct udevice_id dwc_ahci_ids[] = {
+   { .compatible = "snps,dwc-ahci" },
+   { }
+};
+
+U_BOOT_DRIVER(dwc_ahci) = {
+   .name   = "dwc_ahci",
+   .id = UCLASS_SCSI,
+   .of_match = dwc_ahci_ids,
+   .ofdata_to_platdata = dwc_ahci_ofdata_to_platdata,
+   .probe  = dwc_ahci_probe,
+   .priv_auto_alloc_size = sizeof(struct dwc_ahci_priv),
+   .platdata_auto_alloc_size = sizeof(struct scsi_platdata),
+   .flags = DM_FLAG_ALLOC_PRIV_DMA,
+};
-- 
1.9.1

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

[U-Boot] [PATCH 7/7] defconfig: dra7xx_evm: enable CONFIG_BLK and disk driver model for SCSI

[Jean-Jacques Hiblot]

Enable disk driver model for dra7xx_evm as dwc_ahci supports
driver model. As a consequence we must also enable CONFIG_BLK and
CONFIG_DM_USB.

Signed-off-by: Mugunthan V N 
Signed-off-by: Jean-Jacques Hiblot 
---
 configs/dra7xx_evm_defconfig| 4 
 configs/dra7xx_hs_evm_defconfig | 4 
 2 files changed, 8 insertions(+)

diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index 42f87b3..1d45622 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -89,6 +89,7 @@ CONFIG_TI_QSPI=y
 CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
@@ -101,3 +102,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
+CONFIG_BLK=y
+CONFIG_DM_SCSI=y
+CONFIG_DWC_AHCI=y
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index f3a9c68..e31ad28 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -93,6 +93,7 @@ CONFIG_TI_QSPI=y
 CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
@@ -105,3 +106,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
+CONFIG_BLK=y
+CONFIG_DM_SCSI=y
+CONFIG_DWC_AHCI=y
-- 
1.9.1

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

[U-Boot] [PATCH 2/7] arm: omap: sata: compile out sata init apis when CONFIG_DM_SCSI is defined

[Jean-Jacques Hiblot]

From: Mugunthan V N 

Compile out sata init/reset apis as this will be implemented in
scsi-uclass driver to initialize sata devices.

Signed-off-by: Mugunthan V N 
Signed-off-by: Jean-Jacques Hiblot 
---
 arch/arm/mach-omap2/sata.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/sata.c b/arch/arm/mach-omap2/sata.c
index 0c82689..217f1c9 100644
--- a/arch/arm/mach-omap2/sata.c
+++ b/arch/arm/mach-omap2/sata.c
@@ -32,6 +32,7 @@ struct omap_pipe3 sata_phy = {
.dpll_map = dpll_map_sata,
 };
 
+#ifndef CONFIG_DM_SCSI
 int init_sata(int dev)
 {
int ret;
@@ -68,3 +69,4 @@ void scsi_bus_reset(void)
ahci_reset((void __iomem *)DWC_AHSATA_BASE);
ahci_init((void __iomem *)DWC_AHSATA_BASE);
 }
+#endif
-- 
1.9.1

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

[U-Boot] [PATCH 3/7] arm: omap-common: sata: prepare driver for DM conversion

[Jean-Jacques Hiblot]

From: Mugunthan V N 

Prepare sata driver for DM conversion by abstracting sata phy
init to seperate function.

Signed-off-by: Mugunthan V N 
Signed-off-by: Jean-Jacques Hiblot 
---
 arch/arm/mach-omap2/sata.c | 13 +
 include/sata.h |  2 ++
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/sata.c b/arch/arm/mach-omap2/sata.c
index 217f1c9..dce432b 100644
--- a/arch/arm/mach-omap2/sata.c
+++ b/arch/arm/mach-omap2/sata.c
@@ -32,16 +32,21 @@ struct omap_pipe3 sata_phy = {
.dpll_map = dpll_map_sata,
 };
 
+int enable_sata_phy(void)
+{
+   sata_phy.power_reg = (void __iomem *)(*ctrl)->control_phy_power_sata;
+
+   /* Power up the PHY */
+   return phy_pipe3_power_on(_phy);
+}
+
 #ifndef CONFIG_DM_SCSI
 int init_sata(int dev)
 {
int ret;
u32 val;
 
-   sata_phy.power_reg = (void __iomem *)(*ctrl)->control_phy_power_sata;
-
-   /* Power up the PHY */
-   phy_pipe3_power_on(_phy);
+   enable_sata_phy();
 
/* Enable SATA module, No Idle, No Standby */
val = TI_SATA_IDLE_NO | TI_SATA_STANDBY_NO;
diff --git a/include/sata.h b/include/sata.h
index d18cc9a..583b72d 100644
--- a/include/sata.h
+++ b/include/sata.h
@@ -18,4 +18,6 @@ int sata_port_status(int dev, int port);
 extern struct blk_desc sata_dev_desc[];
 #endif
 
+int enable_sata_phy(void);
+
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH 1/7] arm: omap: sata: move enable sata clocks to enable_basic_clocks()

[Jean-Jacques Hiblot]

From: Mugunthan V N 

All the clocks which has to be enabled has to be done in
enable_basic_clocks(), so moving enable sata clock to common
clocks enable function.

Signed-off-by: Mugunthan V N 
Signed-off-by: Jean-Jacques Hiblot 
---
 arch/arm/mach-omap2/omap5/hw_data.c | 12 
 arch/arm/mach-omap2/sata.c  | 23 ---
 2 files changed, 12 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/omap5/hw_data.c 
b/arch/arm/mach-omap2/omap5/hw_data.c
index 5d956b5..a8a6b8a 100644
--- a/arch/arm/mach-omap2/omap5/hw_data.c
+++ b/arch/arm/mach-omap2/omap5/hw_data.c
@@ -361,6 +361,9 @@ void enable_basic_clocks(void)
(*prcm)->cm_l4per_gpio6_clkctrl,
(*prcm)->cm_l4per_gpio7_clkctrl,
(*prcm)->cm_l4per_gpio8_clkctrl,
+#ifdef CONFIG_SCSI_AHCI_PLAT
+   (*prcm)->cm_l3init_ocp2scp3_clkctrl,
+#endif
0
};
 
@@ -379,6 +382,9 @@ void enable_basic_clocks(void)
 #ifdef CONFIG_TI_QSPI
(*prcm)->cm_l4per_qspi_clkctrl,
 #endif
+#ifdef CONFIG_SCSI_AHCI_PLAT
+   (*prcm)->cm_l3init_sata_clkctrl,
+#endif
0
};
 
@@ -411,6 +417,12 @@ void enable_basic_clocks(void)
setbits_le32((*prcm)->cm_l4per_qspi_clkctrl, (1<<24));
 #endif
 
+#ifdef CONFIG_SCSI_AHCI_PLAT
+   /* Enable optional functional clock for SATA */
+   setbits_le32((*prcm)->cm_l3init_sata_clkctrl,
+SATA_CLKCTRL_OPTFCLKEN_MASK);
+#endif
+
/* Enable SCRM OPT clocks for PER and CORE dpll */
setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
OPTFCLKEN_SCRM_PER_MASK);
diff --git a/arch/arm/mach-omap2/sata.c b/arch/arm/mach-omap2/sata.c
index 2c2d1bc..0c82689 100644
--- a/arch/arm/mach-omap2/sata.c
+++ b/arch/arm/mach-omap2/sata.c
@@ -37,29 +37,6 @@ int init_sata(int dev)
int ret;
u32 val;
 
-   u32 const clk_domains_sata[] = {
-   0
-   };
-
-   u32 const clk_modules_hw_auto_sata[] = {
-   (*prcm)->cm_l3init_ocp2scp3_clkctrl,
-   0
-   };
-
-   u32 const clk_modules_explicit_en_sata[] = {
-   (*prcm)->cm_l3init_sata_clkctrl,
-   0
-   };
-
-   do_enable_clocks(clk_domains_sata,
-clk_modules_hw_auto_sata,
-clk_modules_explicit_en_sata,
-0);
-
-   /* Enable optional functional clock for SATA */
-   setbits_le32((*prcm)->cm_l3init_sata_clkctrl,
-SATA_CLKCTRL_OPTFCLKEN_MASK);
-
sata_phy.power_reg = (void __iomem *)(*ctrl)->control_phy_power_sata;
 
/* Power up the PHY */
-- 
1.9.1

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

[U-Boot] [PATCH 0/7] OMAP: Move SATA to use block driver model

[Jean-Jacques Hiblot]

This series adds support for SATA using the driver model on omap platforms.
It is based on the work of Mugunthan V N  in Feb 2016

The first 3 patches are preparatory work.
The 4th patch adds the actual driver.
The 5th and 6th patches are fixes related to the scsi_scan logic when DM is
used.
The last patch enables the DM sata by default for the dra7 platforms.

This series depends on the series "mmc: omap_hsmmc: add support for CONFIG_BLK"
posted a few days ago to add support for CONFIG_BLK in the omap_hsmmc driver.

Tested on DRA72 evm. buildman has been run on am33, dra7, am43, omap5 and am57

Jean-Jacques Hiblot (3):
  dm: scsi: ahci: fill max_lun and max_id members of scsi_platdata
  dm: scsi: fix scan
  defconfig: dra7xx_evm: enable CONFIG_BLK and disk driver model for
SCSI

Mugunthan V N (4):
  arm: omap: sata: move enable sata clocks to enable_basic_clocks()
  arm: omap: sata: compile out sata init apis when CONFIG_DM_SCSI is
defined
  arm: omap-common: sata: prepare driver for DM conversion
  drivers: block: dwc_ahci: Implement a driver for Synopsys DWC sata
device

 arch/arm/mach-omap2/omap5/hw_data.c | 12 ++
 arch/arm/mach-omap2/sata.c  | 38 ++
 common/scsi.c   | 35 +---
 configs/dra7xx_evm_defconfig|  4 ++
 configs/dra7xx_hs_evm_defconfig |  4 ++
 drivers/block/Kconfig   |  9 +
 drivers/block/Makefile  |  1 +
 drivers/block/ahci.c| 12 +-
 drivers/block/dwc_ahci.c| 79 +
 include/sata.h  |  2 +
 10 files changed, 162 insertions(+), 34 deletions(-)
 create mode 100644 drivers/block/dwc_ahci.c

-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 0/3] arc: introduce timer driver and update device tree

[Alexey Brodkin]

Hi Vlad,

On Tue, 2017-03-21 at 14:49 +0300, Vlad Zakharov wrote:
> ARC cores may have up to 2 built-in timers: timer0 and timer1,
> usually at least one of them exists. They both are driven by the
> same core clock.
> 
> They are controlled through auxiliary registers and so we
> don't have to remap their control registers as we used to do
> with MMIO registers of external peripheral devices.
> 
> This patch series replaces legacy approach to access ARC timer
> via specific code in "arch/arc/lib/time.c" and uses timer
> driver instead.
> 
> We want to have common device tree blobs for both Linux and U-Boot.
> To achieve this the patch updates arc device trees with the following:
> 1. Separate axs10x.dts device tree in order to reflect the real
> structure of AXS101 and AXS103 development boards.
> 2. Add timer device to skeleton ARC device tree.
> 3. Add core_clk devices to all ARC boards as it is referenced from
> timer device.
> 
> ---
> Changes v2..v3:
>  - Rebase on top of upstream master
> 
> Vlad Zakharov (3):
>   drivers: timer: Introduce ARC timer driver
>   arc: dts: separate single axs10x.dts file
>   arc: use timer driver for ARC boards

Applied to my tree, thanks!

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

[U-Boot] Please pull ARC changes

[Alexey Brodkin]

Hi Tom,

Please pull changes which introduce ARC built-in timer
support in U-Boot. This replaces legacy arch/arc/lib/timer.c implementation
and allows us to describe ARC Timers in Device Tree. Among other things
that way we may properly inherit Timer's clock from CPU's clock s they
really run synchronously.

The following changes since commit d0ffda8ed208ff2957cd09ccc37e2d6dff81523e:

  Merge git://git.denx.de/u-boot-dm (2017-03-23 12:19:07 -0400)

are available in the git repository at:

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

for you to fetch changes up to 3daa7c7b831ddeed0e490a899710a58691ee20c3:

  arc: use timer driver for ARC boards (2017-03-24 14:47:52 +0300)


Vlad Zakharov (3):
  drivers: timer: Introduce ARC timer driver
  arc: dts: separate single axs10x.dts file
  arc: use timer driver for ARC boards

 arch/Kconfig |   3 +++
 arch/arc/Kconfig |   9 ++---
 arch/arc/dts/Makefile|   3 ++-
 arch/arc/dts/abilis_tb100.dts|  12 +---
 arch/arc/dts/axc001.dtsi |  19 ++
 arch/arc/dts/axc003.dtsi |  19 ++
 arch/arc/dts/axs101.dts  |  17 
 arch/arc/dts/axs103.dts  |  17 
 arch/arc/dts/axs10x.dts  |  57 
-
 arch/arc/dts/axs10x_mb.dtsi  |  66 
+
 arch/arc/dts/nsim.dts|  14 +
 arch/arc/dts/skeleton.dtsi   |  19 +-
 arch/arc/include/asm/arcregs.h   |   4 
 arch/arc/lib/Makefile|   1 -
 arch/arc/lib/timer.c |  24 ---
 board/synopsys/axs10x/Kconfig|   2 +-
 configs/axs101_defconfig |   4 ++--
 configs/axs103_defconfig |   3 +--
 doc/device-tree-bindings/timer/arc_timer.txt |  24 +++
 drivers/timer/Kconfig|   9 +
 drivers/timer/Makefile   |   1 +
 drivers/timer/arc_timer.c| 113
+
 include/configs/axs10x.h |   2 --
 include/configs/nsim.h   |   5 -
 include/configs/tb100.h  |   5 -
 25 files changed, 341 insertions(+), 111 deletions(-)
 create mode 100644 arch/arc/dts/axc001.dtsi
 create mode 100644 arch/arc/dts/axc003.dtsi
 create mode 100644 arch/arc/dts/axs101.dts
 create mode 100644 arch/arc/dts/axs103.dts
 delete mode 100644 arch/arc/dts/axs10x.dts
 create mode 100644 arch/arc/dts/axs10x_mb.dtsi
 delete mode 100644 arch/arc/lib/timer.c
 create mode 100644 doc/device-tree-bindings/timer/arc_timer.txt
 create mode 100644 drivers/timer/arc_timer.c

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

Re: [U-Boot] [PATCH 3/3] arm: mvebu: theadorable: Add 'pcie' test command

[Stefan Roese]

On 10.03.2017 15:40, Stefan Roese wrote:

This board specific command tests for the presence of a specified PCIe
device (via vendor-ID and device-ID). If the device is not detected,
this will get printed. If the device is detected, the board will get
resetted so that an easy loop test can be done. The board will reboot
until the PCIe device is not detected.

Signed-off-by: Stefan Roese 


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH 2/3] arm: mvebu: theadorable: Add board-specific PEX detection pulse width

[Stefan Roese]

On 10.03.2017 15:40, Stefan Roese wrote:

Define a board-specific detection pulse-width array for the SerDes PCIe
interfaces. If not defined in the board code, the default of currently 2
is used. Values from 0...3 are possible (2 bits).

In this case of the theadorable board, PEX interface 0 needs a value
of 0 for the detection pulse width so that the PCIe device (Atheros
WLAN PCIe device) is consistantly detected.

Signed-off-by: Stefan Roese 
Cc: Adam Shobash 
Cc: Nadav Haklai 
Cc: Konstantin Porotchkin 


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH 1/3] arm: mvebu: AXP: Add possiblity to configure PEX detection pulse width

[Stefan Roese]

On 10.03.2017 15:40, Stefan Roese wrote:

Tests have shown that on some boards the default width of the
configuration pulse for the PEX link detection might lead to
non-established PCIe links (link down). Especially under certain
conditions (higher temperature) and with specific PCIe devices
(in the case on the theadorable board its a Atheros PCIe WLAN
device). To enable a board-specific detection pulse width this weak
array "serdes_pex_pulse_width[4]" is introduced which can be
overwritten if needed by a board-specific version. If the board
code does not provide a non-weak version of this variable, the
default value will be used. So nothing is changed from the
current setup on the supported board.

Many thanks to Adam from Marvell for all his insights here and
his suggestion about testing with a changed detection pulse width.

Signed-off-by: Stefan Roese 
Suggested-by: Adam Shobash 
Cc: Adam Shobash 
Cc: Nadav Haklai 
Cc: Konstantin Porotchkin 


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH] imx: i.mx6q: add the initial support for LogicPD i.MX6Q SOM

[Stefano Babic]

Hi Adam,

On 22/03/2017 23:07, Adam Ford wrote:
> Logic PD has an i.MX6Q system on module (SOM) with a development kit.
> This have been verified to boot the i.MX6Q version over either SD
> on the development kit or NAND built into the SOM.

A short list of supported peripherals (Ethernet,..) will help. See
commits of other i.MX6 boards.

> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
> index 190e5c6..059d905 100644
> --- a/arch/arm/cpu/armv7/mx6/Kconfig
> +++ b/arch/arm/cpu/armv7/mx6/Kconfig
> @@ -367,6 +367,13 @@ config TARGET_ZC5601
>   select DM
>   select DM_THERMAL
>  
> +config TARGET_MX6LOGICPD
> + bool "mx6logicpd"
> + select BOARD_LATE_INIT
> + select DM
> + select DM_THERMAL
> + select BOARD_EARLY_INIT_F
> +
>  endchoice
>  
>  config SYS_SOC
> @@ -415,5 +422,6 @@ source "board/udoo/Kconfig"
>  source "board/udoo/neo/Kconfig"
>  source "board/wandboard/Kconfig"
>  source "board/warp/Kconfig"
> +source "board/logicpd/imx6/Kconfig"
>  
>  endif
> diff --git a/board/logicpd/imx6/Kconfig b/board/logicpd/imx6/Kconfig
> new file mode 100644
> index 000..f5e2f58
> --- /dev/null
> +++ b/board/logicpd/imx6/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_MX6LOGICPD
> +
> +config SYS_BOARD
> +   default "imx6"
> +
> +config SYS_VENDOR
> +   default "logicpd"
> +
> +config SYS_CONFIG_NAME
> +   default "imx6_logic"
> +
> +endif
> diff --git a/board/logicpd/imx6/MAINTAINERS b/board/logicpd/imx6/MAINTAINERS
> new file mode 100644
> index 000..5db7d2c
> --- /dev/null
> +++ b/board/logicpd/imx6/MAINTAINERS
> @@ -0,0 +1,6 @@
> +MX6LOGICPD BOARD
> +M: Adam Ford 
> +S: Maintained
> +F: board/logicpd/imx6/
> +F: include/configs/imx6_logic.h
> +F: configs/imx6q_logic_defconfig
> diff --git a/board/logicpd/imx6/Makefile b/board/logicpd/imx6/Makefile
> new file mode 100644
> index 000..397bc5e
> --- /dev/null
> +++ b/board/logicpd/imx6/Makefile
> @@ -0,0 +1,11 @@
> +#
> +# Copyright (C) 2007, Guennadi Liakhovetski 
> +#
> +# (C) Copyright 2011 Freescale Semiconductor, Inc.
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +obj-y  := imx6logic.o
> +obj-$(CONFIG_POWER_PFUZE100)   += ../../freescale/common/pfuze.o
> +
> diff --git a/board/logicpd/imx6/README b/board/logicpd/imx6/README
> new file mode 100644
> index 000..5814b9d
> --- /dev/null
> +++ b/board/logicpd/imx6/README
> @@ -0,0 +1,103 @@
> +How to use and build U-Boot on mx6sabresd:
> +--
> +
> +Currently there are three methods for booting mx6sabresd boards:
> +

We already know how to boot sabresd - what about your board ?

I do not see support for SPL.

You should also add explanation how to install U-Boot into the NAND.

> +1. Booting via Normal U-Boot (u-boot.imx)
> +
> +2. Booting via SPL (SPL and u-boot.img)
> +
> +3. Booting via Falcon mode (SPL launches the kernel directly)
> +
> +
> +1. Booting via Normal U-Boot
> +
> +
> +$ make mx6qsabresd_defconfig (If you want to build for mx6qsabresd)
> +
> +or
> +
> +$ make mx6dlsabresd_defconfig (If you want to build for mx6dlsabresd)
> +
> +$ make
> +
> +This will generate the image called u-boot.imx.
> +
> +- Flash the u-boot.imx binary into the SD card:
> +
> +$ sudo dd if=u-boot.imx of=/dev/sdb bs=1K seek=1 && sync
> +
> +
> +2. Booting via SPL
> +--
> +
> +Other method for building U-Boot on mx6qsabresd and mx6qpsabresd is
> +through SPL. In order to do so:
> +
> +$ make mx6sabresd_spl_defconfig
> +$ make
> +
> +This will generate the SPL image called SPL and the u-boot.img.
> +
> +- Flash the SPL image into the SD card:
> +
> +$ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 && sync
> +
> +- Flash the u-boot.img image into the SD card:
> +
> +$ sudo dd if=u-boot.img of=/dev/sdbbs=1K seek=69 && sync
> +
> +
> +3. Booting via Falcon mode
> +--
> +
> +$ make mx6sabresd_spl_defconfig
> +$ make
> +
> +This will generate the SPL image called SPL and the u-boot.img.
> +
> +- Flash the SPL image into the SD card:
> +
> +$ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 oflag=sync status=none && sync
> +
> +- Flash the u-boot.img image into the SD card:
> +
> +$ sudo dd if=u-boot.img of=/dev/sdbbs=1K seek=69 oflag=sync status=none && 
> sync
> +
> +Create a partition for root file system and extract it there:
> +
> +$ sudo tar xvf rootfs.tar.gz -C /media/root
> +
> +The SD card must have enough space for raw "args" and "kernel".
> +To configure Falcon mode for the first time, on U-Boot do the following 
> commands:
> +
> +- Setup the IP server:
> +
> +# setenv serverip 
> +
> +- Download dtb file:
> +
> +# dhcp ${fdt_addr} imx6q-sabresd.dtb
> +
> +- Download kernel image:
> +
> +# dhcp ${loadaddr} uImage
> +
> +- Write kernel at 2MB offset:
> +
> +# mmc write ${loadaddr} 0x1000 0x4000
> +
> +- Setup kernel bootargs:
> +
> +# setenv 

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

[Alexey Brodkin]

Hi Marek,

On Sun, 2017-03-05 at 02:09 +0100, Marek Vasut wrote:
> On 03/03/2017 02:22 PM, Alexey Brodkin wrote:
> > 
> > Hi Marek,
> > 
> > On Fri, 2017-03-03 at 00:57 +0100, Marek Vasut wrote:
> > > 
> > > On 03/01/2017 01:52 PM, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Marek,
> > > > 
> > > > On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 02/10/2017 09:23 PM, Alexey Brodkin wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Current implementation doesn't allow utilization of 
> > > > > > platform-specific
> > > > > > reads and writes.
> > > > > > 
> > > > > > But some arches or platforms may want to use their accessors that do
> > > > > > some extra work like adding barriers for data serialization etc.
> > > > > > 
> > > > > > Interesting enough OHCI accessors already do that so just aligning
> > > > > > EHCI to it now.
> > > > > > 
> > > > > > Signed-off-by: Alexey Brodkin 
> > > > > > Cc: Marek Vasut 
> > > > > > Cc: Simon Glass 
> > > > > > Cc: Mateusz Kulikowski 
> > > > > 
> > > > > IMO looks OK,
> > > > > 
> > > > > Acked-by: Marek Vasut 
> > > > > 
> > > > > I'd like to have a few more reviews of this before applying it for
> > > > > 2017.05 . Also CCing Wills, it'd be great to get a test on atheros
> > > > > MIPS .
> > > > 
> > > > It's been quite some time since your request to try the patch
> > > > on other systems and so far nobody answered. May we consider that
> > > > one for application then?
> > > > 
> > > > Essentially I'm not talking about current Tom's master branch
> > > > but would be good if the patch lands somewhere and once 2017.03
> > > > gets cut is merged in the main branch?
> > > 
> > > Yeah, it's not happening for 2017.03, it'll go into the next one.
> > > 
> > > Can you just rebase and repost the patch please ? I'll get to it next
> > > week, I'm traveling until the 10th.
> > 
> > I just tried and the same .mbox applies cleanly on top of today's
> > U-Boot master so I believe there's no point in resending it.
> > 
> > Are you OK to just grab existing one?
> 
> I no longer have the patch in my mailbox, which is why I asked you to 
> resend it. Moreover, did you just test that it applies or did you 
> actually build-test and retest the patch on real hardware too ?

I did test it on my boards again on top of today's master branch and
everything seem to work perfectly fine so please consider applying this one.

You may use mbox from here http://patchwork.ozlabs.org/patch/726714/mbox/
Al least it worked for me this way:
->8---
curl http://patchwork.ozlabs.org/patch/726714/mbox/ | git am
->8---

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

[U-Boot] [patch v3] armv8: ls1043a/ls1046aqds: fix the offsets of MTD partitions on Nor flash

[Wenbin song]

Fix the offsets of MTD partitions on Nor flash on ls1043ardb, ls1043aqds
and ls1046aqds boards.
Delete the rcw, uboot env and fman partitions.
Add user partitions for general usage.

Signed-off-by: Wenbin Song 
---
Changes for v1:
Delete the rcw, uboot env and fman partitions.
Add user partitions for general usage.
---
 include/configs/ls1043a_common.h | 14 --
 include/configs/ls1046aqds.h | 14 --
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index 9a01e48..d5d1388 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -188,12 +188,14 @@
 #define MTDPARTS_DEFAULT "mtdparts=spi0.0:1m(uboot)," \
"5m(kernel),1m(dtb),9m(file_system)"
 #else
-#define MTDPARTS_DEFAULT "mtdparts=6000.nor:1m(nor_bank0_rcw)," \
-   "1m(nor_bank0_uboot),1m(nor_bank0_uboot_env)," \
-   "1m(nor_bank0_fman_uconde),40m(nor_bank0_fit)," \
-   "1m(nor_bank4_rcw),1m(nor_bank4_uboot)," \
-   "1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode)," \
-   "40m(nor_bank4_fit);7e80.flash:" \
+#define MTDPARTS_DEFAULT "mtdparts=6000.nor:" \
+   "2m@0x10(nor_bank0_uboot),"\
+   "40m@0x110(nor_bank0_fit)," \
+   "7m(nor_bank0_user)," \
+   "2m@0x410(nor_bank4_uboot)," \
+   "40m@0x510(nor_bank4_fit),"\
+   "-(nor_bank4_user);" \
+   "7e80.flash:" \
"1m(nand_uboot),1m(nand_uboot_env)," \
"20m(nand_fit);spi0.0:1m(uboot)," \
"5m(kernel),1m(dtb),9m(file_system)"
diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h
index 4b3b21e..476387d 100644
--- a/include/configs/ls1046aqds.h
+++ b/include/configs/ls1046aqds.h
@@ -485,12 +485,14 @@ unsigned long get_board_ddr_clk(void);
 #define MTDPARTS_DEFAULT "mtdparts=155.quadspi:2m(uboot)," \
"14m(free)"
 #else
-#define MTDPARTS_DEFAULT "mtdparts=6000.nor:1m(nor_bank0_rcw)," \
-   "1m(nor_bank0_uboot),1m(nor_bank0_uboot_env)," \
-   "1m(nor_bank0_fman_uconde),40m(nor_bank0_fit)," \
-   "1m(nor_bank4_rcw),1m(nor_bank4_uboot)," \
-   "1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode)," \
-   "40m(nor_bank4_fit);7e80.flash:" \
+#define MTDPARTS_DEFAULT "mtdparts=6000.nor:" \
+   "2m@0x10(nor_bank0_uboot),"\
+   "40m@0x110(nor_bank0_fit)," \
+   "7m(nor_bank0_user)," \
+   "2m@0x410(nor_bank4_uboot)," \
+   "40m@0x510(nor_bank4_fit),"\
+   "-(nor_bank4_user);" \
+   "7e80.flash:" \
"4m(nand_uboot),36m(nand_kernel)," \
"472m(nand_free);spi0.0:2m(uboot)," \
"14m(free)"
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 3/3] lib: tpm: Add command to list resources

[Mario Six]

On Wed, Mar 22, 2017 at 2:05 PM, Simon Glass  wrote:
> On 20 March 2017 at 03:28, Mario Six  wrote:
>> It is sometimes convenient to know how many and/or which resources are
>> currently loaded into a TPG, e.g. to test is a flush operation succeeded.
>>
>> Hence, we add a command that lists the resources of a given type currently
>> loaded into the TPM.
>>
>> Signed-off-by: Mario Six 
>> ---
>>  cmd/tpm.c   | 76 
>> -
>>  drivers/tpm/Kconfig |  7 +
>>  2 files changed, 82 insertions(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 
>
> Again I wonder if we need the CONFIG.
>

Thanks for the review!

As for the CONFIG option, well, there is the trivial symmetry reason that the
flush command is deactivatable, so this should be too (since they are,
essentially, complementary functions, one view, one deletion).

Also, the list function is really more of a debug tool than a function that
should be in a production environment.

And, the most important reason why I think the CONFIG is justified is this:
should a embedded device with a TPM that's using U-Boot as a boot loader be
subjected to a security evaluation (e.g. Common Criteria), an evaluator might
ask why a function like this, which, essentially has no real purpose aside from
providing debug information, is part of the TOE (especially if the TPM is used
as a fundamental security mechanism in the design). It enables an attacker that
gains access to the U-Boot console to, for example, read the handles of the
keys stored in the TPM, which is already one part of the data needed to access
them. Granted, it's not a huge advantage, but the best answer you can give an
evaluator is always "That's not possible" :-).

So, from a user perspective, I think it's desirable to have to option to
deactivate this function.

Best regards,

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

[U-Boot] [patch v2] armv8: ls1043a/ls1046aqds: fix the offsets of MTD partitions on Nor flash

[Wenbin song]

Fix the offsets of MTD partitions on Nor flash on ls1043ardb, ls1043aqds
and ls1046aqds boards.
Delete the rcw, uboot env and fman partitions.
Add user partitions for general usage.

Signed-off-by: Wenbin Song 
---
Changes for v1:
Delete the rcw, uboot env and fman partitions.
Add user partitions for general usage.
---
 include/configs/ls1043a_common.h | 14 --
 include/configs/ls1046aqds.h | 14 --
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index 9a01e48..b311d92 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -188,12 +188,14 @@
 #define MTDPARTS_DEFAULT "mtdparts=spi0.0:1m(uboot)," \
"5m(kernel),1m(dtb),9m(file_system)"
 #else
-#define MTDPARTS_DEFAULT "mtdparts=6000.nor:1m(nor_bank0_rcw)," \
-   "1m(nor_bank0_uboot),1m(nor_bank0_uboot_env)," \
-   "1m(nor_bank0_fman_uconde),40m(nor_bank0_fit)," \
-   "1m(nor_bank4_rcw),1m(nor_bank4_uboot)," \
-   "1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode)," \
-   "40m(nor_bank4_fit);7e80.flash:" \
+#define MTDPARTS_DEFAULT "mtdparts=6000.nor:" \
+   "2m@10(nor_bank0_uboot),"\
+   "40m@110(nor_bank0_fit)," \
+   "7m(nor_bank0_user)," \
+   "2m@410(nor_bank4_uboot)," \
+   "40m@51(nor_bank4_fit);"\
+   "-(nor_bank4_user)," \
+   "7e80.flash:" \
"1m(nand_uboot),1m(nand_uboot_env)," \
"20m(nand_fit);spi0.0:1m(uboot)," \
"5m(kernel),1m(dtb),9m(file_system)"
diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h
index 4b3b21e..5cd9d4a 100644
--- a/include/configs/ls1046aqds.h
+++ b/include/configs/ls1046aqds.h
@@ -485,12 +485,14 @@ unsigned long get_board_ddr_clk(void);
 #define MTDPARTS_DEFAULT "mtdparts=155.quadspi:2m(uboot)," \
"14m(free)"
 #else
-#define MTDPARTS_DEFAULT "mtdparts=6000.nor:1m(nor_bank0_rcw)," \
-   "1m(nor_bank0_uboot),1m(nor_bank0_uboot_env)," \
-   "1m(nor_bank0_fman_uconde),40m(nor_bank0_fit)," \
-   "1m(nor_bank4_rcw),1m(nor_bank4_uboot)," \
-   "1m(nor_bank4_uboot_env),1m(nor_bank4_fman_ucode)," \
-   "40m(nor_bank4_fit);7e80.flash:" \
+#define MTDPARTS_DEFAULT "mtdparts=6000.nor:" \
+   "2m@10(nor_bank0_uboot),"\
+   "40m@110(nor_bank0_fit)," \
+   "7m(nor_bank0_user)," \
+   "2m@410(nor_bank4_uboot)," \
+   "40m@51(nor_bank4_fit);"\
+   "-(nor_bank4_user)," \
+   "7e80.flash:" \
"4m(nand_uboot),36m(nand_kernel)," \
"472m(nand_free);spi0.0:2m(uboot)," \
"14m(free)"
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH] ti: clocks: Fix do_enable_clocks() to accept NULL pointers as input parameters

[Lokesh Vutla]

On Friday 24 March 2017 02:41 PM, Lukasz Majewski wrote:
> Hi Lokesh,
> 
>>
>>
>> On 3/24/2017 3:54 AM, Lukasz Majewski wrote:
>>> Up till this commit passing NULL as input parameter was allowed,
>>> but not handled properly.
>>>
>>> When one passed NULL to one of this function parameters, the code
>>> was executed causing data abort.
>>>
>>> However, what is more interesting, the abort was not caught because
>>> of code execution in HYP mode with masked CPSR A bit ("Imprecise
>>> Data Abort mask bit). The TI's AM57xx SoC switch to HYP mode with A
>>> bit masked in lowlevel_init.S due to SMC call. Such operation (by
>>> default) is performed in SoC ROM code.
>>>
>>> The problem would pop up when one:
>>> - Switch back to SVC mode after disabling LPAE support
>>> - Somebody enables A bit (by executing cpsie a asm instruction)
>>>
>>> and then the previously described exception would be caught.
>>>
>>> Signed-off-by: Lukasz Majewski 
>>> ---
>>>  arch/arm/cpu/armv7/omap-common/clocks-common.c | 10 ++
>>
>> This has been moved to arch/arm/mach-omap2/clocks-common.c
>> Please use the latest U-Boot.
> 
> Ok. I'm not working on a cutting-edge u-boot.
> 
>>
>>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
>>> b/arch/arm/cpu/armv7/omap-common/clocks-common.c index
>>> 097b8e3..157155a 100644 ---
>>> a/arch/arm/cpu/armv7/omap-common/clocks-common.c +++
>>> b/arch/arm/cpu/armv7/omap-common/clocks-common.c @@ -822,27 +822,29
>>> @@ void do_enable_clocks(u32 const *clk_domains, u32 i, max = 100;
>>>  
>>> /* Put the clock domains in SW_WKUP mode */
>>> -   for (i = 0; (i < max) && clk_domains[i]; i++) {
>>> +   for (i = 0; (i < max) && clk_domains && clk_domains[i];
>>> i++) {
>>
>> Instead of checking for clk_domains every time, can we use max as
>> ARRAY_SIZE(clk_domains)?
> 
> do_enable_clocks() accepts pointer to u32 as an argument
> (clk_domains). IMHO the ARRAY_SIZE(clk_domains) would be 1 - always.
> 

you are right. Discard my comment.

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

Re: [U-Boot] [PATCH] ti: clocks: Fix do_enable_clocks() to accept NULL pointers as input parameters

[Lukasz Majewski]

Hi Lokesh,

> 
> 
> On 3/24/2017 3:54 AM, Lukasz Majewski wrote:
> > Up till this commit passing NULL as input parameter was allowed,
> > but not handled properly.
> > 
> > When one passed NULL to one of this function parameters, the code
> > was executed causing data abort.
> > 
> > However, what is more interesting, the abort was not caught because
> > of code execution in HYP mode with masked CPSR A bit ("Imprecise
> > Data Abort mask bit). The TI's AM57xx SoC switch to HYP mode with A
> > bit masked in lowlevel_init.S due to SMC call. Such operation (by
> > default) is performed in SoC ROM code.
> > 
> > The problem would pop up when one:
> > - Switch back to SVC mode after disabling LPAE support
> > - Somebody enables A bit (by executing cpsie a asm instruction)
> > 
> > and then the previously described exception would be caught.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> >  arch/arm/cpu/armv7/omap-common/clocks-common.c | 10 ++
> 
> This has been moved to arch/arm/mach-omap2/clocks-common.c
> Please use the latest U-Boot.

Ok. I'm not working on a cutting-edge u-boot.

> 
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
> > b/arch/arm/cpu/armv7/omap-common/clocks-common.c index
> > 097b8e3..157155a 100644 ---
> > a/arch/arm/cpu/armv7/omap-common/clocks-common.c +++
> > b/arch/arm/cpu/armv7/omap-common/clocks-common.c @@ -822,27 +822,29
> > @@ void do_enable_clocks(u32 const *clk_domains, u32 i, max = 100;
> >  
> > /* Put the clock domains in SW_WKUP mode */
> > -   for (i = 0; (i < max) && clk_domains[i]; i++) {
> > +   for (i = 0; (i < max) && clk_domains && clk_domains[i];
> > i++) {
> 
> Instead of checking for clk_domains every time, can we use max as
> ARRAY_SIZE(clk_domains)?

do_enable_clocks() accepts pointer to u32 as an argument
(clk_domains). IMHO the ARRAY_SIZE(clk_domains) would be 1 - always.

> Similarly other places.
> 
> Thanks and regards,
> Lokesh
> 
> > enable_clock_domain(clk_domains[i],
> > CD_CLKCTRL_CLKTRCTRL_SW_WKUP);
> > }
> >  
> > /* Clock modules that need to be put in HW_AUTO */
> > -   for (i = 0; (i < max) && clk_modules_hw_auto[i]; i++) {
> > +   for (i = 0; (i < max) && clk_modules_hw_auto &&
> > +clk_modules_hw_auto[i]; i++) {
> > enable_clock_module(clk_modules_hw_auto[i],
> > MODULE_CLKCTRL_MODULEMODE_HW_AUTO,
> > wait_for_enable);
> > };
> >  
> > /* Clock modules that need to be put in SW_EXPLICIT_EN
> > mode */
> > -   for (i = 0; (i < max) && clk_modules_explicit_en[i]; i++) {
> > +   for (i = 0; (i < max) && clk_modules_explicit_en &&
> > +clk_modules_explicit_en[i]; i++) {
> > enable_clock_module(clk_modules_explicit_en[i],
> > MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN,
> > wait_for_enable);
> > };
> >  
> > /* Put the clock domains in HW_AUTO mode now */
> > -   for (i = 0; (i < max) && clk_domains[i]; i++) {
> > +   for (i = 0; (i < max) && clk_domains && clk_domains[i];
> > i++) { enable_clock_domain(clk_domains[i],
> > CD_CLKCTRL_CLKTRCTRL_HW_AUTO);
> > }
> > 




Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] [PATCH 6/8] rockchip: rk3188: Switch to new i2c IP blocks

[Heiko Stübner]

Am Donnerstag, 23. März 2017, 21:28:08 CET schrieb Simon Glass:
> Hi Heiko,
> 
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
> > The rk3066/rk3188 introduced new i2c IP blocks but kept the old ones
> > around just in case. The default also points to these old controllers.
> > 
> > The "new" blocks proved stable and nobody ever used the old ones anywhere,
> > not in the kernel and not in U-Boot, so to be able to reuse the already
> > existing driver make the rk3188 switch to the new ones in U-Boot as well.
> > 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > 
> >  arch/arm/mach-rockchip/rk3188-board-spl.c | 21 +
> >  1 file changed, 21 insertions(+)
> > 
> > diff --git a/arch/arm/mach-rockchip/rk3188-board-spl.c
> > b/arch/arm/mach-rockchip/rk3188-board-spl.c index affd959f86..14847a7b1b
> > 100644
> > --- a/arch/arm/mach-rockchip/rk3188-board-spl.c
> > +++ b/arch/arm/mach-rockchip/rk3188-board-spl.c
> > @@ -17,6 +17,7 @@
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > +#include 
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > @@ -102,6 +103,7 @@ void board_init_f(ulong dummy)
> > 
> >  {
> >  
> > struct udevice *pinctrl, *dev;
> > struct rk3188_pmu *pmu;
> > 
> > +   struct rk3188_grf *grf;
> > 
> > int ret;
> > 
> > /* Example code showing how to enable the debug UART on RK3188 */
> > 
> > @@ -154,6 +156,25 @@ void board_init_f(ulong dummy)
> > 
> > error("pmu syscon returned %ld\n", PTR_ERR(pmu));
> > 
> > SAVE_SP_ADDR = readl(>sys_reg[2]);
> > 
> > +   /* init common grf settings */
> > +   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> > +   if (IS_ERR(grf)) {
> > +   error("grf syscon returned %ld\n", PTR_ERR(grf));
> > +   } else {
> > +   /* make i2c controllers use the new IP */
> > +   rk_clrsetreg(>soc_con1,
> > +   RKI2C4_SEL_MASK << RKI2C4_SEL_SHIFT |
> > +   RKI2C3_SEL_MASK << RKI2C3_SEL_SHIFT |
> > +   RKI2C2_SEL_MASK << RKI2C2_SEL_SHIFT |
> > +   RKI2C1_SEL_MASK << RKI2C1_SEL_SHIFT |
> > +   RKI2C0_SEL_MASK << RKI2C0_SEL_SHIFT,
> > +   RKI2C4_SEL_MASK << RKI2C4_SEL_SHIFT |
> > +   RKI2C3_SEL_MASK << RKI2C3_SEL_SHIFT |
> > +   RKI2C2_SEL_MASK << RKI2C2_SEL_SHIFT |
> > +   RKI2C1_SEL_MASK << RKI2C1_SEL_SHIFT |
> > +   RKI2C0_SEL_MASK << RKI2C0_SEL_SHIFT);
> > +   }
> 
> Can you move this to the pinctrl driver?

Are you sure that is the right approach?

This setting switches the i2c controller IP block used, while the i2c-pins are 
not affected by this at all. You could also use the i2c pins with the other 
i2c controller with the same pinctrl settings, so it feels a tiny bit strange 
to burden the pinctrl driver with this.

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

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

[Jernej Škrabec]

Hi Kever,

Dne petek, 24. marec 2017 ob 03:38:16 CET je Kever Yang napisal(a):
> Hi Jernej,
> 
> On 03/24/2017 08:11 AM, Jernej Skrabec wrote:
> > MiQi is rk3288 based development board with 1 or 2 GB SDRAM, 16 GB eMMC,
> > micro SD card interface, 4 USB 2.0 ports, HDMI, gigabit Ethernet and
> > expansion ports.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >   arch/arm/dts/Makefile   |   1 +
> >   arch/arm/dts/rk3288-miqi.dts|  46 
> >   arch/arm/dts/rk3288-miqi.dtsi   | 459
> >    arch/arm/mach-rockchip/rk3288/Kconfig 
> >|  11 +
> >   board/mqmaker/miqi_rk3288/Kconfig   |  15 ++
> >   board/mqmaker/miqi_rk3288/MAINTAINERS   |   6 +
> >   board/mqmaker/miqi_rk3288/Makefile  |   7 +
> >   board/mqmaker/miqi_rk3288/miqi-rk3288.c |  15 ++
> >   configs/miqi-rk3288_defconfig   |  73 +
> >   doc/README.rockchip |   5 +-
> >   include/configs/miqi_rk3288.h   |  22 ++
> >   11 files changed, 658 insertions(+), 2 deletions(-)
> >   create mode 100644 arch/arm/dts/rk3288-miqi.dts
> >   create mode 100644 arch/arm/dts/rk3288-miqi.dtsi
> >   create mode 100644 board/mqmaker/miqi_rk3288/Kconfig
> >   create mode 100644 board/mqmaker/miqi_rk3288/MAINTAINERS
> >   create mode 100644 board/mqmaker/miqi_rk3288/Makefile
> >   create mode 100644 board/mqmaker/miqi_rk3288/miqi-rk3288.c
> >   create mode 100644 configs/miqi-rk3288_defconfig
> >   create mode 100644 include/configs/miqi_rk3288.h
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index afeb43ff66..60a9aeb698 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -38,6 +38,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> > 
> > rk3288-fennec.dtb \
> > rk3288-tinker.dtb \
> > rk3288-popmetal.dtb \
> > 
> > +   rk3288-miqi.dtb \
> 
> Should be alphabet order, so before tinker and after fennec.
> 

But then also other rk3288 boards are not listed in any particular order. I 
will reorder them all alphabetically.

> > rk3328-evb.dtb \
> > rk3399-evb.dtb
> >   
> >   dtb-$(CONFIG_ARCH_MESON) += \
> > 
> > diff --git a/arch/arm/dts/rk3288-miqi.dts b/arch/arm/dts/rk3288-miqi.dts
> > new file mode 100644
> > index 00..7b92caf024
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3288-miqi.dts
> > @@ -0,0 +1,46 @@
> > +/*
> > + * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> > + *
> > + * SPDX-License-Identifier: GPL-2.0+ X11
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3288-miqi.dtsi"
> > +
> > +/ {
> > +   model = "mqmaker MiQi";
> > +   compatible = "mqmaker,miqi", "rockchip,rk3288";
> > +
> > +   chosen {
> > +   stdout-path = "serial2:115200n8";
> > +   };
> > +};
> > +
> > + {
> > +   rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
> > +   0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
> > +   0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
> > +   0x1 0x7 0x7 0x4 0xc 0x43 0x100 0x0
> > +   0x5 0x0>;
> > +   rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
> > +   0xa60 0x40 0x10 0x0>;
> > +   rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
> > +};
> > +
> > +
> > + {
> > +   u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > +   u-boot,dm-pre-reloc;
> > +   reg-shift = <2>;
> > +};
> > +
> > + {
> > +   u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > +   u-boot,dm-pre-reloc;
> > +};
> > diff --git a/arch/arm/dts/rk3288-miqi.dtsi b/arch/arm/dts/rk3288-miqi.dtsi
> > new file mode 100644
> > index 00..12e584f242
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3288-miqi.dtsi
> > @@ -0,0 +1,459 @@
> > +/*
> > + * Copyright (c) 2016 Heiko Stuebner 
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + *  a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License, or (at your option) any later version.
> > + *
> > + * This file is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + *  b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies