This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
l--putt ichgeh at l--putt.deHi 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