From nobody Tue Jan 16 16:36:40 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 4TDvmM004gz57ZbS for ; Tue, 16 Jan 2024 16:36:50 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) (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 4TDvmL4wjSz4Yxm for ; Tue, 16 Jan 2024 16:36:50 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-5edbcdc323dso94262257b3.3 for ; Tue, 16 Jan 2024 08:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1705423009; x=1706027809; 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=HtTOPBBqS/YOEf3fkz25r8S6TwDWHAJAmqzlLFHmSjI=; b=2jFAvxv1i/aH/lp9b35rWccteWbic8x46sAlq0yLzQrL6gStDyKnGGutRkOUF65lv5 nshUulQ+4HRpfoft2ovYeNgYtMH1sWMcqA90H7r7UzoOzJERwlPL5Wez4uWLKFLJYXB4 we0bH/OTnIR/q/hn/F5t9r9/LxZ81sa3ijvmz+UGlYOIbb/qsaNRJsyFbsSaBKkPYl7f bDQKrF3zU/OXhtsTC5vFypS/fSC+SiMWvMSIT2elde3hkijA8IcCeUlTKXBlfw75dQBN KcflOKLD4bKE0z9ay3qY0VVy7nl1nP8QhbUKdEZCTtVxAPD2qaBuq/pp2yHUjGqe2UaM 8a4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705423009; x=1706027809; 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=HtTOPBBqS/YOEf3fkz25r8S6TwDWHAJAmqzlLFHmSjI=; b=DmPW6NSSSmLJyAcB/RrDE//U83SMfofDnlxDrs+n4PZeW+fOGC3e6UYn48/KlDbkEo aHkxTlYQ1m6NQOHgtckmmB4WRx4uMlEwl4Eh0xmY9tQXFKpwcppHrGK8O2kE4r91ZULt 3y1O2CNg9L15aQ1/dc+U+bkn7fHzGy1CmScfrUREBXM23ePG33/2dv561I0Yti3SzCL2 nRoTBbr7AGeAIWwPrMJjTk9S7tyZ7EYU7KeYxRtjv+Us2sVpd24O30+Tk4XJdXxvRbus 9U6191VD6PhmiVMW7/6q4U4k5PSjXfpBTxIduw0B/tONW/bgJXvy8GCMdY1BxoFG58wN sRtw== X-Gm-Message-State: AOJu0YwdQBZaH80kzde1IhU5G/lFtXD2t0tHDAmbouvj+SPranMSbHwr 7rJ7X2DzfCLePb/1kG1Hqsbo98C7Nt53fTz5Uu5HA+lEJNgRaA== X-Google-Smtp-Source: AGHT+IFT52hCDzHmf6mCaFq6XxRvkcc7xYM9IV/oQLryv0pBLOhkes1hABrOjhWFM3PUtmFZjPav3/zPMICygS0lMPw= X-Received: by 2002:a81:c409:0:b0:5f7:74bf:9525 with SMTP id j9-20020a81c409000000b005f774bf9525mr5314236ywi.53.1705423008853; Tue, 16 Jan 2024 08:36:48 -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: <20240116173205.41b4e0ebaacc42581a0d408d@bidouilliste.com> From: Doug Rabson Date: Tue, 16 Jan 2024 16:36:40 +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="000000000000a282b4060f12bcbf" X-Rspamd-Queue-Id: 4TDvmL4wjSz4Yxm 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:2607:f8b0::/32, country:US] --000000000000a282b4060f12bcbf Content-Type: text/plain; charset="UTF-8" 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"; --000000000000a282b4060f12bcbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 16 Jan 2024 at 16:32, Emmanue= l Vadot <manu@bidouilliste.com<= /a>> 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";
=C2=A0
--000000000000a282b4060f12bcbf--