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

[Alistair Francis]

On Mon, Sep 1, 2014 at 10:44 PM, Peter Maydell <address@hidden> wrote:
> 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.

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