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

[Mark Langsdorf]

On 01/20/2012 10:58 AM, Peter Maydell wrote:
> On 20 January 2012 16:57, Mark Langsdorf <address@hidden> wrote:
>> On 01/20/2012 10:27 AM, Peter Maydell wrote:
>>> It's still not clear to me from this conversation if the right
>>> answer is "0", "-1" or "anything that's not a valid board ID
>>> and not -1 either"...
>>
>> Quoting Rob from upthread:
>> "0 or -1 is the right value as those are obviously meaningless."
>>
>> The original code that Rob wrote had a board_id of -1. That's
>> the right answer.
> 
> In that case you need a patch that causes arm_boot to actually
> pass -1, not 0xffff.
> 
> (Also it would be nice if the kernel barfed if (id == -1 and
> there's no appended device tree), but that's not a qemu thing.)

It looks like there's an issue with commit 2be276242135eac6,
in that target-arm/helper.c:cpu_reset() is called after
hw/highbank.c:highbank_cpu_reset() and keeps clobbering
our c15_config_base_address. So when the kernel attempts to
read that address, it gets a 0, and it never accesses the
GIC code but instead reads the value of the hw/arm_boot.c:
bootloader[] array (loaded into ROM at address 0).

Is there a way to prioritize the callbacks or something
so that arm's cpu_reset() doesn't clobber highbank's
cpu_reset()? Alternately, is there some other way to
set c15 values outside of cpu_reset()?

--Mark Langsdorf
Calxeda, Inc.