Re: sysutils/rpi-firmware update

On 2022-Oct-31, at 06:15, Juraj Lutter <[email protected]> wrote:
> 
> On 31 Oct 2022, at 12:20, Mark Millard <[email protected]> wrote:
>> 
>> On 2022-Oct-31, at 01:17, Juraj Lutter <[email protected]> wrote:
>> 
>>> what should be done to update sysutils/rpi-firmware to the recent version?
>>> I’ve tried to naively update the PORTVERSION but I’ve not been able to boot (I only tried one time) the RPI-4-B.
>> 
>> To my knowledge, no one is actively working on support of the
>> RPi* related code base in FreeBSD.
>> 
> 
> 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.
>> 
> 
> The problem I’m 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 = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci";
> . . .
>                dma@7e007000 {
>                        compatible = "brcm,bcm2835-dma";
> . . .
>                mmcnr@7e300000 {
>                        compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci";
> . . .
>                dma@7e007b00 {
>                        compatible = "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 = "brcm,bcm2835-dma";
> . . .
>                mmc@7e300000 {
>                        compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci";
> . . .
>                mmcnr@7e300000 {
>                        compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci";
> . . .
>                dma@7e007b00 {
>                        compatible = "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’ve 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’s why I took the recent version), decompiled dtbo to dts, added AHT10/AHT20
> lines (similar to https://github.com/raspberrypi/linux/commit/c20376da5e61323410d1ffb076db1ae818ccbf59),
> compiled back to dtbo, only to find out that the device is not recognized at all.
> 
> It did not appear even in devinfo.
> 
> So i’ve 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).
> 
> Then I’ve written a “stub” driver, just to test whether it will at least probe and attach (and it did!) :-)




===
Mark Millard
marklmi at yahoo.com