Nuttx for Calypso

Gregory Nutt spudarnia at yahoo.com
Mon May 23 21:14:52 UTC 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110523/966bfc6e/attachment.html>


More information about the baseband-devel mailing list