Nuttx for Calypso

l--putt ichgeh at l--putt.de
Tue May 24 22:13:31 UTC 2011


Hi all,

after that bunch of patches, some more thoughts:

On 24.05.2011 17:04, Harald Welte wrote:
> Hi Gregory,
>
> On Tue, May 24, 2011 at 06:38:10AM -0700, Gregory Nutt wrote:
>
>> 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).
> 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
> applicaitons.

My plan is to bring up NuttShell, add NXFLAT support and put that into
flash. We can then load a ramfs image by whatever means and execute the app.

The problem is that the UART driver is still a hack. I'm reusing the
Osmocom code (with IRQ stuff modified) and wrapped it into a Nuttx
device structure. However, this is one-way phone to host for the time
being. The current UART driver is closely tied to sercomm and the
console, respectively. A cleaner seperation might help ports to other
devices, new protocols, etc.

Before I spend more work on the current code: Is the sercomm protocol
successful and will stay? What interface to userspace do you suggest?
Should be something that works on Linux if our stuff ends up on more
powerful devices. My proposal: A char device /dev/sercomm Each time you
open it, it starts a new channel. With ioctl, you can change the
channel. Each write is send as a message. Nuttx has buffers for stdio
and hence will take care that there are not too many messages (I hope :P
) The receive part: a blocking read?

>> 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=
> great, we will simply use that feature then.

If you don't see any problems, I would like to go one step further and
move some of the hardware initialization like dsp, dma,... into
user_main. Advantage: I won't go into the binary if you don't need it
(hello_world, charger debugging, whatever)

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

I thought local_fiq_disable() in secomm_cons messes around with FIQs.
Why is that save or what does it actually do?

> Thanks once again for all your support,
> 	Harald


Regards,
Stefan




More information about the baseband-devel mailing list