From craig_comstock at yahoo.com Wed May 6 12:02:20 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Wed, 6 May 2015 12:02:20 +0000 (UTC) Subject: nuttx, menu, loader, running from flash Message-ID: <32479685.1036955.1430913740713.JavaMail.yahoo@mail.yahoo.com> Hi, I'm trying to get nuttx running on my C139 compal_e86(88?) phone. I have been reading some emails and loader scripts but am a bit unexperienced with this area of software. I've managed to use the "menu" app with flashing successfully but so far am unable to get nuttx to run either due to the compal loader not letting me load more than 128k into highram or the flash setup not being quite right in terms of loader scripts. I think what I would like is this (based loosely on LINKAGE.txt in osmocom-bb/.../compal_e88) - keep compal loader at 0x0- put something custom at 0x2000, either the menu app or a simple 2nd stage loader- put nuttx at 0x10000 The "menu" app option (http://bb.osmocom.org/trac/wiki/flashing_new) would require me to modify that code a bit so that I wasn't copying nuttx into highram but instead just running it "in-place" in flash. So maybe two header options: "highram:APPNAME" and "flash:APPNAME"? I suppose I could try running nuttx in highram as menu currently intends, by copying it from flash to ram but that seems sort of "wrong" if nuttx is my main goal. The "other" option would be to write some simple loader for 0x2000 which did whatever setup might be required (none?) and simply jump to 0x10000. That way the ideas in LINKAGE.txt about safety and what-not are preserved. If I need to flash a new nuttx image I don't have to worry about ruining page 0 and compal loader and bricking the phone. Another option would be to replace the compal loader but I'd rather get to nuttx sooner than later and don't see much immediate advantage to an entirely custom bootloader. If I preserve the compal loader then all the normal osmocom-bb functionality is preserved in terms of being able to load layer1, rssi if you want to in highram while nuttx could be living in flash for booting into "normally" to use as a consumer-style device. I think I prefer the "other" option I mention above to keep things fairly simple. Do you think I can just use the flash.lds from compal_e88, modify slightly for e86 (bigger IRAM I think is the only change) and simply put a jump at 0x2000 to 0x10000? Would that take care of exception vectors, setup and all the other stuff I don't currently understand about bringing things "up"? Just FYI, I am working off the latest nuttx code and not nuttx-bb since nuttx-bb seems pretty out of date. Not sure what folks want to do with that. Thanks,Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Thu May 7 14:54:02 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 7 May 2015 14:54:02 +0000 (UTC) Subject: nuttx, menu, loader, running from flash References: <32479685.1036955.1430913740713.JavaMail.yahoo@mail.yahoo.com> Message-ID: Craig Comstock yahoo.com> writes: > > > Hi, > > I'm trying to get nuttx running on my C139 compal_e86(88?) phone. I have been reading some emails and loader scripts but am a bit unexperienced with this area of software. I've managed to use the "menu" app with flashing successfully but so far am unable to get nuttx to run either due to the compal loader not letting me load more than 128k into highram or the flash setup not being quite right in terms of loader scripts. > > > I think what I would like is this (based loosely on LINKAGE.txt in osmocom-bb/.../compal_e88) > > > - keep compal loader at 0x0 > - put something custom at 0x2000, either the menu app or a simple 2nd stage loader > - put nuttx at 0x10000 > > The "menu" app option (http://bb.osmocom.org/trac/wiki/flashing_new) would require me to modify that code a bit so that I wasn't copying nuttx into highram but instead just running it "in-place" in flash. So maybe two header options: "highram:APPNAME" and "flash:APPNAME"? I suppose I could try running nuttx in highram as menu currently intends, by copying it from flash to ram but that seems sort of "wrong" if nuttx is my main goal. > > The "other" option would be to write some simple loader for 0x2000 which did whatever setup might be required (none?) and simply jump to 0x10000. That way the ideas in LINKAGE.txt about safety and what-not are preserved. If I need to flash a new nuttx image I don't have to worry about ruining page 0 and compal loader and bricking the phone. > > Another option would be to replace the compal loader but I'd rather get to nuttx sooner than later and don't see much immediate advantage to an entirely custom bootloader. > > > If I preserve the compal loader then all the normal osmocom-bb functionality is preserved in terms of being able to load layer1, rssi if you want to in highram while nuttx could be living in flash for booting into "normally" to use as a consumer-style device. > > I think I prefer the "other" option I mention above to keep things fairly simple. Do you think I can just use the flash.lds from compal_e88, modify slightly for e86 (bigger IRAM I think is the only change) and simply put a jump at 0x2000 to 0x10000? Would that take care of exception vectors, setup and all the other stuff I don't currently understand about bringing things "up"? > > > Just FYI, I am working off the latest nuttx code and not nuttx-bb since nuttx-bb seems pretty out of date. Not sure what folks want to do with that. > > Thanks, > Craig > > > I modified the menu firmware to simply jump to 0x10000. Flashed the compal_loader + menu + nuttx using a slightly modified flash.lds from compal_e88 (put start of FLASH at 0x10000) and it kind of worked. Got an exception printout from nuttx code complaining about unregistered IRQ so I think I'm on my way. I'll probably have a good patch submitted to nuttx pretty soon that others could play with if they wish. From craig_comstock at yahoo.com Fri May 8 02:34:56 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 8 May 2015 02:34:56 +0000 (UTC) Subject: patch on jolly/menu for jumper app Message-ID: <2019415965.2390591.1431052496602.JavaMail.yahoo@mail.yahoo.com> Here is a patch for a simple "jumper" app which loads at 0x2000 and which disables the irqs (thought it might help with the nuttx startup error I have) and jumps to 0x10000 (where I have flashed nuttx). I'm submitting a patch to nuttx as well for building nuttx.bin for running in compal_e86 flash. I may have fouled up the patch due to being on jolly/menu. Wasn't sure if you wanted to pull in those changes as well? I've certainly used the menu app with the flashing_new instructions and it seems to work great on my c139. -Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-support-for-e86-flash-and-loader-configs-as-well.patch Type: text/x-patch Size: 13029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Menu-App-to-select-highram-images-from-phone-s-flash.patch Type: text/x-patch Size: 8810 bytes Desc: not available URL: From craig_comstock at yahoo.com Tue May 12 04:29:14 2015 From: craig_comstock at yahoo.com (Craig Comstock) Date: Tue, 12 May 2015 04:29:14 +0000 (UTC) Subject: c139 nuttx bringup - irq problem? Message-ID: <1510380614.214480.1431404954323.JavaMail.yahoo@mail.yahoo.com> Hi, I'm working on bringing up nuttx on the c139. I am running this as I described previously by jumping from 0x2000 to 0x10000 with a small firmware image there and then nuttx is configured to run from flash at 0x10000. I configured nuttx RAM to live at 0x800100 to skip the exception vectors area that the compal loader sets up. NuttX is coming up somewhat but getting stuck on an unregistered interrupt #21 which seems strange since there are 21 interrupts and I thought they might be 0-based so not sure what's going on here. Was wondering if there was some state that the compal loader setup that is giving me problems or if there is some other issue going on. If anyone has an idea off-hand let me know. If I take a DEBUGASSERT() out is when I get the info about irq 21. With the DEBUGASSERT() in it seems I'm trying to do initialization during interrupt handling somehow?? "This API should not be called from interrupt handlers" is the comment near the assert in sem_wait(). Attached is a serial log from the phone booting up. I've added a lot of debug logging beyond what is normally in NuttX. I included first a log with DEBUGASSERT() included and then one without. Thanks,Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: with-assert.log Type: text/x-log Size: 3277 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: without-assert.log Type: text/x-log Size: 14132 bytes Desc: not available URL: From Max.Suraev at fairwaves.co Fri May 22 13:38:01 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Fri, 22 May 2015 15:38:01 +0200 Subject: segfault on bssgp test Message-ID: <555F3139.4080206@fairwaves.co> Hi. Anyone else experienced this with latest libosmocore from git? ./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test stderr: MESSAGE to 0x7f0000ff, msg length 12 02 00 81 01 01 82 0b 56 04 82 0b 55 All NS-VCs for NSEI 2901 are either dead or blocked! All NS-VCs for NSEI 2901 are either dead or blocked! BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989 Unable to resolve NSEI 4660 to NS-VC! Assert failed rc >= 0 gb/gprs_bssgp_test.c:229 /home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25: 8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_ bssgp_test -- best regards, Max, http://fairwaves.co From danieljesc at gmail.com Fri May 22 17:23:27 2015 From: danieljesc at gmail.com (Daniel Escobar) Date: Fri, 22 May 2015 17:23:27 +0000 (UTC) Subject: Baseband: MS '1' is up, service is limited References: <1365762485338-4025975.post@n3.nabble.com> <1365831951751-4025978.post@n3.nabble.com> <1365990897108-4025986.post@n3.nabble.com> Message-ID: hungbangchu gmail.com> writes: > >> View this message in context: > >> http://baseband-devel.722152.n3.nabble.com/Baseband-MS-1-is-up- service-is-limited-tp4025964p4025978.html > >> Sent from the baseband-devel mailing list archive at Nabble.com. > >> > >> > > -- > View this message in context: http://baseband- devel.722152.n3.nabble.com/Baseband-MS-1-is-up-service-is-limited- tp4025964p4025986.html > Sent from the baseband-devel mailing list archive at Nabble.com. > > Hi i find that the problem is the version the mobile and the image .bin that you load in mobile, that is to say: for MotorolaC115/C117 you need the binary into: (compal_E87) (layer1.compalram.bin) MotorolaC123/C121/C118 you need the binary into: (compalE88) MotorolaC140/C139 you need the binary into: (compalE86) MotorolaC155 you need the binary into: (compalE99) ? our secondary target MotorolaV171 you need the binary into: (compalE68/E69) i hope that this can help you. Regards @mrdesc from colombia. From alexandr_x at list.ru Tue May 26 17:45:58 2015 From: alexandr_x at list.ru (=?UTF-8?B?QWxleGFuZGVy?=) Date: Tue, 26 May 2015 20:45:58 +0300 Subject: =?UTF-8?B?YmFkIGNyYyA5YmYx?= Message-ID: <1432662358.953069542@f314.i.mail.ru> Hello Biggest thanks for the osmocombb project! ? I am trying to follow this wikki http://bb.osmocom.org/trac/wiki/flashing_new ? to flash rssi app ? And facing this error host/osmocon/osmoload fprogram 0 0x010000 compal_loader.bin Loading 8192 bytes of memory at 0x10000 in chip 0 from file compal_loader.bin bad crc 9bf1 (not 4190) at offset 0x00000000 status 69206016, aborting ? How to solve it? ? I use latest jolly/menu git branch HW: C115 and c113 ( e88) ?both providing same error -- Sincerely, Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: