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.4 required=5.0 tests=DATE_IN_PAST_24_48,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 24756 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 a8-18.smtp-out.amazonses.com ([54.240.8.18]) by 4ess; Tue Dec 7 21:32:19 -0500 2021 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=a4tryept6ew4kp6pdupzhtikhmwphypy; d=mapinternet.com; t=1638910924; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:References:To:Date; bh=DxdKRrTDlV1Yl4+CUkPuK3ST4RtDWwL3fQ+fGVpvsEI=; b=M/mfT+Mr1dDiK+DEUja0ouotqT8GE+7x5rR+TWRuz0Vo3xFlThcPHl8ovomJEioS lHppvkdtJiCfhDy0YCs1+C61XW+/t7E2S3pODuBZtRi+afMrRiZGgJStfl5kmj/pA1Z p3eUL2iAIpCiQk0lZGoRjzmxybIY+MQveI5laIK4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1638910924; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:References:To:Date:Feedback-ID; bh=DxdKRrTDlV1Yl4+CUkPuK3ST4RtDWwL3fQ+fGVpvsEI=; b=Ekb6S54smA50s9uVgJHfum7fAFtNQiR5PDDm6rBJ9BSYbdgUVeQ8SQmA5IyfDcxf PkHChK+Zz4hqoLPYk1xJtqjAnz8kpmYb5IBdKMrMYHAI+ljGlP0Rds/ZYyXyyIhnLHp 0PZqCP4sEqPYLZiHjdsqzM9dGiPBTUSoWdQ9rEFA= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.172.62.51; envelope-from=; From: Mack Wallace Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-ID: <0100017d96b417b9-a5e2eae6-0ba3-426f-ad01-212e91371731-000000@email.amazonses.com> References: To: 9front@9front.org Date: Tue, 7 Dec 2021 21:02:04 +0000 X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Qnum: 1321783188 X-Authenticated-User: mackbw@mapinternet.com Feedback-ID: 1.us-east-1.X+xhoL9JiEQ8K0gzGjV36WZnSewOzOs8YCWuakKsLBY=:AmazonSES X-SES-Outgoing: 2021.12.08-54.240.8.18 List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: decentralized scale-out core template session-aware framework Subject: Fwd: [9front] Porting RTL8111 (ether8169) driver to bcm64 Reply-To: 9front@9front.org Precedence: bulk realized I wrote the wrong expected address - should be 0x00008678, not = 0x0000c681 - but what I end up reading is still not what I expect.=20 mackbe > Begin forwarded message: >=20 > From: Mack Wallace > Subject: Re: [9front] Porting RTL8111 (ether8169) driver to bcm64 > Date: December 7, 2021 at 3:41:43 PM EST > To: 9front@9front.org >=20 > What was outlined was generally what I was doing. A notable difference = was when pcienable occurred - I don=E2=80=99t know whether it is that = important to execute that before or after the vmap. >=20 > Previously, the controller did not appear to be initializing, and so = my question was whether or not the PCI setup was occurring at all. = Whether 9front was set up to properly configure extra PCIe devices, or = if more work was needed. =20 >=20 > I=E2=80=99ve moved around my code - tried a few different things, just = trying to see if I can get the device to reset or read whether I have a = link - and I am failing at those basic tasks=E2=80=A6 and there are a = few symptoms that concern me, but I am not sure whether I should be = concerned. >=20 > Symptom 1: the irq is 255. Maybe it is a non-issue - maybe expected = the way interrupts are allocated, I don=E2=80=99t know. >=20 > Symptom 2: I get an odd MAC address: c6:3d:40:80:0:0. I say this is = odd for a few reasons. The last two octets being zero are unusual, but = also knowing that this board does not have a rom to load a MAC address = from and that the linux driver, upon failing to read a MAC address from = the unit, assigns its own. I would presume that without a ROM, that such = an unassigned address would be all zeros=E2=80=A6 but that=E2=80=99s a = complete guess.=20 >=20 > The data sheet seems to contradict itself regarding the MAC address = field: "ID registers 0-5 are only permitted to read/write via 4-byte = access. Read access can be byte, word, or double word access. =E2=80=A6=E2= =80=9D I=E2=80=99ve attempted reading by bytes to check if the latter = statement is true, but I get something completely different than when I = read via 4-byte access. So maybe only 4-byte access is viable. However, = if I read the first four bytes of the MAC address (by either mmio[0], or = by using the drivers csr32r(ctlr, 0)), and then the last four bytes (by = either mmio[2], or by using the drivers csr32r(ctlr, 2)), the latter = value does not seem to contain the two middle bytes shifted - i.e. for = the first read I get 0x8678a1c6, and the second read with a two byte = offset I get 0x00020040 when I expect 0x0000c6a1.=20 >=20 > Symptom 3: The lower nibble of Config1 is read only and should always = be 0xF. - But when I read it, it is 0. >=20 > There are some other items - but it seems that I am missing something = in the vmap. >=20 > I=E2=80=99ll include my current code - debugging acrobatics and print = statements and all. I know, =E2=80=98io=E2=80=99 is a misnomer as I am = trying to look at the PCI memory. Although, looking at the data sheet. = the MAC registers are available in both I/O and PCI Memory space. I=E2=80=99= d try the I/O space, but mem[0].bar =3D 0x01 - which makes the address = 0x0 - though this seems consistent with the linux driver, and then linux = just says that it can not allocate the memory for the i/o space. >=20 > =E2=80=94 thanks,=20 > mackbw >=20 >=20 > Current Code:=20 >=20 > static void > rtl8169pci(void) > { > Pcidev *p; > Ctlr *ctlr; > int i, pcie; > uvlong io; > u32int *mmio, a, b; > uint macv, r; >=20 > p =3D nil; > print("Checking ether8169\n"); > while(p =3D pcimatch(p, 0, 0)){ > if(p->ccrb !=3D 0x02 || p->ccru !=3D 0) > continue; > pcie =3D 0; > switch(i =3D ((p->did<<16)|p->vid)){ > default: > continue; > case Rtl8100e: /* RTL810[01]E ? */ > case Rtl8168b: /* RTL8168B */ > pcie =3D 1; > break; > case Rtl8169c: /* RTL8169C */ > case Rtl8169sc: /* RTL8169SC */ > case Rtl8169: /* RTL8169 */ > break; > case (0xC107<<16)|0x1259: /* Corega CG-LAPCIGT */ > i =3D Rtl8169; > break; > } >=20 > print("Mem0 is %d bytes, and BAR: %llux\n", = p->mem[0].size, p->mem[0].bar); > print("Mem2 is %d bytes, and BAR: %llux\n", = p->mem[2].size, p->mem[2].bar); >=20 > if(p->mem[2].bar & 1) //checks to see if this is = "memory" or "io" > continue; >=20 > pcienable(p); >=20 > io =3D p->mem[2].bar & ~0xF; > mmio =3D vmap(io, p->mem[2].size); >=20 > if(mmio =3D=3D nil){ > print("rtl8169: cannot map registers\n"); > continue; > } >=20 > ctlr =3D malloc(sizeof(Ctlr)); > if(ctlr =3D=3D nil){ > print("rtl8169: can't allocate memory\n"); > vunmap(mmio, p->mem[2].size); > continue; > } > ctlr->port =3D (uint)mmio; > ctlr->mmio =3D mmio; > ctlr->pcidev =3D p; > ctlr->pciv =3D i; > ctlr->pcie =3D pcie; > print("rtl8169: %#x %#x: port %ux size %d irq %d\n", > p->vid, p->did, *mmio, p->mem[2].size, p->intl); >=20 > if(vetmacv(ctlr, &macv) =3D=3D -1){ > print("rtl8169: %T: unknown mac %.4ux %.8ux\n", = p->tbdf, p->did, macv); > pcidisable(p); > vunmap(mmio, p->mem[2].size); > free(ctlr); > continue; > } >=20 >=20 > /* if(rtl8169reset(ctlr)){ > print("Failed to reset!\n"); > pcidisable(p); > vunmap(mmio, p->mem[2].size); > free(ctlr); > continue; > } */ >=20 > print("bytes of MAC address %ux:%ux:%ux:%ux:%ux:%ux\n", = mmio[0], mmio[1], mmio[2], mmio[3], mmio[4], mmio[5]); > a =3D mmio[0]; > b =3D mmio[2]; > print("bytes of MAC address %ux:%ux\n", a, b); >=20 > print("Configuration byte: %ux\n", mmio[Config1]); >=20 > r =3D csr8r(ctlr, Phystatus); >=20 > /* > * Maybe the link changed - do we care very much? > * Could stall transmits if no link, maybe? > */ > print ("Phystatus: %ux\n", r); > if (r & Linksts) > print("pre: We have link!\n"); > else > print("pre: We don't have a link!\n"); >=20 > rtl8169halt(ctlr); >=20 > /* > * Extract the chip hardware version, > * needed to configure each properly. > */ >=20 > ctlr->macv =3D macv; > if(rtl8169ctlrhead !=3D nil) > rtl8169ctlrtail->next =3D ctlr; > else > rtl8169ctlrhead =3D ctlr; > rtl8169ctlrtail =3D ctlr; > } > } >=20 >=20 >=20 > Suggested Code from cinap: >>=20 >> // find my device. >> Pcidev *pcidev =3D pcimatch(....); >>=20 >> // bring device out of suspend >> pcienable(pcidev); >>=20 >> // make sure it has the membar >> if(pcidev->mem[2].bar&1){ >> print("this is not a membar\n"); >> return -1; >> } >>=20 >> // make sure it has the expected size >> if(pcidev->mem[2].size <=3D HOWMANBYTESAREMYREGISTERBLOCK){ >> print("the membar is too small, does not cover all the = registers\n"); >> return -1; >> } >>=20 >> // map it into kernel virtual memory >> uint32 *regs =3D vmap(pcidev->mem[2].bar&~0xF, pcidev->mem[2].size); >>=20 >> if(regs =3D=3D nil){ >> print("can't map it\"); >> return -1; >> } >>=20 >> // then you can poke at the register >> regs[CONTROL123] =3D 1; >>=20 >> thats it. >>=20 >> =E2=80=94 >> cinap >=20 > Code from my prior message: >> print("Mem2 is %d bytes, and BAR: %llux\n", p->mem[2].size, = p->mem[2].bar); >> if(p->mem[0].size =3D=3D 0 || (p->mem[0].bar & 1) =3D=3D = 0) >> continue; >>=20 >> if(p->mem[2].bar & 1) //checks to see if this is = "memory" or "io" >> continue; >> io =3D p->mem[2].bar & ~0x0f; >> if(io =3D=3D 0) >> continue; >> print("rtl8169: %#x %#x: port %llux size %d irq %d\n", >> p->vid, p->did, io, p->mem[2].size, p->intl); >> mmio =3D vmap(io, p->mem[2].size); >> if(mmio =3D=3D nil){ >> print("rtl8169: cannot map registers\n"); >> continue; >> } >> ctlr =3D malloc(sizeof(Ctlr)); >> if(ctlr =3D=3D nil){ >> print("rtl8169: can't allocate memory\n"); >> vunmap(mmio, p->mem[2].size); >> continue; >> } >> ctlr->port =3D io; >> ctlr->mmio =3D mmio; >=20 >=20 >=20