Nuttx for Calypso

historical

Hi, Harald,

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

The NuttX startup logic may have to care in that it may have to initialize data sections.  Running in RAM, the start-up code may have to initialized .bss.  But running out of FLASH, it will need to copy .data from into RAM.  If you want executable code in internal SRAM, then that code would have to be copied into IRAM in either case.

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

This worked fine that last time I used that configuration.  There is a configuration option CONFIG_BOOT_RUNFROMFLASH that would have to be deselected so that it would not try to initialize .data (and a different linker script would have to be used so that initialization data is not saved in FLASH)

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

Are you talking about a separately linked, monolithic kernel (like a tiny Linux) and a separately built application image?  The application image would then have to communicate to the monolithic kernel either through a call table or through system calls (or it would have to be linked with the kernel image at build time).

Is that what you are thinking?  I have implemented that configuration for the Cortex M3 (with supervisor/user mode and system calls).  There there hooks are in place for ARM7 as well but more integration work is needed.

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

XIP from FLASH can mean a lot of things.  Running a NuttX image from flash truly is a no brainer.  Running separate programs from FLASH is complex because dynamic linking is needed.  NuttX supports a file format called NXFLAT that will let you run a program from an XIP file system (like ROMFS) but it needs a symbol table and NXFLAT loader (the moral equivalent of ld.so).

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

Or if NuttX is in FLASH, it can copy memory as it does now to initialize .data.

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

That seems appropriate.

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

Yes, I am sure you have noticed that NuttX is provided as two tarballs:  One called nuttx-a.b.tar.gz that hold the core OS functionality in the nuttx/ directory and one called apps-a.b.tar.gz that holds sample application code in the apps/.  That apps/ directory is meant to be a "break-away."  You would discard the current apps/ directory (taking whatever is useful to you), and create your own application directory.

When NuttX builds is needs to know the location of the apps directory.  In the .config configuration file, you will see:

#
# General OS setup
#
# CONFIG_APPS_DIR - Identifies the relative path to the directory
#   that builds the application to link with NuttX.  Default: ../apps
...
#CONFIG_APPS_DIR=

Note that CONFIG_APPS_DIR is not defined.  And at the very bottom of the configuration file you will see:

# Application configuration

CONFIG_APPS_DIR="../apps"

The version of CONFIG_APPS_DIR at the bottom of the .config file was not in the original defconfig file.  It was appended by the configuration script.  The configuration script noted that there was no application directory and looked around in some well known locations and picked one.

However, if you were to have defined CONFIG_APPS_DIR=../calypso, then that is the application directory that would have been used.  Your low-level drivers and ARM7 code code could be released inside of the common nuttx repository.  But your application-specific code would reside in your custom application directory.

Would you like to retain the Calypso code in the NuttX SVN repository?  There are some long range advantages to that in that the Calypso code will maintained and will always be in sync with the latest NuttX.  Licensing is the only issue.  NuttX is BSD and Calypso is GPL.  So the possibilities are:  (1) You carry the NuttX code in your repository, (2) You release the Calypso OS (only) logic under BSD, or (3) I carry the Calypso code as GPL add-on.

The base NuttX is BSD, but I have started putting together GPL add-on support. I would keep the GPL separate and there would be an INSTALL script.  In the install script would require that the user agree to the GPL license.  And if so, it would copy the GPL code into the NuttX source tree and replace the COPYING files, making the combined code GPL.  This is kind of awkward, but if you would like to have a GPL version of NuttX for Calypso, then I think this could be the way to go.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110524/be34b7b9/attachment.htm>