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
