Re: [Qemu-devel] [PATCH v10 4/5] arm: SoC model for Calxeda Highbank

[Mark Langsdorf <mark.langsdorf@calxeda.com>]

On 01/17/2012 09:13 AM, Peter Maydell wrote:
> On 17 January 2012 13:50, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote:
>> +    highbank_binfo.ram_size = ram_size;
>> +    highbank_binfo.kernel_filename = kernel_filename;
>> +    highbank_binfo.kernel_cmdline = kernel_cmdline;
>> +    highbank_binfo.initrd_filename = initrd_filename;
>> +    highbank_binfo.board_id = -1; /* provided by deviceTree */
>> +    highbank_binfo.nb_cpus = smp_cpus;
>> +    highbank_binfo.loader_start = 0;
>> +    highbank_binfo.smp_loader_start = SMP_BOOT_ADDR;
>> +    arm_load_kernel(env, &highbank_binfo);
> 
> Unfortunately for you Evgeny's patch to arm_boot.c has been
> committed to master (commit 078758d0) which means you need
> to update this to specify a value for highbank_binfo.smp_bootreg_addr.
> 
> Incidentally I'm surprised this worked for you at all -- before
> Evgeny's patch the secondary bootloader code in arm_boot.c would
> have been polling 0x10000030, which the highbank kernel code
> doesn't ever change, so I don't see how you got the secondary
> cores into the kernel when using -kernel...

I think I was undertesting.

I can set the smp_loader code so that I can boot 2 cpus
and verify their existence in /proc/cpuinfo, but I can't
get 3 cpus to boot at all, no matter how I hack the existing
arm_boot code.

Is there a good example of how to write secondary smp boot
code other than arm_boot.c? Should I just expect to pull
most of arm_boot.c into highbank and adjust from there? I
don't want to duplicate code like that, but I need more
flexibility than I can easily add to arm_boot.c.

--Mark Langsdorf
Calxeda, Inc.