On 06/20/2012 06:10 PM, Alexander Graf wrote:
>
> On 21.06.2012, at 01:07, Scott Wood wrote:
>
>> On 06/20/2012 05:59 PM, Alexander Graf wrote:
>>>
>>> On 21.06.2012, at 00:26, Scott Wood wrote:
>>>
>>>> On 06/20/2012 03:11 PM, Alexander Graf wrote:
>>>>> + /* XXX better abstract into Emb.xxx features */
>>>>> + if (version == fsl_e5500) {
>>>>> + spr_register(env, SPR_BOOKE_EPCR, "EPCR",
>>>>> + SPR_NOACCESS, SPR_NOACCESS,
>>>>> + &spr_read_generic, &spr_write_generic,
>>>>> + 0x00000000);
>>>>> + spr_register(env, SPR_BOOKE_MAS7_MAS3, "MAS7_MAS3",
>>>>> + SPR_NOACCESS, SPR_NOACCESS,
>>>>> + &spr_read_mas73, &spr_write_mas73,
>>>>> + 0x00000000);
>>>>> + env->reset_msr = (1ULL < MSR_CM);
>>>>
>>>> That's a funny way of writing "env->reset_msr = 0". :-)
>>>>
>>>> Assuming you really meant "env->reset_msr = 1ULL << MSR_CM", why? We
>>>> enter the kernel in 32-bit mode. It resets in 32-bit mode as well, if
>>>> we ever implement that for e5500 QEMU.
>>>
>>> Hrm. At least my self-compiled kernel did issue an "ld" instruction before
>>> going into MSR_CM mode, hence I figured we need it.
>>
>> You don't need MSR_CM to run 64-bit instructions. It just affects
>> masking in certain places.
>
> Wait - you don't? Is there a comprehensive description on what MSR_CM really
> does and does not?
Not that I know of -- you need to search the ISA for places that mention
MSR[CM] or 64-bit mode.
-Scott
