qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 5/5] Netduino: Add the Netduino Plus 2 Machin


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v1 5/5] Netduino: Add the Netduino Plus 2 Machine Model
Date: Mon, 1 Sep 2014 13:44:20 +0100

On 1 September 2014 13:34, Alistair Francis <address@hidden> wrote:
> On Sun, Aug 24, 2014 at 11:20 PM, Peter Crosthwaite
> <address@hidden> 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.

(There's almost certainly scope for QOMification in the
process of separating out the generic v7m from the board
code here too.)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]