Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)

On 2020-Oct-9, at 18:08, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:

>> Am 10.10.2020 um 02:39 schrieb Mark Millard <[email protected]>:
>> ……
>> ...
>> No use is made of FreeBSD’s sys/gnu/dts/arm64/broadcom/ by this technique.

From the log for one of my builds of sysutils/rpi-firmware :
( I ignore armstub8*.bin related things. )

===>  License BROADCOM accepted by the user
. . .
=> Attempting to fetch https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=/raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz
. . .
===>  Extracting for rpi-firmware-1.20200723.g20200723
=> SHA256 Checksum OK for raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz.
. . .
===>  Patching for rpi-firmware-1.20200723.g20200723
cp -f /usr/ports/sysutils/rpi-firmware/files/config.txt /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/
cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi_0_w.txt /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/
cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/
cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/
cp -f /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/
/bin/rm -f /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/kernel.img
/bin/rm -f /wrkdirs/usr/ports/sysutils/rpi-firmware/work/firmware-2042453/boot/kernel7.img
. . .

So, if you want to see what sysutils/rpi-firmware is currently based on,
you can try that:

fetch https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=/raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz

yourself and then look at the content of the .tar.gz produced.

When I try it:

fetch https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=/raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz
fetch: https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=/raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz: size of remote file is not known
raspberrypi-firmware-1.20200723.g20200723-2042         177 MB 8136 kBps    22s

# tar -tf raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz | more
firmware-2042453/
firmware-2042453/.github/
firmware-2042453/.github/ISSUE_TEMPLATE/
firmware-2042453/.github/ISSUE_TEMPLATE/bug_report.md
firmware-2042453/README.md
firmware-2042453/boot/
firmware-2042453/boot/COPYING.linux
firmware-2042453/boot/LICENCE.broadcom
firmware-2042453/boot/bcm2708-rpi-b-plus.dtb
firmware-2042453/boot/bcm2708-rpi-b.dtb
firmware-2042453/boot/bcm2708-rpi-cm.dtb
firmware-2042453/boot/bcm2708-rpi-zero-w.dtb
firmware-2042453/boot/bcm2708-rpi-zero.dtb
firmware-2042453/boot/bcm2709-rpi-2-b.dtb
firmware-2042453/boot/bcm2710-rpi-2-b.dtb
firmware-2042453/boot/bcm2710-rpi-3-b-plus.dtb
firmware-2042453/boot/bcm2710-rpi-3-b.dtb
firmware-2042453/boot/bcm2710-rpi-cm3.dtb
firmware-2042453/boot/bcm2711-rpi-4-b.dtb
firmware-2042453/boot/bootcode.bin
firmware-2042453/boot/fixup.dat
firmware-2042453/boot/fixup4.dat
firmware-2042453/boot/fixup4cd.dat
firmware-2042453/boot/fixup4db.dat
firmware-2042453/boot/fixup4x.dat
firmware-2042453/boot/fixup_cd.dat
firmware-2042453/boot/fixup_db.dat
firmware-2042453/boot/fixup_x.dat
firmware-2042453/boot/kernel.img
. . .
firmware-2042453/boot/overlays/wittypi.dtbo
firmware-2042453/boot/start.elf
firmware-2042453/boot/start4.elf
firmware-2042453/boot/start4cd.elf
firmware-2042453/boot/start4db.elf
firmware-2042453/boot/start4x.elf
firmware-2042453/boot/start_cd.elf
firmware-2042453/boot/start_db.elf
firmware-2042453/boot/start_x.elf
. . .

(I'll not list it all.)

The .tar.gz provides the .dtb files directly., no compilation
needed.

The .tar.gz contains lots of unused files and directories
as well as the ones to be put on RPi* media.


> Seems to be unclear(at least to me), whether ever used or never
> ...while absolutely possible that you`re  right here.

> ` have discussed that with Rob Crowston & Mike Karels some time ago, 
> The problem was the bcm2711-rpi-4-b.dtb , which at that time shouldn’t be changed because to stay compatible with the 8GB-model.,
> so possibly since then there never was a newer dts compiled to dtb.

The fetch command picks out a specific commit and ignores more
recent commits (until the Makefile and distinfo are changed to
cause and check the results of a different fetch command).

> But I  G U E S S(still can’t resist;-) that we now have to patch&compile( at least bcm2711-rpi-4-b)  to stay in touch with 2020.10
> 
>> Am 10.10.2020 um 02:21 schrieb Mark Millard <marklmi at yahoo.com>:
>> My FreeBSD USB3 SSD is partitioned as:……..
>> After that it tries to boot from ethernet (which was
>> not connected).
> 
> Tomorrow I will look again exactly with which partition tables I booted the SSD, 
> for today I am completely dizzy from all that rpi-dtb stuff , I can’t remember what I did :-)






===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"