On 01/20/2012 08:43 PM, Alexander Graf wrote:
>
>
> Am 20.01.2012 um 21:01 schrieb Scott Wood <scottw...@freescale.com>:
>> I'm not sure what happens when you write
>> an entry to TLB1 with an invalid TSIZE.
>
> What it says, the ISA means it's implementation dependent. What e500mc
> actually implements is an different question. Which still needs to be
> answered.
AFAIK it's not documented what e500mc does for invalid sizes in TLB1, so
I think anything that complies with the architecture's statement of any
supported size is OK.
> However for now I think wde 're ok by not modeling every odd corner case.
Sure. I was just curious about the architectural statement.
>>> + /* XXX only applies for MAV 1.0 */
>>> + size_tlb = (tlb->mas1 & MAS1_TSIZE_MASK) >> (MAS1_TSIZE_SHIFT + 1);
>>> + size_min = (tlbncfg & TLBnCFG_MINSIZE) >> TLBnCFG_MINSIZE_SHIFT;
>>> + size_max = (tlbncfg & TLBnCFG_MAXSIZE) >> TLBnCFG_MAXSIZE_SHIFT;
>>> + if ((size_tlb > size_max) || (size_tlb < size_min)) {
>>> + /* set to min size */
>>> + tlb->mas1 &= ~MAS1_TSIZE_MASK;
>>> + tlb->mas1 |= size_min << (MAS1_TSIZE_SHIFT + 1);
>>> + }
>>
>> You could just implement a bitmap now, which will work for MAV 2.0 as well.
>>
>> Especially since we're using the MAV 2.0 definition of tsize already, so
>> min/max isn't an accurate way to describe what we support.
>
> Not sure I follow. In MAV 1.0 the size constraints are defined in TLBnCFG,
> while for MAV 2.0 they are defned in their own bitmap registers (TLBnPS)
>
> Would you like to have a function called that returns a bitmap of
> supported sizes for the TLB depending on its MAV value based on
> either TLBnCFG or TLBnPS? We could then check if that size value bit
> is set.
Yes, use a bitmap internally regardless of how the programming model
says we convey the information to the target code.
-Scott
