arm: tegra: apalis-tk1 and ext clock loopback

From: Marcel Ziswiler <[email protected]>

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 <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Signed-off-by Marcel Ziswiler <[email protected]>

---

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(+)

arch/arm/include/asm/arch-tegra/tegra_mmc.h +2 -0

index 64c848a..c40599a 100644
@@ -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)

drivers/mmc/Kconfig +11 -0

index ddef59a..3a6dcec 100644
@@ -345,6 +345,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.ziswiler at toradex.com): Move to device tree controlled
+	  approach once proper kernel integration made it mainline.
+
 endmenu
 
 config SYS_FSL_ERRATUM_ESDHC111

drivers/mmc/tegra_mmc.c +16 -0

index 0df74ef..6c6affb 100644
@@ -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.ziswiler at toradex.com): Move to device tree controlled
+	 * approach once proper kernel integration made it mainline.
+	 */
+	if (priv->reg == (void *)0x700b0400) {
+		mask = readl(&priv->reg->venmiscctl);
+		mask &= ~TEGRA_MMC_MISCON_ENABLE_EXT_LOOPBACK;
+		writel(mask, &priv->reg->venmiscctl);
+	}
+#endif
+
 	priv->version = readw(&priv->reg->hcver);
 	debug("host version = %x\n", priv->version);
 

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.

Quoted 8 lines · 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

Quoted 14 lines

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?

Alex

Hi Alex

Quoted 25 lines · Alexander Graf

Quoted 22 lines · 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 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.

Quoted 1 line

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.

Quoted 32 lines · Marcel Ziswiler

Hi Alex

Quoted 28 lines · Alexander Graf

Quoted 9 lines · 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

Quoted 15 lines

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?

Quoted 5 lines

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.

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.

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.

Alex

Hi Alexander

Quoted 40 lines · Alexander Graf

Quoted 37 lines · Marcel Ziswiler

Hi Alex

Quoted 27 lines · Alexander Graf

Quoted 9 lines · 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

Quoted 15 lines

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.

Quoted 1 line

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.

Quoted 1 line

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?

Quoted 5 lines

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

Quoted 19 lines

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.

Quoted 3 lines

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.

Quoted 48 lines · Marcel Ziswiler

Hi Alexander

Quoted 36 lines · Alexander Graf

Quoted 34 lines · Marcel Ziswiler

Hi Alex

Quoted 30 lines · Alexander Graf

Quoted 10 lines · 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-n
ext

Quoted 16 lines

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?

Quoted 8 lines

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 2 lines

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

Quoted 8 lines

Quoted 7 lines

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.

Quoted 10 lines

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

:)

Quoted 22 lines

Quoted 22 lines

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 6 lines

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 enable thumb2, otherwise you will get bitten on random compiler
updates down the road.

Thanks,

Alex

Quoted 58 lines · Alexander Graf

Quoted 48 lines · Marcel Ziswiler

Hi Alexander

Quoted 36 lines · Alexander Graf

Quoted 34 lines · Marcel Ziswiler

Hi Alex

Quoted 30 lines · Alexander Graf

Quoted 10 lines · 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-n
ext

Quoted 16 lines

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?

Quoted 8 lines

Quoted 6 lines

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.

Quoted 7 lines

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

Quoted 4 lines

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.

Quoted 15 lines

Quoted 2 lines

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.

Quoted 10 lines

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.

Quoted 3 lines

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

Quoted 52 lines

Quoted 8 lines

Quoted 7 lines

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.

Quoted 10 lines

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

:)

Quoted 22 lines

Quoted 22 lines

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.

Quoted 8 lines

Quoted 3 lines

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

Quoted 9 lines

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.

Uups, we still have it kind of hard coded by default but at least with a distro boot fall back.

Quoted 7 lines

Quoted 6 lines

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.

Quoted 4 lines

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.

OK, I will send a V5 which does not explicitly disable it.

Quoted 5 lines

And if you really are size constrained with today's configuration, please enable thumb2, otherwise you will get bitten on random compiler
updates down the road.

Unfortunately the platforms I have that are space constrained do not support any such but again those probably won't ever run any regular distro neither.

Hi,

On 24 March 2017 at 17:52, Marcel Ziswiler <[email protected]> wrote:

Quoted 7 lines

Quoted 4 lines

And if you really are size constrained with today's configuration, please enable thumb2, otherwise you will get bitten on random compiler
updates down the road.

Unfortunately the platforms I have that are space constrained do not support any such but again those probably won't ever run any regular distro neither.

We certainly should not mandate EFI support in U-Boot :-(

I think it's
a nice idea if you have to use EFI/grub on your system though. A great way to get past the legacy problem.

Anyway, the video looks interesting - are the slides available somewhere? I'd really like to see how this is presented.