Skip site navigation (1)Skip section navigation (2)
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>