linux-samsung-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Jaehoon Chung <jh80.chung@samsung.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Christian Hewitt <christianshewitt@gmail.com>
Cc: "linux-samsung-soc@vger.kernel.org" 
	<linux-samsung-soc@vger.kernel.org>,
	Marian Mihailescu <mihailescu2m@gmail.com>,
	Sylwester Nawrocki <snawrocki@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
Date: Mon, 4 Oct 2021 12:07:57 +0200	[thread overview]
Message-ID: <3f2c93f5-e207-ce9d-ee90-ec34ad6d39ea@samsung.com> (raw)
In-Reply-To: <fec1cc85-0c81-035b-fe89-1b6dedbb3bc5@samsung.com>

Hi Jaehoon,

On 01.10.2021 02:40, Jaehoon Chung wrote:
> On 9/27/21 8:09 PM, Krzysztof Kozlowski wrote:
>> On Mon, 13 Sept 2021 at 06:32, Christian Hewitt
>> <christianshewitt@gmail.com> wrote:
>>> https://protect2.fireeye.com/v1/url?k=6f7d4070-30e6793d-6f7ccb3f-0cc47aa8f5ba-2c8976d4b015314f&q=1&e=776d64d2-22f3-400a-a241-42af8b5f60d0&u=https%3A%2F%2Fgithub.com%2Fchewitt%2Flinux%2Fcommit%2F8a4ebfb43a394e5dc5e9fafc92a50d5e81a4f258
>>>
>>> If I boot any recent kernel without the above patch, the emmc module on the XU4 is not detected, see:
>>>
>>> Without:
>>>
>>> [    3.227837] mmc0: tuning execution failed: -5
>>> [    3.231229] mmc0: error -5 whilst initialising MMC card
>>> [    3.536450] mmc0: tuning execution failed: -5
>>> [    3.539680] mmc0: error -5 whilst initialising MMC card
>>> [    3.794056] mmc0: tuning execution failed: -5
>>> [    3.794212] mmc0: error -5 whilst initialising MMC card
>>> [    4.111097] mmc0: tuning execution failed: -5
>>> [    4.115356] mmc0: error -5 whilst initialising MMC card
>>> [    4.426164] mmc0: tuning execution failed: -5
>>> [    4.429678] mmc0: error -5 whilst initialising MMC card
>>> [    4.756226] mmc0: tuning execution failed: -5
>>> [    4.760641] mmc0: error -5 whilst initialising MMC card
>>>
>>> With:
>>>
>>> [    3.305461] mmc0: new HS400 MMC card at address 0001
>>> [    3.307444] mmcblk0: mmc0:0001 8GME4R 7.28 GiB
>>> [    3.308132] mmcblk0boot0: mmc0:0001 8GME4R 4.00 MiB
>>> [    3.309172] mmcblk0boot1: mmc0:0001 8GME4R 4.00 MiB
>>> [    3.310255] mmcblk0rpmb: mmc0:0001 8GME4R 512 KiB, chardev (246:0)
>>> [    3.315963]  mmcblk0: p1 p2
>>>
>>> The patch is sourced from a Linux 5.4 patchset used by several retro gaming distros for XU4 images shared in the HardKernel forums. I would be happy to submit it, but the original patch has no description in the commit message. Not being a coding developer myself I cannot explain whether it is correct or what it’s doing to add one. All I can do is confirm that it works, and is needed. SD card boot is not an issue.
>>>
>>> I’ve CC’d the original author (Marian) in case he remembers the patch and can comment. It would be good to get this upstream.
>> The patch might have sense but would require describing conditions -
>> what MMC input and output clock settings work and which do not work.
>> Also someone would need to test other Exynos5422 boards and other
>> Exynos with HS200 and HS400 support (Exynos5433, Exynos7). I think
>> this should not affect SD cards.
>
> Thanks for adding me.
> I didn't see XU4 booting fail with linux-5.15-rc1 kernel.
>
> [    4.561934] mmc1: new HS400 MMC card at address 0001
> [    4.572401] mmcblk1: mmc1:0001 SDW16G 14.7 GiB
> [    4.602555]  mmcblk1: p1 p2 p3 p4 < p5 p6 p7 >
> [    4.623201] mmcblk1boot0: mmc1:0001 SDW16G 4.00 MiB
> [    4.640465] mmcblk1boot1: mmc1:0001 SDW16G 4.00 MiB
>
> Which kernel version did you use?

I came across this patch some time ago, but also didn't manage to 
reproduce the issue - in my case eMMC was always detected properly. It 
might be related to particular version or series of the eMMC modules.

I've just checked that patch on XU3, XU4, PeachPi and TM2e boards. All 
are working properly with it.

I've also tried to benchmark the impact of that change and in some case 
it causes some performance degradation.

The main difference is clock configuration. Before this patch (XU4):

# dmesg | grep mmc0
mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, 
actual 396825HZ div = 63)
mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot req 200000000Hz, 
actual 200000000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, 
actual 50000000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 400000000Hz (slot req 200000000Hz, 
actual 200000000HZ div = 1)
mmc0: new HS400 MMC card at address 0001
mmcblk0: mmc0:0001 SDW16G 14.7 GiB
mmcblk0boot0: mmc0:0001 SDW16G 4.00 MiB
mmcblk0boot1: mmc0:0001 SDW16G 4.00 MiB
mmcblk0rpmb: mmc0:0001 SDW16G 4.00 MiB, chardev (245:0)

After applying the patch (mmc device number is random depending on the 
boot):

# dmesg | grep mmc1
[    3.619177] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 
400000Hz, actual 396825HZ div = 63)
[    4.057167] mmc_host mmc1: Bus speed (slot 0) = 200000000Hz (slot req 
200000000Hz, actual 200000000HZ div = 0)
[    4.070040] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 
52000000Hz, actual 50000000HZ div = 0)
[    4.089028] mmc_host mmc1: Bus speed (slot 0) = 266666666Hz (slot req 
200000000Hz, actual 133333333HZ div = 1)
[    4.102296] mmc1: new HS400 MMC card at address 0001
[    4.119072] mmcblk1: mmc1:0001 SDW16G 14.7 GiB
[    4.173507] mmcblk1boot0: mmc1:0001 SDW16G 4.00 MiB
[    4.196210] mmcblk1boot1: mmc1:0001 SDW16G 4.00 MiB
[    4.215163] mmcblk1rpmb: mmc1:0001 SDW16G 4.00 MiB, chardev (245:0)

The performance has been measured with:

# dd if=/dev/mmcblk1p6 of=/dev/null bs=128k
31944+0 records in
31944+0 records out
4186963968 bytes (4.2 GB) copied, 36.6981 s, 114 MB/s

Results (XU4 board):

exynos_defconfig: 145 MB/s (before) vs 114 MB/s (after)
exynos_defconfig + all devfreqs set to performance: 146 MB/s vs 115 MB/s
exynos_defconfig + cpufreq & all devfreqs set to performance: 154 MB/s 
vs 139 MB/s
exynos_defconfig + CONFIG_ARM_EXYNOS_BUS_DEVFREQ disabled: 130 MB/s vs 
108 MB/s
exynos_defconfig + CONFIG_CPUFREQ_DT disabled: 69 MB/s (no impact)
exynos_defconfig + CONFIG_ARM_EXYNOS_BUS_DEVFREQ & CONFIG_CPUFREQ_DT: 66 
MB/s (no impact)


Maybe some other clock configuration (I mean the rate of the top-level 
clocks or even PLLS) will solve the issue without degrading the 
performance, but it is hard to judge that without reproducing the issue.


Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


  parent reply	other threads:[~2021-10-04 10:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13  4:27 BUG: Cannot boot Odroid XU4 from eMMC without this patch Christian Hewitt
2021-09-27 11:09 ` Krzysztof Kozlowski
2021-10-01  0:40   ` Jaehoon Chung
2021-10-01 13:41     ` Christian Hewitt
2021-10-06 22:16       ` Jaehoon Chung
2021-10-07  4:36         ` Christian Hewitt
2021-10-07 11:05           ` Jaehoon Chung
2021-10-20 11:14             ` Jaehoon Chung
2021-10-04 10:07     ` Marek Szyprowski [this message]
2021-10-04 13:01       ` Krzysztof Kozlowski
2021-10-04 15:51         ` Marek Szyprowski
2021-10-06 10:40           ` Ulf Hansson
2021-10-06 22:12             ` Jaehoon Chung
2021-10-06 22:01       ` Jaehoon Chung

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3f2c93f5-e207-ce9d-ee90-ec34ad6d39ea@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=christianshewitt@gmail.com \
    --cc=jh80.chung@samsung.com \
    --cc=krzk@kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mihailescu2m@gmail.com \
    --cc=snawrocki@kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).