[Top] [All Lists]

Re: [Fwd: [bug report] 0xffffffffc0000000 can't be used on bcm1250]

To: Weiwei Wang <>
Subject: Re: [Fwd: [bug report] 0xffffffffc0000000 can't be used on bcm1250]
From: "Maciej W. Rozycki" <>
Date: Tue, 14 Oct 2008 11:46:12 +0100 (BST)
Cc: Ralf Baechle <>, weiwei wang <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <> <> <> <>
User-agent: Alpine 1.10 (LFD 962 2008-03-14)
On Tue, 14 Oct 2008, Weiwei Wang wrote:

> I checked the sb-1 core user manual, and finally confirm the virtual
> address space is 44 bits wide, not 40 bits. so for function

 Lucky you to have access to this thing!  Anyway, Ralf has promised us a 
brand new wonderful alternative solution, so let's wait for that to happen 
first before fiddling with my proposal any further.  Thanks for the note 

> But another issue is confusing me right now. Since the bit 44-61 in
> entryhi is not valid, and are read as 0,  so when issue command tlbwr,
> the cpu will copy the contents of EntryHi, EntryLo, and PageMask into
> the TLB entry, including the invalid bits in VPN2 of entryhi.  Here I
> think tlb entry conflict may appear. Take address 0xc0000fffc0000000 and
> 0xffffffffc0000000 for example, the two address may get the same tlb
> entry. am i getting it wrong? can you give me your understanding.

 If you have a close look at the MIPS64 architecture spec, then you'll 
notice that the last 2GB of the XKSEG space are reserved.  This is exactly 
so that the clash you are concerned about does not happen.  Any EntryHi 
value written with the value of R set to 0x3 and all the bits of VPN2 
starting from the most significant one down to the bit #31 set to 1 refers 
to the compatibility segment.


<Prev in Thread] Current Thread [Next in Thread>