Hi,
I'm trying to run the latest osmocom-bb git on a Motorola C118 phone.
After a minor problem with the build (as you may've noticed in the
patch I've sent). I got to the point of successfuly running layer1 on
the phone and the mobile app on the PC (I have also enabled TX). The
process seems to be stuck on trying to perform a location update. The
status of the ms is always either:
show ms
MS '1' is up, MM connection active
IMEI: 000000000000000
IMEISV: 0000000000000000
IMEI generation: fixed
automatic network selection state: A1 trying RPLMN
MCC=104 MNC=002 (104, 002)
cell selection state: connected mode 1
ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9
(104, 002)
radio ressource layer state: connection pending
mobility management layer state: wait for RR connection (location updating)
OsmocomBB>
or
show ms
MS '1' is up, service is limited (pending)
IMEI: 000000000000000
IMEISV: 0000000000000000
IMEI generation: fixed
automatic network selection state: A1 trying RPLMN
MCC=104 MNC=002 (104, 002)
cell selection state: C3 camped normally
ARFCN=19 MCC=104 MNC=002 LAC=0xb00f CELLID=0x4fd9
(104, 002)
radio ressource layer state: idle
mobility management layer state: MM idle, attempting to update
OsmocomBB>
I think, that because of this I can't make any calls or send sms (all
the requests are being rejected):
OsmocomBB# call 1 <X>
call 1 <X>
OsmocomBB#
% (MS 1)
% Call has been rejected
The log information from mobile when it's trying to do a location
update is show below:
<000b> gsm48_rr.c:2174 PAGING REQUEST 1
<000b> gsm48_rr.c:2141 IMSI 260021964220249 (not for us)
<000b> gsm48_rr.c:2132 TMSI fd82a501 (not for us)
<000e> gsm48_mm.c:344 Location update retry
<0005> gsm48_mm.c:345 timer T3211 (loc. upd. retry delay) has fired
<0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_TIMEOUT_T3211' event
in state MM IDLE, attempting to update
<000e> gsm48_mm.c:2199 Perform location update (MCC 104, MNC 002 LAC 0xb00f)
<0005> gsm48_mm.c:2333 LOCATION UPDATING REQUEST
<0005> gsm48_mm.c:2355 using LAI (mcc 104 mnc 002 lac 0xb00f)
<0005> gsm48_mm.c:2363 using TMSI 0x28a3d62e
<0005> gsm48_mm.c:914 new state MM IDLE, attempting to update -> wait
for RR connection (location updating)
<0001> gsm48_rr.c:5428 (ms 1) Message 'RR_EST_REQ' received in state
idle (sapi 0)
<000e> gsm48_rr.c:1318 Establish radio link due to mobility management request
<0003> gsm322.c:4037 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell
selection in state 'C3 camped normally'
<0003> gsm322.c:823 new state 'C3 camped normally' -> 'connected mode 1'
<0003> gsm322.c:3653 Going to camping (normal) ARFCN 19.
<0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB)
<0001> gsm48_rr.c:366 new state idle -> connection pending
<0001> gsm48_rr.c:1465 CHANNEL REQUEST: 00 (Location Update with NECI)
<0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17)
<0001> gsm322.c:2959 using DSC of 90
<0003> gsm48_rr.c:4816 Channel provides data.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 5)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 0 ra 0x0e)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 4)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x07)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38
TS 2 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x75 chan_nr 0x0a MAIO 0 HSN 38
TS 2 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 3)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x0f)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 2)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x01)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1
SS 3 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 1/553m ra 0x18 chan_nr 0x59 ARFCN 19 TS 1
SS 3 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 1)
<0001> gsm48_rr.c:1658 RANDOM ACCESS (Tx-integer 50 combined no
S(lots) 55 ra 0x0a)
<0001> gsm48_rr.c:1697 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm)
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 1 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:1601 RANDOM ACCESS (requests left 0)
<0001> gsm48_rr.c:1605 Done with sending RANDOM ACCESS bursts
<0001> gsm48_rr.c:836 starting T3126 with 5.000 seconds
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x0a chan_nr 0x41 ARFCN 19 TS 1
SS 0 TSC 1)
<0001> gsm48_rr.c:2393 request 0a matches but not frame number
(IMM.ASS fn=22,6,30 != RACH fn=22,5,25)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1
SS 1 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x05 chan_nr 0x49 ARFCN 19 TS 1
SS 1 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-77 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1
SS 4 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2473 (ta 2/1107m ra 0x00 chan_nr 0x61 ARFCN 19 TS 1
SS 4 TSC 1)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38
TS 3 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x7d chan_nr 0x0b MAIO 0 HSN 38
TS 3 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 0 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 3 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38
TS 1 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT:
<0001> gsm48_rr.c:2462 (ta 2/1107m ra 0x77 chan_nr 0x09 MAIO 0 HSN 38
TS 1 SS 0 TSC 0)
<0001> gsm48_rr.c:2503 Request, but not for us.
<0001> gsm48_rr.c:2225 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:2170 PAGING ignored, we are not camping.
<0001> gsm48_rr.c:673 MON: f=19 lev=-78 snr= 0 ber= 6 LAI=104 002 b00f ID=4fd9
<0001> gsm48_rr.c:765 timer T3126 has fired
<000e> gsm48_rr.c:770 Requesting channel failed
<0001> gsm48_rr.c:366 new state connection pending -> idle
<0003> gsm322.c:4037 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection
in state 'connected mode 1'
<0003> gsm322.c:3565 Selecting ARFCN 19. after LOC.UPD.
<0003> gsm322.c:463 Sync to ARFCN=19 rxlev=-74 (Sysinfo, ccch mode NON-COMB)
<0003> gsm322.c:823 new state 'connected mode 1' -> 'C3 camped normally'
<0005> gsm48_mm.c:3902 (ms 1) Received 'RR_REL_IND' from RR in state
wait for RR connection (location updating) (sapi 0)
<0005> gsm48_mm.c:2732 RR link released after loc. upd.
<000e> gsm48_mm.c:2676 Location update failed
<000e> gsm48_mm.c:2686 Try location update later
<0005> gsm48_mm.c:2688 Loc. upd. failed, retry #0
<0005> gsm48_mm.c:413 starting T3211 (loc. upd. retry delay) with 15.0 seconds
<0005> gsm48_mm.c:1143 We are camping normally as returning to MM IDLE
<0005> gsm48_mm.c:1159 Loc. upd. allowed.
<0005> gsm48_mm.c:919 new state wait for RR connection (location
updating) -> MM IDLE, location updating needed
<0005> gsm48_mm.c:909 new MM IDLE state location updating needed ->
attempting to update
<0005> gsm48_mm.c:2215 Loc. upd. already pending.
<0005> gsm48_mm.c:4311 (ms 1) Received 'MM_EVENT_CELL_SELECTED' event
in state MM IDLE, attempting to update
<0005> gsm48_mm.c:2215 Loc. upd. already pending.
<0003> gsm322.c:2938 Channel synched. (ARFCN=19, snr=16, BSIC=17)
<0001> gsm322.c:2959 using DSC of 90
Can you provide me any hints on how to debug this ? Why is the
location update failing constantly ?
Thanks in advance for your help.
Best regards,
Maciej Grela
"TSAREGORODTSEV, Yury" <yury(a)bridgecommunication.co.uk> wrote:
> Damn, yeah
> its not charging at all :)
> even when connected to hub with external power :)
Unfortunately there are no schematics available for the DP-L10 (and
reconstructing them from steve-m's PCB layer scans is anything but
easy), so everything that follows is ultimately pure guesswork, but it
*seems* to me that the battery charging circuit in this phone is
fundamentally the same as in the more traditional Calypso+Iota phones
(Compal etc), aside from using USB VBUS as the charging power source
instead of a dedicated round-plug type of power jack.
If the charging circuit in the DP-L10 works the way I think it does,
following common sense and all that, than the battery charging process
ought to be controlled by Iota ABB. The ABB chip in this phone is
TWL3014, but I'll use the more readable TWL3025 datasheet as a
reference instead - back in 2011 both Steve M. and Sylvain M. said on
this list that the two chips are functionally identical.
The battery charging functionality is described on pages 46-48 of
TWL3025_SWRS021.pdf; in particular, refer to Figure 4-10 on page 48.
If my understanding of this datasheet description is correct, and if
the phone in question (Pirelli DP-L10) indeed has its battery charging
circuit implemented in the canonical way, then one of the following
two conditions must be met in order for charging current to pass from
VBUS into the battery:
1. The "precharge" function is enabled inside the ABB chip, such that
an internal transistor in the ABB opens up to pass some current from
the VCHG pin to the PCHG pin. This precharge function is intended for
situation when the battery has discharged so low that it needs to be
charged some before one can boot the CPU, hence this precharge phase
has to be done entirely in hardware without any CPU firmware
supervision. But it appears that this hardware-only precharge function
is automatically disabled when the CPU is turned on, or maybe the
precharge current is so feeble that the drain from the running CPU is
greater than the amount of power coming from the precharge circuit.
-or-
2. The "normal" way of charging the battery (with the CPU running) is
for the CPU to enable the main charging circuit in the ABB via some
register writes. In this case the power flows from the charging source
(USB VBUS in the case of Pirelli DP-L10) into the battery through an
external power transistor controlled by the ICTL output from the ABB.
In TI's standard firmware the battery charging function lives in the
PWR SWE (RiViera Software Entity) in the older versions and in the LCC
SWE in newer ones. Pirelli's version appears to use PWR rather than
LCC. We (the world public) have the source for the PWR SWE in the
MV100 find, and that for LCC in the Sotovik find, but I haven't really
looked at either of them yet - working on L1 integration currently.
If you would like to get Pirelli battery charging working in OsmocomBB,
I would recommend that you take the charging code for compal_e88,
enable it for the DP-L10 build, and experiment from there. Don't be
fooled by Pirelli's use of USB charging instead of a round-plug
charger, my guess is that they use USB VBUS in exactly the same way as
how Compal etc use their charging power source.
It also seems to me that Pirelli's charging mechanism does not strictly
comply with the USB spec. Per the spec, you are supposed to draw no
more than 100 mA from VBUS until and unless you negotiate a higher
power budget with the host, and that negotiation takes place over the
D+ and D- wires. But in Pirelli's case these D+ and D- wires go to
the CP2102 USB-serial chip and nowhere else, and only this CP2102
speaks the USB protocol - the Calypso only sees UART-serial on the
other side of the CP2102. So they "illegally" tap VBUS (which per the
spec must not go anywhere but to the device that speaks the USB
protocol) to use it as the charging power source, but have no way to
negotiate their current draw.
When Pirelli's fw detects the presence of VBUS via the charger-insert
interrupt from the ABB and decides to start charging the battery, it
has no choice but to enable some hard-coded charging current value -
the charging current can be adjusted by programming a register in the
ABB, but the fw has no way of knowing how much current it is allowed
to draw from VBUS, if any at all, because only the USB logic in the
CP2102 has access to this knowledge. So whatever charging current it
draws, it must do so blindly. I can only guess that this current must
be somewhere around 500 mA, as charging at 100 mA would be too slow.
I actually like Pirelli's design in this regard, and I currently plan
on copying it in my own Pirelli-inspired Calypso dumbphone design: put
a CP2102 inside the phone just like Pirelli did, and use the same USB
charging arrangement, drawing 500 mA for charging unconditionally,
showing "the middle finger" to the developer-unfriendly Unusable
Serial Botch specs... Or can someone think of a better way?
VLR,
SF
Hello,
anyone has experience to use application mobile on pirelli ?
there is no layer1.compalram.bin for this model,
any ideas how to run app mobile?
Sincerely Yours,
Tsaregorodtsev Yury
Bridge Communication Billing & Settlement Plan Limited
Fernhills Business Center, Foerster Chambers,
Todd Street Bury, Gtr Manchester, BL9 5BJ
United Kingdom
Tel: +441570200000
ICQ: 622719210
MSN: y.tsaregorodtsev(a)live.com
Skype: tsarik-108
web: www.bridgecommunication.co.uk
Hi
I wonder if there is a way to develop a Denial of Service or Conditional Access system for a GSM network based on Osmocom. The idea is to develop a commercial product intended to be used to limit unlawful communication in prisons or correctional facilities. My investigation is that this is a kind of worldwide necessity as inmates use smuggled mobile phones for criminal activities (I live in Central America and constantly see news that confirm this is urgent requirement). Currently there a few options available to achieve this purpose:
1. Government authorities require telecom operators to reduce radio signal in the vicinity of confinement facilities2. The use of radio jamming systems to propagate a noise signal3. One or two commercial solutions like iNAC Managed Access from Tecore (a very clever and patented technology)
I imagine a solution based on Osmocom as a base station simulating a roaming area in the correctional facility area, for authorized users, dummy network should appear as a FPLMN but for illegal users the fake network must grant access entering driving them into a dead end network with no communication. However I see there are several flaws for this aproach: one is that inmates could set their mobiles to manual network selection and connect themself to commercial mobile networks but I hope this could serve as a ground for further discussion. I will appreciate very much your comments. Regards,
Hi
I thought I try to flash some osmocom tools into a C118.
I have the loader loaded succesfully onto the C118.
I can do a finfo (see below)
So I wanted to backup the complete flash:
osmoload memdump 0x000000 0x200000 c118.bin
-> I get "bad crc" for every page
Same when I try to backup the loader as on the flashing wiki.
Dumping 8192 bytes of memory at 0x0 to file compal_loader.bin
bad crc 4190 (not 5c9a) at offset 0x00000000
bad crc f041 (not d50d) at offset 0x000000f0
bad crc f041 (not 3afa) at offset 0x000001e0
Is the C118 not supported for flashing?
Can somebody give me any helpful hints?
CU, Ricsi
chip 0 at 0x00000000 of 2097152 bytes in 2 regions
region 0 with 31 blocks of 65536 bytes each
block 0 with 65536 bytes at 0x00000000 on chip 0
block 1 with 65536 bytes at 0x00010000 on chip 0
block 2 with 65536 bytes at 0x00020000 on chip 0
block 3 with 65536 bytes at 0x00030000 on chip 0
block 4 with 65536 bytes at 0x00040000 on chip 0
block 5 with 65536 bytes at 0x00050000 on chip 0
block 6 with 65536 bytes at 0x00060000 on chip 0
block 7 with 65536 bytes at 0x00070000 on chip 0
block 8 with 65536 bytes at 0x00080000 on chip 0
block 9 with 65536 bytes at 0x00090000 on chip 0
block 10 with 65536 bytes at 0x000a0000 on chip 0
block 11 with 65536 bytes at 0x000b0000 on chip 0
block 12 with 65536 bytes at 0x000c0000 on chip 0
block 13 with 65536 bytes at 0x000d0000 on chip 0
block 14 with 65536 bytes at 0x000e0000 on chip 0
block 15 with 65536 bytes at 0x000f0000 on chip 0
block 16 with 65536 bytes at 0x00100000 on chip 0
block 17 with 65536 bytes at 0x00110000 on chip 0
block 18 with 65536 bytes at 0x00120000 on chip 0
block 19 with 65536 bytes at 0x00130000 on chip 0
block 20 with 65536 bytes at 0x00140000 on chip 0
block 21 with 65536 bytes at 0x00150000 on chip 0
block 22 with 65536 bytes at 0x00160000 on chip 0
block 23 with 65536 bytes at 0x00170000 on chip 0
block 24 with 65536 bytes at 0x00180000 on chip 0
block 25 with 65536 bytes at 0x00190000 on chip 0
block 26 with 65536 bytes at 0x001a0000 on chip 0
block 27 with 65536 bytes at 0x001b0000 on chip 0
block 28 with 65536 bytes at 0x001c0000 on chip 0
block 29 with 65536 bytes at 0x001d0000 on chip 0
block 30 with 65536 bytes at 0x001e0000 on chip 0
region 1 with 8 blocks of 8192 bytes each
block 31 with 8192 bytes at 0x001f0000 on chip 0
block 32 with 8192 bytes at 0x001f2000 on chip 0
block 33 with 8192 bytes at 0x001f4000 on chip 0
block 34 with 8192 bytes at 0x001f6000 on chip 0
block 35 with 8192 bytes at 0x001f8000 on chip 0
block 36 with 8192 bytes at 0x001fa000 on chip 0
block 37 with 8192 bytes at 0x001fc000 on chip 0
block 38 with 8192 bytes at 0x001fe000 on chip 0
Hi List
I have just reactivated my Pirelli Osmocom phone, and recompiled osmocom-bb.
(after rolling back libosmocore it works great)
But can it be that charging is not implemented on the Pirelli phone with OsmocomBB?
When I attach the MiniUSB cable, I can upload the code great, but when I leave it running for a longer time, it booted into the default charging pirelli screen.
I assume that the battery is not that good any more, and it seems that it is running on battery power instead of on USB power.
When I upload the RSSI app to the phone it shows me an empty battery icon in the right.
(Pirelli SW showed completely full battery icon)
Can somebody confirm that the pirelli phone is not charging in osmocom-bb?
Is there a chance tha somebody is looking into this anytime?
CU, Ricsi
PS: Is it still correct that the jolly/test branch is the best for 2 phone transceiver (for OpenBTS/OpenBSC)?
This branch should support 2 phones.
But as half rate channels are not supported you can only make one call.
(ie not possible to make a testcall without going over SIP)
Is this information still valid?
