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/.
Patrick McHardy kaber at trash.netHarald Welte wrote: > Hi Patrick, > > good to have you on board! > > On Thu, Mar 11, 2010 at 07:19:04PM +0100, Patrick McHardy wrote: > >> I'm trying to run the layer1 firmware and the layer23 program >> with an C123, however as soon as the firmware reports a layer 1 >> reset and a L1CTL_NEW_CCCH_REQ message is sent to the phone, >> it appears to crash and sends a new PROMPT1, causing an endless >> cycle of firmware uploads and following crashes. > > that's something I haven't seen so far yet. Are you using the C123 that > I shipped you (i.e. from the same batch as those I and others use), or > was it obtained somewhere else? In the latter case, it might be some > different hardware version or the like. So far I haven't yet seen any > differences, but well, what do weknow about what the manufacturer did. Yeah, its the one you sent me. I'll try a different one tommorrow. > btw: What about the l1test.bin. This one does a scan over the GSM900 > band and then automatically selects the strongest ARFCN (and sends DATA > INDICATIONS to the layer23). That shows the same behaviour, after finding the first ARFCN it restarts with PROMPT1: ... Assert DSP into Reset Releasing DSP from Reset Setting some dsp_api.ndb values Setting API NDB parameters DSP Download Status: 0x0001 DSP API Version: 0x0000 0x0000 Finishing download phase DSP Download Status: 0x0002 DSP API Version: 0x3606 0x0000 Performing power measurement over GSM900 LOST!ARFCN Top 10 Rx Level ARFCN 22: -41 dBm Received PROMPT1 from phone, responding with CMD read_file(/tmp/harald/l1test.bin): file_size=37000, hdr_len=4, dnload_len=37007 >> Any hints how to debug this further? > > At this point I would say try to eliminate differences to other > developers, i.e. what particular toolchain are you using? Can you try > a layer1.bin compiled by somebody else, just to determine if its > something in the build or something related to your hardware that > we're not doing right yet. I'm using the gnuarm.com gcc 4.0 toolchain. I've also tried using the builds you sent me, no differences. This is what the DSP dumper shows: ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: 0c933a10d0039bcf ====================================================================== Assert DSP into Reset Releasing DSP from Reset DSP bootloader version 0x0100 DSP dump: Registers [00000-0005f] 00000 : 3000 0008 0008 0008 0e0c 0e0c 181f 2900 0000 0000 0000 0060 0000 0000 0000 3fa6 00010 : 4340 005f 0813 0014 0003 0014 4099 43c0 1100 00ff 0000 8869 8869 ffa8 0000 0000 00020 : 0000 0000 0800 0000 f501 ffff 0000 0000 7fff f802 0000 0000 0000 0000 0000 0000 00030 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000