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=1.1 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 24755 invoked from network); 8 Dec 2021 22:16:57 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 8 Dec 2021 22:16:57 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 4ess; Wed Dec 8 08:31:58 -0500 2021 Message-ID: <98FE28F68DAC382CDBC90217AF1A7464@felloff.net> Date: Wed, 08 Dec 2021 14:31:46 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <0100017d96b417b9-a5e2eae6-0ba3-426f-ad01-212e91371731-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: patented persistence app-aware table method Subject: Re: Fwd: [9front] Porting RTL8111 (ether8169) driver to bcm64 Reply-To: 9front@9front.org Precedence: bulk > Symptom 1: the irq is 255. Maybe it is a non-issue - maybe expected the way interrupts are allocated, I don’t know. that doesnt matter. this is just a scratch register in pci config space that has no impact on anything. on a pc, it was used by the BIOS to communicate what effective interrupt line on the PIC a device would signal on. so the OS would not need to know the irq routing details on the mainboard. on the raspberry pi, none of this matters. as this is pcie, we expect the device to support message signaled interrupts and the pcie controller has dedicated msi control block for this. just call intrenable() with the devices tbdf, the irq argument is ignored in case of a pci type tbdf. > What was outlined was generally what I was doing. A notable difference was when pcienable occurred - I don’t know whether it is that important to execute that before or after the vmap. yes, that makes sense. pcienable() power saving wakeup, as well as enabling address decode bits in the pci command register appropriate to the bars. > There are some other items - but it seems that I am missing something in the vmap. no. the vmap() is invisible to the device. it is a pure software thing, just to get access to the physical address space from the cpu's perspective. vmap() always creates the mapping with the appropriate non-cached an device attributes asuitable for device registers. the more difficult part is sequencing access to/from dram from the device (dma), as the dram is not held coherent in regards to your register accesses on arm. so opposed to the pc, dmaflush() cache maintenance operations are required to make sure memory becomes visible to the device. but that is, just like interrupts something that should come later, once you can read the mac address properly. in regards to the differnet results depending on the access size, yes. makes sense. it is something that is observable by the device... the pcie transactions have byte enable bits in transactions. make sure your not doing unaligned accesses in regards to the access size. i cannot help you there tho... check datasheet and in doubt you can take a look at openbsd or linux drivers... maybe the register map is wrong or out of date for the device in question. what i can see tho is that your mmio pointer is of type u32int*, so you'r not doing byte reads here at all, and mmio[1] is byte offset 0x4. and again, i already told you theres no I/O space on the pi. the I/O bar is useless for you, and you cant vmap() it... I/O space and Memory space are completely different things. and I/O space does not exist on the pi. -- cinap