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 13059 invoked from network); 24 Nov 2021 11:50:58 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 24 Nov 2021 11:50:58 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 4ess; Wed Nov 24 06:41:56 -0500 2021 Message-ID: <6F8C8ABB6C0295545097E678640601B1@felloff.net> Date: Wed, 24 Nov 2021 12:41:45 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <0100017d49aafed3-57681c2d-2725-4b6b-af16-b0cfd55b85e0-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: X-Glyph: ➈ X-Bullshit: anonymous realtime-java singleton Subject: Re: [9front] Porting RTL8111 (ether8169) driver to bcm64 Reply-To: 9front@9front.org Precedence: bulk no, your completely confused. this is not how pci works at all. stop mucking with VIRTIO addresses, these are for SoC internal peripheral buses. you'r absolutely off the rails with this... look at ANY pci device driver, theres no mucking with anything. you have to understand how pci works. all you said i already TOLD you from information from the datasheet, you just do not seem to understand what it means. so in the kernel, a pci device is represented by a Pcidev struct (port/pci.h). there are Pcidev.mem[6], which is a array of 6 bar/size pairs. the bar field is just the register contents of the devices BAR registers when the device got enumerated. the platform pci code is responsible for (re-) programming / checking the bars before any drivers touches any pci device. it is not your drivers business to muck with them. on a pc, that job is even done by the bios/uefi. and the os doesnt really need todo anything. (except work around misconfigurations). on bcm64, the pci code allocates specifically reserved physical address space for the bar windows and the programs all found bars. from your drivers point of view, you only deal with a already programmed Pcidev struct of the device. next important thing, thats absolutely basic pci knowledge: bars are TYPED. the low 7 bits of the bars tell you what TYPE it is. if it is i/o space or memory. (IOBAR, MEMBAR). if a bar has bit 0 set, it means it is I/O bar. so that is why EVERY driver checks bit 0 first, to see if it is of type memory (bit0 == clear). and then the whole 4 low bits get masked off to get the PHYSICAL address value of the bar. the reason is that there is also a "prefetchable" and "64-bit" bit in there that is not part of the physical address. so all your driver really needs todo is: // find my device. Pcidev *pcidev = pcimatch(....); // bring device out of suspend pcienable(pcidev); // make sure it has the membar if(pcidev->mem[2].bar&1){ print("this is not a membar\n"); return -1; } // make sure it has the expected size if(pcidev->mem[2].size <= HOWMANBYTESAREMYREGISTERBLOCK){ print("the membar is too small, does not cover all the registers\n"); return -1; } // map it into kernel virtual memory uint32 *regs = vmap(pcidev->mem[2].bar&~0xF, pcidev->mem[2].size); if(regs == nil){ print("can't map it\"); return -1; } // then you can poke at the register regs[CONTROL123] = 1; thats it. -- cinap