Re: [PATCH v2] MIPS: Add basic R5900 support

[Fredrik Noring <noring@nocrew.org>]

Hi Maciej,

>  Hmm, this looks consistent with the TX79 manual:
> 
> "6.2.1 Virtual Address Space
> 
> The C790 only implements 32 bits of virtual address space.  There is no 
> requirement for address sign extension and no checking will be done on the 
> upper 32 bits of the address."
> 
> and then say in the JAL instruction description:
> 
> "I: GPR[31] 63..0 <- zero_extend (PC + 8)"
> 
> It does not matter for the user mode where bit #31 is 0 and therefore both 
> zero-extension and sign-extension produce the same result, so the typical 
> PIC code sequence used to determine its own location, i.e.:
> 
> 	la	$2, 0f
> 	bltzal	$0, 0f
> 0:
> 	subu	$2, $31, $2
> 
> will work correctly, not causing UB with the SUBU instruction.
> 
>  However it does cause complications for the kernel in that the value of 
> $ra retrieved cannot be readily used for 32-bit calculations and has to be 
> treated with SLL by 0 first.  You'll have to audit the arch/mips subtree 
> for any such $ra use for calculation; hopefully are there's none.
> 
>  I wonder why they broke it like this -- was it a silly deliberate choice 
> or merely an oversight (erratum) they chose to document rather than fix? 
> For a change they do implement MFC0 with sign-extension, so retrieving 
> e.g. CP0.EPC will see kernel addresses correctly sign-extended.

After some further tests, it appears that for $ra, save/restore works with
both SW/LW and SW/LWU. Hence, $ra bits 63:32 do not seem to matter at all
(as intended), and its sign-extension failure can therefore be disregarded.
This is somewhat non-obvious since $ra is the only register that fails to
sign-extend after kernel initialisation (and consequently trigger a trap).

>  Anyway, as noted above that shouldn't cause a problem with user software 
> and I think that any corruption you can see comes from elsewhere.  You'll 
> have to paper this $ra non-sign-extension issue over somehow to proceed 
> though.

During early kernel initialisation at least one other register (besides
$ra) appears to fail the sign-extension test, and the error cannot be
ignored. I will now try figure this out.

Fredrik