Nuttx for Calypso
laforge at gnumonks.org
Tue May 24 15:04:29 UTC 2011
On Tue, May 24, 2011 at 06:38:10AM -0700, Gregory Nutt wrote:
> > ... 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).
Well, the call table or syscall approach may be nice to have in the
future, but even linking it at build time (so it knows the addresses of
the various kernel functions it wants to call) would be fine for me
> 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
I've tried to compile the syscall code for ARM7TDMI and figured it is
not complete yet. As indicated above, I don't think it's a big deal.
We shouldn't try to put too much effort into changing/extending Nuttx
and rather use what's there and focus on our GSM related work.
> > 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.
that's what I was primarily thinking of.
> 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
if those things exist and work for ARM7TDMI: great, let's use them.
If not, we can live with that, too. The idea of separate kernel and
application images is simple: We normally download our code via a
115,200 bps serial line, and to speed up development it would be great
to not re-download "all of" nuttx again, but only the GSM related
> > 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
Actually I haven't noticed since I rarely use any release tarballs of
FOSS projects but simply the contents of the revision control system.
But I've noticed the nuttx/ and apps/ directories ;)
> 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
great, we will simply use that feature then.
> 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.
yes, this is what I had in mind.
> 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.
We've already briefly discussed this either here or on IRC, and I have
no problems with the 'standard' non-gsm port+drivers to be under a BSD
license. We would have to see if all developers agree, but I don't see
big problems here.
BTW, since we're in this discussion anyway: The synchronous part of the
GSM Layer1 right runs in FIQ context, to ensure the tight timing of the
TDMA nature of GSM. All non-GSM related interrupts are normal IRQs, so
they can be pre-empted by the GSM FIQ.
Do you see any problems with this? Is there something in the Nuttx
ARM7TDMI related code that disables FIQs or otherwise interferes with
Thanks once again for all your support,
- 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