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