Hi folks. We locally just rebased and picked up a change where the ARM PCI controller's configuration was fixed so that it had the appropriate starting address for memory mappings. Now that that's correct, it means that instead of setting memory BARs to 0x40000000 (for example) to get them in the correct place, they need to be set to 0, and the "hardware" will take care of adding in a 0x40000000 offset.
That's more correct, but it means that now the BAR needs to be set to 0, and the gem5 PCI BAR handling code is a little bit simplistic and wrong in that it treats 0 and 0xffffffff as magical values and has special behavior when the BARs are set to them. Specifically, it treats a 0 as off, and doesn't update the ranges the device responds to on its parent bus. This isn't a problem on x86 where the memory addresses are usually not 0 since there's actual RAM there, and there's generally no offset applied either. To fix this, I have a big rework in progress which will change how BARs are set up for PCI devices across the board. Note that this will not affect any of the work Andreas did a while ago setting up a host device, the DeviceInterface type, etc., which is all fine. There are two major parts to the change I'm making, in python and C++. First, rather than having several arrays of scalar parameters which together control the BARs, a raw BAR value as it would be in the config, a flag setting it s a "legacyIO", and a size, (and a legacy IO offset!) each BAR is represented by a python object whose type reflects it's job. There is one for IO, one for memory, one for the upper 32 bits of a 64 bit BAR, and one for legacy IO. They each have appropriate properties like a fixed address or a size as appropriate, and are assigned to a device as a VectorParam. Then on the C++ side, rather than try to track things from the raw BAR values, config writes are filtered through the BAR objects which know what bits to mask, what the corresponding address range should be based on their type, etc. I also took this opportunity to clear away a number of clumsy bookkeeping mechanisms and bugs/misunderstandings of how BARs work, many of them my own from a long time ago. Also, the handling of disabling memory or IO BARs through the config "command" byte is now handled centrally, rather than being implemented one off in the IDE controller. Both of these things seem to now be working, so that's great. The reason I'm writing an email rather than sending a code review (yet) is that I'm also running into a problem with the python config. The gist of it is that the PCI device creates the VectorParam of BARs. The IDE controller then sets the BARs using a python list of BAR objects as a default, and that works. Then in the X86 SouthBridge object (x86 is a little easier for me to test atm), I've tried to overwrite some of those BARs individually to give them new defaults which make sense on x86. That fails because the new values are not parented correctly. If I try setting the whole VectorParam with a new list, then it works fine. I think the problem is that foo.bar[0] = doesn't actually set foo.bar, it extracts bar from foo and then sets element 0 in the bar it extracted. The bookkeeping for this is wrong somehow. Anyway, I wanted to send out an email to let people know there's a bug here on both counts, in case they ran into any problems. The default ARM setup should be mostly ok since the only PCI device seems to be the IDE controller, and that uses legacy style fixed IO BARs which seem to work fine. I also wanted to let people know I'm fighting with the bug in the config system. I'm going to try to figure that one out, but it's pretty twisty in there and I'm struggling to understand how all that plumbing works. If anybody has any great insights, I'd be happy to hear them! Gabe
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
