Date: Mon, 31 Oct 2022 08:36:01 -0700 From: Mark Millard <marklmi@yahoo.com> To: Juraj Lutter <otis@freebsd.org> Cc: "uboot@freebsd.org" <uboot@FreeBSD.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: sysutils/rpi-firmware update Message-ID: <4693B4BF-4E8A-41BD-B5E1-6398A6BA3E43@yahoo.com> In-Reply-To: <4A881278-6206-482D-97E4-BE15D7DCB298@FreeBSD.org> References: <82FEA78C-96BC-4B6B-AB90-2CF521250FA8@FreeBSD.org> <A804CF4F-39EB-4673-A931-F4C5DB34C7AC@yahoo.com> <4A881278-6206-482D-97E4-BE15D7DCB298@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Oct-31, at 06:15, Juraj Lutter <otis@freebsd.org> wrote: >=20 > On 31 Oct 2022, at 12:20, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >> On 2022-Oct-31, at 01:17, Juraj Lutter <otis@freebsd.org> wrote: >>=20 >>> what should be done to update sysutils/rpi-firmware to the recent = version? >>> I=E2=80=99ve tried to naively update the PORTVERSION but I=E2=80=99ve = not been able to boot (I only tried one time) the RPI-4-B. >>=20 >> To my knowledge, no one is actively working on support of the >> RPi* related code base in FreeBSD. >>=20 >=20 > Good to know. Can I help somehow? Not a question I can answer. >> It is not clear what you are looking to make work observably >> differently by updating just the RPi* firmware to more recent >> than FreeBSD officially supports. >>=20 >=20 > The problem I=E2=80=99m observing is: = https://files.wilbury.net/s/A7jWesNiHQ7GM9e FYI: from earlier of my 2022-APr messages about the .dtb handling: https://lists.freebsd.org/archives/freebsd-arm/2022-April/001279.html The tracebacks look similar to yours. Look like I misremembered the panic text though. An example was: panic: vm_fault failed: ffff000000862134 (not near the null pointer). A failure was handling: QUOTE > mmc@7e300000 { > compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; > . . . > dma@7e007000 { > compatible =3D "brcm,bcm2835-dma"; > . . . > mmcnr@7e300000 { > compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; > . . . > dma@7e007b00 { > compatible =3D "brcm,bcm2711-dma"; END QUOTE by doing bcm_dma_allocate before the bcm_dma_probe/bcm_dma_attach. Earlier .dtb's had: QUOTE > dma@7e007000 { > compatible =3D "brcm,bcm2835-dma"; > . . . > mmc@7e300000 { > compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; > . . . > mmcnr@7e300000 { > compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; > . . . > dma@7e007b00 { > compatible =3D "brcm,bcm2711-dma"; END QUOTE which happens to have define-before-use order for what the kernel does. As far as I could tell, .dtb's are not required to have define-before-use order for such. So, if I got that right, the kernel was supposed to handle the ordering. You might have an option of making your own .dtb variant that avoids the FreeBSD kernel mishandling: You might be able to set up an always defined-before-use .dtb variant. > My initial approach was to make use of DHT20 sensor that I=E2=80=99ve = got. > It is an i2c-connected (compared to GPIO-connected DHT11/DHT22) = sensor. Your activity here is well outside my knowledge base. But others on the arm list likely have the background knowledge. > So one of the first things I did was to take i2c-sensor.dtbo from the > recent rpi-firmware ( There is no i2c-sensor in 20210805 version of = firmware, > that=E2=80=99s why I took the recent version), decompiled dtbo to dts, = added AHT10/AHT20 > lines (similar to = https://github.com/raspberrypi/linux/commit/c20376da5e61323410d1ffb076db1a= e818ccbf59), > compiled back to dtbo, only to find out that the device is not = recognized at all. >=20 > It did not appear even in devinfo. >=20 > So i=E2=80=99ve also added fragments for DHT10 and DHT20, then the = devices at least appeared in > devinfo output (the device is seemingly marketed as AHT20 but present = itself as DHT20 on the bus). >=20 > Then I=E2=80=99ve written a =E2=80=9Cstub=E2=80=9D driver, just to = test whether it will at least probe and attach (and it did!) :-) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4693B4BF-4E8A-41BD-B5E1-6398A6BA3E43>