[External] - Re: Issues with bcm2835-host: let firmware manage the clock divisor

[Peter Robinson]

On Mon, May 15, 2023 at 1:10 PM Vincent Fazio <vfazio at xes-inc.com> wrote:
>
> All
>
> > -----Original Message-----
> > From: Stefan Wahren <stefan.wahren at i2se.com>
> > Sent: Sunday, May 14, 2023 1:55 PM
> > To: Nuno Gonçalves <nunog at fr24.com>; u-boot at lists.denx.de; Vincent
> > Fazio <vfazio at xes-inc.com>; pbrobinson at gmail.com
> > Subject: [External] - Re: Issues with bcm2835-host: let firmware manage the
> > clock divisor
> >
> > Hi Nuno,
> >
> > Am 14.05.23 um 14:06 schrieb Nuno Gonçalves:
> > > Hi, after 85bdd28d2bb0827f311913e00e4e338f8e4e6565 (bcm2835-host: let
> > > firmware manage the clock divisor), Linux fails to start the eMMC
> > > memory on a CM3 most times (but it sometimes also works).
> >
> > thanks for your report.
> >
> > >
> > > I am using Linux mainline and I wonder if this assumes the change in
> > > which this was based also needs to be used in Linux?
> >
> > Yes, this is very likely. But how can U-Boot assume that at least Linux is
> > booting afterwards. How about the other OSes with devicetree support?
> >
>
> To be fair, I never tested with a linux kernel that was _not_ the RPi kernel, but I did test on test this on 3b+ and CM3.

We've included them in the Fedora builds since Spet 21 (2021.10 RC4)
and it fixed the issues around the MMC clocking when the firmware
changed. I've personally run it across most RPi platforms inc a CM3
device with upstream kernels with no issues and we've not had reports
from users there either.

> Feel free to revert; I honestly thought these patches died on the vine a year or more ago.

The was a lack of maintainer and I took that role over and went
through the back log of patches, I pulled this one in as it was one of
the ones we'd shipped with Fedora and it had fixed problems we had
back then, if they've been resolved in other ways as well since I
wasn't aware of. But that explains the lag in applying the patches.

> > >
> > > In that case I would think it's fair to revert until it comes to mainline.
> >
> > Actually from the original commit i wasn't able to see a real benefit from the
> > change. Shorter boot time?
>
> The purpose of this commit and the previous (0a36afa) was to work around an issue with a regression in RPi firmware [0]
>
> Since we couldn't guarantee what firmware payload was being used on an RPi or that RPF wouldn't make a similar change in the future, it was important to set the clock to something sane so mmc speeds didn't tank. The first commit in the series may have been the only necessary commit to work around the firmware regression, but I heard no negative responses on this list [1] nor on the related GH issue[2] where others tested them.
>
> [0] https://github.com/raspberrypi/firmware/issues/1619
> [1] https://lists.denx.de/pipermail/u-boot/2021-November/465992.html
> [2] https://github.com/raspberrypi/firmware/issues/1619#issuecomment-931750755
>
> >
> > >
> > > Thanks,
> > > Nuno
> > 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.
>