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

titus <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
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 <[email protected]> wrote:
> 
> On Aug 12, 2023, at 17:42, Mike Karels <[email protected]> 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
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.