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