From nobody Tue Jan 16 16:43:07 2024 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 4TDvvn0tgjz57ZxM for ; Tue, 16 Jan 2024 16:43:17 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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 4TDvvm23mpz4ZcR for ; Tue, 16 Jan 2024 16:43:16 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rabson-org.20230601.gappssmtp.com header.s=20230601 header.b=ThhMjrBX; dmarc=none; spf=pass (mx1.freebsd.org: domain of dfr@rabson.org designates 2607:f8b0:4864:20::1132 as permitted sender) smtp.mailfrom=dfr@rabson.org Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-5ec7a5a4b34so105621717b3.0 for ; Tue, 16 Jan 2024 08:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1705423395; x=1706028195; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NqDBYIe7jEaj1GrXE5W/VrLHeJoKScT/xDu5vrbqyDw=; b=ThhMjrBXqMqgYkygv3p4Ph1WhStYlHpwXu5ZpnH4gPRk6Cm4esaA8/hwEygID4Z3dv cVYrEBJ9QWQfrEV3gvr/ppBDbxlwD0DdkrXzNIqJD5K7heNnTWDZqoU2wn61E9CN1VhQ mYysVoJ84jXVhu9ntJaqcv0ON/WSu5Al/SnK0E6wHO0p9YZ4JRd6Gf4AFbLfkHkPGE8b XHPINOrqZlJi+ZMrZGYDGDKNFutSBbSrnWObLFxc8NQFZ1Sh6zFDoCHdRWNNxBb68VO9 aaexZIhFhOVJLkz2wS7xyQtkJgD45PXvyagcJVR6IOFqfOjyX6sdj5i12tAo7er8YKB5 o9yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705423395; x=1706028195; 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=NqDBYIe7jEaj1GrXE5W/VrLHeJoKScT/xDu5vrbqyDw=; b=BK5beUu7xNBeFg0/e55QOIuURd9JDATQ2Hru4ZOcSvLr/I+xkvESfvR/h+hQaRHrIB AnLEDzCrSeyDrvA7Js79/prRfUQBu0CXolesc6GYUT+vYUvRouK66fnfkRxnvpu0Co+l veIB/qScB0Qvozu0RWluetKAUU/bGYXb8cNloBXqicv75qhJAstzNnlgsXmz4RMrjoyQ CC1NoZvsIoPlztsrfkZdYvGNP9tVPCcbGtXCAfDaO8p7pFU4Whn3aRFXkX69WYqZ7VTL wgxWWFNNhKpiFGEF/arYCR3jEQIHQjypDELd49DEnrvpR6FlgWQBi8dty8FecbXIzp84 rGBw== X-Gm-Message-State: AOJu0Ywg6r7ifkuIeNAm686OIK8AfWjbfwgHU5ta35uQIX9pVrReAe1c NwuHO2UP+WqmpzScp0XwdR3CWHEHEygwVgvspGxCpyZb5r/QWg== X-Google-Smtp-Source: AGHT+IEJcE0llrsYIq6+5pBEWGA7axp5hZV51ZJXwP7zM9Pu4nwAHLb1jGQ70zpsHXCx4MqeLdsX1zHWjUxiQpxqD24= X-Received: by 2002:a81:4419:0:b0:5fb:8d5:e418 with SMTP id r25-20020a814419000000b005fb08d5e418mr6257570ywa.4.1705423395378; Tue, 16 Jan 2024 08:43:15 -0800 (PST) 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: <5a39810c-5fd8-4969-a222-2561b050b035@FreeBSD.org> <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> <76FA010A-338F-4E32-B381-37C7BA63CAFC@yahoo.com> <1C02D1FA-5BF0-4C82-AD0E-6F9E5EB8A0B9@karels.net> <20240116173205.41b4e0ebaacc42581a0d408d@bidouilliste.com> In-Reply-To: From: Doug Rabson Date: Tue, 16 Jan 2024 16:43:07 +0000 Message-ID: Subject: Re: When will FreeBSD support RPI5? To: Emmanuel Vadot Cc: Mike Karels , Mark Millard , FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000ad1349060f12d33d" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[rabson-org.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[dfr]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from]; FREEMAIL_CC(0.00)[karels.net,yahoo.com,freebsd.org]; DMARC_NA(0.00)[rabson.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[rabson-org.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4TDvvm23mpz4ZcR --000000000000ad1349060f12d33d Content-Type: text/plain; charset="UTF-8" On Tue, 16 Jan 2024 at 16:36, Doug Rabson wrote: > > > On Tue, 16 Jan 2024 at 16:32, Emmanuel Vadot > wrote: > >> On Tue, 16 Jan 2024 14:57:40 +0000 >> Doug Rabson wrote: >> >> > On Sat, 13 Jan 2024 at 19:05, Mike Karels wrote: >> > >> > > On 13 Jan 2024, at 12:32, Mark Millard wrote: >> > > >> > > > On Jan 13, 2024, at 07:38, Doug Rabson wrote: >> > > > >> > > >> Getting back to the RPI 5, with a tweak to >> > > arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config the >> same as >> > > RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci >> controllers as >> > > generic, I can boot to multiuser mode using the EDK2 firmware from >> > > https://github.com/worproject/rpi5-uefi with ACPI/Device Tree mode >> set to >> > > Both. >> > > > >> > > > What does FreeBSD do with "Both"? Does it actually use some ACPI >> > > > and some Device Tree? Or does it just use ACPI? Does your >> > > > combination do anything different than just using ACPI? >> > > > >> > > >> This does not have working PCIe or ethernet yet - I think ethernet >> > > ought to work since we seem to have a matching driver in the tree in >> > > dev/cadence. >> > > > >> > > > Sounds like the same status as booting just ACPI with no such >> > > > adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ? >> > > > >> > > > I think Mike Karels plans on investigating getting Ethernet >> > > > going based on cgem . I've no clue if this is ACPI, DeviceTree, >> > > > or both. >> > > >> > > The cadence/cgem driver uses FDT. I haven't looked at details yet. >> The >> > > addition >> > > might be as simple as adding a compat string. Hopefully it doesn't >> > > require major >> > > surgery. I just ordered an RPi 5 (8 GB); it will take a while to be >> > > delivered. >> > > >> > >> > The existing driver has the correct compat string but we don't get that >> far >> > since the rp1 node doesn't get probed and attached. This node is nested >> > under pcie@120000 and the whole subtree never gets explored. >> Interestingly, >> > if I hack the 2711 driver a little (based on reading Linux sources), I >> can >> > get that to attach and the rp1 southbridge is visible on the PCI bus >> with >> > vendor id 0x1de4, device id 0x0001. I made a stub driver for it but that >> > isn't particularly helpful since we need an FDT device to get simplebus >> to >> > attach and discover all the rp1 sub-devices. >> >> Why is there FDT children under a pci device ??? >> > > That's a very good question and I don't have an answer. This is just how > the DTB is structured: > > pcie@120000 { > > compatible = "brcm,bcm2712-pcie"; > ... > rp1 { > > compatible = "simple-bus"; > > My best guess is that it needs to be under the pcie@120000 so that its ranges field can work properly? --000000000000ad1349060f12d33d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 16 Jan 2024 at 16:36, Doug Ra= bson <dfr@rabson.org> wrote:


On Tue, 16 Ja= n 2024 at 16:32, Emmanuel Vadot <manu@bidouilliste.com> wrote:
On Tue, 16 Jan 2024 14:57:40 +0000
Doug Rabson <dfr@rab= son.org> wrote:

> On Sat, 13 Jan 2024 at 19:05, Mike Karels <mike@karels.net> wrote:
>
> > On 13 Jan 2024, at 12:32, Mark Millard wrote:
> >
> > > On Jan 13, 2024, at 07:38, Doug Rabson <dfr@rabson.org> wrote:
> > >
> > >> Getting back to the RPI 5, with a tweak to
> > arm/broadcom/bcm2835bcm2835_vcbus.c to treat the memory config th= e same as
> > RPI 4 and to dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci contr= ollers as
> > generic, I can boot to multiuser mode using the EDK2 firmware fro= m
> > https://github.com/worproject/rpi5-uefi with AC= PI/Device Tree mode set to
> > Both.
> > >
> > > What does FreeBSD do with "Both"? Does it actually= use some ACPI
> > > and some Device Tree? Or does it just use ACPI? Does your > > > combination do anything different than just using ACPI?
> > >
> > >> This does not have working PCIe or ethernet yet - I thin= k ethernet
> > ought to work since we seem to have a matching driver in the tree= in
> > dev/cadence.
> > >
> > > Sounds like the same status as booting just ACPI with no suc= h
> > > adjustments too bcm2835bcm2835_vcbus.c or sdhci_fdt.c ?
> > >
> > > I think Mike Karels plans on investigating getting Ethernet<= br> > > > going based on cgem . I've no clue if this is ACPI, Devi= ceTree,
> > > or both.
> >
> > The cadence/cgem driver uses FDT.=C2=A0 I haven't looked at d= etails yet.=C2=A0 The
> > addition
> > might be as simple as adding a compat string.=C2=A0 Hopefully it = doesn't
> > require major
> > surgery.=C2=A0 I just ordered an RPi 5 (8 GB); it will take a whi= le to be
> > delivered.
> >
>
> The existing driver has the correct compat string but we don't get= that far
> since the rp1 node doesn't get probed and attached. This node is n= ested
> under pcie@120000 and the whole subtree never gets explored. Interesti= ngly,
> if I hack the 2711 driver a little (based on reading Linux sources), I= can
> get that to attach and the rp1 southbridge is visible on the PCI bus w= ith
> vendor id 0x1de4, device id 0x0001. I made a stub driver for it but th= at
> isn't particularly helpful since we need an FDT device to get simp= lebus to
> attach and discover all the rp1 sub-devices.

=C2=A0Why is there FDT children under a pci device ???

That's a very good question and I don't have an ans= wer. This is just how the DTB is structured:

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pcie@120000 {

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 compatible =3D "brcm,bcm2712-pcie";
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 rp1 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 comp= atible =3D "simple-bus";


My best guess is that it needs to be under the= pcie@120000 so that its ranges field can work properly?
=C2=A0
--000000000000ad1349060f12d33d--