Am 15.05.23 um 19:57 schrieb Vincent Fazio:
Stefan
-----Original Message-----
From: Stefan Wahren <stefan.wah...@i2se.com>
Sent: Monday, May 15, 2023 11:35 AM
To: Vincent Fazio <vfa...@xes-inc.com>; Nuno Gonçalves
<nu...@fr24.com>; 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 <stefan.wah...@i2se.com>
Sent: Sunday, May 14, 2023 1:55 PM
To: Nuno Gonçalves <nu...@fr24.com>; u-boot@lists.denx.de; Vincent
Fazio <vfa...@xes-inc.com>; 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.
