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

[Grant Likely <grant.likely@secretlab.ca>]

On Fri, Jan 20, 2012 at 07:48:09AM -0600, 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?
> 
> 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.)
> > 

I've got a patch that fixes arm_boot.  I'll send it separately.

How about this patch for the kernel:

g.

---

diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
index a341d87..72b064d 100644
--- a/Documentation/arm/Booting
+++ b/Documentation/arm/Booting
@@ -148,7 +148,9 @@ In either case, the following conditions must be met:
 
 - CPU register settings
   r0 = 0,
-  r1 = machine type number discovered in (3) above.
+  r1 = machine type number discovered in (3) above, or if booting with
+       a dtb then this may be set to ~0 if a valid MACH_TYPE_xxx value
+       does not exist for the machine.
   r2 = physical address of tagged list in system RAM, or
        physical address of device tree block (dtb) in system RAM
 
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index 7c1329d..33e2b51 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -176,7 +176,8 @@ it with special cases.
 
                 r1 : Valid machine type number.  When using a device tree,
                 a single machine type number will often be assigned to
-                represent a class or family of SoCs.
+                represent a class or family of SoCs.  If a valid machine
+                type number is not assigned, then use ~0.
 
                 r2 : physical pointer to the device-tree block
                 (defined in chapter II) in RAM.  Device tree can be located