From nobody Sat Jan 13 15:38:06 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 4TC2c95xp2z57ldN for ; Sat, 13 Jan 2024 15:38:17 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 4TC2c85KpXz4Sh5 for ; Sat, 13 Jan 2024 15:38: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=t22gYM02; dmarc=none; spf=pass (mx1.freebsd.org: domain of dfr@rabson.org designates 2607:f8b0:4864:20::b34 as permitted sender) smtp.mailfrom=dfr@rabson.org Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-dbed729a51eso6404999276.0 for ; Sat, 13 Jan 2024 07:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1705160296; x=1705765096; 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=gTKN+W8CIKF+1z3rRrOsbGxVbiOw/oOhw4+scY4pW7E=; b=t22gYM02leAlVe2kMhVYXAwLzRurOtEFnxg/2nl9Y2yEbwypl0zBSqbRLa4ZFf67Go qywgUXIGPoRfig4MEEi98KL0lc6Cw/AG5NEChar18RGgMB/Ch7d/cIgvZvakJQ8klzBM eg5dv0KpXF3Uscgj8Jl/7suQMkHjKf9w0q7Gh2bbDCxen4mbubkxZ+ZnMLrNMSPb/Wot k1aCqD4VBVDpDoQI+Pxrqnhx6usJr0X1DjGFdsLNTgvTnYNn8lKO19q3inTgUesvnPg/ DaseTEszR5IBqK3nXVQLez3/oIwtnI98fl9pdgp1Y1Vi+jLGqKq6SHoBWJ310pFoNcUC 4Yew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705160296; x=1705765096; 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=gTKN+W8CIKF+1z3rRrOsbGxVbiOw/oOhw4+scY4pW7E=; b=JSxjS6ciHkmuuMrF/gkmcNkc8Y7Upifid8JbgqHOHFQ075f5tm/JXsVzAXKcwPMUX1 I6jaLY1PUPoyZzHQR7As/aD5cy+X/b0U6LxUqR3HOm+rvwPNgsmUN4fQWd84do3fLDLh X2kjjtEhIc5OxaHO/XYpnIDFnY0lBPSFr1fZcNABnnSEIZtHpzO9ZKYSszodg8+oJazF 2U28fKWZET9yPWaFWyhOMkarFVlwGLLSy3RhMeaWFjpejMiGm5V0tyV9U1XcnsyU4G6s mjiUhUul5oVcT/CDrKi1ANydQq4cmn9LBf5TjtWENBJ6Jvu+z9s/8IEpZKgZXUyn9yZL h7Fw== X-Gm-Message-State: AOJu0YzGCu9YJtOl3wNYibqKMHKQ9k7xeMId4Y5jg0183q+J4k7kV2Nd f6sV8yCDghD+3rT4JzZa1aKow5WC6+vRjOy1y/Uu0bwZqTf5oA== X-Google-Smtp-Source: AGHT+IGZYy+XrzTiZHnvf7lyIIknsLewXNc/Vtuf1uvgWPUWEFJV1qFQeWSz1hwl6iw3ZqKjuqzPGzM9Bnhv0QkBjwI= X-Received: by 2002:a25:9085:0:b0:db9:5b19:4852 with SMTP id t5-20020a259085000000b00db95b194852mr1419824ybl.50.1705160295706; Sat, 13 Jan 2024 07:38: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> In-Reply-To: <347FE009-A470-4765-A9B9-7C9AB5E954DA@yahoo.com> From: Doug Rabson Date: Sat, 13 Jan 2024 15:38:06 +0000 Message-ID: Subject: Re: When will FreeBSD support RPI5? To: Mark Millard Cc: Jesper Schmitz Mouridsen , John Kennedy , ykla , FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000b6018c060ed59102" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,phouka.net,gmail.com]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[rabson.org]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[rabson-org.20230601.gappssmtp.com:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b34:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEFALL_USER(0.00)[dfr]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4TC2c85KpXz4Sh5 --000000000000b6018c060ed59102 Content-Type: text/plain; charset="UTF-8" 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. 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. Doug. On Thu, 11 Jan 2024 at 18:09, Mark Millard wrote: > On Jan 11, 2024, at 08:56, Mark Millard wrote: > > > On Jan 11, 2024, at 08:20, Doug Rabson wrote: > > > >>> On Thu, 11 Jan 2024 at 01:30, Mark Millard wrote: > >>> (While I normally use FreeBSD's U-Boot type of context, > >>> My builds do have patches to allow RPi4B EDK2 use to > >>> avoid the problems that I know to test for.) > >> > >> I'm curious how you were able to boot FreeBSD on rpi4 with EDK2 - I > tried with both the FreeBSD package as well as the latest release from > github. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 > gets a little further but also hangs before reaching single user mode. I'm > wondering if perhaps I should use the dtbs from sysutils/rpi-firmware > rather than the ones from sysutils/edk2@rpi4. > > > > It has been a while since I last tested booting based on > > a EDK2-based release from https://github.com/pftf/RPi4/ . > > It looks like v1.35 is from 2023-Jun-05. At some point > > I'll (re?-)try it. > > > > I used the same style of having EDK2 on a microsd card and > > booting my normal USB3 media. The RPi4B is configured to > > first try the microsd card slot (usually empty for me) and > > then to try USB. I do set things up in EDK2 for serial > > console use as primary. (I only rarely connect video to > > the RPi*'s that I have access to. Mostly I ssh to them over > > ethernet and otherwise use the serial console.) > > > > I've access to RPi4B Rev 1.1, 1.4, and 1.5 examples, > > a mix of 4 GiByte and 8 GiByte. > > > > I've never used sysutils/edk2@rpi4 to boot as far as I > > remember. My EDK2 activity started long before that > > existed and I did not switch. > > > > The RPPi4B EDK2-based releases that I've used were from: > > > > https://github.com/pftf/RPi4/releases/ > > > > But there are many releases that I've never tried. > > > > I do use patches to avoid some reliability > > problems with USB file I/O . The reliability > > problems never interfered with booting and were > > only systematically reproducible via generating huge > > files. But the problems were originally notice via > > buildworld/buildkernel oddities that involved > > randomly corrupted files, but not many. The problems > > are FreeBSD bugs/incompletenesses in an area not used > > with most UEFI/ACPI contexts that FreeBSD supports. > > > > I found my v1.35 microsd card from the last time I tried. > > I had forgotten that the boot attempts now get a FreeBSD > panic (seen via serial console use): > > panic: ram_attach: resource 5 failed to attach > cpuid = 0 > time = 1 > KDB: stack backtrace: > #0 0xffff00000050f450 at kdb_backtrace+0x58 > #1 0xffff0000004ba930 at vpanic+0x19c > #2 0xffff0000004ba790 at panic+0x44 > #3 0xffff00000086e7c0 at ram_attach+0x1ac > #4 0xffff0000004fba88 at device_attach+0x3f8 > #5 0xffff0000004fdce8 at bus_generic_new_pass+0x120 > #6 0xffff0000004fdc78 at bus_generic_new_pass+0xb0 > #7 0xffff000000500450 at root_bus_configure+0x40 > #8 0xffff00000042b600 at mi_startup+0xdc > #9 0xffff0000000008ac at virtdone+0x70 > > It is a FreeBSD problem, not an EDK2 problem. My old > notes on the lists about the FreeBSD problem are at: > > > https://lists.freebsd.org/archives/freebsd-current/2023-September/004775.html > > I do not know if v1.34 might sidestep the mishandling > in FreeBSD or not. > > === > Mark Millard > marklmi at yahoo.com > > --000000000000b6018c060ed59102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Getting back to the RPI 5, with a tweak to arm/broadcom/bc= m2835bcm2835_vcbus.c to treat the memory config the same as RPI 4 and to=C2= =A0dev/sdhci/sdhci_fdt.c to treat the RPI 5 sdhci controllers as generic, I= can boot to multiuser mode using the EDK2 firmware from=C2=A0https://github.com/worproject/rpi5-u= efi with ACPI/Device Tree mode set to Both. 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=C2=A0dev/cadence.

Doug= .

On Thu, 11 Jan 2024 at 18:09, Mark Millard <marklmi@yahoo.com> wrote:
= On Jan 11, 2024, at 08:56, Mark Millard <marklmi@yahoo.com> wrote:

> On Jan 11, 2024, at 08:20, Doug Rabson <dfr@rabson.org> wrote:
>
>>> On Thu, 11 Jan 2024 at 01:30, Mark Millard <marklmi@yahoo.com> wrote: >>> (While I normally use FreeBSD's U-Boot type of context, >>> My builds do have patches to allow RPi4B EDK2 use to
>>> avoid the problems that I know to test for.)
>>
>> I'm curious how you were able to boot FreeBSD on rpi4 with EDK= 2 - I tried with both the FreeBSD package as well as the latest release fro= m github. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 g= ets a little further but also hangs before reaching single user mode. I'= ;m wondering if perhaps I should use the dtbs from sysutils/rpi-firmware ra= ther than the ones from sysutils/edk2@rpi4.
>
> It has been a while since I last tested booting based on
> a EDK2-based release from https://github.com/pftf/RPi4/ .
> It looks like v1.35 is from 2023-Jun-05. At some point
> I'll (re?-)try it.
>
> I used the same style of having EDK2 on a microsd card and
> booting my normal USB3 media. The RPi4B is configured to
> first try the microsd card slot (usually empty for me) and
> then to try USB. I do set things up in EDK2 for serial
> console use as primary. (I only rarely connect video to
> the RPi*'s that I have access to. Mostly I ssh to them over
> ethernet and otherwise use the serial console.)
>
> I've access to RPi4B Rev 1.1, 1.4, and 1.5 examples,
> a mix of 4 GiByte and 8 GiByte.
>
> I've never used sysutils/edk2@rpi4 to boot as far as I
> remember. My EDK2 activity started long before that
> existed and I did not switch.
>
> The RPPi4B EDK2-based releases that I've used were from:
>
> https://github.com/pftf/RPi4/releases/
>
> But there are many releases that I've never tried.
>
> I do use patches to avoid some reliability
> problems with USB file I/O . The reliability
> problems never interfered with booting and were
> only systematically reproducible via generating huge
> files. But the problems were originally notice via
> buildworld/buildkernel oddities that involved
> randomly corrupted files, but not many. The problems
> are FreeBSD bugs/incompletenesses in an area not used
> with most UEFI/ACPI contexts that FreeBSD supports.
>

I found my v1.35 microsd card from the last time I tried.

I had forgotten that the boot attempts now get a FreeBSD
panic (seen via serial console use):

panic: ram_attach: resource 5 failed to attach
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff00000050f450 at kdb_backtrace+0x58
#1 0xffff0000004ba930 at vpanic+0x19c
#2 0xffff0000004ba790 at panic+0x44
#3 0xffff00000086e7c0 at ram_attach+0x1ac
#4 0xffff0000004fba88 at device_attach+0x3f8
#5 0xffff0000004fdce8 at bus_generic_new_pass+0x120
#6 0xffff0000004fdc78 at bus_generic_new_pass+0xb0
#7 0xffff000000500450 at root_bus_configure+0x40
#8 0xffff00000042b600 at mi_startup+0xdc
#9 0xffff0000000008ac at virtdone+0x70

It is a FreeBSD problem, not an EDK2 problem. My old
notes on the lists about the FreeBSD problem are at:

https://lists.freebsd.o= rg/archives/freebsd-current/2023-September/004775.html

I do not know if v1.34 might sidestep the mishandling
in FreeBSD or not.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--000000000000b6018c060ed59102--