Hi,
Let me volunteer suggestions to at some of your questions.
Also (unrelated to the patch), somethings that I think
should be
discussed/addressed soon are:
- How we will handle the boards in nuttx (including variants like
US/EU version of the same phone)
Nuttx is designed to support a hiearchical configuration: processor family, chips in the
family, boards that host the chips, and board software configurations.
NuttX is configured with .config file. In that file you specify the family (ARM), the
chip (Calypso), and the board (also Calypso now?). The family corresponds to a directory
under arch/ (arch/arm) and the chip corresponds to sub-directories under arch/arm/src and
arch/arm/include (arch/arm/src/calypso and arch/arm/include/calypso).
* arch/arm/include holds general ARM header files
* arch/arm/include/calypso holds calypso specific header files
* arch/arm/src/calypso holds calypso specific source files
Boards are represented by directories under configs/. Right now, I think there is only a
configs/compal_e99.
* configs/compal_e99/include holds Compal E99 specific header files
* configs/compal_e99/src holds Compal E99 specific header files
Other directories under configs/compal_e99 can hold different software configurations for
the same board. For example, configs/compal_e99/ostest holds the make logic for the OS
test; configs/compal_e99/nsh would hold the NuttShell (NSH) make configuration files, etc.
The .config file, for example, is on of the software configuration files in those
directories (it is call defconfig before it is copied to the top-level directory as
.config).
You can see these settings in the .config/defconfig file:
CONFIG_ARCH=arm
CONFIG_ARCH_ARM=y
CONFIG_ARCH_ARM7TDMI=y
CONFIG_ARCH_CHIP=calypso
CONFIG_ARCH_CHIP_CALYPSO=y
CONFIG_ARCH_BOARD=compal_e99
CONFIG_ARCH_BOARD_COMPALE99=y
When the OS is configured, the top-level Makefile uses
these definitions to create symbolic links:
* arch/arm/src/chip will refer to arch/arm/src/calypso
* arch/arm/include/chip will refer to arch/arm/include/calypso
* arch/arm/include/board will refer to configs/compal_e99/include
* arch/arm/src/board will refer to configs/compal_e99/src.
And
* include/arch will refer to to arch/arm/include
So you can include ARM general header, calypso-specific, and board-specific header files
like:
#include <arch/arch.h> // architecture (ARM) specific header files
#include <arch/chip/chip.h> // Chip (calypso)
specific header files
#include <arch/board/board.h> // Board specific header files
So, if you want
to support the same processor (calypso) on a different board, say boardX, you could create
a directory:
configs/boardX
And put boardX specific header files and source files in:
configs/boardX/include
configs/boardX/src
And put boardX software
configurations under
config/boardX/configY
- How we will handle our different ram config (boot
from ram / flash),
can we use the loader to load part of the SDRAM if we
don't fit in
SRAM completely ?
I would think that these would correspond to different software build configuration
directories under configs/BoardX.
You also ask several memory related questions that I can't really answer. I think
there may be some additional memory management requirements here:
- How we will handle the memory zones (SRAM / SDRAM /
Flash / XIP from
flash (or just .rodata ?))
- Memory allocator (handling zones ...). I think that'd be something
very useful. Currently we can only allocate msgb and that's a little
limiting.
Right now, the memory allocator can handle multiple, discontinuous regions of memory.
There is an interface called mm_addregion() that can always add a new block of memory to
the memory pool.
But there is mechanism now to select which region memory will be allocated from. malloc()
is the only allocator for user programs. It will allocate memory only from the best
fitting free memory chunk, but does not take into account any properties of the memory.
Greg