Re: Fwd: [9front] Porting RTL8111 (ether8169) driver to bcm64

[cinap_lenrek@felloff.net]

> 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