linux-samsung-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* BUG: Cannot boot Odroid XU4 from eMMC without this patch
@ 2021-09-13  4:27 Christian Hewitt
  2021-09-27 11:09 ` Krzysztof Kozlowski
  0 siblings, 1 reply; 14+ messages in thread
From: Christian Hewitt @ 2021-09-13  4:27 UTC (permalink / raw)
  To: linux-samsung-soc; +Cc: Marian Mihailescu

https://github.com/chewitt/linux/commit/8a4ebfb43a394e5dc5e9fafc92a50d5e81a4f258

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. 

Christian

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  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
  0 siblings, 1 reply; 14+ messages in thread
From: Krzysztof Kozlowski @ 2021-09-27 11:09 UTC (permalink / raw)
  To: Christian Hewitt
  Cc: linux-samsung-soc, Marian Mihailescu, Marek Szyprowski,
	Sylwester Nawrocki, Jaehoon Chung, Ulf Hansson

On Mon, 13 Sept 2021 at 06:32, Christian Hewitt
<christianshewitt@gmail.com> wrote:
>
> https://github.com/chewitt/linux/commit/8a4ebfb43a394e5dc5e9fafc92a50d5e81a4f258
>
> 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.

+Cc Marek, Sylwester, Jaehoon and Ulf.

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-09-27 11:09 ` Krzysztof Kozlowski
@ 2021-10-01  0:40   ` Jaehoon Chung
  2021-10-01 13:41     ` Christian Hewitt
  2021-10-04 10:07     ` Marek Szyprowski
  0 siblings, 2 replies; 14+ messages in thread
From: Jaehoon Chung @ 2021-10-01  0:40 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Christian Hewitt
  Cc: linux-samsung-soc, Marian Mihailescu, Marek Szyprowski,
	Sylwester Nawrocki, Ulf Hansson

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?

Best Regards,
Jaehoon Chung

> 
> +Cc Marek, Sylwester, Jaehoon and Ulf.
> 
> Best regards,
> Krzysztof
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-01  0:40   ` Jaehoon Chung
@ 2021-10-01 13:41     ` Christian Hewitt
  2021-10-06 22:16       ` Jaehoon Chung
  2021-10-04 10:07     ` Marek Szyprowski
  1 sibling, 1 reply; 14+ messages in thread
From: Christian Hewitt @ 2021-10-01 13:41 UTC (permalink / raw)
  To: Jaehoon Chung
  Cc: Krzysztof Kozlowski, linux-samsung-soc, Marian Mihailescu,
	Marek Szyprowski, Sylwester Nawrocki, Ulf Hansson


> On 1 Oct 2021, at 4:40 am, Jaehoon Chung <jh80.chung@samsung.com> 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?

The original report is against 5.14.0, but I see the same with 5.15-rc3

dmesg: http://ix.io/3AuL
dmesg | grep mmc: http://ix.io/3AuO

And if I pick that patch to my kernel branch all is good:

dmesg: http://ix.io/3Avf
dmesg | grep mmc: http://ix.io/3Ave

Here’s an SD (or eMMC) bootable image for an XU4 that exhibits the problem. You need to run “systemctl stop kodi” once the UART console is available else it attempts to run Kodi and Panfrost (the image is created for some Panfrost poking) currently wedges the board. Once the Kodi service is stopped “systemctl mask kodi” will prevent it from running again.

https://chewitt.libreelec.tv/testing/LibreELEC-Exynos.arm-10.0.0-odroid-xu4.img.gz

Kernel defconfig for the image: http://sprunge.us/G6uxty - basically the exynos config but with a wide variety of not-needed drivers (other SoCs, network cards, etc.) disabled.

The board is booting from u-boot 2020.04 in case that matters.

Christian


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-01  0:40   ` Jaehoon Chung
  2021-10-01 13:41     ` Christian Hewitt
@ 2021-10-04 10:07     ` Marek Szyprowski
  2021-10-04 13:01       ` Krzysztof Kozlowski
  2021-10-06 22:01       ` Jaehoon Chung
  1 sibling, 2 replies; 14+ messages in thread
From: Marek Szyprowski @ 2021-10-04 10:07 UTC (permalink / raw)
  To: Jaehoon Chung, Krzysztof Kozlowski, Christian Hewitt
  Cc: linux-samsung-soc, Marian Mihailescu, Sylwester Nawrocki, Ulf Hansson

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-04 10:07     ` Marek Szyprowski
@ 2021-10-04 13:01       ` Krzysztof Kozlowski
  2021-10-04 15:51         ` Marek Szyprowski
  2021-10-06 22:01       ` Jaehoon Chung
  1 sibling, 1 reply; 14+ messages in thread
From: Krzysztof Kozlowski @ 2021-10-04 13:01 UTC (permalink / raw)
  To: Marek Szyprowski, Jaehoon Chung, Christian Hewitt
  Cc: linux-samsung-soc, Marian Mihailescu, Sylwester Nawrocki, Ulf Hansson

On 04/10/2021 12:07, 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.
> 
> 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.
> 

Thanks for testing and performance measurements. The read speed seems to
be a direct effect of lower mmc bus frequency (DIVRATIO changed from 2
to 3).

What next? Except what Marek suggested, maybe compare MMC card
capabilities and try to find a difference? For example Marek's eMMC (at
least one with logs) is from Sandisk SDW16G. Christian's and Marian's
(Memeka / mihailescu2m) is apparently Samsung's 8GME4R.

Because the patch reduces performance and not all users are affected, I
have some doubts. Maybe use by default lower clock (so as in this patch)
but if card is in list of known good cards go higher?

Another idea is to use always slower bus because it is simply safer and
we do not have resources to test 100x of different eMMC modules...

Any comments from you?

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-04 13:01       ` Krzysztof Kozlowski
@ 2021-10-04 15:51         ` Marek Szyprowski
  2021-10-06 10:40           ` Ulf Hansson
  0 siblings, 1 reply; 14+ messages in thread
From: Marek Szyprowski @ 2021-10-04 15:51 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Jaehoon Chung, Christian Hewitt
  Cc: linux-samsung-soc, Marian Mihailescu, Sylwester Nawrocki, Ulf Hansson

Hi Krzysztof,

On 04.10.2021 15:01, Krzysztof Kozlowski wrote:
> On 04/10/2021 12:07, Marek Szyprowski wrote:
>> 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.
>>
> Thanks for testing and performance measurements. The read speed seems to
> be a direct effect of lower mmc bus frequency (DIVRATIO changed from 2
> to 3).
>
> What next? Except what Marek suggested, maybe compare MMC card
> capabilities and try to find a difference? For example Marek's eMMC (at
> least one with logs) is from Sandisk SDW16G. Christian's and Marian's
> (Memeka / mihailescu2m) is apparently Samsung's 8GME4R.

I have also eMMC modules with AJTD4R and 016G92 IDs. I can test them, 
but that won't happen soon due to remote work.

> Because the patch reduces performance and not all users are affected, I
> have some doubts. Maybe use by default lower clock (so as in this patch)
> but if card is in list of known good cards go higher?
>
> Another idea is to use always slower bus because it is simply safer and
> we do not have resources to test 100x of different eMMC modules...
>
> Any comments from you?

I vote for the safer clock rates. Maybe we can add some dt-property for 
the higher rates for the boards with the known to be working properly 
eMMC modules.

Best regards

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-04 15:51         ` Marek Szyprowski
@ 2021-10-06 10:40           ` Ulf Hansson
  2021-10-06 22:12             ` Jaehoon Chung
  0 siblings, 1 reply; 14+ messages in thread
From: Ulf Hansson @ 2021-10-06 10:40 UTC (permalink / raw)
  To: Marek Szyprowski, Krzysztof Kozlowski
  Cc: Jaehoon Chung, Christian Hewitt, linux-samsung-soc,
	Marian Mihailescu, Sylwester Nawrocki

On Mon, 4 Oct 2021 at 17:51, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> Hi Krzysztof,
>
> On 04.10.2021 15:01, Krzysztof Kozlowski wrote:
> > On 04/10/2021 12:07, Marek Szyprowski wrote:
> >> 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.
> >>
> > Thanks for testing and performance measurements. The read speed seems to
> > be a direct effect of lower mmc bus frequency (DIVRATIO changed from 2
> > to 3).
> >
> > What next? Except what Marek suggested, maybe compare MMC card
> > capabilities and try to find a difference? For example Marek's eMMC (at
> > least one with logs) is from Sandisk SDW16G. Christian's and Marian's
> > (Memeka / mihailescu2m) is apparently Samsung's 8GME4R.
>
> I have also eMMC modules with AJTD4R and 016G92 IDs. I can test them,
> but that won't happen soon due to remote work.
>
> > Because the patch reduces performance and not all users are affected, I
> > have some doubts. Maybe use by default lower clock (so as in this patch)
> > but if card is in list of known good cards go higher?
> >
> > Another idea is to use always slower bus because it is simply safer and
> > we do not have resources to test 100x of different eMMC modules...
> >
> > Any comments from you?
>
> I vote for the safer clock rates. Maybe we can add some dt-property for
> the higher rates for the boards with the known to be working properly
> eMMC modules.

We already have a common mmc DT property, "max-frequency". I think
that should fit well, as it allows us to cap the frequency on those
boards that need this, right?

Having a card quirk could be another option, but then we need to be
sure that it's actually the card that has the limitation.

Kind regards
Uffe

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-04 10:07     ` Marek Szyprowski
  2021-10-04 13:01       ` Krzysztof Kozlowski
@ 2021-10-06 22:01       ` Jaehoon Chung
  1 sibling, 0 replies; 14+ messages in thread
From: Jaehoon Chung @ 2021-10-06 22:01 UTC (permalink / raw)
  To: Marek Szyprowski, Krzysztof Kozlowski, Christian Hewitt
  Cc: linux-samsung-soc, Marian Mihailescu, Sylwester Nawrocki, Ulf Hansson

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
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-06 10:40           ` Ulf Hansson
@ 2021-10-06 22:12             ` Jaehoon Chung
  0 siblings, 0 replies; 14+ messages in thread
From: Jaehoon Chung @ 2021-10-06 22:12 UTC (permalink / raw)
  To: Ulf Hansson, Marek Szyprowski, Krzysztof Kozlowski
  Cc: Christian Hewitt, linux-samsung-soc, Marian Mihailescu,
	Sylwester Nawrocki

On 10/6/21 7:40 PM, Ulf Hansson wrote:
> On Mon, 4 Oct 2021 at 17:51, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>>
>> Hi Krzysztof,
>>
>> On 04.10.2021 15:01, Krzysztof Kozlowski wrote:
>>> On 04/10/2021 12:07, Marek Szyprowski wrote:
>>>> 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.
>>>>
>>> Thanks for testing and performance measurements. The read speed seems to
>>> be a direct effect of lower mmc bus frequency (DIVRATIO changed from 2
>>> to 3).
>>>
>>> What next? Except what Marek suggested, maybe compare MMC card
>>> capabilities and try to find a difference? For example Marek's eMMC (at
>>> least one with logs) is from Sandisk SDW16G. Christian's and Marian's
>>> (Memeka / mihailescu2m) is apparently Samsung's 8GME4R.
>>
>> I have also eMMC modules with AJTD4R and 016G92 IDs. I can test them,
>> but that won't happen soon due to remote work.
>>
>>> Because the patch reduces performance and not all users are affected, I
>>> have some doubts. Maybe use by default lower clock (so as in this patch)
>>> but if card is in list of known good cards go higher?
>>>
>>> Another idea is to use always slower bus because it is simply safer and
>>> we do not have resources to test 100x of different eMMC modules...
>>>
>>> Any comments from you?
>>
>> I vote for the safer clock rates. Maybe we can add some dt-property for
>> the higher rates for the boards with the known to be working properly
>> eMMC modules.
> 
> We already have a common mmc DT property, "max-frequency". I think
> that should fit well, as it allows us to cap the frequency on those
> boards that need this, right?

It's already using "max-frequency" for those boards.I think that its value is correct.
I will check this issue on this week. Will share after checking what's best solution.

> 
> Having a card quirk could be another option, but then we need to be
> sure that it's actually the card that has the limitation.

I don't want to use a card quirk if there is no solution to issue.

Best Regards,
Jaehoon Chung

> 
> Kind regards
> Uffe
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-01 13:41     ` Christian Hewitt
@ 2021-10-06 22:16       ` Jaehoon Chung
  2021-10-07  4:36         ` Christian Hewitt
  0 siblings, 1 reply; 14+ messages in thread
From: Jaehoon Chung @ 2021-10-06 22:16 UTC (permalink / raw)
  To: Christian Hewitt
  Cc: Krzysztof Kozlowski, linux-samsung-soc, Marian Mihailescu,
	Marek Szyprowski, Sylwester Nawrocki, Ulf Hansson

Hi,

On 10/1/21 10:41 PM, Christian Hewitt wrote:
> 
>> On 1 Oct 2021, at 4:40 am, Jaehoon Chung <jh80.chung@samsung.com> 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?
> 
> The original report is against 5.14.0, but I see the same with 5.15-rc3
> 
> dmesg: https://protect2.fireeye.com/v1/url?k=703ee5f5-2fa5dcb3-703f6eba-0cc47a3003e8-ad25e9061be78bbb&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3AuL
> dmesg | grep mmc: https://protect2.fireeye.com/v1/url?k=5d2277f1-02b94eb7-5d23fcbe-0cc47a3003e8-b778cb8e233bbe4b&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3AuO
> 
> And if I pick that patch to my kernel branch all is good:
> 
> dmesg: https://protect2.fireeye.com/v1/url?k=8bcf7900-d4544046-8bcef24f-0cc47a3003e8-6124ad41dd642d56&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3Avf
> dmesg | grep mmc: https://protect2.fireeye.com/v1/url?k=66ce5f96-395566d0-66cfd4d9-0cc47a3003e8-b9768331cc0e4416&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3Ave
> 
> Here’s an SD (or eMMC) bootable image for an XU4 that exhibits the problem. You need to run “systemctl stop kodi” once the UART console is available else it attempts to run Kodi and Panfrost (the image is created for some Panfrost poking) currently wedges the board. Once the Kodi service is stopped “systemctl mask kodi” will prevent it from running again.
> 
> https://chewitt.libreelec.tv/testing/LibreELEC-Exynos.arm-10.0.0-odroid-xu4.img.gz
> 
> Kernel defconfig for the image: https://protect2.fireeye.com/v1/url?k=806156b6-dffa6ff0-8060ddf9-0cc47a3003e8-b2bec8fd0863dc1b&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fsprunge.us%2FG6uxty - basically the exynos config but with a wide variety of not-needed drivers (other SoCs, network cards, etc.) disabled.
> 
> The board is booting from u-boot 2020.04 in case that matters.

Thanks for sharing information. Sorry for replying late. I will check this problem on this week. 
It needs to satisfy all exynos5 SoCs. I just wonder why not working fine according to eMMC modules.

Best Regards,
Jaehoon Chung


> 
> Christian
> 
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-06 22:16       ` Jaehoon Chung
@ 2021-10-07  4:36         ` Christian Hewitt
  2021-10-07 11:05           ` Jaehoon Chung
  0 siblings, 1 reply; 14+ messages in thread
From: Christian Hewitt @ 2021-10-07  4:36 UTC (permalink / raw)
  To: Jaehoon Chung
  Cc: Krzysztof Kozlowski, linux-samsung-soc, Marian Mihailescu,
	Marek Szyprowski, Sylwester Nawrocki, Ulf Hansson

> 
> On 7 Oct 2021, at 2:16 am, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> 
> Hi,
> 
> On 10/1/21 10:41 PM, Christian Hewitt wrote:
>> 
>>> On 1 Oct 2021, at 4:40 am, Jaehoon Chung <jh80.chung@samsung.com> 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?
>> 
>> The original report is against 5.14.0, but I see the same with 5.15-rc3
>> 
>> dmesg: https://protect2.fireeye.com/v1/url?k=703ee5f5-2fa5dcb3-703f6eba-0cc47a3003e8-ad25e9061be78bbb&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3AuL
>> dmesg | grep mmc: https://protect2.fireeye.com/v1/url?k=5d2277f1-02b94eb7-5d23fcbe-0cc47a3003e8-b778cb8e233bbe4b&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3AuO
>> 
>> And if I pick that patch to my kernel branch all is good:
>> 
>> dmesg: https://protect2.fireeye.com/v1/url?k=8bcf7900-d4544046-8bcef24f-0cc47a3003e8-6124ad41dd642d56&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3Avf
>> dmesg | grep mmc: https://protect2.fireeye.com/v1/url?k=66ce5f96-395566d0-66cfd4d9-0cc47a3003e8-b9768331cc0e4416&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3Ave
>> 
>> Here’s an SD (or eMMC) bootable image for an XU4 that exhibits the problem. You need to run “systemctl stop kodi” once the UART console is available else it attempts to run Kodi and Panfrost (the image is created for some Panfrost poking) currently wedges the board. Once the Kodi service is stopped “systemctl mask kodi” will prevent it from running again.
>> 
>> https://chewitt.libreelec.tv/testing/LibreELEC-Exynos.arm-10.0.0-odroid-xu4.img.gz
>> 
>> Kernel defconfig for the image: https://protect2.fireeye.com/v1/url?k=806156b6-dffa6ff0-8060ddf9-0cc47a3003e8-b2bec8fd0863dc1b&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fsprunge.us%2FG6uxty - basically the exynos config but with a wide variety of not-needed drivers (other SoCs, network cards, etc.) disabled.
>> 
>> The board is booting from u-boot 2020.04 in case that matters.
> 
> Thanks for sharing information. Sorry for replying late. I will check this problem on this week. 
> It needs to satisfy all exynos5 SoCs. I just wonder why not working fine according to eMMC modules.

No problem, I’ve been watching the thread :)

This is the module I’m using https://www.hardkernel.com/shop/8gb-emmc-module-h2/ .. I can probably organise one to be shipped to you if needed.

Christian

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-07  4:36         ` Christian Hewitt
@ 2021-10-07 11:05           ` Jaehoon Chung
  2021-10-20 11:14             ` Jaehoon Chung
  0 siblings, 1 reply; 14+ messages in thread
From: Jaehoon Chung @ 2021-10-07 11:05 UTC (permalink / raw)
  To: Christian Hewitt
  Cc: Krzysztof Kozlowski, linux-samsung-soc, Marian Mihailescu,
	Marek Szyprowski, Sylwester Nawrocki, Ulf Hansson

On 10/7/21 1:36 PM, Christian Hewitt wrote:
>>
>> On 7 Oct 2021, at 2:16 am, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>>
>> Hi,
>>
>> On 10/1/21 10:41 PM, Christian Hewitt wrote:
>>>
>>>> On 1 Oct 2021, at 4:40 am, Jaehoon Chung <jh80.chung@samsung.com> 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?
>>>
>>> The original report is against 5.14.0, but I see the same with 5.15-rc3
>>>
>>> dmesg: https://protect2.fireeye.com/v1/url?k=703ee5f5-2fa5dcb3-703f6eba-0cc47a3003e8-ad25e9061be78bbb&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3AuL
>>> dmesg | grep mmc: https://protect2.fireeye.com/v1/url?k=5d2277f1-02b94eb7-5d23fcbe-0cc47a3003e8-b778cb8e233bbe4b&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3AuO
>>>
>>> And if I pick that patch to my kernel branch all is good:
>>>
>>> dmesg: https://protect2.fireeye.com/v1/url?k=8bcf7900-d4544046-8bcef24f-0cc47a3003e8-6124ad41dd642d56&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3Avf
>>> dmesg | grep mmc: https://protect2.fireeye.com/v1/url?k=66ce5f96-395566d0-66cfd4d9-0cc47a3003e8-b9768331cc0e4416&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3Ave
>>>
>>> Here’s an SD (or eMMC) bootable image for an XU4 that exhibits the problem. You need to run “systemctl stop kodi” once the UART console is available else it attempts to run Kodi and Panfrost (the image is created for some Panfrost poking) currently wedges the board. Once the Kodi service is stopped “systemctl mask kodi” will prevent it from running again.
>>>
>>> https://protect2.fireeye.com/v1/url?k=b114ca54-ee8ff369-b115411b-0cc47a31309a-d8858f2897ed5521&q=1&e=addfcceb-9c68-4d7e-828c-344dd51262c2&u=https%3A%2F%2Fchewitt.libreelec.tv%2Ftesting%2FLibreELEC-Exynos.arm-10.0.0-odroid-xu4.img.gz
>>>
>>> Kernel defconfig for the image: https://protect2.fireeye.com/v1/url?k=806156b6-dffa6ff0-8060ddf9-0cc47a3003e8-b2bec8fd0863dc1b&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fsprunge.us%2FG6uxty - basically the exynos config but with a wide variety of not-needed drivers (other SoCs, network cards, etc.) disabled.
>>>
>>> The board is booting from u-boot 2020.04 in case that matters.
>>
>> Thanks for sharing information. Sorry for replying late. I will check this problem on this week. 
>> It needs to satisfy all exynos5 SoCs. I just wonder why not working fine according to eMMC modules.
> 
> No problem, I’ve been watching the thread :)
> 
> This is the module I’m using https://protect2.fireeye.com/v1/url?k=991de2ef-c686dbd2-991c69a0-0cc47a31309a-1b07f48d5f69f8e8&q=1&e=addfcceb-9c68-4d7e-828c-344dd51262c2&u=https%3A%2F%2Fwww.hardkernel.com%2Fshop%2F8gb-emmc-module-h2%2F .. I can probably organise one to be shipped to you if needed.

Thanks for sharing eMMC module information. I will order it. 

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

And When I have been checked the code, it seems that changing CLK_DIV value to 2 is not correct. (It's workaround to just work.)
Maybe, it seems that phase is not a proper value about its eMMC. (After getting eMMC module, I can check in more detail.)

Best Regards,
Jaehoon Chung

> 
> Christian
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: BUG: Cannot boot Odroid XU4 from eMMC without this patch
  2021-10-07 11:05           ` Jaehoon Chung
@ 2021-10-20 11:14             ` Jaehoon Chung
  0 siblings, 0 replies; 14+ messages in thread
From: Jaehoon Chung @ 2021-10-20 11:14 UTC (permalink / raw)
  To: Christian Hewitt
  Cc: Krzysztof Kozlowski, linux-samsung-soc, Marian Mihailescu,
	Marek Szyprowski, Sylwester Nawrocki, Ulf Hansson

Hi Chritian,

On 10/7/21 8:05 PM, Jaehoon Chung wrote:
> On 10/7/21 1:36 PM, Christian Hewitt wrote:
>>>
>>> On 7 Oct 2021, at 2:16 am, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>>>
>>> Hi,
>>>
>>> On 10/1/21 10:41 PM, Christian Hewitt wrote:
>>>>
>>>>> On 1 Oct 2021, at 4:40 am, Jaehoon Chung <jh80.chung@samsung.com> 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?
>>>>
>>>> The original report is against 5.14.0, but I see the same with 5.15-rc3
>>>>
>>>> dmesg: https://protect2.fireeye.com/v1/url?k=703ee5f5-2fa5dcb3-703f6eba-0cc47a3003e8-ad25e9061be78bbb&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3AuL
>>>> dmesg | grep mmc: https://protect2.fireeye.com/v1/url?k=5d2277f1-02b94eb7-5d23fcbe-0cc47a3003e8-b778cb8e233bbe4b&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3AuO
>>>>
>>>> And if I pick that patch to my kernel branch all is good:
>>>>
>>>> dmesg: https://protect2.fireeye.com/v1/url?k=8bcf7900-d4544046-8bcef24f-0cc47a3003e8-6124ad41dd642d56&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3Avf
>>>> dmesg | grep mmc: https://protect2.fireeye.com/v1/url?k=66ce5f96-395566d0-66cfd4d9-0cc47a3003e8-b9768331cc0e4416&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fix.io%2F3Ave
>>>>
>>>> Here’s an SD (or eMMC) bootable image for an XU4 that exhibits the problem. You need to run “systemctl stop kodi” once the UART console is available else it attempts to run Kodi and Panfrost (the image is created for some Panfrost poking) currently wedges the board. Once the Kodi service is stopped “systemctl mask kodi” will prevent it from running again.
>>>>
>>>> https://protect2.fireeye.com/v1/url?k=b114ca54-ee8ff369-b115411b-0cc47a31309a-d8858f2897ed5521&q=1&e=addfcceb-9c68-4d7e-828c-344dd51262c2&u=https%3A%2F%2Fchewitt.libreelec.tv%2Ftesting%2FLibreELEC-Exynos.arm-10.0.0-odroid-xu4.img.gz
>>>>
>>>> Kernel defconfig for the image: https://protect2.fireeye.com/v1/url?k=806156b6-dffa6ff0-8060ddf9-0cc47a3003e8-b2bec8fd0863dc1b&q=1&e=df3dbd0f-ccc7-40e0-b96a-1d47883a7f71&u=http%3A%2F%2Fsprunge.us%2FG6uxty - basically the exynos config but with a wide variety of not-needed drivers (other SoCs, network cards, etc.) disabled.
>>>>
>>>> The board is booting from u-boot 2020.04 in case that matters.
>>>
>>> Thanks for sharing information. Sorry for replying late. I will check this problem on this week. 
>>> It needs to satisfy all exynos5 SoCs. I just wonder why not working fine according to eMMC modules.
>>
>> No problem, I’ve been watching the thread :)
>>
>> This is the module I’m using https://protect2.fireeye.com/v1/url?k=991de2ef-c686dbd2-991c69a0-0cc47a31309a-1b07f48d5f69f8e8&q=1&e=addfcceb-9c68-4d7e-828c-344dd51262c2&u=https%3A%2F%2Fwww.hardkernel.com%2Fshop%2F8gb-emmc-module-h2%2F .. I can probably organise one to be shipped to you if needed.

I had been ordered above module, but it's different with yours.

This is mine. 

[    3.615140] mmcblk0: mmc0:0001 8GTF4R 7.28 GiB

Anyway, I found other eMMC module that can be reproduced this issue.
This issue is that host can't determine correct clock sampling value about some eMMC module.
exynos_get_bset_clksmp() function had been considered HS200 and HS104 at first time. 

commit c537a1c5ff63d3553617a9ff80ef5ed1493028e2
Author: Seungwon Jeon <tgih.jun@samsung.com>
Date:   Sat Aug 31 00:12:50 2013 +0900

    mmc: dw_mmc: exynos: add variable delay tuning sequence

    Implements variable delay tuning. In this change, exynos host can
    determine the correct sampling point for the HS200 and SDR104 speed mode.

So it seems that host needs to consider about HS400 mode.

I will post the fixing patch as soon as possible. At that time, I will cc'd you.

Best Regards,
Jaehoon Chung

> 
> Thanks for sharing eMMC module information. I will order it. 
> 
> 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
> 
> And When I have been checked the code, it seems that changing CLK_DIV value to 2 is not correct. (It's workaround to just work.)
> Maybe, it seems that phase is not a proper value about its eMMC. (After getting eMMC module, I can check in more detail.)
> 
> Best Regards,
> Jaehoon Chung
> 
>>
>> Christian
>>
> 
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-10-20 11:14 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).