linux-samsung-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jaehoon Chung <jh80.chung@samsung.com>
To: Marek Szyprowski <m.szyprowski@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: Thu, 7 Oct 2021 07:01:29 +0900	[thread overview]
Message-ID: <1a4870b9-b57a-461b-83a1-2410bd84bbd7@samsung.com> (raw)
In-Reply-To: <3f2c93f5-e207-ce9d-ee90-ec34ad6d39ea@samsung.com>

Hi Marek,

On 10/4/21 7:07 PM, Marek Szyprowski wrote:
> 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.

Thanks for checking them. I had also suspected that this problem is producing according to eMMC modules.
(Chritian's eMMC is different with mine.)

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

I'm checking this problem in more detail since today. I don't have all eMMC modules to connect on XU3/4.
So as you mentioned, it's difficult to check without reproducing the issue.
I'm trying to find eMMC module to reproduce this issue in my office.

Best Regards,
Jaehoon Chung

> 
> 
> Best regards
> 


      parent reply	other threads:[~2021-10-06 22:00 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
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 [this message]

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=1a4870b9-b57a-461b-83a1-2410bd84bbd7@samsung.com \
    --to=jh80.chung@samsung.com \
    --cc=christianshewitt@gmail.com \
    --cc=krzk@kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --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).