Re: pci_mapreg_map and BAR from `Bus space tutorial'

Hi :)! > Sent: Sunday, June 14, 2020 at 7:21 PM > From: "Radoslaw Kujawa" > To: "Rocky Hotas" > Cc: "Martin Husemann" , tech-kern@NetBSD.org > Subject: Re: pci_mapreg_map and BAR from `Bus space tutorial' > There's also a good genera

Re: pci_mapreg_map and BAR from `Bus space tutorial'

Hi. On 6/12/20 3:30 PM, Rocky Hotas wrote: I applied your patch and it works for me the same way. Thanks! Excellent, glad to hear that. As a sidenote: I found your bus_space_tutorial very useful, the only one available about this topic. For this problem, I suspended it at slide 47 of your p

Re: pci_mapreg_map and BAR from `Bus space tutorial'

Hello Radoslaw, On giu 11 1:02, Radoslaw Kujawa wrote: > It seems that in 2018 cobalt port was switched to common MIPS bus space > implementation. As a part of this implementation, it started to be more > strict about verification of addresses used by device during bus_space_map. [...] > Please

Re: pci_mapreg_map and BAR from `Bus space tutorial'

>> [in your driver: extern int mapreg_debug; ... mapreg_debug = 1;] >> int mapreg_debug = 0; >> ... >> if (mapreg_debug) printf("...", ...); >> It's a horrible thing to do for "permanent" (production) code, but I >> see nothing at all wrong with it for experimental debugging. > Thank yo

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On giu 10 7:05, Mouse wrote: > You can't. If you have read-only access to the BAR - which is what > pcictl gives you - then all you can get is the base address. You need > read/write access to get the range as well. (In case you haven't yet > seen the trick: you read the value and save it, the

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On 6/10/20 4:30 PM, Radoslaw Kujawa wrote: It is more likely that something mis-compiles now (I see a ton of warnings trying to build it now), or that there is a bug in implementation of test device emulation, that somehow went unnoticed back in 2012. It seems that in 2018 cobalt port was s

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On 6/10/20 4:19 PM, Martin Husemann wrote: On Wed, Jun 10, 2020 at 04:12:03PM +0200, Radoslaw Kujawa wrote: I suspect there are two options: either something has bit-rotted in Cobalt-specific PCI code, or the ancient gxemul from 2012 does not work correctly anymore. FWIW, Anders Gavare is q

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On Wed, Jun 10, 2020 at 04:12:03PM +0200, Radoslaw Kujawa wrote: > I suspect there are two options: either something has bit-rotted in > Cobalt-specific PCI code, or the ancient gxemul from 2012 does not work > correctly anymore. FWIW, Anders Gavare is quite responsive to email, if there is a hint

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On 6/10/20 12:58 PM, Rocky Hotas wrote: On giu 10 12:54, Rocky Hotas wrote: the address 0x1011 belongs to a `user process virtual space, mapped and cached', both when the processor uses 32 and 64 bit addresses. The address reported by pcictl is a physical address. It looks correct i

Re: pci_mapreg_map and BAR from `Bus space tutorial'

>> Guessing should not be relevant; how BARs work is part of the PCI >> definition. > What I was meaning is that it seems counterintuitive that a single 32 > bit register can at the same time specify a 32 bit physical memory > address and a memory region extent. Yes. It is clever - but I wish the

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On giu 10 12:54, Rocky Hotas wrote: > the address 0x1011 belongs to a `user process virtual space, mapped > and cached', both when the processor uses 32 and 64 bit addresses. No, sorry, that was about Virtual addresses, not physical ones. Here,

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On giu 10 11:50, Martin Husemann wrote: > so it is PCI_MAPREG_TYPE_MEM ("memory" in the type line), and the mapping > should just work. Ok! And I guess that invoking pci_mapreg_type() would give the same result. > Does the map address (0x1011) make sense on that machine? I really don't know

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On Wed, Jun 10, 2020 at 11:41:51AM +0200, Rocky Hotas wrote: > Base address register at 0x10 > type: 32-bit nonprefetchable memory > base: 0x1011 so it is PCI_MAPREG_TYPE_MEM ("memory" in the type line), and the mapping should just work. Does the map address (0x1011) make sense on tha

Re: pci_mapreg_map and BAR from `Bus space tutorial'

Hi! On giu 08 15:31, Mouse wrote: > Guessing should not be relevant; how BARs work is part of the PCI > definition. Yes, of course. What I was meaning is that it seems counterintuitive that a single 32 bit register can at the same time specify a 32 bit physical memory address and a memory region

Re: pci_mapreg_map and BAR from `Bus space tutorial'

>>> - FAA_MMREG_BAR may contain the beginning address of a space to be >>>mapped. But how does `pci_mapreg_map' know the extension of such >>>a map? >> [...], the BAR contains all info needed (or should, if setup has >> worked correctly). > Oh, ok, so the BAR does not specify just an addres

Re: pci_mapreg_map and BAR from `Bus space tutorial'

Hello Martin, sorry for the delay and thanks a lot for your answer. On giu 02 7:03, Martin Husemann wrote: > > - FAA_MMREG_BAR may contain the beginning address of a space to be > > mapped. But how does `pci_mapreg_map' know the extension of such a map? > > It is just an offset (like a regis

Re: pci_mapreg_map and BAR from `Bus space tutorial'

On Mon, Jun 01, 2020 at 08:35:13PM +0200, Rocky Hotas wrote: > pci_aprint_devinfo(pa, NULL); > > if (pci_mapreg_map(pa, FAA_MMREG_BAR, PCI_MAPREG_TYPE_MEM, 0, > &sc->sc_regt, &sc->sc_regh, &sc->sc_reg_pa, 0) != 0 ) { > aprint_error_dev(sc->sc_dev, "can't ma

pci_mapreg_map and BAR from `Bus space tutorial'

Hello! A very useful tutorial is available for newbies like me in with a first introduction to kernel PCI drivers. I hope this is the right ML to write to, des