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

[Nuno Gonçalves]

On Tue, May 23, 2023 at 1:16 PM Stefan Wahren 
wrote:

> Because we stuck in this discussion, can you please provide more
> information to reproduce this issue?
>
> What is the exact behavior based on debug UART and LED when Linux fails
> to start from eMMC (timeout, SoC lockup, ...)?
>

Kernel says:

sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1)
Waiting for root device /dev/mmcblk0p3...
sdhost-bcm2835 3f202000.mmc: sdhost_busy_irq: intmask 0410

Other boot messages continue, but the rootfs is never found so eventually
it hangs.


>
> Does your boot setup (U-Boot) based on Device tree (Mainline or RPF) or
> EFI?
>
>
DT mainline with some aliases and __overrides__ for the firmware to set up
uart and watchdog.


> Which Raspberry firmware version are you using?
>

Buildroot default, 3f20b832b27cd730deb6419b570f31a98167eef6 (Jan 17, 2022)


> What settings of config.txt do you use?
>

arm_64bit=1
gpu_freq=250
gpu_mem=16
device_tree=bcm2837-rpi-cm3-io3.dtb
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
dtparam=uart0=off
dtparam=watchdog
kernel=u-boot.bin


>
> Are you able to reproduce this issue on other RPi variants?
>

I found the issue on the CM3 and CM3+.

In addition I tested the RPi 1 Model A and it is NOT affected.

Thanks

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

[Stefan Wahren]

Hi Nuno,

Am 15.05.23 um 10:13 schrieb Nuno Gonçalves:
On Sun, May 14, 2023 at 7:54 PM Stefan Wahren > wrote:


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?


I don't know what other OSes the patch author have tested it and if 
there was any good argument for breaking Linux Mainline.


sorry, the question wasn't actually for you, since you just reported the 
issue. There is never a good argument to break Linux Mainline, 
especially the Raspberry Pi folks don't support for U-Boot.


Because we stuck in this discussion, can you please provide more 
information to reproduce this issue?


What is the exact behavior based on debug UART and LED when Linux fails 
to start from eMMC (timeout, SoC lockup, ...)?


Does your boot setup (U-Boot) based on Device tree (Mainline or RPF) or EFI?

Which Raspberry firmware version are you using?

What settings of config.txt do you use?

Are you able to reproduce this issue on other RPi variants?

Best regards



Thanks,
Nuno

Re: [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  wrote:
>
> All
>
> > -Original Message-
> > From: Stefan Wahren 
> > Sent: Sunday, May 14, 2023 1:55 PM
> > To: Nuno Gonçalves ; u-boot@lists.denx.de; Vincent
> > Fazio ; pbrobin...@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.
>

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

[Vincent Fazio]

Stefan

> -Original Message-
> From: Stefan Wahren 
> Sent: Tuesday, May 16, 2023 12:54 AM
> To: Vincent Fazio ; Nuno Gonçalves
> ; u-boot@lists.denx.de; pbrobin...@gmail.com
> Subject: Re: [External] - Re: Issues with bcm2835-host: let firmware manage
> the clock divisor
> 
> Am 15.05.23 um 19:57 schrieb Vincent Fazio:
> > Stefan
> >
> >
> 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.
> 
> Okay, are you able to list the effected bootchains (starting from RPi firmware
> to Linux)?
> 
> Example for a bootchain:
> 
> RPi firmware -> U-Boot -> Linux

As far as I'm aware, the issue [0] documents :

RPi Firmware -> U-Boot
RPi Firmware -> EDK2
RPi Firmware -> Ultibo

I did not notice degraded performance in RPi Linux, presumably due to clock 
delegation [1]

If someone is using linux-stable vs RPi Linux, there may be some variation.

This was nearly 2 years ago however, I'm heavily relying on what's been 
documented in the GH issue [0].
 
[0] https://github.com/raspberrypi/firmware/issues/1619
[1] https://github.com/raspberrypi/firmware/issues/1619#issuecomment-917370376

-Vincent

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

[Stefan Wahren]

Am 15.05.23 um 19:57 schrieb Vincent Fazio:

Stefan


-Original Message-
From: Stefan Wahren 
Sent: Monday, May 15, 2023 11:35 AM
To: Vincent Fazio ; Nuno Gonçalves
; u-boot@lists.denx.de; pbrobin...@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 
Sent: Sunday, May 14, 2023 1:55 PM
To: Nuno Gonçalves ; u-boot@lists.denx.de; Vincent
Fazio ; pbrobin...@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.


Okay, are you able to list the effected bootchains (starting from RPi 
firmware to Linux)?


Example for a bootchain:

RPi firmware -> U-Boot -> Linux







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

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

[Vincent Fazio]

Stefan

> -Original Message-
> From: Stefan Wahren 
> Sent: Monday, May 15, 2023 11:35 AM
> To: Vincent Fazio ; Nuno Gonçalves
> ; u-boot@lists.denx.de; pbrobin...@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 
> >> Sent: Sunday, May 14, 2023 1:55 PM
> >> To: Nuno Gonçalves ; u-boot@lists.denx.de; Vincent
> >> Fazio ; pbrobin...@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.
> >

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

[Stefan Wahren]

Hi Vincent,

Am 15.05.23 um 14:10 schrieb Vincent Fazio:

All


-Original Message-
From: Stefan Wahren 
Sent: Sunday, May 14, 2023 1:55 PM
To: Nuno Gonçalves ; u-boot@lists.denx.de; Vincent
Fazio ; pbrobin...@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?




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

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

[Vincent Fazio]

All

> -Original Message-
> From: Stefan Wahren 
> Sent: Sunday, May 14, 2023 1:55 PM
> To: Nuno Gonçalves ; u-boot@lists.denx.de; Vincent
> Fazio ; pbrobin...@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.

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

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

[Nuno Gonçalves]

On Sun, May 14, 2023 at 7:54 PM Stefan Wahren 
wrote:

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

I don't know what other OSes the patch author have tested it and if there
was any good argument for breaking Linux Mainline.

Thanks,
Nuno

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

[Stefan Wahren]

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?




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?




Thanks,
Nuno

Issues with bcm2835-host: let firmware manage the clock divisor

[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).

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?

In that case I would think it's fair to revert until it comes to mainline.

Thanks,
Nuno