On Wed, Jun 27, 2012 at 11:04 PM, Andreas Färber <afaer...@suse.de> wrote:
> Am 27.06.2012 14:25, schrieb Peter Crosthwaite:
>> Hi Jia,
>>
>> On Wed, Jun 27, 2012 at 7:54 PM, Jia Liu <pro...@gmail.com> wrote:
>>> +static void openrisc_sim_init(ram_addr_t ram_size,
>>> + const char *boot_device,
>>> + const char *kernel_filename,
>>> + const char *kernel_cmdline,
>>> + const char *initrd_filename,
>>> + const char *cpu_model)
>>> +{
>>> + CPUOpenRISCState *env;
>>> + MemoryRegion *ram = g_new(MemoryRegion, 1);
>>> +
>>> + if (!cpu_model) {
>>> + cpu_model = "or1200";
>>> + }
>>> + env = cpu_init(cpu_model);
>>> + if (!env) {
>>> + fprintf(stderr, "Unable to find CPU definition!\n");
>>> + exit(1);
>>> + }
>>> +
>>> + qemu_register_reset(main_cpu_reset, env);
>>> + main_cpu_reset(env);
>>> +
>>
>> I think this needs rebasing. Andreas a while back abstracted back to
>> the CPU level instead for resets. Andreas can you confirm? should this
>> be changed to pass the CPU QOM object to the reset instead? cc
>> andreas.
>
> Thought I had commented that already... maybe I'm starting to confuse
> uc32 and or32? :) Yes please, cpu_or32_init() should be called and
> return an OpenRISCCPU *cpu. main_cpu_reset() should be passed the cpu,
> too. All new APIs (static helpers etc.) should use OpenRISCCPU, not
> CPUOpenRISCState.
That rule has significant impact on patches 9-10. Andreas, you may
wish to check these out - they are psuedo device-models tightly
coupled to the cpu env.
Regards,
Peter
That will greatly simplify moving forward.
>
> Thanks for catching this, Peter.
>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
