On 01/20/2012 10:58 AM, Peter Maydell wrote: > On 20 January 2012 16:57, Mark Langsdorf <mark.langsd...@calxeda.com> 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.
