diff mbox

[v12,4/4] arm: SoC model for Calxeda Highbank

Message ID 1327008660-16789-5-git-send-email-mark.langsdorf@calxeda.com
State New
Headers show

Commit Message

Mark Langsdorf Jan. 19, 2012, 9:31 p.m. UTC
From: Rob Herring <rob.herring@calxeda.com>

Adds support for Calxeda's Highbank SoC.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
---
Changes from v11
 	Provided a meaningful board ID
	Added comments on the way the device tree memory values interact with
qemu command line arguments for memory
Changes from v10
        Added secondary core boot functions
Changes from v9
        Made typedef struct names in CamelCase
Changes from v7, v8
        None
Changes from v3, v4, v5, v6
        Skipped
Changes from v2
        Created a reset function for highbank_regs
        Handled creation of regs i/o memory region in a sensible manner
        Added code to boot secondary CPUs properly
Changes from v1
        Restructed the loading of sysram.bin and made it more clearly optional
        Made the regs structure into a proper qdev/sysbus object
        Removed some unnecessary include files
        Clarified the GPL version
        Simplified the reset function
        Removed the automatic detection and resetting of ram_size. Image MUST
be loaded with -m 4089 or it will crash
        Added a guard for xgmac creation
        Added a fuller description in the QEMUMachine .desc field

 Makefile.target |    1 +
 hw/highbank.c   |  327 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 328 insertions(+), 0 deletions(-)
 create mode 100644 hw/highbank.c

Comments

Peter Maydell Jan. 19, 2012, 9:44 p.m. UTC | #1
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
Rob Herring Jan. 19, 2012, 11:17 p.m. UTC | #2
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
John Williams Jan. 19, 2012, 11:41 p.m. UTC | #3
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
Peter Maydell Jan. 20, 2012, 8:47 a.m. UTC | #4
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
Rob Herring Jan. 20, 2012, 1:48 p.m. UTC | #5
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
Peter Maydell Jan. 20, 2012, 1:57 p.m. UTC | #6
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
Mark Langsdorf Jan. 20, 2012, 4:25 p.m. UTC | #7
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.
Peter Maydell Jan. 20, 2012, 4:27 p.m. UTC | #8
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
Mark Langsdorf Jan. 20, 2012, 4:57 p.m. UTC | #9
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.
Peter Maydell Jan. 20, 2012, 4:58 p.m. UTC | #10
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
Grant Likely Jan. 20, 2012, 6:27 p.m. UTC | #11
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.
Mark Langsdorf Jan. 20, 2012, 7:25 p.m. UTC | #12
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.
Peter Maydell Jan. 21, 2012, 2:35 a.m. UTC | #13
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
Peter Maydell Jan. 21, 2012, 2:39 a.m. UTC | #14
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
Grant Likely Jan. 23, 2012, 4:32 p.m. UTC | #15
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 mbox

Patch

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);