Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B]
- Reply: Mark Millard : "Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B]"
- In reply to: titus : "Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B]"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 13 Aug 2023 15:17:21 UTC
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 > > > > > > >