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/.
Harald Welte laforge at gnumonks.orgGregory, 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)