| *** tpb <[email protected]> has joined #openrisc | 00:00 | |
| shorne | arnd: thanks for your review on the PCI stuff | 08:45 |
|---|---|---|
| shorne | I will need to take that and review some things | 08:45 |
| arnd | ok, no worries. What PCI host bridge implementation are you actually working on integrating? Is this for qemu, some license IP core or something else? | 08:46 |
| shorne | the host bridge we use is "pci-host-ecam-generic/", the hardware is using qemu's generic pci stack in a new virt openrisc platform I am putting together | 08:47 |
| arnd | ok, I see. I think at least traditionally the way qemu dealt with I/O space was rather weird, as the person who first ported that code from x86 to the arm kvm model didn't understand how I/O space works | 08:48 |
| shorne | I see, probably I don't really understand either as I was just using existing code as examples | 08:49 |
| shorne | Your comments help, I should be able to simplify this | 08:49 |
| arnd | they used to put the I/O space at a fixed location at physical address zero to have I/O port number equal to physical memory address. This sounds like the right thing at first, but it really is not, as no real hardware ever did this | 08:49 |
| arnd | what you should have in the qemu model is one register range for ECAM config space registers, and another 64KB register range for I/O space | 08:50 |
| shorne | https://github.com/stffrdhrn/qemu/commit/d45518b39f35ee6dc2f764b2a65b4115f3dd2057 | 08:51 |
| arnd | both get listed in DT. The way they do get listed is again rather confusing, let me know if you need help with that. config space here is a regular 'reg' property, but I/O space is encoded in 'ranges' | 08:51 |
| shorne | this is my current patch for adding the qemu pci bus | 08:51 |
| shorne | [VIRT_ECAM] = { 0x9e000000, 0x1000000 }, | 08:51 |
| shorne | [VIRT_PIO] = { 0x9f000000, 0x1000000 }, | 08:51 |
| shorne | [VIRT_MMIO] = { 0xa0000000, 0x10000000 }, | 08:51 |
| arnd | ok, that seems reasonable, though the PIO space is much too large, and the MMIO space is rather small | 08:52 |
| arnd | PIO space size should be 0x10000, or possibly 0x1000, MMIO space should be as large as you can afford | 08:52 |
| shorne | ok, mmio is now 256mb if I read it correct, so maybe 1gb would be more reasonable? | 08:54 |
| shorne | I am not sure i can afford much more | 08:54 |
| shorne | considering I will like to run with 1-2gb ram | 08:54 |
| shorne | I have to step away and get kids | 08:56 |
| arnd | it depends on what kind of PCI card you want to attach, and how many of them. Most cards use at most 1MB of address space, the critical ones tend to be GPU or infiniband adapters, which you may not care about | 08:58 |
| arnd | the NVIDIA GPU on my system has one 256MB BAR, everything else fits into 64MB I think | 08:59 |
| arnd | the traditional way that x86-32 handled this was to give everything that is not RAM to PCI MMIO address space, so e.g. you could have RAM start at address 0, have all fixed MMIO locations start top-down from 0xffffffff, and use everything in the middle for MMIO space. | 09:02 |
| shorne | arnd: I see, that could work | 12:56 |
| *** shorne <[email protected]> has quit IRC (Read error: Connection reset by peer) | 15:43 | |
| *** shorne <[email protected]> has joined #openrisc | 15:49 | |
| *** shorne <[email protected]> has quit IRC (Read error: Connection reset by peer) | 16:53 | |
| *** shorne <[email protected]> has joined #openrisc | 16:58 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!