> HI, Nate, could you give some more specific hints on how to implement an > extra structure in M5 and get it accessd from user code? What exactly are you trying to provide to user code? You may have mentioned this a while ago, but I forgot.
> The major problem > may be the address allocation, how can I make this structure accessed by an > address range that I designated myself? This isn't a trivial exercise because the kernel is designed to not give user processes access to physical addresses. As you say, you can create a simulator object and place it at a particular address and mmap /dev/mem in your user process. Is this not sufficient? Another, more involved way, is to create a device model and a device driver and teach the device driver to support mmap. I think that no matter what you try to do, you're going to end up needing mmap. > How does M5 open an address range > to the linux and to the application ? Thank you! M5 provides address ranges to linux, it does not provide ranges to applications, linux does that part. Depending on what you choose to do, you generally provide addresses to linux by creating MemObjects that have ports and connect them to the memory system. The simplest thing to do is create an object like PhysicalMemory. You can configure the (physical) address range to either be cacheable or uncacheable by the address you choose. Look in the src/dev/alpha directory for things that have uncacheable addresses. Now, the thing is, if you add something, linux needs to be able to find it. Right now, M5 is really only set up to tell the kernel about one cacheable address range (I think), so you may have to use a kernel command line parameter to tell it about more. As for uncacheable addresses, it's likely that you will have to create some sort of device model and driver, unless that same command line parameter for cacheable addresses works for uncacheable ones. All that said, you need to be careful with the linux command line parameters since you probably don't want linux to actually treat the addresses as normal RAM. Hopefully that all made sense. For me personally, if I were building something that was not to be treated like RAM, I would create a PCI device model for it, and write a simple device driver. It's really not all that much work (someone who knew what they were doing would be able to do it in a day), but I'll admit that the learning curve is steep. Nate _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
