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

Craig Comstock craig_comstock at
Fri Apr 17 04:50:04 UTC 2015

Craig Comstock <craig_comstock <at>> writes:

> Craig Comstock <craig_comstock <at>> writes:
> > 
> > 
> > Hi all,
> > 
> > Was starting to work on making a usable phone again and wondered about the
> status of nuttx-bb git on versus nuttx source. It seems nuttx
> source is more up-to-date and has configs for my device: compal_e86/c139.
> Wondering if there is something in nuttx-bb that is unique that I should pay
> attention to? Should nuttx-bb be rebased from nuttx upstream?
> > 
> > I was able to cobble together a nuttx.bin but on loading it always stops
> at 88% with the chainloader. The nuttx.bin is 148K which would seem plenty
> of room since the C139 has 4000K flash (32MBit) (am I doing that calculation
> correctly)?
> > 
> > I had to fiddle with the MEMORY section of the ld.script in order to make
> space for nuttx, I'm not too familiar with this sort of thing so may have
> done something wrong...
> > 
> > /* E86 stacked flash 32mbit flash, 4mbit sram, DBB internal 256kb SRAM
> */    /* 0x800000-0x87ffff */ /* bump up because we have 32mbit instead of
> 16mbit */    /* compal-loaded binary: our text, initialized data */    LRAM
> (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000    TRAM (rw) : ORIGIN =
> 0x00820000, LENGTH = 0x00040000    /* compal-loaded binary: our unitialized
> data, stacks, heap */    IRAM (rw) : ORIGIN = 0x00860000, LENGTH = 0x00020000
> > 
> > 
> > Originally TRAM was 20000 long and gave me an error on building. Not sure
> if I can fiddle with these values or not.
> > 
> > 
> > Thanks,
> > Craig
> > 
> > 
> > 
> > Attachment (diff2): application/octet-stream, 4233 bytes
> > Attachment (osmocon.log): text/x-log, 3339 bytes
> I did some debugging on osmocon and it seems it is getting stuck on the
> serial read not returning anything, maybe blocking forever waiting for data
> coming back. I wasn't sure how the chainloader program was loaded... there
> seemed to be 30-40 bytes of code in an array maybe? Maybe the chainloader is
> being corrupted? Other chainloaded programs such as rssi work just fine so
> maybe my nuttx.bin is causing a problem somehow.
> Thanks,
> Craig

I tried chopping the binary down to 130 chunks of 1014 bytes, i.e. 128kb
bytes, and that loads fine. So maybe this TI Calypso romloader can only load
128kb? The osmocom c140 page mentions 256kb of internal SRAM. Can anyone
give me some clues here? I suppose the c139 might have a different Calypso
chip with only 128kb internal sram?

Does this have something to do with the extra control register ffff:fb10 it
has a note that mentions access ending at some point...

0 = Accessing nCS3 with programmed wait-state.
1 = When accessing nCS3 the number of wait is
set to 127, but access is ended when
nready_mem goes low. If nready_mem stays
at ‘1’ after 127 wait states an abort is

I read a bunch of old messages on this list about nuttx b/w Greg and Harald
and learned a lot. Sounds like running NuttX from flash and then loading
GSM-specific "apps" into SRAM is sort of the best idea?

If anyone else is working on nuttx-bb or maybe porting mobile onto the phone
it would be great to collaborate.

More information about the baseband-devel mailing list