heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (05/07/91)
I have a customer who is trying to convert their application from an MVME133XT to an MVME165. They have a 68040 MMU related question that has arisen from their configuration and the requirements of using the on-chip cache for performance. They have four regions of memory. 1. On-board memory - 4Meg at 0x0, to be cached I&D, copyback 2. A24 VMEbus space - 12Meg just after the end of 1, non-cached 3. A32 VMEbus space - various areas, many megabytes, non-cached 4. On-board resources - high memory, non-cached We believe that 3 and 4 can be treated the same, as they are both A32 and non-cached. If so, then they collapse to a single region. We had hoped to be able to do something simple, like with transparent translation registers, but 16Meg seems to be the minimum size for a TT reg. Perhaps one could be used for everything beyond the first 16Meg? As there are only two TT registers, and we have three kinds of memory space, it looks as though we have to construct MMU page tables. The customer is concerned that it seems like a lot of work and a lot of memory used up in page tables. As I look at it, I don't see how to create a TT register that maps everything except the first 16Meg. If it is possible, then page tables are needed for only that first 16Meg, which looks like it would be doable in about 8KBytes (with 8K pages). I'm not an MMU expert. I'm hoping to find one that can help guide us in configuring the 040 MMU for this application. Thanks much. -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "Wrong is wrong, even when it helps you." Popeye
jclark@sdcc6.ucsd.edu (John Clark) (05/16/91)
In article <62390@mcdchg.chg.mcd.mot.com> heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) writes: +I have a customer who is trying to convert their application from an +MVME133XT to an MVME165. They have a 68040 MMU related question that +has arisen from their configuration and the requirements of using the +on-chip cache for performance. They have four regions of memory. This is coming from Mot??? The TT registers have an ignore mask to be used in conjuction with the base 16 meg TT zone. However it seem that this may not work. For the MMU set up on need not have 'all' of memory mapped. The A level could map as 'invalid' everything but the low memory and those regions of VME and high control addresses. Each A level entry 'points' to a 32 meg region. B level 128 128K regions. C level 32 or 64 8 or 4K regions. It would seem that with sufficient 'holes' not all the B and C level tables need be filled out either. A 'critique', the 'mask' value of the TT register would have been better as a 'length'. I.e. start at Meg 16 and map the next umpty-ump Megs. > >1. On-board memory - 4Meg at 0x0, to be cached I&D, copyback >2. A24 VMEbus space - 12Meg just after the end of 1, non-cached >3. A32 VMEbus space - various areas, many megabytes, non-cached >4. On-board resources - high memory, non-cached > >We believe that 3 and 4 can be treated the same, as they are both A32 >and non-cached. If so, then they collapse to a single region. > >We had hoped to be able to do something simple, like with transparent >translation registers, but 16Meg seems to be the minimum size for a TT >reg. Perhaps one could be used for everything beyond the first 16Meg? >As there are only two TT registers, and we have three kinds of memory >space, it looks as though we have to construct MMU page tables. The >customer is concerned that it seems like a lot of work and a lot of >memory used up in page tables. As I look at it, I don't see how to >create a TT register that maps everything except the first 16Meg. If >it is possible, then page tables are needed for only that first 16Meg, >which looks like it would be doable in about 8KBytes (with 8K pages). > >I'm not an MMU expert. I'm hoping to find one that can help guide us >in configuring the 040 MMU for this application. Thanks much. >-- >Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod >"Wrong is wrong, even when it helps you." Popeye -- John Clark jclark@ucsd.edu
valentin@public.BTR.COM (Valentin Pepelea) (05/23/91)
>In article <62390@mcdchg.chg.mcd.mot.com> heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) writes: > >I have a customer who is trying to convert their application from an >MVME133XT to an MVME165. They have a 68040 MMU related question that >has arisen from their configuration and the requirements of using the >on-chip cache for performance. They have four regions of memory. >1. On-board memory - 4Meg at 0x0, to be cached I&D, copyback >2. A24 VMEbus space - 12Meg just after the end of 1, non-cached >3. A32 VMEbus space - various areas, many megabytes, non-cached >4. On-board resources - high memory, non-cached Sigh, I should read this newsgroup more often. For performance reasons, your priority should be to set up the MMU in such a way that accesses to the 4Meg of physical ram are maximized. I suggest that you use a TT register to transparently translate the lower 16Meg as copyback cacheable. Then construct a translation table to map the A24 VMEbus space into a higher 16Mb block of logical space. Then access that 12Mb block only at its new logical space. Finally, use the second TT register to transparently translate the rest of the universe as non cached. You will thus require a little over 6K of translation tables, but that should be of no concern. Reserving 6K out of 4Mb for translation tables is insignificant. >We had hoped to be able to do something simple, like with transparent >translation registers, but 16Meg seems to be the minimum size for a TT >reg. Perhaps one could be used for everything beyond the first 16Meg? Not quite. No matter how you remap it, the VMEbus 24 space will prevent an entire 2 Gig space to be adequately transparently translated. But for simplicity, you could remap the VMEbus 24 space beyond the 2Gig line address, and use the second TT register to map everyting below it. For example, you could could set the VMEbus24 address at 0x80000000, set TT register 0 to translate the entire first 16Meg block (addr: 0x00 mask: 0x00) and TT register 1 to translate the first 2Gig. (addr: 0x00 mask: 0x8F) Assuming your customer was wise enough to keep regions 3 and 4 below the 2Gig line, that is. Otherwise you'll have to get trickier. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
valentin@public.BTR.COM (Valentin Pepelea) (05/23/91)
In article <19417@sdcc6.ucsd.edu> jclark@sdcc6.ucsd.edu (John Clark) writes: >In article <62390@mcdchg.chg.mcd.mot.com> heiby@mcdchg.chg.mcd.mot.com (Ron >Heiby) writes: > >+I have a customer who is trying to convert their application from an >+MVME133XT to an MVME165. They have a 68040 MMU related question that >+has arisen from their configuration and the requirements of using the >+on-chip cache for performance. They have four regions of memory. > >This is coming from Mot??? What kind of question is that? Should Motorola employees not draw on the collective programming experience of net readers just because they happen to manufacture the chip? Ridiculizing statements such as yours serve only to deter further enquiries, not to mention wasting net bandwidth. Very much like this message. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com