From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 9990 invoked from network); 27 Jan 2021 18:35:12 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 27 Jan 2021 18:35:12 -0000
Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Wed Jan 27 12:57:58 -0500 2021
Message-ID: <2B36CF440E98DA3D5E8A94B83AC9CF65@felloff.net>
Date: Wed, 27 Jan 2021 18:57:48 +0100
From: cinap_lenrek@felloff.net
To: 9front@9front.org
In-Reply-To: <0100017741afd09d-da43b097-8dba-46b2-98d9-05414e118708-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: CSS-aware HTTP method CMS descriptor 
Subject: Re: [9front] 9front on Raspberry Pi 400
Reply-To: 9front@9front.org
Precedence: bulk

ok, so it seems on the CM4 and PI400 with newer firmware, they changed
the pcie inbound window address space. which is the range of addresses
as seen from a pci device perspecive doing busmaster dma towards memory
on the host system.

this also means we need to configure the inbound windows differently
in the pcie controller and also that drivers offset physical memory
addresses by that window base when passing them to pci devices for dma.

this is done by the PCIWADDR() macro, which currently just translates
to physical address and then adds PCIWINDOW constant, which in the
previous address scheme was 0 (no translation).

so the problem is likely that the xhcireset firmware call places the
firmware image somewhere in memory, and then the xhci controller is
not able to reach it because we assume a "no translation" regime in the
pcie controller. also the window we program is currently limited to
1GB so not all dma memory can be targeted, but this was not a problem
as we only do dma to kernel memory and the kernel memory pool fits in
that range.

to top it off, all this garbage is communicated thru devicetree blobs,
which we only partially support at this point. (mainly just to get
the sdram memory sizes and boot arguments).

i can work on this and might have something for you to test in a
couple of days.

--
cinap