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

[Vincent Fazio]

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.

> 
> 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