Hi Vincent On 11/11/21 1:45 AM, Vincent Fazio wrote: > Ivan, > >> -----Original Message----- >> From: Ivan T. Ivanov <iiva...@suse.de> >> Sent: Wednesday, November 10, 2021 4:01 AM >> To: Vincent Fazio <vfa...@xes-inc.com> >> Cc: Mario Lombardo <m...@akamo.de>; u-boot@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 <vfa...@xes-inc.com> >>> To: Mario Lombardo <m...@akamo.de>, "u-boot@lists.denx.de" >>> <u-boot@lists.denx.de> >>> Subject: RE: [External] - Slow MMC IO with Raspberry CM3+ Module >>> Message-ID: >>> >> <BN1P110MB09373DD94630D64646C46DF69F8C9@BN1P110MB0937.NAMP11 >> 0.PROD.OUT >>> LOOK.COM> >> Tags: all uboot >> >> Hi Vincent, >> >>> >>> Mario, >>> >>>> -----Original Message----- >>>> From: U-Boot <u-boot-boun...@lists.denx.de> On Behalf Of Mario >>>> Lombardo >>>> Sent: Wednesday, November 3, 2021 5:40 AM >>>> To: u-boot@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 >
