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