Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B]

Manu just updated Linux DTS in the tree. Maybe see if you revert that if
the problem persists.

Warner

On Sun, Aug 13, 2023, 12:12 AM titus <titus@edc.ro> wrote:

> the failed devices are all linked to raspberrypi,bcm2835-firmware
> (gpio, cpufreq_dt,…) which does not see to be probed / attached
> check fdt ls at the loader prompt and ofwdump -a
> and boot -v
> and nm /boot/kernel/kernel|grep bcm2835_firmware_get_revision
> > On 13 Aug 2023, at 07:25, Mark Millard <marklmi@yahoo.com> wrote:
> >
> > On Aug 12, 2023, at 17:42, Mike Karels <mike@karels.net> wrote:
> >
> >> I booted 14.0-ALPHA1 on a Raspberry Pi 3B+.  It boots and runs, but
> there
> >> are some rough edges that probably indicate things that are broken.
> During
> >> the boot, there are 56 occurrences of this sequence:
> >>
> >> clk_fixed2: <Fixed clock> disabled on ofwbus0
> >> clk_fixed2: Cannot FDT parameters.
> >> device_attach: clk_fixed2 attach returned 6
> >
> > The large count is from a small number of examples. Each
> > internal scan repeats the messages for each example,
> > unless eventually found. I learned this when I had
> > something being looked for too early, before the
> > definition was added to match up with. Everything worked
> > because of the retries eventually finding things after
> > they had been added, but it produced lots of messages
> > first. But, in that case, there was material to find.
> >
> > The RPi4B's get clk_fixed4's instead, with a similar
> > overall count. For the RPi4B the cause is the
> > "fixed-clock" material below (from a diff of .dts
> > files produced from the .dtb files):
> >
> > -       cam1_reg {
> > +       cam0_clk {
> >
> > +               #clock-cells = <0x0>;
> > +               compatible = "fixed-clock";
> > +               status = "disabled";
> > +       };
> > +       cam0_regulator {
> > +
> >                compatible = "regulator-fixed";
> >                enable-active-high;
> > -               gpio = <0xa 0x5 0x0>;
> > -               regulator-name = "cam1-reg";
> > +               regulator-name = "cam0-reg";
> >                status = "disabled";
> >        };
> > +       cam1_clk {
> > +
> > +               #clock-cells = <0x0>;
> > +               compatible = "fixed-clock";
> > +               status = "disabled";
> > +       };
> > +       cam1_regulator {
> > +
> > +               compatible = "regulator-fixed";
> > +               enable-active-high;
> > +               gpio = <0xb 0x5 0x0>;
> > +               regulator-name = "cam1-reg";
> > +               status = "okay";
> > +       };
> >
> > I doubt that cam0_clk and cam1_clk are ever added to later
> > find, as stands, making every scan report the 2 fixed-clock
> > references each time.
> >
> > This is something that I reported on on the lists back on
> > 2022-Apr-30. But it was mixed with a crash report that
> > turned out to be a separate issue (and was fixed some time
> > ago).
> >
> > It would be possible to decompile the .dtb used for RPi3B+'s
> > to see if cam?_clk fixed-clock's are present.
> >
> >> Two other failures:
> >>
> >> bcm2835_cpufreq0: <CPU Frequency Control> on cpu0
> >> bcm2835_cpufreq0: Unable to find firmware device
> >> device_attach: bcm2835_cpufreq0 attach returned 6
> >> gpioled0: <GPIO LEDs> on ofwbus0
> >> gpioled0: <PWR> failed to map pin
> >
> > Those are more than noise messages.
> >
> >> The red LED that's on when the system is halted stays on after boot; not
> >> sure if that's related to the last item.
> >>
> >> Looks like the kernel needs adjustments to correspond with the new DTB.
> >>
> >> I'll append the full dmesg.boot.
> > . . .
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> >
> >
>
>
>