Yes, that is correct. Accessing the boot loader out on the PIO bus should work just fine assuming it maps to a different physical address space than DRAM. Also Andrew's observations definitely jive with my expectations. Currently Ruby does not support discontinuous address spaces.
Brad > -----Original Message----- > From: [email protected] [mailto:gem5-dev- > [email protected]] On Behalf Of Ali Saidi > Sent: Friday, May 25, 2012 8:24 AM > To: gem5 Developer List > Subject: Re: [gem5-dev] Review Request: ARM: Enable Ruby functionality > with ARM FS > > Hi Andrew, > > The boot loader we used is only a couple of KB, so it doesn't need to be that > big, but what I read into Brad's comment was that we could execute the boot > loader if it was attached to a ROM outside of main memory as long as we > didn't care about the Ruby timing. Brad, did I get that right? In this case > couldn't we run the boot loader out of a simple memory connected to a pio > bus only use Ruby for the contiguous memory? > > Thanks, > Ali > > > On 5/24/12 6:22 PM, "Andrew Cebulski" <[email protected]> wrote: > > >The 172 MB was simply because that's the only way I can see to get Ruby > >to find the boot loader ROM...by moving it from the higher address > >space to the lower. I left out that the boot loader ROM is 64MB, > >therefore I had to shrink the DRAM by 64MB. Basically, it seems Ruby > >supports multiple contiguous address spaces, just not discontiguous. > >Is there something I am missing with regards to the ROM...maybe it > >doesn't need to be 64MB? > > > >-Andrew > > > >On Thu, May 24, 2012 at 4:01 PM, Ali Saidi <[email protected]> wrote: > > > >> > >> > >> On 24.05.2012 15:23, Beckmann, Brad wrote: > >> > >> > Sorry for the much > >> delayed response here. I've been too selective reading the gem5-dev > >> list lately. > >> > > >> > So if I understand correctly, the ARM FS boot loader maps > >> to some higher portion of the address space and you would like to > >> model the accesses to this boot loader ROM through Ruby. Is that > >> correct? I'm a bit confused with the comment that the maximum memory > >> supported by Ruby is 172 MB. That certainly is not true. > >> > >> This isn't true, but what > >> I'm not understating is why it was done in the first place. > >> > >> > So it > >> appears from the patch that the CPU accesses to the boot loader don't > >> go thru Ruby, but rather go through the pio bus. Only the dma reads > >> and writes from the boot loader go through Ruby. Does that analysis > >> seem correct to you? Without testing the patch myself, I can't say > >> for sure, but think that is what's happening here. If you view the > >> boot loader accesses as being non-performance critical, then the > >> current simple solution is how I would do it. However, if want *all* > >> those accesses going through Ruby, then Ruby will have to support > >> multiple address spaces. > >> > >> That is a reasonable solution, provided that it works. The boot > >> loader is only executed in during boot and nominally ~10 instructions > >> per CPU, so it shouldn't be critical. The only issue is getting > >> gem5/ruby/cpus/etc to start executing code out of something on the > >> pio bus and the transition to ruby. Brad, do you believe that this > >> should work? > >> > >> Supporting multiple address spaces > non-cacheable accesses and more > >> powerful mapping functions in the protocol files. Currently only one > >> protocol, MOESI_hammer, supports non-cacheable accesses and even > that > >> hasn't been fully flushed out. Improving the mapping functions > >> requires better coordination between the python config files and > >> Ruby. I don't have a clear idea of how to do it, but I'm happy to discuss > ideas. > >> > >> > > >> > I think most people would be happy in the above worked, although > >> long term that would be a good solution. > >> the response, > >> > >> Ali > >> > >> Brad > >> > >> -----Original Message----- From: > >> > >> Links: > >> ------ > >> [1] > >> mailto:[email protected] > >> [2] http://reviews.gem5.org/r/1191/#review2708 > >> _______________________________________________ > >> gem5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/listinfo/gem5-dev > >> > >_______________________________________________ > >gem5-dev mailing list > >[email protected] > >http://m5sim.org/mailman/listinfo/gem5-dev > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
