or 6225 CPUs (need to look for documentation):
--- MT6225BA
CECT V8
TianShiDa TS822
--- MT6225/6225A
CECT 388
CECT 98
CECT 2618
CECT N95i
ChangHong 868
ChuangWei T508
DaXian X889
DaXian X769
GaoXinQi D808
Hantai HT622
Hantai HT6868
JingLi H9 (some H9 also have MT6226)
JinPeng A918
JinPeng 858
JinPeng A9
JinPeng S3506
JinPeng 2298
JinPeng L818
JinPeng A608
TianYu D170
TianYu B898
TianYu A930
TianYu B926
TianYu A908
ZTC 6988
ZTC 598
ZTC 1118
ZTE ZTLV900
ZTE ZT688 (note MT6205 versions also exist)
--- MT6223PA
TianYu B5010
CECT D1088
Next steps for me: Scan the schematics stuff and put it online. Find some
6223/6225 based phones that are cheap & suitable for hacking, i.e. ideally
with some nice test points or JTAG.
Other common MTK chips are 6205, 6217, 6218, 6219, 6226, 6228.
One word of caution - the above lists, and documentation we start digging
up, may give a false impression of predictability. In reality the brand
names and model numbers are a total mess in China. Typos everywhere. All
sorts of things are printed on cases & boxes, chips are changed without
anybody noticing or caring. There are endless smaller Chinese brands making
phones with 6223 or 6225 chips, but I think it will be very hard to use
them as a stable source, to get phones with the same chips over time. So
I think it's better to focus on the somewhat bigger Chinese brands as
listed above.
Wolfgang
not always 100% perfect (it depends on the phone and the cable), so
moving the phone during the download may cause the connection to be
interrupted. I have not yet looked at the serial signal with an
oscilloscope to see if there are problems with the signal itself.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
stage. Any ideas?
If I boot the phone and use 57600bps I get some prints and then AT
returns OK, no other AT commands work.
In case it is too broken I have ordered a C121 from germany as well.
/Erik
without having to go through the real layer1 or at least without having<br>
to go through the air.<br>
<br>
But without a clear path to later porting this on a real physical<br>
layer1, there would be little motivation of doing all that work.<br></block=
quote><div><br>I'd like to get involved in that, however these are my p=
roblems:<br>- I have no running system that I could debug and <br>=A0 there=
by learn how GSM works.<br>
-=A0 To=A0 get a running system I would need to implement a software<br>=A0=
=A0 only system, however, I cannot implement that without knowledge <br>=A0=
=A0 of GSM<br>=A0That is kindof a deadlock. <br><br>Therefore I wonder wea=
ther the expert of GSM would share their <br>
knowledge in the obove described way:<br>Having=A0 <br>=A0 - a flow diagram=
<br>=A0 - the etsi standard pages (or simple rewrites of it)<br>=A0 - the h=
tml parsed imlemention of a real TSM30 stack implement.<br>and linking that=
all together to get a way for a newbie to <br>
get started.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"border-=
left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left=
: 1ex;">
<br>
I think what makes OsmocomBB special is the very fact that we do not<br>
have to rely on simulation, but can do the "real thing".<br>
<br>
Nonetheleess, if somebody was interested in implementing what I've<br>
described, I'd be more than happy to help any such project and<br>
include the neccessary support in OpenBSC and/or OsmocomBB.<br>
<div><div></div><div class=3D"h5"><br>
--<br>
- Harald Welte <<a href=3D"mailto:laforge@gnumonks.org">laforge@gnumonks=
.org</a>> =A0 =A0 =A0 =A0 =A0 <a href=3D"http://laforge.gnumonks.org/" t=
arget=3D"_blank">http://laforge.gnumonks.org/</a><br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
"Privacy in residential applications is a desirable marketing option.&=
quot;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0(ETSI EN 300 175-7 Ch. A6)<br>
</div></div></blockquote></div><br>
--0016e65ae6825c4265048170c62d--
without having to go through the real layer1 or at least without having
to go through the air.
But without a clear path to later porting this on a real physical
layer1, there would be little motivation of doing all that work.
I think what makes OsmocomBB special is the very fact that we do not
have to rely on simulation, but can do the "real thing".
Nonetheleess, if somebody was interested in implementing what I've
described, I'd be more than happy to help any such project and
include the neccessary support in OpenBSC and/or OsmocomBB.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
data to the network by using the RSL RLL DATA REQUEST primitive.
Also, while we are tuned to any BCCH/CCCH, the L3 frames are sent from
L2 to L3 in RSL RLL UNIT DATA INDICATION messages.
What is not as simple is the non-RLL part, i.e. sending the first RACH
request, ...
For those, we will have to invent our own new RSLms message types,
possibly reusing as many RSL information elements as possible - meaning
we can share more code/structure with what we already have in
libosmocore/openbsc
> is there a better (simpler) way?
The RSLms approach might not be the simplest one, but I think it would
be a very nice/orthogonal approach. Plus: In this model, we can
eventually move the L2 implementation into the MS firmware, while
talking RSLms over HLDC to L3 on the PC.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
December 10, 2021 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "osmo-dev and running Osmocom TTCN3 tests suites locally" by osmith
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
November 25, 2021 at 20:00 CET (yes, Thursday instead of Friday this time!)
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "Control/User Plane Separation (CUPS) + PFCP" by laforge
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
November 12, 2021 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "E1 / TDM / PDH / SDH basics" by laforge
20:30 presentation "icE1usb in practice" by tnt
later USSE: unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Kevin,
On Fri, Nov 05, 2021 at 02:18:14PM +0100, Kévin Redon wrote:
> I'm also happy to help with the recording and streaming of the public talks for those not able to join on site.
thanks for that, as usual.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
