From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOdQh-00038L-F5 for qemu-devel@nongnu.org; Mon, 01 Sep 2014 22:02:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOdQg-0001y5-53 for qemu-devel@nongnu.org; Mon, 01 Sep 2014 22:02:43 -0400 Received: from mail-oi0-x229.google.com ([2607:f8b0:4003:c06::229]:53948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOdQf-0001xt-V1 for qemu-devel@nongnu.org; Mon, 01 Sep 2014 22:02:42 -0400 Received: by mail-oi0-f41.google.com with SMTP id u20so3971893oif.14 for ; Mon, 01 Sep 2014 19:02:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <0c1ee01789620a0f3279c2acfc4e3794a4bee4b7.1408838440.git.alistair23@gmail.com> From: Alistair Francis Date: Tue, 2 Sep 2014 12:02:10 +1000 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH v1 5/5] Netduino: Add the Netduino Plus 2 Machine Model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Peter Crosthwaite , "qemu-devel@nongnu.org Developers" , Konstanty Bialkowski On Mon, Sep 1, 2014 at 10:44 PM, Peter Maydell wrote: > On 1 September 2014 13:34, Alistair Francis wrote: >> On Sun, Aug 24, 2014 at 11:20 PM, Peter Crosthwaite >> wrote: >>> Most of this function is the same as armv7m_init(). This seems the be >>> the main difference - the SRAM and FLASH setup. Everything else is >>> board-level additive. The fact that it's different means that either >>> ARMv7M should be parameterized, or Stellaris specific setup should be >>> pushed up to stellaris.c to get armv7m_init cleaned up into a state >>> where it's usable for you. >>> >>> Specifically, what in armv7m_init() is stopping the code share? > >> It is generally similar, although there are enough differences that I don't >> think it's wroth it. Ideally one day the Netduino Plus 2 will use a >> Cortex-M4 (one can hope) and this will need to be parameterised. >> The Netduino also has different base addresses >> which would need to be parameterised into armv7m_init(). The Netduio >> then has the memory alias as well as a different number of interrupt lines. >> >> It is because of all of these differences that I don't think it is worth using >> the armv7m_init() function. It's really not that much code. > > Yeah, but it's not really the right design IMHO. We should > have common armv7m init code for the parts which are > really "the CPU has all this" (including at least the bitbanding, > NVIC, memory mapped system registers, reset/ELF file > loading, etc), and board specific code in the board files. > Copying this code just because it's easier in the short > term leaves us still with the cleanup to do in the long term. > > You don't want to do this by parameterising flash/RAM > base addresses, incidentally -- you want to use memory > regions so the board sets up its devices in the right > places in system memory and then hands that off to > the v7M/SoC code level which adds the inside-the-CPU > devices. I'm confused about exactly what you mean. Do you mean take the memory initialisation out of the armv7m_init() function and let the board do that? Then the init function just does CPU, NVIC, ELF loading, bitbanding and the reset. Then I guess there could be a STM32F405 SoC device, similar to the A9 MPCore patch that I sent a while ago: https://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg03614.html Thanks, Alistair > > (There's almost certainly scope for QOMification in the > process of separating out the generic v7m from the board > code here too.) > > thanks > -- PMM