On Mon, Sep 1, 2014 at 10:44 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 1 September 2014 13:34, Alistair Francis <alistai...@gmail.com> wrote: >> On Sun, Aug 24, 2014 at 11:20 PM, Peter Crosthwaite >> <peter.crosthwa...@xilinx.com> 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
