RPi4B: edk2-platforms updated because _DMA method for XHCI DMA issue insufficient for Linux; pftf/RPi4 v1.21 has the change

[Mark Millard]

On 2020-Nov-13, at 15:44, Robert Clausecker <fuz at fuz.su> wrote:

> Hi Mark,

Hello Robert.

> Does this change affect FreeBSD w/ UEFI in any way?  Should I consider
> updating the UEFI bootcode on my board?
> . . .

I do not know the FreeBSD implications of having the IORT table in
the ACPI information for the RPi4B. Nor have I started experimenting
to find out how things go with that. Having IORT limit the xHCI to 2
GiByte and the prior FreeBSD code's separate limit handling leaves
me worried but I'm ignorant of the actual implications.

I've been running the RPI4B with a more recent start4.elf (and such)
since the corruption issue was fixed, but mostly booted via u-boot
2020.10 (from before the port was upgraded to 2020.10). The pftf/RPi4
v1.21 materials may be using something more recent than I have in
place for start4.elf .

It may be some time before I have user experience information to
report. Other aspects of my FreeBSD context are dated and need
updating as well.

> On Fri, Nov 13, 2020 at 02:55:21PM -0800, Mark Millard via freebsd-arm wrote:
>> 
>> Quoting https://github.com/tianocore/edk2-platforms/commit/dac891da5cf326d2b4e9aa5adab1d9320b2dd443 :
>> 
>> Add an IORT table that will limit XHCI DMA to 2 GB, by setting the
>> DMA width to 31 bits. This is needed for Linux/arm64, which can
>> only reliably deal with devices that are unable to perform DMA to
>> the entire 32-bit address range if it can discover their existence
>> early during boot, and this is before the ACPI interpreter is up
>> and running (which rules out calling the _DMA method of the XHC0
>> object)
>> 
>> End Quote
>> 
>> https://github.com/pftf/RPi4/releases/tag/v1.21 includes this change.
>> (It also updates the RPI4B firmware to quit using the broken start4.elf
>> that corrupted Device Tree information.)
>> 

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