Re: [Qemu-devel] [PATCH] Fix PReP NIP reset value

[Alexander Graf <agraf@suse.de>]

On 04/30/2013 06:23 PM, Fabien Chouteau wrote:
> On 04/30/2013 06:06 PM, Alexander Graf wrote:
>> On 04/30/2013 06:00 PM, Fabien Chouteau wrote:
>>> On 04/30/2013 05:24 PM, Alexander Graf wrote:
>>>> On 04/30/2013 05:07 PM, Fabien Chouteau wrote:
>>>>> The value was changed by the "PPC: fix hreset_vector..." patch.
>>>>>
>>>>> Signed-off-by: Fabien Chouteau<chouteau@adacore.com>
>>>>> ---
>>>>>     hw/ppc/prep.c |    3 +++
>>>>>     1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
>>>>> index cceab3e..2d0c4fe 100644
>>>>> --- a/hw/ppc/prep.c
>>>>> +++ b/hw/ppc/prep.c
>>>>> @@ -427,6 +427,9 @@ static void ppc_prep_reset(void *opaque)
>>>>>         PowerPCCPU *cpu = opaque;
>>>>>
>>>>>         cpu_reset(CPU(cpu));
>>>>> +
>>>>> +    /* Reset address */
>>>>> +    cpu->env.nip = 0xfffffffc;
>>>> Why does PREP reset at this vector? Is it architected to that? Does 601 reset to that offset?
>>>>
>>> I don't know why PReP reset here. As I said in the hreset_vector patch,
>>> even if the core manual says that hreset is at 0xfff00100, the value is
>>> in fact board specific. OpenHackWare expects 0xfffffffc as reset
>>> address.
>> Do you have 601e or 601 specs handy? Maybe they have a different reset vector.
>>
> None of the specs I have talk about 0xfffffffc...
>
>> Maybe OHW is also just wrong ;).
>>
> Maybe, but I have no way to prove it.

Ok, let's leave it at that patch then ;). It'd be good to know if herve 
can boot his real images from 0x100. If so, OHW is likely at fault and 
we can revert the change once Andreas switched to OpenBIOS.


Alex