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. > > 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 http://www.xes-inc.com
