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

[Vincent Fazio]

Stefan

> -----Original Message-----
> From: Stefan Wahren <stefan.wahren at i2se.com>
> Sent: Monday, May 15, 2023 11:35 AM
> To: Vincent Fazio <vfazio at xes-inc.com>; Nuno Gonçalves
> <nunog at fr24.com>; u-boot at lists.denx.de; pbrobinson at gmail.com
> Subject: Re: [External] - Re: Issues with bcm2835-host: let firmware manage
> the clock divisor
> 
> Hi Vincent,
> 
> Am 15.05.23 um 14:10 schrieb Vincent Fazio:
> > 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.
> >
> > Feel free to revert; I honestly thought these patches died on the vine a
> year or more ago.
> >
> >>>
> >>> 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.
> 
> thanks for clarifying. So the regression occured only in EFI and not in Device
> Tree / OF use case?

I'm not sure I understand the question here re DT/OF. The "regression" in the RPi firmware was noticed both in EDK2 and in U-Boot when reading from the SD card. The regression was _not_ apparent in RPi Linux, at least from what I recall from my testing at the time, meaning that whatever the RPi Linux kernel was doing was working around the issue, which is probably why the regression happened in the first place since U-Boot/EDK2 are not targets for support from RPF.

> 
> >
> > [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-
> 93175
> > 0755
> >
> >>
> >>>
> >>> 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.
> >