From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoEpB-0005HE-MI for qemu-devel@nongnu.org; Fri, 20 Jan 2012 08:48:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoEp9-0000UH-V6 for qemu-devel@nongnu.org; Fri, 20 Jan 2012 08:48:13 -0500 Received: from smtp141.dfw.emailsrvr.com ([67.192.241.141]:39222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoEp9-0000UD-Ow for qemu-devel@nongnu.org; Fri, 20 Jan 2012 08:48:11 -0500 Message-ID: <4F197099.2020708@calxeda.com> Date: Fri, 20 Jan 2012 07:48:09 -0600 From: Rob Herring MIME-Version: 1.0 References: <1326213943-878-1-git-send-email-mark.langsdorf@calxeda.com> <1327008660-16789-1-git-send-email-mark.langsdorf@calxeda.com> <1327008660-16789-5-git-send-email-mark.langsdorf@calxeda.com> <4F18A475.80009@calxeda.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Mark Langsdorf , i.mitsyanko@gmail.com, qemu-devel@nongnu.org, Grant Likely , edgar.iglesias@gmail.com, afaerber@suse.de On 01/20/2012 02:47 AM, Peter Maydell wrote: > On 19 January 2012 23:17, Rob Herring wrote: >> On 01/19/2012 03:44 PM, Peter Maydell wrote: >>> On 19 January 2012 21:31, Mark Langsdorf 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