Comment 4 for bug 811683

Revision history for this message
till (till-straumann) wrote : Re: [Qemu-devel] [Bug 811683] [NEW] 7400, 7410, 7450 cpus vector have wrong exception prefix at reset

Hi Andreas.

I posted a reply to the bug database. Regarding my 'bios' - it is really
nothing.
I need it to boot RTEMS. It just mocks up a minimal residual and jumps to
the kernel load address.
You can take a look at

http://www.rtems.org/viewvc/rtems/c/src/lib/libbsp/powerpc/shared/bootloader/

The stuff that goes into the dummy 'bios' is qemu_fakerom.S and
qemu_fakeres.c

Regards
- Till

On 07/17/2011 05:34 PM, Andreas Färber wrote:
> Hi,
>
> Am 16.07.2011 um 23:49 schrieb till:
>
>> I have a proprietary ROM implementing system calls that are executed
>> via
>> the 'SC' instruction.
>>
>> I use qemu-0.14.1,
>>
>> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel
>>
>> That works fine on a 604 (CPU=0x00040103) - but does not on an
>> emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x80000201). I found
>> that the emulator jumps to 0x00000c00 instead of 0xfff00c00.
>> Probably this is due to a wrong setting in target-ppc/
>> translate_init.c:
>>
>> init_excp_604() correctly sets env->hreset_vector=0xfff00000UL;
>>
>> but
>>
>> init_excp_7400() says env->hreset_vector=0x00000000UL;
>>
>> which seems wrong. (the 7400 manual says a hard-reset jumps
>> initializes the
>> prefix to 0xfff00000.)
> Do you have a link to a spec saying so? Should be trivial to change
> then.
>
>> Likewise, init_excp_7450() (and probably other, related CPUs) are
>> wrong.
>>
>> Indeed, when I change the value in init_excp_7400() to 0xfff00000UL
>> then
>> everything works as expected for me.
>>
>> ** Affects: qemu
>> Importance: Undecided
>> Status: New
>> Bug description:
>> I have a proprietary ROM implementing system calls that are executed
>> via the 'SC' instruction.
>>
>> I use qemu-0.14.1,
>>
>> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel
> We are currently in the process of revamping the PReP machine you are
> using above. Is your BIOS available publicly so that we can test we
> don't break anything for you?
>
> Andreas
>