From nobody Sun Aug 13 15:17:21 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP1Nw05VRz4Tvwm for ; Sun, 13 Aug 2023 15:17:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP1Nv4b48z3fYq for ; Sun, 13 Aug 2023 15:17:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-4fe934c4decso4513254e87.1 for ; Sun, 13 Aug 2023 08:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691939853; x=1692544653; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Z0x1hRHb5KJoy19xmBtTapXWvr029UkYJz51edq8fG0=; b=EhM8cTlCKJ9D0+zPQcfgEPxhbZ8wdeA8qa9Sc9MIV/g8EubPxLE4lgCgyK43u85rK9 4+TVaEHJNn3GWKksSqHvsWYgWPwDXkTZYm6Gr99wb2KbYumvX7X+daE4TfNmMYE1x386 vh5LmOSrB4pWNNdpFXwmDXdoODz1sjUsQd/qNzG3VFfh03Xi5CVt4opKT3WK/DvUMMif hCgnx5/ZrCsHl90FzvG+Fu6SO5tIF1di4bLJP1lBM/Ki20MQTQBbiJ/1fyxYlR0XR2KM H757BvZWiATZDap5jn6/nUXHZeZKtKRn11/xy30NdiaJXyww4RVR9HtbVEmgHSTZ3HI/ MKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691939853; x=1692544653; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Z0x1hRHb5KJoy19xmBtTapXWvr029UkYJz51edq8fG0=; b=GOw55lfpeCzvyweevO2Of7KVxrKo5fV+KbB8984LKRzQ5ELGb04+uorkw3zPXiblLs UdPhj1HPWcnMbfQRfV5tQWy2W6EOTLGbhSOE/mBfPtH8MeNhgGwg+qMWsqZX0fVhUWBZ +tm1IndwuyuIlecetTFKfKiQ3CRJpdoenhVPVihPUp4ez0kF2ME9Iysb27sWfa2FDL6p nLyz3JMkWb0RtP+jkQ2ipVJkHivVK0BtWXTGFQlZJJEJ+ZeGIN8A+BtgXmhoNsoz5tAV u82NpP8eSZWi/BHaK4roHtROXaJmoDTZ2SgqdmJhwzeePOAkwTbF3awV15CMIcIAehjF pV/A== X-Gm-Message-State: AOJu0YxhjpyXNR+7FWX0ndqTeumx+JYyPTynes3xJHrUvVByilsppjiT TFPBqowArVYIisfkzzgOAe+5COP2SB7vfV4c5XY0qA== X-Google-Smtp-Source: AGHT+IHP7wpfFwlWFRFVuOM1Z/PzId4XcQhkuI4RIzNoFCXgzi8elryrm4IwTL+T0CJdgW+C7NIoVIFL0et6lj2hT6U= X-Received: by 2002:a05:6512:3101:b0:4fd:d078:2e3f with SMTP id n1-20020a056512310100b004fdd0782e3fmr4254385lfb.42.1691939853186; Sun, 13 Aug 2023 08:17:33 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> In-Reply-To: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> From: Warner Losh Date: Sun, 13 Aug 2023 09:17:21 -0600 Message-ID: Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] To: titus Cc: Mark Millard , Mike Karels , freebsd-arm Content-Type: multipart/alternative; boundary="000000000000ee5db50602cf71f1" X-Rspamd-Queue-Id: 4RP1Nv4b48z3fYq X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000ee5db50602cf71f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > the failed devices are all linked to raspberrypi,bcm2835-firmware > (gpio, cpufreq_dt,=E2=80=A6) 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 wrote: > > > > On Aug 12, 2023, at 17:42, Mike Karels 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: 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 =3D <0x0>; > > + compatible =3D "fixed-clock"; > > + status =3D "disabled"; > > + }; > > + cam0_regulator { > > + > > compatible =3D "regulator-fixed"; > > enable-active-high; > > - gpio =3D <0xa 0x5 0x0>; > > - regulator-name =3D "cam1-reg"; > > + regulator-name =3D "cam0-reg"; > > status =3D "disabled"; > > }; > > + cam1_clk { > > + > > + #clock-cells =3D <0x0>; > > + compatible =3D "fixed-clock"; > > + status =3D "disabled"; > > + }; > > + cam1_regulator { > > + > > + compatible =3D "regulator-fixed"; > > + enable-active-high; > > + gpio =3D <0xb 0x5 0x0>; > > + regulator-name =3D "cam1-reg"; > > + status =3D "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: on cpu0 > >> bcm2835_cpufreq0: Unable to find firmware device > >> device_attach: bcm2835_cpufreq0 attach returned 6 > >> gpioled0: on ofwbus0 > >> gpioled0: 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; n= ot > >> 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. > > . . . > > > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > > > > > > > --000000000000ee5db50602cf71f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Manu just updated Linux DTS in the tree. Maybe see if you= revert that if the problem=C2=A0persists.=C2=A0

Warner

On Sun, Aug 13, 2023, 12:12 AM titus <titus@edc.ro> wrote:
the failed devices are all linked to raspberrypi,bcm2= 835-firmware
(gpio, cpufreq_dt,=E2=80=A6) 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> wr= ote:
>
> On Aug 12, 2023, at 17:42, Mike Karels <mike@karels.net> wrote:=
>
>> I booted 14.0-ALPHA1 on a Raspberry Pi 3B+.=C2=A0 It boots and run= s, but there
>> are some rough edges that probably indicate things that are broken= .=C2=A0 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):
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0cam1_reg {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cam0_clk {
>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#clock-cells = =3D <0x0>;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible =3D= "fixed-clock";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status =3D &qu= ot;disabled";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cam0_regulator {
> +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 compatible =3D = "regulator-fixed";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enable-active-h= igh;
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gpio =3D <0= xa 0x5 0x0>;
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regulator-name= =3D "cam1-reg";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regulator-name= =3D "cam0-reg";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 status =3D &quo= t;disabled";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 };
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cam1_clk {
> +
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#clock-cells = =3D <0x0>;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible =3D= "fixed-clock";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status =3D &qu= ot;disabled";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cam1_regulator {
> +
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible =3D= "regulator-fixed";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable-active-= high;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gpio =3D <0= xb 0x5 0x0>;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regulator-name= =3D "cam1-reg";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status =3D &qu= ot;okay";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
>
> 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.
> . . .
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>
>


--000000000000ee5db50602cf71f1--