From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42954) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSnAx-0002EA-KE for qemu-devel@nongnu.org; Sun, 06 Oct 2013 08:11:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSnAs-0005i3-6g for qemu-devel@nongnu.org; Sun, 06 Oct 2013 08:11:07 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:65183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSnAr-0005hk-Vc for qemu-devel@nongnu.org; Sun, 06 Oct 2013 08:11:02 -0400 Received: by mail-lb0-f178.google.com with SMTP id z5so4673759lbh.37 for ; Sun, 06 Oct 2013 05:11:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Peter Maydell Date: Sun, 6 Oct 2013 21:10:40 +0900 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] Update the id of Vexpress Cortex-A9 from r0p0 to r0p1? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mian Yousaf Kaukab Cc: QEMU Developers On 6 October 2013 20:12, Mian Yousaf Kaukab wrote: > Default vexpress_defconfig does not boot on qemu vexpress-a9 target. In kernel, > vexpress uart detection for DEBUG_LL is done using Coretex-A9 id. Only r0p1 is > mapped to legacy map. All other variants are mapped to RS1/aseries map. Detecting the board model based on the CPU revision-and-patchlevel is a horrible hack and I wish the kernel guys would drop it. Really the kernel should provide a way to specify (in the device tree or otherwise) where the UART is, in a way that the early kernel code can easily get at to use for its earlyprint uart. > As qemu vexpress-a9 target reports Cortex-A9 version as r0p0, kernel maps uart0 > at address 0x1c090000 instead of 0x10009000. This result in kernel indefinitely > waiting for uart during boot. A kernel patch to fix this was discussed > in the following link > http://comments.gmane.org/gmane.linux.ports.arm.kernel/269657 . > In this discussion Pawel Moll mentioned that V2P-CA9 has Cortex-A9 r0p1 and not > r0p0. If this is correct, to fix this and similar future problems, shouldn't > qemu Cortex-A9 be updated to version r0p1? The trouble is that QEMU models CPUs and boards separately and doesn't model every single variant/patchlevel of each CPU, because that would be a fairly large amount of extra effort. > So what will it take to update the id of Cortex-A9 in qemu from r0p0 to r0p1? If we're updating, why would we update only to r0p1 and not to the most recent rev/patchlevel? The major thing we need is a mechanism for allowing at least the board, and possibly also the user, to specify properties of the cpu like "which rev/patchlevel is it" (being able to specify "do we have an fpu/neon/etc" is a similar thing). If we had that it would not be too hard to then have the vexpress-a9 board specify which rev/patchlevel to use. But we don't have the mechanism currently. -- PMM