Message ID | 1327008660-16789-5-git-send-email-mark.langsdorf@calxeda.com |
---|---|
State | New |
Headers | show |
On 19 January 2012 21:31, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote:
> + highbank_binfo.board_id = 0xEC10100f; /* provided by deviceTree */
Where does this number come from? It's not in
http://www.arm.linux.org.uk/developer/machines/
Is 3027 (==0xbd3) you?
http://www.arm.linux.org.uk/developer/machines/list.php?id=3027
-- PMM
On 01/19/2012 03:44 PM, Peter Maydell wrote: > On 19 January 2012 21:31, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: >> + highbank_binfo.board_id = 0xEC10100f; /* provided by deviceTree */ > > Where does this number come from? It's not in > http://www.arm.linux.org.uk/developer/machines/ > > Is 3027 (==0xbd3) you? > http://www.arm.linux.org.uk/developer/machines/list.php?id=3027 > Much of the data there is wrong as none of it is used. 0 or -1 is the right value as those are obviously meaningless. A highbank kernel will never be booted without devicetree and in that case this number is irrelevant. This is the legacy boot interface and qemu really needs to learn to boot with a separate dtb. Rob
On Fri, Jan 20, 2012 at 9:17 AM, Rob Herring <rob.herring@calxeda.com>wrote: > On 01/19/2012 03:44 PM, Peter Maydell wrote: > > On 19 January 2012 21:31, Mark Langsdorf <mark.langsdorf@calxeda.com> > wrote: > >> + highbank_binfo.board_id = 0xEC10100f; /* provided by deviceTree */ > > > > Where does this number come from? It's not in > > http://www.arm.linux.org.uk/developer/machines/ > > > > Is 3027 (==0xbd3) you? > > http://www.arm.linux.org.uk/developer/machines/list.php?id=3027 > > > > Much of the data there is wrong as none of it is used. 0 or -1 is the > right value as those are obviously meaningless. A highbank kernel will > never be booted without devicetree and in that case this number is > irrelevant. This is the legacy boot interface and qemu really needs to > learn to boot with a separate dtb. > We partially addressed this issue in our rejected device tree machine model patch series from last year. We added two new DTB-related arguments to the qemu cmdline: --kernel-dtb which is the DTB that gets passed through to the kernel, and --hw-dtb which is the DTB describing the actual hardware (we were making QDEV system models by scanning and parsing the device tree) If only a HW DTB is provided, then that same DTB is used for the kernel. There are situations when you might want them to be different. Rgds, John
On 19 January 2012 23:17, Rob Herring <rob.herring@calxeda.com> wrote: > On 01/19/2012 03:44 PM, Peter Maydell wrote: >> On 19 January 2012 21:31, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: >>> + highbank_binfo.board_id = 0xEC10100f; /* provided by deviceTree */ >> >> Where does this number come from? It's not in >> http://www.arm.linux.org.uk/developer/machines/ >> >> Is 3027 (==0xbd3) you? >> http://www.arm.linux.org.uk/developer/machines/list.php?id=3027 >> > > Much of the data there is wrong as none of it is used. 0 or -1 is the > right value as those are obviously meaningless. A highbank kernel will > never be booted without devicetree and in that case this number is > irrelevant. This is the legacy boot interface and qemu really needs to > learn to boot with a separate dtb. Yeah, but the documentation even for DTB boot says we should pass in a machine number. If 0 or -1 are right then there should be some documentation that says so. I'll accept "mailing list post from some authoritative person [eg Grant Likely]" if necessary. But this is an ABI between boot loaders and the kernel so I don't want to just have something random that happens to work. (And in particular if -1 is the officially sanctioned number then we need to fix arm_boot to be able to pass values >16 bits wide.) -- PMM
On 01/20/2012 02:47 AM, Peter Maydell wrote: > On 19 January 2012 23:17, Rob Herring <rob.herring@calxeda.com> wrote: >> On 01/19/2012 03:44 PM, Peter Maydell wrote: >>> On 19 January 2012 21:31, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: >>>> + highbank_binfo.board_id = 0xEC10100f; /* provided by deviceTree */ >>> >>> Where does this number come from? It's not in >>> http://www.arm.linux.org.uk/developer/machines/ >>> >>> Is 3027 (==0xbd3) you? >>> http://www.arm.linux.org.uk/developer/machines/list.php?id=3027 >>> >> >> Much of the data there is wrong as none of it is used. 0 or -1 is the >> right value as those are obviously meaningless. A highbank kernel will >> never be booted without devicetree and in that case this number is >> irrelevant. This is the legacy boot interface and qemu really needs to >> learn to boot with a separate dtb. > > Yeah, but the documentation even for DTB boot says we should pass > in a machine number. If 0 or -1 are right then there should be > some documentation that says so. I'll accept "mailing list post > from some authoritative person [eg Grant Likely]" if necessary. Kernel DT co-maintainer is not authoritative enough for you? The documentation needs some clarification. > But this is an ABI between boot loaders and the kernel so I don't > want to just have something random that happens to work. (And in > particular if -1 is the officially sanctioned number then we need > to fix arm_boot to be able to pass values >16 bits wide.) > Here's were the kernel sets the mach #. nr is from the database for non-DT and ~0 for DT machines. #define MACHINE_START(_type,_name) \ static const struct machine_desc __mach_desc_##_type \ __used \ __attribute__((__section__(".arch.info.init"))) = { \ .nr = MACH_TYPE_##_type, \ .name = _name, #define MACHINE_END \ }; #define DT_MACHINE_START(_name, _namestr) \ static const struct machine_desc __mach_desc_##_name \ __used \ __attribute__((__section__(".arch.info.init"))) = { \ .nr = ~0, \ .name = _namestr, In any case, the kernel ignores the value passed in if a valid dtb is passed in. Rob
On 20 January 2012 13:48, Rob Herring <rob.herring@calxeda.com> wrote: > Kernel DT co-maintainer is not authoritative enough for you? Only if I recognise their name :-) [ie, sorry.] > The documentation needs some clarification. > >> But this is an ABI between boot loaders and the kernel so I don't >> want to just have something random that happens to work. (And in >> particular if -1 is the officially sanctioned number then we need >> to fix arm_boot to be able to pass values >16 bits wide.) >> > > Here's were the kernel sets the mach #. nr is from the database for > non-DT and ~0 for DT machines. > > #define MACHINE_START(_type,_name) \ > static const struct machine_desc __mach_desc_##_type \ > __used \ > __attribute__((__section__(".arch.info.init"))) = { \ > .nr = MACH_TYPE_##_type, \ > .name = _name, > > #define MACHINE_END \ > }; > > #define DT_MACHINE_START(_name, _namestr) \ > static const struct machine_desc __mach_desc_##_name \ > __used \ > __attribute__((__section__(".arch.info.init"))) = { \ > .nr = ~0, \ > .name = _namestr, > > In any case, the kernel ignores the value passed in if a valid dtb is > passed in. I wonder if we should be passing in anything-except-minus-1, since if you pass -1 and no DT then the kernel will fail silently, whereas if you pass something else and no DT the kernel will complain about the mismatch. Even when we add a --dtb foo option to qemu, there's bound to be a pile of user error where users pass in --kernel but not --dtb. -- PMM
On 01/20/2012 07:48 AM, Rob Herring wrote: > On 01/20/2012 02:47 AM, Peter Maydell wrote: >> On 19 January 2012 23:17, Rob Herring <rob.herring@calxeda.com> wrote: >>> On 01/19/2012 03:44 PM, Peter Maydell wrote: >>>> On 19 January 2012 21:31, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: >>>>> + highbank_binfo.board_id = 0xEC10100f; /* provided by deviceTree */ >>>> >>>> Where does this number come from? It's not in >>>> http://www.arm.linux.org.uk/developer/machines/ >>>> >>>> Is 3027 (==0xbd3) you? >>>> http://www.arm.linux.org.uk/developer/machines/list.php?id=3027 >>>> >>> >>> Much of the data there is wrong as none of it is used. 0 or -1 is the >>> right value as those are obviously meaningless. A highbank kernel will >>> never be booted without devicetree and in that case this number is >>> irrelevant. This is the legacy boot interface and qemu really needs to >>> learn to boot with a separate dtb. >> >> Yeah, but the documentation even for DTB boot says we should pass >> in a machine number. If 0 or -1 are right then there should be >> some documentation that says so. I'll accept "mailing list post >> from some authoritative person [eg Grant Likely]" if necessary. > > Kernel DT co-maintainer is not authoritative enough for you? Peter, is that sufficient for me to send in the patch with a board_id of -1? Thanks. --Mark Langsdorf Calxeda, Inc.
On 20 January 2012 16:25, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: > On 01/20/2012 07:48 AM, Rob Herring wrote: >> On 01/20/2012 02:47 AM, Peter Maydell wrote: >>> On 19 January 2012 23:17, Rob Herring <rob.herring@calxeda.com> wrote: >>>> On 01/19/2012 03:44 PM, Peter Maydell wrote: >>>>> On 19 January 2012 21:31, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: >>>>>> + highbank_binfo.board_id = 0xEC10100f; /* provided by deviceTree */ >>>>> >>>>> Where does this number come from? It's not in >>>>> http://www.arm.linux.org.uk/developer/machines/ >>>>> >>>>> Is 3027 (==0xbd3) you? >>>>> http://www.arm.linux.org.uk/developer/machines/list.php?id=3027 >>>>> >>>> >>>> Much of the data there is wrong as none of it is used. 0 or -1 is the >>>> right value as those are obviously meaningless. A highbank kernel will >>>> never be booted without devicetree and in that case this number is >>>> irrelevant. This is the legacy boot interface and qemu really needs to >>>> learn to boot with a separate dtb. >>> >>> Yeah, but the documentation even for DTB boot says we should pass >>> in a machine number. If 0 or -1 are right then there should be >>> some documentation that says so. I'll accept "mailing list post >>> from some authoritative person [eg Grant Likely]" if necessary. >> >> Kernel DT co-maintainer is not authoritative enough for you? > > Peter, is that sufficient for me to send in the patch with a > board_id of -1? Thanks. 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"... -- PMM
On 01/20/2012 10:27 AM, Peter Maydell wrote: > On 20 January 2012 16:25, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: >> On 01/20/2012 07:48 AM, Rob Herring wrote: >>> On 01/20/2012 02:47 AM, Peter Maydell wrote: >>>> On 19 January 2012 23:17, Rob Herring <rob.herring@calxeda.com> wrote: >>>>> On 01/19/2012 03:44 PM, Peter Maydell wrote: >>>>>> On 19 January 2012 21:31, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: >>>>>>> + highbank_binfo.board_id = 0xEC10100f; /* provided by deviceTree */ >>>>>> >>>>>> Where does this number come from? It's not in >>>>>> http://www.arm.linux.org.uk/developer/machines/ >>>>>> >>>>>> Is 3027 (==0xbd3) you? >>>>>> http://www.arm.linux.org.uk/developer/machines/list.php?id=3027 >>>>>> >>>>> >>>>> Much of the data there is wrong as none of it is used. 0 or -1 is the >>>>> right value as those are obviously meaningless. A highbank kernel will >>>>> never be booted without devicetree and in that case this number is >>>>> irrelevant. This is the legacy boot interface and qemu really needs to >>>>> learn to boot with a separate dtb. >>>> >>>> Yeah, but the documentation even for DTB boot says we should pass >>>> in a machine number. If 0 or -1 are right then there should be >>>> some documentation that says so. I'll accept "mailing list post >>>> from some authoritative person [eg Grant Likely]" if necessary. >>> >>> Kernel DT co-maintainer is not authoritative enough for you? >> >> Peter, is that sufficient for me to send in the patch with a >> board_id of -1? Thanks. > > 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. --Mark Langsdorf Calxeda, Inc.
On 20 January 2012 16:57, Mark Langsdorf <mark.langsdorf@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.) -- PMM
On Fri, Jan 20, 2012 at 01:57:29PM +0000, Peter Maydell wrote: > On 20 January 2012 13:48, Rob Herring <rob.herring@calxeda.com> wrote: > > Kernel DT co-maintainer is not authoritative enough for you? > > Only if I recognise their name :-) [ie, sorry.] > > > The documentation needs some clarification. > > > >> But this is an ABI between boot loaders and the kernel so I don't > >> want to just have something random that happens to work. (And in > >> particular if -1 is the officially sanctioned number then we need > >> to fix arm_boot to be able to pass values >16 bits wide.) > >> > > > > Here's were the kernel sets the mach #. nr is from the database for > > non-DT and ~0 for DT machines. > > > > #define MACHINE_START(_type,_name) \ > > static const struct machine_desc __mach_desc_##_type \ > > __used \ > > __attribute__((__section__(".arch.info.init"))) = { \ > > .nr = MACH_TYPE_##_type, \ > > .name = _name, > > > > #define MACHINE_END \ > > }; > > > > #define DT_MACHINE_START(_name, _namestr) \ > > static const struct machine_desc __mach_desc_##_name \ > > __used \ > > __attribute__((__section__(".arch.info.init"))) = { \ > > .nr = ~0, \ > > .name = _namestr, > > > > In any case, the kernel ignores the value passed in if a valid dtb is > > passed in. > > I wonder if we should be passing in anything-except-minus-1, > since if you pass -1 and no DT then the kernel will fail > silently, whereas if you pass something else and no DT the > kernel will complain about the mismatch. Alternately, we can make the kernel always complain about machine type ~0, which is probably safer anyway. g.
On 01/20/2012 10:58 AM, Peter Maydell wrote: > On 20 January 2012 16:57, Mark Langsdorf <mark.langsdorf@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.
On 20 January 2012 19:25, Mark Langsdorf <mark.langsdorf@calxeda.com> wrote: > 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. You may recall that when you first sent the patch with highbank_cpu_reset I said it looked like the resets would be in the wrong order, and you assured me they weren't :-) (Commit 2be276242 is the SCU register change, incidentally, and doesn't seem relevant; did you mean some other commit?) > 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()? Reset callbacks aren't supposed to do things such that they care about what order they're called in. This one does because we're uncleanly reaching into the CPUState from the highbank reset callback rather than doing CPU reset in the CPU proper. I was willing to let that pass since it happened to work OK and we didn't have a clean mechanism to hand, but if it doesn't work anyhow I guess we need to rethink. I can't think of anything nicer (since we don't have a proper qdev object to set properties on) than adding code to cpu_reset() which saves the value of env->cp15_config_base_address across the memset(). That's quite ugly but will work. [And in fact we'd need that even with a hypothetical qdev property because the property would only set the state field once at init, and we'd need to avoid the memset() on reset trashing it. There's an argument that it's the block memset() that's ugly...] OTOH it's 2.30am here so I may be missing a nicer approach. Suggestions welcome. -- PMM
On 20 January 2012 18:27, Grant Likely <grant.likely@secretlab.ca> wrote: > On Fri, Jan 20, 2012 at 01:57:29PM +0000, Peter Maydell wrote: >> I wonder if we should be passing in anything-except-minus-1, >> since if you pass -1 and no DT then the kernel will fail >> silently, whereas if you pass something else and no DT the >> kernel will complain about the mismatch. > > Alternately, we can make the kernel always complain about machine type > ~0, which is probably safer anyway. That sounds like a good idea to me. -- PMM
Hey Peter, I need some advice. I'm adding a -dtb option to qemu for specifying a dtb filename to be passed on to the kernel, similar to how the -initrd flag works. The dtb filename needs to then be passed on to the selected machine, and it looks like the machine->init() callback is the best way to do that. However, the current init callback prototype looks like this: typedef void QEMUMachineInitFunc(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); Now, I could simply add an new "dtb_filename" to the argument list and fix up all of the users (looks to be about 90 machines), but that seems like a lot of churn that will need to be repeated the next time a new argument needs to be passed to the init func. Alternately, I could do something like this: struct machine_args { ram_addr_t ram_size; const char *boot_device; const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *dtb_filename, const char *cpu_model, }; typedef void QEMUMachineInitFunc(const struct machine_args *args); And then I'd fix up all the users, which would be about the same amount of churn, but subsequent additions would be a lot easier. A third option would be to add a new ".dt_init()" that is executed instead of .init() if populated, but that seems like an ugly band-aid to me. How should I approach this? Or is there a better way to pass data to so that it is available at machine->init() time? g.
diff --git a/Makefile.target b/Makefile.target index 9bc0248..1c86522 100644 --- a/Makefile.target +++ b/Makefile.target @@ -342,6 +342,7 @@ obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o obj-arm-y += arm_l2x0.o obj-arm-y += arm_mptimer.o obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o +obj-arm-y += highbank.o obj-arm-y += pl061.o obj-arm-y += xgmac.o obj-arm-y += arm-semi.o diff --git a/hw/highbank.c b/hw/highbank.c new file mode 100644 index 0000000..a79d0e8 --- /dev/null +++ b/hw/highbank.c @@ -0,0 +1,327 @@ +/* + * Calxeda Highbank SoC emulation + * + * Copyright (c) 2010-2012 Calxeda + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2 or later, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not, see <http://www.gnu.org/licenses/>. + * + */ + +#include "sysbus.h" +#include "arm-misc.h" +#include "primecell.h" +#include "devices.h" +#include "loader.h" +#include "net.h" +#include "sysemu.h" +#include "boards.h" +#include "sysbus.h" +#include "blockdev.h" +#include "exec-memory.h" + +#define SMP_BOOT_ADDR 0x100 +#define SMP_BOOT_REG 0x40 +#define GIC_BASE_ADDR 0xfff10000 + +#define NIRQ_GIC 160 + +/* Board init. */ +static void highbank_cpu_reset(void *opaque) +{ + CPUState *env = opaque; + + env->cp15.c15_config_base_address = 0xfff10000; +} + +static void hb_write_secondary(CPUState *env, const struct arm_boot_info *info) +{ + int n; + uint32_t smpboot[] = { + 0xee100fb0, /* mrc p15, 0, r0, c0, c0, 5 - read current core id */ + 0xe210000f, /* ands r0, r0, #0x0f */ + 0xe3a03040, /* mov r3, #0x40 - jump address is 0x40 + 0x10 * core id */ + 0xe0830200, /* add r0, r3, r0, lsl #4 */ + 0xe59f2018, /* ldr r2, privbase */ + 0xe3a01001, /* mov r1, #1 */ + 0xe5821100, /* str r1, [r2, #256] */ + 0xe320f003, /* wfi */ + 0xe5901000, /* ldr r1, [r0] */ + 0xe1110001, /* tst r1, r1 */ + 0x0afffffb, /* beq <wfi> */ + 0xe12fff11, /* bx r1 */ + GIC_BASE_ADDR /* privbase: gic address. */ + }; + for (n = 0; n < ARRAY_SIZE(smpboot); n++) { + smpboot[n] = tswap32(smpboot[n]); + } + rom_add_blob_fixed("smpboot", smpboot, sizeof(smpboot), SMP_BOOT_ADDR); +} + +static void hb_reset_secondary(CPUState *env, const struct arm_boot_info *info) +{ + switch (info->nb_cpus) { + case 4: + stl_phys_notdirty(SMP_BOOT_REG + 0x30, 0); + case 3: + stl_phys_notdirty(SMP_BOOT_REG + 0x20, 0); + case 2: + stl_phys_notdirty(SMP_BOOT_REG + 0x10, 0); + env->regs[15] = SMP_BOOT_ADDR; + break; + default: + break; + } +} + +#define NUM_REGS 0x200 +static void hb_regs_write(void *opaque, target_phys_addr_t offset, + uint64_t value, unsigned size) +{ + uint32_t *regs = opaque; + + if (offset == 0xf00) { + if (value == 1 || value == 2) { + qemu_system_reset_request(); + } else if (value == 3) { + qemu_system_shutdown_request(); + } + } + + regs[offset/4] = value; +} + +static uint64_t hb_regs_read(void *opaque, target_phys_addr_t offset, + unsigned size) +{ + uint32_t *regs = opaque; + uint32_t value = regs[offset/4]; + + if ((offset == 0x100) || (offset == 0x108) || (offset == 0x10C)) { + value |= 0x30000000; + } + + return value; +} + +static const MemoryRegionOps hb_mem_ops = { + .read = hb_regs_read, + .write = hb_regs_write, + .endianness = DEVICE_NATIVE_ENDIAN, +}; + +typedef struct { + SysBusDevice busdev; + MemoryRegion *iomem; + uint32_t regs[NUM_REGS]; +} HighbankRegsState; + +static VMStateDescription vmstate_highbank_regs = { + .name = "highbank-regs", + .version_id = 0, + .minimum_version_id = 0, + .minimum_version_id_old = 0, + .fields = (VMStateField[]) { + VMSTATE_UINT32_ARRAY(regs, HighbankRegsState, NUM_REGS), + VMSTATE_END_OF_LIST(), + }, +}; + +static void highbank_regs_reset(DeviceState *dev) +{ + SysBusDevice *sys_dev = sysbus_from_qdev(dev); + HighbankRegsState *s = FROM_SYSBUS(HighbankRegsState, sys_dev); + + s->regs[0x40] = 0x05F20121; + s->regs[0x41] = 0x2; + s->regs[0x42] = 0x05F30121; + s->regs[0x43] = 0x05F40121; +} + +static int highbank_regs_init(SysBusDevice *dev) +{ + HighbankRegsState *s = FROM_SYSBUS(HighbankRegsState, dev); + + s->iomem = g_new(MemoryRegion, 1); + memory_region_init_io(s->iomem, &hb_mem_ops, s->regs, "highbank_regs", + 0x1000); + sysbus_init_mmio(dev, s->iomem); + + return 0; +} + +static SysBusDeviceInfo highbank_regs_info = { + .init = highbank_regs_init, + .qdev.name = "highbank-regs", + .qdev.desc = "Calxeda Highbank registers", + .qdev.size = sizeof(HighbankRegsState), + .qdev.vmsd = &vmstate_highbank_regs, + .qdev.reset = highbank_regs_reset, +}; + +static void highbank_regs_register_device(void) +{ + sysbus_register_withprop(&highbank_regs_info); +} + +device_init(highbank_regs_register_device) + +static struct arm_boot_info highbank_binfo; + +/* ram_size must be set to match the upper bound of memory in the + * device tree (linux/arch/arm/boot/dts/highbank.dts), which is + * normally 0xff900000 or -m 4089. When running this board on a + * 32-bit host, set the reg value of memory to 0xf7ff00000 in the + * device tree and pass -m 2047 + */ +static void highbank_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) +{ + CPUState *env = NULL; + DeviceState *dev; + SysBusDevice *busdev; + qemu_irq *irqp; + qemu_irq pic[128]; + int n; + qemu_irq cpu_irq[4]; + MemoryRegion *sysram; + MemoryRegion *dram; + MemoryRegion *sysmem; + char *sysboot_filename; + + if (!cpu_model) { + cpu_model = "cortex-a9"; + } + + for (n = 0; n < smp_cpus; n++) { + env = cpu_init(cpu_model); + if (!env) { + fprintf(stderr, "Unable to find CPU definition\n"); + exit(1); + } + irqp = arm_pic_init_cpu(env); + cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ]; + qemu_register_reset(highbank_cpu_reset, env); + } + + sysmem = get_system_memory(); + dram = g_new(MemoryRegion, 1); + memory_region_init_ram(dram, "highbank.dram", ram_size); + /* SDRAM at address zero. */ + memory_region_add_subregion(sysmem, 0, dram); + + sysram = g_new(MemoryRegion, 1); + memory_region_init_ram(sysram, "highbank.sysram", 0x8000); + memory_region_add_subregion(sysmem, 0xfff88000, sysram); + if (bios_name != NULL) { + sysboot_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name); + if (sysboot_filename != NULL) { + uint32_t filesize = get_image_size(sysboot_filename); + if (load_image_targphys("sysram.bin", 0xfff88000, filesize) < 0) { + hw_error("Unable to load %s\n", bios_name); + } + } else { + hw_error("Unable to find %s\n", bios_name); + } + } + + dev = qdev_create(NULL, "a9mpcore_priv"); + qdev_prop_set_uint32(dev, "num-cpu", smp_cpus); + qdev_prop_set_uint32(dev, "num-irq", NIRQ_GIC); + qdev_init_nofail(dev); + busdev = sysbus_from_qdev(dev); + sysbus_mmio_map(busdev, 0, GIC_BASE_ADDR); + for (n = 0; n < smp_cpus; n++) { + sysbus_connect_irq(busdev, n, cpu_irq[n]); + } + + for (n = 0; n < 128; n++) { + pic[n] = qdev_get_gpio_in(dev, n); + } + + dev = qdev_create(NULL, "l2x0"); + qdev_init_nofail(dev); + busdev = sysbus_from_qdev(dev); + sysbus_mmio_map(busdev, 0, 0xfff12000); + + dev = qdev_create(NULL, "sp804"); + qdev_prop_set_uint32(dev, "freq0", 150000000); + qdev_prop_set_uint32(dev, "freq1", 150000000); + qdev_init_nofail(dev); + busdev = sysbus_from_qdev(dev); + sysbus_mmio_map(busdev, 0, 0xfff34000); + sysbus_connect_irq(busdev, 0, pic[18]); + sysbus_create_simple("pl011", 0xfff36000, pic[20]); + + dev = qdev_create(NULL, "highbank-regs"); + qdev_init_nofail(dev); + busdev = sysbus_from_qdev(dev); + sysbus_mmio_map(busdev, 0, 0xfff3c000); + + sysbus_create_simple("pl061", 0xfff30000, pic[14]); + sysbus_create_simple("pl061", 0xfff31000, pic[15]); + sysbus_create_simple("pl061", 0xfff32000, pic[16]); + sysbus_create_simple("pl061", 0xfff33000, pic[17]); + sysbus_create_simple("pl031", 0xfff35000, pic[19]); + sysbus_create_simple("pl022", 0xfff39000, pic[23]); + + sysbus_create_simple("sysbus-ahci", 0xffe08000, pic[83]); + + if (nd_table[0].vlan) { + qemu_check_nic_model(&nd_table[0], "xgmac"); + dev = qdev_create(NULL, "xgmac"); + qdev_set_nic_properties(dev, &nd_table[0]); + qdev_init_nofail(dev); + sysbus_mmio_map(sysbus_from_qdev(dev), 0, 0xfff50000); + sysbus_connect_irq(sysbus_from_qdev(dev), 0, pic[77]); + sysbus_connect_irq(sysbus_from_qdev(dev), 1, pic[78]); + sysbus_connect_irq(sysbus_from_qdev(dev), 2, pic[79]); + + qemu_check_nic_model(&nd_table[1], "xgmac"); + dev = qdev_create(NULL, "xgmac"); + qdev_set_nic_properties(dev, &nd_table[1]); + qdev_init_nofail(dev); + sysbus_mmio_map(sysbus_from_qdev(dev), 0, 0xfff51000); + sysbus_connect_irq(sysbus_from_qdev(dev), 0, pic[80]); + sysbus_connect_irq(sysbus_from_qdev(dev), 1, pic[81]); + sysbus_connect_irq(sysbus_from_qdev(dev), 2, pic[82]); + } + + 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 = 0xEC10100f; /* provided by deviceTree */ + highbank_binfo.nb_cpus = smp_cpus; + highbank_binfo.loader_start = 0; + highbank_binfo.write_secondary_boot = hb_write_secondary; + highbank_binfo.secondary_cpu_reset_hook = hb_reset_secondary; + arm_load_kernel(first_cpu, &highbank_binfo); +} + +static QEMUMachine highbank_machine = { + .name = "highbank", + .desc = "Calxeda Highbank (ECX-1000)", + .init = highbank_init, + .use_scsi = 1, + .max_cpus = 4, + .no_vga = 1, +}; + +static void highbank_machine_init(void) +{ + qemu_register_machine(&highbank_machine); +} + +machine_init(highbank_machine_init);