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

On 13 Aug 2023, at 11:10, Mark Millard wrote:

> On Aug 13, 2023, at 08:17, Warner Losh <imp@bsdimp.com> wrote:
>
>> Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists.
>
> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no compatible
>
> is the fix that Manu has committed:
>
> QUOTE
>     ofw_firmware: Only match if there is no compatible
>
>     If there is a compatible string it likely means that the firmware needs
>     a dedicated driver (like on RPI*).
>
>     PR:     273087
>     Tested-by:      Mark Millard <marklmi26-fbsd@yahoo.com>
>     Sponsored by:   Beckhoff Automation GmbH & Co. KG
>     Fixes:          fdfd3a90b6ce ("ofw: Add a ofw_firmware driver")
> END QUOTE

Just for completeness: that change fixes the bcm2835_cpufreq0/powerd
problem and the gpioled0 problem, but not the clk_fixed2 problem
(clk_fixed4 on rpi4).  Installing an msdos boot partition from the
3 Aug image makes that problem disappear.

		Mike

> Also, FreeBSD does not use the linux DTS Files for RPi* 's. They do
> not produce matches to the *.dtb 's that FreeBSD does use: FreeBSD
> uses RPi* *.dtb files that are in the RPi* firmware releases. Those
> RPI* firmware releases (and *.dtb's) are gotten from:
>
> WWW=            https://github.com/raspberrypi/firmware
>
> via the sysutils/rpi-firmware port.

>>
>> 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
>>>
>>>
>>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com