From nobody Sun Jan 08 04:01:27 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 4NqNgC5tjDz2p2dG for ; Sun, 8 Jan 2023 04:01:43 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 4NqNgC39Blz4PKW for ; Sun, 8 Jan 2023 04:01:43 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id i15so7761566edf.2 for ; Sat, 07 Jan 2023 20:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=NM5D1EoYPUUzvvPbp/QJFGMA078jFhJQiyV6nAhX6fg=; b=YwIyeFIDtCTJGx0up4jLi3naj/xKLITAC7un0WZ35XcCLTa5yd1HTrCGzgBsi7P4SR zG/QCkAj10tYc4FdXyINGeJt2l/nMZDgaanUAP7EQtFzhbgkVbQrrOitLhvBsrNvm9cC fxTv/P3xz1s2xmIX3O0WsFfrNvKQ9kVRdi3v046vHgg4Gbz0OVK9ra3tyHrrLSLYumEs Hob605izDAcojp5p+YANkboixfyjiktXybWjvxYjF5RltVTMvHMptCW5m1sQxro9nhpL LBnR8tRWzOdMqqafWC0/hbrrsTdyFPuzgpzYjg1ghGddENKnBhJqnED3Wd+EGAhfAp7V JkAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NM5D1EoYPUUzvvPbp/QJFGMA078jFhJQiyV6nAhX6fg=; b=inMWzOiCNrdXLJbgBOpYJsX1LOMOyMDPqKPTGcPWHiZnvuZo2L9iFUa35gDjT7TTb2 I8na3SqKMc5Yw8L4bl53P9dKGxh4moM+RlO3lz2S8VV1NVrxSzN1yKjOxB+c7mBMbOeI cySjBQExBDdn3UqN9oTYV9b2aU/q9h034Bt5CH4eX7BpMo1dmcp9phv/GhfwgiQF4taH bQQFt4Izx/U8zb9HIj7um/w68gDMboD0ilsqNRY7ae+/yFiM9T0HgqPRKtj7VX68q5rF PZM4cP1UfLe4K/NKSIuI1uZg1iG/AbISl5fwOFy4NH9pZ6SZge2AIjzq8hn3HO23tIXZ j9hA== X-Gm-Message-State: AFqh2kpMUPAUhbmiH4fBXUf36tmRQsQtoxW/0A2iAjjqiYJCFt5Agr/Z 5qvdCbqXAhU9U0bXb7pjWmE= X-Google-Smtp-Source: AMrXdXvdT44J2sHVNK46zV5/EKS9+X4QLV/g3g1cOpFXeQc8kZTPHJi3I9B/03k5ylh+SwsZR0/m9A== X-Received: by 2002:aa7:d04e:0:b0:45c:835b:ac4d with SMTP id n14-20020aa7d04e000000b0045c835bac4dmr52351870edo.8.1673150500314; Sat, 07 Jan 2023 20:01:40 -0800 (PST) Received: from smtpclient.apple (dynamic-046-114-060-191.46.114.pool.telefonica.de. [46.114.60.191]) by smtp.googlemail.com with ESMTPSA id d26-20020a50f69a000000b0046c7c3755a7sm2133374edn.17.2023.01.07.20.01.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Jan 2023 20:01:39 -0800 (PST) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware Date: Sun, 8 Jan 2023 05:01:27 +0100 References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com> <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com> <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com> <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com> To: Mark Millard , freebsd-arm@freebsd.org In-Reply-To: <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com> Message-Id: <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com> X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4NqNgC39Blz4PKW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > Am 25.12.2022 um 04:15 schrieb Mark Millard : >=20 > The example context used below has: serial console with > USB3 SSD boot media (not requiring a usb_pgood_delay > setting), booting a stable/13. The RPI4B is a C0T one (no > 3 GiByte limitation, for example: the PCIe wrapper logic > has been corrected). O.K., Mark, I=C2=B4ve tried to read your 4b-related reports of the last = period more closely..=20 And now I=E2=80=99m a bit confused : I tried now : <> on USB3 SSD media 4b B0T - device directly from a current img.xz and = couldn=E2=80=99t determine any problems with bcm_dma or pcie, I don=E2=80=99t own a 4b C0T, just the C0T CM4, where my pcie-bug-report = stays unpatched since 1 year, It needs an extended JTAG- investigation, it cannot be fixed by = firmware, it has to happen in the driver logic. The CM4 is my personal problem, it=E2=80=99s not a supported device (has = also devmatch issues on booting), but I can live with that on working emmc& working genet0.. The 4b(including C0T) is a supported device(is it?) and=20 if I understand you right : Your 4b C0T crashes (at least sometimes) by failing in dma-computation. And you have a valid fix for the 4b C0T ? =E2=80=A6 While I unfortunately cannot test 4b C0T, it=20 sounds that if you can fix it, it=E2=80=99s a must have fix for that = device? Side note: have you tried fixing pcie@7d500000 : in the dts without = changing start4.elf and the likes? Is that 4b C0T bug based on start4.elf or the dts or whatever? For my devices the EARLY_DRIVER_ would do nothing but spam dmesg with = new firmware, it can=E2=80=99t fix dma on the CM4 and=20 Is not needed for the 4b B0T... but is your 4b C0T fix based on your EARLY_DRIVER_MODULE -patch, even = without touching any firmware? If so, you have to give it to Phabricator ;-) Thanks for your effort, Regards K. > Am 08.01.2023 um 01:59 schrieb Mark Millard : >>=20 >>=20 >>=20 > Am 25.12.2022 um 04:15 schrieb Mark Millard : >=20 > The example context used below has: serial console with > USB3 SSD boot media (not requiring a usb_pgood_delay > setting), booting a stable/13. The RPI4B is a C0T one (no > 3 GiByte limitation, for example: the PCIe wrapper logic > has been corrected). >=20 > On Jan 7, 2023, at 10:58, Klaus K=C3=BCchemann = wrote: >=20 >>=20 >>> Am 07.01.2023 um 11:18 schrieb Mark Millard : >>>=20 >>>=20 >>> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6= ... >>>>>=20 >>>>>=20 >>>>> stable/13's source code changes are ( similarly for >>>>> releng/13.1 ): >>>>>=20 >>>>> # git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c >>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c = b/sys/arm/broadcom/bcm2835/bcm2835_dma.c >>>>> index cab8639bb607..6d521d6dcace 100644 >>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c >>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c >>>>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D { >>>>>=20 >>>>> static devclass_t bcm_dma_devclass; >>>>>=20 >>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, = bcm_dma_devclass, 0, 0); >>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, = bcm_dma_devclass, >>>>> + 0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE); >>>>> MODULE_VERSION(bcm_dma, 1); >>>>>=20 >>>>>=20 >>>>> main's [so: 14's] source code changes are: >>>>>=20 >>>>> # git -C /usr/main-src/ diff = sys/arm/broadcom/bcm2835/bcm2835_dma.c >>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c = b/sys/arm/broadcom/bcm2835/bcm2835_dma.c >>>>> index 5f9ecb0b7981..d901447df1e9 100644 >>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c >>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c >>>>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D { >>>>> sizeof(struct bcm_dma_softc), >>>>> }; >>>>>=20 >>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0); >>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0, >>>>> + BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE); >>>>> MODULE_VERSION(bcm_dma, 1); >>>>>=20 >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>>=20 >>=20 >>=20 >> =E2=80=A6=E2=80=A6.on the other hand : if your = EARLY_DRIVER_MODULE(bcm_dma=E2=80=A6 doesn=E2=80=99t do anything wrong, >> you could give it in phabricator review, why not?!.. >=20 > Yep, once I've better evidence from the RPi*'s that I have > access to. >=20 > I'll note that no vintages of the following .dtb files are > in the current sysutils/rpi-firmware port: >=20 > bcm2709-rpi-cm2.dtb > bcm2710-rpi-zero-2-w.dtb > bcm2710-rpi-zero-2.dtb > bcm2711-rpi-cm4s.dtb >=20 > I've no direct evidence of if any vintage of any of these > would end up hitting the bcm_dma issue or not. But I expect > that the EARLY_DRIVER_MODULE related patching would avoid > (just!) that specific crash problem if it would otherwise > would occur. >=20 > There is: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261147 >=20 > reporting the absence of bcm2710-rpi-zero-2-w.dtb . So > someone might want to experiment with more recent RPi* > firmware, possibly even to develop some level of support > for bcm2710-rpi-zero-2-w.dtb (live Device Tree possibly > adjusted by the RPi* firmware) --if changes are needed. >=20 > The .dtb vintage and the RPi* start*.efi and the like > vintages are not necessarily fully independent. Mixing > and matching could be a problem, independent of any > additional FreeBSD kernel-related issues. (It is another > example of the poor level of documentation for the RPi* > context.) >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com