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://firstname.lastname@example.org/.Craig Comstock craig_comstock at yahoo.com
Craig Comstock <craig_comstock <at> yahoo.com> writes: > > Craig Comstock <craig_comstock <at> yahoo.com> writes: > > > > > > > Hi all, > > > > Was starting to work on making a usable phone again and wondered about the > status of nuttx-bb git on osmocom.org 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 generated. 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.