Date: Thu, 24 Sep 2020 17:53:33 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com>, Robert Crowston <crowston@protonmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: head -r365677 and later do not have the xhci related DMA problem fixed Message-ID: <04531BA7-F7A6-498B-BB8E-D3AAA53E15E3@yahoo.com> In-Reply-To: <39346C6E-CF29-42E8-BCAB-B04E73F909F7@googlemail.com> References: <5A60B29E-0D24-480C-807D-4A5E92D9C92A.ref@yahoo.com> <5A60B29E-0D24-480C-807D-4A5E92D9C92A@yahoo.com> <CCC44A9E-68C0-4EEF-AA68-AFA2F1F93ADA@googlemail.com> <JTSsaCfyfQICpQuYOx_aY-35TQTxCtQbI3L_t1o70kdtk-MZrrJ06WuluBwhYS5BQ58Apdet1XTP3u79WZYGUj8L2BjY_owAkoVLMN8IXVU=@protonmail.com> <231B8A1B-7F61-4868-B9E6-F8DD824079CA@yahoo.com> <39346C6E-CF29-42E8-BCAB-B04E73F909F7@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-24, at 16:38, Klaus Cucinauomo <maciphone2 at = googlemail.com> wrote: > Am 25.09.2020 um 00:41 schrieb Mark Millard <marklmi at yahoo.com>: >>=20 >> So, should I figure out the currently proper way to have a >> u-boot based boot environment and try the huge-file duplicate >> and diff/cmp test in such an environment? >=20 > you will be shocked how many issues in fdt are meanwhile fixed by the = =E2=80=9Aghostwriter`(Sponsored by: Innovate UK) :-). > see the Wiki-list of features/what works. > I didn`t test the huge-file-thing extensively > but when our `other U.K-innovator`:-) says he has fixed it in D26344 = that means: > It IS definitely fixed. :-)... but of course you should continue = attacking the board because=20 > you mostly find out something interesting ;-) So far I'm unable to figure out how to have a u-boot environment that boots the RPi4B's: figuring out what needs to be different than the rather modern raspberry pi files that I have in place. Also: fully modern eeprom content. As stands I've not been using a microsd card at all: it uses the msdos file system from the USB3 SSD. It hangs with the rainbow screen up and having reported starting start4.elf in every attempt that I've made. As near as I can tell the overall behavior matches what tech-lists at zyxst.net has been reporting. Details of what I've got in place (that fails to boot): I've downloaded: = https://sourceforge.net/projects/rpi4-8gbram-boot-fbsdonly/files/u-boot.bi= n/download = https://sourceforge.net/projects/rpi4-8gb-uboot-bcm2711-backup/files/bcm27= 11-rpi-4-b.dtb/download and substituted them into the USB3 SSD msdos file system: -rwxr-xr-x 1 root wheel 40659 Jun 7 11:37:30 2020 = /usb_efi/bcm2711-rpi-4-b.dtb.ub -rwxr-xr-x 1 root wheel 517160 Jun 6 19:07:50 2020 = /usb_efi/u-boot.bin For u-boot based booting I tried having the config.txt content be: arm_64bit=3D1 dtoverlay=3Ddisable-bt dtoverlay=3Dmmc device_tree_address=3D0x4000 kernel=3Du-boot.bin armstub=3Darmstub8-gic.bin The armstub8-gic.bin is the one I used back in Jan/Feb that was working for the early materials from back then and does not seem to have updates: -rwxr-xr-x 1 root wheel 5888 Jan 30 13:26:30 2020 = /usb_efi/armstub8-gic.bin I have: -rwxr-xr-x 1 root wheel 2283936 Sep 1 14:04:08 2020 = /usb_efi/start4.elf -rwxr-xr-x 1 root wheel 5422 Sep 1 14:04:04 2020 = /usb_efi/fixup4.dat (so modern, per my USB MSD eeprom context and set up for booting via USB3). I'm using: -rwxr-xr-x 1 root wheel 705776 Sep 20 20:41:44 2020 = /usb_efi/EFI/BOOT/BOOTAA64.EFI ( from head -r365932 ). I do not find anything explicitly written that indicates what of these need replacement (or what to replace them with). =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?04531BA7-F7A6-498B-BB8E-D3AAA53E15E3>