head -r365677 and later do not have the xhci related DMA problem fixed

[Mark Millard]

On 2020-Sep-24, at 23:34, tech-lists <tech-lists at zyxst.net> wrote:

> Hi,

Hello.

> On Thu, Sep 24, 2020 at 05:53:06PM -0700, Mark Millard via freebsd-arm wrote:
> 
>> 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.
> 
> Mine *will* boot, even after the eeprom upgrade. What it won't do (what was
> always the case) is boot after I modify config.txt in any way at all.
> 
> I used these files, and the last time I made a working image I used
> FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200917-17bd0444d91.img 
> mount the msdos partition,
> 
> replace u-boot.bin, fixup4.dat, start4.elf
> 
> wget https://sourceforge.net/projects/rpi4-8gbram-boot-fbsdonly/files/u-boot.bin/download
> -O u-boot.bin
> 
> fetch https://github.com/raspberrypi/firmware/raw/1.20200717/boot/fixup4.dat
> fetch https://github.com/raspberrypi/firmware/raw/1.20200717/boot/start4.elf

1.20200717 is from back on 2020-Jul-17 and is too old to
generally work with the modern eeprom for USB MSD use according
to what the raspberry pi folks have published. The
RPi4B will report that the firmware needs to be updated
generally (possibly not universally).

One would have to use an older vintage of the eeprom
content that was in use with pre-2020-Aug-20 firmware in
order to use that older firmware generally:

https://github.com/raspberrypi/rpi-eeprom/commit/279eef4
( firmware/beta/pieeprom-2020-08-31.bin )

looks to be the last that is before the versions that
they eventually noted required 2020-Aug-20 or later
firmware (microsd card date).

Going the other direction, given the modern release of the
eeprom content that was declared "critical" for
most everyone as of 2020-09-04 (so general distribution),
the only officially tagged firmware versions that are
documented as compatible are those in:

https://github.com/raspberrypi/firmware/tree/1.20200902/boot/
https://github.com/raspberrypi/firmware/tree/1.20200819/boot/

(so the first microsd cards were from 2020-Aug-20).
All prior versions predate the 2020-Aug-20 criteria
as far as I can tell.

Looks to me like the u-boot based FreeBSD support currently
requires the use of of-of-date BETA materials from the
raspberry pi folks, both eeprom content and firmware. (Not
surprising, there is normally a lag and the raspberry pi
materials were prompted to being classified as "critical"
for most folks to use only on 2020-Sep-14.)

Folks need to be careful to not do a default upgrade of
the firmware or eeprom content on their RPI4B's (and
to avoid trying to use new RPI4B's as shipped, once the
older RPi4B inventory has been sold off).

[rpi4-uefi-devel's v1.20 has other tradeoffs but allows
using the modern raspberry pi firmware and eeprom-content
combination.]

> unmount the partition
> 
> it should boot.

By official raspbeery pi criteria it should not boot for
the eeprom contents that I have in place: too new for
1.20200717 firmware because I have what was promoted to
be the default EEPROM image for everyone. The RPi4B needs
more recent firmware (2020-Aug-20 or later) if that modern
eeprom content is to be used.

>> 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.
> 
> I am using the same image (subsequently rebuilt world, kernel so it's at
> r365898 now), I took out this sdcard, wrote raspios-64bit to another one, updated the eeprom, put back the freebsd card. It boots, just can't touch config.txt or or I get the raspberry problem (happened before the eeprom upgrade), if I try the different start4.elf & fixup4.dat, I get the rainbow screen.

Thanks for the notes. What I've learned is that the U-boot
based context requires that I'd have to revert both the
eeprom content and the rpi firmware before I could run
u-boot based tests.

I'm not sure that I want to do that so I'll likely wait on
any testing of u-boot based operation until the following
are supported via u-boot based booting:

https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/critical/pieeprom-2020-09-03.bin
https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/critical/vl805-000138a1.bin
https://github.com/raspberrypi/firmware/tree/1.20200902/boot/

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