Nuttx for Calypso

Harald Welte laforge at gnumonks.org
Tue May 24 07:59:52 UTC 2011


Gregory,

thanks a lot for your detailed response.

On Mon, May 23, 2011 at 02:14:52PM -0700, Gregory Nutt wrote:

> Nuttx is designed to support a hiearchical configuration:  processor
> family, chips in the family, boards that host the chips, and board
> software configurations. [..]

I think there is no obvious missing part from our requirements point of view.

> 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.

btw: there is no SDRAM.  IT's SRAM, but there is external SRAM (slow)
and internal SRAM (fast), as well eas external NOR flash.  The normal
procedure is to use section attributes in the code to determine which
parts of the code get put into what part of memory.  I think Nuttx
doesn't care much about this, except that we will have custom linker
scripts that will produce output for the different memory regions.

I think the division will be roughly:
* internal SRAM
 * super time critical code like FIQ handler for GSM TDMA
 * IRQ and FIQ stack
 * normal process stack?
* external SRAM
* external NOR flash
 * bootloader
 * .text segment of Nuttx, XIP
 * filesystem

this is at least the configuration that would make most sense for the
final version.  During development (so far) we have been using no code
in flash, and always loaded our code into RAM on every boot.  This is
definitely also a configuration that would make sense to have with
Nuttx.  But here it would probably make even more sense to have the
Nuttx kernel in NOR flash and only load our application into
external+internal SRAM.

> 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 ?))

XIP from flash should be a no-brainer, if the code is linked to the
right address.  I guess we simply divide the flash in one .text+.rodata
part, and one filesystem partition.

SRAM/SDRAM division as indicated above.  Linker script will take care of
correct linking.  The only part I see is that our bootloader will have
to load the different segments to different addresses correctly before
jumping into Nuttx.

> > - 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.

I think what our use case really wants is something that can efficiently
create (and allocate from) pools of same-sized objects (like our 'struct
msgb').  We'll probably have to code something custom for it,

One real Nuttx related question that I have in mind though:  Do you see
an easy way how we can keep our 'application' code (that is all the GSM
related stuff) in a separete source repository?  I would like to come up
with a situation where we have two repositories:

1) Nuttx (contains calypso uart/spi/i2c/lcd/... drivers and demo apps)
2) OsmocomBB (contains GSM layer1 and our application code)

The reason for this is simple: The GSM code is still under a lot of
flux, and we have many branches of it for different types of
experiments.  None of it will be useful to the general Nuttx user, as it
is very specific to our project.

Would it be as simple as to put a symlink pointing to the OsmocomBB
repository somewhere in the Nuttx source tree?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the baseband-devel mailing list