Date: Fri, 9 Oct 2020 18:54:06 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-ID: <5B658E5E-C438-4A05-99F5-8E4B67A89488@yahoo.com> In-Reply-To: <A4434A74-1D46-4372-9936-E794410C128B@yahoo.com> References: <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B.ref@yahoo.com> <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B@yahoo.com> <ABE16EA6-49F1-461F-9B8A-6DAA7ED6A18D@googlemail.com> <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <B3133D77-FA24-4F42-B529-D0B56F48E790@yahoo.com> <CCEEC0AD-B874-4753-AAA1-B3B5B302A30C@googlemail.com> <E82AE086-837C-4CEA-92D5-78A39412F964@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> <7CB99D94-6F37-4150-9D1B-9488D4FE83EF@googlemail.com> <A4434A74-1D46-4372-9936-E794410C128B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-9, at 18:46, Mark Millard <marklmi at yahoo.com> wrote: > On 2020-Oct-9, at 18:08, Klaus Cucinauomo <maciphone2 at = googlemail.com> wrote: >=20 >>> Am 10.10.2020 um 02:39 schrieb Mark Millard <marklmi@yahoo.com>: >>> =E2=80=A6=E2=80=A6 >>> ... >>> No use is made of FreeBSD=E2=80=99s sys/gnu/dts/arm64/broadcom/ by = this technique. >=20 > =46rom the log for one of my builds of sysutils/rpi-firmware : > ( I ignore armstub8*.bin related things. ) >=20 > =3D=3D=3D> License BROADCOM accepted by the user > . . . > =3D> Attempting to fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz > . . . > =3D=3D=3D> Extracting for rpi-firmware-1.20200723.g20200723 > =3D> SHA256 Checksum OK for = raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz. > . . . > =3D=3D=3D> 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/kernel= 7.img > . . . >=20 > So, if you want to see what sysutils/rpi-firmware is currently based = on, > you can try that: >=20 > fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz >=20 > yourself and then look at the content of the .tar.gz produced. >=20 > When I try it: >=20 > fetch = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz > fetch: = https://codeload.github.com/raspberrypi/firmware/tar.gz/2042453?dummy=3D/r= aspberrypi-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 >=20 > # tar -tf raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz = | more > . . . > . . . >=20 > (I'll not list it all.) >=20 > The .tar.gz provides the .dtb files directly., no compilation > needed. >=20 > The .tar.gz contains lots of unused files and directories > as well as the ones to be put on RPi* media. A better listing would have shown dates and such: # tar -tvf raspberrypi-firmware-1.20200723.g20200723-2042453_GH0.tar.gz = | more drwxrwxr-x 0 root root 0 Nov 22 2019 firmware-2042453/ drwxrwxr-x 0 root root 0 Nov 22 2019 = firmware-2042453/.github/ drwxrwxr-x 0 root root 0 Nov 22 2019 = firmware-2042453/.github/ISSUE_TEMPLATE/ -rw-rw-r-- 0 root root 2147 Nov 22 2019 = firmware-2042453/.github/ISSUE_TEMPLATE/bug_report.md -rw-rw-r-- 0 root root 1255 Nov 22 2019 = firmware-2042453/README.md drwxrwxr-x 0 root root 0 Nov 22 2019 firmware-2042453/boot/ -rw-rw-r-- 0 root root 18693 Nov 22 2019 = firmware-2042453/boot/COPYING.linux -rw-rw-r-- 0 root root 1594 Nov 22 2019 = firmware-2042453/boot/LICENCE.broadcom -rw-rw-r-- 0 root root 24201 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-b-plus.dtb -rw-rw-r-- 0 root root 23938 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-b.dtb -rw-rw-r-- 0 root root 23719 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-cm.dtb -rw-rw-r-- 0 root root 24379 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-zero-w.dtb -rw-rw-r-- 0 root root 23643 Nov 22 2019 = firmware-2042453/boot/bcm2708-rpi-zero.dtb -rw-rw-r-- 0 root root 25265 Nov 22 2019 = firmware-2042453/boot/bcm2709-rpi-2-b.dtb -rw-rw-r-- 0 root root 25394 Nov 22 2019 = firmware-2042453/boot/bcm2710-rpi-2-b.dtb -rw-rw-r-- 0 root root 27054 Nov 22 2019 = firmware-2042453/boot/bcm2710-rpi-3-b-plus.dtb -rw-rw-r-- 0 root root 26435 Nov 22 2019 = firmware-2042453/boot/bcm2710-rpi-3-b.dtb -rw-rw-r-- 0 root root 25249 Nov 22 2019 = firmware-2042453/boot/bcm2710-rpi-cm3.dtb -rw-rw-r-- 0 root root 40659 Nov 22 2019 = firmware-2042453/boot/bcm2711-rpi-4-b.dtb -rw-rw-r-- 0 root root 52304 Nov 22 2019 = firmware-2042453/boot/bootcode.bin -rw-rw-r-- 0 root root 6744 Nov 22 2019 = firmware-2042453/boot/fixup.dat -rw-rw-r-- 0 root root 6193 Nov 22 2019 = firmware-2042453/boot/fixup4.dat -rw-rw-r-- 0 root root 3089 Nov 22 2019 = firmware-2042453/boot/fixup4cd.dat -rw-rw-r-- 0 root root 9181 Nov 22 2019 = firmware-2042453/boot/fixup4db.dat -rw-rw-r-- 0 root root 9183 Nov 22 2019 = firmware-2042453/boot/fixup4x.dat -rw-rw-r-- 0 root root 2655 Nov 22 2019 = firmware-2042453/boot/fixup_cd.dat -rw-rw-r-- 0 root root 9816 Nov 22 2019 = firmware-2042453/boot/fixup_db.dat -rw-rw-r-- 0 root root 9816 Nov 22 2019 = firmware-2042453/boot/fixup_x.dat -rw-rw-r-- 0 root root 5142424 Nov 22 2019 = firmware-2042453/boot/kernel.img . . . -rw-rw-r-- 0 root root 1056 Nov 22 2019 = firmware-2042453/boot/overlays/wittypi.dtbo -rw-rw-r-- 0 root root 2880356 Nov 22 2019 = firmware-2042453/boot/start.elf -rw-rw-r-- 0 root root 2775076 Nov 22 2019 = firmware-2042453/boot/start4.elf -rw-rw-r-- 0 root root 775872 Nov 22 2019 = firmware-2042453/boot/start4cd.elf -rw-rw-r-- 0 root root 4582664 Nov 22 2019 = firmware-2042453/boot/start4db.elf -rw-rw-r-- 0 root root 3536680 Nov 22 2019 = firmware-2042453/boot/start4x.elf -rw-rw-r-- 0 root root 688068 Nov 22 2019 = firmware-2042453/boot/start_cd.elf -rw-rw-r-- 0 root root 4857160 Nov 22 2019 = firmware-2042453/boot/start_db.elf -rw-rw-r-- 0 root root 3794600 Nov 22 2019 = firmware-2042453/boot/start_x.elf This illustrates the lack of updates based on lack of updates to the Makefile and distinfo file. More recent material is available from github but is being ignored for now. >> Seems to be unclear(at least to me), whether ever used or never >> ...while absolutely possible that you`re right here. >=20 >> ` have discussed that with Rob Crowston & Mike Karels some time ago,=20= >> The problem was the bcm2711-rpi-4-b.dtb , which at that time = shouldn=E2=80=99t be changed because to stay compatible with the = 8GB-model., >> so possibly since then there never was a newer dts compiled to dtb. >=20 > 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). >=20 >> But I G U E S S(still can=E2=80=99t resist;-) that we now have to = patch&compile( at least bcm2711-rpi-4-b) to stay in touch with 2020.10 >>=20 >>> Am 10.10.2020 um 02:21 schrieb Mark Millard <marklmi at yahoo.com>: >>> My FreeBSD USB3 SSD is partitioned as:=E2=80=A6=E2=80=A6.. >>> After that it tries to boot from ethernet (which was >>> not connected). >>=20 >> Tomorrow I will look again exactly with which partition tables I = booted the SSD,=20 >> for today I am completely dizzy from all that rpi-dtb stuff , I = can=E2=80=99t remember what I did :-) >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5B658E5E-C438-4A05-99F5-8E4B67A89488>