[External] - Slow MMC IO with Raspberry CM3+ Module

[Jaehoon Chung]

Hi Vincent

On 11/11/21 1:45 AM, Vincent Fazio wrote:
> Ivan,
> 
>> -----Original Message-----
>> From: Ivan T. Ivanov <iivanov at suse.de>
>> Sent: Wednesday, November 10, 2021 4:01 AM
>> To: Vincent Fazio <vfazio at xes-inc.com>
>> Cc: Mario Lombardo <ml at akamo.de>; u-boot at lists.denx.de
>> Subject: Re: [External] - Slow MMC IO with Raspberry CM3+ Module
>>
>> On 11-03 20:57, Vincent Fazio wrote:
>>> Date: Wed, 3 Nov 2021 20:57:13 +0000
>>> From: Vincent Fazio <vfazio at xes-inc.com>
>>> To: Mario Lombardo <ml at akamo.de>, "u-boot at lists.denx.de"
>>>  <u-boot at lists.denx.de>
>>> Subject: RE: [External] - Slow MMC IO with Raspberry CM3+ Module
>>> Message-ID:
>>>
>> <BN1P110MB09373DD94630D64646C46DF69F8C9 at BN1P110MB0937.NAMP11
>> 0.PROD.OUT
>>> LOOK.COM>
>> Tags: all uboot
>>
>> Hi Vincent,
>>
>>>
>>> Mario,
>>>
>>>> -----Original Message-----
>>>> From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Mario
>>>> Lombardo
>>>> Sent: Wednesday, November 3, 2021 5:40 AM
>>>> To: u-boot at lists.denx.de
>>>> Subject: [External] - Slow MMC IO with Raspberry CM3+ Module
>>>>
>>>> Dear u-boot list,
>>>>
>>>> I recently compiled (latest: 2021.10) code of uboot as a boot loader
>>>> for the Compute Module 3+ (Raspberry). Everything works fine except
>> one issue:
>>>> the IO from the storage is extreme slow. I read about issues in the
>>>> past related to ext file systems. However the present issue relates
>>>> to both ext and fat file systems so I assume its cause is different.
>>>
>>> Please see this series:
>>> https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fpat
>>>
>> chwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D262375&am
>> p;da
>>>
>> ta=04%7C01%7C%7Ca736ee7a8d7446c34adb08d9a430fdf3%7C2925f1cdbdc34
>> a76bb3
>>>
>> 86159e20a17f1%7C0%7C0%7C637721352603649117%7CUnknown%7CTWFpb
>> GZsb3d8eyJ
>>>
>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>> 7C1000
>>>
>> &sdata=4snQV571x4aGlf7NwXnR%2B%2F5RgkyZ2MOMax%2FudbP6xu
>> w%3D&re
>>> served=0 And this RPi issue:
>>> https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fgit
>>>
>> hub.com%2Fraspberrypi%2Ffirmware%2Fissues%2F1619&data=04%7C0
>> 1%7C%7
>>>
>> Ca736ee7a8d7446c34adb08d9a430fdf3%7C2925f1cdbdc34a76bb386159e20a1
>> 7f1%7
>>>
>> C0%7C0%7C637721352603659112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>> MC4wLjAwMD
>>>
>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
>> das1
>>> lOBGq%2BMDOz7OlqbEbyBS9eXtrp7W5SQ25VteYLk%3D&reserved=0
>>
>> Are your patches still needed? If I read the comments on the issue it was
>> fixed in RPi firmware and your workaround is not needed, correct?
> 
> I think this is a fair question.
> 
> The patches are still needed for certain tagged versions of the RPi firmware. 
> Later tags may resolve this problem but may also introduce their own regressions which
> force users back to a previous tag where this is a problem.
> 
> I think I would recommend including the patches so U-Boot works across all revisions of 
> firmware and to future proof against subsequent changes in the clock API. 
> 
> Ultimately, I defer to the maintainers' choice.

Sorry, I missed your patch. I will test with your patch on today. 
I think that it's good to apply yours if there is no side-effect or any problem.

Best Regards,
Jaehoon Chung

> 
>>
>> Regards,
>> Ivan
>>
>> CAUTION: This email originated from outside of the organization. Do not click
>> links or open attachments unless you recognize the sender and know the
>> content is safe.
> 
> Vincent Fazio
> Embedded Software Engineer - ATS
> Extreme Engineering Solutions, Inc
> https://protect2.fireeye.com/v1/url?k=71bc6382-2e275aad-71bde8cd-0cc47a31cdf8-745f5150d097619e&q=1&e=53bc8cca-5f48-44c6-ba88-35540558f2d6&u=http%3A%2F%2Fwww.xes-inc.com%2F
>