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